Esquemas ASIM (Advanced Security Information Model)

Um esquema ASIM (Advanced Security Information Model) é um conjunto de campos que representam uma atividade. Usar os campos de um esquema normalizado em uma consulta garante que a consulta funcione com todas as fontes normalizadas.

Para entender como os esquemas se encaixam na arquitetura ASIM, consulte o diagrama de arquitetura 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 do esquema e a estender o esquema de maneira normalizada caso seus dados incluam informações que o esquema não cobre.

Nomenclatura de campos

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

• Campos comuns a todos os esquemas.
• Campos específicos de um esquema.
• Campos que representam entidades, como utilizadores, que participam no esquema. Os 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. Se os campos extras representarem uma entidade, eles serão normalizados com base nas diretrizes do campo da entidade. Caso contrário, os esquemas se esforçam para manter a consistência em todos os esquemas.

Por exemplo, enquanto os logs de atividade do servidor DNS não fornecem 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 espaço de trabalho do Log Analytics tem um conjunto limitado de tipos de dados. Por esse motivo, o Microsoft Sentinel usa um tipo lógico para muitos campos de esquema, que o Log Analytics não impõe, mas é necessário para compatibilidade de esquema. Os tipos de campo lógico garantem que os valores e os nomes de campo sejam consistentes entre as fontes.

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

Classes de campo

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

• Campos obrigatórios devem aparecer em todos os analisadores. Se sua fonte não fornecer informações para esse valor, ou se os dados não puderem ser adicionados de outra forma, ela não suportará 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 faça referência a esse esquema normalizado deve levar em conta a disponibilidade.
• Campos opcionais , se disponíveis, podem ser normalizados ou mantidos na sua forma original. Normalmente, um analisador mínimo não os normalizaria por motivos de desempenho.
• Os campos condicionais são obrigatórios se o campo que seguem estiver preenchido. Os campos condicionais são normalmente usados para descrever o valor em outro campo. Por exemplo, o campo comum DvcIdType descreve o valor int do campo comum DvcId e, portanto, é obrigatório se este último for preenchido.
• Alias é um tipo especial de campo condicional e é obrigatório se o campo aliasado estiver preenchido.

Campos comuns

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

Entities

Os eventos evoluem em torno de entidades, como usuários, hosts, processos ou arquivos. Cada entidade pode necessitar de vários campos para a descrever. Por exemplo, um host pode ter um nome e um endereço IP.

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

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

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

Aliases

Os aliases permitem vários nomes para um valor especificado. Em alguns casos, usuários diferentes esperam que um campo tenha nomes diferentes. Por exemplo, na terminologia DNS, você pode esperar um campo chamado DnsQuery, enquanto mais geralmente, ele contém um nome de domínio. O alias Domain ajuda o usuário, permitindo o uso de ambos os 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 faz alias para os campos DvcFQDN, DvcId, DvcHostname, ou DvcIpAddr, ou Produto de Evento. Quando um alias pode ter vários valores, seu tipo deve ser uma cadeia de caracteres para acomodar todos os possíveis valores com alias. Como resultado, ao atribuir um valor a esse alias, certifique-se de converter o tipo em string usando a função KQL tostring.

As tabelas normalizadas nativas não incluem aliases, pois isso implicaria 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 extend operador . |

Tipos lógicos

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

Entities

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

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

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

• Entidade de Utilizador
• Entidade do Dispositivo

Exemplo de mapeamento de entidade

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

Este evento conta com as seguintes entidades:

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

Próximos passos

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

Para obter mais informações, consulte:

• Assista ao webinar Deep Dive sobre a normalização de analisadores e conteúdo normalizado do Microsoft Sentinel ou revise os slides
• Visão geral do ASIM (Advanced Security Information Model, modelo avançado de informações de segurança)
• Analisadores ASIM (Advanced Security Information Model)
• Conteúdo do modelo avançado de informações de segurança (ASIM)