Utiliser la simulation d'événements pour évaluer la couverture de la détection

Ce guide est destiné aux équipes d'ingénierie de détection et aux équipes SOC qui souhaitent fournir de manière programmatique des séquences de menaces réalistes dans le pipeline d'ingestion en direct à l'aide de la simulation d'événements. La simulation d'événements est un framework de simulation de menaces et d'évaluation de la couverture de la détection intégré directement à Google Security Operations. En tant que fonctionnalité de base de l'architecture de l'agent d'ingénierie de détection (DEA), la simulation d'événements vérifie le cycle de vie de la détection, de l'ingestion et de la normalisation de la télémétrie à la corrélation multi-événements et aux alertes, tout en préservant les workflows opérationnels du SOC.

En connectant les outils MCP Google SecOps à l'assistance de l'IA (tels que Gemini ou Claude Code), la simulation d'événements automatise le cycle de vie de l'ingénierie de détection : ingestion de rapports de menaces bruts, structuration des tactiques de menaces en opportunités de détection de menaces (TDO) exploitables, synthèse de télémétrie réaliste du modèle de données unifié (UDM), évaluation de la couverture des règles YARA-L 2.0 existantes pour les règles à événement unique, multi-événements et composites, et création de règles de détection pour combler les failles de sécurité identifiées.

Cas d'utilisation principaux

La simulation d'événements et l'agent d'ingénierie de détection (DEA) sont compatibles avec les workflows de base suivants :

  • Tests d'ingestion et de normalisation de pipelines en direct : diffusez de manière programmatique la télémétrie synthétique du modèle de données unifié (UDM) directement via des pipelines d'ingestion en direct, des modules d'enrichissement de contexte et des graphiques d'entités pour obtenir une préparation complète de la détection de bout en bout.
  • Couverture continue des menaces et validation de la régression : évaluez les règles YARA-L 2.0 gérées et personnalisées par rapport à des tactiques, techniques et procédures (TTP) d'adversaires spécifiques, en établissant des tests unitaires automatisés et des tests de régression continus sur les ensembles de règles avant le déploiement en production.
  • Génération de télémétrie synthétique : générez des événements UDM valides pour le schéma simulant des chaînes d'attaque complexes (telles que l'exploitation d'applications Web, l'accès aux identifiants ou le mouvement latéral) pour tester les règles dans des environnements de production réels.

Principaux avantages et proposition de valeur

  • Posture proactive et validation des menaces : testez les règles YARA-L 2.0 par rapport aux failles et aux comportements des acteurs malveillants récemment divulgués avant que des incidents réels ne se produisent.
  • Synthèse directe et assurance d'ingestion : synthétisez des événements UDM valides pour le schéma directement à partir du texte de renseignements sur les menaces qui transitent par le pipeline d'ingestion Google SecOps en direct (ImportEvents) pour une normalisation complète, un alignement des champs et un enrichissement du contexte.
  • Télémétrie isolée et sécurité de la production : les événements synthétiques générés par la simulation d'événements sont balisés avec des métadonnées de simulation (SIMULATION libellés d'ingestion) et entraînent des détections balisées comme INCLUDES_SIMULATION_DATA. Les détections issues de données simulées sont automatiquement exclues des cas de production, des playbooks, des flux d'analyse des risques (RBA) et des tableaux de bord de triage des alertes.

Comprendre les concepts et l'architecture de la simulation d'événements

Les composants principaux suivants de la simulation d'événements et du framework de l'agent d'ingénierie de détection (DEA) sont essentiels pour le déploiement :

  • Opportunité de détection de menaces (TDO) : modèle de données formalisé agissant comme un test unitaire qui identifie, hiérarchise et catégorise des TTP d'adversaires spécifiques extraits de rapports de renseignements sur les menaces ou de descriptions en langage naturel. Les identifiants TDO doivent respecter des exigences de format strictes (par exemple, t01, t02, correspondant à l'expression régulière ^[a-zA-Z]\d{2}$).
  • Événements UDM synthétiques : événements de journaux générés par une machine et mis en forme de manière stricte sous le schéma du modèle de données unifié (UDM) de Google SecOps. Ces événements simulent des actions d'attaquants spécifiques requises pour tester la logique des règles de détection à l'aide de ImportEvents.
  • Libellisation de la simulation et balisage des alertes : les événements synthétiques comportent un libellé d'ingestion (metadata.ingestion_labels["SIMULATION"]). Dans le proto Collection, les détections résultant de données simulées sont marquées sous tags avec INCLUDES_SIMULATION_DATA. Les champs proto des métadonnées de détection incluent simulated_event_count (nombre total d'événements simulés contribuant à la détection) et simulated_event_names (ensemble de valeurs de libellé SIMULATION provenant d'événements contributifs).
  • Visibilité des données et suppression de la recherche : les recherches UDM Google SecOps standards suppriment les événements libellisés comme des simulations par défaut. Les requêtes de recherche et les vues de l'interface utilisateur peuvent inclure explicitement des données simulées à l'aide du paramètre de configuration simulated_data_visibility ou du bouton bascule des préférences utilisateur.
  • Opérations de longue durée (LRO) : mécanisme d'exécution backend asynchrone (evaluate_rule_coverage_long_running) qui orchestre les lots d'exécution de règles à la demande sans rencontrer de délais d'attente HTTP de l'API.

Avant de commencer

La simulation d'événements partage les prérequis d'environnement sous-jacents, les autorisations IAM et la configuration du serveur avec le kit d'outils de l'agent d'ingénierie de détection. Avant de commencer, vérifiez que les conditions préalables suivantes sont remplies :

Comment la télémétrie synthétique est-elle injectée ?

La télémétrie synthétique est injectée dans Google SecOps à l'aide du kit d'outils de l'agent MCP ou d'appels d'API Chronicle directs :

  1. Invocation du sous-agent MCP : appelez l'outil generate_synthetic_events avec les ID d'opportunité de détection de menaces (TDO) cibles et les spécifications de comportement.
  2. Point de terminaison de l'API Chronicle : diffusez de manière programmatique des événements UDM synthétiques à l'aide du point de terminaison de l'API REST ImportEvents (POST /v1alpha/projects/{project}/locations/{location}/instances/{instance}/events:import).
  3. Libellisation de la simulation : lorsque vous appelez directement l'API ImportEvents, les appelants doivent inclure manuellement metadata.ingestion_labels contenant la clé "SIMULATION" et un identifiant unique de simulation ou d'exécution de test comme valeur dans leur charge utile de requête (par exemple, "key": "SIMULATION", "value": "TEST123" ou "t01"). L'API ne remplit pas automatiquement les libellés de simulation.

Exemple d'appel d'ingestion UDM

Requête HTTP :

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

Corps de la requête :

{
  "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 simulation d'événements injecte directement des événements UDM synthétisés à l'aide de ImportEvents, en évaluant la normalisation UDM, l'enrichissement du contexte et la détection des règles. L'analyse des journaux bruts est testée lors de la génération d'événements synthétiques dans l'outil de l'agent d'ingénierie de détection (DEA).

Configurer les préférences utilisateur pour les données de test synthétiques

Pour afficher les événements de test synthétiques et les alertes simulées dans Google SecOps via l'interface utilisateur, l'API ou les outils MCP, configurez la visibilité en fonction de votre interface :

Console Google SecOps

Pour afficher les événements synthétiques sur la page Recherche SIEM ou dans les consoles de l'interface utilisateur :

  1. Dans la console Google SecOps, cliquez sur l'avatar de votre profil dans la barre de navigation, puis sélectionnez Préférences utilisateur.
  2. Accédez à Visibilité des données.
  3. Définissez Afficher les données de test synthétiques sur ACTIVÉ.
  4. Cliquez sur Enregistrer.

API Chronicle

Pour les requêtes d'API programmatiques, fournissez simulated_data_visibility = "SIMULATED_DATA_INCLUDED" lorsque vous interrogez la recherche UDM, les règles ou les points de terminaison de détection à l'aide de l'API Chronicle :

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

Valeurs d'énumération du paramètre simulated_data_visibility acceptées :

  • SIMULATED_DATA_EXCLUDED (par défaut) : supprime les événements et les alertes libellisés comme des simulations.
  • SIMULATED_DATA_INCLUDED : renvoie à la fois les données de production et les données de test synthétiques dans les résultats de la requête.

Serveur MCP Google SecOps

Lorsque vous interagissez avec Google SecOps à l'aide d'un client MCP (par exemple, l'interface de ligne de commande Gemini ou AntiGravity), configurez la visibilité de la simulation à l'échelle du locataire dans votre fichier de contexte d'espace de travail (Gemini.md ou settings.json) :

Lorsque vous utilisez le serveur MCP GoogleSecOps, définissez simulated_data_visibility = "SIMULATED_DATA_INCLUDED" pour toutes les recherches UDM, l'évaluation des règles et les outils de requête de détection.

Comprendre l'isolation du système en aval

Pour s'assurer que les données de test sont gérées de manière appropriée dans Google SecOps, la simulation d'événements applique des limites d'isolation claires pour les composants en aval :

Système ou fonctionnalité Traitement des données synthétiques Mécanisme d'isolation
Détections et magasin d'alertes Isolées et balisées Dans le proto Collection, les détections résultant de la télémétrie simulée sont marquées sous tags avec INCLUDES_SIMULATION_DATA et incluent les champs proto des métadonnées de détection simulated_event_count et simulated_event_names. Supprimées des API de lecture et de liste de détection standards, sauf si simulated_data_visibility = "SIMULATED_DATA_INCLUDED" est demandé.
Recherche UDM et tableaux de bord Masqués par défaut Filtrés, sauf si simulated_data_visibility = "SIMULATED_DATA_INCLUDED" est spécifié.
Cas et triage des incidents Exclus Les détections avec des tags de simulation sont ignorées lors de la création automatique de cas.
Playbooks et automatisation SOAR Exclus Les playbooks SOAR automatisés ne se déclenchent pas sur les alertes simulées.
Analyse des risques (RBA) Exclue Les pipelines agrégés de scores de risque en streaming abandonnent les événements libellisés comme des simulations.
Agent de traque des menaces (THA) Exclu Les requêtes d'ensemble de données de traque des menaces suppriment automatiquement la télémétrie libellisée comme des simulations.

Fonctionnalités de la suite et des outils agentiques

La simulation d'événements exploite les fonctionnalités des outils de sous-agent exposées par le serveur MCP Google SecOps. Pour obtenir des informations détaillées sur les outils de sous-agent disponibles (y compris generate_threat_detection_opportunity, generate_synthetic_events, evaluate_rule_coverage_long_running, get_operation, generate_rules, et create_rule), les entrées clés et les schémas de sortie, consultez Utiliser l'agent d'ingénierie de détection pour évaluer la couverture des menaces.

Comprendre le cycle de vie et le workflow de l'ingénierie de détection

Le workflow d'ingénierie de détection de simulation d'événements de bout en bout suit un cycle de vie structuré en plusieurs étapes :

  1. Traitement des renseignements et ingestion de la télémétrie : transmettez le texte brut des renseignements sur les menaces à generate_threat_detection_opportunity pour extraire les TDO structurés (par exemple, t01, t02), appliquez le décalage d'horodatage avant vol et appelez generate_synthetic_events pour diffuser les journaux UDM libellisés comme des SIMULATION via le pipeline d'ingestion Google SecOps en direct (ImportEvents).
  2. Évaluation asynchrone de la couverture : exécutez evaluate_rule_coverage_long_running pour évaluer la couverture des règles YARA-L 2.0 sur la télémétrie synthétique, en interrogeant get_operation jusqu'à la fin pour récupérer la matrice de correspondance des règles.
  3. Correction des écarts et gestion du cycle de vie des règles : appelez generate_rules pour tous les TDO non couverts afin de générer des brouillons de règles YARA-L 2.0 validés, puis déployez les règles examinées en production à l'aide de create_rule.

Pour obtenir des charges utiles d'invocation d'outils détaillées et des exemples de code complets à chaque étape du cycle de vie de la détection, consultez Utiliser l'agent d'ingénierie de détection pour évaluer la couverture des menaces.

Dépannage

Cette section contient quelques questions fréquentes sur le dépannage et leurs réponses.

Par conception, les recherches UDM Google SecOps standards suppriment les événements portant le libellé d'ingestion SIMULATION afin de préserver l'hygiène opérationnelle du SOC. Pour afficher les événements synthétiques dans la recherche UDM ou les consoles de l'interface utilisateur, assurez-vous que l'option Afficher les données de test synthétiques est activée dans vos préférences utilisateur ou définissez simulated_data_visibility = "SIMULATED_DATA_INCLUDED" dans votre requête.

Q : Comment empêcher les détections issues de données simulées d'alerter les analystes SOC ?

Lorsqu'une règle se déclenche sur des événements synthétiques, le compilateur backend balise la détection résultante avec INCLUDES_SIMULATION_DATA. Les détections portant ce tag sont exclues des cas de production, des playbooks, de l'analyse des risques (RBA) et des tableaux de bord de triage des alertes par défaut.

Q : Pourquoi evaluate_rule_coverage_long_running a-t-il renvoyé 0 correspondance pour mes événements synthétiques ?

Vérifiez que les horodatages de vos événements synthétiques se trouvent dans la fenêtre d'exécution glissante d'une heure ([StartTime - 1 hour, StartTime]). Assurez-vous que vos ID TDO sont conformes à l'expression régulière requise (^[a-zA-Z]\d{2}$, par exemple, t01).

Q : Comment gérer les indicateurs atomiques (adresses IP, noms de domaine, hachages de fichiers) par rapport aux règles comportementales ?

Gérez les indicateurs atomiques à l'aide de la correspondance IOC Google SecOps ou des tables de données plutôt que de coder en dur des adresses IP statiques ou des valeurs de hachage directement dans les règles de détection YARA-L 2.0. Réservez YARA-L 2.0 pour les modèles comportementaux et la corrélation TTP.

Q : Quelle est la taille maximale des lots pour les appels d'évaluation de la couverture TDO ?

Pour optimiser les performances et respecter les paramètres d'API Gateway, les requêtes d'évaluation de la couverture par lot sont limitées à un maximum de trois TDO ou 40 événements synthétiques par appel evaluate_rule_coverage_long_running.

Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.