Configurar programações personalizadas para regras
Este documento é destinado a administradores de plataforma e analistas de SOC que querem configurar e resolver problemas de programações personalizáveis para regras de vários eventos. Ele explica como definir programações de processamento e executar verificações extras para incluir dados atrasados.
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. As regras de vários eventos exigem um período de buffer para agregar dados com precisão. Com esse método, você define esse período em vez de depender dos padrões do sistema.
Casos de uso comuns
Use programações personalizáveis para alinhar a velocidade de detecção com a disponibilidade e integridade dos dados.
Monitoramento de contas inativas com base na compliance
Situação: você monitora contas que não fazem login há 30 dias para atender a um requisito de auditoria.
- Objetivo: priorizar a integridade do enriquecimento.
- Valor: garante a máxima fidelidade dos dados ao ativar a opção Garantir a integridade do enriquecimento, que aguarda o processamento de todos os registros e metadados globais antes da avaliação final.
Segregação de dados de MSSP multilocatário
Cenário: como um provedor de serviços de segurança gerenciados (MSSP, na sigla em inglês), você gerencia dados de vários clientes com diferentes velocidades de ingestão de registros.
- Objetivo: gerenciar diferentes velocidades de ingestão em vários ambientes de clientes.
- Valor: reduz os alertas de "falso negativo". Ao aguardar de uma a duas horas para a primeira execução, o sistema reduz o número de detecções que aparecem apenas durante as execuções de ajuste, proporcionando uma experiência mais consistente para os analistas do SOC que monitoram o painel.
Terminologia importante
- Primeira execução (𝑇 + ajuste): a execução inicial da lógica da regra. O valor de ajuste representa o atraso adicionado para considerar os dados que chegam tarde.
- Execução de ajuste: uma reavaliação em segundo plano da mesma janela de tempo para capturar registros ou dados de enriquecimento que chegaram após a primeira execução.
- 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 do 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
Obrigatório: para modificar programações de regras, você precisa ter um papel do IAM que conceda a seguinte ação:
detection:ModifyRuleSchedule
Papéis predefinidos:
roles/detectionEngine.adminroles/detectionEngine.editor
Verificação do ambiente
- Tipo de regra: os programações personalizáveis se aplicam apenas a regras de vários eventos. As regras de evento único e selecionadas são excluídas.
- Janela de
match: regras com uma janela dematchmaior que 48 horas são restritas a uma frequência de execução diária. - Migração: migrar 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 sua regra, clique em Mais more_vert e selecione Executar programação.
- Na guia Programação da regra, selecione um valor para o campo Programação da primeira execução e escolha a frequência com que a regra é executada.
- Ative a opção Ajustar a primeira execução para dados que chegam atrasados.
- Falha prevista: a primeira execução ainda pode perder registros se o deslocamento for menor que a latência de ingestão real da sua fonte.
- Etapa corretiva: aumente o ajuste ou confie nas execuções de ajuste para a validação final.
- Ative a opção Garantir a integridade do enriquecimento.
- Falha prevista: os alertas podem aparecer muito depois do carimbo de data/hora do evento.
- Etapa corretiva: use apenas para regras de compliance não críticas em que a acurácia é mais importante do que a velocidade.
- Revise a prévia da programação da regra para entender o cronograma de execução:
- Primeira execução (𝑇 + ajuste): o sistema executa a lógica da regra após o atraso especificado para dados que chegam tarde.
- Execução de ajuste 1 (𝑇 + 4 horas): o sistema faz uma nova verificação da janela 4 horas após a primeira execução 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 de todos os dados de enriquecimento associados.
- Execução de ajuste 2 (𝑇 + 30 horas): essa execução só aparece se você ativar a opção Garantir a integridade do enriquecimento. O sistema realiza uma verificação final 30 horas após a primeira execução para oferecer a máxima fidelidade de dados.
- Clique em Salvar.
Entender a visualização da programação
A prévia da programação identifica os marcos específicos da sua lógica de detecção. Use essas execuções em segundo plano para medir com precisão o tempo médio até a detecção (MTTD) e verificar a integridade dos alertas.
Primeira execução (𝑇 + deslocamento)
A primeira execução identifica ameaças o mais rápido possível. Como alguns dados ainda podem estar em trânsito ou passando por enriquecimento, as detecções na primeira execução podem chegar mais tarde do que o esperado.
Execuções de ajuste
As reconciliações proativas reavaliam a janela de tempo. Essas execuções permitem que a plataforma capture o seguinte:
- Registros que chegam tarde: dados que chegaram à plataforma após a conclusão da primeira execução.
- Contexto de enriquecimento: metadados, como identidades de recursos ou pseudônimos de usuários, que exigiam processamento em segundo plano adicional.
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.
Limitações
- Somente regras de vários eventos: esse recurso não está disponível para regras de evento único.
- Somente regras personalizadas: as regras selecionadas usam programações fixas que não podem ser modificadas. Se você acessar uma regra selecionada, o sistema vai mostrar a mensagem:
Curated rules use 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 estão ausentes. | Verifique se a regra é personalizada para vários eventos e se a janela de correspondência tem menos de 48 horas. |
| 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 primeira execução (𝑇). |
Clique em Latência de ingestão para verificar. Se os registros chegarem com 15 minutos de atraso, mas seu ajuste for de 10 minutos, aumente o ajuste da primeira execução. |
As detecções só aparecem em execuções de ajuste.
Se uma detecção não aparecer durante a primeira execução (𝑇), mas aparecer em uma execução de ajuste (𝑇+4$ ou 𝑇+30$), 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 o evento, uma programação de primeira execução de 10 minutos não os incluirá. As execuções de ajuste capturam esses dados atrasados.
- 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 da primeira execução, a detecção só vai aparecer depois que o sistema concluir o enriquecimento em uma execução posterior.
Faltam opções personalizáveis
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:os agendamentos personalizáveis se aplicam apenas a regras de vários eventos. As regras de evento único usam o mecanismo contínuo (em tempo real) e não são compatíveis com programações personalizadas.
- Verifique a janela de
match:as regras com uma janela dematchmaior que 48 horas são restritas a uma frequência de execução diária e não podem ser personalizadas. - Identificar regras selecionadas:não é possível modificar a programação das regras selecionadas. Procure a mensagem
Curated rules uses a legacy schedulepara confirmar se a regra é de um sistema protegido.
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 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 aprimoramento:se você ativar a opção Garantir a integridade do aprimoramento, o sistema poderá ajustar dinamicamente o tempo para aguardar a conclusão dos processos de aprimoramento 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 exato de
𝑇.
As medições de MTTD parecem altas
As medições de MTTD incluem o período de estabilização 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.
- Otimize para velocidade: se você precisar de uma latência menor, faça a transição da regra para uma programação em tempo real. Observação: isso pode aumentar o número de detecções que dependem de execuções de ajuste para ter precisão total.
Identificar fontes de detecção
O Google SecOps usa indicadores visuais para ajudar você a distinguir entre as detecções iniciais e as que aparecem durante as novas execuções em segundo plano.
Indicadores de detecção
Na coluna Tipo de detecção, o identifica detecções de execuções de ajuste, reprocessamento ou retrocaças.
- Se você vir esse ícone, a detecção ocorreu durante uma execução de ajuste (
𝑇+4$ou𝑇+30$) em vez da execução inicial (𝑇). - As detecções com esse ícone geralmente indicam que a plataforma capturou a ameaça após a ingestão inicial, geralmente devido a registros atrasados ou atrasos no enriquecimento.
Verificar a integridade do alerta na página de alertas
O na página Alertas indica a origem de um alerta. Use esse indicador para verificar a origem de um alerta ao investigar uma linha do tempo.
- Os alertas sem um ícone são da primeira execução (
𝑇) ou do mecanismo contínuo. - Os alertas com indicam que o sistema identificou a ameaça durante uma verificação de dados posterior para oferecer a máxima precisão.
Validação e teste
Para verificar se sua programação está funcionando conforme o esperado, siga estas etapas:
- Acesse o Painel de regras.
- Selecione sua regra e confira a guia Detecções.
- Filtre por para ver se as execuções de ajuste estão capturando dados que a primeira execução perdeu e ajuste os intervalos de acordo.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.