Normalização em tempo de ingestão
Análise em tempo de consulta
Conforme a discussão na Visão geral do ASIM, o Microsoft Sentinel usa normalização em tempo de consulta e em tempo de ingestão para aproveitar os benefícios de cada um.
Para usar a normalização em tempo de consulta, use analisadores de unificação em tempo de consulta, como _Im_Dns, em suas consultas. A normalização usando a análise em tempo de consulta tem várias vantagens:
- Preservar o formato original: a normalização em tempo de consulta não exige que os dados sejam modificados, preservando assim o formato de dados original enviado pela origem.
- Evitar o potencial armazenamento duplicado: como os dados normalizados são apenas uma exibição dos dados originais, não há necessidade de armazenar dados originais e normalizados.
- Desenvolvimento mais fácil: como os analisadores em tempo de consulta apresentam uma exibição dos dados e não os modificam, eles são fáceis de desenvolver. O desenvolvimento, o teste e a correção de um analisador podem ser feitos em dados existentes. Além disso, os analisadores podem ser corrigidos quando um problema é descoberto e a correção se aplicará aos dados existentes.
Análise em tempo de ingestão
Enquanto os analisadores em tempo de consulta do ASIM são otimizados, a análise em tempo de consulta pode diminuir a velocidade das consultas, especialmente em conjuntos de dados grandes.
A análise de tempo de ingestão permite transformar eventos em um esquema normalizado conforme eles são ingeridos no Microsoft Sentinel, bem como armazená-los em um formato normalizado. A análise em tempo de ingestão é menos flexível e os analisadores são mais difíceis de desenvolver, mas como os dados são armazenados em um formato normalizado, ela oferece melhor desempenho.
Os dados normalizados podem ser armazenados nas tabelas normalizadas nativas do Microsoft Sentinel ou em uma tabela personalizada que usa um esquema ASIM. Uma tabela personalizada que tem um esquema próximo, mas não idêntico, a um esquema ASIM também fornece os benefícios de desempenho da normalização em tempo de ingestão.
Atualmente, o ASIM dá suporte às seguintes tabelas normalizadas nativas como um destino para a normalização em tempo de ingestão:
- ASimAuditEventLogs para o esquema de Evento de Auditoria.
- ASimAuthenticationEventLogs para o esquema de Autenticação.
- ASimDnsActivityLogs para o esquema DNS.
- ASimNetworkSessionLogs para o esquema de Sessão de rede
- ASimWebSessionLogs para o esquema de Sessão na Web.
A vantagem das tabelas normalizadas nativas é que elas são incluídas por padrão nos analisadores unificadores do ASIM. Tabelas normalizadas personalizadas podem ser incluídas nos analisadores unificadores, conforme discutido em Gerenciar Analisadores.
Combinando a normalização em tempo de ingestão e em tempo de consulta
As consultas sempre devem usar analisadores unificadores em tempo de consulta, como _Im_Dns, para aproveitar a normalização em tempo de consulta e em tempo de ingestão. Tabelas normalizadas nativas são incluídas nos dados consultados usando um analisador stub.
O analisador stub é um analisador em tempo de consulta que usa como entrada a tabela normalizada. Como a tabela normalizada não requer análise, o analisador stub é eficiente.
O analisador stub apresenta uma exibição para a consulta de chamada que adiciona à tabela nativa do ASIM:
- Aliases – para não desperdiçar armazenamento com valores repetidos, os aliases não são armazenados em tabelas nativas do ASIM e são adicionados em tempo de consulta pelos analisadores stub.
- Valores constantes – como aliases e, pelo mesmo motivo, as tabelas normalizadas do ASIM também não armazenam valores constantes, como EventSchema. O analisador stub adiciona esses campos. A tabela normalizada do ASIM é compartilhada por muitas fontes e os analisadores em tempo de ingestão podem alterar sua versão de saída. Portanto, campos como EventProduct, EventVendor e EventSchemaVersion não são constantes e não são adicionados pelo analisador stub.
- Filtragem – o analisador stub também implementa a filtragem. Embora as tabelas nativas do ASIM não precisem de analisadores de filtragem para obter um melhor desempenho, a filtragem é necessária para dar suporte à inclusão no analisador unificador.
- Atualizações e correções – o uso de um analisador stub permite corrigir problemas mais rapidamente. Por exemplo, se os dados foram ingeridos incorretamente, um endereço IP pode não ter sido extraído do campo de mensagem durante a ingestão. O endereço IP pode ser extraído pelo analisador stub em tempo de consulta.
Ao usar tabelas normalizadas personalizadas, crie seu analisador stub para implementar essa funcionalidade e adicione-a aos analisadores unificadores, conforme discutido em Gerenciar Analisadores. Use o analisador stub para a tabela nativa, como o Analisador stub de tabela nativa DNS e seu equivalente de filtragem, como ponto de partida. Se a tabela for seminormalizada, use o analisador stub para executar a análise e a normalização adicionais necessárias.
Saiba mais sobre como escrever analisadores em Desenvolvimento de analisadores do ASIM.
Implementando a normalização em tempo de ingestão
Para normalizar dados na ingestão, você precisará usar uma DCR (Regra de Coleta de Dados). O procedimento para implementar a DCR depende do método usado para ingerir os dados. Para obter mais informações, consulte o artigo Transformar ou personalizar dados em tempo de ingestão no Microsoft Sentinel.
Uma consulta de transformação KQL é o núcleo de uma DCR. A versão KQL usada nas DCRs é ligeiramente diferente da versão usada em outro lugar no Microsoft Sentinel para acomodar os requisitos de processamento de eventos do pipeline. Portanto, você precisará modificar qualquer analisador em tempo de consulta para usá-lo em uma DCR. Para obter mais informações sobre as diferenças e saber como converter um analisador em tempo de consulta em um analisador em tempo de ingestão, leia sobre as limitações de KQL da DCR.
Próximas etapas
Para obter mais informações, consulte: