Esquemas do ASIM (Modelo de Informações de Segurança Avançado)

Um esquema do ASIM (Modelo de Informações de Segurança Avançado) é um conjunto de campos que representam uma atividade. O uso dos campos de um esquema normalizado em uma consulta garante que a consulta funcione com todas as fontes normalizadas.

Para entender como os esquemas se ajustam à arquitetura do ASIM, veja o diagrama de arquitetura do ASIM.

As referências de esquema descrevem os campos que compõem cada esquema. Atualmente, o ASIM define os seguintes esquemas:

Conceitos de esquema

Os conceitos a seguir ajudam a entender os documentos de referência de esquema e a estender o esquema de maneira normalizada, caso os dados incluam informações que o esquema não abrange.

Nomeação de campo

No núcleo de cada esquema estão os nomes de campo. Os nomes de campo pertencem aos seguintes grupos:

• Campos comuns a todos os esquemas.
• Campos específicos de um esquema.
• Campos que representam entidades, como usuários, que participam do esquema. Campos que representam entidades são semelhantes entre esquemas.

Quando as fontes têm campos que não são apresentados no esquema documentado, elas são normalizadas para manter a consistência. Quando os campos extras representam uma entidade, eles são normalizados com base nas diretrizes de campo de entidade. Caso contrário, os esquemas se esforçam para manter a consistência entre os esquemas.

Por exemplo, embora os logs de atividade do servidor DNS não forneçam informações do usuário, os logs de atividade do DNS de um ponto de extremidade podem incluir informações do usuário, que podem ser normalizadas de acordo com as diretrizes da entidade do usuário. |

Tipos lógicos de campo

Cada campo de esquema tem um tipo. O workspace do Log Analytics tem um conjunto limitado de tipos de dados. Por esse motivo, o Microsoft Sentinel usa um tipo lógico em muitos campos de esquema, que o Log Analytics não impõe, mas são necessários para a compatibilidade do esquema. Os tipos de campo lógicos garantem que os valores e os nomes de campo sejam consistentes nas fontes.

Para obter mais informações, confira Tipos lógicos.

Classes de campo

Os campos podem ter várias classes, que definem quando os campos devem ser implementados por um analisador:

• Os campos obrigatórios devem aparecer em cada analisador. Se a sua fonte não fornecer informações para esse valor ou se os dados não puderem ser adicionados de outra forma, não haverá suporte para a maioria dos itens de conteúdo que fazem referência ao esquema normalizado.
• Os campos recomendados devem ser normalizados se disponíveis. No entanto, eles podem não estar disponíveis em todas as fontes. Qualquer item de conteúdo que faz referência a esse esquema normalizado deve levar em conta a disponibilidade.
• Os campos opcionais , se disponíveis, podem ser normalizados ou deixados no formulário original. Normalmente, analisadores mínimos não normalizam esses campos por motivos de desempenho.
• Os campos condicionais serão obrigatórios se o campo a seguir for preenchido. Os campos condicionais normalmente são usados para descrever o valor em outro campo. Por exemplo, o campo comum DvcIdType descreve o valor int do campo comum DvcId e, portanto, será obrigatório se o último for preenchido.
• Alias é um tipo especial de campo condicional e é obrigatório se o campo associado for preenchido.

Campos comuns

Alguns campos são comuns a todos os esquemas do ASIM. Cada esquema pode adicionar diretrizes para usar alguns dos campos comuns no contexto do esquema específico. Por exemplo, os valores permitidos do campo EventType podem variar por esquema, assim como o valor do campo EventSchemaVersion.

Entidades

Eventos evoluem em relação a entidades, como usuários, hosts, processos e arquivos. Cada entidade pode exigir vários campos para descrevê-la. Por exemplo, um host pode ter nome e endereço IP.

Um único registro pode incluir várias entidades do mesmo tipo, como host de origem e host de destino.

O ASIM define como descrever as entidades de forma consistente e as entidades possibilitam estender os esquemas.

Por exemplo, embora o esquema de Sessão de Rede não inclua informações de processo, algumas origens de eventos fornecem informações de processo que podem ser adicionadas. Para obter mais informações, confira Entidades.

Aliases

Os aliases permitem vários nomes para um valor especificado. Em alguns casos, usuários diferentes esperam que os campos tenham nomes diferentes. Por exemplo, na terminologia do DNS, pode-se esperar um campo chamado DnsQuery, enquanto, de maneira mais geral, ele teria um nome de domínio. O Domínio do alias ajuda o usuário permitindo o uso dos dois nomes.

Em alguns casos, um alias pode ter o valor de um dos vários campos, dependendo de quais valores estão disponíveis no evento. Por exemplo, o alias Dvc, abrange os campos DvcFQDN, DvcId, DvcHostname ou DvcIpAddr ou Produto de Evento. Quando um alias pode ter vários valores, seu tipo precisa ser de cadeia de caracteres, a fim de acomodar todos os valores de alias possíveis. Como resultado, ao atribuir um valor a esse alias, converta o tipo em cadeia de caracteres usando a função KQL tostring.

As tabelas normalizadas nativas não incluem aliases, pois isso implicaria um armazenamento de dados duplicado. Em vez disso, os analisadores de stub adicionam os aliases. Para implementar aliases em analisadores, crie uma cópia do valor original usando o operador extend. |

Tipos lógicos

Cada campo de esquema tem um tipo. Alguns têm tipos do Log Analytics integrados, como string, int, datetime ou dynamic. Outros campos têm um tipo Lógico, que representa como os valores de campo devem ser normalizados.

Entidades

Eventos evoluem em relação a entidades, como usuários, hosts, processos e arquivos. A representação de entidade permite que várias entidades do mesmo tipo façam parte de um único registro e dão suporte a vários atributos para as mesmas entidades.

Para habilitar a funcionalidade de entidade, a representação de entidade tem as seguintes diretrizes:

Para obter mais informações sobre tipos de entidade específicos, consulte:

• Entidade de Usuário
• Entidade do dispositivo

Mapeamento de entidade de exemplo

Esta seção usa o evento 4624 do Windows como exemplo para descrever como os dados do evento são normalizados no Microsoft Sentinel.

Esse evento tem as seguintes entidades:

Com base nessas entidades, o evento 4624 do Windows é normalizado da seguinte forma (alguns campos são opcionais):

Próximas etapas

Este artigo fornece uma visão geral da normalização no Microsoft Sentinel e no ASIM.

Para obter mais informações, consulte:

• Assista também ao Webinar de aprofundamento no Microsoft Sentinel: normalizando analisadores e conteúdo normalizado ou veja os slides
• Visão geral do ASIM (Modelo de Informações de Segurança Avançado)
• Analisadores do ASIM (Modelo de Informações de Segurança Avançado)
• Conteúdo do ASIM (Modelo de Informações de Segurança Avançado)