Webhooks verwenden

Webhooks ermöglichen Hydden Discovery die Integration mit jedem HTTP-fähigen System durch automatisierte HTTP-Anfragen, wenn Ereignisse auftreten. Verwenden Sie Webhooks, um Daten an SIEM-Plattformen, Ticketing-Systeme, Chat-Anwendungen, benutzerdefinierte APIs und andere externe Dienste zu senden.

Übersicht

Webhook-Provider senden HTTP-Anfragen an externe Endpunkte, wenn Workflow-Trigger ausgelöst werden. Webhooks sind hochflexibel und unterstützen:

Mehrere HTTP-Methoden: GET, POST, PUT
Benutzerdefinierte Payloads: JSON, XML oder beliebiges Textformat mit Vorlagenvariablen-Substitution
Authentifizierung: Bearer-Token und anmeldeinformationsbasierte Authentifizierung
Automatische Wiederholungen: 5 Versuche mit exponentiellem Backoff
Flexible Formatierung: Benutzerdefinierte Payloads senden oder automatisch aus Ereignisdaten generieren

Voraussetzungen

Vor der Konfiguration von Webhook-Providern:

Zielendpunkt: Die Webhook-URL muss von Hydden Discovery erreichbar sein
Authentifizierung: Falls erforderlich, erstellen Sie Anmeldeinformationen unter Configuration > Settings > Credentials oder beschaffen Sie einen Bearer-Token
Netzwerkzugriff: Stellen Sie sicher, dass Hydden Discovery den Webhook-Endpunkt erreichen kann (Firewalls, Netzwerkrichtlinien prüfen)
Endpunktanforderungen: Verstehen Sie das erwartete Payload-Format, die HTTP-Methode und die Authentifizierungsmethode für Ihr Zielsystem

Webhook-Provider hinzufügen

So fügen Sie einen Webhook-Provider hinzu:

Navigieren Sie zu Configuration > Automate.
Klicken Sie auf der Registerkarte Provider auf + Add New.
Wählen Sie aus dem Drop-down Type den Eintrag Webhook.
Geben Sie unter Name einen beschreibenden Provider-Namen ein (z. B. "Splunk SIEM Integration", "Slack Notifications").
Geben Sie unter Description eine optionale Beschreibung des Provider-Zwecks an.
Wählen Sie aus dem Drop-down Method die HTTP-Methode:
- POST (Standard): Am häufigsten für Webhook-Integrationen
- PUT: Für Update-Operationen oder REST-APIs, die PUT erfordern
- GET: Für einfache Benachrichtigungen oder APIs, die Daten über Abfrageparameter akzeptieren
Geben Sie unter URL die vollständige Webhook-Endpunkt-URL an:
- Muss das Protokoll enthalten: https://webhook.example.com/api/events
- Kann Abfrageparameter enthalten: https://api.example.com/notify?source=hydden
- Muss von der Hydden Discovery Instanz erreichbar sein
(Optional) Geben Sie unter Token einen Bearer-Token ein, wenn der Endpunkt Bearer-Token-Authentifizierung erfordert:
- Leer lassen bei anmeldeinformationsbasierter Authentifizierung oder ohne Authentifizierung
- Token wird als Header Authorization: Bearer <token> gesendet
Wählen Sie aus dem Drop-down Credential eine vorkonfigurierte Anmeldeinformation, wenn der Endpunkt anmeldeinformationsbasierte Authentifizierung erfordert:
- Leer lassen bei Bearer-Token-Authentifizierung oder ohne Authentifizierung
- Anmeldeinformationen werden als HTTP Basic Auth oder wie konfiguriert gesendet
Klicken Sie auf Save.

Authentifizierungsmethoden

Webhooks unterstützen drei Authentifizierungsansätze:

Keine Authentifizierung

Wenn der Webhook-Endpunkt öffentlich oder hinter einer Firewall/VPN ist:

Lassen Sie die Felder Token und Credential leer
Hydden Discovery sendet Anfragen ohne Authentifizierungsheader

Bearer-Token-Authentifizierung

Für APIs, die OAuth2-Token oder API-Schlüssel als Bearer-Token erfordern:

Geben Sie den Token im Feld Token der Provider-Konfiguration ein
Lassen Sie das Feld Credential leer
Token wird gesendet als: Authorization: Bearer <your-token>

Beispiel:

Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Anmeldeinformationsbasierte Authentifizierung

Für APIs, die Benutzername/Passwort oder andere Anmeldeinformationstypen erfordern:

Wählen Sie eine Anmeldeinformation aus dem Drop-down Credential
Lassen Sie das Feld Token leer
Anmeldeinformationen werden mit HTTP Basic Auth gesendet: Authorization: Basic <base64(username:password)>

Beispiel: Erstellen Sie eine Anmeldeinformation mit Benutzername api_user und Passwort api_key, dann wählen Sie diese in der Webhook-Provider-Konfiguration aus.

Webhook-Workflow hinzufügen

So erstellen Sie einen Webhook-Workflow:

Navigieren Sie zu Configuration > Automate.
Klicken Sie auf der Registerkarte Workflow auf + Add New.
Geben Sie unter Name einen beschreibenden Workflow-Namen an (z. B. "Send Threats to Splunk").
Geben Sie unter Description eine optionale Beschreibung des Workflow-Zwecks an.
Wählen Sie aus dem Drop-down Trigger das Ereignis, das diesen Webhook auslösen soll:
- Threat Detected
- Threat Resolved
- Collection Failed
- Collection Succeeded
- Data Validation Failed
- Data Validation Succeeded
- Classification Added
- Classification Removed
- Entity Alert
Wählen Sie aus dem Drop-down Action Ihren konfigurierten Webhook-Provider.
Geben Sie unter Payload den Webhook-Anfragekörper an:
- Benutzerdefinierter Payload: JSON, XML oder Text mit Vorlagenvariablen eingeben
- Automatisch generierter Payload: Leer lassen oder {} eingeben, um das vollständige Ereignis als JSON zu senden
- Vorlagenvariablen: Geben Sie { ein, um verfügbare Variablen zu sehen (siehe Trigger)
(Optional) Konfigurieren Sie Filteroptionen, um den Workflow einzugrenzen (siehe Workflows)
Klicken Sie auf Save.
Um den Workflow zu aktivieren, schalten Sie den Umschalter in der Tabellenzeile auf die Position on.

NOTE

Eine Erfassung muss mindestens einmal erfolgreich ausgeführt worden sein, bevor Aktionen ausgelöst werden können.

Payload-Konfiguration

Benutzerdefinierte Payloads

Benutzerdefinierte Payloads geben Ihnen volle Kontrolle über das Format des Anfragekörpers. Verwenden Sie Vorlagenvariablen, um Ereignisdaten einzubeziehen.

Beispiel JSON-Payload (für SIEM-Integration):

json

{
  "event_type": "threat_detected",
  "timestamp": "{JobTime}",
  "severity": "high",
  "threat": {
    "id": "{ThreatID}",
    "name": "{ThreatName}",
    "score": {Score}
  },
  "affected_accounts": "{Accounts}",
  "platform": "{Platform}",
  "site": "{Site}"
}

Beispiel XML-Payload:

xml

<alert>
  <type>threat</type>
  <name>{ThreatName}</name>
  <platform>{Platform}</platform>
  <accounts>{Accounts}</accounts>
  <score>{Score}</score>
</alert>

Beispiel Klartext-Payload (für Chat-Anwendungen):

Threat Alert: {ThreatName}

Platform: {Platform}
Affected Accounts: {Accounts}
Risk Score: {Score}
Site: {Site}

Action Required: Review and remediate immediately.

Automatisch generierte Payloads

Wenn Sie das Feld Payload leer lassen oder {} eingeben, sendet Hydden Discovery automatisch das vollständige Ereignisobjekt als formatiertes JSON.

Beispiel automatisch generierter Payload:

json

{
 "title": "Threat Detected",
 "threat_id": "dormant-admin-90",
 "threat_name": "Dormant Admin Account",
 "job_time": "2024-01-15T10:45:00Z",
 "platform": "Active Directory",
 "name": "admin_prod",
 "site": "corp.example.com",
 "status": "detected",
 "score": "85",
 "accounts": "admin_prod, admin_dev",
 "ids": "uuid-1, uuid-2"
}

Automatisch generierte Payloads sind nützlich, wenn:

Das Zielsystem flexible JSON-Schemas akzeptiert
Sie alle Ereignisdaten ohne Filterung möchten
Sie prototypisch arbeiten und alle verfügbaren Felder sehen möchten

HTTP-Methoden

POST (Standard)

Die meisten Webhook-Integrationen verwenden POST, um Daten an Zielsysteme zu senden.

POST verwenden für:

SIEM-Integrationen (Splunk, LogRhythm, QRadar)
Ticketing-Systeme (Jira, ServiceNow-Alternativen)
Chat-Anwendungen (Slack, Teams, Discord)
Benutzerdefinierte APIs, die Ressourcen erstellen

Eigenschaften:

Anfragekörper enthält Payload
Header Content-Type: application/json wird automatisch gesetzt
Häufigste Webhook-Methode

PUT

PUT für REST-APIs verwenden, die Update-Semantik oder idempotente Operationen erfordern.

PUT verwenden für:

REST-APIs mit Update-Operationen
Systeme, die idempotente Anfragen erfordern
APIs, die ressourcenbasierte URL-Muster verwenden

Eigenschaften:

Anfragekörper enthält Payload
Header Content-Type: application/json wird automatisch gesetzt
Weniger häufig als POST

GET

GET für einfache Benachrichtigungen oder Systeme verwenden, die Daten über Abfrageparameter akzeptieren.

GET verwenden für:

Einfache Benachrichtigungsendpunkte
Health-Check-Pings
Legacy-Systeme, die Abfrageparameter erwarten

Eigenschaften:

Kein Anfragekörper
Daten müssen in der URL oder in Abfrageparametern sein
Weniger häufig für Webhook-Integrationen

Wiederholung und Fehlerbehandlung

Webhooks enthalten automatische Wiederholungslogik zur Behandlung vorübergehender Fehler:

Wiederholungskonfiguration

Wiederholungsversuche: 5 automatische Wiederholungen
Timeout: 10 Sekunden pro Anfrage
Erfolgskriterien: HTTP 200-Statuscode
Fehler: Jeder Nicht-200-Statuscode oder Timeout

Wiederholungsverhalten

Erstanfrage: Webhook sendet die erste HTTP-Anfrage
Fehlererkennung: Wenn der Statuscode nicht 200 ist oder ein Timeout auftritt, wird die Anfrage als fehlgeschlagen markiert
Exponentielles Backoff: Nachfolgende Wiederholungen warten progressiv länger (exponentielles Backoff)
Endgültiger Fehler: Nach 5 fehlgeschlagenen Versuchen wird der Workflow als fehlgeschlagen markiert und protokolliert

Fehlerprotokollierung

Alle Webhook-Fehler werden protokolliert mit:

Workflow-ID und -Name
Aktions-Provider-ID und -Name
HTTP-Statuscode (falls empfangen)
Fehlermeldung
Zeitstempel

Überprüfen Sie die Hydden Discovery Protokolle für Informationen zur Webhook-Fehlerbehebung.

Häufige Integrationsbeispiele

Splunk SIEM Integration

Provider-Konfiguration:

Type: Webhook
Method: POST
URL: https://splunk.example.com:8088/services/collector/event
Token: Ihr Splunk HEC Token

Workflow-Payload:

json

{
  "sourcetype": "hydden:threat",
  "event": {
    "threat_name": "{ThreatName}",
    "threat_id": "{ThreatID}",
    "platform": "{Platform}",
    "accounts": "{Accounts}",
    "score": {Score},
    "site": "{Site}",
    "timestamp": "{JobTime}"
  }
}

Slack-Benachrichtigungen

Provider-Konfiguration:

Type: Webhook
Method: POST
URL: Ihre Slack Incoming Webhook URL

Workflow-Payload:

json

{
  "text": "Threat Detected: {ThreatName}",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*Threat Details*\n*Name:* {ThreatName}\n*Platform:* {Platform}\n*Accounts:* {Accounts}\n*Score:* {Score}"
      }
    }
  ]
}

Microsoft Teams Benachrichtigungen

Provider-Konfiguration:

Type: Webhook
Method: POST
URL: Ihre Teams Incoming Webhook URL

Workflow-Payload:

json

{
  "@type": "MessageCard",
  "@context": "https://schema.org/extensions",
  "summary": "Threat Detected",
  "themeColor": "FF0000",
  "title": "Threat Detected: {ThreatName}",
  "sections": [
    {
      "activityTitle": "Threat Details",
      "facts": [
        {
          "name": "Platform:",
          "value": "{Platform}"
        },
        {
          "name": "Accounts:",
          "value": "{Accounts}"
        },
        {
          "name": "Risk Score:",
          "value": "{Score}"
        },
        {
          "name": "Site:",
          "value": "{Site}"
        }
      ]
    }
  ]
}

Jira Issue-Erstellung

Provider-Konfiguration:

Type: Webhook
Method: POST
URL: https://your-instance.atlassian.net/rest/api/2/issue
Credential: Jira API Anmeldeinformation (E-Mail + API-Token)

Workflow-Payload:

json

{
  "fields": {
    "project": {
      "key": "SEC"
    },
    "summary": "Threat Detected: {ThreatName} on {Platform}",
    "description": "Threat {ThreatName} was detected on {Platform} affecting accounts: {Accounts}. Risk Score: {Score}. Site: {Site}.",
    "issuetype": {
      "name": "Bug"
    },
    "priority": {
      "name": "High"
    }
  }
}

Benutzerdefinierte REST-API

Provider-Konfiguration:

Type: Webhook
Method: POST oder PUT
URL: Ihr API-Endpunkt
Token oder Credential: Basierend auf Ihren API-Anforderungen

Workflow-Payload: Gestalten Sie basierend auf den Schema-Anforderungen Ihrer API

Fehlerbehebung

Problem	Lösung
Webhook wird nicht ausgelöst	Überprüfen, ob Workflow aktiviert ist, Trigger-Übereinstimmung mit Ereignistyp prüfen, Webhook-Provider-Konfiguration sicherstellen
HTTP-Timeout-Fehler	Netzwerkkonnektivität zum Webhook-Endpunkt prüfen, sicherstellen, dass der Endpunkt innerhalb von 10 Sekunden antwortet, Firewall-Regeln überprüfen
Authentifizierungsfehler	Bearer-Token oder Anmeldeinformationen auf Korrektheit prüfen, überprüfen, ob Token abgelaufen ist, Endpunkt-Authentifizierungsanforderungen bestätigen
400 Bad Request	Payload-Format auf Übereinstimmung mit Endpunkt-Erwartungen prüfen, erforderliche Felder überprüfen, JSON-Syntax validieren
401 Unauthorized	Authentifizierungsanmeldeinformationen prüfen, Bearer-Token-Gültigkeit überprüfen, Endpunkt-Authentifizierungsmethode mit Provider-Konfiguration abgleichen
403 Forbidden	API-Anmeldeinformationen auf erforderliche Berechtigungen prüfen, IP-Allowlists auf dem Zielsystem überprüfen
404 Not Found	Webhook-URL auf Korrektheit prüfen, auf Tippfehler in der URL prüfen, Endpunktpfad-Existenz bestätigen
500 Internal Server Error	Webhook-Endpunktprotokolle auf Fehler prüfen, Payload-Daten auf Gültigkeit überprüfen, Endpunktadministrator kontaktieren
SSL/TLS-Fehler	Sicherstellen, dass Webhook-URL `https://` verwendet, SSL-Zertifikat auf Gültigkeit prüfen, Zertifikatskette überprüfen
Variablen werden nicht ersetzt	Variablennamen auf Übereinstimmung mit Triggertyp prüfen (siehe Trigger), Syntax auf `{Variable}`-Format prüfen
Payload zu groß	Payload-Größe reduzieren, Filteroptionen verwenden, um Ereignisumfang zu begrenzen, Endpunktadministrator zu Größenlimits kontaktieren
Wiederholungen erschöpft	Webhook-Endpunktverfügbarkeit prüfen, sicherstellen, dass Endpunkt das Anfragevolumen verarbeiten kann, Fehlerprotokolle auf Ursache überprüfen

Best Practices

Sicherheit

HTTPS verwenden: Immer https://-URLs für Webhooks verwenden, um Daten bei der Übertragung zu verschlüsseln
Token rotieren: Bearer-Token und Anmeldeinformationen regelmäßig rotieren
Minimale Berechtigungen: Webhook-Endpunkten minimale erforderliche Berechtigungen gewähren
Endpunkte validieren: Webhook-Endpunkte testen, bevor Produktions-Workflows aktiviert werden
Fehler überwachen: Webhook-Fehlerprotokolle regelmäßig überprüfen

Payload-Design

Kontext einbeziehen: Relevante Ereignisdetails in Payloads einbeziehen, um Kontext zu bieten
Einfach halten: Keine unnötigen Felder einbeziehen, die die Payload-Größe erhöhen
Payloads testen: Payload-Formate mit Zielsystemen testen, bevor sie produktiv verwendet werden
Variablen verwenden: Vorlagenvariablen nutzen, um Daten dynamisch zu befüllen
Angemessen formatieren: Payload-Format an Endpunkterwartungen anpassen (JSON, XML usw.)

Leistung

Workflows filtern: Workflow-Filter verwenden, um unnötige Webhook-Aufrufe zu reduzieren
Wenn möglich bündeln: Wenn das Zielsystem Batching unterstützt, Aggregation von Ereignissen in Betracht ziehen
Volumen überwachen: Webhook-Aufrufvolumen verfolgen, um Zielsysteme nicht zu überlasten
Ratenbegrenzungen beachten: Ratenbegrenzungen auf Zielsystemen berücksichtigen

Betrieblich

Beschreibende Namen: Klare Provider- und Workflow-Namen verwenden, die den Zweck angeben
Integrationen dokumentieren: Webhook-Konfigurationen und Zwecke dokumentieren
Gründlich testen: Webhooks mit Beispielereignissen testen, bevor sie produktiv verwendet werden
Erfolgsrate überwachen: Webhook-Erfolgsraten verfolgen und Fehler untersuchen

Datenquellen

Universal Collector Übersicht

Risikoerkennungsregeln

OpenID-Anbieter

Anmeldedaten

CyberArk-Integration verwenden

Webhooks verwenden ​

Übersicht ​

Voraussetzungen ​

Webhook-Provider hinzufügen ​

Authentifizierungsmethoden ​

Keine Authentifizierung ​

Bearer-Token-Authentifizierung ​

Anmeldeinformationsbasierte Authentifizierung ​

Webhook-Workflow hinzufügen ​

Payload-Konfiguration ​

Benutzerdefinierte Payloads ​

Automatisch generierte Payloads ​

HTTP-Methoden ​

POST (Standard) ​

PUT ​

GET ​

Wiederholung und Fehlerbehandlung ​

Wiederholungskonfiguration ​

Wiederholungsverhalten ​

Fehlerprotokollierung ​

Häufige Integrationsbeispiele ​

Splunk SIEM Integration ​

Slack-Benachrichtigungen ​

Microsoft Teams Benachrichtigungen ​

Jira Issue-Erstellung ​

Benutzerdefinierte REST-API ​

Fehlerbehebung ​

Best Practices ​

Sicherheit ​

Payload-Design ​

Leistung ​

Betrieblich ​

Verwandte Themen ​

Webhooks verwenden

Übersicht

Voraussetzungen

Webhook-Provider hinzufügen

Authentifizierungsmethoden

Keine Authentifizierung

Bearer-Token-Authentifizierung

Anmeldeinformationsbasierte Authentifizierung

Webhook-Workflow hinzufügen

Payload-Konfiguration

Benutzerdefinierte Payloads

Automatisch generierte Payloads

HTTP-Methoden

POST (Standard)

PUT

GET

Wiederholung und Fehlerbehandlung

Wiederholungskonfiguration

Wiederholungsverhalten

Fehlerprotokollierung

Häufige Integrationsbeispiele

Splunk SIEM Integration

Slack-Benachrichtigungen

Microsoft Teams Benachrichtigungen

Jira Issue-Erstellung

Benutzerdefinierte REST-API

Fehlerbehebung

Best Practices

Sicherheit

Payload-Design

Leistung

Betrieblich

Verwandte Themen