Partager via


Étape 5. Développer et tester des cas d’usage

S’applique à :

  • Microsoft Defender XDR

Les méthodes recommandées pour déployer Microsoft Defender XDR dans votre Centre des opérations de sécurité (SOC) dépendent de l’ensemble actuel d’outils, de processus et de compétences de l’équipe SOC. Le maintien de la cybersécurité entre les plateformes peut être difficile en raison de la grande quantité de données provenant de dizaines, voire de centaines de sources de sécurité.

Les outils de sécurité sont liés. L’activation d’une fonctionnalité dans une technologie de sécurité ou la modification d’un processus peut à son tour en rompre une autre. Pour cette raison, Microsoft recommande à votre équipe SOC de formaliser une méthode pour définir et hiérarchiser les cas d’usage. Les cas d’usage aident à définir les exigences et à tester les processus pour les opérations SOC au sein de différentes équipes. Il crée une méthodologie de capture des métriques afin de déterminer si les rôles appropriés et la combinaison de tâches sont alignés sur l’équipe appropriée avec l’ensemble de compétences approprié.

Développer et formaliser le processus de cas d’usage

Le SOC doit définir une norme et un processus de haut niveau pour l’élaboration de cas d’usage, qui seraient réglementés par l’équipe de supervision soc. L’équipe de supervision SOC doit travailler avec votre entreprise, votre service informatique, le secteur juridique, les RH et d’autres groupes pour hiérarchiser les cas d’usage du SOC qui finiront par faire leur chemin dans les runbooks et les playbooks de l’équipe SOC. La priorité des cas d’usage est basée sur des objectifs, tels que la conformité ou la confidentialité.

Les activités de supervision soc liées au développement de cas d’usage sont les suivantes :

  • Conditions requises
  • Besoins en personnel ou en formation
  • Licences logicielles
  • Contrat fournisseur
  • Gestion du plan
  • Gestion du registre de cas d’usage
  • Maintenance/mise à jour des modèles

Pour faciliter les processus de création de runbook et de playbook, créez un arbre de décision de cas d’usage. Cette figure montre un exemple.

Le processus de décision de cas d’usage

Une fois qu’une norme de cas d’usage de haut niveau a été définie et approuvée, l’étape suivante consiste à créer et tester un cas d’usage réel. Les sections suivantes utilisent des scénarios anti-hameçonnage et d’analyse des menaces et des vulnérabilités comme exemples.

Exemple de cas d’usage 1 : Nouvelle variante de hameçonnage

La première étape de la création d’un cas d’usage consiste à décrire le flux de travail à l’aide d’un story board. Voici un exemple de story-board de haut niveau pour une nouvelle notification d’attaque d’hameçonnage à une équipe de renseignement sur les menaces.

Flux de travail d’un cas d’usage pour une campagne anti-hameçonnage

Appeler le workflow de cas d’usage pour l’exemple 1

Une fois que le story board a été approuvé, l’étape suivante consiste à appeler le workflow de cas d’usage. Voici un exemple de processus pour une campagne anti-hameçonnage.

Flux de travail de cas d’usage détaillé pour une campagne anti-hameçonnage

Exemple de cas d’usage 2 : Analyse des menaces et des vulnérabilités

Un autre scénario où un cas d’usage peut être utilisé concerne l’analyse des menaces et des vulnérabilités. Dans cet exemple, le SOC exige que les menaces et les vulnérabilités soient corrigées contre les ressources via des processus approuvés qui incluent l’analyse des ressources.

Voici un exemple de storyboard de haut niveau pour la Gestion des vulnérabilités Microsoft Defender de ressources.

Flux de travail de cas d’usage pour Gestion des menaces et des vulnérabilités

Appeler le workflow de cas d’usage pour l’exemple 2

Voici un exemple de processus pour l’analyse des menaces et des vulnérabilités.

Flux de travail de cas d’usage détaillé pour Gestion des menaces et des vulnérabilités

Analyser la sortie du cas d’usage et les leçons apprises

Une fois qu’un cas d’usage a été approuvé et testé, les lacunes au sein de vos équipes de sécurité doivent être identifiées, ainsi que les personnes, les processus et les technologies Microsoft Defender XDR impliquées. Microsoft Defender XDR technologies doivent être analysées pour déterminer si elles sont capables d’atteindre les résultats souhaités. Ceux-ci peuvent être suivis via une liste de contrôle ou une matrice.

Par exemple, dans l’exemple de scénario anti-hameçonnage, les équipes SOC auraient pu effectuer les découvertes dans ce tableau.

Équipe SOC Conditions requises Personnes répondre aux exigences Processus pour répondre aux exigences Technologie pertinente Écart identifié Journal des modifications des cas d’usage Exempt (Y/N)
Équipe Threat Intelligence and Analytics Les sources de données alimentent correctement les moteurs de renseignement sur les menaces. Analyste/ingénieur du renseignement sur les menaces Exigences de flux de données établies, déclencheurs de renseignement sur les menaces à partir de sources approuvées Microsoft Defender pour Identity, Microsoft Defender pour point de terminaison L’équipe Threat Intelligence n’a pas utilisé de script d’automatisation pour lier Microsoft Defender XDR’API aux moteurs d’intelligence des menaces Ajouter des Microsoft Defender XDR en tant que sources de données aux moteurs de menaces

Mettre à jour le livre d’exécution des cas d’usage

N
Équipe de supervision Les sources de données alimentent correctement les tableaux de bord de surveillance Analyste SOC de niveau 1,2 – Surveillance des alertes & Flux de travail pour la création de rapports niveau de sécurité & de conformité du Centre de conformité Examiner les alertes dans Microsoft Defender XDR

Surveillance du degré de sécurisation

Aucun mécanisme pour les analystes SOC pour signaler la détection réussie d’une nouvelle variante d’hameçonnage afin d’améliorer le degré de sécurisation

Afficher les rapports de sécurité des e-mails dans le portail Microsoft Defender

Ajouter un processus de suivi de l’amélioration du degré de sécurisation aux flux de travail de création de rapports N
Équipe d’ingénierie et de SecOps Les mises à jour du contrôle des modifications sont effectuées dans les runbooks d’équipe SOC Ingénieur SOC de niveau 2 Procédure de notification de contrôle des modifications pour les runbooks d’équipe SOC Modifications approuvées apportées aux appareils de sécurité Les modifications apportées à Microsoft Defender XDR connectivité à la technologie de sécurité SOC nécessitent une approbation Ajouter Microsoft Defender for Cloud Apps, Defender pour Identity, Defender pour point de terminaison, Security & Compliance Center aux runbooks SOC O

En outre, les équipes SOC auraient pu effectuer les découvertes décrites dans le tableau ci-dessous en ce qui concerne le scénario de gestion des vulnérabilités Defender décrit ci-dessus :

Équipe SOC Conditions requises Personnes répondre aux exigences Processus pour répondre aux exigences Technologie pertinente Écart identifié Journal des modifications des cas d’usage Exempt (Y/N)
Supervision SOC Toutes les ressources connectées à des réseaux approuvés sont identifiées et classées Supervision SOC, propriétaires d’bu, propriétaires d’applications, propriétaires de ressources informatiques, etc. Système de gestion centralisée des ressources pour découvrir et répertorier les attributs et les catégories d’actifs en fonction du risque. ServiceNow ou d’autres ressources.

Inventaire des appareils Microsoft 365
Seulement 70 % des ressources ont été découvertes. Microsoft Defender XDR le suivi des corrections ne prend effet que pour les ressources connues Services de gestion du cycle de vie des ressources matures pour garantir Microsoft Defender XDR a une couverture à 100 % N
Ingénierie & SecOps Teams Les vulnérabilités critiques et à impact élevé des ressources sont corrigées conformément à la stratégie Ingénieurs SecOps, analystes SOC : vulnérabilité & conformité, ingénierie de sécurité Processus défini pour la catégorisation des vulnérabilités critiques et à haut risque Tableaux de bord Gestion des vulnérabilités Microsoft Defender Defender pour point de terminaison a identifié des appareils à fort impact et à forte alerte sans plan de correction ou implémentation de l’activité recommandée par Microsoft Ajoutez un flux de travail pour avertir les propriétaires de ressources lorsque l’activité de correction est requise dans les 30 jours par stratégie ; Implémentez un système de tickets pour informer les propriétaires de ressources des étapes de correction. N
Surveillance des équipes Les status de menaces et de vulnérabilités sont signalées via le portail intranet de l’entreprise Analyste SOC de niveau 2 Rapports générés automatiquement à partir de Microsoft Defender XDR montrant la progression de la correction des ressources Examiner les alertes dans Microsoft Defender XDR

Surveillance du degré de sécurisation

Aucun affichage ou rapport de tableau de bord n’est communiqué aux propriétaires de ressources concernant les menaces et les vulnérabilités status des ressources. Create script d’automatisation pour remplir status de correction des vulnérabilités des ressources critiques et à haut risque dans le organization. N

Dans ces exemples de cas d’usage, les tests ont révélé plusieurs lacunes dans les exigences de l’équipe SOC, qui ont été établies comme bases de référence pour les responsabilités de chaque équipe. La liste de contrôle du cas d’utilisation peut être aussi complète que nécessaire pour s’assurer que l’équipe SOC est prête pour l’intégration Microsoft Defender XDR aux exigences SOC nouvelles ou existantes. Étant donné qu’il s’agit d’un processus itératif, le processus de développement de cas d’usage et le contenu de sortie du cas d’usage servent naturellement à mettre à jour et à faire évoluer les runbooks du SOC avec les leçons apprises.

Mettre à jour les runbooks de production et les playbooks

Une fois que les tests de cas d’usage ont été corrigés pour toutes les lacunes, les leçons apprises et les métriques collectées dans celles-ci peuvent être incorporées dans les runbooks de production (processus d’exploitation) et les playbooks de votre équipe SOC (réponses aux incidents et procédures d’escalade).

La maintenance des runbooks et playbooks de l’équipe SOC peut être organisée de nombreuses façons. Chaque équipe SOC peut être responsable de sa propre version, ou il peut y avoir une seule version centralisée que toutes les équipes peuvent partager dans un référentiel central. La gestion des runbooks et des playbooks pour chaque organisation est basée sur la taille, l’ensemble des compétences, les rôles et la répartition des tâches. Une fois qu’un runbook a été mis à jour, le processus de mise à jour du playbook doit suivre.

Utiliser une infrastructure standard pour l’escalade

Les playbooks sont les étapes que les équipes SOC doivent suivre lorsqu’un événement réel se produit, en fonction de la réussite de l’intégration et du test du cas d’usage. Par conséquent, il est impératif que le SOC suive une approche formalisée de la réponse aux incidents, telle que la norme de réponse aux incidents NIST qui est devenue l’une des normes les plus importantes du secteur en matière de réponse aux incidents.

Le processus de réponse aux incidents en quatre étapes du NIST comprend quatre phases :

  1. Préparation
  2. Détection et analyse
  3. Limitation, éradication et récupération
  4. Activité post-incident

Exemple : Suivi de l’activité de la phase de préparation

L’un des fondements d’un playbook d’escalade est de s’assurer qu’il y a peu d’ambiguïté quant à ce que chaque équipe SOC est censée faire avant, pendant et après un événement ou un incident. Par conséquent, il est recommandé de répertorier des instructions pas à pas.

Par exemple, la phase de préparation peut inclure une matrice if/then ou XoR de tâches. Dans le cas du nouveau cas d’usage de variante de hameçonnage, une telle matrice peut ressembler à ceci :

Pourquoi l’escalade est-elle justifiée ? Étape suivante
Alerte dans la surveillance SOC évaluée comme critique déclenchée >500/heure Accédez au Playbook A, Section 2, Activité 5 (avec un lien vers la section playbook)
Le commerce électronique a signalé une attaque DDoS potentielle Appeler playbook B-Section C, Activité 19 (avec un lien vers la section playbook)
Un responsable a signalé un e-mail suspect comme tentative d’hameçonnage par lance Accédez au Playbook 5, Section 2, Activité 5 (avec un lien vers la section playbook)

Après avoir exécuté la phase de préparation, les organisations doivent appeler les phases restantes comme indiqué par le NIST :

  • Détection et analyse
  • Limitation, éradication et récupération
  • Activité post-incident

Étape suivante

Étape 6. Identifier les tâches de maintenance SOC

Conseil

Voulez-vous en savoir plus ? Engage avec la communauté Microsoft Security dans notre communauté technique : Microsoft Defender XDR Tech Community.