Utilisation de déclencheurs et d’actions dans les playbooks Microsoft Sentinel

Article
03/14/2024
S’applique à:

Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Ce document explique les types de déclencheurs et d’actions du connecteur Logic Apps Microsoft Sentinel que les playbooks peuvent utiliser pour interagir avec Microsoft Sentinel et les informations contenues dans les tables de votre espace de travail. Il vous montre également comment accéder à des types spécifiques d’informations Azure Sentinel dont vous aurez probablement besoin.

Ce document, de même que notre guide Authentification des playbooks dans Microsoft Sentinel, vient compléter notre autre documentation sur les playbooks, Tutoriel : Utilisation des playbooks avec des règles d’automatisation dans Microsoft Sentinel. Ces trois documents font référence les uns aux autres.

Pour obtenir une présentation des playbooks, consultez Automatiser la réponse aux menaces à l’aide de playbooks dans Microsoft Sentinel.

Pour connaître la spécification complète du connecteur Microsoft Sentinel, consultez la documentation du connecteur Logic Apps.

Important

Microsoft Sentinel est disponible dans le cadre de la préversion publique de la plateforme d’opérations de sécurité unifiée dans le portail Microsoft Defender. Pour en savoir plus, consultez Microsoft Sentinel dans le portail Microsoft Defender.

Autorisations requises

Rôles/Composants du connecteur	Déclencheurs	Actions « Get »	Mettre à jour l’incident, ajouter un commentaire
Lecteur Microsoft Sentinel	✓	✓	✗
Répondeur/Contributeur Microsoft Sentinel	✓	✓	✓

En savoir plus sur les autorisations dans Microsoft Sentinel.

Résumé déclencheurs Microsoft Sentinel

Bien que le connecteur Microsoft Sentinel soit utilisable de différentes manières, ses composants peuvent être divisés en trois flux, chacun déclenché par une occurrence Microsoft Sentinel distincte :

Déclencheur (nom complet dans le concepteur Logic Apps)	Quand utiliser cette fonctionnalité ?	Limitations connues
Incident Microsoft Sentinel (préversion)	Recommandé pour la plupart des scénarios d’automatisation des incidents. Le playbook reçoit les objets Incident, notamment les entités et les alertes. Ce déclencheur permet d’associer le playbook à une règle d’automatisation. Il peut donc être mis en œuvre lorsqu’un incident est créé (et maintenant également mis à jour) dans Microsoft Sentinel. Tous les avantages des règles d’automatisation s’appliquent alors à l’incident.	Les playbooks qui comportent ce déclencheur ne prennent pas en charge le regroupement d’alertes. Ils ne reçoivent donc que la première alerte envoyée avec chaque incident. MISE À JOUR : depuis février 2023, le regroupement d’alertes est pris en charge pour ce déclencheur.
Alerte Microsoft Sentinel (préversion)	Recommandé pour les playbooks qui doivent être exécutés manuellement sur les alertes à partir du portail Microsoft Sentinel et pour les règles d’analytique planifiées qui ne génèrent pas d’incidents pour leurs alertes.	Ce déclencheur ne peut pas être utilisé pour automatiser les réponses dans le cas des alertes générées par les règles d’analytique de sécurité Microsoft. Les playbooks qui utilisent ce déclencheur ne peuvent pas être appelées par des règles d’automatisation.
Entité Microsoft Sentinel (préversion)	À utiliser pour les playbooks qui doivent être exécutés manuellement sur des entités spécifiques à partir d’un contexte d’investigation ou de chasse aux menaces.	Les playbooks qui utilisent ce déclencheur ne peuvent pas être appelées par des règles d’automatisation.

Les schémas utilisés par ces flux ne sont pas identiques. La pratique recommandée consiste à utiliser le flux déclenchement d’incident Microsoft Sentinel, qui s’applique à la plupart des scénarios.

Champs dynamiques des incidents

L’objet Incident reçu de l’incident Microsoft Sentinel comprend les champs dynamiques suivants :

Propriétés de l’incident (indiquées sous la forme « Incident : nom du champ »)
Alertes (tableau)
- Propriétés de l’alerte (indiquées sous la forme « Alerte : nom du champ »)
  
  Quand vous sélectionnez une propriété d’alerte telle que Alerte : <nom de la propriété>, une boucle for each est générée automatiquement, car un incident peut inclure plusieurs alertes.
Entités (tableau de toutes les entités d’une alerte)
Champs d’informations sur l’espace de travail (s’applique à l’espace de travail Sentinel dans lequel l’incident a été créé)
- Identifiant d’abonnement
- Nom de l’espace de travail
- ID de l’espace de travail
- Nom de groupe ressources

Résumé des actions Microsoft Sentinel

Composant	Quand utiliser cette fonctionnalité ?
Alerte – Obtenir l’incident	Dans les playbooks qui commencent par le déclencheur d’alerte. Utile pour obtenir les propriétés de l’incident ou pour récupérer l’ID ARM de l’incident à utiliser avec les actions Mettre à jour l’incident et Ajouter un commentaire à l’incident.
Obtenir l'incident	Pour déclencher un playbook à partir d’une source externe ou d’un déclencheur autre que Sentinel. Identifié par un ID ARM de l’incident. Récupère les propriétés et les commentaires de l’incident.
Mettre à jour l'incident	Pour modifier l’État d’un incident (par exemple lors de la fermeture de l’incident), attribuer un Propriétaire, ajouter ou supprimer une balise, ou modifier sa Gravité, son Titre ou sa Description.
Ajouter des commentaires à l’incident	Pour enrichir l’incident avec les informations collectées à partir de sources externes, auditer les actions effectuées par le playbook sur les entités, fournir des informations supplémentaires utiles pour l’examen des incidents.
*Entités – Obtenir <type d’entité>*	Dans les playbooks qui fonctionnent sur un type d’entité spécifique (Adresse IP, Compte, Hôte, URL ou Hachage de fichier), connu au moment de la création du playbook. Vous devez être en mesure de l’analyser et de travailler sur ses champs uniques.

Exemples d’utilisation des incidents

Conseil

Les actions Mettre à jour l’incident et Ajouter un commentaire à l’incident exigent l’ID ARM de l’incident.

Utilisez au préalable l’action Alerte – Obtenir l’incident pour obtenir l’ID ARM de l’incident.

Mise à jour d’un incident

Le playbook est déclenché par l’incident Microsoft Sentinel
Le playbook est déclenché par l’alerte Microsoft Sentinel

Utilisation des informations sur l’incident

Voici le playbook de base pour envoyer les détails de l’incident par e-mail :

Le playbook est déclenché par l’incident Microsoft Sentinel
Le playbook est déclenché par l’alerte Microsoft Sentinel

Ajout d’un commentaire à l’incident

Le playbook est déclenché par l’incident Microsoft Sentinel
Le playbook est déclenché par l’alerte Microsoft Sentinel

Désactiver un utilisateur

Le playbook est déclenché par l’Entité Microsoft Sentinel

Playbooks d’entité sans ID d’incident

Les playbooks créés avec le Déclencheur d’entité utilisent souvent le champ ID ARM de l’incident (par exemple, pour mettre à jour un incident après avoir pris des mesures sur l’entité).

Si un tel playbook est déclenché dans un contexte non connecté à un incident (par exemple, lors de la chasse aux menaces), il n’existe aucun incident dont l’ID peut remplir ce champ. Dans ce cas, le champ est rempli avec une valeur null.

Par conséquent, le playbook peut ne pas s’exécuter jusqu’à la fin. Pour éviter cet échec, il est recommandé de créer une condition qui recherche une valeur dans le champ ID d’incident avant d’effectuer des actions dessus, et de prescrire un autre ensemble d’actions si le champ a une valeur null, c’est-à-dire si le playbook n’est pas exécuté à partir d’un incident.

Avant la première action qui fait référence au champ ID ARM de l’incident, ajoutez une étape de type Condition.
Sélectionnez le champ Choisir une valeur et ouvrez la boîte de dialogue Ajouter du contenu dynamique.
Sélectionnez l’onglet Expression et la fonction length(collection).
Sélectionnez l’onglet Contenu dynamique et le champ ID ARM de l’incident.
Vérifiez que l’expression résultante est length(triggerBody()?['IncidentArmID']), puis sélectionnez OK.
Définissez l’opérateur et la valeur dans la condition sur « est supérieur à » et « 0 ».
Dans le cadre True, ajoutez les actions à effectuer si le playbook est exécuté à partir d’un contexte d’incident.

Dans le cadre False, ajoutez les actions à effectuer si le playbook est exécuté à partir d’un contexte hors incident.

Utilisation de types d’entités spécifiques

Le champ dynamique Entités consiste en un tableau d’objets JSON, chacun représentant une entité. Chaque type d’entité possède son propre schéma, en fonction de ses propriétés uniques.

L’action « Entités – Obtenir <type d’entité> » vous permet d’effectuer les opérations suivantes :

Filtrez le tableau d’entités selon le type demandé.
Analysez les champs spécifiques de ce type pour qu’ils puissent être utilisés comme champs dynamiques dans d’autres actions.

L’entrée correspond au champ dynamique Entités.

La réponse est un tableau d’entités, dans lequel les propriétés spéciales sont analysées et peuvent être utilisées directement dans une boucle For each.

Les types d’entités pris en charge à l’heure actuelle sont les suivants :

Pour les autres types d’entités, des fonctionnalités similaires peuvent être obtenues avec les actions intégrées Logic Apps :

Filtrez le tableau d’entités selon le type demandé avec Filtrer le tableau.
Analysez les champs spécifiques de ce type pour qu’ils puissent être utilisés comme champs dynamiques dans d’autres actions avec Analyser le code JSON.

Utilisation de détails personnalisés

Le champ dynamique Détails personnalisés des alertes, disponible dans le déclencheur d’incident, consiste en un tableau d’objets JSON, chacun représentant l’un des détails personnalisés d’une alerte. Pour rappel, les Détails personnalisés sont des paires clé-valeur qui permettent d’afficher des informations provenant d’événements dans l’alerte, pour qu’ils puissent être représentés, suivis et analysés dans le cadre de l’incident.

Étant donné que ce champ est personnalisable dans l’alerte, son schéma dépend du type d’événement mis en évidence. Vous devez fournir des données issues d’une instance de cet événement pour générer le schéma qui déterminera la façon dont le champ de détails personnalisés sera analysé.

Voir l’exemple suivant :

Détails personnalisés définis dans la règle d’analytique.

Dans ces paires clé-valeur, la clé (colonne de gauche) représente les champs personnalisés que vous créez, et la valeur (colonne de droite) les champs des données d’événement qui alimentent les champs personnalisés.

Vous pouvez fournir le code JSON suivant pour générer le schéma. Ce code présente les noms de clés sous forme de tableaux, et les valeurs (qui apparaissent comme les valeurs réelles, et non la colonne les contenant) comme éléments des tableaux.

{ "FirstCustomField": [ "1", "2" ], "SecondCustomField": [ "a", "b" ] }

Ajoutez une nouvelle étape avec l’action intégrée Analyser le code JSON. Vous pouvez entrer « analyser JSON » dans le champ de recherche pour la trouver.
Recherchez et sélectionnez Détails personnalisés des alertes dans la liste Contenu dynamique, sous le déclencheur d’incident.

Une boucle For each est créée, car un incident contient un tableau d’alertes.
Sélectionnez le lien Utiliser l’exemple de charge utile pour générer le schéma.
Indiquez un exemple de charge utile. Pour trouver un exemple de charge utile, recherchez dans Log Analytics une autre instance de cette alerte et copiez l’objet de détails personnalisés (sous Propriétés étendues). Accédez aux données Log Analytics dans la page Journaux d’activité du Portail Azure ou dans la page Repérage avancé du portail Defender. Dans la capture d’écran ci-dessous, nous avons utilisé le code JSON indiqué plus haut.
Les champs personnalisés sont prêts à être utilisés comme champs dynamiques de type Tableau. Le tableau et ses éléments figurent à la fois dans le schéma et dans la liste qui apparaît sous Contenu dynamique (cf. ci-dessus).