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, descreve abordagens de solução de problemas e sugere técnicas para reduzir os atrasos sempre que possível.

Regras de detecção

As regras de detecção examinam eventos regulares e de entidade do Modelo de dados universal (UDM), que são registros brutos normalizados, para gerar detecções de acordo com as especificações da regra. Os eventos UDM de entidade geralmente contêm informações contextuais, como detalhes do usuário ou do recurso. As regras também geram detecções com base em detecções geradas anteriormente.

Atrasos previstos e não previstos

Os tempos de detecção estão sujeitos a atrasos no processamento. Embora algumas regras sejam acionadas quase em tempo real, outras podem levar vários minutos ou horas para serem concluídas. Fatores como tipo de regra, frequência de execução e método de geração de detecção afetam esses atrasos. Este documento aborda esses e outros fatores de atraso.

Os atrasos são categorizados como esperados ou não previstos.

  • Atrasos esperados: esses atrasos resultam do processo de ingestão e das escolhas de configuração feitas ao definir a regra de detecção. Por exemplo, o tempo gasto para criar uma detecção é um fator. Esses atrasos dependem de fatores estruturais conhecidos, como o tipo de regra, a frequência de execução, o método de geração de detecção, as limitações conhecidas e outros fatores previsíveis.
    É possível minimizar esses atrasos mudando ou ajustando as configurações de regra de detecção, conforme descrito neste documento.
    Para mais detalhes, consulte Dicas para reduzir atrasos.

  • Atrasos não previstos: são atrasos específicos de regras ou eventos causados por muitos fatores, incluindo atrasos na chegada dos dados de eventos ao Google SecOps, lentidão temporária no processamento de pipelines nos serviços do Google SecOps, reenriquecimento e outros atrasos no tratamento de dados.

Analisar atrasos na detecção de regras

Para analisar atrasos na detecção de regras, encontre informações sobre a regra e os fatores relacionados:

  1. No console do Google SecOps, acesse Detecção > Regras e detecções.

    O painel de regras mostra metadados de regras, como Rule name, Rule type e Run frequency.

    Para mais detalhes, consulte Como ver regras no painel "Regras".

  2. No painel de regras, clique no nome de uma regra para ver o histórico de detecção e outros detalhes dela.

  3. Para qualquer execução de regra específica, há vários fatores que podem afetar a latência de detecção. Dimensões como Rule type, Run frequency, Event type, Event time e Ingested time são boas heurísticas para entender por que uma detecção específica foi atrasada.

Um ícone na coluna Tipo de detecção identifica detecções geradas com base em dados de eventos atrasados em mais de 30 minutos, execuções de reprocessamento de regras ou retrocaças. Esse ícone também aparece na página Alertas do Google SecOps.

  1. Conheça os seguintes tópicos para entender como esses fatores influenciam os atrasos na detecção de regras:

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

Saiba como o sistema cria detecções de regras para entender como o método de geração de detecção afeta os atrasos.

O sistema gera detecções de regras das seguintes maneiras:

  1. Streaming Engine

    O Streaming Engine é um pipeline de streaming dedicado que opera com baixa latência (normalmente menos de cinco minutos de atraso). Ele avalia regras padrão de evento único que não têm seção de correspondência, conjuntos de dados externos (como listas de referência ou tabelas de dados) e funções de UEBA.

  2. Mecanismo de consulta

    O mecanismo de consulta avalia regras complexas de eventos únicos e múltiplos:

    • Regras de evento único complexas:

      • Regras de evento único com listas de referência ou tabelas de dados: regras que avaliam um único evento e fazem pesquisas em listas de referência ou tabelas de dados.
      • Regras de evento único com janela: regras que avaliam um único evento com uma janela de correspondência e uma condição de existência simples (por exemplo, $e, #e > 0 ou #e >= 1).
      • Embora as regras complexas de evento único usem o mecanismo de consulta em vez do mecanismo de streaming, elas são programadas em uma programação de alta frequência quase em tempo real à medida que novos dados são ingeridos. Isso oferece uma latência menor, próxima da latência típica do mecanismo de streaming. Os dados enriquecidos e que chegam atrasados são reavaliados durante a execução padrão da consulta sem exigir intervalos de correção de vários eventos.

    • Regras de vários eventos: essas regras consultam dados em blocos de horário do evento (10 minutos, por hora, por dia), de acordo com uma programação definida por você. Os tempos de nova consulta para dados que chegam atrasados dependem do tipo de programação.

      • Para a programação padrão, as novas consultas acontecem cerca de 5 e 24 horas após o horário do evento.
      • Os cronogramas personalizáveis oferecem diferentes tempos de ajuste. Para mais detalhes, consulte Entender as repetições de regras e o MTTD.

  3. As regras são executadas com base em dados históricos

    Para mais detalhes, consulte Retro hunts.

  4. Reenriquecimento de eventos do UDM

    Para mais detalhes, consulte Reenriquecimento de eventos da UDM e Processamento do gráfico de contexto da entidade.

Limitações conhecidas

Confira algumas limitações padrão que contribuem para atrasos na detecção de regras:

  • Às vezes, os atrasos no enriquecimento podem levar mais tempo do que o esperado. O reprocessamento do enriquecimento faz com que as execuções de regras posteriores reavaliem os dados. O sistema realiza várias execuções de enriquecimento, que podem atualizar eventos da UDM até 24 horas após a ingestão.

  • Regras de vários eventos:

    • Para regras de vários eventos na programação padrão, o sistema reexecuta as regras aproximadamente 5 horas e 24 horas após o horário do evento.

    • As regras de vários eventos com programações personalizáveis têm tempos de ajuste diferentes.

    Essas reexecuções de regras são acionadas para processar dados atrasados.

  • As regras baseadas no contexto dependem de fontes de enriquecimento, como alias de ativos e identidades, ou o gráfico de contexto de entidade. Como essas regras dependem de várias fontes de eventos, elas são mais suscetíveis a alta latência.

  • O sistema executa as regras novamente entre 5 e 8 horas e entre 24 e 48 horas após a execução inicial. Essas duas reproduções de regras separadas são acionadas com base nos tempos de execução do pipeline de reprocessamento.

  • Para mais limites de detecção, consulte Entender os limites de detecção.

Resolver problemas de atrasos na detecção de regras

Solucione problemas de atrasos na detecção de regras por um processo de eliminação.

Siga esta abordagem sugerida para investigar e resolver problemas de atrasos na detecção de regras:

  1. Verifique se há atrasos óbvios:

    Determine se há um atraso na ingestão:

    1. No console do Google SecOps, acesse Detecção > Regras e detecções.

    2. Pesquise a regra que você quer analisar no painel de regras.

    3. Compare o Event time com o Ingested time.

      Por exemplo, para uma detecção de regra específica, se houver uma grande diferença entre Event time e Ingested time, é provável que o atraso na detecção seja atribuído a um atraso esperado. Um ícone na coluna Tipo de detecção é aplicado quando o Ingestion time ocorre mais de 30 minutos após o Event time.

  2. Revise o horário da coleta da origem do contexto:

    Verifique o horário de coleta da origem do contexto.

    As regras baseadas no contexto podem incluir as seguintes fontes de contexto. Confira os horários de coleta:

    • Campos derivados do enriquecimento de UDM.
    • Eventos que incluem um campo principal.

    • Regras que fazem referência a um campo graph.entity.

      Regras que fazem referência ao gráfico de contexto de entidade (ECG) com a sintaxe graph.entity podem causar latência muito alta. Por exemplo, o pipeline de ECG gera dados de contexto, um processo que pode levar 30 horas ou, em alguns casos, até 8 dias, dependendo do tipo de dados.

    Para mais detalhes, consulte Atrasos no processamento de dados.

  3. Examine a frequência de execução da regra e a configuração da janela de correspondência:

    • Frequência:verifique a frequência de execução da regra. Uma regra configurada para ser executada com menos frequência naturalmente tem atrasos de detecção mais longos.
    • Janela de correspondência:se uma regra tiver uma janela de correspondência, o atraso mínimo será a duração dessa janela.
    • Relação entre frequência e período de correspondência:confira se a frequência de veiculação é compatível com o período de correspondência. Por exemplo, para janelas de correspondência com menos de 60 minutos, é possível usar uma frequência de execução de 10 minutos (quase em tempo real). Para janelas de correspondência de 60 minutos ou mais (até 48 horas), use 1 hora. Para janelas de correspondência maiores que 48 horas, use "Diário".

  4. Verificar incidentes recentes:

    Procure incidentes recentes que possam ter causado atrasos ou problemas com os feeds de dados.

Dicas para reduzir atrasos

Para atualizar as configurações de regras de detecção, consulte Gerenciar regras usando o editor de regras.

Use as técnicas a seguir para reduzir os atrasos sempre que possível:

  • Para regras sensíveis à latência, use as opções de execução mais frequentes:

    • Aumente a frequência da regra:

      Para reduzir os atrasos, configure a maior frequência possível com base no tipo de regra e na janela de correspondência:

      • Para todas as regras de evento único: use Quase em tempo real.
      • Para regras de vários eventos com janelas de correspondência menores que 60 minutos: use Quase em tempo real (10 minutos).
      • Para regras de vários eventos com janelas de correspondência de 60 minutos ou mais, use 1 hora ou Diário, conforme apropriado.

      Para mais detalhes, consulte Definir a frequência de execução.

    • Reduzir a duração da janela de correspondência:

      Reduzir a janela de correspondência não afeta diretamente a latência, mas pode aumentar a eficiência ao definir o atraso mínimo.

  • Evite dados que chegam tarde:

    Os dados que chegam atrasados não são incluídos na consulta inicial, e o sistema os processa somente quando consulta novamente o bloco de tempo do evento de 5 a 8 horas depois, causando atrasos significativos. Os dados de pontualidade geralmente têm um atraso de cerca de 20 minutos.

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

O tipo de regra, a frequência de execução e a velocidade da ingestão do Google SecOps são fatores importantes nos atrasos de detecção de regras.

Os fatores a seguir contribuem para os atrasos na detecção de regras.

Tipos de regra

As regras se enquadram em duas categorias principais:

Regras de evento único

As regras de evento único padrão detectam eventos individuais sem pesquisas de dados externos, janelas de correspondência ou análise do comportamento de usuários e entidades (UEBA). Essas regras são executadas quase em tempo real usando um mecanismo de streaming dedicado e alcançam a menor latência de detecção (normalmente menos de cinco minutos).

Regras complexas de evento único

As regras complexas de evento único avaliam eventos individuais, mas incorporam listas de referência, tabelas de dados ou janelas de correspondência simples. Elas são executadas usando o mecanismo de consulta em vez do mecanismo de streaming, mas são programadas em uma programação quase em tempo real com baixa latência próxima ao mecanismo de streaming:

  • Lista de referência e regras de evento único da tabela de dados:

    Essas regras de evento único fazem pesquisas em listas de referência ou tabelas de dados sem exigir uma janela de correspondência de vários eventos.

  • Regras de evento único com janela:

    Essas regras de evento único incluem uma janela de correspondência com uma condição simples de contagem de eventos, como $e, #e > 0 ou #e >= 1.

Regras de vários eventos

As regras de vários eventos são executadas de acordo com uma programação, o que resulta em atrasos maiores devido ao tempo entre as execuções programadas.

  • Regras de vários eventos

    Essas regras examinam duas ou mais condições de eventos da UDM. Elas geralmente têm uma janela de correspondência e várias condições.

  • Regras baseadas no contexto

    As regras baseadas no contexto ajudam você a unir mais dados de contexto de detecção e entidade aos seus eventos.

    • Essas regras consistem em duas ou mais fontes de dados, em que pelo menos uma condição é um evento de entidade da UDM (em que o evento da UDM é do tipo contexto, como user_context).
    • As regras baseadas no contexto são as mais sensíveis a dados que chegam atrasados.
    • As regras baseadas no contexto geralmente têm os maiores atrasos porque o sistema precisa primeiro gerar os dados de contexto necessários, como dados no gráfico de contexto da entidade .
    • Para mais detalhes, consulte Usar dados enriquecidos com contexto em regras.

Saiba mais sobre a diferença entre as regras de Evento único e Vários eventos.

Frequência de execução da regra

A frequência de execução da regra afeta diretamente o atraso na detecção.

  • Quase em tempo real:as regras são executadas com latência mínima à medida que os eventos são ingeridos. Isso se aplica a:
    • Todas as regras de evento único (padrão, com listas de referência ou tabelas de dados e com janelas).
    • Regras de vários eventos com janelas de correspondência menores que 60 minutos.
  • Outras frequências:para outras configurações de regra, é possível definir as seguintes frequências:
    • A frequência de 10 minutos é válida para janelas de correspondência com menos de 60 minutos.
    • As frequências de uma hora e diárias são válidas para janelas de correspondência de até 48 horas.
    • A frequência diária é válida para todas as janelas de correspondência maiores que 48 horas.

Solução alternativa possível:para ter detecções mais rápidas, use uma frequência de execução menor. Reduzir a janela de correspondência não afeta diretamente a latência, mas pode aumentar a eficiência ao definir o atraso mínimo.

Janela de correspondência

Se uma regra tiver uma janela de correspondência, a duração dela vai determinar o atraso mínimo de detecção, já que o sistema precisa aguardar a ocorrência de toda a janela.

Atraso na ingestão

O atraso na ingestão se refere ao tempo que o Google SecOps leva para ingerir dados após a ocorrência do evento.

Se os dados chegarem atrasados, eles não vão entrar na janela de consulta inicial. Uma consulta de processamento histórico subsequente a identifica, mas isso pode causar atrasos de 5 a 8 horas.

Por exemplo, o evento A (horário do evento: 9h03) e o evento B (horário do evento: 9h05) fazem parte de uma regra que procura dois eventos em 30 minutos. Se o evento A chegar às 10h05 (uma hora depois), ele vai perder as consultas iniciais do bloco das 9h às 9h30. Uma consulta de acompanhamento para esse bloco entre 14h e 17h gera a detecção, resultando em atrasos de 5 a 8 horas.

Solução de problemas:verifique se você envia dados para o Google SecOps assim que o evento ocorre. Ao analisar uma detecção, verifique com atenção os carimbos de data/hora do evento e da ingestão da UDM.

Problemas de fuso horário

O fuso horário padrão do Google SecOps SIEM é UTC. Se os registros não incluírem uma definição explícita de fuso horário, o sistema os interpretará como UTC. A interpretação incorreta pode fazer com que os registros sejam tratados como atrasados, o que resulta em atrasos na detecção, mesmo que o sistema os receba em tempo real.

Por exemplo, um registro com um horário de evento das 10h (horário do leste dos EUA) (15h UTC) chega às 15h05 UTC, mas não tem um fuso horário. Se o registro não tiver um fuso horário, o sistema vai interpretar o horário do evento como 10:00 UTC. Em seguida, o sistema calcula um atraso de 5 horas entre o horário do evento interpretado (10h UTC) e o horário real de ingestão (15h05 UTC). Esse atraso calculado aciona atrasos na detecção porque as regras priorizam o processamento com base na ingestão em tempo real.

Soluções alternativas:se o carimbo de data/hora do evento dos dados originais estiver em um fuso horário diferente do UTC, tente uma das seguintes opções:

  • Atualize o fuso horário do evento dos dados originais.
  • Se não for possível atualizar o fuso horário na origem do registro, entre em contato com o suporte para substituir o fuso horário.
  • Como alternativa, use um processador do BindPlane para corrigir o carimbo de data/hora e formatá-lo como UTC ou adicione o indicador de fuso horário adequado. Para mais detalhes, consulte Modificar carimbos de data/hora do corpo do registro usando o BindPlane.

Junções contextuais

As regras de vários eventos que usam dados contextuais, como UEBA ou campos de gráfico de contexto de entidade, podem ter atrasos maiores. Primeiro, o Google SecOps precisa gerar os dados contextuais.

Sistema de enriquecimento

O Google SecOps enriquece os eventos do UDM adicionando dados contextuais de outras fontes. Esse processo geralmente leva até 30 minutos. Atrasos na adição desses dados enriquecidos aos eventos do UDM podem aumentar os tempos de detecção.

Para verificar se uma regra está avaliando um campo enriquecido, analise o Visualizador de eventos. Se a regra estiver avaliando um campo enriquecido, a detecção poderá ser adiada.

Para mais detalhes, consulte aprimoramento de dados.

Alias e enriquecimento

O aliasing e o enriquecimento são duas etapas do processo de aprimoramento de dados de segurança do Google SecOps que correlacionam e adicionam dados de contexto aos registros de eventos. O aliasing encontra as conexões, e o enriquecimento preenche os campos da UDM com esses dados conectados. Os campos preenchidos por esse processo são chamados de campos com alias ou campos enriquecidos.

  • Aliasing:é o processo de identificar e vincular diferentes nomes ou identificadores para a mesma entidade. Ele encontra dados de contexto adicionais que descrevem um indicador. Por exemplo, o aliasing pode conectar um único hostname (como alex-macbook) a outros indicadores relacionados, como IP addresses e MAC addresses (de registros do DHCP). O uso de alias também pode conectar um user ID (como alex) ao job title e employment status do usuário (de dados de contexto do usuário).
  • Enriquecimento:é o processo que usa as informações coletadas do aliasing para adicionar contexto a um evento da UDM. Por exemplo, quando um novo evento chega com apenas um IP address, o processo de enriquecimento usa os dados com alias para encontrar o hostname associado (por exemplo, alex-macbook) e preenche o campo $udm.event.principal.hostname.

O Google SecOps oferece suporte a alias e enriquecimento para vários tipos de entidades, incluindo: recursos (por exemplo, nomes de host, endereços IP, MACs), usuários, processos, metadados de hash de arquivo, locais geográficos e recursos da nuvem. Para mais detalhes, consulte Visão geral do enriquecimento e da criação de alias da UDM.

Reenriquecimento de eventos do UDM

  • Mudanças nos dados subjacentes:se os dados subjacentes mudarem depois que um evento for ingerido, o sistema vai processar novamente os dados históricos e atualizar os eventos por até 24 horas após a ingestão.

  • Atualizações do sistema de enriquecimento:se o sistema de enriquecimento atualizar metadados de entidade ou processo, geolocalização de IP ou indicadores do VirusTotal, o mecanismo de regras reavaliará esses blocos de 24 a 48 horas depois para capturar essas atualizações.
    Por exemplo, um evento às 9h03 tem entity.asset.hostname = hostnameA, mas não tem IP. Um registro de DHCP das 8h55 mostra hostnameA = IP 1.2.3.4. O mecanismo de regras é executado às 9h10, e a regra não corresponde. O pipeline de processamento de enriquecimento correlaciona hostnameA a 1.2.3.4 para esse período, atualizando o evento da UDM. Agora a regra corresponde, e o sistema cria uma detecção.

  • Dados de contexto atrasados:se você enviar dados de contexto, como um hostname, um dia após o registro inicial, o sistema vai enriquecer novamente o evento da UDM. As regras que procuram esses dados repletos são executadas novamente e criam uma detecção.

  • Mudanças nos dados de enriquecimento:elas podem fazer com que uma regra corresponda mais tarde, mesmo que não tenha correspondido inicialmente.
    Por exemplo, um evento às 9h03 tem entity.ip_geo_artifact.country_or_region = USA. O mecanismo de regras é executado às 9h10, consulta das 9h às 10h, e a regra não corresponde. Depois, o reprocessamento do enriquecimento atualiza a geolocalização para o Canadá. Quando a regra é executada novamente, ela corresponde, e o sistema cria uma detecção.

Processamento de gráficos de contexto de entidade

O sistema gera e adiciona informações do gráfico de contexto de entidade (ECG) aos dados de registro para fornecer contexto, por exemplo, indicadores de comprometimento (IOCs) ou dados de contexto de recursos. Como o pipeline de ECG depende principalmente do processamento em lote, as informações de contexto da entidade geralmente são atualizadas somente depois que a execução de uma regra cria uma detecção.

Buscas retroativas

Quando você executa uma regra com base em dados históricos usando uma busca retroativa, o sistema só cria a detecção depois que o processo de busca retroativa é concluído. Esse processo pode levar muito tempo, o que causa um atraso na detecção.

Exemplo de um processo de atualização retroativa:

  1. Evento inicial: um evento chega às 13h com ip_address = 10.0.0.5. No momento, o hostname é desconhecido.
  2. Chegada da origem do alias: às 14h30 (mais de uma hora depois), um registro de DHCP chega para as 13h, vinculando 10.0.0.5 a workstation-123.
  3. Enriquecimento retroativo:o sistema de pseudônimos processa esse novo link. Ele atualiza retroativamente o evento da UDM das 13h, enriquecendo o campo $udm.event.principal.hostname, que estava vazio, com o valor workstation-123.
  4. Detecção:as repetições de regras subsequentes veem o valor enriquecido (workstation-123) e podem acionar detecções que foram perdidas anteriormente.

Listas de referências

As execuções de regras sempre usam a versão mais recente de uma lista de referência. Quando as regras programadas são executadas novamente, o sistema pode criar novas detecções com base no conteúdo atualizado da lista de referência. Essas detecções podem aparecer tarde porque são baseadas em dados ingeridos antes da atualização da lista de referência.

Para reduzir os atrasos na detecção, faça o seguinte:

  • Envie dados de registros para o Google SecOps assim que o evento ocorrer.
  • Analise as regras de auditoria para determinar se é melhor usar dados de não existência ou enriquecidos com contexto.
  • Configure uma frequência de execução menor.

Regras de não existência

O sistema espera pelo menos uma hora antes de executar regras que verificam a não existência (por exemplo, regras que contêm !$e ou #e=0), garantindo que os dados tenham tempo para chegar.

Atrasos no processamento de dados

O sistema pode continuar processando dados mesmo depois de criar uma detecção inicial, o que pode levar a detecções novas ou atualizadas. Para mais detalhes, consulte Quando as repetições de regras são acionadas.

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