Monitorar a performance das regras

Compatível com:

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 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, é necessário 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 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 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.
  • Retrocaça: 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 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:

  1. Acesse Painéis.

  2. Pesquise Rule Observability.

  3. 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ê:

  1. Acesse Detecções > Alertas e IOCs.
  2. Na guia Alertas, encontre a coluna Tipo de detecção.
  3. Pesquise alertas com um ícone de lâmpada amarela.
  4. Passe o cursor sobre o ícone para ver se a detecção foi acionada por um dos seguintes:
    • Reprocessamento de regras: gerado devido a uma repetição de regras
    • Retrocaça: acionada manualmente por um usuário.
    • Dados de eventos atrasados: gerados devido a uma repetição de regras especificamente por causa de dados que chegaram tarde.

Para uma descrição mais detalhada das detecções criadas devido ao reprocessamento de regras, consulte Repetições de regras.

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

  1. Acesse Detecções > Alertas e IOCs.

  2. 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.

  3. 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 (confira a coluna Nome da regra).

Examinar metadados

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

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 na janela de programação padrão.
Informações empíricas para MTTD.

REPROCESSING


Gerado devido a uma repetição de regras (por exemplo, dados que chegam tarde).
Representa risco operacional e precisa ser contabilizado nos relatórios.

RETROHUNT


Gerado por uma execução histórica de retrocaça.
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 as 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, e não à latência de execução da regra. 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 delas, 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.