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 que contribuem para isso nos pipelines de ingestão e processamento, descreve abordagens estruturadas de solução de problemas e oferece 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 modelo de dados universal [UDM] de entidade) para gerar detecções de segurança de acordo com as especificações da regra. Os eventos UDM de entidade geralmente contêm informações de contexto, como metadados de usuário ou de recurso. As regras de detecção também podem avaliar detecções geradas anteriormente para produzir alertas compostos.

Atrasos previstos e não previstos

A latência de detecção varia de acordo com a lógica da regra, as dependências de dados e os 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 de 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 de entrega de registros de fontes de dados, latência de processamento temporária nos serviços do Google SecOps, disponibilidade de contexto atrasada e ciclos de re-enriquecimento da UDM.

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

O Google SecOps gera detecções de regras usando os 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 em tempo quase real (normalmente em até 5 minutos após a ingestão). Os eventos que chegam atrasados e os 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 agrupados de tempo de evento (como intervalos de 10 minutos ou 1 hora ou match_window / 10 para períodos maiores que 48 horas) com base em programações configuradas.
  • As regras são executadas em dados históricos: avalia as regras de forma retroativa em relação aos registros históricos usando retrocaças. As detecções aparecem depois que a verificação histórica é concluída.
  • Reenriquecimento de eventos da 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 diferentes perfis de latência:

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 outras dependências de dados:

  • Regras de evento único com janela: regras de evento único que incluem uma seção match (por exemplo, avaliar se um único evento corresponde a uma condição em um período). Essas regras são avaliadas quase em tempo real no mecanismo de streaming contínuo à medida que os dados são ingeridos.
  • Referenciar regras de evento único: 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 múltiplos eventos correlacionam duas ou mais condições de eventos da 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: correlacione dados de eventos com eventos de entidades da UDM (como user_context ou asset_context) usando a análise baseada 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 da regra

A frequência de execução configurada determina a regularidade com que 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 de menos de 60 minutos.
  • Frequência de 1 hora: intervalo padrão para regras de vários eventos com janelas de correspondência de até 48 horas.
  • Frequência de 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 com múltiplos eventos, a duração da janela de correspondência define o período de observação necessário para agregar eventos. As detecções só aparecem depois que toda a janela de tempo expira.

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 quando o Google SecOps recebe e analisa o registro.

Se um evento chegar depois da avaliação inicial programada para esse período, ele não será incluído na primeira execução. O sistema captura dados que chegam atrasados em execuções automatizadas em segundo plano subsequentes (execuções de ajuste), que ocorrem aproximadamente 4 horas (e, opcionalmente, 30 horas com 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 um período de 30 minutos. Se o evento A chegar às 10h05 (uma hora depois), ele vai perder a execução inicial do bloco das 9h às 9h30. O sistema reavalia o bloqueio durante uma execução de ajuste 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 registros como UTC por padrão. Se uma origem de registro omitir um ajuste de fuso horário explícito, o sistema vai tratar o carimbo de data/hora como UTC, o que pode fazer com que o registro apareça atrasado, mesmo que tenha sido recebido imediatamente.

  • Exemplo: um evento ocorre às 10h (horário do leste dos EUA) ou 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 ajuste em segundo plano.

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

  • Configure a origem do registro para incluir diferenças explícitas de fuso horário UTC nos carimbos de data/hora dos 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 em UTC antes da ingestão. Para mais informações, consulte Como modificar os carimbos de data/hora do corpo do registro usando o BindPlane.

Junções contextuais e aprimoramento de dados

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

Mecanismos de alias e enriquecimento

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

  • Aliasing: identifica e vincula diferentes identificadores da mesma entidade em várias fontes de dados, como mapear um endereço IP de registros DHCP para um endereço MAC e um nome de host como alex-macbook ou mapear um ID de usuário para um cargo de funcionário.
  • Enriquecimento: preenche campos de eventos UDM normalizados com o contexto de alias (por exemplo, preenche $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 arquivo, locais geográficos e recursos da nuvem. Para mais informações, consulte Visão geral do enriquecimento e da criação de alias da UDM.

Reenriquecimento de eventos da UDM

O sistema atualiza continuamente os 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 de entidades, a geolocalização de IP ou as atualizações de inteligência contra ameaças do VirusTotal são atualizados, o mecanismo de regras reavalia os bloqueios históricos (normalmente durante execuções de ajuste ou reprocessamento programados) para gerar detecções com contexto atualizado.
  • Dados de contexto atrasados: se os dados de contexto (como um nome de host) chegarem um dia depois do registro de eventos, o sistema vai enriquecer novamente o evento da UDM, e as execuções de ajuste subsequentes vão avaliar o registro enriquecido.
  • Modificações de contexto: se uma atualização de enriquecimento mudar um atributo de evento (como atualizar um geolocalização de IP de USA para Canada), as regras que corresponderem ao valor atualizado vão acionar detecções durante as reavaliações subsequentes.

Processamento do gráfico de contexto da entidade (ECG)

O gráfico de contexto de entidade (ECG, na sigla em inglês) correlaciona indicadores de comprometimento (IOCs) e dados do gráfico de recursos empresariais. Como o pipeline de 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 e RetroHunts históricas

Executar uma regra em dados históricos gera detecções somente depois que a verificação de retrocaça é concluída 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 com base na 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 retroativas 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 tratamento de dados e ajuste

Ao avaliar a latência de detecção, considere os seguintes comportamentos do sistema:

  • Processamento de enriquecimento: o enriquecimento de contexto pode atualizar eventos históricos da UDM até 24 horas após a ingestão inicial.
  • Ciclos de ajuste: as regras de vários eventos são executadas novamente de forma automática aproximadamente 4 horas (e, opcionalmente, 30 horas) após a execução principal para capturar dados que chegam atrasados. Para mais informações, consulte Entender as repetições de regras e o MTTD.
  • Limites de detecção: para capacidade da plataforma e limites de reduçã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 etapas do pipeline no console do Google SecOps:

  • Revise os metadados e a programação da regra: no Painel de regras, verifique as colunas Nome da regra, Tipo de regra e Programação da regra para identificar o mecanismo de execução e a frequência de avaliação de comparativo de mercado da regra.
  • Compare o horário do evento com o horário da ingestão: localize a detecção na guia Detecções e compare os carimbos de data/hora do evento e da ingestão. Se a diferença entre o horário do evento e o horário de ingestão exceder 30 minutos, a latência foi causada por atrasos na entrega de registros na origem ou durante a coleta. As detecções geradas com base em dados de eventos que chegam com mais de 30 minutos de atraso, execuções de ajuste automático, pipelines de reprocessamento ou retrocaças mostram um ícone na coluna Tipo de detecção.
  • Analise as dependências da origem do 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 ajuste subsequentes.
  • Verifique 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, verifique se uma regra com uma janela de correspondência de 15 minutos está programada para 10 minutos ou 1 hora.
  • Verifique se há interrupções no feed de dados: analise os registros de ingestão e os painéis de gerenciamento de feeds para identificar atrasos na ingestão ou interrupções temporárias na fonte.

Dicas para reduzir os 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 da regra:
    • Use Quase em tempo real para regras de evento único (padrão e com janela).
    • Configure uma programação de 10 minutos para regras de vários eventos com janelas de correspondência de menos de 60 minutos.
    • Use 1 hora para regras com janelas de correspondência entre 1 e 48 horas em que é necessário um alerta rápido.
  • Ajuste as durações das janelas de correspondência: defina as janelas de correspondência com a duração mínima necessária para capturar o comportamento de ameaça correlacionado.
  • Elimine 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: verifique se as fontes de registros fornecem compensações UTC explícitas para evitar atrasos de ingestão percebidos de mais de cinco horas.
  • Condições de contexto e não existência de auditoria: 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 conhecer conceitos de programação e fluxos de trabalho de configuração relacionados, consulte os seguintes documentos:

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