Otimizar a performance da regra

Compatível com:

Este documento descreve como otimizar a performance de detecção e geração de relatórios.

Latência total de detecção

Para uma central de operações de segurança (SOC), o tempo médio total para detecção (MTTD) é a soma dos atrasos no pipeline de segurança. Para medir e reduzir o MTTD com precisão, é necessário acompanhar três componentes principais:

Latência de ingestão de registros (criação de registros até a ingestão de dados)

A latência de ingestão de registros é o tempo decorrido entre a ocorrência do ocorrência de segurança no sistema de origem (metadata.event_timestamp) e a ingestão e análise do registro no Google Security Operations (metadata.ingested_time).

Fatores que contribuem:

  • Problemas com o coletor ou encaminhador (por exemplo, pendências ou limitação de rede).
  • Problemas de análise da origem do registro (por exemplo, atrasos na normalização da UDM).

Para reduzir a latência de ingestão de registros, faça o seguinte:

  • Monitore a integridade da origem de registros e otimize as configurações do coletor ou encaminhador.
  • Para monitorar o delta, no YARA-L ou no data lake, compare os carimbos de data/hora da UDM: metadata.ingested_timestamp e metadata.event_timestamp.

Latência de processamento de regras (ingestão de dados até a criação da detecção)

A latência de processamento de regras é o tempo decorrido entre a ingestão de dados e a criação de um alerta pelo mecanismo de detecção (detection.creation_time). Esse componente é muito afetado pela configuração da regra YARA-L.

Fatores que contribuem:

  • Frequência de execução da regra:quase em tempo real (menor latência), 10 minutos, 1 hora ou match_window / 10 (para janelas de correspondência maiores que 48 horas). Para mais informações, consulte Entender o agendamento de execução de regras.
  • Tipo e complexidade da regra:as regras de vários eventos exigem uma janela de correspondência para serem totalmente processadas, o que impõe uma latência inerente. Regras compostas que dependem de outras detecções não em tempo real também introduzem atrasos. Para mais informações, consulte Detecções compostas.

Para reduzir a latência de processamento de regras, faça o seguinte:

  • Sempre que possível, use regras de evento único executadas quase em tempo real.
  • Para regras de vários eventos, defina o menor tamanho de janela possível.

Para mais informações, consulte Exemplos de consultas YARA-L 2.0 para painéis.

Regra YARA-L para monitorar a latência de processamento de regras

A regra da YARA-L a seguir identifica instâncias em que o delta entre o momento em que um registro foi ingerido e o momento em que a detecção foi criada excede um limite específico. Use a regra para identificar gargalos de desempenho no pipeline de detecção.

Implante essa regra no ambiente de teste para definir uma linha de base para suas fontes de registros.

É possível exportar esses resultados para um painel e visualizar tendências de latência em diferentes tipos de registros.

A regra compara o metadata.event_timestamp (quando a atividade ocorreu) com o metadata.ingested_time (quando o Google SecOps recebeu o registro). 

rule rule_processing_latency_monitor {
  meta:
    author = "SecOps Engineering"
    description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
    severity = "Low"

  events:
    $event.metadata.event_timestamp.seconds = $event_ts
    $event.metadata.ingested_time.seconds = $ingest_ts
    
    // Calculate the delta in seconds
    $latency_delta = $ingest_ts - $event_ts

    // Threshold: 900 seconds (15 minutes)
    $latency_delta > 900

  match:
    $event.metadata.log_type over 1h

  outcome:
    $max_latency = max($latency_delta)
    $log_source = array_distinct($event.metadata.log_type)

  condition:
    $event
}

Latência de confirmação de caso (criação de detecção até atribuição ao analista)

Esta seção não é relevante para clientes que usam a plataforma independente do Google SecOps SIEM.

A latência de confirmação de caso é o tempo decorrido entre a detecção que cria um alerta e o reconhecimento do alerta por um analista para triagem no componente SOAR.

A métrica tempo médio para confirmação (MTTA, na sigla em inglês) rastreia especificamente a eficiência da equipe do SOC na resposta a um alerta gerado.

  • Para reduzir a latência de confirmação de caso, otimize o roteamento, o ajuste e a automação de alertas (por exemplo, usando manuais para atribuição automática ou enriquecimento) para mover rapidamente o alerta para a fase de triagem.

A seguir

  • Para saber como os replays de regras (também chamados de execuções de limpeza) gerenciam dados que chegam atrasados e atualizações de contexto, e como isso afeta as métricas de MTTD, consulte Entenda os replays de regras e o MTTD.
  • Para saber mais sobre atrasos na detecção de regras no Google SecOps, fatores contribuintes, solução de problemas e técnicas para reduzir atrasos, consulte Entender os atrasos na detecção de regras.

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