Planifier votre migration vers Microsoft Sentinel
Les équipes du centre des opérations de sécurité (SOC) utilisent des solutions centralisées de gestion des informations de sécurité et des événements (SIEM), et d’orchestration, d’automatisation et de réponse en matière de sécurité (SOAR) pour protéger leur patrimoine numérique de plus en plus décentralisé. Bien que les SIEM hérités puissent maintenir une bonne couverture des ressources locales, les architectures locales peuvent avoir une couverture insuffisante pour les ressources cloud, comme dans Azure, Microsoft 365, AWS ou Google Cloud Platform (GCP). Par comparaison, Microsoft Sentinel peut ingérer des données provenant à la fois de ressources locales et de ressources cloud, ce qui garantit une couverture de l’ensemble du patrimoine.
Cet article explique les raisons de migrer depuis un SIEM hérité et décrit comment planifier les différentes phases de votre migration.
Étapes de la migration
Dans ce guide, vous allez apprendre à migrer votre SIEM hérité vers Microsoft Sentinel. Suivez votre processus de migration à travers cette série d’articles, où vous allez apprendre à parcourir les différentes étapes du processus.
Notes
Pour un processus de migration guidé, rejoignez le programme de migration et de modernisation Microsoft Sentinel. Le programme vous permet de simplifier et d’accélérer la migration, en incluant des conseils de bonnes pratiques, des ressources et de l’aide d’experts à chaque étape. Pour en savoir plus, contactez votre équipe de compte.
Présentation de Microsoft Sentinel
Microsoft Sentinel est une solution native cloud et évolutive de type SIEM (Security Information and Event Management) et SOAR (Security Orchestrated Automated Response). Microsoft Sentinel fournit une analytique de sécurité intelligente et des renseignements sur les menaces à l’échelle de l’entreprise. Microsoft Sentinel fournit une solution unique pour la détection des attaques, la visibilité des menaces, le repérage proactif et la réponse aux menaces. En savoir plus sur Microsoft Sentinel.
Pourquoi migrer depuis un SIEM hérité ?
Les équipes SOC sont confrontées à un ensemble de problématiques dans la gestion d’un SIEM hérité :
- Réponse lente aux menaces. Les SIEM hérités utilisent des règles de corrélation, difficiles à maintenir et qui sont inefficaces pour identifier les menaces émergentes. En outre, les analystes SOC sont confrontés à de grandes quantités de faux positifs, à de nombreuses alertes provenant de nombreux composants de sécurité différents et à des volumes de journaux de plus en plus importants. L’analyse de ces données ralentit les équipes SOC dans leurs efforts pour répondre aux menaces critiques dans l’environnement.
- Problématiques de mise à l’échelle. À mesure que les vitesses d’ingestion des données augmentent, les équipes SOC sont confrontées à la mise à l’échelle de leur SIEM. Au lieu de se concentrer sur la protection de l’organisation, les équipes SOC doivent investir dans la configuration et la maintenance de l’infrastructure, et elles sont contraintes par les limites du stockage ou des requêtes.
- Analyse et réponse manuelles. Les équipes SOC ont besoin d’analystes hautement qualifiés pour traiter manuellement de grandes quantités d’alertes. Les équipes SOC sont surchargées et de nouveaux analystes sont difficiles à trouver.
- Gestion complexe et inefficace. Les équipes SOC supervisent généralement l’orchestration et l’infrastructure, gèrent les connexions entre le SIEM et différentes sources de données, et effectuent des mises à jour et appliquent des correctifs. Ces tâches se font souvent au détriment du triage et de l’analyse critiques.
Un SIEM natif cloud répond à ces problématiques. Microsoft Sentinel collecte les données automatiquement et à grande échelle, détecte les menaces inconnues, examine les menaces avec de l’intelligence artificielle et répond rapidement aux incidents avec une automatisation intégrée.
Planifier votre migration
Au cours de la phase de planification, vous identifiez vos composants SIEM et vos processus SOC existants, et vous concevez et vous planifiez de nouveaux cas d’usage. Une planification approfondie vous permet de maintenir la protection de vos ressources cloud (Microsoft Azure, AWS ou GCP) et de vos solutions SaaS, comme Microsoft Office 365.
Ce diagramme décrit les grandes phases d’une migration classique. Chaque phase comprend des objectifs clairs, des activités clés, et des résultats et des livrables spécifiés.
Les phases de ce diagramme servent de guide pour effectuer une procédure de migration classique. Une migration réelle peut ne pas inclure certaines phases ou inclure plus de phases. Au lieu de passer en revue l’ensemble complet des phases, les articles de ce guide passent en revue des tâches et des étapes spécifiques qui sont particulièrement importantes pour une migration vers Microsoft Sentinel.
Considérations
Passez en revue ces considérations importantes pour chaque phase.
| Phase | Considération |
|---|---|
| Découvrez | Identifiez les cas d’usage et les priorités de migration dans le cadre de cette phase. |
| Conception | Définissez une conception et une architecture détaillées pour votre implémentation de Microsoft Sentinel. Vous allez utiliser ces informations pour obtenir l’approbation des parties prenantes pertinentes avant de démarrer la phase d’implémentation. |
| Implémenter | Quand vous implémentez des composants Microsoft Sentinel en fonction de la phase de conception et avant de convertir toute votre infrastructure, déterminez si vous pouvez utiliser du contenu prédéfini de Microsoft Sentinel au lieu de migrer tous les composants. Vous pouvez commencer à utiliser Microsoft Sentinel progressivement, en commençant par un produit minimum viable (MVP) pour plusieurs cas d’usage. Au fil de l’ajout d’autres cas d’usage, vous pouvez utiliser cette instance Microsoft Sentinel comme environnement de test d’acceptation des utilisateurs (UAT) pour valider les cas d’usage. |
| Opérationnaliser | Vous migrez votre contenu et vos processus SOC pour faire en sorte que l’expérience des analystes existants ne soit pas interrompue. |
Identifier vos priorités de migration
Utilisez ces questions pour définir vos priorités de migration :
- Quels sont les composants d’infrastructure, les systèmes, les applications et les données les plus critiques dans votre entreprise ?
- Qui vos parties prenantes dans la migration ? La migration SIEM est susceptible de toucher de nombreux domaines de votre entreprise.
- Qu’est-ce qui pilote vos priorités ? Par exemple, le risque métier le plus important, les exigences de conformité, des priorités métier, etc.
- Quelle est l’échelle et le calendrier de votre migration ? Quels facteurs affectent vos dates et vos échéance ? Migrez-vous tout un système hérité ?
- Avez-vous les compétences nécessaires ? Votre personnel de sécurité est-il formé et prêt pour la migration ?
- Existe-t-il des éléments bloquants spécifiques dans votre organisation ? Des problèmes affectent-ils la planification et le calendrier de la migration ? Par exemple, des problèmes comme des exigences en matière de personnel et de formation, des dates de licence, des échéances impératives, des besoins métier spécifiques, etc.
Avant de commencer la migration, identifiez les cas d’usage clés, les règles de détection, les données et l’automatisation dans votre SIEM actuel. Approchez votre migration comme un processus progressif. Soyez précis et réfléchi quant à ce que vous migrez d’abord, ce que vous n’allez pas traiter en priorité et ce qui n’a pas réellement besoin d’être migré. Votre équipe peut avoir un nombre considérable de détections et de cas d’usage s’exécutant dans votre SIEM actuel. Avant de commencer la migration, décidez de celles qui sont réellement utiles à votre entreprise.
Identifier les cas d’usage
Lors de la planification de la phase de découverte, utilisez les conseils suivants pour identifier vos cas d’usage.
- Identifiez et analysez vos cas d’utilisation actuels par menace, système d’exploitation, produit, etc.
- Quelle est l’étendue ? Voulez-vous migrer tous les cas d’usage ou utiliser certains critères de priorité ?
- Identifiez les ressources de sécurité les plus critiques pour votre migration.
- Quels sont les cas d’usage efficaces ? Un bon point de départ consiste à examiner les détections qui ont produit des résultats au cours de la dernière année (faux positifs par rapport au taux de positifs).
- Quelles sont les priorités métier qui affectent la migration des cas d’usage ? Quels sont les plus grands risques pour votre entreprise ? Quels types de problèmes sont les plus grands risques pour votre entreprise ?
- Définissez des priorités en fonction des caractéristiques des cas d’usage.
- Envisagez de définir des priorités plus basses et plus élevées. Nous vous recommandons de vous concentrer sur les détections qui appliqueraient 90 % de vrais positifs sur les flux d’alertes. Les cas d’usage qui provoquent un taux de faux positifs élevé peuvent être d’une priorité moindre pour votre entreprise.
- Sélectionnez les cas d’usage qui justifient la migration des règles en termes de priorité et d’efficacité métier :
- Passez en revue les règles qui n’ont déclenché aucune alerte au cours des 6 à 12 derniers mois.
- Éliminez les menaces ou les alertes de bas niveau que vous ignorez régulièrement.
- Préparez un processus de validation. Définissez des scénarios de test et créez un script de test.
- Pouvez-vous appliquer une méthodologie pour définir les priorités des cas d’usage ? Vous pouvez suivre une méthodologie comme MoSCoW pour prioriser un ensemble plus restreint de cas d’usage pour la migration.
Étape suivante
Dans cet article, vous avez appris à planifier et à préparer votre migration.