Configurar programações personalizadas para regras

Compatível com:

Este documento é destinado a analistas de segurança, engenheiros e administradores de plataformas que querem configurar e gerenciar como o Google Security Operations programa as execuções de regras. Ele explica como ajustar a frequência de execução, configurar atrasos de liquidação e gerenciar cronogramas de correção para regras personalizadas de vários eventos.

Ao seguir o processo descrito neste documento, você terá controle preciso sobre a latência de detecção e a integridade dos dados. A conclusão bem-sucedida garante que suas detecções sejam oportunas e precisas, reduzindo os falsos negativos causados por atrasos na ingestão e garantindo operações de segurança consistentes.

As programações personalizáveis oferecem transparência e controle sobre como as regras de vários eventos são executadas no Google Security Operations. Algumas regras de vários eventos podem exigir um período de buffer para agregar dados com precisão. Esse método permite definir esse período em vez de depender dos padrões do sistema.

Casos de uso comuns

As programações personalizáveis permitem ajustar os parâmetros de execução para corresponder a metas operacionais específicas:

  • Correlação de janela curta: execute regras de vários eventos com janelas de correspondência com menos de 60 minutos em uma frequência de 10 minutos (em vez de esperar o intervalo padrão de 1 hora) para detectar ameaças sensíveis ao tempo, como ataques de força bruta, mais rapidamente.
  • Compensação da latência de ingestão: configure um atraso de liquidação (T + deslocamento) para fontes de registro com atrasos de entrega conhecidos, garantindo que a execução principal inclua todos os eventos esperados.
  • Garantia da integridade do contexto: ative a opção Garantir a integridade do enriquecimento para regras forenses e de conformidade não críticas que exigem a resolução completa de metadados de entidades e recursos antes da avaliação final.

Terminologia importante

  • Execução principal (T + deslocamento): a execução inicial da lógica de regra em dados recebidos. O atraso de liquidação representa o deslocamento adicionado para contabilizar dados recebidos com atraso.
  • Atraso de liquidação: o período de buffer adicionado à execução principal para permitir que os registros recebidos com atraso sejam processados antes do início da avaliação da regra.
  • Execução de correção: uma reavaliação em segundo plano da mesma janela de tempo para capturar registros ou dados de enriquecimento que chegaram após a execução principal.
  • Enriquecimento: metadados externos (como tags de recursos ou aliases de usuários) adicionados aos registros durante o processamento.

Antes de começar

Antes de tentar modificar ou automatizar as programações de regras, verifique se o ambiente e a conta atendem aos requisitos de segurança e do sistema necessários. Ao validar esses pré-requisitos, você evita erros de implantação e garante que a lógica de detecção esteja alinhada às políticas do Identity and Access Management da sua organização.

  • Permissões: para modificar as programações de regras, é necessário ter as seguintes permissões do IAM:

    • chronicle.ruleDeployments.update para uso da API para atualizações de programação individuais.

    • chronicle.rules.modifyRules para atualizações em lote da API e uso da UI.

    Se você usar papéis predefinidos do IAM, como o admin da API do Chronicle (roles/chronicle.admin) ou o editor da API do Chronicle (roles/chronicle.editor), essas permissões serão incluídas automaticamente.

  • Verificação do ambiente:

    • Tipo de regra: as programações personalizáveis se aplicam apenas a regras de vários eventos. As regras de evento único (incluindo regras padrão, com janela e baseadas em referência) são avaliadas quase em tempo real e não podem ser personalizadas. As regras selecionadas usam programações fixas do sistema e são excluídas.
    • match window: as regras de vários eventos com uma janela match maior que 48 horas são executadas em uma frequência atribuída automaticamente de match_window / 10 e não podem ser personalizadas.
    • Migração: a migração de uma programação legada para uma programação personalizável é um processo unidirecional e não pode ser revertido.

Configurar a programação de uma regra de vários eventos

Para configurar a programação de uma regra de vários eventos, siga estas etapas:

  1. No Google SecOps, acesse Detecção > Regras e detecções.
  2. Clique em Painel de regras.
  3. Localize sua regra na tabela de regras, clique em Mais more_vert e selecione Executar programação.
  4. Na guia Programação de regras, configure a seção Execução principal :
    1. Na lista Definir frequência, selecione a frequência com que a regra é executada (por exemplo, A cada 10 minutos ou A cada 1 hora).
    2. (Opcional) Para contabilizar dados recebidos com atraso, ative a opção Atraso de liquidação.
    3. No campo Atraso, insira o valor do atraso e selecione a unidade de tempo (Minutos ou Horas) no menu Unidade.
  5. Na seção Execução de correção, (opcional) ative a opção Garantir a integridade do enriquecimento.
    • Falha prevista: os alertas podem aparecer significativamente mais tarde do que o carimbo de data/hora do evento se as fontes de contexto externas demorarem para processar.
    • Etapa corretiva: use isso apenas para regras forenses e de conformidade não críticas em que a fidelidade do contexto é priorizada em relação à velocidade de alerta imediata.
  6. Revise a linha do tempo de execução em Execução principal e Execução de correção:
    • Execução principal:o sistema executa a lógica de regra após o atraso de liquidação especificado para dados recebidos com atraso.
    • Execução de correção 1:o sistema faz uma nova verificação automática da janela 4 horas após a execução principal para capturar dados perdidos ou atrasados. Se você ativar a opção Garantir a integridade do enriquecimento, essa execução também vai aguardar o processamento dos dados de enriquecimento associados.
    • Execução de correção 2:aparece apenas quando você ativa a opção Garantir a integridade do enriquecimento. O sistema realiza uma verificação final 30 horas após a execução principal para fornecer a máxima fidelidade de dados.
  7. Clique em Salvar.

Solução de problemas

Investigue problemas de programação revisando o tempo de avaliação e a configuração de regras. Embora a plataforma automatize a maioria das tarefas de programação, determinadas configurações ou atrasos de dados podem afetar o momento em que as detecções aparecem.

As detecções só aparecem em execuções de correção

Se uma detecção não aparecer durante a execução principal (T), mas aparecer em uma execução de correção (T + 4h ou T + 30h), verifique o seguinte:

  • Latência de ingestão:verifique se a origem do registro tem um atraso. Se os registros chegarem 15 minutos após a ocorrência do evento, uma programação de primeira execução de 10 minutos vai perdê-los. As execuções de correção capturam essas chegadas tardias.
  • Enriquecimento de contexto:confirme se a regra depende de metadados externos, como tags de recursos ou aliases de usuários. Se o processo de enriquecimento levar mais tempo do que a janela de execução principal, a detecção só vai aparecer depois que o sistema concluir o enriquecimento em uma execução de correção posterior.

Opções personalizáveis ausentes

Se a guia Programação de regras não mostrar opções de personalização ou o menu estiver esmaecido:

  • Verifique o tipo de regra:as programações personalizáveis se aplicam apenas a regras de vários eventos. As regras de evento único (incluindo regras padrão, com janela e baseadas em referência) são avaliadas quase em tempo real e não oferecem suporte a programações personalizadas.
  • Verifique a janela match: as regras de vários eventos com uma janela match maior que 48 horas são executadas em uma frequência atribuída automaticamente de match_window / 10 e não podem ser personalizadas.
  • Identifique regras selecionadas:não é possível modificar a programação de regras selecionadas. Se você inspecionar uma regra selecionada, a UI vai mostrar a mensagem: Multi-event curated rules use a legacy schedule.

Atraso inesperado em alertas de primeira execução

Se uma detecção chegar mais tarde do que o intervalo programado:

  • Período de inicialização:as regras novas ou modificadas recentemente exigem um período de inicialização de uma hora. As detecções não aparecem até que a plataforma conclua essa configuração inicial e comece o primeiro ciclo programado.
  • Tempos de espera de enriquecimento:se você ativar a opção Garantir a integridade do enriquecimento, o sistema poderá ajustar dinamicamente o tempo para aguardar a conclusão dos processos de enriquecimento de dados. Embora esse processo evite detecções perdidas, ele pode fazer com que a detecção inicial chegue mais tarde do que o carimbo de data/hora T exato.

As medições de MTTD parecem altas

As medições de MTTD incluem o período de buffer necessário para a integridade dos dados.

  • Revise o buffer: para uma programação de uma hora, o sistema avalia os eventos de uma a duas horas após a chegada.
  • Otimize para velocidade: se você precisar de uma latência menor, configure a regra para uma programação de 10 minutos (para janelas de correspondência com menos de 60 minutos) ou converta a lógica de detecção em uma regra de evento único executada quase em tempo real se a agregação de eventos não for necessária.

Limitações

  • Apenas regras de vários eventos: esse recurso não está disponível para regras de evento único. As regras de evento único (incluindo regras padrão, com janela e baseadas em referência) são avaliadas quase em tempo real.
  • Apenas regras personalizadas: as regras selecionadas usam programações fixas que não podem ser modificadas. Se você visualizar uma regra selecionada, o sistema vai mostrar a mensagem: Multi-event curated rules use a legacy schedule. Se você visualizar uma regra personalizada legada, o sistema vai mostrar: Your Multi-Event rule uses a legacy schedule.

Correção de erros

Erro Problema Corrigir
Faltam opções A guia "Programação de regras" está esmaecida ou as opções estão ausentes. Verifique se a regra é uma regra personalizada de vários eventos e se a janela de correspondência é de 48 horas ou menos. As regras selecionadas e as regras de evento único não podem ser personalizadas.
Intervalos sem suporte Não é possível selecionar o streaming quase em tempo real. As regras de vários eventos que exigem correlação entre eventos ou regras que usam agregações (como count ou sum) exigem o mecanismo de consulta em lote programado.
Alertas atrasados As detecções chegam mais tarde do que o intervalo programado. Verifique se a opção Garantir a integridade do enriquecimento está ativada. O sistema pode estar aguardando o processamento de metadados.
Somente alertas de correção As detecções nunca aparecem na execução principal (T). Verifique a latência de ingestão de registros. Se os registros chegarem com 15 minutos de atraso, mas o atraso de liquidação for de 10 minutos, aumente o atraso de liquidação.

Validação e teste

Para verificar se a programação está funcionando conforme o esperado, siga estas etapas:

  1. No Google SecOps, acesse Detecção > Regras e detecções e selecione Painel de regras.
  2. Selecione sua regra e acesse a guia Detecções.
  3. Verifique a coluna Tipo de detecção e filtre por para verificar se as execuções de correção estão capturando dados que a execução principal perdeu. Em seguida, ajuste o atraso de liquidação de acordo.

A seguir

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