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

Embora o Microsoft Sentinel possa ingerir dados de várias fontes, o tempo de ingestão para cada fonte de dados pode diferir em circunstâncias diferentes.

Este artigo descreve como o atraso na ingestão pode afetar suas regras de análise agendadas e como você pode corrigi-las para cobrir essas lacunas.

Por que razão o atraso é significativo

Por exemplo, você pode escrever uma regra de deteção personalizada, definindo a consulta Executar todos os dados e Pesquisa 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 configuração conhecida como período de retrospetiva . Idealmente, quando não há atraso, essa deteção não perde nenhum evento, como mostrado no diagrama a seguir:

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

Agora, suponha que haja algum atraso para sua fonte 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 retrospetiva, mas não é ingerido no espaço de trabalho do Microsoft Sentinel na primeira execução. Na próxima vez que a consulta agendada for executada, ela ingerirá o evento, mas o filtro gerado pelo tempo removerá o evento porque ele aconteceu há mais de cinco minutos. Neste caso, a regra não dispara um alerta.

Como lidar com o atraso

Nota

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

Para resolver o problema, você precisa saber o atraso para o seu tipo de dados. Para este exemplo, você já sabe que o atraso é de dois minutos.

Para seus próprios dados, você pode entender o atraso usando a função Kusto ingestion_time() e calculando a diferença entre o TimeGenerated e o tempo de ingestão. Para obter mais informações, consulte Calcular atraso de ingestão.

Depois de determinar o atraso, você pode resolver o problema da seguinte maneira:

• Aumente o período de retrospetiva. A intuição básica diz que aumentar o tamanho do período de retrospetiva ajudará. Como o período de retrospetiva é de cinco minutos e o atraso é de dois minutos, definir o período de retrospetiva para sete minutos ajudará a resolver esse problema. Por exemplo, nas configurações da regra:

  

  O diagrama a seguir mostra como o período do look-pack agora contém o evento perdido:

  

• Lidar com a duplicação. Apenas aumentar o período de retrospetiva pode criar duplicação, porque as janelas de retrospetiva agora se sobrepõem. Por exemplo, um evento diferente pode ter a aparência mostrada no diagrama a seguir:

  

  Como o valor TimeGenerated do evento é encontrado em ambos os períodos de retrospetiva, o evento dispara dois alertas. Você precisa encontrar uma maneira de resolver a duplicação.

• Associe o evento a um período de retrospetiva específico. No primeiro exemplo, você perdeu eventos porque seus dados não foram ingeridos quando a consulta agendada foi executada. Você estendeu o look-back para incluir o evento, mas isso causou duplicação. Você precisa associar o evento à janela estendida para contê-lo.

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

  

  A restrição de tempo de ingestão agora reduz os dois minutos extras que você adicionou ao período de retrospetiva. E para o primeiro exemplo, o segundo período de retrospetiva de execução agora captura o evento:

  

A consulta de exemplo a seguir 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 de ingestão

Por padrão, as regras de alerta agendado do Microsoft Sentinel são configuradas para ter um período de retrospetiva de 5 minutos. No entanto, cada fonte de dados pode ter o seu próprio atraso de ingestão individual. Ao unir vários tipos de dados, você deve entender os diferentes atrasos para cada tipo de dados para configurar o período de retrospetiva corretamente.

O Relatório de Uso do Espaço de Trabalho, fornecido no Microsoft Sentinel pronto para uso, inclui um painel que mostra a latência e os atrasos para os diferentes tipos de dados que fluem para o seu espaço de trabalho.

Por exemplo:

Próximos passos

Para obter mais informações, consulte:

• Criar regras de análise personalizadas para detetar ameaças
• Personalizar detalhes de alerta no Azure Sentinel
• Gerenciar versões de modelo para suas regras de análise agendadas no Azure Sentinel
• Usar a pasta de trabalho de monitoramento de integridade
• Log data ingestion time in Azure Monitor (Tempo de ingestão de dados de registo no Azure Monitor)