Información sobre las repeticiones de reglas y el MTTD
En este documento se explica cómo gestionan las repeticiones de reglas (también llamadas ejecuciones de limpieza) los datos que llegan tarde y las actualizaciones de contexto, y cómo afecta esto a las métricas de tiempo medio de detección (MTTD).
Repeticiones de reglas
Google SecOps procesa grandes volúmenes de datos de seguridad. Para asegurar que las detecciones de las reglas que dependen de datos contextuales o correlacionados sean precisas, 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 a intervalos diferentes para gestionar los datos que llegan tarde o las reglas que necesitan un contexto actualizado, como la coincidencia con un indicador de riesgo (IOC).
Activadores de repetición de reglas
Las reglas se vuelven a evaluar (se vuelven a ejecutar) cuando llegan o se procesan datos de contexto relevantes después de los datos de eventos iniciales.
Entre los activadores de repetición de reglas habituales 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 de UDM llega antes que sus datos contextuales relacionados (como la información de los recursos o el contexto del usuario), es posible que no se detecte nada durante la ejecución inicial de la regla.
Actualizaciones retroactivas del enriquecimiento de 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 DHCP) llegan más de una hora después, esos valores de campo se actualizan retroactivamente para ese momento específico del evento. Las ejecuciones posteriores de la regla (las "ejecuciones de limpieza") usan estos valores recién enriquecidos, lo que puede activar una detección que antes se había pasado por alto.Reglas de varios eventos programadas
Las reglas multievento (ME) se ejecutan según una programación (por ejemplo, cada 10 minutos, cada hora o cada día) para evaluar bloques de tiempo de eventos. Para registrar las actualizaciones de enriquecimiento tardías de los datos históricos, estas reglas vuelven a evaluar el mismo bloque de tiempo más adelante, a menudo al menos dos o tres veces (por ejemplo, con comprobaciones entre 5 y 8 horas y, de nuevo, entre 24 y 48 horas después).
Impacto en las métricas de tiempos
Cuando una detección se produce como resultado de una repetición de una regla, la Ventana de detección o la Marca de tiempo del evento de la alerta hacen referencia a la hora de la actividad maliciosa original. La hora de creación es la hora en la que se crea la detección, que puede ser mucho más tarde, a veces horas o días después.
La latencia de detección alta (una gran diferencia de tiempo entre el evento y la detección) suele deberse a un nuevo enriquecimiento de los datos que llegan tarde o a la latencia en la canalización del gráfico de contexto de entidad (ECG).
Esta diferencia horaria puede hacer que una detección parezca "tardía" o "retrasada", lo que puede confundir a los analistas y distorsionar las métricas de rendimiento, como el tiempo medio de detección.
| Componente de métrica | Fuente de la hora | Cómo afectan las repeticiones al MTTD |
|---|---|---|
| Ventana de detección/Marca de tiempo del evento | Hora en la que se produjo el evento de seguridad original. | Esta información sigue siendo precisa en relación con la hora del evento. |
| Hora de detección/Hora de creación | Hora en la que el motor ha emitido la detección. | Esta hora aparece "tarde" o "con retraso" 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 al 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 analice las detecciones activadas por repeticiones de reglas, aplique las siguientes prácticas recomendadas para mantener métricas de MTTD precisas.
Priorizar 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, normalmente con un retraso de menos de 5 minutos.
También permite un uso más completo de las detecciones compuestas.
Tener en cuenta la repetición de reglas en reglas de varios eventos
Las reglas de varios eventos conllevan una latencia mayor debido a la frecuencia de ejecución programada. Cuando se mide el MTTD de las detecciones generadas por reglas de varios eventos, es fundamental tener en cuenta que las detecciones resultantes de las repeticiones de reglas automatizadas sirven para aumentar la cobertura y la precisión. Aunque estas repeticiones suelen detectar amenazas que requieren un contexto tardío, aumentarán necesariamente la latencia registrada de esa detección específica.
Para alertas críticas y urgentes: usa reglas de un solo evento o de varios eventos con las frecuencias de ejecución prácticas más cortas (por ejemplo, ventanas de coincidencia más cortas, de menos de una hora).
Para correlaciones complejas y de larga duración (UEBA, ataques de varias fases): la latencia será mayor (hasta 48 horas o más) si las reglas se basan en combinaciones contextuales extensas o en listas de referencia que pueden actualizarse de forma asíncrona. La ventaja es que la detección es más precisa, no que sea más rápida.
Optimizar 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 la posibilidad de usar campos sin alias (campos que no están sujetos a las canalizaciones de enriquecimiento posteriores) en la lógica de tus reglas siempre que sea posible.
¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.