Comprende las repeticiones de reglas y el MTTD
En este documento, se explica cómo los reprocesamientos de reglas (también llamados ejecuciones de limpieza) administran los datos que llegan tarde y las actualizaciones de contexto, y cómo esto afecta las métricas de tiempo medio de detección (MTTD).
Reproducciones de reglas
Google SecOps procesa grandes volúmenes de datos de seguridad. Para garantizar detecciones precisas en las reglas que dependen de datos correlacionados o contextuales, el motor de reglas ejecuta automáticamente un proceso de repetición de reglas.
El proceso de reproducción de reglas controla dos categorías diferentes de reglas:
Reglas de un solo evento: Cuando el proceso de enriquecimiento del UDM actualiza un evento evaluado previamente, el sistema vuelve a ejecutar las reglas de un solo evento.
Reglas de varios eventos: Las reglas de varios eventos se ejecutan según un programa que tú seleccionas y procesan bloques de tiempo de eventos. Estas reglas vuelven a evaluar repetidamente el mismo período en diferentes intervalos para capturar las actualizaciones de enriquecimiento tardías, como los datos de contexto del usuario o del activo coincidentes, o un indicador de compromiso (IOC).
Por ejemplo, una regla podría ejecutarse al menos dos o tres veces (entre 5 y 8 horas después, y de nuevo entre 24 y 48 horas después) para tener en cuenta los datos de eventos y de contexto que llegan tarde.
Activadores de repetición de reglas
El sistema vuelve a evaluar (vuelve a ejecutar) las reglas cuando llegan datos de contexto pertinentes o cuando los datos de contexto se procesan más tarde que los datos del evento inicial.
Estos son algunos de los motivos comunes por los que se repiten los videos:
Datos de enriquecimiento que llegan tarde: Las canalizaciones de enriquecimiento de datos, como el gráfico de contexto de entidades (ECG), suelen procesar datos en lotes. Cuando un evento de UDM llega antes que sus datos contextuales relacionados (como la información del recurso o el contexto del usuario), es posible que la ejecución inicial de la regla no detecte nada.
Actualizaciones retroactivas del enriquecimiento del UDM: Las reglas que usan campos con alias (campos enriquecidos) en su lógica de detección, como
$udm.event.principal.hostname, pueden activar repeticiones cuando se retrasan los datos de origen (por ejemplo, los registros DHCP). Esta llegada tardía actualiza de forma retroactiva esos valores de campo. Las repeticiones de reglas posteriores usan estos valores recién enriquecidos, lo que podría activar una detección que se había omitido anteriormente.
Impacto en las métricas de tiempo
Cuando una detección resulta de una reproducción de regla, usamos la siguiente terminología:
- La ventana de detección o la marca de tiempo del evento de la alerta hacen referencia al momento de la actividad maliciosa original.
- La fecha de creación es la fecha y hora en que el sistema crea la detección, que puede ser mucho más tarde, a veces horas o días después.
- La latencia de detección es la diferencia de tiempo entre la marca de tiempo del evento y la fecha de creación de la detección.
El re-enriquecimiento debido a datos que llegan tarde o la latencia con una actualización de la fuente de contexto, como el gráfico de contexto de entidades (ECG), suelen causar una latencia de detección alta.
Esta diferencia de tiempo puede hacer que una detección parezca "tardía" o "demorada", lo que puede confundir a los analistas y distorsionar las métricas de rendimiento, como el MTTD.
| Componente de métrica | Fuente de la hora | Cómo afectan las repeticiones al MTTD |
|---|---|---|
| Ventana de detección / Marca de tiempo del evento | Fecha y hora en que ocurrió el evento de seguridad original. | Esto sigue siendo preciso en relación con la hora del evento. |
| Hora de detección / Hora de creación | Fecha y hora en que el motor emitió la detección. | Esta hora aparece "tarde" o "demorada" en relación con la marca de tiempo del evento porque se basa en una ejecución secundaria (de repetición) que incorpora datos de enriquecimiento tardíos. Este delta afecta negativamente el cálculo del MTTD. |
Prácticas recomendadas para medir el MTTD
El MTTD cuantifica el tiempo transcurrido desde la vulneración inicial hasta la detección efectiva de la amenaza. Cuando analices las detecciones activadas por las repeticiones de reglas, aplica las siguientes prácticas recomendadas para mantener métricas de MTTD precisas.
Google SecOps proporciona varias métricas que los usuarios pueden consultar para medir el MTTD con precisión. Para obtener detalles sobre estas métricas, consulta la página de ejemplos de consultas de YARA-L 2.0 para paneles.
Un ícono de en la columna Tipo de detección identifica las detecciones de ejecuciones de reprocesamiento o de retrobúsquedas. Este ícono también aparece en la página Alertas de Google SecOps.
Prioriza los sistemas de detección en tiempo real
Para obtener las detecciones más rápidas, usa reglas de eventos únicos. Estas reglas se ejecutan casi en tiempo real, por lo general, con una demora de menos de 5 minutos.
Esto también admite un uso más integral de las detecciones compuestas.
Ten en cuenta la reproducción de reglas en las reglas de varios eventos
Las reglas de varios eventos generan inherentemente una latencia más alta debido a su frecuencia de ejecución programada. Cuando midas el MTTD para las detecciones de reglas de varios eventos, ten en cuenta que las repeticiones de reglas automatizadas aumentan la cobertura y la precisión. Estos reintentos suelen detectar amenazas que requieren contexto tardío, lo que aumenta la latencia informada para esas detecciones.
Para alertas críticas y urgentes: Usa reglas de evento único o reglas de evento múltiple con las frecuencias de ejecución prácticas más cortas. Reducir la ventana de coincidencia no afecta directamente la latencia, pero puede aumentar la eficiencia estableciendo la demora mínima.
Para correlaciones complejas y de larga duración (UEBA, ataques de varias etapas): Estas reglas se basan en uniones contextuales o listas de referencia extensas, que pueden actualizarse de forma asíncrona. Pueden experimentar una latencia alta con datos contextuales o de eventos que llegan tarde, pero ofrecen el beneficio de una detección de mayor fidelidad en lugar de una velocidad absoluta.
Optimiza las reglas para reducir la dependencia del enriquecimiento tardío
Para optimizar la velocidad de detección y minimizar el impacto de las ejecuciones de enriquecimiento retroactivo, considera usar campos sin alias (campos que no están sujetos a canalizaciones de enriquecimiento posteriores) en la lógica de tus reglas siempre que sea posible.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.