Información sobre la programación de ejecución de reglas
Este documento está dirigido a analistas de seguridad, ingenieros y administradores de plataformas que desean comprender y administrar cómo Google Security Operations programa las ejecuciones de reglas. En él, 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 de contexto.
Casos de uso habituales
Elegir o comprender la programación correcta 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 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 reglas de varios eventos que calculan recuentos, sumas o períodos de coincidencias deslizantes. Los intervalos programados garantizan que el sistema transfiera y enriquezca los registros relacionados antes de la ejecución, lo que mejora la precisión de las alertas para el cumplimiento y el análisis de tendencias.
Terminología clave
- Frecuencia determinista: Es el intervalo de ejecución de referencia que el sistema asigna automáticamente en función del período de coincidencias y el tipo de regla.
- Ejecución principal (T + desplazamiento): Es la ejecución inicial de la lógica de detección en un bloque de tiempo de eventos. La demora de liquidación representa el desplazamiento agregado para tener en cuenta los datos que llegan tarde.
- Demora de 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 la regla.
- 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: Es el 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 de detección: Es el tiempo total transcurrido 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 Administrador de la API de Chronicle (
roles/chronicle.admin) o Editor de la API de Chronicle (roles/chronicle.editor) para modificar las programaciones de reglas, o el rol de Visor de la API de Chronicle (roles/chronicle.viewer) para inspeccionar las programaciones 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:
- Motor de transmisión: Evalúa las reglas de un solo evento estándar y con ventanas (incluso con períodos de coincidencias de más de 48 horas) de forma continua 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.
- 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 / 10para ventanas de más de 48 horas). Las reglas de varios eventos requieren un período para agregar y correlacionar eventos en todas las fuentes.
Configuración de 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 coincidencias de la regla:
| Tipo de regla y tamaño de la ventana | Frecuencia de ejecución | Tiempo de evaluación | Ejecuciones de regularización |
|---|---|---|---|
| Regla de evento único (estándar o con ventanas) | Tiempo real | Poco después de la llegada (menos de 5 minutos) | No. Evalúa los datos tardíos y enriquecidos 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 tardíos y enriquecidos de forma continua durante la ejecución de consultas estándar. |
Regla de varios eventos (window <= 48h) |
Cada 1 hora (o Cada 10 min personalizable para ventanas de menos de 1 hora) | Entre 1 y 2 horas después de la llegada | Sí. Incluye una ejecución de regularización automatizada de 4 horas y una ejecución de regularización opcional de 30 horas. |
Regla de varios eventos (window > 48h) |
match_window / 10 (por ejemplo, cada 1 día para un período de coincidencias de 10 días) |
Varía según el período de coincidencias (match_window / 10) |
No. Evalúa los datos tardíos y enriquecidos durante las ejecuciones superpuestas posteriores. |
Ejecuciones de regularización automáticas
Para evitar detecciones perdidas causadas por la latencia de transferencia o los metadatos de enriquecimiento que llegan tarde (como etiquetas de activos o alias de usuario), el sistema realiza automáticamente ejecuciones de regularización en segundo plano para reglas de varios eventos (window <= 48h):
- Ejecución inicial: Se ejecuta lo más rápido posible según el intervalo programado para exponer amenazas inmediatas.
- Primera ejecución de regularización (4 horas): 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.
- Segunda ejecución de regularización (30 horas): (Opcional) Se ejecuta aproximadamente 30 horas después de la ejecución inicial una vez que se completan todas las canalizaciones de contexto adicional y enriquecimiento de datos.
Para obtener más información sobre el comportamiento y las situaciones de regularización, consulta Información sobre las repeticiones de reglas y el MTTD.
Programaciones personalizables
Para las reglas personalizadas de varios eventos con un período de coincidencias de <=48 horas, 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 coincidencias de menos de 60 minutos) o Cada 1 hora.
- Demora de liquidación: Agrega una demora de búfer (T + desplazamiento) para adaptarse a la latencia de transferencia de la fuente de registro conocida.
- Integridad del enriquecimiento: Extiende el procesamiento de regularización a 30 horas para garantizar que todas las uniones de metadatos externos se completen antes de la evaluación final.
Para conocer los pasos de configuración completos, consulta Configura programaciones personalizadas para las reglas.
Visibilidad de la programación en el panel de reglas
El panel de reglas muestra la programación de ejecución asignada para cada regla activa en la columna Programación de reglas. Las reglas inactivas no muestran una programación activa hasta que se habilitan.
Para modificar la frecuencia de ejecución, agregar demoras de liquidación o ajustar los tiempos de espera de enriquecimiento para una regla personalizada de varios eventos, consulta Configura programaciones personalizadas 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 más de 30 minutos tarde, ejecuciones de regularizació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 tus 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 de más de 48 horas: El sistema ejecuta estas reglas a una tasa de
match_window / 10y no realiza ninguna ejecución de regularización. - Discrepancias entre ejecuciones: Una detección que no se activa en la primera ejecución puede activarse durante una ejecución de regularización si se retrasó la transferencia de registros o si el enriquecimiento de 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 programaciones fijas del sistema. Las reglas personalizadas de varios eventos con un período de coincidencias de más de 48 horas se ejecutan con una frecuencia de
match_window / 10y 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 correlación de eventos en el tiempo o incluye agregaciones (como
countosum), que requieren el motor de consultas por lotes programado.
Para conocer los pasos detallados para la solución de problemas, consulta Información sobre las demoras en la detección de reglas.
¿Qué sigue?
Para explorar conceptos de programación relacionados y flujos de trabajo de configuración, consulta los siguientes documentos:
- Configura programaciones personalizadas para las reglas: Personaliza las frecuencias de ejecución, las demoras de liquidación y la integridad del enriquecimiento de regularización para las reglas de varios eventos.
- Información sobre las repeticiones de reglas y el MTTD: Obtén información sobre cómo las ejecuciones de regularización automatizadas controlan los datos que llegan tarde y las actualizaciones de contexto para afectar las métricas del tiempo medio de detección (MTTD).
- Información sobre las demoras en la detección de reglas: Diagnostica y resuelve las demoras esperadas y no previstas en las canalizaciones de transferencia y procesamiento.
- Administra reglas con el editor de reglas: Crea, edita y administra reglas de detección personalizadas en Google SecOps.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.