Compreenda os atrasos na deteção de regras

Suportado em:

Este documento explica os atrasos na deteção de regras no Google Security Operations, identifica os fatores que contribuem, descreve abordagens de resolução de problemas e sugere técnicas para reduzir os atrasos sempre que possível.

Regras de deteção

As regras de deteção examinam eventos do modelo de dados universal (UDM) de entidades e regulares, que são registos não processados normalizados, para gerar deteções de acordo com as especificações da regra. Normalmente, os eventos UDM de entidades contêm informações de contexto , como detalhes do utilizador ou do recurso. As regras também geram deteções com base em deteções geradas anteriormente.

Atrasos previstos e imprevistos

As deteções de regras têm sempre algum atraso, que varia entre quase em tempo real e alguns minutos ou muitas horas. Fatores como o tipo de regra, a frequência de execução e o método de geração de deteções afetam estes atrasos. Este documento explora estes e outros fatores de atraso.

Categorizamos os atrasos como esperados ou imprevistos.

  • Atrasos esperados: estes atrasos resultam do processo de carregamento e das escolhas de configuração que faz quando configura a regra de deteção.
    Por exemplo, a criação de uma deteção demora tempo. Estes atrasos dependem de fatores estruturais conhecidos, como o tipo de regra, a frequência de execução, o método de geração de deteções, as limitações conhecidas e outros fatores previsíveis.
    Pode minimizar estes atrasos alterando ou ajustando as configurações das regras de deteção, conforme descrito neste documento.
    Para obter detalhes, consulte o artigo Sugestões para reduzir os atrasos.

  • Atrasos imprevisíveis: estes são atrasos específicos de regras ou eventos causados por vários fatores, incluindo atrasos na chegada de dados de eventos ao Google SecOps, lentidão temporária nos pipelines de processamento nos serviços do Google SecOps, re-enriquecimento e outros atrasos no processamento de dados.

Analise os atrasos na deteção de regras

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

  1. Na consola do Google SecOps, aceda a Deteção > Regras e deteções.

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

    Para mais detalhes, consulte o artigo Ver regras no painel de controlo Regras.

  2. No painel de controlo Regras, use a pesquisa para identificar regras com atrasos de deteção longos.

  3. Para qualquer execução de regra específica, existem vários fatores que podem afetar a latência de deteção. As dimensões, como Rule type, Run frequency, Event type, Event time e Ingested time, são boas heurísticas para compreender por que motivo uma deteção específica pode ter sido atrasada.

  4. Familiarize-se com os seguintes tópicos para compreender como estes fatores influenciam os atrasos na deteção de regras:

Métodos de geração de deteções

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

O sistema gera deteções de regras das seguintes formas:

  1. Motor de streaming

    O motor de streaming é um pipeline rápido que funciona normalmente com um atraso inferior a cinco minutos. Processa regras de evento único sem secção de correspondência e sem conjuntos de dados externos, como listas de referência ou tabelas de dados.

  2. Motor de consultas

    O motor de consultas processa as regras da seguinte forma:

    • Regras de evento único complexas:

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

    • Regras de vários eventos: estas regras consultam dados em blocos de tempo do evento (10 minutos, por hora, por dia), de acordo com uma programação que define.
      Por exemplo, para uma programação de 10 minutos, a regra volta a consultar os blocos de tempo do evento após 5 a 8 horas e 24 a 48 horas, consoante os prazos de processamento a montante.

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

    Para obter detalhes, consulte a secção Retro hunts.

  4. Reenriquecimento de eventos da UDM

    Para obter detalhes, consulte os artigos Reenriquecimento de eventos UDM e Processamento do gráfico de contexto da entidade

Limitações conhecidas

Seguem-se algumas limitações padrão que contribuem para os atrasos na deteção de regras:

  • Por vezes, os atrasos nos enriquecimentos podem demorar mais do que o esperado. O reprocessamento do enriquecimento faz com que as execuções de regras posteriores reavaliem os dados. O sistema executa várias execuções de enriquecimento, sendo a última execução três dias após a hora do evento.
  • As regras de vários eventos juntam frequentemente dados contextuais que chegam muitas horas após a hora do evento principal. A latência elevada nestes dados contextuais pode fazer com que o processamento de reenriquecimento e as repetições de regras interajam, o que resulta numa deteção atrasada. Embora o Google SecOps use esta funcionalidade para processar dados que chegam com um atraso extremo, aparece como um grande intervalo de tempo entre a janela de deteção (bloco de tempo do evento) e a hora de criação do alerta.
  • As regras sensíveis ao contexto são regras que dependem de origens de enriquecimento, como a criação de alias de recursos e identidades, ou o gráfico de contexto de entidades. Uma vez que estas regras dependem de várias origens de eventos, são mais suscetíveis à latência.
  • O sistema volta a executar as regras entre 5 e 8 horas, e novamente entre 24 e 48 horas após a execução inicial das regras. Estas duas reproduções de regras separadas ocorrem consoante os tempos de execução do pipeline de reprocessamento.

Resolva problemas de atrasos na deteção de regras

Resolva problemas de atrasos na deteção de regras através de um processo de eliminação.

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

  1. Verifique se existem atrasos óbvios:

    Determinar se existe algum atraso na carregamento:

    1. Na consola do Google SecOps, aceda a Deteção > Regras e deteções.

    2. Pesquise a regra a analisar no painel de controlo de regras.

    3. Compare o Event time com o Ingested time.

      Por exemplo, para uma deteção de regra específica, se existir uma grande diferença entre a Event time e a Ingested time, é provável que possa atribuir o atraso na deteção a um atraso esperado.

  2. Reveja a hora de recolha da origem do contexto:

    Verifique a hora de recolha da origem do contexto.

    As regras sensíveis ao contexto podem incluir as seguintes origens de contexto. Verifique os respetivos horários de recolha:

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

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

      As regras que fazem referência ao gráfico de contexto de entidades (ECG) com a sintaxe graph.entity podem causar uma latência particularmente elevada. Por exemplo, o pipeline de ECG gera dados de contexto, um processo que pode demorar 30 horas ou, em alguns casos, até 8 dias, consoante o tipo de dados.

    Para mais detalhes, consulte o artigo Atrasos no tratamento de dados.

  3. Examine a frequência de execução da regra e a configuração do período de correspondência:

    • Frequência: verifique a frequência de execução da regra. Uma regra configurada para ser executada com menos frequência tem, naturalmente, atrasos de deteção mais longos.
    • Janela de correspondência: se uma regra tiver uma janela de correspondência, o atraso mínimo é a duração dessa janela.
    • Relação entre a frequência e o período de correspondência: certifique-se de que a frequência de execução é compatível com o período de correspondência. Por exemplo, se a janela de correspondência for de 5 minutos, uma frequência de execução de 10 minutos é aceitável. No entanto, se a janela de correspondência for superior a 10 minutos, use a frequência de execução seguinte disponível, ou seja, 1 hora.

  4. Verifique se existem incidentes recentes:

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

Sugestões para reduzir os atrasos

Para atualizar as configurações das regras de deteção, consulte o artigo Faça a gestão das regras através do editor de regras.

Use as seguintes técnicas 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 frequência mais elevada possível com base no tipo de regra e na janela de correspondência:

      • Para regras de evento único: use a opção Quase em tempo real.
      • Para regras de vários eventos com janelas de correspondência inferiores a 60 minutos: use 10 minutos.
      • Para regras com janelas de correspondência de 60 minutos ou mais: use 1 hora ou 24 horas, conforme adequado.

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

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

      As janelas de correspondência mais pequenas são mais eficientes. Altere um período 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 tarde não são incluídos na consulta inicial e o sistema processa-os apenas quando consulta novamente o respetivo bloco de tempo de evento 5 a 8 horas mais tarde, o que causa atrasos significativos. Normalmente, os dados de pontualidade têm um atraso de cerca de 20 minutos.

Fatores que contribuem para os atrasos na deteção de regras

O tipo de regra, a frequência de execução e a velocidade de carregamento do Google SecOps são fatores essenciais nos atrasos na deteção de regras.

Os seguintes fatores contribuem para os atrasos na deteção de regras.

Tipos de regras

  • Regras de evento único:

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

    • Regras simples de evento único

      Estas regras detetam eventos únicos e não usam listas de referência, tabelas de dados, janelas de correspondência nem User and Entity Behavior Analytics (UEBA). Estas regras são executadas quase em tempo real, em streaming, e têm os atrasos de deteção mais curtos.

    • Regras complexas de evento único

      • Regras de evento único de janela

        Estas são regras de evento único que incluem um período de correspondência e, normalmente, têm um ligeiro atraso superior ao de outras regras de evento único. Uma janela de correspondência é, normalmente, um período durante o qual uma regra examina um ou mais eventos.

      • Consulte regras de evento único

        Estas 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 mais longos devido ao tempo entre as execuções programadas.

    • Regras de vários eventos

      Estas regras examinam duas ou mais condições de eventos UDM. Normalmente, têm um período de correspondência e várias condições.

    • Regras sensíveis ao contexto

      As regras sensíveis ao contexto ajudam a compreender os padrões comportamentais na telemetria e o contexto das entidades afetadas a partir desses padrões.

      • Estas regras consistem em duas ou mais condições, mas, pelo menos, uma condição é um evento de entidade do UDM (em que o evento do UDM é do tipo context, como user_context).
      • Estes tipos de regras têm atrasos mais longos e não é invulgar que as deteções demorem alguns dias.
      • Geralmente, as regras sensíveis ao contexto têm os atrasos mais longos porque o sistema tem de gerar primeiro os dados de contexto necessários.

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

Frequência de execução de regras

A frequência de execução das regras afeta diretamente o atraso na deteção.

  • Quase em tempo real: as regras são executadas com maior frequência para dados em tempo real e estão em execução constante. Isto aplica-se apenas a regras de evento único.
  • Outras frequências: para outros tipos de regras, pode 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 hora e 24 horas são válidas para janelas de correspondência inferiores a 48 horas.
    • A frequência de 24 horas é válida para todos os períodos de correspondência de >= 48 horas.

Solução alternativa possível: para conseguir deteções mais rápidas, use uma frequência de execução mais curta e um período de correspondência mais pequeno. A utilização de períodos de correspondência mais curtos (menos de uma hora) permite execuções mais frequentes.

Janela de correspondência

Se uma regra tiver um período de correspondência, a duração do período determina o atraso mínimo de deteção, uma vez que o sistema tem de aguardar que todo o período ocorra.

Atraso no carregamento

O atraso na carregamento refere-se ao tempo que o Google SecOps demora a carregar dados após a ocorrência do evento.

Se os dados chegarem tarde, não entram na janela de consulta inicial. Uma consulta de processamento histórico subsequente deteta-o, mas isto pode introduzir atrasos de 5 a 8 horas.

Por exemplo: o Evento A (hora do evento: 09:03) e o Evento B (hora do evento: 09:05) fazem parte de uma regra que procura dois eventos no prazo de 30 minutos. Se o Evento A chegar às 10:05 (1 hora de atraso), perde as consultas iniciais do bloco das 09:00 às 09:30. Uma consulta de seguimento para esse bloco entre as 14:00 e as 17:00 gera a deteção, o que resulta em atrasos de 5 a 8 horas.

Resolução de problemas: verifique se envia dados para o Google SecOps assim que o evento ocorre. Quando revê uma deteção, verifique cuidadosamente o evento da UDM e as datas/horas de carregamento.

Problemas de fuso horário

O fuso horário predefinido do SIEM do Google SecOps é UTC. Se os registos não incluírem uma definição explícita do fuso horário, o sistema interpreta-os como UTC. A interpretação incorreta pode fazer com que os registos sejam tratados como recebidos tardiamente, o que resulta em atrasos na deteção, mesmo que o sistema os receba em tempo real.

Por exemplo, um registo com uma hora do evento de 10:00 AM Eastern Time (15:00 UTC) chega às 15:05 UTC, mas não tem um fuso horário. Se o registo não tiver um fuso horário, o sistema interpreta a hora do evento como 10:00 UTC. Em seguida, o sistema calcula um atraso de 5 horas entre a hora do evento interpretada (10:00 UTC) e a hora de carregamento real (15:05 UTC). Este atraso calculado aciona atrasos na deteção porque as regras dão prioridade ao processamento com base no carregamento em tempo real.

Soluções alternativas: se a data/hora do evento dos dados originais estiver num fuso horário diferente de UTC, experimente uma das seguintes opções:

  • Atualize o fuso horário do evento dos dados originais.
  • Se não conseguir atualizar o fuso horário na origem do registo, contacte o apoio técnico para substituir o fuso horário.
  • Em alternativa, use um processador BindPlane para corrigir a data/hora e formatá-la como UTC ou adicione o indicador de fuso horário adequado. Para ver detalhes, consulte o artigo Modificar as datas/horas do corpo do registo com o BindPlane.

Junções contextuais

As regras de vários eventos que usam dados contextuais, como UEBA ou Entity Graph, podem sofrer atrasos mais longos. O Google SecOps tem de gerar primeiro os dados contextuais.

Sistema de enriquecimento

O SecOps da Google enriquece os eventos da GDU adicionando dados contextuais de outras origens. Normalmente, este processo demora 30 minutos a ser concluído. Os atrasos na adição destes dados enriquecidos aos eventos do UDM podem aumentar os tempos de deteção.

Para verificar se uma regra está a avaliar um campo enriquecido, reveja o Visualizador de eventos. Se a regra estiver a avaliar um campo enriquecido, a deteção pode ser atrasada.

Para mais detalhes, consulte o artigo Enriquecimento de dados.

Criação de alias e enriquecimento

A atribuição de pseudónimos e o enriquecimento são dois passos no processo de enriquecimento de dados de segurança do Google SecOps que correlacionam e adicionam dados de contexto aos registos de eventos. A atribuição de alias encontra as associações e o enriquecimento preenche os campos da UDM com esses dados associados. Os campos preenchidos através deste processo são denominados campos com alias ou campos enriquecidos.

  • Criação de alias: este é o processo de identificação e associação de diferentes nomes ou identificadores à mesma entidade. Encontra dados de contexto adicionais que descrevem um indicador. Por exemplo, a criação de pseudónimos pode associar um único hostname (como alex-macbook) a outros indicadores relacionados, como o respetivo IP addresses, MAC addresses (dos registos DHCP) ou um user ID (como alex) ao respetivo job title e employment status (dos dados do contexto do utilizador).
  • Enriquecimento: este é o processo que usa as informações recolhidas da criação de alias para adicionar contexto a um evento UDM. Por exemplo: quando chega um novo evento 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 suporta a criação de alias e o enriquecimento de vários tipos de entidades, incluindo: recursos (por exemplo, nomes de anfitriões, IPs, MACs), utilizadores, processos, metadados de hash de ficheiros, localizações geográficas e recursos da nuvem. Para mais detalhes, consulte o artigo Vista geral do enriquecimento e da criação de alias da UDM.

Reenriquecimento de eventos da UDM

  • Alterações aos dados subjacentes: depois de o sistema carregar um evento, se os dados subjacentes mudarem após o carregamento do evento, o sistema volta a processar os dados do histórico e atualiza os eventos durante um período máximo de 24 horas.

  • Atualizações do sistema de enriquecimento: se o sistema de enriquecimento atualizar os metadados de entidades ou processos, a geolocalização do IP ou os indicadores do VirusTotal, o motor de regras reavalia estes blocos 24 a 48 horas mais tarde para captar essas atualizações.
    Por exemplo: um evento às 09:03 tem entity.asset.hostname = hostnameA, mas não tem IP. Um registo de DHCP das 08:55 mostra hostnameA = IP 1.2.3.4. O motor de regras é executado às 09:10 e a regra não corresponde. O pipeline de processamento de enriquecimento correlaciona hostnameA com 1.2.3.4 para esse período, atualizando o evento UDM. Agora, a regra corresponde e o sistema cria uma deteção.

  • Dados de contexto atrasados: se enviar dados de contexto, como um hostname, por exemplo, três dias após o registo inicial, o sistema volta a enriquecer o evento UDM. As regras que procuram estes dados re-enriquecidos são executadas novamente e criam uma deteção. Esta funcionalidade garante que o sistema cria deteções mesmo quando o contexto está atrasado.

  • Alterações nos dados de enriquecimento: as alterações nos dados de enriquecimento podem fazer com que uma regra corresponda mais tarde, mesmo que não tenha correspondido inicialmente.
    Por exemplo, um evento às 09:03 tem entity.ip_geo_artifact.country_or_region = USA. O motor de regras é executado às 09:10, consulta o período das 09:00 às 10:00 e a regra não corresponde. Mais tarde, o reprocessamento do enriquecimento atualiza a geolocalização para o Canadá. Quando a regra é executada novamente, corresponde e o sistema cria uma deteção.

Processamento do gráfico de contexto de entidades

O sistema gera e adiciona informações do gráfico de contexto de entidades (ECG) aos dados de registo para fornecer contexto, por exemplo, indicadores de comprometimento (IOCs) ou dados de contexto de ativos. Uma vez que o pipeline de ECG depende principalmente do processamento em lote, as informações de contexto das entidades são frequentemente atualizadas apenas depois de uma execução de regra criar uma deteção.

Caças retro

Quando executa uma regra em dados do histórico através de uma análise retrospetiva, o sistema só cria a deteção após a conclusão do processo de análise retrospetiva. Este processo pode demorar muito tempo, o que causa um atraso na deteção.

Exemplo de um processo de atualização retroativo:

  1. Evento inicial: um evento chega às 13:00 com ip_address = 10.0.0.5. Neste momento, o valor hostname é desconhecido.
  2. Chegada da origem de criação de alias: às 14:30 (mais de uma hora depois), chega um registo DHCP para as 13:00, associando 10.0.0.5 a workstation-123.
  3. Enriquecimento retroativo: o sistema de pseudónimos processa esta nova associação. Atualiza retroativamente o evento da UDM das 13:00, enriquecendo o campo $udm.event.principal.hostname anteriormente vazio com o valor workstation-123.
  4. Deteção: as execuções de regras subsequentes (execuções de limpeza) veem agora o valor enriquecido (workstation-123) e podem acionar deteções que foram perdidas anteriormente.

Nota: não é possível distinguir as métricas de monitorização da latência para regras de deteção em direto das regras de deteção de retrocaça. Para evitar distorcer as métricas de monitorização da latência de deteção, não use uma regra em direto para simular uma regra de retrocaça. Como prática recomendada, crie uma regra de deteção dedicada e execute-a como uma regra de retrocaça.

Listas de referências

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

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

  • Envie dados de registo para o Google SecOps assim que o evento ocorrer.
  • Reveja as regras de auditoria para determinar se deve usar dados de não existência ou enriquecidos com contexto.
  • Configure uma frequência de execução mais pequena.

Regras de não existência

O sistema aguarda, 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 têm tempo para chegar.

Atrasos no tratamento de dados

O sistema pode continuar a processar dados mesmo após a criação de uma deteção inicial, o que pode levar a deteções novas ou atualizadas. Para obter detalhes, consulte o artigo Quando são acionadas as repetições de regras.

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