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 o ejecuciones de ajuste) manejan los datos que llegan tarde y las actualizaciones de contexto, y cómo estas repeticiones afectan las métricas del tiempo promedio de detección (MTTD).

Repeticiones de reglas

Google Security Operations 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 evento único: Estas reglas se repiten cuando el proceso de enriquecimiento de UDM actualiza un evento evaluado anteriormente. Para conocer las excepciones relacionadas con las reglas con tablas de datos, consulta Situaciones de datos que llegan tarde más adelante en este documento.

  • Reglas de evento único con ventana (WSE) y reglas de evento único 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 evento único y de varios eventos.

  • Reglas de varios eventos: Estas reglas se ejecutan según una programación y procesan bloques de tiempo de eventos. Reevalúan 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 horarios exactos dependen de la configuración de la programación.

Activadores de repetición de reglas

El sistema vuelve a evaluar (ejecuta nuevamente) las reglas para asegurarse de 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 los valores de esos campos.

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 evento único (sin ventanas de coincidencia 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 límite 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 evento único en función del evento con el contexto nuevo. Esto puede ocurrir horas o incluso días después del evento inicial.

  • Reglas de evento único con ventana (WSE) y reglas de evento único con tablas de datos:

    • Estas reglas no siguen el mismo manejo de datos tardíos que otras reglas de evento único o las programaciones de ajuste de las reglas de varios eventos.
    • Tienen el siguiente comportamiento:
      • Corte: Estas reglas no procesan eventos ingeridos 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 ingesta), 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 pasados 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 programación de la regla determina el período límite efectivo:
      • Ejecución principal: El sistema ejecuta la primera evaluación en la hora del evento más cualquier retraso de liquidación 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 ejecución principal. Esto permite que el sistema incluya eventos que llegan tarde.
      • Ejecución de ajuste 2 (condicional): Si activas Asegurarse de que el enriquecimiento esté completo, el sistema ejecuta una ejecución de ajuste final aproximadamente 30 horas después de la ejecución principal. Esto extiende el período para que el sistema procese los datos que llegan tarde y los enriquecimientos de contexto hasta aproximadamente 30 horas.
      • Implicaciones del corte: La ejecución de ajuste final dicta el corte efectivo para incluir datos tardíos. Por lo general, esto ocurre alrededor de 4 horas después de la ejecución principal (o alrededor de 30 horas después de la ejecución principal si habilitas Asegurarse de que el enriquecimiento esté completo). 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 evento único

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

  • Situación 2: Enriquecimiento tardío: Regla de evento único

    • Ayer, el sistema procesó un evento de acceso. Hoy, ingiere y enriquece información nueva para el usuario involucrado (por ejemplo, un cambio de departamento). El sistema vuelve a evaluar la regla de evento único 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 (ajuste predeterminado de 4 horas)

    • Un evento llega 3 horas después de su marca de tiempo para una regla de varios eventos programada con la configuración predeterminada. El evento no se incluyó en la ejecución principal inicial (T + 1 h), pero el sistema lo procesa durante la ejecución de ajuste de 4 horas.

  • Situación 4: Evento de origen tardío: Regla de varios eventos (sin enriquecimiento completo)

    • Configuras una regla de varios eventos con un desplazamiento de ejecución principal de 1 hora sin habilitar Asegurarse de que el enriquecimiento esté completo. Un evento llega 6 horas después de su marca de tiempo.
    • Este evento no se incluye en la ejecución principal (T + 1 h) ni en la primera ejecución de ajuste (T + 4 h). El sistema no procesará este evento para ese período porque llegó después de la ejecución de ajuste final.

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

    • Una regla de varios eventos tiene un desplazamiento de 1 hora y habilitas Asegurarse de que el enriquecimiento esté completo. Los datos de enriquecimiento de un evento llegan 28 horas después de la marca de tiempo del evento.
    • El sistema vuelve a evaluar la regla con este enriquecimiento tardío durante la segunda ejecución de ajuste aproximadamente a las T + 31 h.

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

    • Una regla de varios eventos tiene una ventana de match de 48 horas y una programación con Asegurarse de que el enriquecimiento esté completo habilitado (ajuste final alrededor de las 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 coincidencia de la regla en relación con otros eventos. El corte se basa en la hora de llegada en relación con la programación de ajuste, no solo en la ventana de coincidencia.

  • Situación 7: Evento de origen tardío: Regla de evento único con ventana

    • 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.

Delta de cronograma y MTTD

El tiempo transcurrido entre la marca de tiempo del evento inicial y la creación de una detección afecta directamente el cálculo del MTTD.

Etapa de canalización o programación Tiempo de evaluación Impacto en la medición del MTTD
Regla de evento único (transmisión) Continuo (menos de 5 minutos después de la llegada) Las detecciones en tiempo real representan la velocidad real de la plataforma con un impacto mínimo en el MTTD.
Regla de varios eventos (ejecución principal) De 1 a 2 horas después de la llegada (más el retraso de liquidación configurado) Incluye la ventana de almacenamiento en búfer por lotes inevitable que se requiere para agregar estados de correlación de varios eventos.
Regla de varios eventos (ejecuciones de ajuste) 4 horas o 30 horas después de la ejecución principal Una ejecución secundaria (repetición) que incorpora datos de enriquecimiento tardíos hace que este tiempo aparezca tarde o retrasado 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 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 más información sobre estas métricas, consulta Consultas de ejemplo de YARA-L 2.0 para la página Paneles.

Un ícono en la columna Tipo de detección identifica las detecciones generadas a partir de datos de eventos que llegan con más de 30 minutos de retraso, ejecuciones de ajuste automatizadas, canalizaciones de reprocesamiento 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 evento único. 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 evento único o reglas de varios eventos 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 si se establece el retraso mínimo.

  • Para correlaciones complejas 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 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 las canalizaciones de enriquecimiento descendentes no procesan) en la lógica de tu regla cuando sea posible.

¿Qué sigue?

Para explorar conceptos de programación y flujos de trabajo de configuración relacionados, consulta los siguientes documentos:

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