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

Embora o Microsoft Sentinel possa ingerir dados de várias origens, o tempo de ingestão de cada origem de dados pode ser diferente em circunstâncias diferentes.

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 a consulta Executar todos os e Procurar dados dos últimos campos 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 referência . Idealmente, quando não há atraso, esta deteção não falha eventos, conforme mostrado no diagrama seguinte:

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

Agora, suponha que existe algum atraso na sua origem de dados. Para este 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 pesquisa, mas não é ingerido na sua área 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

Nota

Pode resolver o problema com o processo descrito abaixo ou implementar as regras de deteção quase em tempo real (NRT) do Microsoft Sentinel. Para obter mais informações, veja Detetar ameaças rapidamente com regras de análise quase em tempo real (NRT) no Microsoft Sentinel.

Para resolver o problema, precisa de saber o atraso do seu tipo de dados. Neste exemplo, já sabe que o atraso é de dois minutos.

Para os seus próprios dados, pode compreender o atraso com a função Kusto ingestion_time() e calcular a diferença entre TimeGenerated e o tempo 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:

• Aumente o período de retrospetivo. A intuição básica diz-lhe que aumentar o tamanho do período de pesquisa irá ajudar. 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 look-pack contém agora o evento perdido:

  

• Processar a duplicação. Apenas aumentar o período de pesquisa pode criar duplicação, porque as janelas de pesquisa agora se sobrepõem. Por exemplo, um evento diferente pode ter o aspeto apresentado no seguinte diagrama:

  

  Uma vez que o valor TimeGenerated do evento é encontrado em ambos os períodos de pesquisa, o evento aciona dois alertas. Tem de encontrar uma forma de resolver a duplicação.

• Associe o evento a um período de pesquisa específico. No primeiro exemplo, falhou eventos porque os seus dados não foram ingeridos quando a consulta agendada foi executada. Alargou o look-back para incluir o evento, mas isto causou duplicação. Tem de associar o evento à janela que estendeu para o conter.

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

  

  A restrição de tempo de ingestão reduz agora os dois minutos adicionais que adicionou ao período de retroscrição. E, para o primeiro exemplo, o segundo período de pesquisa de execução captura agora 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)

Calcular o atraso na ingestão

Por predefinição, as regras de alerta agendadas do Microsoft Sentinel estão configuradas para ter um período de retrospetivo período de 5 minutos. No entanto, cada origem de dados pode ter o seu próprio atraso de ingestão individual. Ao associar vários tipos de dados, tem de compreender os diferentes atrasos para cada tipo de dados para configurar o período de pesquisa corretamente.

O Relatório de Utilização da Área de Trabalho, fornecido no Microsoft Sentinel, 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:

Passos seguintes

Para obter mais informações, consulte:

• Criar regras de análise personalizadas para detetar ameaças
• Personalizar detalhes do alerta no Azure Sentinel
• Gerir versões de modelos para as regras de análise agendadas no Azure Sentinel
• Utilizar o livro de monitorização do estado de funcionamento
• Log data ingestion time in Azure Monitor (Tempo de ingestão de dados de registo no Azure Monitor)