Nous avons réorganisé la structure de navigation de notre documentation pour l'aligner directement sur vos workflows opérationnels. Pour en savoir plus, consultez les notes de version et la vidéo de présentation.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Configurer un webhook SOAR

Compatible avec :

Google secops SOAR

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

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

Pour éviter de créer des cas en double, Google vous recommande d'utiliser un connecteur ou un webhook 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 afin d'ingérer des alertes, procédez comme suit :

Accédez à SOAR Settings > Ingestion > Webhooks (Paramètres SOAR > Ingestion > Webhooks).
Cliquez sur add Add incoming webhook (Ajouter un webhook entrant).
Saisissez un nom pour le nouveau webhook, puis choisissez un environnement.
Cliquez sur Save (Enregistrer). Une fois enregistré, le nouveau webhook s'affiche sur la page principale.
Copiez l'URL du webhook et notez-la pour une utilisation ultérieure. Vous devez la saisir dans la plate-forme source comme destination du webhook.

Mapper des données

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

Dans la section Data mapping (Mappage des données), cliquez sur Upload JSON sample (Importer un exemple JSON). Fournissez un exemple représentatif de la charge utile JSON que votre webhook envoie.
Mappez les champs Google Security Operations avec les champs correspondants dans votre exemple JSON. Par exemple, pour mapper le champ obligatoire StartTime, vous pouvez sélectionner un champ d'horodatage de votre JSON, tel que Detections.Last.Update.
Utilisez le générateur d'expressions pour affiner les données. Par exemple, vous pouvez utiliser la fonction Date format (Format de date) pour convertir votre horodatage au format Unix epoch milliseconds requis. Pour en savoir plus, consultez Utiliser le générateur d'expressions.
Cliquez sur Run (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.
Votre charge utile JSON de webhook doit contenir les champs requis pour la création de cas et l'ingestion d'alertes. Pour en savoir plus, consultez Comprendre le schéma JSON du webhook.
Une fois que vous avez mappé tous les champs nécessaires, cliquez sur Save (Enregistrer), puis activez le webhook.

Comprendre les champs cibles du mappage

Lorsque vous mappez vos données JSON, vous les mappez vers 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 interne du système. Les principales catégories sont les suivantes :

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 vers ces champs enrichit l'alerte et améliore la corrélation et le pivot.
Champs d'événement génériques : utilisez-les pour les métadonnées d'événement générales, telles que les horodatages (StartTime, EndTime), les descriptions ou messages d'événement, et d'autres attributs d'événement courants.
Métadonnées techniques et d'appareil : utilisez ces champs pour obtenir des informations techniques sur la source de l'événement, telles que le fournisseur et le produit de l'appareil de signalement (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 Google Security Operations SOAR 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, votre charge utile JSON de 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'alerte

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

Champ	Type	Format recommandé	Obligatoire	Description	Exemple
`TicketId`	Chaîne	UUID	Oui	Identifiant global unique (GUID) interne pour un cas 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, le `TicketId` doit être unique. Le `TicketId` a souvent la même valeur que le `DisplayId`.	`"f7167971-f641-432f-a06f-ebca3caaa9dd"`
`SourceSystemName`	Chaîne	Texte	Oui	Nom du système externe (par exemple, SIEM ou système de détection et de réponse sur les terminaux (EDR)) qui a envoyé les alertes d'origine à SOAR.	`"Splunk"`
`Name`	Chaîne	Texte	Oui	Titre ou nom du cas, souvent tiré du type ou du résumé de l'alerte source.	`"Suspicious Login Attempt"`
`DeviceVendor`	Chaîne	Texte	Oui	Fournisseur de l'appareil ou du produit qui a généré l'alerte. Ce champ peut également être mappé à 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	Epoch milliseconds (UTC) ou chaîne ISO8601 (par exemple, "2026-04-09T14:30:00Z")	Oui	Heure de début de l'événement le plus ancien du cas. Si vous fournissez un entier, il doit être au format Unix epoch milliseconds.	`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 du cas 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'interface utilisateur 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 d'unicité sur `DisplayId` est prioritaire par rapport à `TicketId`. Le `DisplayId` a souvent la même valeur que le `TicketId`.	`"f7167971-f641-432f-a06f-ebca3caaa9dd"`
`Reason`	Chaîne	Texte	Non	Raison pour laquelle l'alerte a été créée ou déclenchée.	`"Unusual file access patterns detected."`
`DeviceProduct`	Chaîne	Texte	Non	Nom du produit du fournisseur qui a généré l'alerte. Ce champ peut également être mappé à partir des données d'événement.	`"Cortex XDR"`
`EndTime`	Chaîne ou entier	Epoch milliseconds (UTC) ou chaîne ISO8601 (par exemple, "2026-04-09T14:30:00Z")	Non	Heure de fin de l'événement le plus récent du cas. Si vous fournissez un entier, il doit être au format Unix epoch milliseconds.	`1670000060000` ou `"2026-04-09T14:31:00Z"`
`Priority`	Integer	0–100	Non	Niveau de priorité du cas. La valeur par défaut est 40 si elle n'est pas fournie. (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 sont reçus de la source. Consultez Envoyer des données d'événement brutes.	`[ { ... }, { ... } ]`
`EventProduct`	Chaîne	Texte	Non	Produit qui a 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 et bonnes pratiques

Horodatages : utilisez Unix epoch milliseconds pour tous les champs StartTime et EndTime de premier niveau (sous forme d'entier). Dans les données d'événement, fournissez les horodatages tels qu'ils proviennent de la source. Vous les convertissez dans l'interface utilisateur 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.
Tableau EventsList : ce tableau est essentiel. Même si l'alerte représente 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 Webhook configuration (Configuration du webhook) pour mapper les champs de votre JSON brut vers les 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.
Tests : utilisez les onglets Upload JSON sample (Importer un exemple JSON) et Testing (Tests) de la page Webhook configuration (Configuration du webhook) dans SOAR pour valider la structure et les mappages de votre charge utile.

Remarque concernant l'affichage de l'horodatage de l'événement : lorsque vous ingérez des données d'événement à l'aide de webhooks, l'affichage des champs d'horodatage dans la liste des détails de l'alerte peut varier. La plate-forme tente de mettre en forme les champs qui semblent être liés à l'heure, en supposant que la valeur est fournie en epoch milliseconds. Si un champ d'horodatage (souvent celui contenant "time" dans son nom, tel que `@timestamp`) est envoyé dans un format autre que epoch milliseconds (par exemple, `MM/DD/YYYY HH:MM:SS` ou `YYYY-MM-DDTHH:MM:SSz`), la vue de liste peut ne pas afficher l'heure comme prévu. En effet, le système tente de l'interpréter comme des millisecondes depuis l'epoch. Vous pouvez afficher la valeur brute d'origine telle qu'elle est envoyée dans le webhook en double-cliquant sur le champ d'horodatage dans la liste des événements. Pour obtenir des résultats d'affichage plus cohérents sur l'ensemble de la plate-forme, configurez le système source pour qu'il envoie des valeurs temporelles en epoch milliseconds dans la mesure du possible, ou assurez-vous que la conversion est correcte dans l'interface utilisateur de mappage des données.

Tester le webhook

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

Dans l'onglet Testing (Tests), copiez l'URL du webhook.
Importez un fichier JSON contenant les données pertinentes.
Cliquez sur Run (Exécuter). Les résultats s'affichent avec la sortie.

Configurer la plate-forme CrowdStrike

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

Dans le tableau de bord CrowdStrike Falcon, accédez au Falcon Store et installez le module complémentaire Webhooks.
Configurez le webhook avec le nom et l'URL du webhook que vous avez copiés à partir de la plate-forme Google SecOps, puis cliquez sur Save (Enregistrer).
Accédez à la section Workflows (Workflows).
Cliquez sur Create a workflow (Créer un workflow).
Sélectionnez un déclencheur, tel que New detection (Nouvelle détection), puis cliquez sur Next (Suivant).
Sélectionnez Add action (Ajouter une action).
Dans la section Customize action (Personnaliser l'action), sélectionnez Notifications dans le menu Action type (Type d'action), puis sélectionnez Call webhook (Appeler le webhook) dans le menu Action.
Sélectionnez le nom que vous avez ajouté à l'étape initiale et tous les champs nécessaires, puis cliquez sur Finish (Terminer).

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