Acerca de los retrasos en la detección de reglas

Disponible en:

En este documento se explican los retrasos en la detección de reglas en Google Security Operations, se identifican los factores que contribuyen a estos retrasos, se describen los enfoques para solucionar problemas y se sugieren técnicas para reducir los retrasos siempre que sea posible.

Reglas de detección

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

Retrasos previstos e imprevistos

Las detecciones de reglas siempre tienen un cierto retraso, que va desde casi en tiempo real hasta unos minutos o muchas horas. Estos retrasos dependen de factores como el tipo de regla, la frecuencia de ejecución y el método de generación de detecciones. En este documento se analizan estos y otros factores que pueden provocar retrasos.

Las clasificamos como previstas o imprevistas.

  • Retrasos previstos: estos retrasos se deben al proceso de ingestión y a las opciones de configuración que elijas al configurar 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 detecciones, las limitaciones conocidas y otros factores predecibles.
    Puedes minimizar estos retrasos cambiando o ajustando las configuraciones de las reglas de detección, tal como se describe en este documento.
    Para obtener más información, consulta Consejos para reducir los retrasos.

  • Retrasos imprevistos: se trata de retrasos específicos de reglas o eventos causados por muchos factores, como retrasos en la llegada de datos de eventos a Google SecOps, lentitud transitoria en el procesamiento de las canalizaciones de los servicios de Google SecOps, reenriquecimiento y otros retrasos en el tratamiento de datos.

Analizar los retrasos en la detección de reglas

Para analizar los retrasos en la detección de reglas, busca información sobre la regla y los factores que la rodean:

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

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

    Para obtener más información, consulta el artículo Ver reglas en el panel de control de reglas.

  2. En el panel de control Reglas, usa la búsqueda para identificar las reglas que experimentan retrasos de detección prolongados.

  3. En cualquier ejecución de una regla concreta, hay varios factores que pueden influir en la latencia de detección. Las dimensiones Rule type, Run frequency, Event type, Event time y Ingested time son buenas heurísticas para entender por qué se ha podido retrasar una detección concreta.

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

Métodos de generación de detecciones

Consulta cómo crea el sistema detecciones de reglas para saber cómo afecta el método de generación de detecciones a los retrasos de detección.

El sistema genera detecciones de reglas de las siguientes formas:

  1. Streaming Engine

    El motor de streaming es una canalización rápida que suele funcionar con un retraso de menos de cinco minutos. Procesa reglas de un solo evento con sin sección de coincidencia 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 de un solo evento complejas:

      • Reglas de un solo evento que hacen referencia a listas de referencia o tablas de datos.
      • Reglas de un solo evento con ventana que usan una ventana de coincidencia con una condición simple. Por ejemplo, "un evento en el que nuestro recuento de eventos sea > 0". Estas reglas se ejecutan con una frecuencia de consulta alta (en tiempo real) a medida que se ingieren 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 (10 minutos, una hora o un día) según una programación que definas.
      Por ejemplo, en 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, en función de los plazos de procesamiento de origen.

  3. Reglas ejecutadas según el historial de datos

    Para obtener más información, consulta Cazas retro.

  4. Reenriquecimiento de eventos de UDM

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

Limitaciones conocidas

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

  • A veces, los retrasos en el enriquecimiento pueden tardar más de lo previsto. El reprocesamiento del enriquecimiento hace que las ejecuciones de reglas posteriores vuelvan a evaluar los datos. El sistema realiza varias ejecuciones de enriquecimiento. La última se produce tres días después de la hora del evento.
  • Las reglas de varios eventos suelen combinar datos contextuales que llegan muchas horas después de la hora del evento principal. Una latencia alta en estos datos contextuales puede provocar que interactúen el procesamiento de reenriquecimiento y las repeticiones de reglas, lo que retrasa la detección. Aunque Google SecOps usa esta función para gestionar los datos que llegan con mucho retraso, aparece como un intervalo de tiempo amplio entre la ventana de detección (bloque de tiempo del evento) y la hora de creación de la alerta.
  • Las reglas contextuales son reglas que se basan en fuentes de enriquecimiento, como los alias de activos e identidades, o el gráfico de contexto de entidades. Como 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 de nuevo entre 24 y 48 horas después de la ejecución inicial de la regla. Estas dos repeticiones de reglas independientes se producen en función de los tiempos de ejecución de la canalización de reprocesamiento.

Solucionar problemas de retrasos en la detección de reglas

Soluciona los problemas de retrasos en la detección de reglas mediante un proceso de eliminación.

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

  1. Comprueba si hay retrasos evidentes:

    Determina si hay algún retraso en la ingesta:

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

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

    3. Compara el Event time con el Ingested time.

      Por ejemplo, en una detección de una regla concreta, si hay un gran intervalo entre Event time y Ingested time, es probable que la demora en la detección se deba a un retraso esperado.

  2. Revisa la hora de recogida de la fuente de contexto:

    Comprueba la hora de recogida de la fuente de contexto.

    Las reglas contextuales pueden incluir las siguientes fuentes de contexto. Consulta los horarios de recogida:

    • Campos derivados del enriquecimiento de 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 provocar una latencia especialmente 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, en función del tipo de datos.

    Para obtener más información, consulta Retrasos en el tratamiento de datos.

  3. Examine la frecuencia de ejecución de la regla y la configuración del periodo de coincidencia:

    • Frecuencia: comprueba la frecuencia de ejecución de la regla. Una regla configurada para ejecutarse con menos frecuencia tiene, naturalmente, retrasos de detección más largos.
    • Ventana de coincidencia: si una regla tiene una ventana de coincidencia, el retraso mínimo es la duración de esa ventana.
    • Relación entre la frecuencia y la ventana de coincidencia: asegúrese de que la frecuencia de ejecución sea compatible con la ventana de coincidencia. Por ejemplo, si la ventana de coincidencia es de 5 minutos, una frecuencia de ejecución de 10 minutos es aceptable. Sin embargo, si la ventana de coincidencia es de más de 10 minutos, usa la siguiente frecuencia de ejecución disponible, que es de 1 hora.

  4. Comprueba si hay incidentes recientes:

    Busque incidentes recientes que hayan podido provocar retrasos o problemas con los feeds de datos.

Consejos para reducir los retrasos

Para actualizar las configuraciones de las reglas de detección, consulta Gestionar reglas con el editor de reglas.

Utiliza las siguientes técnicas para reducir los retrasos siempre que sea posible:

  • En el caso de las reglas sensibles a la latencia, utiliza las opciones de ejecución más frecuentes:

    • Aumentar la frecuencia de la regla:

      Para reducir los retrasos, configura la frecuencia más alta posible en función del tipo de regla y de la ventana de coincidencia:

      • En el caso de las reglas de un solo evento, use Casi en tiempo real.
      • En el caso de las reglas de varios eventos con ventanas de coincidencia de menos de 60 minutos, usa 10 minutos.
      • En el caso de las reglas con ventanas de coincidencia de 60 minutos o más, usa 1 hora o 24 horas, según corresponda.

      Para obtener más información, consulta Definir la frecuencia de ejecución.

    • Reducir la duración de la ventana de coincidencia:

      Las ventanas de coincidencia más pequeñas son más eficientes. Cambia el periodo 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 evento entre 5 y 8 horas más tarde, lo que provoca retrasos significativos. Los datos de puntualidad suelen tener un retraso de unos 20 minutos.

Factores que contribuyen a los retrasos en la detección de reglas

El tipo de regla, la frecuencia de ejecución y la velocidad de ingestión de Google SecOps son factores clave en los retrasos de detección de reglas.

Los siguientes factores contribuyen a los retrasos en la detección de reglas.

Tipos de reglas

  • Reglas de un solo evento:

    Como las reglas de un solo evento se ejecutan casi en tiempo real mediante un enfoque de streaming, úsalas para minimizar los retrasos siempre que sea posible.

    • Reglas sencillas de un solo evento

      Estas reglas detectan eventos únicos y no usan listas de referencia, tablas de datos, ventanas de coincidencia ni analíticas del comportamiento de usuarios y entidades (UEBA). Estas reglas se ejecutan casi en tiempo real, en forma de streaming, y tienen los retrasos de detección más cortos.

    • Reglas complejas de un solo evento

      • Reglas de un solo evento de ventana

        Se trata de reglas de un solo evento que incluyen una ventana de coincidencia y que suelen tener un retraso ligeramente mayor que otras reglas de un solo evento. Una ventana de coincidencia es, por lo general, un periodo durante el cual una regla examina uno o varios eventos.

      • Consultar reglas de un solo evento

        Se trata de reglas de un solo evento 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 provoca retrasos más largos 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. Normalmente, tienen una ventana de coincidencia y varias condiciones.

    • Reglas contextuales

      Las reglas contextuales te ayudan a comprender tanto los patrones de comportamiento de la telemetría como el contexto de las entidades afectadas por esos patrones.

      • Estas reglas constan de dos o más condiciones, pero al menos una de ellas es un evento de entidad de UDM (donde el evento de UDM es de tipo context, como user_context).
      • Este tipo de reglas tienen retrasos más largos y no es raro que las detecciones tarden unos días.
      • Las reglas contextuales suelen tener los mayores retrasos porque el sistema primero debe generar los datos de contexto necesarios.

Consulta más información sobre la diferencia entre las reglas de un solo evento y las de varios eventos.

Frecuencia de ejecución de reglas

La frecuencia de ejecución de las reglas influye directamente en el retraso de la detección.

  • Casi en tiempo real: las reglas se ejecutan con más frecuencia para los datos en tiempo real y se ejecutan constantemente. Esto solo se aplica a las reglas de un solo evento.
  • Otras frecuencias: en otros tipos de reglas, puedes definir las siguientes frecuencias:
    • La frecuencia de 10 minutos es válida para ventanas de coincidencia de menos de 60 minutos.
    • Las frecuencias de 1 y 24 horas son válidas para ventanas de coincidencia de menos de 48 horas.
    • La frecuencia de 24 horas es válida para todas las ventanas de coincidencia de 48 horas o más.

Solución alternativa: para conseguir detecciones más rápidas, usa una frecuencia de ejecución más corta y una ventana de coincidencia más pequeña. Si usas ventanas de coincidencia más cortas (menos de una hora), podrás hacer más pruebas.

Ventana de coincidencia

Si una regla tiene una ventana de coincidencia, la duración de la ventana determina el retraso mínimo de detección, ya que el sistema debe esperar a que se produzca toda la ventana.

Retraso de ingestión

La latencia de ingestión es el tiempo que tarda Google SecOps en ingerir los datos después de que se produzca el evento.

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

Por ejemplo, el evento A (hora del evento: 9:03) y el evento B (hora del evento: 9:05) forman parte de una regla que busca dos eventos en un plazo de 30 minutos. Si el evento A llega a las 10:05 (una hora tarde), no se incluirá en las consultas iniciales del bloque de 9:00 a 9:30. Una consulta de seguimiento de ese bloque entre las 14:00 y las 17:00 genera la detección, lo que provoca retrasos de entre 5 y 8 horas.

Solución de problemas: comprueba que envías datos a Google SecOps en cuanto se produce el evento. Cuando revise una detección, compruebe detenidamente las marcas de tiempo del evento de UDM y de la ingestión.

Problemas con la zona horaria

La zona horaria predeterminada de SIEM de Google SecOps es UTC. Si los registros no incluyen una definición de zona horaria explícita, el sistema los interpreta como UTC. Si se interpretan de forma incorrecta, los registros se pueden tratar como si llegaran tarde, lo que provoca retrasos en la detección, aunque el sistema los reciba en tiempo real.

Por ejemplo, un registro con la hora del evento 10:00 (hora del este) (15:00 UTC) llega a las 15:05 UTC, pero no tiene zona horaria. Si el registro no tiene una zona horaria, el sistema interpreta la hora del evento como las 10:00 UTC. A continuación, el sistema calcula un retraso de 5 horas entre la hora del evento interpretada (10:00 UTC) y la hora de ingestión real (15:05 UTC). Este retraso calculado provoca retrasos en la detección, ya que las reglas priorizan el procesamiento en función de la ingesta en tiempo real.

Soluciones alternativas: Si la marca de tiempo del evento de los datos originales está 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, ponte en contacto con el equipo de Asistencia para anularla.
  • También puedes usar un procesador de BindPlane para corregir la marca de tiempo y darle el formato UTC, o bien añadir el indicador de zona horaria adecuado. Para obtener más información, consulta Modificar las marcas de tiempo del cuerpo de los registros con BindPlane.

Uniones contextuales

Las reglas de varios eventos que usan datos contextuales, como UEBA o Gráfico de entidades, pueden experimentar retrasos más largos. Google SecOps debe generar primero los datos contextuales.

Sistema de enriquecimiento

Google SecOps enriquece los eventos de UDM añadiendo datos contextuales de otras fuentes. Este proceso suele completarse en un plazo de 30 minutos. Si se retrasa la adición de estos datos enriquecidos a los eventos de UDM, los tiempos de detección pueden aumentar.

Para comprobar si una regla está evaluando un campo enriquecido, consulta el Visor de eventos. Si la regla evalúa un campo enriquecido, la detección puede retrasarse.

Para obtener más información, consulta Enriquecimiento de datos.

Creación de alias y enriquecimiento

La creación de alias y el enriquecimiento son dos pasos del proceso de enriquecimiento de datos de seguridad de Google SecOps que correlacionan y añaden datos de contexto a los registros de eventos. La creación de alias busca las conexiones y el enriquecimiento rellena los campos de UDM con esos datos conectados. Los campos que se rellenan mediante este proceso se denominan campos con alias o campos enriquecidos.

  • Creación de alias: proceso de identificar y vincular diferentes nombres o identificadores de la misma entidad. Busca datos de contexto adicionales que describan un indicador. Por ejemplo, la creación de alias puede conectar un único hostname (como alex-macbook) con otros indicadores relacionados, como su IP addresses, MAC addresses (de los registros 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 recogida de la creación de alias para añadir contexto a un evento de 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 rellena el campo $udm.event.principal.hostname.

Google SecOps admite el uso de alias y el enriquecimiento de varios tipos de entidades, como recursos (por ejemplo, nombres de host, IPs o MACs), usuarios, procesos, metadatos de hash de archivos, ubicaciones geográficas y recursos de la nube. Para obtener más información, consulta el artículo Descripción general del enriquecimiento y la creación de alias de UDM.

Reenriquecimiento de eventos de UDM

  • Cambios en los datos subyacentes: después de que el sistema ingiera un evento, si los datos subyacentes cambian tras la ingestión, 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 una entidad o un proceso, la geolocalización de una IP o los indicadores de VirusTotal, el motor de reglas vuelve a evaluar estos bloques entre 24 y 48 horas después para registrar esas actualizaciones.
    Por ejemplo, un evento a las 9:03 tiene entity.asset.hostname = hostnameA, pero no tiene IP. Un registro de DHCP de las 8:55 muestra hostnameA = IP 1.2.3.4. El motor de reglas se ejecuta a las 9:10 y la regla no coincide. El flujo de procesamiento de enriquecimiento correlaciona hostnameA con 1.2.3.4 en ese periodo y actualiza el evento de 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, tres días después del registro inicial, el sistema vuelve a enriquecer el evento de UDM. Las reglas que buscan estos datos enriquecidos se vuelven a ejecutar y crean una detección. Esta función asegura que el sistema cree detecciones incluso cuando el contexto se retrase.

  • Cambios en los datos de enriquecimiento: los cambios en los datos de enriquecimiento pueden hacer que una regla coincida más adelante, aunque no lo hiciera inicialmente.
    Por ejemplo, un evento a las 9:03 tiene entity.ip_geo_artifact.country_or_region = USA. El motor de reglas se ejecuta a las 9:10, consulta el periodo de 9:00 a 10:00 y la regla no coincide. Más adelante, el reprocesamiento del enriquecimiento actualiza la geolocalización a Canadá. Cuando la regla se vuelve a ejecutar, ahora coincide y el sistema crea una detección.

Procesamiento de gráficos de contexto de entidad

El sistema genera y añade información del gráfico de contexto de entidades (ECG) a los datos de registro para proporcionar contexto, como indicadores de compromiso (IOCs) o datos de contexto de activos. Como el flujo de trabajo de ECG se basa principalmente en el procesamiento por lotes, la información del contexto de la entidad a menudo solo se actualiza después de que la ejecución de una regla cree una detección.

Cazas retro

Cuando ejecutas una regla en el historial de datos mediante una búsqueda retrospectiva, el sistema solo crea la detección una vez que finaliza el proceso de búsqueda retrospectiva. Este proceso puede llevar mucho tiempo, lo que provoca un retraso en la detección.

Ejemplo de un proceso de actualización retroactivo:

  1. Evento inicial: un evento llega a las 13:00 con ip_address = 10.0.0.5. Por el momento, se desconoce el hostname.
  2. Llega el alias de la fuente: a las 14:30 (más de una hora después), llega un registro DHCP de las 13:00 que vincula 10.0.0.5 con workstation-123.
  3. Enriquecimiento retroactivo: el sistema de alias procesa este nuevo enlace. Actualiza retroactivamente el evento de UDM de las 13:00, enriqueciendo el campo $udm.event.principal.hostname, que antes estaba vacío, con el valor workstation-123.
  4. Detección: en las ejecuciones posteriores de la regla (ejecuciones de limpieza), ahora se ve el valor enriquecido (workstation-123) y se pueden activar detecciones que antes se habían pasado por alto.

Nota: No puede distinguir las métricas de monitorización de la latencia de las reglas de detección en directo de las reglas de detección retroactiva. Para evitar que se sesguen las métricas de monitorización de la latencia de detección, no uses una regla activa para simular una regla de búsqueda retrospectiva. Como práctica recomendada, crea una regla de detección específica y ejecútala como regla de búsqueda retrospectiva.

Listas de referencias

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

Para reducir los retrasos 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 quieres usar datos de no existencia o datos enriquecidos con 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 las reglas que comprueban la inexistencia (por ejemplo, las reglas que contienen !$e o #e=0) para asegurarse de que los datos tengan tiempo de llegar.

Retrasos en el tratamiento de datos

El sistema puede seguir procesando datos incluso después de crear una detección inicial, lo que puede dar lugar a detecciones nuevas o actualizadas. Para obtener más información, consulta Cuándo se activan las repeticiones de reglas.

¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.