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

As detecções de regras sempre têm algum atraso, que varia de quase em tempo real a alguns minutos ou muitas horas. 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.

Categorizamos os atrasos como previstos ou não previstos.

  • Atrasos esperados: esses atrasos são resultado do processo de ingestão e das escolhas de configuração feitas ao definir a regra de detecção.
    Por exemplo, a criação de uma detecção leva tempo. 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 nos dados de eventos que chegam 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, use a pesquisa para identificar regras com longos atrasos na detecção.

  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 pode ter sido atrasada.

  4. 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 rápido que normalmente opera com um atraso de menos de cinco minutos. Ele processa regras de evento único sem seção de não correspondência e sem conjuntos de dados externos, como listas de referência ou tabelas de dados.

  2. Mecanismo de consulta

    O mecanismo de consulta processa as regras da seguinte maneira:

    • Regras de evento único complexas:

      • Regras de evento único que fazem referência a listas de referência ou tabelas de dados.
      • Regras de evento único com janela que usam uma janela de correspondência com uma condição simples. Por exemplo, "um evento em que nossa contagem de eventos > 0". Essas regras são executadas em uma taxa de consulta de alta frequência (em tempo real) à medida que novos dados são ingeridos e disponibilizados para processamento de regras.

    • Regras de vários eventos: essas regras consultam dados em blocos de tempo de evento (10 minutos, por hora, diário), de acordo com uma programação definida por você.
      Por exemplo, para uma programação de 10 minutos, a regra consulta novamente os blocos de tempo de evento após 5 a 8 horas e 24 a 48 horas, dependendo dos cronogramas de processamento upstream.

  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, sendo a última três dias após o horário do evento.
  • As regras de vários eventos geralmente combinam dados contextuais que chegam muitas horas depois do horário do evento principal. A alta latência nesses dados contextuais pode fazer com que o processamento de reenriquecimento e as repetições de regras interajam, resultando em uma detecção atrasada. Embora o Google SecOps use esse recurso para processar dados que chegam muito tarde, ele aparece como um grande período entre a janela de detecção (bloco de tempo do evento) e a hora de criação do alerta.
  • 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 à 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 ocorrem dependendo dos tempos de execução do pipeline de reprocessamento.

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 a ser analisada 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.

  2. Revise o tempo de 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 janela de correspondência:verifique se a frequência de execução é compatível com a janela de correspondência. Por exemplo, se a janela de correspondência for de 5 minutos, uma frequência de execução de 10 minutos será aceitável. No entanto, se a janela de correspondência for maior que 10 minutos, use a próxima frequência de execução disponível, que é de 1 hora.

  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 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 10 minutos.
      • Para regras com janelas de correspondência de 60 minutos ou mais: use 1 hora ou 24 horas, conforme apropriado.

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

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

      Janelas de correspondência menores são mais eficientes. Mude uma janela de correspondência de 60 minutos para 59 minutos para ativar o processamento de 10 minutos.

  • 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 atrasos na detecção de regras.

Tipos de regra

  • Regras de evento único:

    Como as regras de evento único são executadas quase em tempo real usando uma abordagem de streaming, use-as para minimizar atrasos, sempre que possível.

    • Regras simples de evento único

      Essas regras detectam eventos únicos e não usam listas de referência, tabelas de dados, janelas de correspondência ou análise comportamental de usuários e entidades (UEBA). Essas regras são executadas quase em tempo real, em um formato de streaming, e têm os menores atrasos de detecção.

    • Regras complexas de evento único

      • Regras de evento único da janela

        São regras de evento único que incluem uma janela de correspondência e geralmente têm um atraso um pouco maior do que outras regras de evento único. Um período de correspondência é normalmente um período em que uma regra examina um ou mais eventos.

      • Referenciar regras de evento único

        São regras de evento único que incluem listas de referência ou tabelas de dados.

  • Regras de vários eventos:

    As regras de vários eventos são executadas de forma programada, 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 sensíveis ao contexto ajudam a entender os padrões comportamentais na telemetria e o contexto das entidades afetadas por esses padrões.

      • Essas regras consistem em duas ou mais condições, mas pelo menos uma delas é um evento de entidade do UDM (em que o evento do UDM é do tipo context, como user_context).
      • Esses tipos de regras têm atrasos maiores, e não é incomum que as detecções levem alguns dias.
      • As regras sensíveis ao contexto geralmente têm os maiores atrasos porque o sistema precisa primeiro gerar os dados de contexto necessários.

Saiba mais sobre a diferença entre 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 mais frequência para dados em tempo real, funcionando constantemente. Isso se aplica apenas a regras de evento único.
  • Outras frequências:para outros tipos de regras, é 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 1 e 24 horas são válidas para janelas de correspondência de menos de 48 horas.
    • A frequência de 24 horas é válida para todas as janelas de correspondência de 48 horas ou mais.

Solução alternativa possível:para ter detecções mais rápidas, use uma frequência de execução menor e uma janela de correspondência menor. Usar janelas de correspondência mais curtas (menos de uma hora) permite execuções mais frequentes.

Janela de correspondência

Se uma regra tiver uma janela de correspondência, a duração dela vai determinar o atraso mínimo na 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 não vai aparecer nas 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 cuidado os carimbos de data/hora de eventos e ingestão da UDM.

Problemas de fuso horário

O fuso horário padrão do SIEM do Google SecOps é 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 causa 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 Entity Graph, 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 Enriquecimento de dados.

Pseudônimos e enriquecimento

O aliasing e o enriquecimento são duas etapas do processo de enriquecimento 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 o IP addresses, o MAC addresses (de registros DHCP) ou um user ID (como alex) ao job title e ao employment status (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, IPs, 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:depois que o sistema ingere um evento, se os dados subjacentes mudarem, o sistema vai reprocessar os dados históricos e atualizar os eventos por até 24 horas.

  • 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, por exemplo, três dias após o registro inicial, o sistema vai enriquecer novamente o evento da UDM. As regras que procuram esses dados enriquecidos novamente são executadas de novo e criam uma detecção. Esse recurso garante que o sistema crie detecções mesmo quando o contexto está atrasado.

  • 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, consultando o período das 9h às 10h, e a regra não corresponde. Mais tarde, 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, na sigla em inglês) 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 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 antes estava vazio, com o valor workstation-123.
  4. Detecção:as execuções de regra subsequentes (execuções de limpeza) agora mostram o valor enriquecido (workstation-123) e podem acionar detecções que antes eram perdidas.

Observação:não é possível distinguir as métricas de monitoramento de latência para regras de detecção em tempo real e de retrocaça. Para evitar distorcer as métricas de monitoramento da latência de detecção, não use uma regra ativa para simular uma regra de retrocaça. Como prática recomendada, crie uma regra de detecção dedicada e execute-a como uma regra de retrohunt.

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 com atraso 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 registro para o Google SecOps assim que o evento ocorrer.
  • Revise 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.