> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wirespeed.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Generic Detection

> Senden Sie Detektionen aus einem beliebigen System per Webhook an Wirespeed

Die Generic Detection-Integration macht jedes System, das einen HTTPS-POST senden kann — ein SIEM, ein internes Tool, ein Skript oder ein anderes Sicherheitsprodukt — zu einer Detektionsquelle für Wirespeed. Sie senden eine Detektion pro Anfrage im dokumentierten JSON-Format, und Wirespeed führt die Triage dafür durch wie für eine Detektion aus jeder anderen Integration: Assets werden extrahiert, die Detektion wird mit der von Ihnen angegebenen Kategorie klassifiziert und erscheint in **Detections** und im SIEM.

Verwenden Sie diese Integration, wenn Ihr System bereits fertige Detektionen produziert. Wenn Wirespeed stattdessen Detektionen in Rohprotokollen finden soll, verwenden Sie [Generic JSON](https://docs.wirespeed.co/de/integrations/generic-json.md) oder eine dedizierte Integration für Ihr Produkt.

## Einrichtung in Wirespeed

1. Melden Sie sich bei Wirespeed an und navigieren Sie zu Integrations > [**Add Integration**](https://app.wirespeed.co/settings/integrations?tab=browse) > **Generic Detection**
2. Geben Sie einen **Quellennamen** ein, um dieses sendende System zu identifizieren (zum Beispiel `Internal SIEM`)
3. Aktivieren Sie optional **Authentifizierung** (siehe [Authentifizierung](#authentication))
4. Klicken Sie auf **Integrate**
5. Wählen Sie **Webhook Details**
6. Kopieren Sie die **Webhook-URL** und, falls Sie die Authentifizierung aktiviert haben, das **Webhook-Secret**

Die Webhook-URL hat die Form:

```text theme={null}
https://<API_HOST>/integration/webhook/generic-detection/receive-detection?teamId=<TEAM_ID>&integrationId=<INTEGRATION_ID>
```

Erstellen Sie eine Generic Detection-Integration pro sendendem System. Jede Integration hat ihre eigene URL, ihr eigenes optionales Secret und ihren eigenen Quellennamen, sodass Zustellungen zuordenbar bleiben und das Secret eines Systems rotiert werden kann, ohne ein anderes zu beeinträchtigen.

## Authentifizierung

Die Authentifizierung ist optional und standardmäßig deaktiviert. Wenn **Authentifizierung** aktiviert ist, muss jede Anfrage das Webhook-Secret der Integration im Header `X-Webhook-Key` enthalten:

```text theme={null}
X-Webhook-Key: <WEBHOOK_SECRET>
```

Anfragen mit fehlendem oder falschem Schlüssel werden mit `401` abgelehnt, und die Ablehnung wird im Protokoll der Integration vermerkt (höchstens einmal alle fünf Minuten, damit ein falsch konfigurierter Absender das Protokoll nicht fluten kann). Das Secret wird niemals in der URL oder im Anfragekörper akzeptiert.

### Das Secret rotieren

1. Öffnen Sie die **Webhook Details** der Integration
2. Klicken Sie auf **Secret rotieren**
3. Aktualisieren Sie den Absender mit dem neuen Secret

Das alte Secret funktioniert nicht mehr, sobald die Rotation abgeschlossen ist. Es gibt keine Übergangsfrist, aktualisieren Sie den Absender also umgehend; Zustellungen, die zwischenzeitlich mit dem alten Secret gesendet werden, werden mit `401` abgelehnt und nicht in die Warteschlange gestellt.

## Eine Detektion senden

Senden Sie eine Detektion pro `POST`-Anfrage mit einem JSON-Körper:

```bash theme={null}
curl -X POST '<WEBHOOK_URL>' \
  -H 'Content-Type: application/json' \
  -H 'X-Webhook-Key: <WEBHOOK_SECRET>' \
  -d '{
    "id": "alert-9042",
    "source": "internal-siem",
    "title": "Impossible travel sign-in",
    "description": "User signed in from two countries within one hour without a VPN session.",
    "severity": "high",
    "category": "IDENTITY__LOGIN",
    "occurredAt": "2026-11-13T15:00:00Z",
    "assets": {
      "users": [{ "email": "jane.doe@example.com", "username": "jane.doe" }]
    }
  }'
```

Lassen Sie den Header `X-Webhook-Key` weg, wenn Sie die Authentifizierung nicht aktiviert haben. Eine `200`-Antwort bedeutet, dass die Detektion akzeptiert und in die Warteschlange gestellt wurde; sie wartet nicht auf den Abschluss der Triage.

## Payload-Referenz

Unbekannte Felder werden abgelehnt, auch innerhalb von `assets`, sodass ein Tippfehler die Anfrage fehlschlagen lässt, statt still verworfen zu werden.

| Feld | Erforderlich | Beschreibung |
| - | - | - |
| `id` | Nein | Stabile eindeutige ID aus Ihrem System (max. 256 Zeichen). Wiederholungen mit derselben `id` werden dedupliziert, senden Sie also immer eine, wenn Ihr System eine hat. |
| `source` | Nein | Name des sendenden Systems (max. 128 Zeichen). Wird in der SIEM-Zeile gespeichert; verwenden Sie ihn, um eine Quelle zu filtern, wenn eine Integration mehrere Absender bündelt. |
| `title` | Ja | Kurze Zusammenfassung der Detektion (max. 512 Zeichen). |
| `description` | Ja | Was passiert ist und warum es wichtig ist (max. 10.000 Zeichen). Das lesen Analysten bei der Triage. |
| `severity` | Ja | Einer von `informational`, `low`, `medium`, `high`, `critical`. |
| `category` | Ja | Eine der [Kategorien](#categories) unten, im Standard-Wirespeed-Format mit doppelten Unterstrichen. |
| `occurredAt` | Ja | ISO 8601-Zeit des erkannten Vorgangs, zum Beispiel `2026-11-13T15:00:00Z`. |
| `firstSeenAt` | Nein | ISO 8601-Zeit der ersten Beobachtung. Darf nicht nach `lastSeenAt` liegen. |
| `lastSeenAt` | Nein | ISO 8601-Zeit der letzten Beobachtung. Darf nicht vor `occurredAt` oder `firstSeenAt` liegen. |
| `referenceUrl` | Nein | `http`- oder `https`-Link zurück zur Detektion in Ihrem System. |
| `blocked` | Nein | Setzen Sie `true`, wenn Ihr System den Vorgang blockiert hat. |
| `mitigated` | Nein | Setzen Sie `true`, wenn Ihr System den Vorgang bereits abgeschwächt oder behoben hat. |
| `assets` | Ja | Mindestens eines von `users`, `endpoints`, `files` oder `ips`. Jedes ist ein Array; jedes Asset im Array braucht mindestens ein identifizierendes Feld (siehe unten). |

### Assets

Assets teilen Wirespeed mit, welche Benutzer, Endgeräte, Dateien oder IP-Adressen von der Detektion betroffen sind, damit sie mit Ihrem Inventar korreliert werden kann. Benutzer, Endgeräte und Dateien können bei Bedarf auch eingedämmt werden; IP-Adressen dienen nur der Korrelation. Senden Sie so viele, wie die Detektion betrifft — bis zu 50 pro Typ in einer Anfrage. Senden Sie nur die Felder, die Sie kennen: Jedes Benutzer-, Endgeräte- oder Datei-Asset braucht mindestens eines seiner Felder, und jedes IP-Asset braucht `address`.

| Asset | Felder |
| - | - |
| `assets.users[]` | `id` (Ihre eindeutige Benutzer-ID), `email`, `username` |
| `assets.endpoints[]` | `id` (Ihre eindeutige Endgeräte-ID), `hostname` |
| `assets.files[]` | `name`, `path`, `sha256` (64 Hex-Zeichen), `sha1` (40 Hex-Zeichen) |
| `assets.ips[]` | `address` (Pflicht): eine IPv4- oder IPv6-Adresse, zum Beispiel `203.0.113.7` oder `2001:db8::1` |

Hashes sind nicht groß-/kleinschreibungsempfindlich und werden in Kleinbuchstaben gespeichert. Ein Hash mit falscher Länge oder Nicht-Hex-Zeichen lässt die Anfrage fehlschlagen.

Senden Sie jede IP-Adresse als reine Adresse. Ein Port (`203.0.113.7:443`), ein CIDR-Bereich (`10.0.0.0/8`) oder ein Hostname lässt die Anfrage fehlschlagen; senden Sie Hostnamen stattdessen als Endgeräte. IPv6-Adressen werden in Kleinbuchstaben gespeichert.

### Kategorien

Wählen Sie die eine Kategorie, die die Detektion am besten beschreibt. Die Liste ist bewusst kurz; senden Sie für eine verdächtige Detektion die am besten passende Kategorie. Verwenden Sie `OTHER__INFORMATIONAL_EVENT` nur für Aktivität, die keine Reaktion erfordert, denn Wirespeed schließt diese Detektionen automatisch als harmlos.

Kategoriewerte verwenden das Standard-Kategorieformat von Wirespeed: Großbuchstaben-Segmente, verbunden durch **doppelte Unterstriche**. Zum Beispiel hat `IDENTITY__LOGIN` zwei Unterstriche zwischen `IDENTITY` und `LOGIN` — `IDENTITY_LOGIN` und `IDENTITY-LOGIN` werden nicht akzeptiert.

| Kategorie | Verwendung für |
| - | - |
| `IDENTITY__LOGIN` | Verdächtige oder anomale Anmeldungen |
| `ENDPOINT__EXECUTION` | Verdächtige Programme, Befehle oder Malware auf einem Endgerät |
| `CLOUD__INVOCATION` | Verdächtige Cloud-API-Aufrufe |
| `NETWORK__INBOUND_CONNECTION` | Verdächtige eingehende Netzwerkverbindungen |
| `NETWORK__OUTBOUND_CONNECTION` | Verdächtige ausgehende Netzwerkverbindungen |
| `DATA__DATA_TRANSFER` | Ungewöhnliche Datenbewegung oder Exfiltration |
| `OTHER__INFORMATIONAL_EVENT` | Informative Aktivität, die keine Reaktion erfordert; wird automatisch als harmlos geschlossen |

## Beispiel-Payloads

### Endgeräte-Malware mit einem Datei-Asset

```json theme={null}
{
  "id": "edr-77120",
  "source": "custom-edr",
  "title": "Malware executed on workstation",
  "description": "The agent quarantined evil.exe after it injected into explorer.exe.",
  "severity": "critical",
  "category": "ENDPOINT__EXECUTION",
  "occurredAt": "2026-11-13T14:58:11Z",
  "referenceUrl": "https://edr.example.com/alerts/edr-77120",
  "blocked": true,
  "mitigated": true,
  "assets": {
    "endpoints": [{ "id": "endpoint-7", "hostname": "WS-001" }],
    "files": [
      {
        "name": "evil.exe",
        "path": "C:\\Users\\jane\\Downloads\\evil.exe",
        "sha256": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
      }
    ]
  }
}
```

### Netzwerkverbindung mit IP-Adress-Assets

```json theme={null}
{
  "id": "fw-30418",
  "source": "perimeter-firewall",
  "title": "Outbound connection to known command-and-control server",
  "description": "WS-014 opened a TLS session to an IP address on the command-and-control blocklist.",
  "severity": "high",
  "category": "NETWORK__OUTBOUND_CONNECTION",
  "occurredAt": "2026-11-13T09:41:27Z",
  "blocked": true,
  "assets": {
    "endpoints": [{ "hostname": "WS-014" }],
    "ips": [{ "address": "198.51.100.23" }, { "address": "2001:db8::1" }]
  }
}
```

### Minimale Payload

Nur die erforderlichen Felder. Wirespeed kann für diese Detektion die Triage durchführen, aber eine `id` und Asset-Kennungen verbessern Deduplizierung und Korrelation.

```json theme={null}
{
  "title": "Unusual outbound transfer",
  "description": "Workstation uploaded 2 GB to an unknown host overnight.",
  "severity": "medium",
  "category": "DATA__DATA_TRANSFER",
  "occurredAt": "2026-11-13T07:12:00Z",
  "assets": {
    "endpoints": [{ "hostname": "WS-014" }]
  }
}
```

## Fehler und Grenzfälle

Abgelehnte Zustellungen werden niemals in die Warteschlange gestellt. Wenn eine Zustellung die Validierung nicht besteht, wird der Grund im Protokoll der Integration in Wirespeed vermerkt, damit Sie den Absender korrigieren können; schauen Sie dort zuerst nach, wenn Detektionen nicht erscheinen.

| Status | Bedeutung | Was zu tun ist |
| - | - | - |
| `400` | Fehlerhafte oder ungültige Payload: fehlendes Pflichtfeld, unbekanntes Feld, ungültige `category` oder `severity`, nicht lesbare oder falsch geordnete Zeitstempel, ein Asset ohne Kennungen oder eine fehlerhafte E-Mail, URL, Hash oder IP-Adresse. | Korrigieren Sie das im Protokolleintrag der Integration genannte Feld und senden Sie erneut. |
| `401` | Die Authentifizierung ist aktiviert und der Header `X-Webhook-Key` fehlt oder stimmt nicht überein. | Senden Sie das aktuelle Webhook-Secret. Wenn Sie es rotiert haben, aktualisieren Sie den Absender. |
| `404` | Die `teamId` oder `integrationId` in der URL identifiziert keine Integration. | Kopieren Sie die Webhook-URL erneut aus den **Webhook Details**. |
| `422` | Die Webhook-Verarbeitung ist vorübergehend pausiert. | Mit Backoff erneut versuchen. |
| `429` | Ihr Team hat das Webhook-Ratenlimit überschritten (3.000 Anfragen/Minute). | Mit Backoff erneut versuchen; Batch-Absender sollten Zustellungen verteilen. |

Grenzfälle, die Sie kennen sollten:

* **Eine Detektion pro Anfrage.** Senden Sie ein Array, schlägt die Validierung fehl; iterieren Sie stattdessen über die Detektionen.
* **Wiederholungen sind mit einer `id` sicher.** Dieselbe `id` zweimal zugestellt wird zu einer Detektion. Ohne `id` kann eine Wiederholung ein Duplikat erzeugen.
* **Zukünftige Zeitstempel** werden für die Ereigniszeit der Detektion auf die Ingestionszeit geklemmt; die von Ihnen gesendeten Zeitstempel bleiben in der SIEM-Zeile erhalten.
* **Deaktivierte Integrationen** lehnen Zustellungen ab, bis sie wieder aktiviert werden.
* **Secrets in URLs werden ignoriert.** Ein Query-Parameter `webhookSecret` authentifiziert keine Anfrage; verwenden Sie den Header `X-Webhook-Key`.

## Was Wirespeed damit macht

Jede akzeptierte Zustellung wird zu einer vollwertigen Wirespeed-Detektion, genau wie eine Detektion aus jeder integrierten Integration, und durchläuft automatisch die Triage: Wirespeed untersucht sie, trifft ein Urteil und eskaliert oder reagiert gemäß den Automatisierungseinstellungen Ihres Teams, ohne manuellen Schritt. Die von Ihnen gesendeten Benutzer, Endgeräte und Dateien werden für Korrelation und Eindämmung extrahiert, die IP-Adressen für die Korrelation, die Detektion wird mit der von Ihnen gesendeten `category` klassifiziert, und die normalisierte Payload wird in die SIEM-Tabelle `generic_detection_logs` geschrieben. Im SIEM können Sie diese Tabelle nach `severity`, `category` und `source` filtern; Zeilen werden nach Team, dann `source`, dann Zeit sortiert gespeichert, damit nach Quelle gefilterte Abfragen schnell bleiben. Jede Generic Detection-Integration erscheint außerdem als eigene SIEM-Quelle unter ihrem **Source Name**, sodass Zustellungen verschiedener sendender Systeme getrennt bleiben, obwohl sie sich eine Tabelle teilen.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.