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

Compatible con:

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 transferencia y procesamiento, 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 eventos del Modelo de datos universal (UDM) de entidades, 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 de usuarios o recursos. 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 las reglas, las dependencias de datos y los ciclos de procesamiento del sistema. Las demoras se clasifican en dos tipos:

  • Demoras previstas: 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 previstas ajustando las configuraciones de las reglas de detección y los parámetros de programación.
  • Demoras no previstas: Son las 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 re-enriquecimiento 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:

  • Motor de transmisión: Es una canalización de alta velocidad que evalúa continuamente las reglas de eventos únicos estándar y con períodos en tiempo casi 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 continuamente durante la ejecución estándar.
  • Motor de consultas: Evalúa las reglas que requieren la correlación de eventos basados en el tiempo en varios eventos o uniones de datos externos:
    • Reglas complejas de eventos únicos: Incluyen reglas de eventos únicos 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 de más de 48 horas) según las programaciones configuradas.
  • Reglas que se ejecutan en relación con los datos históricos: Evalúan las reglas de forma retroactiva en relación con los registros históricos a través de RetroHunts. Las detecciones aparecen después de que se completa el análisis histórico.
  • Re-enriquecimiento de eventos del UDM: Vuelve a evaluar los bloques de tiempo procesados anteriormente cuando se agregan datos de contexto nuevos o actualizados de entidades 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 las reglas, los intervalos de programación, la latencia de transferencia de datos y las canalizaciones de enriquecimiento de 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 eventos únicos se ejecutan en tiempo casi 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 eventos únicos

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

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

Reglas de varios eventos

Las reglas de varios eventos correlacionan dos o más condiciones de eventos del UDM durante un período de coincidencia especificado y se ejecutan en intervalos por 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 de más de 48 horas).
  • Reglas adaptadas al contexto: Correlacionan datos de eventos con eventos de entidades del UDM (como user_context o asset_context) mediante el análisis adaptado al contexto. Debido a que las reglas adaptadas al contexto dependen de varias transmisiones de datos, son más sensibles a la sincronización de la transferencia. Para obtener más información, consulta Usa datos enriquecidos con contexto en las reglas.

Frecuencia de ejecución de reglas

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

  • Tiempo casi real: Evaluación continua para reglas de eventos únicos (estándar y con períodos).
  • Frecuencia de 10 minutos: Disponible para reglas de varios eventos con períodos de coincidencia de menos de 60 minutos.
  • Frecuencia de 1 hora: Intervalo predeterminado para reglas de varios eventos con períodos de coincidencia de 48 horas o menos.
  • Frecuencia de match_window / 10: Se asigna automáticamente a las reglas de varios eventos con períodos de coincidencia de más de 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 coincidencia

En el caso de las reglas de varios eventos, 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 haya transcurrido el período completo.

Demora en la transferencia de registros

La demora en la transferencia es el tiempo transcurrido entre el momento en que se produce 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 bloque de tiempo, se pierde la primera ejecución. El sistema captura los datos que llegan tarde en las ejecuciones automáticas posteriores en segundo plano (ejecuciones de conciliació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), se pierde la ejecución inicial para el bloque de 9:00 a 9:30 a.m. El sistema vuelve a evaluar el bloque durante una ejecución de conciliación posterior aproximadamente 4 horas después de la ejecución principal (alrededor de las 2:00 p.m.), lo que genera la detección aproximadamente 5 horas después de que se produjo 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 aparezca como que llegó tarde, incluso si se recibió de inmediato.

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

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

  • Configura la fuente del archivo de registro para que incluya desplazamientos de zona horaria UTC explícitos en las marcas de tiempo de los eventos.
  • Comunícate con el equipo de asistencia para establecer una anulación de zona horaria para la transmisión de transferencia específica.
  • 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. Las demoras en la disponibilidad del contexto pueden extender el tiempo de detección.

Mecánica de alias y enriquecimiento

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

  • Alias: Identifica y vincula diferentes identificadores para la misma entidad en las fuentes de datos (como asignar una dirección IP de los registros de DHCP a una dirección MAC y un nombre de host como alex-macbook, o asignar un ID de usuario a un puesto de trabajo de empleado).
  • Enriquecimiento: Propaga los campos de eventos del UDM normalizados con el contexto con alias (como propagar $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 la nube. Para obtener más información, consulta Descripción general del enriquecimiento y los alias del UDM.

Re-enriquecimiento de eventos del 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 los datos de contexto nuevos.
  • Actualizaciones del sistema de enriquecimiento: Cuando se actualizan los metadatos de la entidad, la geolocalización de IP o la inteligencia contra amenazas de VirusTotal, el motor de reglas vuelve a evaluar los bloques 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 conciliación posteriores evalúan el registro enriquecido.
  • Modificaciones de contexto: Si una actualización de enriquecimiento cambia un atributo de evento (como actualizar una geolocalización de IP de USA a Canada), las reglas que coinciden con el valor actualizado activan detecciones durante las reevaluaciones posteriores.

Procesamiento del gráfico de contexto de entidades (ECG)

El gráfico de contexto de entidades (ECG) correlaciona los indicadores de vulneración (IOC) y los datos del gráfico de recursos empresariales. Debido a que la canalización del ECG depende del procesamiento por lotes (que puede tardar 30 horas o 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

La ejecución de una regla en relación con los datos históricos genera detecciones solo después de que se completa el análisis de RetroHunt 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 a 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 las detecciones de superficie 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 más reciente de la lista 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 relación con los registros transferidos anteriormente.

Reglas de inexistencia

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 de llegar.

Limitaciones de procesamiento de datos y conciliación

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

  • Procesamiento de enriquecimiento: El enriquecimiento de contexto puede actualizar los eventos históricos del UDM hasta 24 horas después de la transferencia inicial.
  • Ciclos de conciliación: Las reglas de varios eventos se vuelven a ejecutar automáticamente aproximadamente 4 horas (y, de manera 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 la capacidad de la plataforma y los límites de regulación, consulta Información sobre los límites de detección.

Soluciona problemas de demoras 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 las reglas: 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 referencia.
  • Compara la hora del evento con la hora de transferencia: Busca 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 diferencia entre la hora del evento y la hora de transferencia supera los 30 minutos, la latencia se debió a demoras en la entrega de registros en la fuente o durante la recopilación. Las detecciones generadas a partir de datos de eventos que llegan más de 30 minutos tarde, las ejecuciones de conciliación automáticas, las canalizaciones de reprocesamiento o las RetroHunts muestran un ícono de bombilla en la columna Tipo de detección.
  • Revisa las dependencias de la fuente de contexto: Verifica si la regla hace referencia al enriquecimiento principal, a los alias del UDM o a los campos graph.entity. Las canalizaciones de contexto se procesan de forma asíncrona y pueden mostrar detecciones durante las ejecuciones de conciliación posteriores.
  • Verifica la frecuencia y la compatibilidad del período de coincidencia: Confirma que la frecuencia de ejecución configurada coincida con el tamaño del período de coincidencia (por ejemplo, asegúrate de que una regla con un período de coincidencia de 15 minutos esté programada para 10 minutos o 1 hora).
  • Verifica si hay interrupciones en la transmisión de datos: Revisa los registros de transferencia y los paneles de administración de transmisiones para detectar demoras en la transferencia o interrupciones transitorias de la fuente.

Sugerencias para acortar las demoras en la detección

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

  • Optimiza la frecuencia de ejecución de reglas:
    • Usa Tiempo casi real para las reglas de eventos únicos (estándar y con períodos).
    • 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 períodos de coincidencia de entre 1 y 48 horas en las que se necesiten alertas rápidas.
  • Ajusta las duraciones de los períodos de coincidencia: Establece períodos de coincidencia con la duración mínima necesaria para capturar 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 el período de ejecución inicial.
  • Valida las configuraciones de zona horaria: Asegúrate de que las fuentes de registro proporcionen desplazamientos UTC explícitos para evitar demoras percibidas en la transferencia de más de 5 horas.
  • Audita las condiciones de contexto y de inexistencia: Usa campos enriquecidos con contexto y condiciones de inexistencia (!$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 los conceptos de programación relacionados y los flujos de trabajo de configuración, consulta los siguientes documentos:

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