SOAR-Webhook einrichten

Unterstützt in:

Google SecOps SOAR

Webhooks sind eine einfache Lösung zum Erfassen von Benachrichtigungen aus Ihrer Organisation in der Google Security Operations SOAR-Plattform.

Über Webhooks aufgenommene Benachrichtigungen werden auf der Plattform mit denselben Informationen angezeigt wie Benachrichtigungen, die über Connectors aufgenommen wurden.

Google empfiehlt, entweder einen Connector oder einen Webhook aus derselben Quelle zu verwenden, aber nicht beides, um doppelte Kundenservicetickets zu vermeiden.

Webhooks eignen sich am besten für Szenarien, die eine einfache Zuordnungslogik erfordern, während Connectors besser für eine erweiterte und flexible Zuordnung geeignet sind.

Webhook zum Erfassen von Benachrichtigungen einrichten

So richten Sie einen Webhook zum Erfassen von Benachrichtigungen ein:

1. Rufen Sie die SOAR-Einstellungen > „Ingestion“ (Aufnahme) > „Webhooks“ auf.
2. Klicken Sie auf add Add incoming webhook (Eingehenden Webhook hinzufügen).
3. Geben Sie einen Namen für den neuen Webhook ein und wählen Sie eine Umgebung aus.
4. Klicken Sie auf Speichern. Nach dem Speichern wird der neue Webhook auf der Hauptseite angezeigt.
5. Kopieren Sie die Webhook-URL und notieren Sie sie für die spätere Verwendung. Sie müssen sie in der Quellplattform als Webhook-Ziel eingeben.

Hinweis: Die Webhook-URL wird nach dem Speichern angezeigt. Kopieren Sie diese URL sofort, da sie nach dem Verlassen der Seite nicht mehr sichtbar ist. Sie benötigen diese URL, um das Webhook-Ziel auf der Quellplattform zu konfigurieren. Wenn Sie die URL nicht kopieren, bevor Sie speichern, klicken Sie auf im Cache Neue URL generieren, um eine neue URL zu erstellen.

Kartendaten

Nachdem Sie ein JSON-Beispiel hochgeladen haben, können Sie im Abschnitt Datenabgleich Felder aus Ihrer JSON-Quelle den entsprechenden Feldern in Google Security Operations SOAR zuordnen. Das System verarbeitet Ihr rohes JSON und Sie verwenden die Benutzeroberfläche, um die Zuordnungen festzulegen.

1. Klicken Sie im Bereich Datenabgleich auf JSON-Beispiel hochladen. Geben Sie ein repräsentatives Beispiel der JSON-Nutzlast an, die Ihr Webhook sendet.
2. Ordnen Sie die Google Security Operations-Felder den entsprechenden Feldern in Ihrem JSON-Beispiel zu. Wenn Sie beispielsweise das Pflichtfeld StartTime zuordnen möchten, können Sie ein Zeitstempelfeld aus Ihrem JSON-Dokument auswählen, z. B. Detections.Last.Update.
3. Verwenden Sie den Ausdruckseditor, um die Daten zu verfeinern. Mit der Funktion Datumsformat können Sie beispielsweise Ihren Zeitstempel in das erforderliche Format „Unix-Epochenzeit in Millisekunden“ konvertieren. Weitere Informationen finden Sie unter Ausdrucks-Generator verwenden.
4. Klicken Sie im Ausdrucks-Editor auf Ausführen, um die Zuordnung zu testen und das Ergebnis zu sehen. Ein grünes Häkchen weist auf eine erfolgreiche Zuordnung hin.
5. Die JSON-Nutzlast Ihres Webhooks muss die erforderlichen Felder für die Fallerstellung und die Aufnahme von Benachrichtigungen enthalten. Weitere Informationen finden Sie unter Webhook-JSON-Schema.
6. Nachdem Sie alle erforderlichen Felder zugeordnet haben, klicken Sie auf Speichern und aktivieren Sie dann den Webhook.

Zuordnungszielfelder verstehen

Wenn Sie Ihre JSON-Daten zuordnen, ordnen Sie sie standardisierten Feldern in Google Security Operations SOAR zu. Diese Felder sind in Kategorien unterteilt, damit Sie die eingehenden Daten normalisieren und strukturieren können. Die in der Benutzeroberfläche für den Datenabgleich verfügbaren Felder basieren auf der internen Systemontologie. Die Hauptkategorien sind:

• Felder für Entitäten:Verwenden Sie diese Felder für Datenpunkte, aus denen das System automatisch Entitäten wie IP-Adressen, Domainnamen, Dateihashes und Nutzernamen extrahieren und modellieren kann. Durch die Zuordnung zu diesen Feldern wird die Benachrichtigung angereichert und die Korrelation und das Pivoting werden verbessert.
• Allgemeine Ereignisfelder: Verwenden Sie diese für allgemeine Ereignismetadaten wie Zeitstempel (StartTime, EndTime), Ereignisbeschreibungen oder ‑nachrichten und andere gängige Ereignisattribute.
• Technische und Gerätemetadaten: Verwenden Sie diese Felder für technische Details zur Ereignisquelle, z. B. den Anbieter und das Produkt des meldenden Geräts (DeviceVendor, DeviceProduct), den Schweregrad des Ereignisses und andere ähnliche technische Attribute.

Sehen Sie sich die verfügbaren Felder im Tool für den Datenabgleich in der Google Security Operations SOAR-Benutzeroberfläche an, um das am besten geeignete Zielfeld für die einzelnen Daten in Ihrer JSON-Nutzlast zu finden.

JSON-Schema für Webhooks

Damit Ihre Benachrichtigungen von Google Security Operations SOAR richtig aufgenommen und verarbeitet werden, muss die JSON-Nutzlast Ihres Webhooks einer bestimmten Struktur folgen. In den folgenden Tabellen werden die wichtigsten Felder der JSON-Nutzlast beschrieben.

Hauptfelder für Fälle und Benachrichtigungen

Diese Felder stellen die Attribute der obersten Ebene der erstellten Benachrichtigung oder des erstellten Falls dar.

Feld	Typ	Empfohlenes Format	Erforderlich	Beschreibung	Beispiel
TicketId	String	UUID	Ja	Eine interne global eindeutige Kennung (GUID) für einen Fall in der SOAR-Plattform. Die Anforderung für die Eindeutigkeit von TicketId ist bedingt und hängt von DisplayId ab: Wenn ein eindeutiges DisplayId angegeben wird, muss das TicketId nicht eindeutig sein. Wenn DisplayId nicht angegeben ist, muss TicketId eindeutig sein. Der TicketId hat oft denselben Wert wie der DisplayId.	"f7167971-f641-432f-a06f-ebca3caaa9dd"
SourceSystemName	String	Text	Ja	Der Name des externen Systems (z. B. SIEM oder ein EDR-System (Endpoint Detection and Response)), das die ursprünglichen Benachrichtigungen an SOAR gesendet hat.	"Splunk"
Name	String	Text	Ja	Der Titel oder Name des Falls, der oft aus dem Quellalerttyp oder der Zusammenfassung übernommen wird.	"Suspicious Login Attempt"
DeviceVendor	String	Text	Ja	Der Anbieter des Geräts oder Produkts, das die Benachrichtigung generiert hat. Diese können auch aus den Ereignisdaten zugeordnet werden.	"Palo Alto Networks"
RuleGenerator	String	Text	Ja	Der Name der Regel im Quellsystem (z. B. eine SIEM-Korrelationsregel), die die Benachrichtigung generiert hat.	"Brute Force Attempt Detected"
StartTime	String oder Ganzzahl	Epochen-Millisekunden (UTC) oder ISO8601-String (z. B. „2026-04-09T14:30:00Z“)	Ja	Die Startzeit des frühesten Ereignisses im Fall. Wenn Sie eine Ganzzahl angeben, muss sie in Unix-Epochen-Millisekunden angegeben werden.	1670000000000 oder "2026-04-09T14:30:00Z"
Environment	String	Text	Nein	Der Name der SOAR-Umgebung, zu der diese Benachrichtigung gehört. Dies muss mit einer Umgebung übereinstimmen, die in Ihren SOAR-Einstellungen definiert ist.	"Default Environment"
Description	String	Text	Nein	Eine kurze Beschreibung des Falls oder der Benachrichtigung.	"Failed login followed by success from new IP"
DisplayId	String	UUID oder String	Nein	Eine Kennung, die in der SOAR-Benutzeroberfläche zu Anzeigezwecken verwendet wird. Dieses Feld ist der Primärschlüssel, den das System prüft, um doppelte Benachrichtigungen zu erkennen. Eine Benachrichtigung wird als Duplikat abgelehnt, wenn die DisplayId nicht eindeutig ist. Diese Eindeutigkeitsprüfung für DisplayId hat Vorrang vor TicketId. DisplayId hat oft denselben Wert wie TicketId.	"f7167971-f641-432f-a06f-ebca3caaa9dd"
Reason	String	Text	Nein	Der Grund, aus dem die Benachrichtigung erstellt oder ausgelöst wurde.	"Unusual file access patterns detected."
DeviceProduct	String	Text	Nein	Der Produktname des Anbieters, der die Benachrichtigung generiert hat. Das kann auch aus den Ereignisdaten abgeleitet werden.	"Cortex XDR"
EndTime	String oder Ganzzahl	Epochen-Millisekunden (UTC) oder ISO8601-String (z. B. „2026-04-09T14:30:00Z“)	Nein	Die Endzeit des letzten Ereignisses im Fall. Wenn Sie eine Ganzzahl angeben, muss sie in Unix-Epochen-Millisekunden angegeben werden.	1670000060000 oder "2026-04-09T14:31:00Z"
Priority	Ganzzahl	0–100	Nein	Die Prioritätsstufe der Anfrage. Ohne Angabe wird der Standardwert 40 verwendet. (0–19: informativ, 20–39: niedrig, 40–59: mittel, 60–79: hoch, 80–100: kritisch)	80
EventsList	Array	Array von JSON-Objekten	Nein	Ein Array mit einem oder mehreren Rohereignisobjekten, wie sie von der Quelle empfangen wurden. Weitere Informationen finden Sie unter Rohereignisdaten senden.	[ { ... }, { ... } ]
EventProduct	String	Text	Nein	Das Produkt, mit dem die Ereignisse erstellt wurden.	"Cortex XDR"
EventName	String	Text	Nein	Der Titel oder Name des Ereignisses, der oft aus dem Typ oder der Zusammenfassung der Quellbenachrichtigung stammt.	"Suspicious Login Attempt"

Rohdaten zu Ereignissen senden – das EventsList-Array

Sie sollten die rohe JSON-Nutzlast, die die Ereignisse darstellt, wie sie aus dem Quellsystem stammen, im EventsList-Array senden. Dieses Objekt ist ein Element im EventsList-Array. Anschließend ordnen Sie Felder wie source_ip und timestamp über die Benutzeroberfläche für die Datenzuordnung zu.

Beispiel für ein Ereignisobjekt im EventsList-Array

{
  "event_id": "9a8b7c-1234-5678",
  "timestamp": "2026-07-01T07:29:50Z",
  "signature": "UserLoginFailed",
  "severity": "Medium",
  "user_name": "administrator",
  "source_ip": "192.168.1.50",
  "destination_ip": "10.0.0.10",
  "domain": "CORP",
  "status": "Failure",
  "Reason": "Wrong Password",
  "EventProduct": "Acme Firewall",
  "EventName": "Failed Login Attempt"
}

Wichtige Überlegungen und Best Practices

• Zeitstempel:Verwenden Sie für alle StartTime- und EndTime-Felder auf der obersten Ebene Unix-Epochen-Millisekunden (als Ganzzahl). Geben Sie in den Ereignisdaten Zeitstempel so an, wie sie aus der Quelle stammen. Die Konvertierung erfolgt in der Benutzeroberfläche für den Datenabgleich.
• Pflichtfelder:Alle Felder, die in der Spalte „Pflichtfeld“ mit „Ja“ gekennzeichnet sind, müssen in der JSON-Nutzlast enthalten sein.
• EventsList-Array:Dieses Array ist entscheidend. Auch wenn die Benachrichtigung ein einzelnes Ereignis darstellt, muss sie im EventsList-Array enthalten sein.
• Benutzeroberfläche für die Datenzuordnung:Mit dem Tool für die Datenzuordnung auf der Benutzeroberfläche Webhook-Konfiguration können Sie Felder aus Ihrem Roh-JSON den entsprechenden Google Security Operations SOAR-Feldern zuordnen.
• Eindeutigkeit:DisplayId muss für jede neue Benachrichtigung eindeutig sein, um eine Deduplizierung zu vermeiden. TicketId muss eindeutig sein, wenn DisplayId nicht angegeben ist.
• Antwortstatus:Eine HTTP 200 OK-Antwort vom Webhooks Ingest-Endpunkt bestätigt, dass die Nutzlast empfangen wurde. Sie garantiert jedoch nicht, dass eine Benachrichtigung erstellt wird. Das Erstellen von Benachrichtigungen kann während der Downstream-Verarbeitung aufgrund der Nutzlaststruktur oder Filterregeln fehlschlagen. Sie können den Status der Downstream-Verarbeitung mit der Funktion SOAR-Plattformprotokolle erfassen verfolgen.
• Testen:Verwenden Sie die Tabs JSON-Beispiel hochladen und Testen auf der Seite Webhook-Konfiguration in SOAR, um Ihre Nutzlaststruktur und Zuordnungen zu validieren.

Hinweis zur Anzeige von Ereigniszeitstempeln:Beim Erfassen von Ereignisdaten über Webhooks kann die Anzeige von Zeitstempelfeldern in der Liste mit den Benachrichtigungsdetails variieren. Die Plattform versucht, Felder zu formatieren, die zeitbezogen zu sein scheinen, und geht davon aus, dass der Wert in Millisekunden seit der Epoche angegeben ist. Wenn ein Zeitstempelfeld (oft eines, das „time“ im Namen enthält, z. B. „@timestamp“) in einem anderen Format als Epochen-Millisekunden gesendet wird (z. B. „MM/DD/YYYY HH:MM:SS“ oder „YYYY-MM-DDTHH:MM:SSz“), wird die Zeit in der Listenansicht möglicherweise nicht wie erwartet angezeigt. Das liegt daran, dass das System versucht, den Wert als Millisekunden seit der Epoche zu interpretieren. Sie können den ursprünglichen Rohwert, der im Webhook gesendet wurde, aufrufen, indem Sie in der Ereignisliste auf das Zeitstempelfeld doppelklicken. Damit die Anzeigeergebnisse auf der gesamten Plattform möglichst einheitlich sind, sollten Sie das Quellsystem so konfigurieren, dass Zeitwerte nach Möglichkeit in Epoch-Millisekunden gesendet werden. Alternativ können Sie in der Benutzeroberfläche für die Datenzuordnung für eine korrekte Umrechnung sorgen.

Webhook testen

Auf dem Tab Test können Sie die End-to-End-Funktionalität des Webhooks testen und detaillierte Fehlerbeschreibungen aufrufen.

1. Kopieren Sie auf dem Tab Testen die Webhook-URL.
2. Laden Sie eine JSON-Datei mit den relevanten Daten hoch.
3. Klicken Sie auf Ausführen. Die Ergebnisse werden zusammen mit der Ausgabe angezeigt.

CrowdStrike-Plattform konfigurieren

In diesem Anwendungsfall werden die Schritte in CrowdStrike beschrieben, die erforderlich sind, damit der Webhook mit der Aufnahme von Benachrichtigungen in die Google SecOps-Plattform beginnt.

1. Rufen Sie im CrowdStrike Falcon-Dashboard den Falcon Store auf und installieren Sie das Webhooks-Add-on.
2. Konfigurieren Sie den Webhook mit dem Namen und der Webhook-URL, die Sie von der Google SecOps-Plattform kopiert haben, und klicken Sie dann auf Speichern.
3. Wechseln Sie zum Bereich Workflows.
4. Klicken Sie auf Workflow erstellen.
5. Wählen Sie einen Trigger aus, z. B. Neue Erkennung, und klicken Sie auf Weiter.
6. Wählen Sie Aktion hinzufügen aus.
7. Wählen Sie im Bereich Aktion anpassen im Menü Aktionstyp die Option Benachrichtigungen und im Menü Aktion die Option Webhook aufrufen aus.
8. Wählen Sie den Namen, den Sie im ersten Schritt hinzugefügt haben, und alle erforderlichen Felder aus und klicken Sie dann auf Fertig.

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