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.
Les équipes du centre des opérations de sécurité (SOC) utilisent des solutions SIEM (Security Information and Event Management) centralisées et des solutions d’orchestration, d’automatisation et de réponse 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, telles que dans Azure, Microsoft 365, AWS ou Google Cloud Platform (GCP). En revanche, Microsoft Sentinel pouvez ingérer des données à partir de ressources locales et cloud, ce qui garantit une couverture sur l’ensemble du patrimoine.
Cet article décrit les raisons de la migration à partir d’une solution SIEM héritée et explique comment planifier les différentes phases de votre migration.
Étapes de 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, dans lesquels vous allez apprendre à parcourir les différentes étapes du processus.
Remarque
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, notamment des conseils sur les meilleures pratiques, des ressources et une aide d’experts à chaque étape. Pour en savoir plus, contactez votre équipe de compte.
Qu’est-ce que Azure Sentinel ?
Microsoft Sentinel est une solution native cloud évolutive, de gestion des informations et des événements de sécurité (SIEM) et d’orchestration, d’automatisation et de réponse de sécurité (SOAR). Microsoft Sentinel fournit des analyses de sécurité intelligentes et des informations sur les menaces au sein de l’entreprise. Microsoft Sentinel fournit une solution unique pour la détection des attaques, la visibilité des menaces, la chasse proactive et la réponse aux menaces. En savoir plus sur Microsoft Sentinel.
Pourquoi migrer à partir d’un SIEM hérité ?
Les équipes SOC sont confrontées à un ensemble de défis lors de la gestion d’un SIEM hérité :
- Réponse lente aux menaces. Les SIEM hérités utilisent des règles de corrélation, qui sont difficiles à gérer et 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 élevés. L’analyse de ces données ralentit les équipes SOC dans leurs efforts pour répondre aux menaces critiques dans l’environnement.
- Défis de mise à l’échelle. À mesure que les taux 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 des organization, les équipes SOC doivent investir dans la configuration et la maintenance de l’infrastructure, et sont liées par des limites de stockage ou de requête.
- 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és et les 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 siem et diverses sources de données, et effectuent des mises à jour et des correctifs. Ces tâches sont souvent au détriment du triage et de l’analyse critiques.
Une solution SIEM native cloud répond à ces défis. Microsoft Sentinel collecte des données automatiquement et à grande échelle, détecte les menaces inconnues, examine les menaces avec l’intelligence artificielle et répond rapidement aux incidents avec l’automatisation intégrée.
Planifier la migration
Pendant la phase de planification, vous identifiez vos composants SIEM existants, vos processus SOC existants, puis vous concevez et 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, telles que Microsoft Office 365.
Ce diagramme décrit les phases générales qu’une migration classique inclut. Chaque phase comprend des objectifs clairs, des activités clés et des résultats et livrables spécifiés.
Les phases de ce diagramme sont des instructions pour effectuer une procédure de migration classique. Une migration réelle peut ne pas inclure certaines phases ou peut inclure d’autres phases. Au lieu d’examiner l’ensemble complet des phases, les articles de ce guide passent en revue les tâches et étapes spécifiques qui sont particulièrement importantes pour une migration Microsoft Sentinel.
Considérations
Passez en revue ces considérations clés pour chaque phase.
| Phase | Considération |
|---|---|
| Découvrir | 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 Microsoft Sentinel. Vous utiliserez ces informations pour obtenir l’approbation des parties prenantes concernées avant de commencer la phase d’implémentation. |
| Implémenter | Lorsque vous implémentez Microsoft Sentinel composants en fonction de la phase de conception et avant de convertir l’ensemble de votre infrastructure, déterminez si vous pouvez utiliser Microsoft Sentinel contenu prête à l’emploi 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. À mesure que vous ajoutez d’autres cas d’usage, vous pouvez utiliser cette Microsoft Sentinel instance comme environnement de test d’acceptation utilisateur (UAT) pour valider les cas d’usage. |
| Opérationnaliser | Vous migrez votre contenu et vos processus SOC pour vous assurer que l’expérience d’analyste existante n’est pas interrompue. |
Identifier vos priorités de migration
Utilisez ces questions pour identifier vos priorités de migration :
- Quels sont les composants, systèmes, applications et données d’infrastructure les plus critiques de votre entreprise ?
- Qui sont vos parties prenantes dans la migration ? La migration SIEM est susceptible de toucher de nombreux domaines de votre entreprise.
- Qu’est-ce qui détermine vos priorités ? Par exemple, les risques les plus importants pour l’entreprise, les exigences de conformité, les priorités métier, etc.
- Quelles sont votre mise à l’échelle et votre chronologie de migration ? Quels sont les facteurs qui affectent vos dates et échéances. Migrez-vous l’intégralité d’un système hérité ?
- Avez-vous les compétences dont vous avez besoin ? Votre personnel de sécurité est-il formé et prêt pour la migration ?
- Existe-t-il des bloqueurs spécifiques dans votre organization ? Les problèmes affectent-ils la planification et la planification de la migration ? Par exemple, des problèmes tels que les exigences en matière de personnel et de formation, les dates de licence, les arrêts physiques, les besoins spécifiques de l’entreprise, 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 intentionnel et attentif à ce que vous migrez en premier, ce que vous déprioritez et ce qui n’a pas réellement besoin d’être migré. Votre équipe peut avoir un nombre écrasant de détections et de cas d’usage en cours d’exécution dans votre SIEM actuel. Avant de commencer la migration, choisissez celles qui sont activement utiles à votre entreprise.
Identifier les cas d’usage
Lorsque vous planifiez la phase de découverte, utilisez les conseils suivants pour identifier vos cas d’usage.
- Identifiez et analysez vos cas d’usage 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 hiérarchisation ?
- Identifiez les ressources de sécurité les plus critiques pour votre migration.
- Quels cas d’usage sont 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 (taux de faux positifs par rapport au taux positif).
- Quelles sont les priorités métier qui affectent la migration des cas d’usage ? Quels sont les risques les plus importants pour votre entreprise ? Quels types de problèmes mettent votre entreprise le plus en danger ?
- Hiérarchiser par caractéristiques de cas d’usage.
- Envisagez de définir des priorités plus faibles et plus élevées. Nous vous recommandons de vous concentrer sur les détections qui appliqueraient 90 % de vrais positifs sur les flux d’alerte. Les cas d’usage qui entraînent un taux élevé de faux positifs peuvent être une priorité inférieure pour votre entreprise.
- Sélectionnez les cas d’usage qui justifient la migration des règles en termes de priorité métier et d’efficacité :
- Passez en revue les règles qui n’ont déclenché aucune alerte au cours des 6 à 12 derniers mois.
- Éliminez les menaces de bas niveau ou les alertes que vous ignorez régulièrement.
- Préparer un processus de validation. Définissez des scénarios de test et générez un script de test.
- Pouvez-vous appliquer une méthodologie pour hiérarchiser les cas d’usage ? Vous pouvez suivre une méthodologie telle que MoSCoW pour hiérarchiser un ensemble plus léger de cas d’usage pour la migration.
Étape suivante
Dans cet article, vous avez appris à planifier et à préparer votre migration.