Recommandations pour les tests de sécurité
S’applique à cette recommandation de liste de contrôle Sécurité Power Platform Well-Architected :
| SE:09 | Établissez un programme de tests complet qui combine des approches pour prévenir les problèmes de sécurité, valider les mises en œuvre de la prévention des menaces et tester les mécanismes de détection des menaces. |
|---|
Des tests rigoureux constituent la base d’une bonne conception de sécurité. Les tests sont une forme tactique de validation pour garantir que les contrôles fonctionnent comme prévu. Les tests constituent également un moyen proactif de détecter les vulnérabilités du système.
Établissez la rigueur des tests grâce à la cadence et à la vérification sous plusieurs perspectives. Vous devez inclure des points de vue de l’intérieur vers l’extérieur qui testent la plate-forme et l’infrastructure, ainsi que des évaluations de l’extérieur vers l’intérieur qui testent le système comme un attaquant externe.
Ce guide fournit des recommandations pour tester la posture de sécurité de votre charge de travail. Mettez en œuvre ces méthodes de test pour améliorer la résistance de votre charge de travail aux attaques et maintenir la confidentialité, l’intégrité et la disponibilité des ressources.
Définitions
| Terme | Définition |
|---|---|
| Tests de la sécurité des applications (AST) | Technique du cycle de vie de développement de la sécurité Microsoft qui utilise des méthodologies de test boîte blanche et boîte noire pour vérifier les vulnérabilités de sécurité dans le code. |
| Tests en boîte noire | Méthodologie de test qui valide le comportement de l’application visible de l’extérieur sans connaissance des composants internes du système. |
| Équipe bleue | Équipe qui se défend contre les attaques de l’équipe rouge lors d’un exercice de jeu de guerre. |
| Test d’intrusion | Méthodologie de test qui utilise des techniques de piratage éthique pour valider les défenses de sécurité d’un système. |
| Équipe rouge | Équipe qui joue le rôle d’un adversaire et tente de pirater le système dans un exercice de jeu de guerre. |
| Cycle de vie du développement de la sécurité | Ensemble de pratiques fournies par Microsoft qui prennent en charge les exigences d’assurance de la sécurité et de conformité. |
| Cycle de vie du développement logiciel | Processus systématique et en plusieurs étapes pour développer des systèmes logiciels. |
| Tests en boîte blanche | Méthodologie de test où la structure du code est connue du praticien. |
Stratégies de conception clés
Les tests sont une stratégie non négociable, notamment pour la sécurité. Ils vous permettent de découvrir et de résoudre de manière proactive les problèmes de sécurité avant qu’ils ne puissent être exploités et de vérifier que les contrôles de sécurité que vous avez mis en œuvre fonctionnent comme prévu.
La portée des tests doit inclure l’application, l’infrastructure et les processus automatisés et humains.
Note
Ces lignes directrices font une distinction entre les tests et la réponse aux incidents. Bien que les tests soient un mécanisme de détection qui résout idéalement les problèmes avant la production, ils ne doivent pas être confondus avec la remédiation ou l’enquête effectuée dans le cadre de la réponse aux incidents. L’aspect de la récupération après des incidents de sécurité est décrit dans les Recommandations pour la réponse aux incidents de sécurité.
Soyez impliqué dans la planification des tests. L’équipe chargée de la charge de travail peut ne pas concevoir les cas de test. Cette tâche est souvent centralisée au sein de l’entreprise ou réalisée par des experts en sécurité externes. L’équipe chargée de la charge de travail doit être impliquée dans ce processus de conception pour garantir que les garanties de sécurité s’intègrent aux fonctionnalités de l’application.
Pensez comme un attaquant. Concevez vos cas de test en partant du principe que le système a été attaqué. De cette façon, vous pouvez découvrir les vulnérabilités potentielles et prioriser les tests en conséquence.
Exécutez les tests de manière structurée et avec un processus reproductible. Développez la rigueur de vos tests autour de la cadence, des types de tests, des facteurs déterminants et des résultats attendus.
Utilisez l’outil adéquat pour la tâche. Utilisez des outils configurés pour fonctionner avec la charge de travail. Si vous n’avez pas d’outil, achetez l’outil. Ne le créez pas. Les outils de sécurité sont hautement spécialisés et la création de votre propre outil peut présenter des risques. Profitez de l’expertise et des outils offerts par les équipes SecOps centrales ou par des moyens externes si l’équipe chargée de la charge de travail ne possède pas cette expertise.
Configurez des environnements distincts. Les tests peuvent être classés comme destructifs ou non destructifs. Les tests non destructifs ne sont pas invasifs. Ils indiquent qu’il y a un problème, mais ils ne modifient pas la fonctionnalité afin de résoudre le problème. Les tests destructifs sont invasifs et peuvent endommager les fonctionnalités en supprimant des données d’une base de données.
Les tests dans des environnements de production vous fournissent les meilleures informations, mais provoquent le plus de perturbations. Vous avez tendance à effectuer uniquement des tests non destructifs dans des environnements de production. Les tests dans des environnements hors production sont généralement moins perturbateurs, mais peuvent ne pas représenter avec précision la configuration de l’environnement de production d’une manière importante pour la sécurité.
Vous pouvez créer un clone isolé de votre environnement de production à l’aide de la fonctionnalité de copie d’environnement. Si vous avez configuré des pipelines de déploiement, vous pouvez également déployer vos solutions dans un environnement de test dédié.
Évaluez toujours les résultats des tests. Les tests sont un effort inutile si les résultats ne sont pas utilisés pour prioriser les actions et apporter des améliorations en amont. Documentez les directives de sécurité, y compris les meilleures pratiques, que vous découvrez. La documentation qui capture les résultats et les plans de remédiation informe l’équipe sur les différentes manières dont les attaquants pourraient tenter de violer la sécurité. Organisez régulièrement des formations sur la sécurité pour les développeurs, les administrateurs et les testeurs.
Lorsque vous concevez vos plans de test, réfléchissez aux questions suivantes :
- À quelle fréquence prévoyez-vous que le test soit exécuté et quel est son impact sur votre environnement ?
- Quels sont les différents types de tests que vous devez effectuer ?
À quelle fréquence prévoyez-vous que les tests soient exécutés ?
Testez régulièrement la charge de travail pour vous assurer que les modifications n’introduisent pas de risques de sécurité et qu’il n’y a pas de régression. L’équipe doit également être prête à répondre aux validations de sécurité organisationnelles qui peuvent être effectuées à tout moment. Il existe également des tests que vous pouvez exécuter en réponse à un incident de sécurité. Les sections suivantes fournissent des recommandations sur la fréquence des tests.
Tests de routine
Les tests de routine sont effectués à une cadence régulière, dans le cadre de vos procédures opérationnelles standard et pour répondre aux exigences de conformité. Divers tests peuvent être exécutés à différentes cadences, mais l’essentiel est qu’ils soient effectués périodiquement et selon un calendrier.
Vous devez intégrer ces tests dans votre cycle de vie de développement logiciel, car ils assurent une défense en profondeur à chaque étape. Diversifiez la suite de tests pour vérifier les garanties d’identité, de stockage et de transmission des données, ainsi que les canaux de communication. Effectuez les mêmes tests à différents moments du cycle de vie pour vous assurer qu’il n’y a pas de régression. Les tests de routine permettent d’établir une première référence. Cependant, ce n’est qu’un point de départ. À mesure que vous découvrez de nouveaux problèmes aux mêmes étapes du cycle de vie, vous ajoutez de nouveaux scénarios de test. Les tests s’améliorent également avec la répétition.
À chaque étape, ces tests doivent valider le code ajouté ou supprimé ou les paramètres de configuration modifiés afin de détecter l’impact de ces modifications sur la sécurité. Vous devez améliorer l’efficacité des tests grâce à l’automatisation, équilibrée par des évaluations par les pairs.
Envisagez d’exécuter des tests de sécurité dans le cadre d’un pipeline automatisé ou d’une exécution de tests planifiée. Plus tôt vous découvrez les problèmes de sécurité, plus il est facile de trouver le code ou la modification de configuration qui les provoque.
Ne vous fiez pas uniquement aux tests automatisés. Utilisez des tests manuels pour détecter les vulnérabilités que seule l’expertise humaine peut détecter. Les tests manuels sont utiles pour les cas d’utilisation exploratoires et pour détecter des risques inconnus.
Tests improvisés
Des tests improvisés permettent une validation ponctuelle des défenses de sécurité. Les alertes de sécurité susceptibles d’affecter la charge de travail à ce moment-là déclenchent ces tests. Les mandats organisationnels peuvent nécessiter un état d’esprit de pause et de test pour vérifier l’efficacité des stratégies de défense si l’alerte se transforme en urgence.
L’avantage des tests improvisés est la préparation à un incident réel. Ces tests peuvent être une fonction obligeant à effectuer des tests d’acceptation utilisateur (UAT).
L’équipe de sécurité peut auditer toutes les charges de travail et exécuter ces tests si nécessaire. En tant que propriétaire de charge de travail, vous devez faciliter et collaborer avec les équipes de sécurité. Négociez suffisamment de délais avec les équipes de sécurité pour pouvoir vous préparer. Reconnaissez et communiquez à votre équipe et aux parties prenantes que ces perturbations sont nécessaires.
Dans d’autres cas, vous devrez peut-être exécuter des tests et signaler l’état de sécurité du système par rapport à la menace potentielle.
Compromis : parce que les tests improvisés sont des événements gênants, attendez-vous à donner une nouvelle priorité aux tâches, qui peuvent reporter un autre travail planifié.
Risque : il y a un risque de l’inconnu. Les tests improvisés peuvent être des efforts ponctuels sans processus ou outils établis. Mais le risque prédominant est l’éventuelle interruption du rythme des affaires. Vous devez évaluer ces risques par rapport aux avantages.
Tests d’incidents de sécurité
Il existe des tests qui détectent la cause d’un incident de sécurité à sa source. Ces failles de sécurité doivent être résolues pour garantir que l’incident ne se reproduise pas.
Les incidents améliorent également les cas de test au fil du temps en révélant les lacunes existantes. L’équipe doit appliquer les leçons tirées de l’incident et intégrer régulièrement des améliorations.
Quels sont les différents types de tests ?
Les tests peuvent être classés par technologie et par méthodologies de test. Combinez ces catégories et approches au sein de ces catégories pour obtenir une couverture complète.
En ajoutant plusieurs tests et types de tests, vous pouvez découvrir :
- Lacunes dans les contrôles de sécurité ou contrôles compensatoires.
- Configurations incorrectes.
- Lacunes dans les méthodes d’observabilité et de détection.
Un bon exercice de modélisation des menaces peut identifier des domaines clés pour garantir la couverture et la fréquence des tests. Pour obtenir des recommandations sur la modélisation des menaces, consultez Recommandations pour sécuriser un cycle de vie de développement.
La plupart des tests décrits dans ces sections peuvent être exécutés comme des tests de routine. Cependant, la répétabilité peut dans certains cas entraîner des coûts et provoquer des perturbations. Considérez attentivement ces compromis.
Des tests qui valident la pile technologique
Voici quelques exemples de types de tests et leurs domaines d’intervention. Cette liste n’est pas exhaustive. Testez l’ensemble de la pile, y compris la pile d’applications, le front-end, le back-end, les API, les bases de données et toutes les intégrations externes.
- Sécurité des données : testez l’efficacité du chiffrement des données et des contrôles d’accès pour garantir que les données sont correctement protégées contre tout accès non autorisé et toute falsification.
- Réseau et connectivité : testez vos pare-feu pour vous assurer qu’ils autorisent uniquement le trafic attendu, autorisé et sûr vers la charge de travail.
- Application : testez le code source via des techniques de tests de sécurité des applications (AST) pour vous assurer que vous suivez des pratiques de codage sécurisées et pour détecter les erreurs d’exécution telles que la corruption de la mémoire et les problèmes de privilèges.
- Identité : évaluez si les attributions de rôles et les vérifications conditionnelles fonctionnent comme prévu.
Méthodologie de test
Il existe de nombreuses perspectives sur les méthodologies de test. Nous recommandons des tests qui permettent de traquer les menaces en simulant des attaques réelles. Ils peuvent identifier les acteurs potentiels de la menace, leurs techniques et leurs exploits qui constituent une menace pour la charge de travail. Rendez les attaques aussi réalistes que possible. Utilisez tous les vecteurs de menaces potentiels que vous identifiez lors de la modélisation des menaces.
Voici quelques avantages des tests via des attaques réelles :
- Lorsque vous intégrez ces attaques à des tests de routine, vous utilisez une perspective extérieure pour vérifier la charge de travail et vous assurer que la défense peut résister à une attaque.
- Sur la base des leçons apprises, l’équipe améliore ses connaissances et son niveau de compétence. L’équipe améliore sa connaissance de la situation et peut auto-évaluer son état de préparation à répondre aux incidents.
Quelques exemples de tests simulés incluent les tests en boîte noire et en boîte blanche, les tests d’intrusion et les exercices de jeux de guerre.
Tests en boîte noire et en boîte blanche
Ces types de tests offrent deux perspectives différentes. Dans les tests en boîte noire, les composants internes du système ne sont pas visibles. Dans les tests en boîte blanche, le testeur a une bonne compréhension de l’application et a même accès au code, aux journaux, à la topologie des ressources et aux configurations pour mener l’expérience.
Tests qui simulent des attaques grâce à des tests d’intrusion
Les experts en sécurité qui ne font pas partie des équipes informatiques ou applicatives de l’organisation effectuent des tests d’intrusion, ou pentesting. Ils examinent le système de la manière dont les acteurs malveillants ciblent un périmètre d’attaque. Leur objectif est de détecter les failles de sécurité en collectant des informations, en analysant les vulnérabilités et en rendant compte des résultats.
Les praticiens pourraient avoir besoin d’accéder à des données sensibles dans l’ensemble de l’organisation. Suivez les règles d’engagement pour garantir que l’accès n’est pas utilisé à mauvais escient. Voir les ressources répertoriées dans Voir également.
Tests qui simulent des attaques grâce à des exercices de jeux de guerre
Dans cette méthodologie d’attaques simulées, il y a deux équipes :
- L’équipe rouge est l’adversaire qui tente de modéliser des attaques du monde réel. S’ils réussissent, vous identifiez des lacunes dans votre conception de sécurité et évaluez le confinement du rayon d’explosion de leurs brèches.
- L’équipe bleue est l’équipe chargée de la charge de travail qui se défend contre les attaques. Ils testent leur capacité à détecter, répondre et remédier aux attaques. Ils valident les défenses qui ont été mises en œuvre pour protéger les ressources de la charge de travail.
S’ils sont menés sous forme de tests de routine, les exercices de jeux de guerre peuvent fournir une visibilité continue et l’assurance que vos défenses fonctionnent comme prévu. Les exercices de jeux de guerre peuvent potentiellement tester tous les niveaux de vos charges de travail.
Un choix populaire pour simuler des scénarios d’attaque réalistes est Microsoft Defender pour Office 365 Formation à la simulation d’attaque.
Pour plus d’informations, voir Informations et rapports sur la formation relative à la simulation d’attaque.
Pour plus d’informations sur la configuration des équipes rouge et bleue, voir Microsoft Cloud Red Teaming.
Facilitation de Power Platform
Solution Microsoft Sentinel pour Microsoft Power Platform permet aux clients de détecter diverses activités suspectes, telles que :
- Power Apps exécution à partir de zones géographiques non autorisées
- Destruction de données suspectes par Power Apps
- Suppression massive de Power Apps
- Attaques de phishing effectuées via Power Apps
- Power Automate flux d’activité des salariés qui partent
- Microsoft Power Platform Connecteurs ajoutés dans l’environnement
- Mettre à jour ou supprimer les stratégies de protection contre la perte de données Microsoft Power Platform
Pour plus d’informations, consultez la solution Microsoft Sentinel pour Microsoft Power Platform présentation.
Pour la documentation du produit, voir Capacités de chasse dans Microsoft Sentinel.
Microsoft Defender for Cloud propose une analyse des vulnérabilités pour divers domaines technologiques. Pour plus d’informations, voir Activer l’analyse des vulnérabilités avec Microsoft Defender Vulnerability Management.
La pratique du DevSecOps intègre les tests de sécurité dans le cadre d’un état d’esprit d’amélioration continue. Les exercices de jeux de guerre sont une pratique courante intégrée au rythme des affaires chez Microsoft. Pour en savoir plus, consultez la rubrique Sécurité dans DevOps (DevSecOps).
Azure DevOps prend en charge les outils tiers qui peuvent être automatisés dans le cadre des pipelines d’intégration continue/déploiement continu (CI/CD). Pour plus d’informations, voir Activer DevSecOps avec Azure et GitHub.
Voir aussi
Les derniers tests de pénétration et les dernières évaluations de sécurité sont disponibles sur le Portail d’approbation de services Microsoft.
Microsoft effectue des tests approfondis des services de cloud computing Microsoft. Ces tests incluent des tests d’intrusion, dont les résultats sont publiés sur le Service Trust Portal de votre organisation. Votre organisation peut effectuer votre propre test d’intrusion sur les services Microsoft Power Platform et Microsoft Dynamics 365. Tous les tests d’intrusion doivent suivre les règles d’engagement de Microsoft Cloud relatives aux tests d’intrusion. Il est important de rappeler que dans de nombreux cas, Microsoft Cloud utilise une infrastructure partagée pour héberger vos actifs et ceux appartenant à d’autres clients. Vous devez limiter tous les tests d’intrusion à vos actifs et éviter des conséquences inattendues pour les autres clients autour de vous.
Suivez les règles d’engagement pour garantir que l’accès n’est pas utilisé à mauvais escient. Pour obtenir des conseils sur la planification et l’exécution d’attaques simulées, consultez :
Vous pouvez simuler des attaques par déni de service (DoS) dans Azure. Assurez-vous de suivre les politiques énoncées dans les tests de simulation Azure DDoS Protection.
Liste de contrôle de sécurité
Référez-vous à l’ensemble complet des recommandations.
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour