Configurar programações personalizadas para regras
Este documento é destinado a analistas, engenheiros e administradores de plataforma de segurança para configurar e gerenciar como o Google Security Operations programa as execuções de regras. Ela explica como ajustar a frequência de execução, configurar atrasos de liquidação e gerenciar cronogramas de ajuste para regras personalizadas de vários eventos.
Ao seguir o processo descrito neste documento, você ganha controle preciso sobre a latência de detecção e a integridade de 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.
Os cronogramas 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
Com os cronogramas personalizáveis, você pode 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 de 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 + ajuste) para origens de registros com atrasos de entrega conhecidos, garantindo que a execução principal inclua todos os eventos esperados.
- Garantir a integridade do contexto: ative a opção Garantir a integridade do enriquecimento para regras forenses e de compliance não críticas que exigem resolução completa de metadados de entidades e recursos antes da avaliação final.
Terminologia importante
- Execução principal (T + ajuste): a execução inicial da lógica da regra em dados recebidos. 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çã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 seu ambiente e sua conta atendem aos requisitos necessários de segurança e sistema. A validação desses pré-requisitos ajuda a evitar 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 programações de regras, você precisa das seguintes permissões do IAM:
chronicle.ruleDeployments.updatepara uso da API em atualizações de programação individuais.chronicle.rules.modifyRulespara atualizações da API Batch e uso da UI.
Se você usa papéis predefinidos do IAM, como administrador da API do Chronicle (
roles/chronicle.admin) ou editor da API do Chronicle (roles/chronicle.editor), essas permissões sã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 as padrão, de 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.
- Período de
match: as regras de vários eventos com um período dematchmaior que 48 horas são executadas em uma frequência atribuída automaticamente dematch_window / 10e não podem ser personalizadas. - Migração: a migração de um agendamento legado para um 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:
- No Google SecOps, acesse Detecção > Regras e detecções.
- Clique em Painel de regras.
- Localize a regra na tabela, clique em Mais more_vert e selecione Executar programação.
- Na guia Programação da regra, configure a seção Execução principal:
- Na lista Definir frequência, selecione a frequência de execução da regra (por exemplo, A cada 10 minutos ou A cada 1 hora).
- (Opcional) Para considerar dados que chegam atrasados, ative a opção Atraso no pagamento.
- No campo Atraso, insira o valor do atraso e selecione a unidade de tempo (Minutos ou Horas) no menu Unidade.
- Na seção Execução de ajuste, ative (opcional) a opção Garantir a integridade do enriquecimento.
- Falha prevista: os alertas podem aparecer muito depois do carimbo de data/hora do evento se as fontes de contexto externas demorarem para processar.
- Etapa corretiva: use apenas para regras forenses e de compliance não críticas em que a fidelidade do contexto é priorizada em vez da velocidade de alerta imediata.
- Analise a linha do tempo da execução em Execução principal e Execução de ajuste:
- Execução principal:o sistema executa a lógica da 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 ajuste 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 oferecer a máxima fidelidade de dados.
- Clique em Salvar.
Solução de problemas
Investigue problemas de programação revisando o tempo de avaliação e a configuração da regra. Embora a plataforma automatize a maioria das tarefas de programação, algumas configurações ou atrasos nos dados podem afetar o momento em que as detecções aparecem.
As detecções só aparecem em execuções de ajuste.
Se uma detecção não aparecer durante a execução principal (T), mas aparecer em uma execução de ajuste (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 depois que o evento ocorrer, um agendamento de primeira execução de 10 minutos não vai recebê-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 ajuste posterior.
As opções personalizáveis não estão disponíveis
Se a guia Programação da regra 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 janelas e baseadas em referência) são avaliadas quase em tempo real e não aceitam programações personalizadas.
- Verifique o período de
match:as regras de vários eventos com um período dematchmaior que 48 horas são executadas em uma frequência atribuída automaticamente dematch_window / 10e não podem ser personalizadas. - Identificar regras selecionadas:não é possível modificar a programação das regras selecionadas. Se você inspecionar uma regra selecionada, a UI vai mostrar a mensagem:
Multi-event curated rules use a legacy schedule.
Atraso inesperado nos alertas da primeira execução
Se uma detecção chegar depois do intervalo programado:
- Período de inicialização:as regras novas ou modificadas recentemente precisam de 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 depois do 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.
- Analise o buffer: para uma programação de uma hora, o sistema avalia os eventos de uma a duas horas depois que eles chegam.
- Otimizar para velocidade: se você precisar de uma latência menor, configure a regra para uma programação de 10 minutos (para períodos 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
- Somente 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, de janela e baseadas em referência) são avaliadas quase em tempo real.
- Somente 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 |
|---|---|---|
| Opções ausentes | A guia "Programação de regras" está esmaecida ou as opções não aparecem. | Verifique se a regra é personalizada de vários eventos e se a janela de correspondência é de até 48 horas. As regras selecionadas e 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 programada. |
| Alertas atrasados | As detecções chegam depois do intervalo programado. | Verifique se a chave Garantir a integridade do enriquecimento está ativada. O sistema pode estar aguardando o processamento de metadados. |
| Somente alertas de ajuste | 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 sua programação está funcionando conforme o esperado, siga estas etapas:
- No Google SecOps, acesse Detecção > Regras e detecções e selecione Painel de regras.
- Selecione sua regra e acesse a guia Detecções.
- Verifique a coluna Tipo de detecção e filtre por para verificar se as execuções de ajuste estão capturando dados que a execução principal perdeu. Em seguida, ajuste o atraso de liquidação de acordo com isso.
A seguir
Para conhecer conceitos de programação e fluxos de trabalho de configuração relacionados, consulte os seguintes documentos:
- Entenda o agendamento de execução de regras: saiba como o Google SecOps mapeia as configurações de regras para mecanismos de consulta em lote programados e de streaming contínuo.
- Entenda as repetições de regras e o MTTD: saiba como as execuções de ajuste automático processam dados e atualizações de contexto que chegam atrasados para afetar as métricas de tempo médio para detecção (MTTD, na sigla em inglês).
- Entenda os atrasos na detecção de regras: diagnostique e resolva atrasos esperados e inesperados em pipelines de ingestão e processamento.
- Gerenciar regras usando o editor de regras: crie, edite e gerencie regras de detecção personalizadas no Google SecOps.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.