Analisar a eficácia e a eficiência das regras

Compatível com:

Google SecOps SIEM

Este guia é destinado a engenheiros de segurança que criam, implantam e monitoram regras no Google Security Operations. Ele explica como monitorar regras para garantir que elas estejam funcionando conforme o esperado e não consumam recursos em excesso usando os dados disponíveis na sua instância do Google SecOps. Esses dados ajudam a depurar detecções atrasadas, entender o impacto dos dados de enriquecimento que chegam tarde nas regras e identificar quais regras têm o maior tempo médio para detecção (MTTD).

Este guia fornece documentação sobre as seguintes tarefas:

Como avaliar uma regra durante o lançamento inicial, receber alertas e verificar o painel de regras para monitorar a integridade dela.
Como identificar a causa de atrasos na detecção (por exemplo, se foi devido à ingestão tardia ou à lógica ineficiente) e ajustar o relatório de tempo médio para detecção (MTTD) ou ajustar a regra com exclusões de regras adicionais.

Antes de começar

Para visualizar e modificar regras conforme descrito neste documento, você precisa ser um editor da API Chronicle. Para mais informações, consulte Papéis e permissões do Google Security Operations.

Antes de analisar a eficácia das regras no Google SecOps, é recomendável entender bem a linguagem YARA-L, as consultas YARA-L, como criar e gerenciar regras e como criar painéis:

Terminologia importante

Regras: identificam ameaças automaticamente à medida que os dados de registro são ingeridos na sua conta do Google SecOps.
Cotas: limites no volume de ingestão de dados, no número e na complexidade das consultas que podem ser executadas nos seus dados e no número e na complexidade das regras ativas na sua conta do Google SecOps.
Alertas e detecções: problemas de segurança identificados pelo Google SecOps e pela sua própria infraestrutura de segurança que exigem atenção.
Ingestão: processo de importação dos seus dados de segurança para o Google SecOps e conversão deles para UDM.
Repetições de regras: repetições automáticas de regras em dados atuais caso dados de contexto relevantes cheguem ou sejam processados mais tarde do que os dados do evento inicial.
RetroHunt: aplica novas regras aos dados atuais para identificar ameaças não descobertas anteriormente.

Como analisar regras

As seções a seguir descrevem como analisar a performance das suas regras.

Testar e avaliar regras após a implantação

Ao implantar uma regra na produção pela primeira vez, monitore-a no painel Rule Observability por 24 a 48 horas:

Acesse Painéis.
Pesquise Rule Observability.
Pesquise a nova regra na coluna Regra. O painel Rule Observability inclui estatísticas como a contagem de detecções, a latência de ingestão e o tempo entre a ingestão e a detecção.

Para garantir que a lógica da regra não esteja introduzindo atrasos artificiais antes de começar a gerar alertas de alta prioridade, use a referência de esquema para detecções. O esquema define o formato estruturado usado para monitorar alertas de segurança. Ele é otimizado para rastrear a frequência de detecção, a distribuição de riscos e a performance das regras. Para entender melhor como usar o esquema, confira os exemplos de consultas uma olhada.

Identificar o motivo do atraso no resultado da regra

Conclua as etapas a seguir para determinar se os resultados das regras estão atrasados e, em caso afirmativo, por quê:

Acesse Detecções > Alertas e IOCs.
Na guia Alertas, encontre a coluna Tipo de detecção.
Pesquise alertas com um ícone de lâmpada amarela.
Passe o cursor sobre o ícone para ver se a detecção foi acionada por um dos seguintes:
- Reprocessamento de regras: acionado manualmente por um usuário.
- RetroHunt: acionado manualmente por um usuário.
- Dados de eventos atrasados: indica se um atraso na detecção é esperado.

Filtrar alertas com base no horário de detecção

Acesse Detecções > Alertas e IOCs.
Na guia Alertas, use o elemento de filtro da coluna Horário de detecção para classificar as detecções com base no horário de chegada.
Clique no ícone de atualização na parte de cima da tabela e clique em Atualizar agora. Você pode conferir os alertas mais recentes que chegam à sua conta do Google SecOps e a regra associada a cada alerta (verifique a coluna Nome da regra).

Examinar metadados

Para ter mais informações sobre a performance das suas regras, inspecione o JSON de detecção bruto usando latencyMetrics para encontrar a diferença entre o oldestEventTime e ooldestIngestionTime.

Valores de tempo de detecção

A tabela a seguir lista os valores enumerados associados a DetectionTimingDetails:

Valor	Descrição	Impacto do MTTD
`UNSPECIFIED`	Detecção criada no período de agendamento de horários padrão.	Informações empíricas para MTTD.
`REPROCESSING`	Gerado devido a uma repetição de regra (por exemplo, dados que chegam tarde).	Representa risco operacional e precisa ser contabilizado nos relatórios.
`RETROHUNT`	Gerado por uma execução histórica do RetroHunt.	Normalmente filtrado dos relatórios padrão de MTTD.

Exemplo: metadados `latencyMetrics`

O exemplo a seguir latencyMetrics mostra a diferença de tempo entre quando um evento ocorreu (oldestEventTime versus newestEventTime) e quando o evento foi ingerido (oldestIngestionTime versus newestIngestionTime). A latência entre o evento e a ingestão na conta do Google SecOps é de cerca de 53 minutos.

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

Solução de problemas

A tabela a seguir lista alguns problemas que você pode ter com suas regras e como resolvê-los:

Problema	Resolução
O ícone de lâmpada aparece, mas a enumeração é `UNSPECIFIED.`	Esse é o comportamento normal quando o delta entre o horário do evento e o horário de ingestão excede 30 minutos. Use as métricas do Data Health Hub para investigar a origem do atraso na ingestão.
A detecção aparece tarde em relação ao horário do evento.	Verifique o `detectionTimingDetails`. Se o valor de enumeração for `REPROCESSING`, o atraso provavelmente será devido a dados de enriquecimento que chegam tarde, em vez de latência de execução de regras. Se for `UNSPECIFIED`, investigue a eficiência da lógica da regra.
Excesso de computação.	A regra provavelmente está verificando muitos dados ou tem uma lógica ineficiente. Acesse Exclusões de regras ou use o Descarregamento de filtros para ajustar a regra e restringir a pesquisa de dados.

Limitações conhecidas

Rigidez do limite:a dica visual para dados atrasados é fixa em um limite de 30 minutos e não considera janelas de latência definidas pelo usuário.
Integridade dos dados:a observabilidade das regras informa a integridade das regras, mas o monitoramento da integridade dos dados (mais próximo da ingestão) é mais eficaz para detectar problemas gerais de dados que chegam tarde.
Aplicação de cotas:embora o painel mostre o uso de recursos, ele não fornece notificações em tempo real quando as regras estão se aproximando de um limite de cota.

A seguir

Para informações sobre repetições de regras e atrasos na detecção de regras, consulte o seguinte:

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.