Lidar com o atraso da ingestão nas regras de análise agendada

Embora o Microsoft Sentinel possa ingerir dados de fontes de dados conectadas, o tempo de ingestão para cada fonte de dados pode variar consoante as circunstâncias.

Este artigo descreve como o atraso na ingestão pode afetar as regras de análise agendada e como pode corrigi-las para cobrir estas lacunas.

Por que motivo o atraso é significativo

Por exemplo, pode escrever uma regra de deteção personalizada, definindo os campos Executar consulta a cada e Procurar dados dos últimos para que a regra seja executada a cada cinco minutos, procurando dados desses últimos cinco minutos:

Os dados de Pesquisa do último campo definem uma definição conhecida como um período de pesquisa . Idealmente, quando não há atraso, esta deteção não perde eventos, conforme mostrado no diagrama seguinte:

O evento chega à medida que é gerado e é incluído no período de pesquisa .

Agora, suponha que há algum atraso na sua origem de dados. Neste exemplo, digamos que o evento foi ingerido dois minutos depois de ter sido gerado. O atraso é de dois minutos:

O evento é gerado no primeiro período de retrospetiva, mas não é importado para o espaço de trabalho do Microsoft Sentinel na primeira execução. Da próxima vez que a consulta agendada for executada, ingere o evento, mas o filtro gerado pelo tempo remove o evento porque ocorreu há mais de cinco minutos. Neste caso, a regra não aciona um alerta.

Como lidar com atrasos

Utilize a seguinte abordagem para ter em conta o atraso na ingestão nas regras de análise agendadas.

Para resolver o problema, precisa de conhecer a latência relativa ao seu tipo de dados. Neste exemplo, já sabe que o atraso é de dois minutos.

Para os seus próprios dados, pode determinar o atraso utilizando a função Kusto ingestion_time() e calculando a diferença entre TimeGenerated e a hora de ingestão. Para obter mais informações, veja Calcular o atraso na ingestão.

Depois de determinar o atraso, pode resolver o problema da seguinte forma:

• Aumentar o período de retrovisão: A intuição básica diz-lhe que aumentar o tamanho do período de retrocesso ajuda. Uma vez que o período de retroscrição é de cinco minutos e o atraso é de dois minutos, definir o período de retroscrição para sete minutos ajudará a resolver este problema. Por exemplo, nas definições da regra:

  

  O diagrama seguinte mostra como o período de retrospetiva inclui agora o evento em falta:

  

• * Lidar com duplicação: O simples aumento do período retrospetivo pode criar duplicação, porque as janelas retrospetivas agora se sobrepõem. Por exemplo, um evento diferente pode ter o aspeto mostrado no diagrama seguinte:

  

  Como o valor TimeGenerated do evento é encontrado em ambos os períodos de retrospeção, o evento dispara dois alertas. Tem de encontrar uma forma de resolver a duplicação.

• Associe o evento a um período de retrospetiva específico: No primeiro exemplo, perdeu eventos porque os seus dados não foram ingeridos quando a consulta agendada foi executada. Alargou o período retrospetivo para incluir o evento, mas isso provocou duplicação. Tem de associar o evento à janela que alargou para o incluir.

  Faça-o ao definir ingestion_time() > ago(5m), em vez da regra look-back = 5moriginal . Esta configuração associa o evento à primeira janela retrospetiva. Por exemplo:

  

  A restrição do tempo de ingestão remove agora os dois minutos extra que adicionou ao período retrospetivo. E, para o primeiro exemplo, o período retrospetivo da segunda execução passa agora a captar o evento:

  

A seguinte consulta de exemplo resume a solução para resolver problemas de atraso de ingestão:

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Veja mais informações sobre os seguintes itens usados no exemplo anterior na documentação Kusto:

• instrução let
• where operador
• função ago()

Calcular o atraso da ingestão

Por defeito, as regras de alerta agendado do Microsoft Sentinel estão configuradas para ter um período de análise de cinco minutos. No entanto, cada fonte de dados pode ter o seu próprio atraso individual na ingestão. Ao combinar vários tipos de dados, tem de compreender os diferentes atrasos de cada tipo de dados para configurar corretamente o período retrospetivo.

O Relatório de Utilização da Área de Trabalho, fornecido no Microsoft Sentinel inicial, inclui um dashboard que mostra latência e atrasos para os diferentes tipos de dados que fluem para a sua área de trabalho.

Por exemplo:

Conteúdo relacionado

• Crie uma regra de análise agendada do zero
• Personalizar detalhes do alerta no Microsoft Sentinel
• Gerir versões de modelos para as suas regras de análise agendadas no Microsoft Sentinel
• Monitorizar o estado de funcionamento dos conectores de dados
• Tempo de ingestão de dados de registo no Monitor do Azure