Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’un des facteurs les plus importants pour l’exécution efficace et efficiente de vos opérations de sécurité (SecOps) est la standardisation des processus. Les analystes SecOps sont censés effectuer une liste d’étapes, ou de tâches, dans le processus de tri, d’enquête ou de correction d’un incident. La standardisation et la formalisation de la liste des tâches peuvent vous aider à assurer le bon fonctionnement de votre SOC, en veillant à ce que les mêmes exigences s’appliquent à tous les analystes. De cette façon, quelle que soit la personne en poste, un incident recevra toujours le même traitement et les mêmes SLA. Les analystes n’auront pas besoin de passer du temps à réfléchir à ce qu’il faut faire ou de s’inquiéter de manquer une étape critique. Ces étapes sont définies par le responsable du SOC ou les analystes principaux (niveaux 2/3) sur la base de connaissances courantes en matière de sécurité (telles que le NIST), de leur expérience des incidents passés ou des recommandations fournies par le fournisseur de sécurité qui a détecté l’incident.
Cas d’utilisation
Vos analystes SOC peuvent utiliser une seule liste de contrôle centrale pour gérer les processus de triage, d’enquête et de réponse aux incidents, le tout sans se soucier de manquer une étape critique.
Vos ingénieurs SOC ou vos analystes seniors peuvent documenter, mettre à jour et aligner les normes de réponse aux incidents dans les équipes et les équipes des analystes. Ils peuvent également créer des listes de contrôle des tâches pour former les nouveaux analystes ou les analystes confrontés à de nouveaux types d’incidents.
En tant que responsable SOC ou MSSP, vous pouvez vous assurer que les incidents sont traités conformément aux SLA/SOP pertinents.
Conditions préalables
Le rôle Répondeur Microsoft Sentinel est nécessaire pour créer des règles d’automatisation et pour voir et modifier les incidents, ce qui est à la fois nécessaire pour ajouter, afficher et modifier des tâches.
Le rôle Contributeur Logic Apps est requis pour créer et modifier des playbooks.
Scénarios
Analyste
Suivre des tâches lors de la gestion d’un incident
Quand vous sélectionnez un incident et affichez tous les détails, dans la page des détails de l’incident, vous voyez, dans le panneau situé à droite, toutes les tâches qui ont été ajoutées à cet incident, qu’elles l’aient été manuellement ou par des règles d’automatisation.
Développez une tâche pour voir sa description complète, notamment l’utilisateur, la règle d’automatisation ou le playbook qui l’a créée.
Marquez une tâche comme terminée en cochant sa case.
Ajouter à chaud des tâches à un incident
Vous pouvez ajouter des tâches à un incident ouvert sur lequel vous travaillez, soit pour vous rappeler les mesures que vous avez découvertes et avez besoin de prendre, soit pour enregistrer les mesures que vous avez prises à votre propre initiative et qui n’apparaissent pas dans la liste des tâches. Les tâches ajoutées de cette façon s’appliquent uniquement à l’incident ouvert.
Créateur de workflows
Ajouter des tâches aux incidents avec des règles d’automatisation
Utilisez l’action Ajouter une tâche dans les règles d’automatisation pour fournir automatiquement à tous les incidents une check-list des tâches pour vos analystes. Définissez la condition Nom de la règle d’analyse dans votre règle d’automatisation pour déterminer l’étendue :
Appliquez la règle d’automatisation à toutes les règles d’analyse afin de définir un ensemble standard de tâches à appliquer à tous les incidents.
En appliquant votre règle d’automatisation à un ensemble limité de règles d’analyse, vous pouvez affecter des tâches spécifiques à des incidents particuliers, en fonction des menaces détectées par la règle d’analyse ou les règles qui ont généré ces incidents.
Considérez que l’ordre dans lequel les tâches apparaissent dans votre incident est déterminé par l’heure de création des tâches. Vous pouvez définir l’ordre des règles d’automatisation afin que celles qui ajoutent des tâches nécessaires à tous les incidents s’exécutent en premier et que celles qui ajoutent des tâches nécessaires aux incidents générés par des règles d’analyse spécifiques s’exécutent seulement après. Au sein d’une règle unique, l’ordre dans lequel les actions sont définies détermine l’ordre dans lequel elles apparaissent dans un incident.
Avant de créer une règle d’automatisation, déterminez quels incidents sont couverts par les règles et tâches d’automatisation existantes.
Utilisez le filtre Action de la liste Règles d’automatisation pour voir uniquement les règles qui ajoutent des tâches aux incidents et déterminer à quelles règles d’analyse ces règles d’automatisation s’appliquent, afin de comprendre à quels incidents ces tâches seront ajoutées.
Ajouter des tâches aux incidents avec des playbooks
Utilisez l’action Ajouter une tâche dans un playbook (dans le connecteur Microsoft Sentinel) pour ajouter automatiquement une tâche à l’incident qui a déclenché le playbook.
Ensuite, utilisez d’autres actions de playbook, dans leurs connecteurs Logic Apps respectifs, pour terminer le contenu de la tâche.
Enfin, utilisez l’action Marquer la tâche comme terminée (encore dans le connecteur Microsoft Sentinel) pour marquer automatiquement la tâche comme terminée.
Considérez les scénarios suivants comme des exemples :
Laisser les playbooks ajouter et exécuter des tâches : Quand un incident est créé, il déclenche un playbook qui effectue ceci :
- Il ajoute une tâche à l’incident pour réinitialiser le mot de passe d’un utilisateur.
- Il effectue la tâche en émettant un appel d’API au système de provisionnement d’utilisateurs pour réinitialiser le mot de passe de l’utilisateur.
- Il attend une réponse du système quant à la réussite ou l’échec de la réinitialisation.
- Si la réinitialisation du mot de passe a réussi, le playbook marque la tâche qu’il vient de créer dans l’incident comme terminée.
- Si la réinitialisation du mot de passe a échoué, le playbook ne marque pas la tâche comme terminée, ce qui laisse à un analyste le soin de l’exécuter.
Laisser le playbook évaluer si des tâches conditionnelles doivent être ajoutées : Quand un incident est créé, il déclenche un playbook qui demande un rapport d’adresse IP auprès d’une source externe de renseignement sur les menaces.
- Si l’adresse IP est malveillante, le playbook ajoute une certaine tâche (par exemple, « Bloquer cette adresse IP »).
- Sinon, le playbook n’effectue aucune autre action.
Utiliser des règles d’automatisation ou des playbooks pour ajouter des tâches ?
Quelles sont les considérations qui doivent dicter les méthodes à utiliser pour créer des tâches d’incident ?
- Règles d’automatisation : à utiliser dans la mesure du possible. Utilisez-les pour les tâches statiques simples qui ne nécessitent pas d’interactivité.
- Playbooks : à utiliser pour les cas d’utilisation avancés, c’est-à-dire la création de tâches basées sur des conditions ou de tâches avec des actions automatisées intégrées.
Étapes suivantes
- Découvrez comment les analystes peuvent utiliser des tâches pour gérer le flux de travail des incidents dans Microsoft Sentinel.
- En savoir plus sur l’investigation des incidents dans Microsoft Sentinel.
- Découvrez comment ajouter automatiquement des tâches à des groupes d’incidents à l’aide de règles d’automatisation ou de playbooks.
- Découvrez-en plus sur les règles d’automatisation et la manière de les créer.
- Découvrez-en plus sur les playbooks et la manière de les créer.