Otimizar a performance de detecção e geração de relatórios

Compatível com:

Google SecOps SIEM

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 rastrear três componentes principais:

• Latência de ingestão de registros (criação de registros para ingestão de dados)
• Latência do processamento de regras (ingestão de dados até a criação da detecção)
• Latência de confirmação de caso (criação de detecção até atribuição ao analista)

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 o momento em que o ocorrência de segurança ocorreu no sistema de origem (metadata.event_timestamp) e quando o registro foi ingerido e analisado com sucesso no Google Security Operations (metadata.ingested_time).

Fatores contribuintes:

• 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 o momento em que o mecanismo de detecção cria um alerta (detection.creation_time). Esse componente é muito afetado pela configuração da regra YARA-L.

Fatores contribuintes:

• Frequência de execução da regra:quase em tempo real (melhor), 10 minutos, 1 hora ou 24 horas. Quanto maior a frequência, maior a latência mínima de processamento. Para mais informações, consulte Definir a frequência de execução.
• Tipo e complexidade da regra:as regras de vários eventos exigem um período 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 causam 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 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 um valor de referência para suas fontes de registros.

É possível exportar esses resultados para um painel e visualizar as 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 ao responder a um alerta gerado.

Observação: em alguns relatórios avançados do SOAR, como o painel Análise de performance: tempos de tratamento, o MTTD quantifica o tempo médio desde a criação do caso até a atribuição a um usuário, o que é mais próximo do tempo médio para reconhecimento (MTTA). A definição padrão de MTTD se refere ao tempo decorrido entre o evento inicial e a criação da detecção.

• Para reduzir a latência de confirmação de caso, otimize o encaminhamento, 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 etapa 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 que contribuem, 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.