> ## 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 > Envoyez des détections depuis n’importe quel système vers Wirespeed à l’aide d’un webhook L’intégration Generic Detection transforme tout système capable d’envoyer un POST HTTPS — un SIEM, un outil interne, un script ou un autre produit de sécurité — en source de détections pour Wirespeed. Vous envoyez une détection par requête au format JSON documenté, et Wirespeed la trie comme une détection de n’importe quelle autre intégration : les actifs sont extraits, la détection est classée avec la catégorie que vous fournissez, et elle apparaît dans **Détections** et dans le SIEM. Utilisez cette intégration lorsque votre système produit déjà des détections finalisées. Si vous voulez plutôt que Wirespeed trouve des détections dans des journaux bruts, utilisez [Generic JSON](https://docs.wirespeed.co/fr/integrations/generic-json.md) ou une intégration dédiée à votre produit. ## Configuration dans Wirespeed 1. Connectez-vous à Wirespeed et accédez à Intégrations > [**Ajouter une intégration**](https://app.wirespeed.co/settings/integrations?tab=browse) > **Generic Detection** 2. Saisissez un **Nom de la source** pour identifier ce système émetteur (par exemple, `Internal SIEM`) 3. Activez éventuellement **Authentification** (voir [Authentification](#authentication)) 4. Cliquez sur **Intégrer** 5. Sélectionnez **Détails du webhook** 6. Copiez l’**URL du webhook** et, si vous avez activé l’authentification, le **Secret du webhook** L’URL du webhook a la forme suivante : ```text theme={null} https:///integration/webhook/generic-detection/receive-detection?teamId=&integrationId= ``` Créez une intégration Generic Detection par système émetteur. Chaque intégration a sa propre URL, son propre secret facultatif et son propre Nom de la source, de sorte que les livraisons restent attribuables et que le secret d’un système peut être régénéré sans affecter un autre. ## Authentification L’authentification est facultative et désactivée par défaut. Lorsque **Authentification** est activé, chaque requête doit inclure le secret de webhook de l’intégration dans l’en-tête `X-Webhook-Key` : ```text theme={null} X-Webhook-Key: ``` Les requêtes dont la clé est absente ou incorrecte sont rejetées avec un `401` et le rejet est inscrit dans le journal de l’intégration (au plus une fois toutes les cinq minutes, pour qu’un émetteur mal configuré ne puisse pas inonder le journal). Le secret n’est jamais accepté dans l’URL ni dans le corps de la requête. ### Régénérer le secret 1. Ouvrez les **Détails du webhook** de l’intégration 2. Cliquez sur **Régénérer le secret** 3. Mettez à jour l’émetteur avec le nouveau secret L’ancien secret cesse de fonctionner dès que la régénération se termine. Il n’y a aucune période de grâce, alors mettez à jour l’émetteur rapidement ; les livraisons envoyées entre-temps avec l’ancien secret sont rejetées avec un `401` et ne sont pas mises en file d’attente. ## Envoyer une détection Envoyez une détection par requête `POST` avec un corps JSON : ```bash theme={null} curl -X POST '' \ -H 'Content-Type: application/json' \ -H 'X-Webhook-Key: ' \ -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" }] } }' ``` Omettez l’en-tête `X-Webhook-Key` si vous n’avez pas activé l’authentification. Une réponse `200` signifie que la détection a été acceptée et mise en file d’attente ; elle n’attend pas la fin du tri. ## Référence de la charge utile Les champs inconnus sont rejetés, y compris dans `assets`, de sorte qu’une faute de frappe fait échouer la requête au lieu d’être ignorée silencieusement. | Champ | Requis | Description | | - | - | - | | `id` | Non | Identifiant unique stable de votre système (256 caractères max). Les nouvelles tentatives qui réutilisent le même `id` sont dédupliquées, alors envoyez-en toujours un si votre système en possède un. | | `source` | Non | Nom du système émetteur (128 caractères max). Enregistré sur la ligne SIEM ; utilisez-le pour filtrer une source lorsqu’une intégration couvre plusieurs émetteurs. | | `title` | Oui | Court résumé de la détection (512 caractères max). | | `description` | Oui | Ce qui s’est passé et pourquoi cela compte (10 000 caractères max). C’est ce que les analystes lisent pendant le tri. | | `severity` | Oui | Une valeur parmi `informational`, `low`, `medium`, `high`, `critical`. | | `category` | Oui | Une des [catégories](#categories) ci-dessous, au format standard Wirespeed avec doubles traits de soulignement. | | `occurredAt` | Oui | Heure ISO 8601 de l’activité détectée, par exemple `2026-11-13T15:00:00Z`. | | `firstSeenAt` | Non | Heure ISO 8601 de la première observation de l’activité. Ne doit pas être après `lastSeenAt`. | | `lastSeenAt` | Non | Heure ISO 8601 de la dernière observation de l’activité. Ne doit pas être avant `occurredAt` ni `firstSeenAt`. | | `referenceUrl` | Non | Lien `http` ou `https` vers la détection dans votre système. | | `blocked` | Non | Mettez `true` lorsque votre système a bloqué l’activité. | | `mitigated` | Non | Mettez `true` lorsque votre système a déjà atténué ou résolu l’activité. | | `assets` | Oui | Au moins un actif parmi `users`, `endpoints`, `files` ou `ips`. Chacun est un tableau ; chaque actif du tableau doit avoir au moins un champ d’identification (voir ci-dessous). | ### Actifs Les actifs indiquent à Wirespeed quels utilisateurs, terminaux, fichiers ou adresses IP sont concernés par la détection, afin qu’elle puisse la corréler avec votre inventaire. Les utilisateurs, terminaux et fichiers peuvent aussi être confinés au besoin ; les adresses IP servent uniquement à la corrélation. Envoyez autant d’actifs que la détection en concerne — jusqu’à 50 de chaque type par requête. N’envoyez que les champs que vous connaissez : chaque actif utilisateur, terminal ou fichier doit avoir au moins un de ses champs, et chaque actif IP doit avoir `address`. | Actif | Champs | | - | - | | `assets.users[]` | `id` (votre identifiant unique d’utilisateur), `email`, `username` | | `assets.endpoints[]` | `id` (votre identifiant unique de terminal), `hostname` | | `assets.files[]` | `name`, `path`, `sha256` (64 caractères hexadécimaux), `sha1` (40 caractères hexadécimaux) | | `assets.ips[]` | `address` (obligatoire) : une adresse IPv4 ou IPv6, par exemple `203.0.113.7` ou `2001:db8::1` | Les empreintes sont insensibles à la casse et sont stockées en minuscules. Une empreinte de mauvaise longueur ou contenant des caractères non hexadécimaux fait échouer la requête. Envoyez chaque adresse IP seule. Un port (`203.0.113.7:443`), une plage CIDR (`10.0.0.0/8`) ou un nom d’hôte fait échouer la requête ; envoyez plutôt les noms d’hôte comme terminaux. Les adresses IPv6 sont stockées en minuscules. ### Catégories Choisissez la catégorie qui décrit le mieux la détection. La liste est volontairement courte ; pour une détection suspecte, envoyez la catégorie la plus proche. Utilisez `OTHER__INFORMATIONAL_EVENT` uniquement pour une activité qui ne nécessite aucune intervention, car Wirespeed clôture automatiquement ces détections comme bénignes. Les valeurs de catégorie utilisent le format standard des catégories Wirespeed : des segments en majuscules joints par des **doubles traits de soulignement**. Par exemple, `IDENTITY__LOGIN` comporte deux traits de soulignement entre `IDENTITY` et `LOGIN` — `IDENTITY_LOGIN` et `IDENTITY-LOGIN` ne sont pas acceptés. | Catégorie | À utiliser pour | | - | - | | `IDENTITY__LOGIN` | Connexions suspectes ou anormales | | `ENDPOINT__EXECUTION` | Programmes, commandes ou logiciels malveillants suspects exécutés sur un terminal | | `CLOUD__INVOCATION` | Appels d’API cloud suspects | | `NETWORK__INBOUND_CONNECTION` | Connexions réseau entrantes suspectes | | `NETWORK__OUTBOUND_CONNECTION` | Connexions réseau sortantes suspectes | | `DATA__DATA_TRANSFER` | Mouvement de données inhabituel ou exfiltration | | `OTHER__INFORMATIONAL_EVENT` | Activité informative ne nécessitant aucune intervention ; clôturée automatiquement comme bénigne | ## Exemples de charges utiles ### Logiciel malveillant sur terminal avec un actif fichier ```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" } ] } } ``` ### Connexion réseau avec des actifs adresse IP ```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" }] } } ``` ### Charge utile minimale Uniquement les champs requis. Wirespeed peut trier cette détection, mais l’ajout d’un `id` et d’identifiants d’actifs améliore la déduplication et la corrélation. ```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" }] } } ``` ## Erreurs et cas limites Les livraisons rejetées ne sont jamais mises en file d’attente. Lorsqu’une livraison échoue à la validation, la raison est inscrite dans le journal de l’intégration dans Wirespeed pour que vous puissiez corriger l’émetteur ; vérifiez-y d’abord lorsque des détections n’apparaissent pas. | Statut | Signification | Quoi faire | | - | - | - | | `400` | Charge utile malformée ou invalide : champ requis manquant, champ inconnu, `category` ou `severity` invalide, horodatages illisibles ou dans le désordre, actif sans identifiants, ou courriel, URL, empreinte ou adresse IP malformés. | Corrigez le champ nommé dans l’entrée du journal de l’intégration et renvoyez. | | `401` | L’authentification est activée et l’en-tête `X-Webhook-Key` est absent ou ne correspond pas. | Envoyez le secret de webhook actuel. Si vous l’avez régénéré, mettez à jour l’émetteur. | | `404` | Le `teamId` ou l’`integrationId` dans l’URL n’identifie aucune intégration. | Copiez de nouveau l’URL du webhook depuis **Détails du webhook**. | | `422` | Le traitement des webhooks est temporairement en pause. | Réessayez avec un délai croissant. | | `429` | Votre équipe a dépassé la limite de débit des webhooks (3 000 requêtes/minute). | Réessayez avec un délai croissant ; les émetteurs par lots devraient étaler leurs livraisons. | Cas limites à connaître : * **Une détection par requête.** Envoyez un tableau et la requête échoue à la validation ; bouclez plutôt sur les détections. * **Les nouvelles tentatives sont sûres avec un `id`.** Le même `id` livré deux fois devient une seule détection. Sans `id`, une nouvelle tentative peut créer un doublon. * **Les horodatages futurs** sont ramenés à l’heure d’ingestion pour l’heure d’événement de la détection ; les horodatages que vous avez envoyés sont conservés sur la ligne SIEM. * **Les intégrations désactivées** rejettent les livraisons jusqu’à leur réactivation. * **Les secrets dans les URL sont ignorés.** Un paramètre de requête `webhookSecret` n’authentifie pas une requête ; utilisez l’en-tête `X-Webhook-Key`. ## Ce que Wirespeed en fait Chaque livraison acceptée devient une détection Wirespeed à part entière, comme une détection issue de n’importe quelle intégration native, et elle est triée automatiquement : Wirespeed l’analyse, rend un verdict, puis escalade ou intervient selon les paramètres d’automatisation de votre équipe, sans aucune étape manuelle. Les utilisateurs, terminaux et fichiers que vous envoyez sont extraits pour la corrélation et le confinement, les adresses IP pour la corrélation, la détection est classée avec la `category` que vous avez envoyée, et la charge utile normalisée est écrite dans la table SIEM `generic_detection_logs`. Dans le SIEM, vous pouvez filtrer cette table par `severity`, `category` et `source` ; les lignes sont stockées triées par équipe, puis par `source`, puis par heure, de sorte que les requêtes filtrées par source restent rapides. Chaque intégration Generic Detection apparaît aussi comme sa propre source SIEM sous son **Nom de source**, de sorte que les livraisons de différents systèmes émetteurs restent séparées même si elles partagent une seule table. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.