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, se describen los enfoques de solución de problemas y se sugieren técnicas para reducir las demoras siempre que sea posible.

Reglas de detección

Las reglas de detección examinan los eventos normales y de entidad del modelo universal de datos (UDM), que son registros sin procesar normalizados, para generar detecciones según las especificaciones de la regla. Por lo general, los eventos de UDM de entidades contienen información de contexto, como detalles del usuario o del activo. Las reglas también generan detecciones basadas en detecciones generadas anteriormente.

Retrasos previstos y no previstos

Los tiempos de detección están sujetos a demoras en el procesamiento. Si bien algunas reglas se activan casi en tiempo real, otras pueden tardar varios minutos u horas en completarse. Factores como el tipo de regla, la frecuencia de ejecución y el método de generación de detección afectan estos retrasos. En este documento, se exploran estos y otros factores de demora.

Las demoras se clasifican como previstas o imprevistas.

  • Demoras esperadas: Estas demoras son el resultado del proceso de incorporación y de las opciones de configuración que elijas cuando establezcas la regla de detección. Por ejemplo, el tiempo que se tarda en crear una detección es un factor. Estos retrasos dependen de factores estructurales conocidos, como el tipo de regla, la frecuencia de ejecución, el método de generación de detección, las limitaciones conocidas y otros factores predecibles.
    Puedes minimizar estos retrasos si cambias o ajustas la configuración de las reglas de detección, como se describe en este documento.
    Para obtener más información, consulta Sugerencias para reducir las demoras.

  • Demoras imprevistas: Son demoras específicas de la regla o del evento causadas por muchos factores, incluidas las demoras en los datos del evento que llegan a Google SecOps, la lentitud transitoria en las canalizaciones de procesamiento dentro de los servicios de Google SecOps, el reenriquecimiento y otras demoras en el procesamiento de datos.

Analiza las demoras en la detección de reglas

Para analizar las demoras en la detección de reglas, busca información sobre la regla y sus factores circundantes:

  1. En la consola de Google SecOps, ve a Detección > Reglas y detecciones.

    El panel de reglas muestra metadatos de reglas, como Rule name, Rule type y Run frequency.

    Para obtener más detalles, consulta Cómo ver reglas en el panel de reglas.

  2. En el panel de reglas, usa la búsqueda para identificar las reglas que experimentan demoras prolongadas en la detección.

  3. En el caso de cualquier ejecución de regla en particular, existen varios factores que pueden afectar la latencia de detección. Las dimensiones como Rule type, Run frequency, Event type, Event time y Ingested time son buenas heurísticas para comprender por qué se pudo haber retrasado una detección en particular.

  4. Familiarízate con los siguientes temas para comprender cómo estos factores influyen en las demoras en la detección de reglas:

Métodos de generación de detección

Obtén información sobre cómo el sistema crea detecciones de reglas para comprender cómo el método de generación de detecciones afecta las demoras en la detección.

El sistema genera detecciones de reglas de las siguientes maneras:

  1. Streaming Engine

    El motor de transmisión es una canalización rápida que suele operar con una demora de menos de cinco minutos. Procesa reglas de un solo evento sin sección de coincidencias y sin conjuntos de datos externos, como listas de referencia o tablas de datos.

  2. Motor de consultas

    El motor de consultas procesa las reglas de la siguiente manera:

    • Reglas complejas de un solo evento:

      • Reglas de un solo evento que hacen referencia a listas de referencia o tablas de datos
      • Reglas de un solo evento con ventanas que usan una ventana de coincidencia con una condición simple Por ejemplo, "un evento en el que nuestro recuento de eventos es > 0". Estas reglas se ejecutan con una frecuencia alta (casi en tiempo real) a medida que se incorporan datos nuevos y se ponen a disposición para el procesamiento de reglas.

    • Reglas de varios eventos: Estas reglas consultan datos en bloques de tiempo de evento (de 10 minutos, por hora y por día), según una programación que establezcas.
      Por ejemplo, para una programación de 10 minutos, la regla vuelve a consultar los bloques de tiempo de evento después de 5 a 8 horas y de 24 a 48 horas, según los plazos de procesamiento ascendentes.

  3. Las reglas se ejecutan en relación con los datos históricos

    Para obtener más información, consulta Búsquedas retroactivas.

  4. Reenriquecimiento de eventos de UDM

    Para obtener más información, consulta Reenriquecimiento de eventos del UDM y Procesamiento del gráfico de contexto de entidades.

Limitaciones conocidas

Estas son algunas limitaciones estándar que contribuyen a las demoras en la detección de reglas:

  • A veces, los retrasos en el enriquecimiento pueden tardar más de lo esperado. El reprocesamiento del enriquecimiento hace que las ejecuciones de reglas posteriores vuelvan a evaluar los datos. El sistema ejecuta varios procesos de enriquecimiento, y el enriquecimiento puede actualizar los eventos del UDM hasta 24 horas después de que se hayan procesado.
  • Las reglas de varios eventos suelen unir datos contextuales que llegan muchas horas después de la hora del evento principal. La latencia alta en estos datos contextuales puede hacer que interactúen el procesamiento del re-enrichment y las repeticiones de reglas, lo que genera una detección retrasada. Si bien Google SecOps usa esta función para controlar los datos que llegan con mucho retraso, aparece como un lapso de tiempo grande entre la ventana de detección (bloque de tiempo del evento) y la hora de creación de la alerta.
  • Las reglas adaptadas al contexto son aquellas que se basan en fuentes de enriquecimiento, como los alias de recursos y de identidades, o el gráfico de contexto de entidades. Debido a que estas reglas dependen de varias fuentes de eventos, son más susceptibles a la latencia alta.
  • El sistema vuelve a ejecutar las reglas entre 5 y 8 horas, y de nuevo entre 24 y 48 horas después de la ejecución inicial de la regla. Estos dos replays de reglas separados se activan según los tiempos de ejecución de la canalización de reprocesamiento.
  • Para conocer otros límites de detección, consulta Acerca de los límites de detección.

Soluciona problemas de retrasos en la detección de reglas

Soluciona los problemas de retrasos en la detección de reglas a través de un proceso de eliminación.

Sigue este enfoque sugerido para investigar y solucionar problemas de retrasos en la detección de reglas:

  1. Verifica si hay demoras evidentes:

    Determina si existe alguna demora en la transferencia:

    1. En la consola de Google SecOps, ve a Detección > Reglas y detecciones.

    2. Busca la regla que deseas analizar en el panel de reglas.

    3. Compara el Event time con el Ingested time.

      Por ejemplo, para una detección de regla en particular, si existe una gran brecha entre el Event time y el Ingested time, es probable que puedas atribuir la demora en la detección a una demora esperada.

  2. Revisa la hora de recopilación de la fuente de contexto:

    Verifica la hora de recopilación de la fuente de contexto.

    Las reglas adaptadas al contexto pueden incluir las siguientes fuentes de contexto. Verifica los horarios de recolección:

    • Son los campos derivados del enriquecimiento del UDM.
    • Eventos que incluyen un campo principal

    • Reglas que hacen referencia a un campo graph.entity

      Las reglas que hacen referencia al gráfico de contexto de la entidad (ECG) con la sintaxis graph.entity pueden causar una latencia particularmente alta. Por ejemplo, la canalización de ECG genera datos de contexto, un proceso que puede tardar 30 horas o, en algunos casos, hasta 8 días, según el tipo de datos.

    Para obtener más detalles, consulta Demoras en el procesamiento de datos.

  3. Examina la frecuencia de ejecución de la regla y la configuración de la ventana de coincidencias:

    • Frecuencia: Verifica la frecuencia de ejecución de la regla. Una regla configurada para ejecutarse con menos frecuencia naturalmente tiene demoras de detección más largas.
    • Período de coincidencia: Si una regla tiene un período de coincidencia, la demora mínima es la duración de ese período.
    • Relación entre la frecuencia y el período de correlación: Asegúrate de que la frecuencia de publicación sea compatible con el período de correlación. Por ejemplo, si el período de coincidencia es de 5 minutos, una frecuencia de ejecución de 10 minutos es aceptable. Sin embargo, si el período de coincidencia es superior a 10 minutos, usa la siguiente frecuencia de ejecución disponible, que es de 1 hora.

  4. Verifica si hay incidentes recientes:

    Busca incidentes recientes que podrían haber causado retrasos o problemas con los feeds de datos.

Sugerencias para reducir las demoras

Para actualizar la configuración de las reglas de detección, consulta Administra reglas con el editor de reglas.

Usa las siguientes técnicas para reducir las demoras siempre que sea posible:

  • Para las reglas sensibles a la latencia, usa las opciones de ejecución más frecuentes:

    • Aumenta la frecuencia de la regla:

      Para reducir las demoras, configura la frecuencia más alta posible según el tipo de regla y el período de coincidencia:

      • Para las reglas de eventos únicos, usa Casi en tiempo real.
      • Para las reglas de varios eventos con períodos de coincidencia de menos de 60 minutos, usa 10 minutos.
      • Para las reglas con períodos de coincidencia de 60 minutos o más, usa 1 hora o 24 horas, según corresponda.

      Para obtener más detalles, consulta Cómo establecer la frecuencia de ejecución.

    • Reduce la duración de la ventana de correlación:

      Reducir la ventana de coincidencia no afecta directamente la latencia, pero puede aumentar la eficiencia estableciendo la demora mínima.

  • Evita los datos que llegan tarde:

    Los datos que llegan tarde no se incluyen en la consulta inicial, y el sistema los procesa solo cuando vuelve a consultar su bloque de tiempo de eventos entre 5 y 8 horas después, lo que provoca demoras significativas. Por lo general, los datos a tiempo tienen un retraso de unos 20 minutos.

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

El tipo de regla, la frecuencia de ejecución y la velocidad de ingesta de Google SecOps son factores clave en las demoras de detección de reglas.

Los siguientes factores contribuyen a las demoras en la detección de reglas.

Tipos de reglas

Las reglas se dividen en dos categorías principales:

Reglas de eventos únicos

Dado que las reglas de un solo evento se ejecutan casi en tiempo real con un enfoque de transmisión, úsalas para minimizar las demoras siempre que sea posible.

Estas reglas detectan eventos únicos y no utilizan listas de referencia, tablas de datos, ventanas de coincidencias ni análisis de comportamiento de usuarios y entidades (UEBA). Estas reglas se ejecutan casi en tiempo real, de forma continua, y tienen los retrasos de detección más cortos.

Reglas complejas de evento único

Estas reglas son más susceptibles a las demoras en la detección porque incluyen períodos de coincidencia o listas de referencia:

  • Reglas de un solo evento con ventana

    Son reglas de evento único que incluyen un período de coincidencia y, por lo general, tienen un retraso un poco más largo que otras reglas de evento único. Por lo general, una ventana de coincidencia es un período durante el cual una regla examina uno o más eventos.

  • Consulta reglas de un solo evento

    Son reglas de evento único que incluyen listas de referencia o tablas de datos.

Reglas de varios eventos

Las reglas de varios eventos se ejecutan de forma programada, lo que genera demoras más largas debido al tiempo que transcurre entre las ejecuciones programadas.

  • Reglas de varios eventos

    Estas reglas examinan dos o más condiciones de eventos de UDM. Por lo general, tienen una ventana de coincidencias y varias condiciones.

  • Reglas adaptadas al contexto

    Las reglas basadas en el contexto te ayudan a unir datos adicionales de contexto de detección y entidades a tus eventos.

    • Estas reglas constan de dos o más fuentes de datos, en las que al menos una condición es un evento de entidad del UDM (en el que el evento del UDM es de tipo contexto, como user_context).
    • Las reglas adaptadas al contexto son las más sensibles a los datos que llegan tarde.
    • Por lo general, las reglas basadas en el contexto tienen las demoras más largas, ya que el sistema primero debe generar los datos de contexto necesarios, como los datos del gráfico de contexto de la entidad .
    • Para obtener más detalles, consulta Usa datos enriquecidos con contexto en las reglas.

Obtén más información sobre la diferencia entre las reglas de evento único y de evento múltiple.

Frecuencia de ejecución de la regla

La frecuencia de ejecución de la regla afecta directamente la demora en la detección.

  • Casi en tiempo real: Las reglas se ejecutan con mayor frecuencia para los datos en tiempo real. Esto solo se aplica a las reglas de evento único.
  • Otras frecuencias: Para otros tipos de reglas, puedes establecer las siguientes frecuencias:
    • La frecuencia de 10 minutos es válida para los períodos de coincidencia de menos de 60 minutos.
    • Las frecuencias de 1 y 24 horas son válidas para los períodos de coincidencia de menos de 48 horas.
    • La frecuencia de 24 horas es válida para todos los períodos de coincidencia de 48 horas o más.

Solución alternativa posible: Para lograr detecciones más rápidas, usa una frecuencia de ejecución más corta. Reducir la ventana de coincidencia no afecta directamente la latencia, pero puede aumentar la eficiencia estableciendo la demora mínima.

Período de las coincidencias

Si una regla tiene un período de coincidencia, la duración de este determina la demora mínima en la detección, ya que el sistema debe esperar a que se produzca todo el período.

Retraso en la transferencia

La demora en la transferencia hace referencia al tiempo que tarda Google SecOps en transferir los datos después de que ocurre el evento.

Si los datos llegan tarde, no se incluyen en la ventana de la consulta inicial. Una consulta de procesamiento histórico posterior la detecta, pero esto puede generar demoras de entre 5 y 8 horas.

Por ejemplo, el evento A (hora del evento: 9:03 a.m.) y el evento B (hora del evento: 9:05 a.m.) forman parte de una regla que busca dos eventos en un plazo de 30 minutos. Si el evento A llega a las 10:05 a.m. (1 hora de retraso), no se incluyen las búsquedas iniciales del bloque de 9:00 a 9:30 a.m. Una búsqueda de seguimiento para ese bloque entre las 2 p.m. y las 5 p.m. genera la detección, lo que provoca demoras de 5 a 8 horas.

Solución de problemas: Verifica que envíes datos a Google SecOps tan pronto como ocurra el evento. Cuando revises una detección, verifica con cuidado las marcas de tiempo de los eventos y la transferencia de datos del UDM.

Problemas con la zona horaria

La zona horaria predeterminada del SIEM de Google SecOps es UTC. Si los registros no incluyen una definición explícita de zona horaria, el sistema los interpreta como UTC. La interpretación incorrecta puede hacer que los registros se traten como si llegaran tarde, lo que genera retrasos en la detección, incluso si el sistema los recibe en tiempo real.

Por ejemplo, un registro con una hora del evento de las 10:00 a.m. (hora del este; 3:00 p.m. UTC) llega a las 3:05 p.m. UTC, pero no tiene una zona horaria. Si el registro no incluye una zona horaria, el sistema interpreta la hora del evento como las 10:00 a.m. (UTC). Luego, el sistema calcula una demora de 5 horas entre la hora del evento interpretada (10:00 UTC) y la hora de la transferencia real (15:05 UTC). Este retraso calculado activa retrasos en la detección porque las reglas priorizan el procesamiento en función de la transferencia en tiempo real.

Soluciones alternativas: Si la marca de tiempo del evento de los datos originales se encuentra en una zona horaria distinta de UTC, prueba una de las siguientes opciones:

Uniones contextuales

Las reglas de varios eventos que usan datos contextuales, como los campos de UEBA o del gráfico de contexto de la entidad, pueden experimentar demoras más largas. Primero, Google SecOps debe generar los datos contextuales.

Sistema de enriquecimiento

Google SecOps enriquece los eventos del UDM agregando datos contextuales de otras fuentes. Este proceso suele completarse en un plazo de 30 minutos. Los retrasos en la incorporación de estos datos enriquecidos a los eventos del UDM pueden aumentar los tiempos de detección.

Para verificar si una regla evalúa un campo enriquecido, revisa el Visor de eventos. Si la regla evalúa un campo enriquecido, es posible que la detección se retrase.

Para obtener más detalles, consulta Enriquecimiento de datos.

Creación de alias y enriquecimiento

El alias y el enriquecimiento son dos pasos del proceso de enriquecimiento de datos de seguridad de SecOps de Google que correlacionan y agregan datos de contexto a los registros de eventos. El alias encuentra las conexiones, y el enriquecimiento completa los campos del UDM con esos datos conectados. Los campos que se propagan con este proceso se denominan campos con alias o campos enriquecidos.

  • Creación de alias: Es el proceso de identificar y vincular diferentes nombres o identificadores para la misma entidad. Encuentra datos de contexto adicionales que describen un indicador. Por ejemplo, la creación de alias puede conectar un solo hostname (como alex-macbook) con otros indicadores relacionados, como su IP addresses y MAC addresses (de los registros de DHCP). La creación de alias también puede conectar un user ID (como alex) al job title y al employment status del usuario (a partir de los datos del contexto del usuario).
  • Enriquecimiento: Es el proceso que usa la información recopilada del alias para agregar contexto a un evento del UDM. Por ejemplo, cuando llega un evento nuevo con solo un IP address, el proceso de enriquecimiento usa los datos con alias para encontrar el hostname asociado (por ejemplo, alex-macbook) y completa el campo $udm.event.principal.hostname.

Google SecOps admite la creación de alias y el enriquecimiento de varios tipos de entidades, incluidos los activos (por ejemplo, nombres de host, direcciones IP, MAC), los usuarios, los procesos, los metadatos de hash de archivos, las ubicaciones geográficas y los recursos de la nube. Para obtener más detalles, consulta la descripción general del enriquecimiento y los alias del UDM.

Reenriquecimiento de eventos de UDM

  • Cambios en los datos subyacentes: Si los datos subyacentes cambian después de que se ingiere un evento, el sistema vuelve a procesar los datos históricos y actualiza los eventos hasta 24 horas después de la ingesta.

  • Actualizaciones del sistema de enriquecimiento: Si el sistema de enriquecimiento actualiza los metadatos de la entidad o el proceso, la ubicación geográfica de la IP o los indicadores de VirusTotal, el motor de reglas vuelve a evaluar estos bloqueos entre 24 y 48 horas después para capturar esas actualizaciones.
    Por ejemplo, un evento a las 9:03 a.m. tiene entity.asset.hostname = hostnameA, pero no tiene IP. Un registro de DHCP de las 8:55 a.m. muestra hostnameA = IP 1.2.3.4. El motor de reglas se ejecuta a las 9:10 a.m., y la regla no coincide. La canalización de procesamiento de enriquecimiento correlaciona hostnameA con 1.2.3.4 para ese período, y actualiza el evento del UDM. Ahora la regla coincide y el sistema crea una detección.

  • Datos de contexto retrasados: Si envías datos de contexto, como un hostname, un día después del registro inicial, el sistema vuelve a enriquecer el evento del UDM. Luego, se vuelven a ejecutar las reglas que buscan estos datos enriquecidos y se crea una detección. Esta función garantiza que el sistema cree detecciones incluso cuando el contexto se retrasa.

  • Cambios en los datos de enriquecimiento: Los cambios en los datos de enriquecimiento pueden hacer que una regla coincida más adelante, incluso si no lo hizo inicialmente.
    Por ejemplo, un evento a las 9:03 a.m. tiene entity.ip_geo_artifact.country_or_region = USA. El motor de reglas se ejecuta a las 9 a.m., consulta el período de 9 a.m. a 10 a.m. y la regla no coincide. Más adelante, el reprocesamiento del enriquecimiento actualiza la ubicación geográfica a Canadá. Cuando la regla se ejecuta de nuevo, ahora coincide y el sistema crea una detección.

Procesamiento de gráficos de contexto de entidades

El sistema genera y agrega información del gráfico de contexto de entidades (ECG) a los datos de registro para proporcionar contexto, por ejemplo, indicadores de compromiso (IOC) o datos de contexto de activos. Dado que la canalización de ECG se basa principalmente en el procesamiento por lotes, la información del contexto de la entidad a menudo se actualiza solo después de que la ejecución de una regla crea una detección.

Cazas retro

Cuando ejecutas una regla en relación con los datos históricos con una búsqueda retroactiva, el sistema solo crea la detección después de que finaliza el proceso de búsqueda retroactiva. Este proceso puede tardar una cantidad de tiempo significativa, lo que provoca una demora en la detección.

Ejemplo de un proceso de actualización retroactiva:

  1. Evento inicial: Llega un evento a la 1:00 p.m. con ip_address = 10.0.0.5. En este momento, se desconoce el hostname.
  2. Llega la fuente de alias: A las 2:30 p.m. (más de una hora después), llega un registro de DHCP para la 1:00 p.m., que vincula 10.0.0.5 a workstation-123.
  3. Enriquecimiento retroactivo: El sistema de alias procesa este nuevo vínculo. Actualiza de forma retroactiva el evento de UDM desde la 1:00 p.m., y enriquece el campo $udm.event.principal.hostname que antes estaba vacío con el valor workstation-123.
  4. Detección: Las repeticiones de reglas posteriores ven el valor enriquecido (workstation-123) y pueden activar detecciones que antes se omitieron.

Nota: No puedes distinguir las métricas de supervisión de latencia para las reglas de detección en vivo de las reglas de detección de Retrohunt. Para evitar sesgar las métricas de supervisión de la latencia de detección, no uses una regla activa para simular una regla de búsqueda retroactiva. Como práctica recomendada, crea una regla de detección exclusiva y ejecútala como regla de búsqueda retroactiva.

Listas de referencia

Las ejecuciones de reglas siempre usan la versión más reciente de una lista de referencia. Cuando se vuelvan a ejecutar las reglas programadas, el sistema podrá crear nuevas detecciones basadas en el contenido actualizado de la lista de referencia. Es posible que estas detecciones aparezcan tarde porque se basan en datos que se incorporaron antes de la actualización de la lista de referencia.

Para reducir las demoras en la detección, haz lo siguiente:

  • Envía datos de registro a Google SecOps tan pronto como ocurra el evento.
  • Revisa las reglas de auditoría para determinar si se deben usar datos de no existencia o enriquecidos con contexto.
  • Configura una frecuencia de ejecución más baja.

Reglas de no existencia

El sistema espera al menos una hora antes de ejecutar reglas que verifican la inexistencia (por ejemplo, reglas que contienen !$e o #e=0), lo que garantiza que los datos tengan tiempo para llegar.

Demoras en el procesamiento de datos

Es posible que el sistema siga procesando datos incluso después de crear una detección inicial, lo que podría generar detecciones nuevas o actualizadas. Para obtener más información, consulta Cuándo se activan las repeticiones de reglas.

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