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

Se admite en los siguientes sistemas operativos:

Google SecOps SIEM

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 para solucionar 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 recurso. Las reglas también generan detecciones basadas en detecciones generadas anteriormente.

Retrasos previstos y no previstos

Las detecciones de reglas siempre tienen cierto retraso, que va desde casi en tiempo real hasta unos minutos o muchas horas. 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 transferencia y las opciones de configuración que elijas cuando establezcas la regla de detección.
  Por ejemplo, crear una detección lleva tiempo. 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 estas demoras 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 la llegada de los datos del evento 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.

   En el panel de reglas, se muestran 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. Para 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
   • Limitaciones conocidas
   • Factores que contribuyen a 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 (en tiempo real) a medida que se ingresan 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, por día), según un programa que establezcas.
     Por ejemplo, para un programa 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 detalles, 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 último se realiza tres días después de la hora del evento.
• 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 las SecOps de Google usan 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. Dado que estas reglas dependen de varias fuentes de eventos, son más susceptibles a la latencia.
• El sistema vuelve a ejecutar las reglas entre 5 y 8 horas, y, luego, entre 24 y 48 horas después de la ejecución inicial de las reglas. Estas dos repeticiones de reglas independientes se producen según los tiempos de ejecución de la canalización de reprocesamiento.

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 Event time y 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:

    Las ventanas de coincidencia más pequeñas son más eficientes. Cambia un período de correlación de 60 minutos a 59 minutos para habilitar el procesamiento de 10 minutos.

• 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 aproximadamente 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

• Reglas de un solo evento:

  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.

  • Reglas simples de un solo evento

    Estas reglas detectan eventos únicos y no utilizan listas de referencia, tablas de datos, ventanas de coincidencia ni análisis del 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.

    Nota: Puedes aplicar la supresión de alertas a reglas de un solo evento con la opción suppression_window.

  • Reglas complejas de un solo evento

    • Reglas de eventos únicos de la 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 eventos múltiples:

  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 comprender los patrones de comportamiento en la telemetría y el contexto de las entidades afectadas a partir de esos patrones.

    • Estas reglas constan de dos o más condiciones, pero al menos una de ellas es un evento de entidad del UDM (en el que el evento del UDM es de tipo context, como user_context).
    • Estos tipos de reglas tienen demoras más largas, y no es raro que las detecciones tarden unos días.
    • Por lo general, las reglas basadas en el contexto tienen las demoras más largas porque el sistema primero debe generar los datos de contexto necesarios.

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 y se ejecutan de forma constante. 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 mayores o iguales a 48 horas.

Solución alternativa posible: Para lograr detecciones más rápidas, usa una frecuencia de ejecución más corta y una ventana de coincidencia más pequeña. El uso de períodos de coincidencia más cortos (menos de una hora) permite ejecuciones más frecuentes.

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:

• Actualiza la zona horaria del evento de los datos originales.
• Si no puedes actualizar la zona horaria en la fuente de registro, comunícate con el equipo de asistencia al cliente para anular la zona horaria.
• También puedes usar un procesador de BindPlane para corregir la marca de tiempo y darle el formato de UTC, o bien agregar el indicador de zona horaria adecuado. Para obtener más información, consulta Cómo modificar las marcas de tiempo del cuerpo del registro con BindPlane.

Uniones contextuales

Las reglas de varios eventos que usan datos contextuales, como UEBA o Entity Graph, 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 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 se retrase la detección.

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 a través de este proceso se conocen como 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, MAC addresses (de los registros de DHCP) o un user ID (como alex) con su job title y employment status (de los datos de 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 para varios tipos de entidades, incluidos los activos (por ejemplo, nombres de host, IPs, MACs), los usuarios, los procesos, los metadatos de hash de archivos, las ubicaciones geográficas y los recursos de Cloud. 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: Después de que el sistema ingiere un evento, si los datos subyacentes cambian después de la ingestión del evento, el sistema vuelve a procesar los datos históricos y actualiza los eventos durante un máximo de 24 horas.

• 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, por ejemplo, tres días 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 nuevamente 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. Por el 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 ejecuciones posteriores de reglas (ejecuciones de limpieza) ahora ven el valor enriquecido (workstation-123) y pueden activar detecciones que antes se omitían.

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 búsqueda retroactiva. 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 en cuanto se produzca el evento.
• Revisa las reglas de auditoría para determinar si se deben usar datos de no existencia o enriquecidos por el 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.