Entender os atrasos na detecção de regras

Compatível com:

Este documento explica os atrasos na detecção de regras no Google Security Operations, identifica os fatores contribuintes nos pipelines de ingestão e processamento, descreve abordagens estruturadas de solução de problemas e fornece técnicas para reduzir a latência de detecção.

Visão geral das regras de detecção

As regras de detecção examinam registros brutos normalizados (eventos regulares e do Universal Data Model, UDM, de entidades) para gerar detecções de segurança de acordo com as especificações da regra. Os eventos do UDM de entidades geralmente contêm informações de contexto como metadados de usuários ou recursos. As regras de detecção também podem avaliar detecções geradas anteriormente para produzir alertas compostos.

Atrasos esperados e não previstos

A latência de detecção varia com base na lógica da regra, nas dependências de dados e nos ciclos de processamento do sistema. Os atrasos são categorizados em dois tipos:

  • Atrasos esperados: atrasos resultantes de fatores estruturais, como o processo de ingestão, o tipo de regra, a frequência de execução, o método de geração de detecção, a duração da janela de correspondência e os limites conhecidos do sistema. É possível minimizar os atrasos esperados ajustando as configurações das regras de detecção e os parâmetros de programação.
  • Atrasos não previstos: atrasos causados por condições externas ou dinâmicas do pipeline, incluindo gargalos na entrega de registros de fontes de dados, latência de processamento transitória nos serviços do Google SecOps, disponibilidade de contexto atrasada e ciclos de reenriquecimento do UDM.

Métodos de geração de detecção

O Google SecOps gera detecções de regras nos seguintes pipelines de execução:

  • Mecanismo de streaming: um pipeline de alta velocidade que avalia regras de evento único padrão e em janela continuamente quase em tempo real (normalmente em até 5 minutos após a ingestão). Eventos atrasados e enriquecimentos retroativos são avaliados continuamente durante a execução padrão.
  • Mecanismo de consulta: avalia regras que exigem correlação de eventos com base no tempo em vários eventos ou junções de dados externos:
    • Regras complexas de evento único: incluem regras de evento único que consultam listas de referência ou tabelas de dados.
    • Regras de vários eventos: consultam dados em blocos de tempo de evento em lote (como intervalos de 10 minutos ou 1 hora ou match_window / 10 para janelas maiores que 48 horas) com base em programações configuradas.
  • Regras executadas com base em dados históricos: avaliam regras retroativamente em relação a registros históricos por meio de retrocaças. As detecções aparecem após a conclusão da verificação histórica.
  • Reenriquecimento de eventos do UDM: reavalia blocos de tempo processados anteriormente quando um novo contexto ou dados de entidade atualizados são adicionados a eventos históricos.

Fatores que contribuem para atrasos na detecção de regras

A velocidade com que as detecções aparecem depende da complexidade da regra, dos intervalos de programação, da latência de ingestão de dados e dos pipelines de enriquecimento de contexto.

Tipos e complexidade de regras

As regras de detecção se enquadram em várias categorias com perfis de latência diferentes:

Regras de evento único

As regras de evento único são executadas quase em tempo real no mecanismo de streaming contínuo e oferecem a menor latência de detecção. Essas regras avaliam eventos individuais sem unir conjuntos de dados externos, tabelas de dados ou janelas de correspondência de vários eventos.

Regras complexas de evento único

Essas regras avaliam eventos únicos, mas incorporam dependências de dados adicionais:

  • Regras de evento único em janela: regras de evento único que incluem uma seção match (por exemplo, avaliar se um único evento corresponde a uma condição em uma janela de tempo). Essas regras são avaliadas quase em tempo real no mecanismo de streaming contínuo à medida que os dados são ingeridos.
  • Regras de evento único de referência: regras de evento único que comparam atributos de eventos com listas de referência ou tabelas de dados.

Regras de vários eventos

As regras de vários eventos correlacionam duas ou mais condições de eventos do UDM em uma janela de correspondência especificada e são executadas em intervalos de lote programados.

  • Regras padrão de vários eventos: agregam vários eventos em janelas de tempo e são executadas em intervalos de 10 minutos ou 1 hora (ou match_window / 10 para janelas maiores que 48 horas).
  • Regras baseadas no contexto: correlacionam dados de eventos com eventos de entidades do UDM (como user_context ou asset_context) usando análises baseadas no contexto. Como as regras baseadas no contexto dependem de vários feeds de dados, elas são mais sensíveis ao tempo de ingestão. Para mais informações, consulte Usar dados enriquecidos com contexto em regras.

Frequência de execução de regras

A frequência de execução configurada determina com que frequência o mecanismo de consulta avalia os blocos de tempo de evento:

  • Quase em tempo real: avaliação contínua para regras de evento único (padrão e em janela).
  • Frequência de 10 minutos: disponível para regras de vários eventos com janelas de correspondência com menos de 60 minutos.
  • Frequência de 1 hora: intervalo padrão para regras de vários eventos com janelas de correspondência de 48 horas ou menos.
  • Frequência match_window / 10: atribuída automaticamente para regras de vários eventos com janelas de correspondência maiores que 48 horas (por exemplo, executadas a cada 10 horas para uma janela de correspondência de 100 horas ou a cada 24 horas para uma janela de 10 dias).

Duração da janela de correspondência

Para regras de vários eventos, a duração da janela de correspondência define o período de observação necessário para agregar eventos. As detecções não podem aparecer até que a janela de tempo completa tenha decorrido.

Atraso na ingestão de registros

O atraso na ingestão é o tempo decorrido entre o momento em que um evento ocorre na origem e o momento em que o Google SecOps recebe e analisa o registro.

Se um evento chegar após a avaliação programada inicial para esse bloco de tempo, ele perderá a primeira execução. O sistema captura dados atrasados em execuções automatizadas subsequentes em segundo plano (execuções de correção), que ocorrem aproximadamente 4 horas (e, opcionalmente, 30 horas com a integridade do enriquecimento) após a execução principal.

  • Exemplo: uma regra correlaciona o evento A (horário do evento:9h03) e o evento B (horário do evento:9h05) em uma janela de 30 minutos. Se o evento A chegar às 10h05 (uma hora de atraso), ele perderá a execução inicial do bloco das 9h às 9h30. O sistema reavalia o bloco durante uma execução de correção subsequente, aproximadamente 4 horas após a execução principal (por volta das 14h), gerando a detecção aproximadamente 5 horas após a ocorrência do evento.

Discrepâncias de fuso horário

O Google SecOps interpreta os carimbos de data/hora de registro como UTC por padrão. Se uma fonte de registro omitir uma diferença de fuso horário explícita, o sistema tratará o carimbo de data/hora como UTC, o que pode fazer com que o registro apareça atrasado, mesmo que seja recebido imediatamente.

  • Exemplo: um evento ocorre às 10h (horário do leste dos EUA, 15h UTC) e chega ao Google SecOps às 15h05 UTC sem metadados de fuso horário. O sistema interpreta o carimbo de data/hora como 10h UTC, criando um atraso de ingestão de 5 horas que adia a avaliação da regra para uma execução de correção em segundo plano.

Soluções alternativas: para resolver discrepâncias de fuso horário:

  • Configure a origem do registro para incluir diferenças de fuso horário UTC explícitas nos carimbos de data/hora de eventos.
  • Entre em contato com o suporte para definir uma substituição de fuso horário para o feed de ingestão específico.
  • Use um processador do BindPlane para normalizar os carimbos de data/hora do corpo do registro para UTC antes da ingestão. Para mais informações, consulte Como modificar carimbos de data/hora do corpo do registro usando o BindPlane.

Junções contextuais e aprimoramento de dados

O Google SecOps enriquece eventos do UDM adicionando metadados de identidade, recursos e ameaças de fontes secundárias. Atrasos na disponibilidade de contexto podem estender o tempo de detecção.

Mecanismos de alias e enriquecimento

O alias e o enriquecimento correlacionam indicadores brutos com o contexto organizacional:

  • Alias: identifica e vincula diferentes identificadores para a mesma entidade em fontes de dados (como mapear um endereço IP de registros DHCP para um endereço MAC e nome do host como alex-macbook, ou mapear um ID de usuário para um cargo de funcionário).
  • Enriquecimento: preenche campos de eventos do UDM normalizados com o contexto de alias (como preencher $udm.event.principal.hostname quando apenas um endereço IP está presente no evento bruto).

Os tipos de enriquecimento compatíveis incluem recursos, usuários, processos, metadados de hash de arquivos, locais geográficos e recursos de nuvem. Para mais informações, consulte Visão geral do enriquecimento e alias do UDM.

Reenriquecimento de eventos do UDM

O sistema atualiza continuamente eventos históricos à medida que as fontes de contexto evoluem:

  • Mudanças nos dados subjacentes: os eventos históricos podem ser atualizados por até 24 horas após a ingestão, à medida que novos dados de contexto chegam.
  • Atualizações do sistema de enriquecimento: quando os metadados da entidade, a geolocalização de IP ou as atualizações de inteligência contra ameaças do VirusTotal, o mecanismo de regras reavalia blocos históricos (normalmente durante execuções de correção programadas ou reprocessamento) para gerar detecções com contexto atualizado.
  • Dados de contexto atrasados: se os dados de contexto (como um nome do host) chegarem um dia após o registro de eventos, o sistema reenriquecerá o evento do UDM, e as execuções de correção subsequentes avaliarão o registro enriquecido.
  • Modificações de contexto: se uma atualização de enriquecimento mudar um atributo de evento (como atualizar uma geolocalização de IP de USA para Canada), as regras que correspondem ao valor atualizado acionam detecções durante as reavaliações subsequentes.

Processamento do gráfico de contexto de entidades (ECG, na sigla em inglês)

O gráfico de contexto de entidades (ECG) correlaciona indicadores de comprometimento (IOCs) e dados de gráfico de recursos corporativos. Como o pipeline do ECG depende do processamento em lote (que pode levar 30 horas ou até vários dias, dependendo do volume de dados), as regras que fazem referência a campos graph.entity geram detecções depois que as relações de gráfico são totalmente calculadas.

Execuções de regras históricas e retrocaças

A execução de uma regra com base em dados históricos gera detecções somente após a conclusão da verificação de retrocaça no período selecionado.

  • Fluxo de trabalho de enriquecimento retroativo:
    1. Um evento chega às 13h com ip_address = 10.0.0.5 (nome do host desconhecido).
    2. Às 14h30, um registro DHCP chega vinculando 10.0.0.5 a workstation-123.
    3. O pipeline de alias atualiza o evento histórico das 13h com principal.hostname = workstation-123.
    4. As repetições de regras subsequentes avaliam o nome do host enriquecido e as detecções de superfície que não foram acionadas durante a execução inicial.

Listas de referências

As regras que consultam listas de referência são avaliadas em relação à versão mais recente da lista no momento da execução. A atualização de uma lista de referência pode fazer com que as regras programadas produzam detecções retroativamente em relação aos registros ingeridos anteriormente.

Regras de não existência

Para evitar falsos positivos, o sistema introduz um buffer mínimo de uma hora antes de avaliar regras que verificam condições de não existência (como !$e ou #e=0), garantindo que todos os registros relacionados tenham tempo para chegar.

Limitações de processamento de dados e correção

Considere os seguintes comportamentos do sistema ao avaliar a latência de detecção:

  • Processamento de enriquecimento: o enriquecimento de contexto pode atualizar eventos históricos do UDM até 24 horas após a ingestão inicial.
  • Ciclos de correção: as regras de vários eventos são executadas automaticamente novamente aproximadamente 4 horas (e, opcionalmente, 30 horas) após a execução principal para capturar dados atrasados. Para mais informações, consulte Entender repetições de regras e MTTD.
  • Limites de detecção: para capacidade da plataforma e limites de limitação, consulte Entender os limites de detecção.

Resolver problemas de atrasos na detecção de regras

Para diagnosticar por que uma regra gerou uma detecção atrasada, examine as seguintes heurísticas e estágios de pipeline no console do Google SecOps:

  • Analisar metadados e programação de regras: no painel de regras, verifique as colunas Nome da regra, Tipo de regra e Programação de regras para identificar o mecanismo de execução da regra e a frequência de avaliação de linha de base.
  • Comparar o horário do evento com o horário ingerido: localize a detecção na guia Detecções e compare o carimbo de data/hora do evento com o carimbo de data/hora de ingestão. Se a diferença entre o horário do evento e o horário ingerido exceder 30 minutos, a latência foi causada por atrasos na entrega de registros na origem ou durante a coleta. As detecções geradas a partir de dados de eventos que chegam com mais de 30 minutos de atraso, execuções de correção automatizadas, pipelines de reprocessamento ou retrocaças mostram um ícone na coluna Tipo de detecção.
  • Analisar dependências de origem de contexto: verifique se a regra faz referência ao enriquecimento principal, ao alias do UDM ou aos campos graph.entity. Os pipelines de contexto são processados de forma assíncrona e podem mostrar detecções durante execuções de correção subsequentes.
  • Verificar a frequência e a compatibilidade da janela de correspondência: confirme se a frequência de execução configurada corresponde ao tamanho da janela de correspondência (por exemplo, garantindo que uma regra com uma janela de correspondência de 15 minutos seja programada para 10 minutos ou 1 hora).
  • Verificar interrupções no feed de dados: analise os registros de ingestão e os painéis de gerenciamento de feeds para atrasos na ingestão ou interrupções de origem temporárias.

Dicas para encurtar atrasos na detecção

Para minimizar os atrasos na detecção em todo o ambiente, aplique as seguintes técnicas de otimização:

  • Otimizar a frequência de execução de regras:
    • Use Quase em tempo real para regras de evento único (padrão e em janela).
    • Configure uma programação de 10 minutos para regras de vários eventos com janelas de correspondência com menos de 60 minutos.
    • Use 1 hora para regras com janelas de correspondência entre 1 e 48 horas em que alertas rápidos são necessários.
  • Ajustar as durações da janela de correspondência: defina janelas de correspondência para a duração mínima necessária para capturar o comportamento de ameaça correlacionado.
  • Eliminar gargalos na entrega de registros: garanta que os encaminhadores e coletores enviem dados de eventos imediatamente para evitar que os registros percam a janela de execução inicial.
  • Validar configurações de fuso horário: garanta que as fontes de registro forneçam diferenças de UTC explícitas para evitar atrasos de ingestão percebidos de mais de 5 horas.
  • Auditar condições de contexto e não existência: use campos enriquecidos com contexto e condições de não existência (!$e) somente quando exigido pela lógica de detecção, já que eles introduzem períodos de buffer intencionais.

A seguir

Para explorar conceitos de programação relacionados e fluxos de trabalho de configuração, consulte os seguintes documentos:

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.