Comprende las repeticiones de reglas y el MTTD
En este documento, se explica 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 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. Este proceso evalúa el mismo bloque de datos de eventos varias veces en diferentes intervalos para controlar los datos que llegan tarde o las reglas que necesitan un contexto actualizado, como la coincidencia con un indicador de compromiso (IOC).
Activadores de repetición de reglas
Las reglas se vuelven a evaluar (se vuelven a ejecutar) cuando llegan datos de contexto relevantes o se procesan más tarde que los datos del evento inicial.
Entre los activadores comunes de la reproducción de reglas, se incluyen los siguientes:
Datos de enriquecimiento que llegan tarde
Las canalizaciones de enriquecimiento de datos, como el gráfico de contexto de entidades (ECG), pueden procesar datos en lotes. Si un evento del UDM llega antes que sus datos contextuales relacionados (como la información del recurso o el contexto del usuario), es posible que se omita una detección durante la ejecución inicial de la regla.
Actualizaciones retroactivas del enriquecimiento del UDM
Si tu regla usa campos con alias (campos enriquecidos) en tu lógica de detección, como
$udm.event.principal.hostname, y los datos de origen (por ejemplo, los registros de DHCP) llegan más de una hora después, los valores de esos campos se actualizan de forma retroactiva para ese momento específico del evento. Las ejecuciones de reglas posteriores ("ejecuciones de limpieza") usan estos valores enriquecidos recientemente, lo que puede activar una detección que se había omitido anteriormente.Reglas de eventos múltiples programadas
Las reglas de Multi-Event (ME) se ejecutan según un programa (por ejemplo, cada 10 minutos, cada hora o cada día) para evaluar bloques de tiempo de eventos. Para capturar las actualizaciones de enriquecimiento tardías en los datos históricos, estas reglas vuelven a evaluar el mismo período más adelante, a menudo ejecutándose al menos dos o tres veces (por ejemplo, con verificaciones entre 5 y 8 horas después, y nuevamente entre 24 y 48 horas después).
Impacto en las métricas de tiempo
Cuando una detección es el resultado de una reproducción de regla, 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 se creó la detección, que puede ser mucho más tarde, a veces horas o días después.
Por lo general, la latencia de detección alta (una gran diferencia de tiempo entre el evento y la detección) se debe al re-enriquecimiento de los datos que llegan tarde o a la latencia en la canalización del gráfico de contexto de entidades (ECG).
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 para 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 como "tardía" o "retrasada" en relación con la marca de tiempo del evento porque se basa en una ejecución secundaria (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 precisas del MTTD.
Prioriza los sistemas de detección en tiempo real
Para obtener las detecciones más rápidas, usa las reglas de un solo evento. 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 se mide el MTTD para las detecciones generadas por reglas de varios eventos, es fundamental reconocer que las detecciones resultantes de las repeticiones de reglas automatizadas sirven para aumentar la cobertura y la precisión. Si bien estas repeticiones suelen detectar amenazas que requieren contexto tardío, necesariamente aumentarán la latencia informada para esa detección específica.
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 (por ejemplo, períodos de coincidencia más cortos, de menos de una hora).
Para la correlación compleja y de larga duración (UEBA, ataques de varias etapas): Es posible que haya una latencia mayor (hasta 48 horas o más) si las reglas dependen de uniones contextuales extensas o listas de referencia que podrían actualizarse de forma asíncrona. El beneficio aquí es 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.