Información sobre las demoras en la detección de reglas

Se admite en los siguientes sistemas operativos:

En este documento, se explican las demoras en la detección de reglas en Google Security Operations, se identifican los factores que contribuyen a ellas en las canalizaciones de procesamiento y de transferencia, se describen enfoques estructurados para la solución de problemas y se proporcionan técnicas para reducir la latencia de detección.

Descripción general de las reglas de detección

Las reglas de detección examinan los registros sin procesar normalizados (tanto los eventos normales como los de entidad del modelo universal de datos [UDM]) para generar detecciones de seguridad según las especificaciones de las reglas. Por lo general, los eventos del UDM de entidades contienen información de contexto, como metadatos del usuario o del activo. Las reglas de detección también pueden evaluar las detecciones generadas anteriormente para producir alertas compuestas.

Demoras previstas y no previstas

La latencia de detección varía según la lógica de la regla, las dependencias de datos y los ciclos de procesamiento del sistema. Las demoras se clasifican en dos tipos:

  • Demoras esperadas: Son las demoras que resultan de factores estructurales, como el proceso de transferencia, el tipo de regla, la frecuencia de ejecución, el método de generación de detección, la duración del período de coincidencia y los límites conocidos del sistema. Puedes minimizar las demoras esperadas ajustando la configuración de las reglas de detección y los parámetros de programación.
  • Demoras imprevistas: Son demoras causadas por condiciones externas o dinámicas de la canalización, incluidos los cuellos de botella en la entrega de registros de las fuentes de datos, la latencia de procesamiento transitoria dentro de los servicios de Google SecOps, la disponibilidad de contexto retrasada y los ciclos de reenriquecimiento del UDM.

Métodos de generación de detección

Google SecOps genera detecciones de reglas a través de las siguientes canalizaciones de ejecución:

  • Streaming Engine: Es una canalización de alta velocidad que evalúa las reglas estándar y las reglas de un solo evento basadas en ventanas de forma continua y casi en tiempo real (por lo general, en un plazo de 5 minutos después de 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: Evalúa reglas que requieren correlación de eventos basada en el tiempo en varios eventos o combinaciones de datos externos:
    • Reglas complejas de un solo evento: Incluyen reglas de un solo evento que consultan listas de referencia o tablas de datos.
    • Reglas de varios eventos: Consultan datos 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) según los programas configurados.
  • Las reglas se ejecutan en función de los datos históricos: Evalúa las reglas de forma retroactiva en función de los registros históricos a través de la función de búsqueda retroactiva. Las detecciones aparecen después de que se completa el análisis histórico.
  • Reenriquecimiento de eventos del UDM: Vuelve a evaluar los períodos procesados anteriormente cuando se agregan datos de contexto nuevos o datos de entidades actualizados a los eventos históricos.

Factores que contribuyen a las demoras en la detección de reglas

La velocidad con la que aparecen las detecciones depende de la complejidad de la regla, los intervalos de programación, la latencia de la transferencia de datos y las canalizaciones de enriquecimiento del contexto.

Tipos de reglas y complejidad

Las reglas de detección se dividen en varias categorías con diferentes perfiles de latencia:

Reglas de eventos únicos

Las reglas de un solo evento se ejecutan casi en tiempo real en el motor de transmisión continua y ofrecen la latencia de detección más baja. Estas reglas evalúan eventos individuales sin unir conjuntos de datos externos, tablas de datos ni períodos de coincidencia de varios eventos.

Reglas complejas de un solo evento

Estas reglas evalúan eventos únicos, pero incorporan dependencias de datos adicionales:

  • Reglas de evento único con ventana: Son reglas de evento único que incluyen una sección match (por ejemplo, evaluar si un solo evento coincide con una condición durante un período). Estas reglas se evalúan casi en tiempo real en el motor de transmisión continua a medida que se transfieren los datos.
  • Reglas de referencia de evento único: Son reglas de evento único que comparan los atributos del evento con listas de referencia o tablas de datos.

Reglas de varios eventos

Las reglas de eventos múltiples correlacionan dos o más condiciones de eventos del UDM durante un período de coincidencia especificado y se ejecutan en intervalos de lotes programados.

  • Reglas estándar de varios eventos: Agregan varios eventos en períodos y se ejecutan en intervalos de 10 minutos o 1 hora (o match_window / 10 para períodos superiores a 48 horas).
  • Reglas basadas en el contexto: Correlaciona los datos de eventos con los eventos de entidades de UDM (como user_context o asset_context) con análisis basados en el contexto. Debido a que las reglas adaptadas al contexto dependen de varios feeds de datos, son más sensibles a los tiempos de transferencia. Para obtener más información, consulta Usa datos enriquecidos con contexto en las reglas.

Frecuencia de ejecución de la regla

La frecuencia de ejecución configurada determina con qué frecuencia el motor de consultas evalúa los bloques de tiempo de eventos:

  • Casi en tiempo real: Evaluación continua para reglas de eventos únicos (estándar y con ventanas).
  • Frecuencia de 10 minutos: Disponible para reglas de varios eventos con ventanas de coincidencia de menos de 60 minutos.
  • Frecuencia de 1 hora: Es el intervalo predeterminado para las reglas de varios eventos con períodos de coincidencia de 48 horas o menos.
  • Frecuencia de match_window / 10: Se asigna automáticamente para las reglas de varios eventos con períodos de coincidencia superiores a 48 horas (por ejemplo, se ejecuta cada 10 horas para un período de coincidencia de 100 horas o cada 24 horas para un período de 10 días).

Duración del período de las coincidencias

En el caso de las reglas de eventos múltiples, la duración del período de coincidencia define el período de observación necesario para agregar eventos. Las detecciones no pueden aparecer hasta que transcurra el período completo.

Retraso en la transferencia de registros

El retraso de la transferencia es el tiempo transcurrido entre el momento en que ocurre un evento en la fuente y el momento en que Google SecOps recibe y analiza el registro.

Si un evento llega después de la evaluación inicial programada para ese período, no se incluye en la primera ejecución. El sistema captura los datos que llegan tarde en ejecuciones automatizadas en segundo plano posteriores (ejecuciones de corrección), que se producen aproximadamente 4 horas (y, de manera opcional, 30 horas con la integridad del enriquecimiento) después de la ejecución principal.

  • Ejemplo: Una regla correlaciona el evento A (hora del evento: 9:03 a.m.) y el evento B (hora del evento: 9:05 a.m.) en un período de 30 minutos. Si el evento A llega a las 10:05 a.m. (una hora tarde), no se incluye en la ejecución inicial del bloque de 9:00 a 9:30 a.m. El sistema vuelve a evaluar el bloqueo durante una ejecución de ajuste posterior, aproximadamente 4 horas después de la ejecución principal (alrededor de las 14:00), y genera la detección aproximadamente 5 horas después de que ocurrió el evento.

Discrepancias en la zona horaria

De forma predeterminada, Google SecOps interpreta las marcas de tiempo de los registros como UTC. Si una fuente de registro omite un desplazamiento de zona horaria explícito, el sistema trata la marca de tiempo como UTC, lo que puede hacer que el registro parezca que llega tarde, incluso si se recibe de inmediato.

  • Ejemplo: Un evento ocurre a las 10:00 a.m. (hora del este; 3:00 p.m. UTC) y llega a Google SecOps a las 3:05 p.m. UTC sin metadatos de zona horaria. El sistema interpreta la marca de tiempo como las 10:00 a.m. (UTC), lo que genera una demora percibida de 5 horas en la transferencia que pospone la evaluación de la regla para una ejecución de conciliación en segundo plano.

Soluciones: Para resolver las discrepancias en la zona horaria, haz lo siguiente:

  • Configura la fuente del archivo de registro para que incluya desplazamientos explícitos de la zona horaria UTC en las marcas de tiempo de los eventos.
  • Comunícate con el equipo de asistencia para establecer una anulación de zona horaria para el feed de transferencia específico.
  • Usa un procesador de BindPlane para normalizar las marcas de tiempo del cuerpo del registro a UTC antes de la transferencia. Para obtener más información, consulta Cómo modificar las marcas de tiempo del cuerpo del registro con BindPlane.

Uniones contextuales y enriquecimiento de datos

Google SecOps enriquece los eventos del UDM agregando metadatos de identidad, recursos y amenazas de fuentes secundarias. Los retrasos en la disponibilidad del contexto pueden extender el tiempo de detección.

Mecánica de alias y enriquecimiento

El enriquecimiento y la creación de alias correlacionan los indicadores sin procesar con el contexto de la organización:

  • Creación de alias: Identifica y vincula diferentes identificadores para la misma entidad en todas las fuentes de datos (por ejemplo, asigna una dirección IP de los registros de DHCP a una dirección MAC y un nombre de host como alex-macbook, o asigna un ID de usuario a un cargo de empleado).
  • Enriquecimiento: Completa los campos normalizados del evento de UDM con el contexto con alias (por ejemplo, completa $udm.event.principal.hostname cuando solo hay una dirección IP en el evento sin procesar).

Los tipos de enriquecimiento admitidos incluyen recursos, usuarios, procesos, metadatos de hash de archivos, ubicaciones geográficas y recursos de Cloud. Para obtener más información, consulta la Descripción general del enriquecimiento y los alias del UDM.

Reenriquecimiento de eventos de UDM

El sistema actualiza continuamente los eventos históricos a medida que evolucionan las fuentes de contexto:

  • Cambios en los datos subyacentes: Los eventos históricos se pueden actualizar hasta 24 horas después de la transferencia, a medida que llegan nuevos datos de contexto.
  • Actualizaciones del sistema de enriquecimiento: Cuando se actualizan los metadatos de la entidad, la ubicación geográfica de la IP o la inteligencia contra amenazas de VirusTotal, el motor de reglas vuelve a evaluar los bloqueos históricos (por lo general, durante las ejecuciones de conciliación programadas o el reprocesamiento) para generar detecciones con contexto actualizado.
  • Datos de contexto retrasados: Si los datos de contexto (como un nombre de host) llegan un día después del registro de eventos, el sistema vuelve a enriquecer el evento del UDM y las ejecuciones de corrección posteriores evalúan el registro enriquecido.
  • Modificaciones del contexto: Si una actualización del enriquecimiento cambia un atributo del evento (por ejemplo, si actualiza una ubicación geográfica de IP de USA a Canada), las reglas que coincidan con el valor actualizado activarán detecciones durante las reevaluaciones posteriores.

Procesamiento del gráfico de contexto de la entidad (ECG)

El gráfico de contexto de entidades (ECG) correlaciona los indicadores de compromiso (IOC) y los datos del gráfico de activos empresariales. Dado que la canalización de ECG se basa en el procesamiento por lotes (que puede tardar 30 horas o hasta varios días, según el volumen de datos), las reglas que hacen referencia a los campos graph.entity generan detecciones después de que se calculan por completo las relaciones del gráfico.

Ejecuciones de reglas históricas y RetroHunts

Cuando se ejecuta una regla en datos históricos, se generan detecciones solo después de que se completa el análisis de retrocaza en el período seleccionado.

  • Flujo de trabajo de enriquecimiento retroactivo:
    1. Un evento llega a la 1:00 p.m. con ip_address = 10.0.0.5 (nombre de host desconocido).
    2. A las 2:30 p.m., llega un registro de DHCP que vincula 10.0.0.5 con workstation-123.
    3. La canalización de alias actualiza el evento histórico de la 1:00 p.m. con principal.hostname = workstation-123.
    4. Las repeticiones de reglas posteriores evalúan el nombre de host enriquecido y muestran las detecciones que no se activaron durante la ejecución inicial.

Listas de referencia

Las reglas que consultan listas de referencia se evalúan en función de la versión de lista más reciente en el momento de la ejecución. La actualización de una lista de referencia puede hacer que las reglas programadas produzcan detecciones de forma retroactiva en los registros transferidos anteriormente.

Reglas de no existencia

Para evitar falsos positivos, el sistema introduce un búfer mínimo de una hora antes de evaluar las reglas que verifican las condiciones de inexistencia (como !$e o #e=0), lo que garantiza que todos los registros relacionados tengan tiempo para llegar.

Limitaciones del procesamiento de datos y la conciliación

Ten en cuenta los siguientes comportamientos del sistema cuando evalúes la latencia de detección:

  • Procesamiento de enriquecimiento: El enriquecimiento del contexto puede actualizar los eventos históricos del UDM hasta 24 horas después de la transferencia inicial.
  • Ciclos de ajuste: Las reglas de varios eventos se vuelven a ejecutar automáticamente aproximadamente 4 horas (y, de forma opcional, 30 horas) después de la ejecución principal para capturar los datos que llegan tarde. Para obtener más información, consulta Información sobre las repeticiones de reglas y el MTTD.
  • Límites de detección: Para conocer los límites de capacidad y de aceleración de la plataforma, consulta Información sobre los límites de detección.

Soluciona problemas de retrasos en la detección de reglas

Para diagnosticar por qué una regla generó una detección retrasada, examina las siguientes heurísticas y etapas de la canalización en la consola de Google SecOps:

  • Revisa los metadatos y la programación de la regla: En el Panel de reglas, consulta las columnas Nombre de la regla, Tipo de regla y Programación de la regla para identificar el motor de ejecución de la regla y la frecuencia de evaluación de la referencia.
  • Compara la hora del evento con la hora de la transferencia: Ubica la detección en la pestaña Detecciones y compara la marca de tiempo del evento con la marca de tiempo de la transferencia. Si la brecha entre el tiempo del evento y el tiempo de la transferencia supera los 30 minutos, la latencia se debió a retrasos en la entrega de registros en la fuente o durante la recopilación. Las detecciones generadas a partir de datos de eventos que llegan con más de 30 minutos de retraso, las ejecuciones de conciliación automáticas, las canalizaciones de reprocesamiento o las búsquedas retroactivas muestran un ícono de en la columna Tipo de detección.
  • Revisa las dependencias de la fuente del contexto: Verifica si la regla hace referencia al enriquecimiento de principal, a la creación de alias de UDM o a los campos de graph.entity. Las canalizaciones de contexto se procesan de forma asíncrona y pueden mostrar detecciones durante las ejecuciones de corrección posteriores.
  • Verifica la frecuencia y la compatibilidad de la ventana de correlación: Confirma que la frecuencia de ejecución configurada coincida con el tamaño de la ventana de correlación (por ejemplo, asegúrate de que una regla con una ventana de correlación de 15 minutos esté programada para 10 minutos o 1 hora).
  • Verifica si hay interrupciones en el feed de datos: Revisa los registros de transferencia y los paneles de administración de feeds para detectar retrasos en la transferencia o interrupciones transitorias de la fuente.

Sugerencias para reducir los retrasos en la detección

Para minimizar las demoras en la detección en todo tu entorno, aplica las siguientes técnicas de optimización:

  • Optimiza la frecuencia de ejecución de las reglas:
    • Usa Casi en tiempo real para las reglas de eventos únicos (estándar y con ventanas).
    • Configura una programación de 10 minutos para las reglas de varios eventos con períodos de coincidencia de menos de 60 minutos.
    • Usa 1 hora para las reglas con ventanas de coincidencia de entre 1 y 48 horas en las que se necesiten alertas rápidas.
  • Ajusta la duración de los períodos de correlación: Establece los períodos de correlación en la duración mínima necesaria para captar el comportamiento de amenazas correlacionado.
  • Elimina los cuellos de botella en la entrega de registros: Asegúrate de que los reenviadores y recopiladores envíen los datos de eventos de inmediato para evitar que los registros se pierdan en la ventana de ejecución inicial.
  • Valida la configuración de la zona horaria: Asegúrate de que las fuentes de registros proporcionen compensaciones de UTC explícitas para evitar retrasos percibidos en la transferencia de más de 5 horas.
  • Condiciones de contexto y no existencia de la auditoría: Usa campos enriquecidos con contexto y condiciones de no existencia (!$e) solo cuando lo requiera la lógica de detección, ya que estos introducen períodos de almacenamiento en búfer intencionales.

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