Comprende la programación de la ejecución de reglas

Se admite en los siguientes sistemas operativos:

Este documento está dirigido a los analistas, ingenieros y administradores de plataformas de Google Security Operations que desean comprender y administrar cómo Google Security Operations programa las ejecuciones de reglas. Se explica cómo las configuraciones de reglas determinan la frecuencia de procesamiento, cómo el sistema equilibra la transmisión casi en tiempo real con el procesamiento por lotes programado y cómo las ejecuciones en segundo plano controlan los registros que llegan tarde y el enriquecimiento del contexto.

Casos de uso habituales

Elegir o comprender la programación adecuada depende de la gravedad de la amenaza y la complejidad de la lógica:

  • Alertas de alta prioridad: Detecta amenazas críticas casi en tiempo real para las coincidencias de un solo evento que no requieren correlación de eventos adicional, lo que reduce el tiempo de permanencia del atacante.
  • Correlación y generación de informes complejos: Usa intervalos programados (como 10 minutos o 1 hora) para las reglas de varios eventos que calculan recuentos, sumas o ventanas de correlación deslizantes. Los intervalos programados garantizan que el sistema ingiera y enriquezca los registros relacionados antes de la ejecución, lo que mejora la precisión de las alertas para el análisis de tendencias y el cumplimiento.

Terminología clave

  • Frecuencia determinística: Es el intervalo de ejecución de referencia que el sistema asigna automáticamente en función del período de coincidencia y el tipo de regla.
  • Ejecución principal (T + desfase): Es la ejecución inicial de la lógica de detección en un bloque de tiempo de eventos. El retraso en la liquidación representa el desplazamiento agregado para tener en cuenta los datos que llegan tarde.
  • Demora en la liquidación: Es el período de búfer que se agrega a la ejecución principal para permitir que se procesen los registros que llegan tarde antes de que comience la evaluación de reglas.
  • Ejecuciones de regularización (repeticiones de reglas): Son ejecuciones automatizadas en segundo plano que vuelven a evaluar los períodos procesados anteriormente para capturar registros o datos de enriquecimiento que llegaron después de la ejecución principal.
  • Enriquecimiento: Proceso de agregar contexto a un registro (como metadatos de activos, identidad del usuario o indicadores de inteligencia contra amenazas) durante el procesamiento de la canalización.
  • Demora en la detección: Es el tiempo transcurrido total entre la marca de tiempo del evento y la creación de una detección.

Antes de comenzar

Confirma que tu entorno cumpla con los siguientes requisitos:

  • Permisos: Debes tener el rol de IAM de administrador de la API de Chronicle (roles/chronicle.admin) o de editor de la API de Chronicle (roles/chronicle.editor) para modificar los programas de reglas, o el rol de visualizador de la API de Chronicle (roles/chronicle.viewer) para inspeccionar los programas en el panel de reglas.
  • Verificación del entorno: Asegúrate de que tus registros estén asignados al Modelo de datos unificado (UDM) para admitir agregaciones de intervalos programados.

Cómo funciona la programación de reglas

Google SecOps equilibra la latencia de detección casi en tiempo real con la estabilidad de la plataforma en miles de reglas. La plataforma usa dos modelos de ejecución principales:

  1. Motor de transmisión: Evalúa las reglas de un solo evento estándar y de ventana (incluso con ventanas de coincidencia de más de 48 horas) de forma continua y casi en tiempo real (por lo general, dentro de los 5 minutos posteriores a la transferencia). Los eventos que llegan tarde y los enriquecimientos retroactivos se evalúan de forma continua durante la ejecución estándar.
  2. Motor de consultas programadas: Evalúa reglas complejas de un solo evento (con listas de referencia o tablas de datos) casi en tiempo real y reglas de varios eventos en bloques por lotes de tiempo de eventos (como intervalos de 10 minutos o 1 hora, o match_window / 10 para períodos superiores a 48 horas). Las reglas de eventos múltiples requieren un período para agregar y correlacionar eventos en todas las fuentes.

Configuración de la programación predeterminada

Cuando habilitas una regla, Google SecOps determina automáticamente la frecuencia de ejecución predeterminada en función de la lógica y el período de coincidencia de la regla:

Tipo de regla y tamaño de la ventana Frecuencia de ejecución Momento de la evaluación Ejecuciones de regularización
Regla de evento único (estándar o basada en ventanas) En tiempo real Poco después de la llegada (menos de 5 minutos) No. Evalúa los datos enriquecidos y tardíos de forma continua en la ejecución estándar.
Regla de evento único (con listas de referencia o tablas de datos) Casi en tiempo real Poco después de la llegada (menos de 5 minutos) No. Evalúa los datos enriquecidos y tardíos de forma continua durante la ejecución de la consulta estándar.
Regla de eventos múltiples (window <= 48h) Cada 1 hora (o Cada 10 min, personalizable para períodos de menos de 1 h) De 1 a 2 horas después de la llegada Sí. Incluye una ejecución de ajuste automatizada de 4 h y una ejecución de ajuste opcional de 30 h.
Regla de eventos múltiples (window > 48h) match_window / 10 (por ejemplo, cada 1 día para una ventana de coincidencias de 10 días) Varía según la ventana de coincidencia (match_window / 10) No. Evalúa los datos enriquecidos y tardíos durante las ejecuciones superpuestas posteriores.

Ejecuciones de regularización automáticas

Para evitar detecciones perdidas causadas por la latencia de la transferencia o los metadatos de enriquecimiento que llegan tarde (como las etiquetas de activos o los alias de usuario), el sistema ejecuta automáticamente procesos de corrección en segundo plano para las reglas de varios eventos (window <= 48h):

  1. Ejecución inicial: Se ejecuta lo más rápido posible según el intervalo programado para exponer las amenazas inmediatas.
  2. Primera ejecución de ajuste (4 h): Vuelve a evaluar el bloque de tiempo aproximadamente 4 horas después de la ejecución inicial para capturar los registros que llegan tarde. Esta etapa no espera el enriquecimiento completo de los datos.
  3. Segunda ejecución de la verificación (30 h): (Opcional) Se ejecuta aproximadamente 30 horas después de la ejecución inicial, una vez que se completan todas las canalizaciones de enriquecimiento de datos y contexto adicionales.

Para obtener más información sobre el comportamiento y las situaciones de ajuste, consulta Comprende las repeticiones de reglas y el MTTD.

Programas personalizables

En el caso de las reglas personalizadas de varios eventos con un período de coincidencia de hasta 48 h, Google SecOps te permite personalizar los parámetros de programación en lugar de depender por completo de los valores predeterminados del sistema:

  • Selección de frecuencia: Elige frecuencias de ejecución, como Cada 10 min (para períodos de coincidencia de menos de 60 minutos) o Cada 1 hora.
  • Retraso en la liquidación: Agrega un retraso de búfer (T + desplazamiento) para tener en cuenta la latencia conocida de la transferencia de fuentes de registro.
  • Integridad del enriquecimiento: Se extendió el procesamiento de conciliación a 30 horas para garantizar que todas las uniones de metadatos externos se completen antes de la evaluación final.

Para conocer todos los pasos de configuración, consulta Cómo configurar programas personalizados para las reglas.

Visibilidad de la programación en el panel de reglas

En el Panel de reglas, se muestra el programa de ejecución asignado para cada regla activa en la columna Programa de reglas. Las reglas inactivas no muestran una programación activa hasta que se habilitan.

Para modificar la frecuencia de ejecución, agregar retrasos en la liquidación o ajustar los tiempos de espera del enriquecimiento de una regla personalizada de varios eventos, consulta Cómo configurar programas personalizados para las reglas.

Indicadores de la fuente de detección

En la página Alertas y el Panel de reglas, la columna Tipo de detección indica si una detección se originó a partir de una ejecución inicial o de una ejecución automatizada en segundo plano:

  • Sin ícono: La detección se generó durante la ejecución principal (T) o con el motor de transmisión continua.
  • Ícono de bombilla : La detección se originó a partir de datos de eventos que llegaron con más de 30 minutos de retraso, ejecuciones de corrección automatizadas, canalizaciones de reprocesamiento o búsquedas retroactivas.

Consideraciones sobre la latencia y la solución de problemas

La frecuencia de ejecución de las reglas afecta directamente la velocidad de las detecciones. Ten en cuenta los siguientes comportamientos cuando diseñes y supervises reglas:

  • Programaciones por hora: Se ejecutan cada hora con los datos más recientes disponibles. No se aplica ningún búfer adicional de forma predeterminada.
  • Períodos de coincidencias superiores a 48 horas: El sistema ejecuta estas reglas a una velocidad de match_window / 10 y no realiza ninguna ejecución de corrección.
  • Discrepancias entre ejecuciones: Una detección que no se activa en la primera ejecución podría activarse durante una ejecución de ajuste si se retrasó la transferencia de registros o si el enriquecimiento del contexto (como la resolución del gráfico de entidades) se completó después de la evaluación inicial.
  • Faltan opciones de personalización: Las reglas de un solo evento se evalúan casi en tiempo real y no admiten la personalización de intervalos. Las reglas seleccionadas siguen programas fijos del sistema. Las reglas personalizadas de varios eventos con un período de coincidencias superior a 48 horas se ejecutan con una frecuencia de match_window / 10 y no se pueden personalizar.
  • Intervalos no admitidos: Si no puedes seleccionar la ejecución casi en tiempo real, tu regla es una regla de varios eventos que requiere la correlación de eventos a lo largo del tiempo o incluye agregaciones (como count o sum), que requieren el motor de consultas por lotes programadas.

Si quieres conocer los pasos detallados para solucionar problemas, consulta Cómo comprender las demoras en la detección de reglas.

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