Configurer un webhook SOAR

Compatible avec :

Les webhooks sont une solution légère pour ingérer les alertes de votre organisation dans la plate-forme Google Security Operations SOAR.

Les alertes ingérées par webhook s'affichent sur la plate-forme avec les mêmes informations que celles ingérées à l'aide de connecteurs.

Pour éviter de créer des demandes en double, Google vous recommande d'utiliser un connecteur ou un webhook provenant de la même source, mais pas les deux.

Les Webhooks sont plus adaptés aux scénarios qui nécessitent une logique de mappage de base, tandis que les connecteurs sont plus adaptés au mappage avancé et flexible.

Configurer un webhook pour ingérer des alertes

Pour configurer un webhook permettant d'ingérer des alertes, procédez comme suit :

  1. Accédez à Paramètres SOAR> Ingestion> Webhooks.
  2. Cliquez sur Ajouter Ajouter un webhook entrant.
  3. Attribuez un nom au nouveau webhook et choisissez un environnement.
  4. Cliquez sur Enregistrer. Une fois enregistré, le nouveau webhook apparaît sur la page principale.
  5. Copiez l'URL du webhook et notez-la pour une utilisation ultérieure. Vous devez la saisir dans la plate-forme source en tant que destination du webhook.

Mapper les données

Une fois que vous avez importé un exemple JSON, vous pouvez utiliser la section Mappage des données pour mapper les champs de votre fichier JSON source avec les champs appropriés dans Google Security Operations SOAR. Le système traite votre fichier JSON brut, et vous utilisez l'interface utilisateur pour établir les mappages.

  1. Dans la section Mappage des données, cliquez sur Importer un exemple JSON. Fournissez un échantillon représentatif de la charge utile JSON envoyée par votre webhook.
  2. Mappez les champs Google Security Operations avec les champs correspondants de votre exemple JSON. Par exemple, pour mapper le champ obligatoire StartTime, vous pouvez sélectionner un champ d'horodatage de votre fichier JSON, tel que Detections.Last.Update.
  3. Utilisez le générateur d'expressions pour affiner les données. Par exemple, vous pouvez utiliser la fonction Format de date pour convertir votre code temporel au format d'epoch Unix en millisecondes requis. Pour en savoir plus, consultez Utiliser le générateur d'expressions.
  4. Cliquez sur Exécuter dans le générateur d'expressions pour tester le mappage et afficher le résultat. Une coche verte indique que le mappage a réussi.
  5. La charge utile JSON de votre webhook doit contenir les champs requis pour la création de demandes et l'ingestion d'alertes. Pour en savoir plus, consultez Comprendre le schéma JSON du webhook.
  6. Une fois que vous avez mappé tous les champs nécessaires, cliquez sur Enregistrer, puis activez le webhook.

Comprendre les champs cibles de mappage

Lorsque vous mappez vos données JSON, vous les mappez à des champs standardisés dans Google Security Operations SOAR. Ces champs sont organisés en catégories pour vous aider à normaliser et à structurer les données entrantes. Les champs disponibles dans l'interface utilisateur de mappage des données sont basés sur l'ontologie du système interne. Voici les principales catégories :

  • Champs d'entité : utilisez ces champs pour les points de données à partir desquels le système peut extraire et modéliser automatiquement des entités, telles que des adresses IP, des noms de domaine, des hachages de fichiers et des noms d'utilisateur. Le mappage à ces champs enrichit l'alerte et améliore la corrélation et le tableau croisé dynamique.
  • Champs d'événement génériques : utilisez-les pour les métadonnées d'événement générales, telles que les codes temporels (StartTime, EndTime), les descriptions ou messages d'événement, et d'autres attributs d'événement courants.
  • Métadonnées techniques et sur l'appareil : utilisez ces champs pour obtenir des informations techniques sur la source de l'événement, comme le fournisseur et le produit de l'appareil concerné (DeviceVendor, DeviceProduct), la gravité de l'événement et d'autres attributs techniques similaires.

Explorez les champs disponibles dans l'outil de mappage des données de l'interface utilisateur SOAR de Google Security Operations pour trouver le champ cible le plus approprié pour chaque élément de données de votre charge utile JSON.

Comprendre le schéma JSON du webhook

Pour vous assurer que vos alertes sont ingérées et traitées correctement par Google Security Operations SOAR, la charge utile JSON de votre webhook doit suivre une structure spécifique. Les tableaux suivants décrivent les principaux champs attendus dans la charge utile JSON.

Principaux champs de cas et d'alertes

Ces champs représentent les propriétés de premier niveau de l'alerte ou de la demande en cours de création.

Champ Type Format recommandé Obligatoire Description Exemple
TicketId Chaîne UUID Oui
  • Identifiant unique global interne (GUID) d'une demande dans la plate-forme SOAR.
  • L'exigence d'unicité de TicketId est conditionnelle et dépend de DisplayId :
    • Si un DisplayId unique est fourni, le TicketId n'a pas besoin d'être unique.
    • Si DisplayId n'est pas fourni, TicketId doit être unique.
  • La valeur de TicketId est souvent identique à celle de DisplayId.
 "f7167971-f641-432f-a06f-ebca3caaa9dd"
SourceSystemName Chaîne Texte Oui Nom du système externe (par exemple, SIEM ou un système de détection et de réponse au niveau des points de terminaison (EDR)) qui a envoyé les alertes d'origine à SOAR. "Splunk"
Name Chaîne Texte Oui Titre ou nom de la demande, souvent tiré du type d'alerte ou du résumé de la source. "Suspicious Login Attempt"
DeviceVendor Chaîne Texte Oui Fournisseur de l'appareil ou du produit ayant généré l'alerte. Vous pouvez également mapper cette valeur à partir des données d'événement. "Palo Alto Networks"
RuleGenerator Chaîne Texte Oui Nom de la règle dans le système source (par exemple, une règle de corrélation SIEM) qui a généré l'alerte. "Brute Force Attempt Detected"
StartTime Chaîne ou entier Millisecondes depuis l'epoch (UTC) ou chaîne ISO8601 (par exemple, "2026-04-09T14:30:00Z") Oui Heure de début de l'événement le plus ancien de la demande. Si vous fournissez un entier, il doit être exprimé en millisecondes epoch Unix. 1670000000000 ou "2026-04-09T14:30:00Z"
Environment Chaîne Texte Non Nom de l'environnement SOAR auquel appartient cette alerte. Il doit correspondre à un environnement défini dans vos paramètres SOAR. "Default Environment"
Description Chaîne Texte Non Brève description de la demande ou de l'alerte. "Failed login followed by success from new IP"
DisplayId Chaîne UUID ou chaîne Non
  • Identifiant utilisé à des fins d'affichage dans l'UI SOAR.
  • Ce champ est la clé primaire que le système vérifie pour détecter les alertes en double.
  • Une alerte est rejetée comme doublon si le DisplayId n'est pas unique. Cette vérification de l'unicité sur DisplayId est prioritaire sur TicketId.
  • La valeur de DisplayId est souvent identique à celle de TicketId.
 "f7167971-f641-432f-a06f-ebca3caaa9dd"
Reason Chaîne Texte Non Motif de la création ou du déclenchement de l'alerte. "Unusual file access patterns detected."
DeviceProduct Chaîne Texte Non Nom du produit du fournisseur qui a généré l'alerte. Il peut également être mappé à partir des données d'événement. "Cortex XDR"
EndTime Chaîne ou entier Millisecondes depuis l'epoch (UTC) ou chaîne ISO8601 (par exemple, "2026-04-09T14:30:00Z") Non Heure de fin du dernier événement de la demande. Si vous fournissez un entier, il doit être exprimé en millisecondes (epoch Unix). 1670000060000 ou "2026-04-09T14:31:00Z"
Priority Integer 0–100 Non Niveau de priorité de la demande. Si aucune valeur n'est indiquée, cet attribut est défini par défaut sur 40. (0-19 : informatif, 20-39 : faible, 40-59 : moyen, 60-79 : élevé, 80-100 : critique) 80
EventsList Tableau Tableau d'objets JSON Non Tableau contenant un ou plusieurs objets d'événement bruts tels qu'ils ont été reçus de la source. Consultez Envoyer des données d'événement brutes. [ { ... }, { ... } ]
EventProduct Chaîne Texte Non Produit ayant créé les événements. "Cortex XDR"
EventName Chaîne Texte Non Titre ou nom de l'événement, souvent tiré du type ou du résumé de l'alerte source. "Suspicious Login Attempt"

Envoyer des données d'événement brutes : le tableau EventsList

Vous devez envoyer la charge utile JSON brute représentant les événements tels qu'ils proviennent du système source dans le tableau EventsList. Cet objet est un élément du tableau EventsList. Vous mappez ensuite des champs tels que source_ip et timestamp à l'aide de l'interface utilisateur de mappage des données.

Exemple d'objet d'événement dans le tableau EventsList

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

Points clés à prendre en compte et bonnes pratiques

  • Codes temporels : utilisez des millisecondes d'epoch Unix pour tous les champs StartTime et EndTime au niveau supérieur (sous forme d'entier). Dans les données d'événement, fournissez les codes temporels tels qu'ils proviennent de la source. Vous les convertirez dans l'UI de mappage des données.
  • Champs obligatoires : assurez-vous que tous les champs marqués "Oui" dans la colonne "Obligatoire" sont présents dans votre charge utile JSON.
  • EventsList array : ce tableau est essentiel. Même si l'alerte ne représente qu'un seul événement, elle doit être encapsulée dans le tableau EventsList.
  • Interface utilisateur de mappage des données : utilisez l'outil de mappage des données dans l'interface utilisateur de configuration des webhooks pour mapper les champs de votre fichier JSON brut aux champs Google Security Operations SOAR appropriés.
  • Unicité : DisplayId doit être unique pour chaque nouvelle alerte afin d'éviter la déduplication. TicketId doit être unique si DisplayId n'est pas fourni.
  • État de la réponse : une réponse HTTP 200 OK du point de terminaison Webhooks Ingest confirme que la charge utile a été reçue, mais ne garantit pas qu'une alerte sera créée. La création d'alertes peut échouer lors du traitement en aval en raison de la structure de la charge utile ou des règles de filtrage. Vous pouvez suivre l'état du traitement en aval à l'aide de la fonctionnalité Collect SOAR platform logs (Collecter les journaux de la plate-forme SOAR).
  • Test : utilisez les onglets Importer un exemple JSON et Test sur la page Configuration du webhook dans SOAR pour valider la structure et les mappages de votre charge utile.

Tester le webhook

Dans l'onglet Tests, vous pouvez tester la fonctionnalité de bout en bout du webhook et afficher des descriptions détaillées des erreurs.

  1. Dans l'onglet Test, copiez l'URL de webhook.
  2. Importez un fichier JSON contenant les données pertinentes.
  3. Cliquez sur Exécuter. Les résultats s'affichent avec la sortie.

Configurer la plate-forme CrowdStrike

Ce cas d'utilisation vous guide à travers les étapes à suivre dans CrowdStrike pour que le webhook commence à ingérer les alertes dans la plate-forme Google SecOps.

  1. Dans le tableau de bord CrowdStrike Falcon, accédez au Falcon Store et installez le module complémentaire Webhooks.
  2. Configurez le webhook avec le nom et l'URL de webhook que vous avez copiés depuis la plate-forme Google SecOps, puis cliquez sur Save (Enregistrer).
  3. Accédez à la section Workflows.
  4. Cliquez sur Créer un workflow.
  5. Sélectionnez un déclencheur, tel que Nouvelle détection, puis cliquez sur Suivant.
  6. Sélectionnez Ajouter une action.
  7. Dans la section Personnaliser l'action, sélectionnez Notifications dans le menu Type d'action, puis Appeler un webhook dans le menu Action.
  8. Sélectionnez le nom que vous avez ajouté à l'étape initiale et tous les champs nécessaires, puis cliquez sur Terminer.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.