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

Embora o Microsoft Sentinel possa ingerir dados de várias fontes, o tempo de ingestão para cada fonte de dados pode ser diferente 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 o atraso é significativo

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

O campo Pesquisar dados dos últimos define uma configuração conhecida como um período retrospectivo. O ideal é que, quando não houver atraso, essa detecção não perca nenhum evento, conforme mostrado no diagrama a seguir:

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

Agora, suponha que haja algum atraso para sua fonte de dados. Para este exemplo, digamos que o evento foi ingerido dois minutos depois que ele foi gerado. O atraso é de dois minutos:

O evento é gerado dentro do primeiro período de retrocesso, mas não é ingerido em seu workspace do Microsoft Sentinel na primeira vez. Na próxima vez que a consulta agendada é executada, ela ingere o evento, mas o filtro gerado pelo tempo remove o evento porque ele ocorreu há mais de cinco minutos. Nesse caso, a regra não dispara um alerta.

Como lidar com atraso

Observação

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

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

Para seus próprios dados, você pode entender o atraso usando a ingestion_time()função Kusto e calcular a diferença entre 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 forma:

• Aumente o período retrospectivo. Intuição básica mostra que aumentar o tamanho do período retrospectivo ajudará. Como o período retrospectivo é de cinco minutos e o atraso é de dois minutos, definir o período retrospectivo como sete minutos ajudará a resolver esse problema. Por exemplo, em suas configurações de regra:

  

  O diagrama a seguir mostra como o período retrospectivo agora contém o evento perdido:

  

• Manipular duplicação. Apenas aumentar o período de retorno pode criar duplicação, pois as janelas retrospectivas agora se sobrepõem. Por exemplo, um evento diferente pode parecer como mostrado no diagrama a seguir:

  

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

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

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

  

  A restrição de tempo de ingestão agora corta os dois minutos extras que você adicionou ao período retrospectivo. E, para o primeiro exemplo, o segundo período retrospectivo de execução agora captura 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 atraso de ingestão

Por padrão, as regras de alerta agendadas do Microsoft Sentinel são configuradas para ter um período retrospectivo de 5 minutos. No entanto, cada fonte de dados pode ter 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 retrospectivo corretamente.

O Relatório de Uso do Workspace, fornecido no Microsoft Sentinel, inclui um painel que mostra latência e atrasos para os diferentes tipos de dados que fluem para seu workspace.

Por exemplo:

Próximas etapas

Para obter mais informações, consulte:

• Criar regras de análise personalizadas para detectar ameaças
• Personalizar detalhes do 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
• Registrar o tempo de ingestão de dados no Azure Monitor