Ereignissimulation zur Bewertung der Erkennungsabdeckung verwenden

Dieser Leitfaden richtet sich an Teams für die Entwicklung von Erkennungsmechanismen und SOC-Teams, die mithilfe der Ereignissimulation programmatisch realistische Bedrohungssequenzen in die Live-Aufnahmepipeline einfügen möchten. Die Ereignissimulation ist ein Framework für die Bedrohungssimulation und die Bewertung der Erkennungsabdeckung, das direkt in Google Security Operations eingebettet ist. Als grundlegende Funktion der Architektur des Detection Engineering Agent (DEA) überprüft die Ereignissimulation den Erkennungslebenszyklus von der Telemetrieaufnahme und -normalisierung bis zur Korrelation und Benachrichtigung bei mehreren Ereignissen, wobei die betrieblichen SOC-Workflows beibehalten werden.

Durch die Verknüpfung von Google SecOps MCP-Tools mit KI-Unterstützung (z. B. Gemini oder Claude Code) automatisiert die Ereignissimulation den Lebenszyklus der Entwicklung von Erkennungsmechanismen: Aufnahme von Rohdaten aus Bedrohungsberichten, Strukturierung von Bedrohungstaktiken in umsetzbare Threat Detection Opportunities (TDOs), Synthese realistischer Telemetriedaten im einheitlichen Datenmodell (Unified Data Model, UDM), Bewertung der vorhandenen YARA-L 2.0-Regelabdeckung für Einzelereignis-, Mehrereignis- und zusammengesetzte Regeln sowie Erstellung neuer Erkennungsregeln, um identifizierte Sicherheitslücken zu schließen.

Primäre Anwendungsfälle

Die Ereignissimulation und der Detection Engineering Agent (DEA) unterstützen die folgenden Kern-Workflows:

  • Tests für die Aufnahme und Normalisierung von Live-Pipelines: Streamen Sie programmatisch synthetische Telemetriedaten im einheitlichen Datenmodell (UDM) direkt über Live-Aufnahmepipelines, Module zur Kontextanreicherung und Entitätsdiagramme, um eine vollständige End-to-End-Erkennungsbereitschaft zu erreichen.
  • Kontinuierliche Bedrohungsabdeckung und Regressionsvalidierung: Bewerten Sie verwaltete und benutzerdefinierte YARA-L 2.0-Regeln anhand bestimmter Taktiken, Techniken und Verfahren (Tactics, Techniques, and Procedures, TTPs) von Angreifern. So können Sie automatisierte Unit-Tests und kontinuierliche Regressionstests für Regelsätze vor der Bereitstellung in der Produktion durchführen.
  • Generierung synthetischer Telemetriedaten: Erstellen Sie schemavalide UDM-Ereignisse, die komplexe Angriffsketten simulieren (z. B. Ausnutzung von Webanwendungen, Zugriff auf Anmeldedaten oder laterale Bewegung), um Regeln in echten Produktionsumgebungen zu testen.

Wichtige Vorteile und Wertversprechen

  • Proaktive Sicherheitsstatus- und Bedrohungsvalidierung: Testen Sie YARA-L 2.0-Regeln anhand neu offengelegter Sicherheitslücken und Verhaltensweisen von Bedrohungsakteuren, bevor es zu Vorfällen in der Praxis kommt.
  • Direkte Synthese und Sicherstellung der Aufnahme: Synthetisieren Sie schemavalide UDM-Ereignisse direkt aus Threat Intelligence-Text, die über die Live-Aufnahmepipeline von Google SecOps (ImportEvents) fließen, um eine vollständige Normalisierung, Feldabstimmung und Kontextanreicherung zu durchlaufen.
  • Isolierte Telemetrie und Produktionssicherheit: Synthetische Ereignisse, die durch die Ereignissimulation generiert werden, werden mit Simulationsmetadaten (SIMULATION Aufnahmelabels) getaggt und führen zu Erkennungen, die als INCLUDES_SIMULATION_DATA gekennzeichnet sind. Erkennungen aus simulierten Daten werden automatisch aus Produktionsfällen, Playbooks, Streams für die Risikoanalyse (Risk-Based Alerting, RBA) und Dashboards für die Benachrichtigungs-Triage ausgeschlossen.

Konzepte und Architektur der Ereignissimulation

Die folgenden Kernkomponenten der Ereignissimulation und des Detection Engineering Agent (DEA)-Frameworks sind für die Bereitstellung unerlässlich:

  • Threat Detection Opportunity (TDO): Ein formalisiertes Datenmodell, das als Unittest dient und bestimmte Taktiken, Techniken und Verfahren von Angreifern identifiziert, priorisiert und kategorisiert, die aus Threat Intelligence-Berichten oder Beschreibungen in natürlicher Sprache extrahiert wurden. TDO-IDs müssen strengen Formatierungsanforderungen entsprechen (z. B. t01, t02, passend zum regulären Ausdruck ^[a-zA-Z]\d{2}$).
  • Synthetische UDM-Ereignisse: Maschinell generierte Logereignisse, die streng nach dem Schema des einheitlichen Datenmodells (UDM) von Google SecOps formatiert sind. Diese Ereignisse simulieren bestimmte Angreiferaktionen, die zum Testen der Erkennungsregellogik mit ImportEvents erforderlich sind.
  • Simulationslabeling und Benachrichtigungstags: Synthetische Ereignisse haben ein Aufnahmelabel (metadata.ingestion_labels["SIMULATION"]). Im Collection-Protokoll werden Erkennungen, die aus simulierten Daten resultieren, unter tags mit INCLUDES_SIMULATION_DATA gekennzeichnet. Zu den Protokollfeldern für Erkennungsmetadaten gehören simulated_event_count (Gesamtzahl der simulierten Ereignisse, die zur Erkennung beitragen) und simulated_event_names (die Menge der SIMULATION-Labelwerte aus den beitragenden Ereignissen).
  • Datensichtbarkeit und Suchunterdrückung: Bei Standard-UDM-Suchen in Google SecOps werden Ereignisse mit Simulationslabel standardmäßig unterdrückt. Suchanfragen und UI-Ansichten können simulierte Daten explizit einbeziehen, indem Sie den Konfigurationsparameter simulated_data_visibility oder die Umschaltfunktion für Nutzerpräferenzen verwenden.
  • Lang andauernde Vorgänge (Long-Running Operations, LROs): Ein asynchroner Backend-Ausführungsmechanismus (evaluate_rule_coverage_long_running), der On-Demand-Regelausführungsbatches orchestriert, ohne dass API-HTTP-Time-outs auftreten.

Hinweis

Die Ereignissimulation teilt die zugrunde liegenden Voraussetzungen für die Umgebung, IAM-Berechtigungen und die Servereinrichtung mit dem Detection Engineering Agent-Toolkit. Bevor Sie beginnen, sollten Sie prüfen, ob die folgenden Voraussetzungen erfüllt sind:

So werden synthetische Telemetriedaten eingefügt

Synthetische Telemetriedaten werden entweder mit dem MCP-Agent-Toolkit oder direkten Chronicle API-Aufrufen in Google SecOps eingefügt:

  1. MCP-Subagent-Aufruf: Rufen Sie das generate_synthetic_events Tool mit den Ziel-TDO-IDs und Verhaltensspezifikationen auf.
  2. Chronicle API-Endpunkt: Streamen Sie programmatisch synthetische UDM-Ereignisse mit dem ImportEvents-REST API-Endpunkt (POST /v1alpha/projects/{project}/locations/{location}/instances/{instance}/events:import).
  3. Simulationslabeling: Wenn Sie die ImportEvents API direkt aufrufen, müssen Aufrufer in ihrer Anfrage-Nutzlast manuell metadata.ingestion_labels mit dem Schlüssel "SIMULATION" und einer eindeutigen Simulations- oder Testlauf-ID als Wert einfügen (z. B. "key": "SIMULATION", "value": "TEST123" oder "t01"). Die API füllt Simulationslabels nicht automatisch aus.

Beispiel für einen UDM-Aufruf zur Aufnahme

HTTP-Anfrage:

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

Anfragetext:

{
  "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"
        }
      }
    }
  ]
}

Die Ereignissimulation fügt synthetisierte UDM-Ereignisse direkt mit ImportEvents ein und bewertet die UDM-Normalisierung, Kontextanreicherung und Regelerkennung. Die Rohdatenprotokollanalyse wird während der Generierung synthetischer Ereignisse im Detection Engineering Agent (DEA)-Tool getestet.

Nutzerpräferenzen für synthetische Testdaten konfigurieren

Wenn Sie synthetische Testereignisse und simulierte Benachrichtigungen in Google SecOps über die UI, API oder MCP-Tools aufrufen möchten, konfigurieren Sie die Sichtbarkeit entsprechend Ihrer Benutzeroberfläche:

Google SecOps Console

So rufen Sie synthetische Ereignisse auf der Seite SIEM-Suche oder in UI-Konsolen auf:

  1. Klicken Sie in der Google SecOps Console in der Navigationsleiste auf Ihr Profilbild und wählen Sie Nutzerpräferenzen aus.
  2. Rufen Sie Datensichtbarkeit auf.
  3. Setzen Sie Synthetische Testdaten anzeigen auf EIN.
  4. Klicken Sie auf Speichern.

Chronicle API

Geben Sie für programmatische API-Abfragen simulated_data_visibility = "SIMULATED_DATA_INCLUDED" an, wenn Sie UDM-Such-, Regel- oder Erkennungsendpunkte mit der Chronicle API abfragen:

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

Unterstützte Enumerationswerte für den Parameter simulated_data_visibility:

  • SIMULATED_DATA_EXCLUDED (Standard): Unterdrückt Ereignisse und Benachrichtigungen mit Simulationslabel.
  • SIMULATED_DATA_INCLUDED: Gibt sowohl Produktionsdaten als auch synthetische Testdaten in den Abfrageergebnissen zurück.

Google SecOps MCP-Server

Wenn Sie mit Google SecOps über einen MCP-Client (z. B. Gemini CLI oder AntiGravity) interagieren, konfigurieren Sie die tenantweite Sichtbarkeit der Simulation in Ihrer Arbeitsbereichskonfigurationsdatei (Gemini.md oder settings.json):

Wenn Sie den Google SecOps MCP-Server verwenden, setzen Sie simulated_data_visibility = "SIMULATED_DATA_INCLUDED" für alle UDM-Suchen, Regelbewertungen und Erkennungsabfragetools.

Isolation von Downstream-Systemen

Damit Testdaten in Google SecOps ordnungsgemäß verarbeitet werden, erzwingt die Ereignissimulation klare Isolationsgrenzen für Downstream-Komponenten:

System oder Feature Behandlung synthetischer Daten Isolationsmechanismus
Erkennungen und Benachrichtigungsspeicher Isoliert und getaggt Im Collection-Protokoll werden Erkennungen, die aus simulierter Telemetrie resultieren, unter tags mit INCLUDES_SIMULATION_DATA gekennzeichnet und enthalten die Protokollfelder für Erkennungsmetadaten simulated_event_count und simulated_event_names. Werden aus Standard-APIs zum Lesen und Auflisten von Erkennungen unterdrückt, es sei denn, simulated_data_visibility = "SIMULATED_DATA_INCLUDED" wird angefordert.
UDM-Suche und Dashboards Standardmäßig ausgeblendet Werden gefiltert, es sei denn, simulated_data_visibility = "SIMULATED_DATA_INCLUDED" ist angegeben.
Fälle und Vorfall-Triage Ausgeschlossen Erkennungen mit Simulationstags werden bei der automatischen Fallerstellung umgangen.
Playbooks und SOAR-Automatisierung Ausgeschlossen Automatisierte SOAR-Playbooks werden nicht durch simulierte Benachrichtigungen ausgelöst.
Risikoanalyse (RBA) Ausgeschlossen Streaming-Pipelines für aggregierte Risikobewertungen verwerfen Ereignisse mit Simulationslabel.
Agent für die Bedrohungssuche (Threat Hunting Agent, THA) Ausgeschlossen Bei Abfragen von Datasets für die Bedrohungssuche wird Telemetrie mit Simulationslabel automatisch unterdrückt.

Agentensuite und Toolfunktionen

Die Ereignissimulation nutzt die Funktionen des Subagent-Tools, die vom Google SecOps MCP-Server bereitgestellt werden. Detaillierte Informationen zu den verfügbaren Subagent-Tools (einschließlich generate_threat_detection_opportunity, generate_synthetic_events, evaluate_rule_coverage_long_running, get_operation, generate_rules, und create_rule), wichtigen Eingaben und Ausgabeschemas finden Sie unter Detection Engineering Agent verwenden, um die Bedrohungsabdeckung zu bewerten.

Lebenszyklus und Workflow der Entwicklung von Erkennungsmechanismen

Der End-to-End-Workflow für die Entwicklung von Erkennungsmechanismen mit Ereignissimulation folgt einem strukturierten mehrstufigen Lebenszyklus:

  1. Verarbeitung von Informationen und Aufnahme von Telemetriedaten: Übergeben Sie Rohdaten aus Bedrohungsdaten an generate_threat_detection_opportunity, um strukturierte TDOs zu extrahieren (z. B. t01, t02), wenden Sie die Vorab-Zeitstempelverschiebung an und rufen Sie generate_synthetic_events auf, um UDM-Logs mit dem Label SIMULATION über die Live-Aufnahmepipeline von Google SecOps (ImportEvents) zu streamen.
  2. Asynchrone Bewertung der Abdeckung: Führen Sie evaluate_rule_coverage_long_running aus, um die YARA-L 2.0-Regelabdeckung für synthetische Telemetriedaten zu bewerten. Rufen Sie get_operation ab, bis der Vorgang abgeschlossen ist, um die Regelübereinstimmungsmatrix abzurufen.
  3. Behebung von Lücken und Lebenszyklusmanagement für Regeln: Rufen Sie generate_rules für alle nicht abgedeckten TDOs auf, um validierte YARA-L 2.0-Regelentwürfe zu erstellen, und stellen Sie überprüfte Regeln mit create_rule in der Produktion bereit.

Detaillierte Nutzlasten für Toolaufrufe und vollständige Codebeispiele für jede Phase des Erkennungslebenszyklus finden Sie unter Detection Engineering Agent verwenden, um die Bedrohungsabdeckung zu bewerten.

Fehlerbehebung

In diesem Abschnitt finden Sie einige häufig gestellte Fragen zur Fehlerbehebung und die entsprechenden Antworten.

Standardmäßig werden bei Standard-UDM-Suchen in Google SecOps Ereignisse mit dem Aufnahmelabel SIMULATION unterdrückt, um die betriebliche Hygiene des SOC zu gewährleisten. Wenn Sie synthetische Ereignisse in der UDM-Suche oder in UI-Konsolen aufrufen möchten, muss in Ihren Nutzerpräferenzen die Option Synthetische Testdaten anzeigen aktiviert sein. Alternativ können Sie in Ihrer Abfrageanfrage simulated_data_visibility = "SIMULATED_DATA_INCLUDED" festlegen.

F: Wie wird verhindert, dass SOC-Analysten über Erkennungen aus simulierten Daten benachrichtigt werden?

Wenn eine Regel durch synthetische Ereignisse ausgelöst wird, taggt der Backend-Compiler die resultierende Erkennung mit INCLUDES_SIMULATION_DATA. Erkennungen mit diesem Tag werden standardmäßig aus Produktionsfällen, Playbooks, der Risikoanalyse (RBA) und Dashboards für die Benachrichtigungs-Triage ausgeschlossen.

F: Warum hat evaluate_rule_coverage_long_running 0 Übereinstimmungen für meine synthetischen Ereignisse zurückgegeben?

Prüfen Sie, ob die Zeitstempel Ihrer synthetischen Ereignisse in das rollierende 1-Stunden-Ausführungsfenster ([StartTime - 1 hour, StartTime]) fallen. Achten Sie darauf, dass Ihre TDO-IDs dem erforderlichen regulären Ausdruck entsprechen (^[a-zA-Z]\d{2}$, z.B. t01).

F: Wie sollten atomare Indikatoren (IP-Adressen, Domainnamen, Dateihashes) im Vergleich zu Verhaltensregeln behandelt werden?

Verwalten Sie atomare Indikatoren mit Google SecOps IOC Matching oder Datentabellen, anstatt statische IP-Adressen oder Hashwerte direkt in YARA-L 2.0-Erkennungsregeln zu codieren. Verwenden Sie YARA-L 2.0 für Verhaltensmuster und TTP-Korrelationen.

F: Was ist die maximale Batchgröße für Aufrufe zur Bewertung der TDO-Abdeckung?

Um die Leistung zu optimieren und die API Gateway-Parameter einzuhalten, sind Batchanfragen zur Abdeckungsbewertung auf maximal drei TDOs oder 40 synthetische Ereignisse pro evaluate_rule_coverage_long_running-Aufruf beschränkt.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten