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

Article
04/29/2024

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.

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.

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.

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.

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.

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 :

Préparation
Détection et analyse
Limitation, éradication et récupération
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.

Partager via