Optimiza el rendimiento de la detección y la generación de informes

Compatible con:

En este documento, se describe cómo optimizar el rendimiento de la detección y la generación de informes.

Latencia total de detección

En el caso de un centro de operaciones de seguridad (SOC), el tiempo promedio total de detección (MTTD) es la suma de las demoras en toda la canalización de seguridad. Para medir y reducir con precisión el MTTD, debes hacer un seguimiento de tres componentes principales:

Latencia de transferencia de registros (creación de registros a transferencia de datos)

La latencia de la transferencia de registros es el tiempo transcurrido entre el momento en que ocurrió el evento de seguridad en el sistema de origen (metadata.event_timestamp) y el momento en que el registro se transfirió y analizó correctamente en Google Security Operations (metadata.ingested_time).

Factores contribuyentes:

  • Problemas del recopilador o del retransmisor (por ejemplo, registros pendientes o limitación de la red)
  • Problemas de análisis de la fuente de registro (por ejemplo, retrasos en la normalización del UDM)

Para reducir la latencia de la transferencia de registros, haz lo siguiente:

  • Supervisa el estado de las fuentes de registros y optimiza la configuración del recopilador o del reenvío.
  • Para supervisar el delta, en YARA-L o Data Lake, compara las marcas de tiempo del UDM: metadata.ingested_timestamp frente a metadata.event_timestamp.

Latencia de procesamiento de reglas (desde la transferencia de datos hasta la creación de la detección)

La latencia del procesamiento de reglas es el tiempo transcurrido entre la transferencia de datos y el momento en que el motor de detección crea correctamente una alerta (detection.creation_time). Este componente se ve muy afectado por la configuración de tus reglas de YARA-L.

Factores que contribuyen:

  • Frecuencia de ejecución de la regla: En tiempo real (mejor), 10 minutos, 1 hora o 24 horas. Cuanto mayor sea la frecuencia, mayor será la latencia de procesamiento mínima. Para obtener más información, consulta Cómo establecer la frecuencia de ejecución.
  • Tipo y complejidad de la regla: Las reglas de varios eventos requieren una ventana de coincidencia para procesarse por completo, lo que impone una latencia inherente. Las reglas compuestas que dependen de otras detecciones que no son en tiempo real también introducen demoras. Para obtener más información, consulta Detecciones compuestas.

Para reducir la latencia del procesamiento de reglas, haz lo siguiente:

  • Usa reglas de un solo evento que se ejecuten casi en tiempo real siempre que sea posible.
  • Para las reglas de múltiples eventos, establece el tamaño de ventana más pequeño posible.

Para obtener más información, consulta Ejemplos de consultas de YARA-L 2.0 para paneles.

Regla de YARA-L para supervisar la latencia del procesamiento de reglas

La siguiente regla de YARA-L identifica las instancias en las que la diferencia entre el momento en que se transfirió un registro y el momento en que se creó la detección supera un umbral específico. Usa la regla para identificar cuellos de botella en el rendimiento de tu canalización de detección.

Implementa esta regla en tu entorno de pruebas para establecer una referencia de tus fuentes de registros.

Puedes exportar estos resultados a un panel para visualizar las tendencias de latencia en diferentes tipos de registros.

La regla compara el metadata.event_timestamp (cuándo ocurrió la actividad) con el metadata.ingested_time (cuándo recibió el registro el equipo de SecOps de Google). 

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
}

Latencia de confirmación del caso (desde la creación de la detección hasta la asignación del analista)

Esta sección no es relevante para los clientes que usan la plataforma independiente de Google SecOps SIEM.

La latencia de confirmación de casos es el tiempo transcurrido entre la detección que crea una alerta y la confirmación de la alerta por parte de un analista para la clasificación en el componente de SOAR.

La métrica del tiempo medio de confirmación (MTTA) hace un seguimiento específico de la eficiencia del equipo del SOC para responder a una alerta generada.

  • Para reducir la latencia en el reconocimiento de casos, optimiza el enrutamiento, el ajuste y la automatización de alertas (por ejemplo, usa guías para la asignación o el enriquecimiento automáticos) para trasladar rápidamente la alerta a la etapa de clasificación.

¿Qué sigue?

  • Para obtener información sobre cómo las repeticiones de reglas (también llamadas ejecuciones de limpieza) administran los datos que llegan tarde y las actualizaciones de contexto, y cómo esto afecta las métricas de MTTD, consulta Información sobre las repeticiones de reglas y el MTTD.
  • Para obtener más información sobre las demoras en la detección de reglas en Google SecOps, los factores que contribuyen a ellas, la solución de problemas y las técnicas para reducir las demoras, consulta Información sobre las demoras en la detección de reglas.

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.