Entender o agendamento da execução de regras

Compatível com:

Este documento é destinado a analistas, engenheiros e administradores de plataforma de segurança 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 lidam com registros que chegam atrasados e o enriquecimento de contexto.

Casos de uso comuns

A escolha ou o entendimento 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 ingere e enriqueça os registros relacionados antes da execução, melhorando a precisão dos alertas para compliance 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 + ajuste): a execução inicial da lógica de detecção em um bloco de tempo de evento. O atraso no ajuste representa o valor adicionado para contabilizar dados que chegam atrasados.
  • Atraso no ajuste de contas: o período de buffer adicionado à execução principal para permitir que os registros atrasados sejam processados 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 períodos processados 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 do recurso, identidade do usuário ou indicadores de inteligência contra ameaças) durante o processamento do pipeline.
  • Atraso na 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 a função do IAM de administrador da API Chronicle (roles/chronicle.admin) ou editor da API Chronicle (roles/chronicle.editor) para modificar programações de regras ou a função de leitor da API Chronicle (roles/chronicle.viewer) para inspecionar programações no painel de regras.
  • Verificação do ambiente: confira se os registros estão mapeados para o modelo de dados unificado (UDM) para oferecer suporte a agregações de intervalo programadas.

Como o agendamento de regras funciona

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 continuamente as regras padrão e de evento único em janelas (mesmo com janelas de correspondência maiores que 48 horas) 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.
  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 múltiplos eventos em blocos em lote de tempo de evento (como intervalos de 10 minutos ou 1 hora ou match_window / 10 para períodos maiores que 48 horas). As regras de múltiplos eventos exigem um período para agregar e correlacionar eventos em várias fontes.

Configuração padrão de programaçã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 no período 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 com 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 consultas padrão.
Regra de vários eventos (window <= 48h) A cada 1 hora (ou A cada 10 minutos, personalizável para intervalos menores que 1 hora) 1 a 2 horas após a chegada Sim. Inclui uma execução de ajuste automatizada de 4 horas e uma execução de ajuste 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 de acordo com a janela de correspondência (match_window / 10) Não.Avalia dados atrasados e enriquecidos durante execuções sobrepostas subsequentes.

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

Para evitar detecções perdidas causadas por latência de ingestão ou metadados de enriquecimento que chegam tarde (como tags de recursos ou aliases de usuários), o sistema executa automaticamente processos de ajuste 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 ajuste (4 horas): reavalia o bloco de tempo aproximadamente 4 horas após a execução inicial para capturar registros que chegam tarde. Essa etapa não espera o enriquecimento total 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 aprimoramento de dados são concluídos.

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

Programações personalizáveis

Para regras personalizadas com vários eventos e 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 períodos 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 conhecida de ingestão da origem de registros.
  • Integridade do enriquecimento: estenda o processamento de ajuste para 30 horas e garanta que todas as junções de metadados externos sejam concluídas antes da avaliação final.

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

Visibilidade de 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 de uma regra personalizada de vários eventos, consulte Configurar programações personalizadas para regras.

Indicadores de origem da 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 ajuste automatizadas, pipelines de reprocessamento ou retrocaças.

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

A frequência de execução da regra afeta diretamente a velocidade das detecções. Ao criar e monitorar regras, lembre-se dos seguintes comportamentos:

  • Agendamentos por hora: são executados 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 faz 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 ajuste se a ingestão de registros foi atrasada ou se o enriquecimento de contexto (como a resolução do gráfico de entidades) foi 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 aceitam personalização de intervalo. As regras selecionadas seguem cronogramas fixos 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 você não puder selecionar a execução quase em tempo real, sua 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 ver etapas detalhadas de solução de problemas, consulte Entender os atrasos na detecção de regras.

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.