Entender a programação de execução de regras

Compatível com:

Este documento é destinado a analistas de segurança, engenheiros e administradores de plataformas que querem entender e gerenciar como o Google Security Operations programa as execuções de regras. Ele explica como as configurações de regras determinam a frequência de processamento, como o sistema equilibra o streaming quase em tempo real com o processamento em lote programado e como as execuções em segundo plano tratam registros e enriquecimento de contexto que chegam atrasados.

Casos de uso comuns

A escolha ou compreensão da programação certa depende da gravidade da ameaça e da complexidade da lógica:

  • Alertas de alta prioridade: detecte ameaças críticas quase em tempo real para correspondências de evento único que não exigem correlação de eventos adicional, reduzindo o tempo de permanência do invasor.
  • Correlação e relatórios complexos: use intervalos programados (como 10 minutos ou 1 hora) para regras de vários eventos que calculam contagens, somas ou janelas de correspondência deslizantes. Os intervalos programados garantem que o sistema ingira e enriqueça os registros relacionados antes da execução, melhorando a precisão dos alertas para conformidade e análise de tendências.

Terminologia importante

  • Frequência determinística: o intervalo de execução de referência que o sistema atribui automaticamente com base na janela de correspondência e no tipo de regra.
  • Execução principal (T + deslocamento): a execução inicial da lógica de detecção em um bloco de tempo de evento. O atraso de liquidação representa o deslocamento adicionado para contabilizar dados que chegam atrasados.
  • Atraso de liquidação: o período de buffer adicionado à execução principal para permitir que os registros que chegam atrasados sejam tratados antes do início da avaliação da regra.
  • Execuções de correção (reproduções de regras): execuções automatizadas em segundo plano que reavaliam janelas de tempo tratadas anteriormente para capturar registros ou dados de enriquecimento que chegaram após a execução principal.
  • Enriquecimento: o processo de adicionar contexto a um registro (como metadados de recursos, identidade do usuário ou indicadores de inteligência de ameaças) durante o tratamento do pipeline.
  • Atraso de detecção: o tempo total decorrido entre o carimbo de data/hora do evento e a criação de uma detecção.

Antes de começar

Confirme se o ambiente atende aos seguintes requisitos:

  • Permissões: você precisa ter o papel do IAM de administrador da API Chronicle (roles/chronicle.admin) ou de editor da API Chronicle (roles/chronicle.editor) para modificar as programações de regras ou o papel de visualizador da API Chronicle (roles/chronicle.viewer) para inspecionar as programações no painel de regras.
  • Verificação do ambiente: verifique se os registros estão mapeados para o modelo de dados unificado (UDM) para oferecer suporte a agregações de intervalos programados.

Como funciona a programação de regras

O Google SecOps equilibra a latência de detecção quase em tempo real com a estabilidade da plataforma em milhares de regras. A plataforma usa dois modelos de execução principais:

  1. Mecanismo de streaming: avalia regras de evento único padrão e em janela (mesmo com janelas de correspondência maiores que 48 horas) continuamente quase em tempo real (normalmente em até 5 minutos após a ingestão). Eventos que chegam atrasados e enriquecimentos retroativos são avaliados continuamente durante a execução padrão.
  2. Mecanismo de consulta programada: avalia regras complexas de evento único (com listas de referência ou tabelas de dados) quase em tempo real e regras de vários eventos 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). As regras de vários eventos exigem uma janela de tempo para agregar e correlacionar eventos em várias fontes.

Configuração de programação padrão

Quando você ativa uma regra, o Google SecOps determina automaticamente a frequência de execução padrão com base na lógica e na janela de correspondência da regra:

Tipo de regra e tamanho da janela Frequência de execução Tempo de avaliação Execuções de correção
Regra de evento único (padrão ou em janela) Tempo real Logo após a chegada (menos de 5 minutos) Não.Avalia dados atrasados e enriquecidos continuamente na execução padrão.
Regra de evento único (com listas de referência ou tabelas de dados) Quase em tempo real Logo após a chegada (menos de 5 minutos) Não.Avalia dados atrasados e enriquecidos continuamente durante a execução de consulta padrão.
Regra de vários eventos (window <= 48h) A cada 1 hora (ou A cada 10 minutos personalizável para janelas menores que 1 hora) De 1 a 2 horas após a chegada Sim. Inclui uma execução de correção automatizada de 4 horas e uma execução de correção opcional de 30 horas.
Regra de vários eventos (window > 48h) match_window / 10 (por exemplo, a cada 1 dia para uma janela de correspondência de 10 dias) Varia com base na janela de correspondência (match_window / 10) Não.Avalia dados atrasados e enriquecidos durante execuções sobrepostas subsequentes.

Execuções de correção automáticas

Para evitar detecções perdidas causadas por latência de ingestão ou metadados de enriquecimento que chegam atrasados (como tags de recursos ou aliases de usuários), o sistema realiza automaticamente execuções de correção em segundo plano para regras de vários eventos (window <= 48h):

  1. Execução inicial: executada o mais rápido possível com base no intervalo programado para expor ameaças imediatas.
  2. Primeira execução de correção (4 horas): reavalia o bloco de tempo aproximadamente 4 horas após a execução inicial para capturar registros que chegam atrasados. Essa fase não espera o enriquecimento completo dos dados.
  3. Segunda execução de correção (30 horas): (opcional) executada aproximadamente 30 horas após a execução inicial, quando todos os pipelines de contexto adicional e enriquecimento de dados forem concluídos.

Para mais informações sobre o comportamento e os cenários de correção, consulte Entender as reproduções de regras e o MTTD.

Programações personalizáveis

Para regras personalizadas de vários eventos com janela de correspondência <=48h, o Google SecOps permite personalizar os parâmetros de programação em vez de depender totalmente dos padrões do sistema:

  • Seleção de frequência: escolha frequências de execução como A cada 10 minutos (para janelas de correspondência com menos de 60 minutos) ou A cada 1 hora.
  • Atraso de liquidação: adicione um atraso de buffer (T + deslocamento) para acomodar a latência de ingestão da fonte de registro conhecida.
  • Conclusão do enriquecimento: estenda o tratamento de correção para 30 horas para garantir que todas as junções de metadados externos sejam concluídas antes da avaliação final.

Para conferir as etapas de configuração completas, consulte Configurar programações personalizadas para regras.

Visibilidade da programação no painel de regras

O painel de regras mostra a programação de execução atribuída para cada regra ativa na coluna Programação de regras. As regras inativas não mostram uma programação ativa até serem ativadas.

Para modificar a frequência de execução, adicionar atrasos de liquidação ou ajustar os tempos de espera de enriquecimento para uma regra personalizada de vários eventos, consulte Configurar programações personalizadas para regras.

Indicadores de origem de detecção

Na página Alertas e no painel de regras, a coluna Tipo de detecção indica se uma detecção foi originada de uma execução inicial ou de uma execução automatizada em segundo plano:

  • Sem ícone: a detecção foi gerada durante a execução principal (T) ou usando o mecanismo de streaming contínuo.
  • Ícone de lâmpada : a detecção foi originada de dados de eventos que chegaram com mais de 30 minutos de atraso, execuções de correção automatizadas, pipelines de reprocessamento ou retrocaças.

Considerações sobre latência e solução de problemas

A frequência de execução de regras afeta diretamente a velocidade das detecções. Considere os seguintes comportamentos ao criar e monitorar regras:

  • Programações por hora: são executadas a cada hora usando os dados mais recentes disponíveis. Nenhum buffer extra é aplicado por padrão.
  • Janelas de correspondência maiores que 48 horas: o sistema executa essas regras a uma taxa de match_window / 10 e não realiza execuções de correção.
  • Discrepâncias entre execuções: uma detecção que não é acionada na primeira execução pode ser acionada durante uma execução de correção se a ingestão de registros for atrasada ou se o enriquecimento de contexto (como a resolução do gráfico de entidades) for concluído após a avaliação inicial.
  • Opções de personalização ausentes: as regras de evento único são avaliadas quase em tempo real e não oferecem suporte à personalização de intervalos. As regras selecionadas seguem programações fixas do sistema. As regras personalizadas de vários eventos com uma janela de correspondência maior que 48 horas são executadas com uma frequência de match_window / 10 e não podem ser personalizadas.
  • Intervalos não compatíveis: se não for possível selecionar a execução quase em tempo real, a regra será de vários eventos que exigem correlação de eventos ao longo do tempo ou incluem agregações (como count ou sum), que exigem o mecanismo de consulta em lote programado.

Para conferir etapas detalhadas de solução de problemas, consulte Entender os atrasos de detecção de regras.

A seguir

Para explorar 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.