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

Importante

As deteções personalizadas são agora a melhor forma de criar novas regras no Microsoft Sentinel Microsoft Defender XDR SIEM. Com as deteções personalizadas, pode reduzir os custos de ingestão, obter deteções ilimitadas em tempo real e beneficiar da integração totalmente integrada com Defender XDR dados, funções e ações de remediação com o mapeamento automático de entidades. Para obter mais informações, leia este blogue.

Embora Microsoft Sentinel possam 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 osdados e Procurar 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 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 pesquisa, mas não é ingerido na área de trabalho 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 olhar para trás 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 do look-pack contém agora o evento perdido:

  

• Processar 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 mostrado no diagrama seguinte:

  

  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, perdeu eventos porque os seus dados não foram ingeridos quando a consulta agendada foi executada. Expandiu o look-back para incluir o evento, mas isto causou duplicação. Tem de associar o evento à janela que expandiu 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 retroscrição. Por exemplo:

  

  A restrição de tempo de ingestão reduz agora os dois minutos adicionais que adicionou ao período de pesquisa. 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)

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

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

Calcular o atraso da ingestão

Por predefinição, Microsoft Sentinel regras de alerta agendadas estão configuradas para ter um período de pesquisa 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 corretamente o período de pesquisa.

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:

Passos seguintes

Para 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
• Tempo de ingestão de dados de registo no Monitor do Azure