Compartilhar via


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:

Captura de tela mostrando a janela Assistente de Regra de Análise – Criar regra.

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:

Diagrama mostrando uma janela retrospectiva de cinco minutos.

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:

Diagrama mostrando janelas de retorno de cinco minutos com um 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:

    Captura de tela que mostra a configuração da janela de pesquisa como sete minutos.

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

    Diagrama mostrando janelas de retorno de sete minutos com um atraso de dois minutos.

  • 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:

    Diagrama mostrando como as janelas retrospectivas sobrepostas criam duplicação.

    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:

    Diagrama mostrando como definir a restrição

    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:

    Diagrama mostrando como definir a restrição

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:

Captura de tela do Relatório de Uso do Workspace mostrando a latência de ponta a ponta por tabela

Próximas etapas

Para obter mais informações, consulte: