Usa la simulación de eventos para evaluar la cobertura de detección

Esta guía está dirigida a los equipos de ingeniería de detección y SOC que desean entregar de forma programática secuencias de amenazas realistas en la canalización de transferencia activa con la simulación de eventos. La simulación de eventos es un marco de trabajo de simulación de amenazas y evaluación de la cobertura de detección integrado directamente en Google Security Operations. Como capacidad fundamental de la arquitectura del Agente de ingeniería de detección (DEA), la simulación de eventos verifica el ciclo de vida de la detección, desde la transferencia y normalización de la telemetría hasta la correlación y las alertas de varios eventos, y preserva los flujos de trabajo operativos del SOC.

Al conectar las herramientas de MCP de Google SecOps con asistencia de IA (como Gemini o Claude Code), la simulación de eventos automatiza el ciclo de vida de la ingeniería de detección: ingiere informes de amenazas sin procesar, estructura las tácticas de amenazas en oportunidades de detección de amenazas (TDO) prácticas, sintetiza telemetría realista del Modelo de datos unificado (UDM), evalúa la cobertura de las reglas existentes de YARA-L 2.0 en reglas de un solo evento, de varios eventos y compuestas, y redacta nuevas reglas de detección para cerrar las brechas de seguridad identificadas.

Casos de uso principales

La simulación de eventos y el agente de ingeniería de detección (DEA) admiten los siguientes flujos de trabajo principales:

  • Pruebas de transferencia y normalización de canalizaciones activas: Transmite de forma programática telemetría sintética del modelo de datos unificados (UDM) directamente a través de canalizaciones de transferencia activas, módulos de enriquecimiento de contexto y gráficos de entidades para lograr una preparación completa para la detección de extremo a extremo.
  • Cobertura continua de amenazas y validación de regresión: Evalúa las reglas administradas y personalizadas de YARA-L 2.0 en función de tácticas, técnicas y procedimientos (TTP) específicos de adversarios, y establece prueba de unidades automatizadas y pruebas de regresión continuas en conjuntos de reglas antes de la implementación en producción.
  • Generación de telemetría sintética: Produce eventos del UDM válidos según el esquema que simulan cadenas de ataques complejos (como la explotación de aplicaciones web, el acceso a credenciales o el movimiento lateral) para probar reglas en entornos de producción reales.

Beneficios clave y propuesta de valor

  • Validación proactiva de la postura y las amenazas: Prueba las reglas de YARA-L 2.0 en relación con las vulnerabilidades y los comportamientos de los actores de amenazas divulgados recientemente antes de que se produzcan incidentes en el mundo real.
  • Garantía de síntesis e ingesta directas: Sintetiza eventos del UDM válidos para el esquema directamente a partir del texto de inteligencia contra amenazas que fluye a través de la canalización de ingesta en vivo de Google SecOps (ImportEvents) para someterse a una normalización completa, una alineación de campos y un enriquecimiento del contexto.
  • Telemetría aislada y seguridad de producción: Los eventos sintéticos generados por la simulación de eventos se etiquetan con metadatos de simulación (etiquetas de transferencia SIMULATION) y generan detecciones etiquetadas como INCLUDES_SIMULATION_DATA. Las detecciones de datos simulados se excluyen automáticamente de los casos de producción, las guías, los flujos de análisis de riesgos (RBA) y los paneles de clasificación de alertas.

Comprende los conceptos y la arquitectura de la simulación de eventos

Los siguientes componentes principales de la simulación de eventos y el framework del agente de ingeniería de detección (DEA) son esenciales para la implementación:

  • Oportunidad de detección de amenazas (TDO): Es un modelo de datos formalizado que actúa como una prueba unitaria que identifica, prioriza y categoriza las TTP específicas de los adversarios que se extraen de los informes de inteligencia contra amenazas o las descripciones en lenguaje natural. Los identificadores de TDO cumplen con requisitos de formato estrictos (por ejemplo, t01, t02, que coinciden con la expresión regular ^[a-zA-Z]\d{2}$).
  • Eventos sintéticos del UDM: Son eventos de registro generados por máquinas y formateados estrictamente según el esquema del modelo de datos unificado (UDM) de Google SecOps. Estos eventos simulan acciones específicas del atacante necesarias para probar la lógica de las reglas de detección con ImportEvents.
  • Etiquetado de simulación y etiquetado de alertas: Los eventos sintéticos tienen una etiqueta de transferencia (metadata.ingestion_labels["SIMULATION"]). En el proto Collection, las detecciones que resultan de los datos simulados se marcan en tags con INCLUDES_SIMULATION_DATA. Los campos .proto de metadatos de detección incluyen simulated_event_count (cantidad total de eventos simulados que contribuyen a la detección) y simulated_event_names (el conjunto de valores de etiquetas SIMULATION de los eventos que contribuyen).
  • Visibilidad de los datos y supresión de la búsqueda: Las búsquedas estándar del UDM de Google SecOps suprimen los eventos etiquetados como simulaciones de forma predeterminada. Las búsquedas y las vistas de la IU pueden incluir de forma explícita datos simulados con el parámetro de configuración simulated_data_visibility o el botón de activación de las preferencias del usuario.
  • Operaciones de larga duración (LRO): Es un mecanismo de ejecución de backend asíncrono (evaluate_rule_coverage_long_running) que coordina lotes de ejecución de reglas a pedido sin encontrar tiempos de espera de HTTP de la API.

Antes de comenzar

La simulación de eventos comparte los requisitos previos del entorno subyacente, los permisos de IAM y la configuración del servidor con el kit de herramientas del agente de Ingeniería de detección. Antes de comenzar, confirma que se cumplan los siguientes requisitos:

Cómo se inserta la telemetría sintética

La telemetría sintética se inserta en Google SecOps con el kit de herramientas del agente de MCP o con llamadas directas a la API de Chronicle:

  1. Invocación del subagente de MCP: Llama a la herramienta generate_synthetic_events con los IDs de la oportunidad de detección de amenazas (TDO) objetivo y las especificaciones de comportamiento.
  2. Extremo de la API de Chronicle: Transmite de forma programática eventos de UDM sintéticos con el extremo de API de REST de ImportEvents (POST /v1alpha/projects/{project}/locations/{location}/instances/{instance}/events:import).
  3. Etiquetado de simulación: Cuando se llama directamente a la API de ImportEvents, los llamadores deben incluir manualmente metadata.ingestion_labels que contenga la clave "SIMULATION" y un identificador único de simulación o ejecución de prueba como el valor en la carga útil de la solicitud (por ejemplo, "key": "SIMULATION", "value": "TEST123" o "t01"). La API no completa automáticamente las etiquetas de simulación.

Ejemplo de llamada de transferencia de UDM

Solicitud HTTP:

POST https://chronicle.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/events:import

Cuerpo de la solicitud:

{
  "events": [
    {
      "metadata": {
        "event_type": "PROCESS_LAUNCH",
        "event_timestamp": "2026-08-05T20:00:00Z",
        "ingestion_labels": [
          {
            "key": "SIMULATION",
            "value": "TEST123"
          }
        ]
      },
      "principal": {
        "user": {
          "userid": "victim_user"
        }
      },
      "target": {
        "process": {
          "command_line": "powershell.exe -ExecutionPolicy Bypass -File dump.ps1"
        }
      }
    }
  ]
}

La simulación de eventos inserta eventos de UDM sintetizados directamente con ImportEvents, lo que permite evaluar la normalización de UDM, el enriquecimiento del contexto y la detección de reglas. El análisis de registros sin procesar se prueba durante la generación de eventos sintéticos dentro de la herramienta Detection Engineering Agent (DEA).

Configura las preferencias del usuario para los datos de prueba sintéticos

Para ver los eventos de prueba sintéticos y las alertas simuladas en Google SecOps en la IU, la API o las herramientas de MCP, configura la visibilidad según tu interfaz:

Consola de Google SecOps

Para ver los eventos sintéticos en la página SIEM Search o en las consolas de la IU, haz lo siguiente:

  1. En la consola de Google SecOps, haz clic en el avatar de tu perfil en la barra de navegación y selecciona Preferencias del usuario.
  2. Navega a Visibilidad de los datos.
  3. Establece Mostrar datos de prueba sintéticos en ACTIVADO.
  4. Haz clic en Guardar.

API de Chronicle

Para las consultas de API programáticas, proporciona simulated_data_visibility = "SIMULATED_DATA_INCLUDED" cuando consultes los extremos de búsqueda, reglas o detección de UDM con la API de Chronicle:

{
  "query": "metadata.event_type = \"USER_LOGIN\"",
  "simulated_data_visibility": "SIMULATED_DATA_INCLUDED"
}

Valores de enumeración del parámetro simulated_data_visibility admitidos:

  • SIMULATED_DATA_EXCLUDED (predeterminado): Suprime los eventos y las alertas etiquetados como simulaciones.
  • SIMULATED_DATA_INCLUDED: Muestra los datos de producción y los datos de prueba sintéticos en los resultados de la consulta.

Servidor de MCP de Google SecOps

Cuando interactúes con Google SecOps a través de un cliente de MCP (por ejemplo, la CLI de Gemini o AntiGravity), configura la visibilidad de la simulación en todo el arrendatario en tu archivo de contexto del espacio de trabajo (Gemini.md o settings.json):

Cuando uses el servidor de MCP de GoogleSecOps, establece simulated_data_visibility = "SIMULATED_DATA_INCLUDED" para todas las búsquedas de UDM, la evaluación de reglas y las herramientas de consulta de detección.

Comprende el aislamiento del sistema descendente

Para garantizar que los datos de prueba se manejen de manera adecuada en todo Google SecOps, la simulación de eventos aplica límites de aislamiento claros para los componentes posteriores:

Sistema o función Tratamiento de datos sintéticos Mecanismo de aislamiento
Almacén de detecciones y alertas Aislada y etiquetada En el archivo Collection .proto, las detecciones resultantes de la telemetría simulada se marcan en tags con INCLUDES_SIMULATION_DATA y se incluyen los campos de metadatos de detección .proto simulated_event_count y simulated_event_names. Se suprimen de las APIs de lectura y lista de detección estándar, a menos que se solicite simulated_data_visibility = "SIMULATED_DATA_INCLUDED".
Búsqueda y paneles de UDM Oculto de forma predeterminada Se filtra a menos que se especifique simulated_data_visibility = "SIMULATED_DATA_INCLUDED".
Clasificación de casos e incidentes Excluido Las detecciones con etiquetas de simulación se omiten en la creación automatizada de casos.
Guías y automatización de SOAR Excluido Las guías de SOAR automatizadas no se activan en alertas simuladas.
Análisis de riesgos (RBA) Excluido Las canalizaciones agregadas de la puntuación de riesgo de transmisión descartan los eventos etiquetados como simulados.
Agente de detección de amenazas (THA) Excluido Las consultas de conjuntos de datos de búsqueda de amenazas suprimen automáticamente la telemetría etiquetada como simulación.

Capacidades de las herramientas y el paquete de agentes

La simulación de eventos aprovecha las capacidades de la herramienta de subagente que expone el servidor de MCP de Google SecOps. Para obtener información detallada sobre las herramientas de subagente disponibles (incluidas generate_threat_detection_opportunity, generate_synthetic_events, evaluate_rule_coverage_long_running, get_operation, generate_rules y create_rule), las entradas clave y los esquemas de salida, consulta Usa el agente de Ingeniería de detección para evaluar la cobertura de amenazas.

Comprende el ciclo de vida y el flujo de trabajo de la ingeniería de detección

El flujo de trabajo de ingeniería de detección de simulación de eventos de extremo a extremo sigue un ciclo de vida estructurado de varias etapas:

  1. Procesamiento de inteligencia y transferencia de datos de telemetría: Pasa texto sin procesar de inteligencia sobre amenazas a generate_threat_detection_opportunity para extraer TDO estructurados (por ejemplo, t01, t02), aplicar el desplazamiento de la marca de tiempo previo al vuelo y llamar a generate_synthetic_events para transmitir registros de UDM etiquetados como SIMULATION a través de la canalización de transferencia de datos de Google SecOps en vivo (ImportEvents).
  2. Evaluación de cobertura asíncrona: Ejecuta evaluate_rule_coverage_long_running para evaluar la cobertura de las reglas de YARA-L 2.0 en la telemetría sintética, sondea get_operation hasta que se complete para recuperar la matriz de coincidencias de reglas.
  3. Corrección de brechas y administración del ciclo de vida de las reglas: Llama a generate_rules para cualquier TDO no descubierto para producir borradores validados de reglas de YARA-L 2.0 y, luego, implementa las reglas revisadas en producción con create_rule.

Para obtener cargas útiles detalladas de invocación de herramientas y ejemplos de código completos en cada etapa del ciclo de vida de la detección, consulta Usa el agente de Ingeniería de detección para evaluar la cobertura de amenazas.

Soluciona problemas

En esta sección, se incluyen algunas preguntas frecuentes sobre la solución de problemas y sus respuestas.

Por diseño, las búsquedas estándar de UDM de Google SecOps suprimen los eventos que llevan la etiqueta de transferencia SIMULATION para preservar la higiene operativa del SOC. Para ver eventos sintéticos en las consolas de la IU o de la UDM de Search, asegúrate de que la opción Mostrar datos de prueba sintéticos esté habilitada en tus preferencias del usuario o establece simulated_data_visibility = "SIMULATED_DATA_INCLUDED" en tu solicitud de consulta.

P.: ¿Cómo se evita que las detecciones de datos simulados alerten a los analistas del SOC?

Cuando una regla se activa en eventos sintéticos, el compilador de backend etiqueta la detección resultante con INCLUDES_SIMULATION_DATA. De forma predeterminada, las detecciones con esta etiqueta se excluyen de los casos de producción, los Playbooks, el análisis de riesgos (RBA) y los paneles de control de clasificación de alertas.

P.: ¿Por qué evaluate_rule_coverage_long_running devolvió 0 coincidencias para mis eventos sintéticos?

Verifica que las marcas de tiempo de tus eventos sintéticos se encuentren dentro del período de ejecución de 1 hora continua ([StartTime - 1 hour, StartTime]). Asegúrate de que tus IDs de TDO cumplan con la expresión regular requerida (^[a-zA-Z]\d{2}$, p.ej., t01).

P.: ¿Cómo se deben controlar los indicadores atómicos (direcciones IP, nombres de dominio, hashes de archivos) en comparación con las reglas de comportamiento?

Administra los indicadores atómicos con la función de correlación de IOC de Google SecOps o las tablas de datos en lugar de codificar valores hash o direcciones IP estáticas directamente en las reglas de detección de YARA-L 2.0. Reserva YARA-L 2.0 para los patrones de comportamiento y la correlación de TTP.

P.: ¿Cuál es el tamaño máximo del lote para las llamadas de evaluación de la cobertura de TDO?

Para optimizar el rendimiento y cumplir con los parámetros de API Gateway, las solicitudes de evaluación de cobertura por lotes se limitan a un máximo de tres TDO o 40 eventos sintéticos por llamada a evaluate_rule_coverage_long_running.

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