Automatiser la gestion des menaces dans Microsoft Sentinel avec des règles d’automatisation

Cet article explique les règles d’automatisation de Microsoft Sentinel et la manière de les utiliser pour implémenter vos opérations d’orchestration, d’automatisation et de réponse en matière de sécurité (Security Orchestration, Automation and Response, SOAR). Les règles d’automatisation augmentent l’efficacité de votre SOC et vous permettent de gagner du temps et des ressources.

Que sont les règles d’automatisation ?

Les règles d’automatisation sont un moyen de gérer de manière centralisée l’automatisation dans Microsoft Sentinel, en vous permettant de définir et de coordonner un petit ensemble de règles pouvant s’appliquer dans différents scénarios.

Les règles d’automatisation s’appliquent aux catégories suivantes de cas d’usage :

• Effectuez des tâches d’automatisation de base pour la gestion des incidents sans utiliser de playbooks. Par exemple :

  • Ajoutez des tâches d’incident que les analystes doivent suivre.
  • Supprimer les incidents bruyants.
  • Trier les nouveaux incidents en modifiant leur état de Nouveau à Actif et en attribuant un propriétaire.
  • Baliser les incidents pour les classifier.
  • Escalader un incident en attribuant un nouveau propriétaire.
  • Fermer les incidents résolus, en spécifiant un motif et en ajoutant des commentaires.

• Automatiser les réponses pour plusieurs règles d’analyse à la fois.

• Contrôler l’ordre des actions exécutées.

• Inspecter le contenu de l’incident (alertes, entités et autres propriétés) et effectuer des actions supplémentaires en appelant un playbook.

• Les règles d’automatisation peuvent également être le mécanisme par lequel vous exécutez un playbook en réponse à une alerte qui n’est pas associée à un incident.

En bref, les règles d'automatisation rationalisent l'utilisation de l'automatisation dans Microsoft Sentinel, vous permettant de simplifier les flux de travail complexes pour vos processus d'orchestration de la réponse aux menaces.

Composants

Les règles d’automatisation sont constituées de plusieurs composants :

• Des déclencheurs qui définissent le type d’événement d’incident qui entraîne l’exécution de la règle, sous réserve de conditions.
• Des conditions qui déterminent les circonstances exactes dans lesquelles la règle s’exécutera et effectuera des actions.
• Des actions pour modifier l’incident d’une certaine façon ou appeler un playbook, qui effectue des actions plus complexes et interagit avec d’autres services.

Déclencheurs

Les règles d’automatisation sont déclenchées quand un incident est créé ou mis à jour, ou quand une alerte est créée. Rappelons que les incidents incluent des alertes, et que les alertes et les incidents peuvent être créés par des règles analytiques comme expliqué dans Détection des menaces dans Microsoft Sentinel.

Le tableau suivant présente les différents scénarios possibles qui entraînent l’exécution d’une règle d’automatisation.

Automatisation basée sur les incidents ou basée sur des alertes ?

Avec les règles d’automatisation qui gèrent de manière centralisée la réponse aux incidents et aux alertes, comment devez-vous choisir la solution à automatiser et dans quelles circonstances ?

Pour la plupart des cas d’usage, l’automatisation déclenchée par incident est l’approche préférable. Dans Microsoft Sentinel, un incident est un « fichier de cas » : agrégation de toutes les preuves pertinentes pour une enquête spécifique. Il s’agit d’un conteneur pour les alertes, les entités, les commentaires, la collaboration et d’autres artefacts. Contrairement aux alertes qui sont des éléments de preuve uniques, les incidents sont modifiables, ont l’état le plus mis à jour et peuvent être enrichis avec des commentaires, des balises et des signets. L’incident vous permet de suivre l’histoire d’attaque qui continue à évoluer avec l’ajout de nouvelles alertes.

Pour ces raisons, il est plus judicieux de créer votre automatisation autour des incidents. La façon la plus appropriée de créer des playbooks consiste donc à les baser sur le déclencheur d’incident Microsoft Sentinel dans Azure Logic Apps.

La principale raison d’utiliser l’automatisation déclenchée par les alertes consiste à répondre aux alertes générées par des règles d’analyse qui ne créent pas d’incidents (autrement dit, où la création d’incident est désactivée sous l’onglet Paramètres d’incident de l’Assistant Règle d’analyse).

Cette raison est particulièrement pertinente lorsque votre espace de travail Microsoft Sentinel est intégré à la plateforme d’opérations de sécurité unifiée. Dans ce scénario, toutes les créations d’incidents se produisent dans Microsoft Defender XDR, et par conséquent, les règles de création d’incident dans Microsoft Sentinel doivent être désactivées.

Même sans être intégré au portail unifié, vous pouvez décider d’utiliser l’automatisation déclenchée par des alertes si vous souhaitez utiliser une autre logique externe pour décider de si (et de quand) créer un incident depuis une alerte, et comment les alertes sont groupées ensemble. Par exemple :

• Un playbook déclenché par une alerte qui n’a pas d’incident associé, peut enrichir l’alerte avec des informations provenant d’autres sources et, en fonction de certaines logiques externes, décider de s’il faut créer un incident ou non.

• Un playbook déclenché par une alerte peut, au lieu de créer un incident, rechercher un incident existant approprié pour ajouter l’alerte. En savoir plus sur l’expansion des incidents.

• Un playbook déclenché par une alerte peut avertir le personnel SOC de l’alerte, afin que l’équipe puisse décider s’il faut ou non créer un incident.

• Un playbook déclenché par une alerte peut envoyer l’alerte à un système de tickets externe pour la création et la gestion des incidents, ce dernier créant un nouveau ticket pour chaque alerte.

Conditions

Vous pouvez définir des ensembles complexes de conditions pour régir le moment où des actions (voir ci-dessous) doivent s’exécuter. Ces conditions incluent l’événement qui déclenche la règle (incident créé ou mis à jour, ou alerte créée), les états ou valeurs des propriétés de l’incident et des propriétés d’entité (pour le déclencheur d'événements uniquement), ainsi que la règle ou les règles d’analyse qui ont généré l’incident ou l’alerte.

Lorsqu’une règle d’automatisation est déclenchée, elle vérifie l’incident de déclenchement par rapport aux conditions définies dans la règle. Les conditions basées sur les propriétés sont évaluées en fonction de l’état actuel de la propriété au moment où l’évaluation a lieu, ou en fonction des changements d’état de la propriété (voir ci-dessous pour plus d’informations). Étant donné qu’un événement de création ou de mise à jour d’incident unique peut déclencher plusieurs règles d’automatisation, l’ordre dans lequel ils s’exécutent (voir ci-dessous) détermine différemment le résultat de l’évaluation des conditions. Les actions définies dans la règle ne s’exécutent que si toutes les conditions sont remplies.

Déclencheur de création d’incident

Pour les règles définies à l’aide du déclencheur Lorsqu’un incident est créé, vous pouvez définir des conditions qui vérifient l’état actuel des valeurs d’une liste de propriétés d’incident donnée, à l’aide d’un ou plusieurs des opérateurs suivants :

• est égale ou n’est pas égale à la valeur définie dans la condition.
• contient ou ne contient pas la valeur définie dans la condition.
• commence par ou ne commence pas par la valeur définie dans la condition.
• se termine par ou ne se termine pas par la valeur définie dans la condition.

Par exemple, si vous définissez le nom de règle Analytique comme Contains == Attaque par force brute contre un PC cloud, une règle analytique avec l’attaque par force brute contre le Portail Azure ne remplit pas la condition. Toutefois, si vous définissez le nom de règle Analytique comme Ne contient pas == Informations d’identification utilisateur, l’attaque par force brute contre un PC cloud et la force brute contre les règles d’analyse du Portail Azure remplissent toutes deux la condition.

Déclencheur de mise à jour d’incident

Les conditions évaluées dans les règles définies à l’aide du déclencheur Lorsqu’un incident est mis à jour incluent toutes celles répertoriées pour le déclencheur de création d’incident. Toutefois, le déclencheur de mise à jour inclut davantage de propriétés qui peuvent être évaluées.

L’une de ces propriétés est Mis à jour par. Cette propriété vous permet de suivre le type de source qui a apporté la modification dans l’incident. Vous pouvez créer une condition qui évalue si l’incident a été mis à jour par l’une des valeurs suivantes, selon que vous avez intégré ou non votre espace de travail à la plateforme d’opérations de sécurité unifiées :

Avec cette condition, vous pouvez, par exemple, demander à cette règle d’automatisation de s’exécuter sur toute modification apportée à un incident, sauf si elle a été apportée par une autre règle d’automatisation.

Plus encore, le déclencheur de mise à jour utilise également d’autres opérateurs qui vérifient les changements d’état dans les valeurs des propriétés d’incident ainsi que leur état actuel. Une condition de changement d’état est remplie si :

La valeur d’une propriété d’incident a été

• modifiée (quelle que soit la valeur réelle avant ou après).
• modifiée par rapport à la valeur définie dans la condition.
• définie sur la valeur définie dans la condition.
• ajoutée (cela s’applique aux propriétés avec une liste de valeurs).

Propriété Étiquette : individuelle ou collection

La propriété d’incident Étiquette est une collection d’éléments individuels : plusieurs étiquettes peuvent être appliquées à un même incident. Vous pouvez définir des conditions qui vérifient chaque étiquette de la collection individuellement, et des conditions qui vérifient la collection d’étiquettes en tant qu’unité.

• Les opérateurs Toute étiquette individuelle vérifient la condition par rapport à chaque étiquette de la collection. L’évaluation est vraie quand au moins une étiquette remplit la condition.
• Les opérateurs Collection de toutes les étiquettes vérifient la condition par rapport à la collection d’étiquettes en tant qu’unité. L’évaluation est vraie uniquement si la collection dans son ensemble remplit la condition.

Cette distinction est importante lorsque votre condition est négative (ne contient pas) et que certaines étiquettes de la collection remplissent la condition et d’autres non.

Examinons un exemple où votre condition est Étiquette ne contient pas « 2024 » et que vous avez deux incidents, chacun avec deux étiquettes :

Dans cet exemple, dans Incident 1 :

• Si la condition vérifie chaque étiquette individuellement, comme il existe au moins une étiquette qui remplit la condition (qui ne contient pas « 2024 »), la condition globale est vraie.
• Si la condition vérifie toutes les étiquettes de l’incident en tant qu’unité, comme il existe au moins une étiquette qui ne remplit pas la condition (qui contient « 2024 »), la condition globale est false.

Dans Incident 2, le résultat est le même quel que soit le type de condition défini.

Propriétés d’entité prises en charge

Pour obtenir la liste des propriétés d’entité prises en charge en tant que conditions pour les règles d’automatisation, consultez la référence des règles d’automatisation Microsoft Sentinel.

Déclencheur de création d’alerte

Actuellement, la seule condition qui peut être configurée pour le déclencheur de création d’alerte est l’ensemble de règles d’analyse pour lesquelles la règle d’automatisation s’exécute.

Actions

Vous pouvez définir des actions peuvent à exécuter quand les conditions (voir ci-dessus) sont remplies. Vous pouvez définir de nombreuses actions dans une règle et choisir l’ordre dans lequel elles s’exécutent (voir ci-dessous). Vous pouvez définir les actions ci-après à l’aide de règles d’automatisation, sans devoir faire appel à la fonctionnalité avancée d’un playbook :

• Ajout d’une tâche à un incident : vous pouvez créer une liste de contrôle des tâches que les analystes doivent suivre tout au long des processus de triage, d’investigation et de correction de l’incident, afin de vous assurer qu’aucune étape critique n’est omise.

• Modification de l’état d’un incident, maintien à jour de votre flux de travail.

  • Lors du passage à « fermé », spécification de la raison de la fermeture et ajout d’un commentaire. Cela vous permet d’effectuer le suivi de vos performances et de votre efficacité, ainsi que de régler précisément pour réduire les faux positifs.

• Modification de la gravité d’un incident : vous pouvez réévaluer et re-hiérarchiser en fonction de la présence, de l’absence, des valeurs ou des attributs des entités impliquées dans l’incident.

• Attribution d’un incident à un propriétaire : cela vous aide à diriger les différents types d’incidents vers le personnel le plus compétent pour les gérer, ou le personnel le plus disponible.

• Ajout d’une étiquette à un incident : cela est utile pour classifier les incidents par objet, par attaquant ou par tout autre dénominateur commun.

Vous pouvez également définir une action exécuter un playbook pour prendre des mesures de réponse plus complexes, notamment impliquant des systèmes externes. Les playbooks disponibles pour être utilisés dans une règle d’automatisation dépendent du déclencheur sur lequel les playbooks et la règle d’automatisation sont basés : seuls les playbooks de déclencheur d’incident peuvent être exécutés à partir de règles d’automatisation de déclencheur d’incident, et seuls les playbooks de déclencheur d’alerte peuvent être exécutés à partir de règles d’automatisation du déclencheur d’alerte. Vous pouvez définir plusieurs actions qui appellent des playbooks ou des combinaisons de playbooks et d’autres actions. Les actions s’exécutent dans l’ordre dans lequel elles sont répertoriées dans la règle.

Les playbooks utilisant la version d’Azure Logic Apps (Standard ou Consommation) sont disponibles pour être exécutés à partir de règles d’automatisation.

Date d'expiration

Vous pouvez définir une date d’expiration sur une règle d’automatisation. La règle est désactivée après cette date. Cela est utile pour gérer (c’est-à-dire fermer) des incidents de « bruit » occasionnés par des activités planifiées limitées dans le temps, telles qu’un test d’intrusion.

Ordre

Vous pouvez définir l’ordre dans lequel les règles d’automatisation s’exécutent. Les règles d’automatisation ultérieures évaluent les conditions de l’incident en fonction de son état après traitement par des règles d’automatisation précédentes.

Par exemple, si une « première règle d’automatisation » a modifié le niveau de gravité d’un incident de Moyenne à Faible, et si une « deuxième règle d’automatisation » est définie pour s’exécuter uniquement sur les incidents de gravité Moyenne ou supérieure, elle ne s’exécute pas sur cet incident.

L’ordre des règles d’automatisation qui ajoutent des tâches d’incident détermine l’ordre dans lequel les tâches apparaissent dans un incident donné.

Les règles basées sur le déclencheur de mise à jour ont leur propre file d’attente d’ordre distincte. Si de telles règles sont déclenchées pour s’exécuter sur un incident juste créé (par une modification apportée par une autre règle d’automatisation), elles ne s’exécutent qu’une fois que toutes les règles applicables ont fini de s’exécuter en fonction du déclencheur de création.

Remarques sur l’ordre d’exécution et la priorité

• La définition du numéro d’ordre dans les règles d’automatisation détermine leur ordre d’exécution.
• Chaque type de déclencheur tient à jour sa propre file d’attente.
• Pour les règles créées dans le portail Azure, le champ ordre est renseigné automatiquement avec le nombre suivant le nombre le plus élevé utilisé par les règles existantes du même type de déclencheur.
• Toutefois, pour les règles créées de différentes manières (ligne de commande, API, etc.), le champ ordre doit être attribué manuellement.
• Il n’existe aucun mécanisme de validation empêchant plusieurs règles d’avoir le même numéro d’ordre, même dans le même type de déclencheur.
• Vous pouvez autoriser plusieurs règles du même type de déclencheur à avoir le même numéro d’ordre, si vous ne vous souciez pas de l’ordre dans lequel elles s’exécutent.
• Pour les règles du même type de déclencheur avec le même numéro d’ordre, le moteur d’exécution sélectionne de façon aléatoire l’ordre d’exécution des règles.
• Pour les règles de différents types de déclencheur d’incident, toutes les règles applicables avec le type de déclencheur création d’incident s’exécutent en premier (conformément à leurs numéros d’ordre), suivies des règles avec le type de déclencheur mise à jour d’incident (conformément à leurs numéros d’ordre).
• Les règles s’exécutent toujours de manière séquentielle, jamais en parallèle.

Cas d’utilisation et scénarios courants

Tâches d’incident

Les règles d’automatisation vous permettent de standardiser et de formaliser les étapes nécessaires pour le triage, l’investigation et la correction des incidents, en créant des tâches qui peuvent être appliquées à un seul incident, à plusieurs groupes d’incidents ou à tous les incidents, selon les conditions que vous définissez dans la règle d’automatisation et la logique de détection des menaces dans les règles d’analyse sous-jacentes. Les tâches appliquées à un incident figurent dans la page de cet incident, de sorte que vos analystes disposent de la liste complète des mesures qu’ils doivent prendre, juste devant leur yeux, et n’omettent aucune étape critique.

Automatisation déclenchée par des incidents et des alertes

Les règles d’automatisation peuvent être déclenchées par la création ou la mise à jour d’incidents ainsi que par la création d’alertes. Ces occurrences peuvent tous déclencher des chaînes de réponse automatisées, qui peuvent inclure des playbooks (des autorisations spéciales sont requises).

Playbooks de déclencheur pour fournisseurs Microsoft

Les règles d’automatisation offrent un moyen d’automatiser la gestion des alertes de sécurité Microsoft en appliquant ces règles aux incidents créés à partir des alertes. Les règles d’automatisation peuvent appeler des playbooks (des autorisations spéciales sont requises) et leur transmettre les incidents avec tous leurs détails, alertes et entités comprises. En général, les meilleures pratiques de Microsoft Sentinel dictent d’utiliser la file d’attente des incidents comme point focal des opérations de sécurité.

Les alertes de sécurité Microsoft sont les suivantes :

• Protection de l'identifiant Microsoft Entra
• Microsoft Defender pour le cloud
• Microsoft Defender for Cloud Apps
• Microsoft Defender pour Office 365
• Microsoft Defender pour point de terminaison
• Microsoft Defender pour Identity
• Microsoft Defender pour IoT

Plusieurs playbooks/actions séquencés dans une même règle

Vous pouvez maintenant exercer un contrôle presque complet sur l’ordre d’exécution des actions et des playbooks dans une même règle d’automatisation. Vous pouvez également contrôler l’ordre d’exécution des règles d’automatisation elles-mêmes. Cela vous permet de simplifier considérablement vos playbooks, en les réduisant à une seule tâche ou à une petite séquence de tâches simple, et de combiner ces petits playbooks dans différentes combinaisons dans différentes règles d’automatisation.

Attribuer un seul playbook à plusieurs règles d’analytique à la fois

Si vous avez une tâche que vous souhaitez automatiser sur toutes vos règles d’analytique (par exemple, la création d’un ticket de support dans un système de ticket externe), vous pouvez appliquer un seul playbook à la totalité ou à une partie de vos règles d’analytique, y compris des règles futures, en une seule fois. Cela rend les tâches de maintenance et de nettoyage simples mais répétitives beaucoup moins fastidieuses.

Attribution automatique d’incidents

Vous pouvez attribuer automatiquement des incidents au propriétaire approprié. Si votre SOC dispose d’un analyste spécialisé dans une plateforme particulière, tous les incidents liés à cette plateforme peuvent être attribués automatiquement à cet analyste.

Suppression d’incident

Vous pouvez utiliser des règles pour résoudre automatiquement des incidents connus pour être des positifs faux/bénins sans utiliser de playbooks. Par exemple, quand vous effectuez des tests de pénétration, des tâches de maintenance planifiée ou des mises à niveau, ou quand vous testez des procédures d’automatisation, cela peut générer de nombreux incidents faux positifs que le SOC souhaite ignorer. Une règle d’automatisation limitée dans le temps peut automatiquement fermer ces incidents au fur et à mesure de leur création, tout en les marquant avec un descripteur de la cause de leur génération.

Automatisation limitée dans le temps

Vous pouvez ajouter des dates d’expiration pour vos règles d’automatisation. Il peut y avoir des cas autres que la suppression d’incident qui nécessitent une automatisation limitée dans le temps. Vous souhaiterez peut-être attribuer un type particulier d’incident à un utilisateur particulier (par exemple, un stagiaire ou un consultant) pour une période spécifique. Si le délai d’exécution est connu à l’avance, vous pouvez très bien faire en sorte que la règle soit désactivée à la fin de sa pertinence, sans que vous ayez à vous souvenir de le faire.

Étiqueter automatiquement des incidents

Vous pouvez ajouter automatiquement des étiquettes en texte libre à des incidents pour les regrouper ou les classer en fonction de critères de votre choix.

Cas d’usage ajoutés par le déclencheur de mise à jour

Maintenant que les modifications apportées aux incidents peuvent déclencher des règles d’automatisation, d’autres scénarios sont ouverts à l’automatisation.

Étendre l’automatisation lorsque l’incident évolue

Vous pouvez utiliser le déclencheur de mise à jour pour appliquer un grand nombre des cas d’usage ci-dessus aux incidents à mesure que leur investigation progresse et que les analystes ajoutent des alertes, des commentaires et des balises. Contrôlez le regroupement d’alertes dans les incidents.

Mettre à jour l’orchestration et la notification

Informez vos différentes équipes et autres personnes lorsque des modifications sont apportées aux incidents, afin qu’elles ne passent à côté d’aucune mise à jour critique. Escaladez les incidents en les attribuant à de nouveaux propriétaires et en informant les nouveaux propriétaires de leurs affectations. Contrôlez quand et comment les incidents sont rouverts.

Maintenir la synchronisation avec des systèmes externes

Si vous avez utilisé des playbooks pour créer des tickets dans des systèmes externes lors de la création d’incidents, vous pouvez utiliser une règle d’automatisation de déclencheur de mise à jour pour appeler un playbook qui met à jour ces tickets.

Exécution de règles d’automatisation

Les règles d’automatisation sont exécutées de façon séquentielle, en fonction de l’ordre que vous déterminez. Chaque règle d’automatisation est exécutée une fois l’exécution de la règle précédente terminée. Dans une règle d’automatisation, toutes les actions sont exécutées de façon séquentielle dans l’ordre dans lequel elles sont définies.

Les actions du playbook au sein d’une règle d’automatisation peuvent être traitées différemment dans certaines circonstances, en fonction des critères suivants :

Autorisations de règles d’automatisation pour l’exécution de playbooks

Quand une règle d’automatisation de Microsoft Sentinel exécute un playbook, elle utilise un compte de service Microsoft Sentinel spécial spécifiquement autorisé pour cette action. L’utilisation de ce compte (par opposition à votre compte d’utilisateur) augmente le niveau de sécurité du service.

Pour qu’une règle d’automatisation exécute un playbook, ce compte doit disposer d’autorisations explicites sur le groupe de ressources dans lequel se trouve le playbook. À ce stade, toute règle d’automatisation est en mesure d’exécuter n’importe quel playbook dans ce groupe de ressources.

Quand vous configurez une règle d’automatisation et ajoutez l’action Exécuter le playbook, une liste déroulante de playbooks s’affiche. Les playbooks sur lesquels Microsoft Sentinel n’a pas d’autorisation apparaissent indisponibles (« grisés »). Vous pouvez accorder une autorisation Microsoft Sentinel aux groupes de ressources du playbook sur place en sélectionnant le lien Gérer les autorisations des playbooks. Pour accorder ces autorisations, vous aurez besoin d’autorisations Propriétaire sur ces groupes de ressources. Consultez les exigences d’autorisations complètes.

Autorisations dans une architecture multilocataire

Les règles d’automatisation prennent entièrement en charge les déploiements multilocataires parmi plusieurs espaces de travail (avec Azure Lighthouse dans le cas d’un déploiement multilocataire).

Par conséquent, si votre déploiement de Microsoft Sentinel utilise une architecture multilocataire, vous pouvez faire en sorte qu’une règle d’automatisation située dans un locataire exécute un playbook qui se trouve dans un autre locataire. Cependant, les autorisations permettant à Sentinel d’exécuter les playbooks doivent être établies dans le locataire où résident les playbooks, et non dans celui où les règles d’automatisation sont définies.

Dans le cas précis d’un fournisseur de services de sécurité gérée (où le locataire d’un fournisseur de services gère un espace de travail Microsoft Sentinel dans le locataire d’un client), deux scénarios particuliers doivent être pris en compte :

• Une règle d’automatisation créée dans le locataire du client est configurée pour exécuter un playbook situé dans le locataire du fournisseur de services.

  Cette approche est normalement utilisée pour protéger la propriété intellectuelle dans le playbook. Rien de spécial n’est nécessaire pour que ce scénario fonctionne. Lorsque vous définissez une action de playbook dans votre règle d’automatisation et que vous arrivez à la phase où vous accordez des autorisations Microsoft Sentinel sur le groupe de ressources dans lequel se trouve le playbook (à l’aide du panneau Gérer les autorisations du playbook), les groupes de ressources appartenant au locataire du fournisseur de services figurent parmi les choix possibles. Consultez l’ensemble du processus décrit ici.

• Une règle d’automatisation créée dans l’espace de travail du client (avec connexion au locataire du fournisseur de services) est configurée pour exécuter un playbook situé dans le locataire du client.

  Cette configuration est utilisée lorsqu’il n’est pas nécessaire de protéger la propriété intellectuelle. Pour que ce scénario fonctionne, les autorisations d’exécution du playbook doivent être accordées à Microsoft Sentinel dans les deux locataires. Dans le locataire du client, vous pouvez les octroyer dans le panneau Gérer les autorisations du playbook comme dans le scénario ci-dessus. Pour accorder les autorisations appropriées dans le locataire du fournisseur de services, vous devez ajouter une délégation Azure Lighthouse supplémentaire qui accorde des droits d’accès à l’application Azure Security Insights avec le rôle Contributeur Automatisation Microsoft Sentinel sur le groupe de ressources où se trouve le playbook.

  Le scénario ressemble à ceci :

  

  Pour mettre en place cette configuration, consultez nos instructions.

Création et gestion de règles d’automatisation

Vous pouvez créer et gérer des règles d’automatisation à partir de différents domaines dans Microsoft Sentinel ou la plateforme d’opérations de sécurité unifiées, en fonction de vos besoins et cas d’usage particuliers.

• Page Automatisation

  Les règles d’automatisation peuvent être gérées de manière centralisée dans la page Automatisation, sous l’onglet Règles d’automatisation. À partir de là, vous pouvez créer des règles d’automatisation et modifier des règles existantes. Vous pouvez également faire glisser des règles d’automatisation pour modifier leur ordre d’exécution, ainsi que les activer ou les désactiver.

  La page Automatisation affiche toutes les règles définies dans l’espace de travail, ainsi que leur état (Activée/Désactivée) et les règles d’analyse auxquelles elles sont appliquées.

  Lorsque vous avez besoin d’une règle d’automatisation qui s’appliquera aux incidents provenant de Microsoft Defender XDR ou provenant de nombreuses règles d’analyse dans Microsoft Sentinel, créez-la directement dans la page Automatisation.

• Assistant Règle d’analytique

  Dans l’onglet Réponse automatisée de l’Assistant de règle d’analyse de Microsoft Sentinel, sous Règles d’automatisation, vous pouvez afficher, modifier et créer des règles d’automatisation qui s’appliquent à la règle d’analyse spécifique créée ou modifiée dans l’Assistant.

  Lorsque vous créez une règle d’automatisation à partir d’ici, le panneau Créer une nouvelle règle d’automatisation affiche la condition de Règle d’analyse comme indisponible, car cette règle est déjà définie pour s’appliquer uniquement à la règle d’analyse que vous modifiez dans l’Assistant. Toutes les autres options de configuration sont toujours disponibles.

• Page Incidents

  Vous pouvez également créer une règle d’automatisation à partir de la page Incidents en réponse à un incident unique et périodique. Cela est utile lors de la création d’une règle de suppression pour la fermeture automatique d’incidents « bruyants ».

  Lorsque vous créez une règle d’automatisation à partir d’ici, le panneau Créer une nouvelle règle d’automatisation remplit tous les champs avec les valeurs de l’incident. Il attribue à la règle le nom de l’incident, l’applique à la règle d’analytique qui a généré l’incident, et utilise toutes les entités disponibles dans l’incident en tant que conditions de la règle. Il suggère également une action de suppression (fermeture) par défaut, ainsi qu’une date d’expiration pour la règle. Vous pouvez ajouter ou supprimer des conditions et actions, ainsi que modifier la date d’expiration à votre guise.

Exporter et importer des règles d’automatisation

Exportez vos règles d’automatisation vers des fichiers de modèle Azure Resource Manager (ARM) et importez des règles à partir de ces fichiers dans le cadre de la gestion et du contrôle de vos déploiements Microsoft Sentinel en tant que code. L’action d’exportation entraîne la création d’un fichier JSON dans l’emplacement de téléchargement de votre navigateur. Vous pouvez ensuite le renommer, le déplacer et le gérer comme tout autre fichier.

Puisque le fichier JSON exporté est indépendant de l’espace de travail, il peut être importé dans d’autres espaces de travail, voire d’autres locataires. En tant que code, il peut également être contrôlé par version, mis à jour et déployé dans une infrastructure CI/CD managée.

Le fichier inclut tous les paramètres définis dans la règle d’automatisation. Les règles de n’importe quel type de déclencheur peuvent être exportées vers un fichier JSON.

Pour obtenir des instructions sur l’exportation et l’importation de règles d’automatisation, consultez Exporter et importer des règles d’automatisation Microsoft Sentinel.

Étapes suivantes

Ce document vous a montré comment des règles d’automatisation peuvent vous aider à gérer votre file d’attente d’incidents Microsoft Sentinel, et implémenter une automatisation de base de la gestion des incidents et alertes.

• Créer et utiliser des règles d’automatisation Microsoft Sentinel pour gérer les incidents.
• Utilisez des règles d’automatisation pour créer des listes de tâches pour les analystes.
• Pour en savoir plus sur les options d’automatisation avancées, consultez Automatiser la réponse aux menaces à l’aide de playbooks dans Microsoft Sentinel.
• Pour obtenir de l’aide sur l’implémentation des playbooks, consultez Tutoriel : Utiliser des playbooks pour automatiser les réponses aux menaces dans Microsoft Sentinel.