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

Embora o Microsoft Sentinel possa ingerir dados de fontes conectadas, o tempo de ingestão para cada fonte de dados pode variar em diferentes 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, você pode escrever uma regra de detecção personalizada, definindo os campos Executar consulta a cada e Consultar dados dos últimos para que a regra seja executada a cada cinco minutos, consultando os dados desses últimos cinco minutos:

O campo Pesquisar dados dos últimos define uma configuração conhecida como um período retrospectivo. 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 retrospectivo.

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 dentro do primeiro período de retrocesso, mas não é ingerido em seu workspace do Microsoft Sentinel na primeira vez. 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

Use a abordagem a seguir para levar em conta o atraso de ingestão nas regras de análise agendadas.

Para resolver o problema, você precisa saber a latência do seu tipo de dados. Neste exemplo, 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, veja Calcular o atraso na ingestão.

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

• Aumente o período de retorno: A intuição básica diz que aumentar o tamanho do período de retorno 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 a seguir mostra como o período retrospectivo agora contém o evento perdido:

  

• * Lidar com duplicação: Somente aumentar o período retrospectivo pode criar duplicação, porque as janelas retrospectivas 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 retorno, o evento dispara dois alertas. Tem de encontrar uma forma de resolver a duplicação.

• Associe o evento a um período de retorno específico: No primeiro exemplo, você perdeu eventos porque seus dados não foram ingeridos quando a consulta agendada foi executada. 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-o ao definir ingestion_time() > ago(5m), em vez da regra look-back = 5moriginal . Esta configuração associa o evento à primeira janela de retrospectiva. Por exemplo:

  

  A restrição do tempo de ingestão agora remove os dois minutos extras que você adicionou ao período de retrospectiva. 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)

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

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

Calcular o atraso da ingestão

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

O Relatório de Uso do Workspace, disponibilizado por padrão no Microsoft Sentinel, inclui um painel que mostra a latência e os atrasos dos diferentes tipos de dados que fluem para o workspace.

Por exemplo:

Conteúdo relacionado

• Crie uma regra de análise agendada do zero
• Personalizar detalhes do alerta no Microsoft Sentinel
• Gerencie versões de modelo para 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