Comprende las repeticiones de reglas y el MTTD

Compatible con:

En este documento, se explica cómo las repeticiones de reglas (también llamadas ejecuciones de limpieza) manejan los datos que llegan tarde y las actualizaciones de contexto, y cómo estas repeticiones afectan las métricas de tiempo medio de detección (MTTD).

Repeticiones de reglas

Google SecOps procesa grandes volúmenes de datos de seguridad. Para garantizar detecciones precisas para las reglas que dependen de datos contextuales o correlacionados, el motor de reglas ejecuta automáticamente un proceso de repetición de reglas.

El proceso de repetición de reglas maneja estas categorías de reglas:

  • Reglas de un solo evento: Cuando el proceso de enriquecimiento de UDM actualiza un evento evaluado anteriormente, el sistema repite las reglas de un solo evento. (Consulta las excepciones para las reglas con tablas de datos a continuación).

  • Reglas de un solo evento en ventanas (WSE) y reglas de un solo evento con tablas de datos: Estas reglas tienen un mecanismo de programación distinto para manejar los datos que llegan tarde, diferente de las reglas estándar de un solo evento y de varios eventos.

  • Reglas de varios eventos: Las reglas de varios eventos se ejecutan según una programación y procesan bloques de tiempo de eventos. Estas reglas vuelven a evaluar repetidamente el mismo bloque de tiempo en diferentes intervalos para capturar actualizaciones de enriquecimiento tardías, como datos de contexto de usuarios o recursos coincidentes, o un indicador de compromiso (IOC). Los tiempos exactos dependen de la configuración de la programación.

Activadores de repetición de reglas

El sistema vuelve a evaluar (vuelve a ejecutar) las reglas para garantizar que detecte las detecciones, incluso si los datos llegan o se actualizan después de la ejecución inicial de la regla. Estos datos que llegan tarde incluyen las siguientes categorías:

  • Eventos de origen que llegan tarde: El registro sin procesar o el evento de UDM en sí llegan a Google SecOps mucho más tarde que la marca de tiempo real del evento.
  • Datos de enriquecimiento que llegan tarde: Los datos contextuales (por ejemplo, usuario, activo, inteligencia contra amenazas) relacionados con un evento están disponibles, o el sistema los actualiza, después de que procesó el evento por primera vez. Esto suele ocurrir porque las canalizaciones de enriquecimiento, como el gráfico de contexto de entidades (ECG), procesan datos en lotes o dependen de fuentes de datos externas.
  • Actualizaciones retroactivas de enriquecimiento de UDM: Los datos de origen que llegan tarde (como los registros de DHCP que actualizan los nombres de host) activan cambios en los campos de eventos de 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. Esta llegada tardía actualiza de forma retroactiva esos valores de campo.

El sistema activa las repeticiones de reglas de manera diferente según el tipo de regla y la naturaleza de los datos tardíos. El objetivo es equilibrar la puntualidad de la detección con la integridad de los datos.

Cómo maneja el sistema los datos que llegan tarde por tipo de regla

El tipo de regla y su configuración determinan el período dentro del cual los datos que llegan tarde pueden activar una reevaluación de la regla.

  • Reglas de un solo evento (sin ventanas de coincidencias ni tablas de datos):

    • Eventos de origen tardíos: Por lo general, estas reglas procesan un evento independientemente de la antigüedad de su marca de tiempo cuando llega al sistema. El sistema no impone un período de corte estricto para el procesamiento inicial de eventos de origen tardíos.
    • Enriquecimiento tardío: Si llegan datos de enriquecimiento para un evento evaluado anteriormente o se produce una actualización, el sistema vuelve a evaluar estas reglas de un solo evento en función del evento con el contexto nuevo. Esto puede ocurrir horas o incluso días después del evento inicial.

  • Reglas de un solo evento en ventanas (WSE) y reglas de un solo evento con tablas de datos:

    • Estas reglas no siguen el mismo manejo de datos tardíos que otras reglas de un solo evento o los programas de ajuste de las reglas de varios eventos.
    • Tienen el siguiente comportamiento:
      • Corte: Estas reglas no procesan los eventos transferidos 7 días o más después de la marca de tiempo del evento.
      • Datos que llegan tarde (<7 días): El sistema procesa los eventos que llegan con menos de 7 días de retraso, pero con una latencia potencialmente mayor.
      • Eventos de origen que llegan tarde: Las reglas de WSE no procesarán eventos si los datos llegan a Google SecOps 7 días o más después de la marca de tiempo del evento.
      • Actualizaciones de contexto: Si el contexto de un evento llega tarde o si un evento se enriquece de forma retroactiva, el sistema vuelve a evaluar automáticamente las reglas en función del evento enriquecido. Esta repetición de reglas puede activar nuevas detecciones, incluso si la evaluación inicial no generó una detección.
      • Enriquecimiento tardío: Si se actualiza un evento de UDM debido al enriquecimiento (que puede ocurrir hasta 7 días después de la transferencia), el sistema vuelve a evaluar estas reglas en función del evento actualizado. Sin embargo, a diferencia de otros tipos de reglas, las actualizaciones del contenido de la tabla de datos no activan una reevaluación automática de los eventos anteriores para estas reglas.
      • Ventana de visualización: Estas reglas usan una ventana de visualización de aproximadamente 7 días para volver a evaluar los eventos. Si llegan datos de enriquecimiento para un evento que se encuentra dentro de esta ventana de 7 días, se volverá a evaluar la regla.

  • Reglas de varios eventos:

    • Las reglas de varios eventos se ejecutan según una programación y vuelven a evaluar los bloques de tiempo para tener en cuenta los datos tardíos. La forma en que configures la programación de la regla determina el período de corte efectivo:
      • Programación predeterminada: Por lo general, el sistema ejecuta automáticamente ejecuciones de ajuste aproximadamente 5 horas y 24 horas después de la hora del evento. Si los datos llegan después de que se completa la ejecución de las 24 horas, esta regla no los evaluará para ese período.
      • Programaciones personalizables habilitadas: Esta función te brinda más control sobre los tiempos de ejecución a través de la configuración de "Frecuencia de ejecución". Consulta Configura programaciones personalizadas para las reglas. Los tiempos clave son los siguientes:
        • Primera ejecución: El sistema ejecuta la primera ejecución en la hora del evento más el desplazamiento configurado (por ejemplo, T + 1 hora).
        • Ejecución de ajuste 1: El sistema ejecuta la primera ejecución de ajuste aproximadamente 4 horas después de la primera ejecución. Esto significa que el sistema puede incluir eventos que lleguen hasta aproximadamente T + 4-5 horas.
        • Ejecución de ajuste 2 (condicional): Si activas Garantizar la integridad del enriquecimiento, el sistema ejecuta una ejecución de ajuste final aproximadamente 30 horas después de la primera ejecución. Esto extiende el período para que el sistema procese los datos tardíos a alrededor de T + 30-31 horas.
      • Implicaciones del corte: Con las programaciones personalizables, la última ejecución de ajuste dicta el corte efectivo para incluir datos tardíos. Por lo general, esto ocurre alrededor de 4 horas después de la primera ejecución o alrededor de 30 horas después de la primera ejecución si habilitas Garantizar la integridad del enriquecimiento. Esta regla no procesará los eventos ni los enriquecimientos que lleguen después de la ejecución de ajuste final para un período determinado.

Ejemplos de situaciones de datos que llegan tarde

  • Situación 1: Evento de origen tardío: Regla de un solo evento

    • Google SecOps transfiere un evento con una marca de tiempo de hace 3 días. Una regla estándar de un solo evento procesa este evento como datos nuevos.

  • Situación 2: Enriquecimiento tardío: Regla de un solo evento

    • Ayer, el sistema procesó un evento de acceso. Hoy, transfiere y enriquece información nueva para el usuario involucrado (por ejemplo, un cambio de departamento). El sistema vuelve a evaluar la regla de un solo evento en función del evento de acceso con el contexto de usuario actualizado.

  • Situación 3: Evento de origen tardío: Regla de varios eventos (programación predeterminada)

    • Si un evento llega 10 horas después de su marca de tiempo, el sistema lo omite durante la ejecución de ajuste de 5 horas, pero lo procesa durante la ejecución de ajuste de 24 horas. No se procesará un evento que llegue 25 horas tarde.

  • Situación 4: Evento de origen tardío: Regla de varios eventos (programación personalizable)

    • Configuras una regla de varios eventos con un desplazamiento de primera ejecución de 1 hora. Un evento llega 6 horas después de su marca de tiempo.
    • Este evento omite la primera ejecución (T + 1 h) y la primera ejecución de ajuste (T + 4 h). El sistema NO procesará este evento con esta regla, a menos que habilites Garantizar la integridad del enriquecimiento.

  • Situación 5: Enriquecimiento tardío: Regla de varios eventos (personalizable con integridad del enriquecimiento)

    • Una regla de varios eventos tiene un desplazamiento de 1 hora y habilitas Garantizar la integridad del enriquecimiento. Los datos de enriquecimiento de un evento llegan 28 horas después de la marca de tiempo del evento.
    • Algunos de estos datos de enriquecimiento tardíos podrían estar disponibles para la segunda "ejecución de ajuste", que ocurre alrededor de T + 30 h (porque activaste Garantizar la integridad del enriquecimiento). Si los datos de enriquecimiento están disponibles, el sistema vuelve a evaluar la regla con este enriquecimiento tardío.

  • Situación 6: Evento de origen tardío: Regla de varios eventos con ventana de coincidencias

    • Una regla de varios eventos tiene una ventana de match de 48 horas y una programación personalizada con Garantizar la integridad del enriquecimiento habilitada (ajuste final alrededor de T + 30 h). Un evento llega 36 horas después de su marca de tiempo. Este evento no se procesará porque llegó después de la ejecución de ajuste final, aunque la hora del evento esté dentro de la ventana de coincidencias de la regla en relación con otros eventos. El corte se basa en la hora de llegada en relación con el programa de ajuste, no solo en la ventana de coincidencias.

  • Situación 7: Evento de origen tardío: Regla de un solo evento en ventanas

    • Si un evento de origen con una marca de tiempo de hace 8 días llega tarde, es posible que quede fuera de la ventana de visualización de 7 días para las reglas de WSE y que no se procese.

Impacto en las métricas de tiempo

Cuando una detección es el resultado de una repetición de reglas, el sistema usa la siguiente terminología:

  • 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 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 hora de creación de la detección.

El re-enriquecimiento debido a los 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) suele causar una latencia de detección alta.

Esta diferencia de tiempo puede hacer que una detección aparezca como "tardía" o "retrasada", lo que puede confundir a los analistas y distorsionar las métricas de rendimiento, como el MTTD.

Componente de la métrica Fuente de tiempo Cómo afectan las repeticiones al MTTD
Ventana de detección / marca de tiempo del evento Hora en que ocurrió el evento de seguridad original Las repeticiones mantienen la precisión de la hora del evento.
Hora de detección / hora de creación Hora en que el motor emitió la detección Una ejecución secundaria (repetición) que incorpora datos de enriquecimiento tardíos hace que esta hora aparezca tarde o retrasada en relación con la marca de tiempo del evento. Este delta afecta negativamente el cálculo del MTTD.

Prácticas recomendadas para medir el MTTD

El MTTD cuantifica el tiempo 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 se pueden consultar por el usuario para medir el MTTD con precisión. Para obtener detalles sobre estas métricas, consulta Ejemplos de consultas de YARA-L 2.0 para la página Paneles.

Un ícono de en la columna Tipo de detección identifica las detecciones que genera el sistema a partir de datos de eventos que llegan más de 30 minutos tarde, ejecuciones de reprocesamiento de reglas o búsquedas retroactivas. 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 un solo evento. Estas reglas se ejecutan casi en tiempo real, por lo general, con un retraso de menos de 5 minutos.

Esto también admite un uso más integral de las detecciones compuestas.

Ten en cuenta la repetición de reglas en las reglas de varios eventos

Las reglas de varios eventos generan una latencia más alta debido a su frecuencia de ejecución programada run frequency. Cuando mides el MTTD para las detecciones de reglas de varios eventos, reconoce que las repeticiones de reglas automatizadas aumentan la cobertura y la precisión. Estas repeticiones 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 un solo evento o reglas de varios eventos con las frecuencias de ejecución prácticas más cortas. Reducir la ventana de coincidencias no afecta directamente la latencia, pero puede aumentar la eficiencia si se establece el retraso mínimo.

  • Para la correlación compleja y de larga duración (UEBA, ataques de varias etapas): Estas reglas se basan en uniones contextuales extensas o listas de referencia, que pueden actualizarse de forma asíncrona. Pueden experimentar una latencia alta con datos contextuales o datos 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 retroactivas, considera usar campos sin alias (campos que las canalizaciones de enriquecimiento descendentes no procesan) en la lógica de tu regla siempre que sea posible.

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