Recommandations pour les tests de sécurité
S’applique à cette recommandation de liste de contrôle de sécurité Azure Well-Architected Framework :
| SE :11 | Établissez un schéma de test complet qui combine des approches pour prévenir les problèmes de sécurité, valider les implémentations de 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 la sécurité. Le test est une forme tactique de validation qui permet de s’assurer que les contrôles fonctionnent comme prévu. Les tests sont également un moyen proactif de détecter les vulnérabilités dans le système.
Établissez la rigueur des tests par le biais de la cadence et de la vérification à partir de plusieurs perspectives. Vous devez inclure des points de vue intérieurs qui testent la plateforme et l’infrastructure, et des évaluations externes 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. Implémentez 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 |
|---|---|
| Test de sécurité des applications (AST) | Technique Microsoft Security Development Lifecycle (SDL) qui utilise des méthodologies de test de boîte blanche et de boîte noire pour case activée pour les failles de sécurité dans le code. |
| Test de boîte noire | Méthodologie de test qui valide le comportement de l’application visible en externe sans connaître les éléments internes du système. |
| Équipe bleue | Une équipe qui se défend contre les attaques de l’équipe rouge dans un exercice de jeu de guerre. |
| Test de pénétration | Méthodologie de test qui utilise des techniques de piratage éthiques pour valider les défenses de sécurité d’un système. |
| Équipe rouge | Une équipe qui joue le rôle d’un adversaire et tente de pirater le système dans un exercice de jeu de guerre. |
| Security Development Lifecycle (SDL) | Ensemble de pratiques fournies par Microsoft qui prend en charge les exigences d’assurance et de conformité de sécurité. |
| Cycle de vie du développement logiciel (SDLC) | Processus systématique et multiphase pour le développement de systèmes logiciels. |
| Test en boîte blanche | Méthodologie de test dans laquelle la structure du code est connue du praticien. |
Stratégies de conception
Le test est une stratégie non négociable, en particulier pour la sécurité. Il vous permet 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 implémentés fonctionnent comme prévu.
L’étendue des tests doit inclure l’application, l’infrastructure et les processus automatisés et humains.
Notes
Ce guide fait une distinction entre le test et la réponse aux incidents. Bien que le test soit un mécanisme de détection qui résout idéalement les problèmes avant la production, il ne doit pas être confondu avec la correction ou l’investigation effectuée dans le cadre de la réponse aux incidents. L’aspect de la récupération suite à des incidents de sécurité est décrit dans Recommandations de réponse aux incidents.
SDL inclut plusieurs types de tests qui interceptent les vulnérabilités dans le code, vérifient les composants d’exécution et utilisent le piratage éthique pour tester la résilience de sécurité du système. SDL est une activité clé de décalage vers la gauche. Vous devez exécuter des tests tels que l’analyse statique du code et l’analyse automatisée de l’infrastructure en tant que code (IaC) le plus tôt possible dans le processus de développement.
Participez à la planification des tests. L’équipe de charge de travail peut ne pas concevoir les cas de test. Cette tâche est souvent centralisée dans l’entreprise ou effectuée par des experts en sécurité externes. L’équipe de charge de travail doit être impliquée dans ce processus de conception pour s’assurer 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 hiérarchiser les tests en conséquence.
Exécutez les tests de manière structurée et avec un processus reproductible. Développez votre rigueur de test autour de la cadence, des types de tests, des facteurs moteurs et des résultats prévus.
Utilisez l’outil approprié pour le travail. 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. Tirez parti de l’expertise et des outils offerts par les équipes SecOps centrales ou par des moyens externes si l’équipe de charge de travail n’a pas cette expertise.
Configurez des environnements distincts. Les tests peuvent être classés comme destructeurs ou non destructeurs. Les tests non destructeurs ne sont pas invasifs. Ils indiquent qu’il y a un problème, mais ils ne modifient pas les fonctionnalités afin de corriger le problème. Les tests de destruction sont invasifs et peuvent endommager les fonctionnalités en supprimant des données d’une base de données.
Les tests dans les environnements de production vous donnent les meilleures informations, mais provoquent le plus d’interruption. Vous avez tendance à effectuer uniquement des tests non destructeurs dans les environnements de production. Les tests dans des environnements hors production sont généralement moins perturbants, mais peuvent ne pas représenter avec précision la configuration de l’environnement de production d’une manière qui est importante pour la sécurité.
Si vous effectuez un déploiement à l’aide de l’IaC et de l’automatisation, déterminez si vous pouvez créer un clone isolé de votre environnement de production à des fins de test. Si vous avez un processus continu pour les tests de routine, nous vous recommandons d’utiliser un environnement dédié.
Évaluez toujours les résultats des tests. Le test est un effort inutile si les résultats ne sont pas utilisés pour hiérarchiser les actions et apporter des améliorations amont. Documentez les instructions de sécurité, y compris les meilleures pratiques, que vous découvrez. La documentation qui capture les résultats et les plans de correction informe l’équipe des différentes façons dont les attaquants peuvent tenter d’enfreindre la sécurité. Effectuez une formation régulière 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 s’exécute et comment cela affecte-t-il votre environnement ?
Quels sont les différents types de tests que vous devez exécuter ?
À quelle fréquence vous attendez-vous à ce que les tests s’exécutent ?
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égressions. 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 d’exploitation standard et pour répondre aux exigences de conformité. Différents tests peuvent être exécutés à des cadences différentes, mais la clé est qu’ils sont effectués régulièrement et selon une planification.
Vous devez intégrer ces tests dans votre SDLC, car ils fournissent une défense en profondeur à chaque étape. Diversifiez la suite de tests pour vérifier les garanties relatives à l’identité, au stockage et à la transmission des données, ainsi qu’aux 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égressions. Les tests de routine permettent d’établir un point de référence initial. Mais ce n’est qu’un point de départ. Lorsque vous découvrez de nouveaux problèmes aux mêmes points du cycle de vie, vous ajoutez de nouveaux cas 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 qui ont été modifiés afin de détecter l’impact de ces modifications sur la sécurité. Vous devez améliorer l’efficacité des tests avec l’automatisation, en équilibre avec les évaluations par les pairs.
Envisagez d’exécuter des tests de sécurité dans le cadre d’un pipeline automatisé ou d’une série de tests planifiée. Plus tôt vous découvrirez des 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 à des tests automatisés. Utilisez des tests manuels pour détecter les vulnérabilités que seule l’expertise humaine peut intercepter. Les tests manuels sont adaptés aux cas d’usage exploratoires et à la recherche de risques inconnus.
Tests improvisés
Les tests improvisés fournissent une validation dans le temps des défenses de sécurité. Les alertes de sécurité susceptibles d’affecter la charge de travail à ce moment déclenchent ces tests. Les mandats organisationnels peuvent nécessiter une mentalité de pause et de test pour vérifier l’efficacité des stratégies de défense si l’alerte dégénère en urgence.
L’avantage des tests improvisés est la préparation à un incident réel. Ces tests peuvent être une fonction forçante à effectuer des tests d’acceptation utilisateur (UAT).
L’équipe de sécurité peut auditer toutes les charges de travail et exécuter ces tests en fonction des besoins. En tant que propriétaire de charge de travail, vous devez faciliter et collaborer avec les équipes de sécurité. Négociez suffisamment de temps avec les équipes de sécurité pour vous préparer. Reconnaissez et communiquez à votre équipe et aux parties prenantes que ces interruptions 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 : étant donné que les tests improvisés sont des événements perturbants, attendez-vous à redimensionné les tâches, ce qui peut retarder d’autres travaux planifiés.
Risque : Il existe un risque d’inconnu. Les tests improvisés peuvent être des efforts ponctuels sans processus ou outils établis. Mais le risque prédominant est l’interruption potentielle du rythme des affaires. Vous devez évaluer ces risques par rapport aux avantages.
Tests d’incident 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 vous assurer que l’incident ne se répète 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 les 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 les contrôles de compensation.
Configurations incorrectes.
Lacunes dans les méthodes d’observabilité et de détection.
Un bon exercice de modélisation des menaces peut pointer vers 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 la sécurisation d’un cycle de vie de développement.
La plupart des tests décrits dans ces sections peuvent être exécutés en tant que tests de routine. Toutefois, la répétabilité peut entraîner des coûts dans certains cas et entraîner une interruption. Réfléchissez soigneusement à ces compromis.
Tests qui valident la pile technologique
Voici quelques exemples de types de tests et leurs domaines d’intérêt. Cette liste n’est pas exhaustive. Testez l’ensemble de la pile, y compris la pile d’applications, le front-end, le serveur principal, 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 vous assurer 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écurisé vers la charge de travail.
Application : testez le code source par le biais de techniques de test de sécurité des applications (AST) pour vous assurer que vous suivez les pratiques de codage sécurisées et pour intercepter les erreurs d’exécution telles que l’altération de la mémoire et les problèmes de privilèges. Pour plus d’informations, consultez ces liens de communauté.
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 la chasse aux menaces en simulant des attaques réelles. Ils peuvent identifier les acteurs de menace potentiels, 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 menace potentiels que vous identifiez lors de la modélisation des menaces.
Voici quelques avantages des tests par le biais d’attaques réelles :
Lorsque vous faites de ces attaques une partie des tests de routine, vous utilisez une perspective extérieure pour case activée la charge de travail et vous assurer que la défense peut résister à une attaque.
En fonction des leçons qu’elle a apprises, l’équipe améliore ses connaissances et son niveau de compétence. L’équipe améliore la connaissance de la situation et peut évaluer elle-même sa préparation pour répondre aux incidents.
Parmi les exemples de tests simulés, citons les tests en boîte noire et en boîte blanche, les tests d’intrusion et les exercices de jeu de guerre.
Test des boîtes noires et des boîtes blanches
Ces types de tests offrent deux perspectives différentes. Dans les tests de boîte noire, les éléments internes du système ne sont pas visibles. Dans les tests de zone blanche, le testeur a une bonne compréhension de l’application et a même accès au code, aux journaux, à la topologie de ressources et aux configurations pour mener l’expérience.
Tests qui simulent des attaques par le biais de tests d’intrusion
Les experts en sécurité qui ne font pas partie des équipes informatiques ou d’applications du organization effectuent des tests d’intrusion ou des pentesting. Ils examinent le système de la façon dont les acteurs malveillants étenduent une surface d’attaque. Leur objectif est de trouver les failles de sécurité en recueillant des informations, en analysant les vulnérabilités et en rapportant les résultats.
Les praticiens peuvent avoir besoin d’accéder aux données sensibles dans l’ensemble de l’organization. Suivez les règles d’engagement pour vous assurer que l’accès n’est pas utilisé à mauvais escient. Consultez les ressources répertoriées dans Liens connexes.
Tests qui simulent des attaques par le biais d’exercices de jeu de guerre
Dans cette méthodologie d’attaques simulées, il existe deux équipes :
L’équipe rouge est l’adversaire qui tente de modéliser des attaques réelles. S’ils réussissent, vous détectez des lacunes dans votre conception de sécurité et évaluez l’endiguement du rayon d’explosion de leurs violations.
L’équipe bleue est l’équipe de charge de travail qui se défend contre les attaques. Ils testent leur capacité à détecter, répondre et corriger les attaques. Ils valident les défenses qui ont été implémentées pour protéger les ressources de charge de travail.
S’ils sont effectués en tant que tests de routine, les exercices de jeu de guerre peuvent fournir une visibilité continue et l’assurance que vos défenses fonctionnent comme prévu. Les exercices de jeu de guerre peuvent potentiellement être testés sur plusieurs niveaux au sein de vos charges de travail.
Le Exercice de simulation d'attaque Microsoft Defender pour Office 365 est un choix courant pour simuler des scénarios d’attaque réalistes.
Pour plus d’informations, consultez Insights et rapports pour Exercice de simulation d'attaque.
Pour plus d’informations sur la configuration de l’équipe rouge et de l’équipe bleue, consultez Microsoft Cloud Red Teaming.
Animation Azure
Microsoft Sentinel est un contrôle natif qui combine des fonctionnalités SIEM (Security Information Event Management) et SOAR (Security Orchestration Automated Response). Il analyse les événements et les journaux issus de différentes sources connectées. En fonction des sources de données et de leurs alertes, Microsoft Sentinel crée des incidents et effectue une analyse des menaces pour une détection précoce. Grâce à des analyses et des requêtes intelligentes, vous pouvez rechercher de manière proactive les problèmes de sécurité. En cas d’incident, vous pouvez automatiser les workflows. En outre, avec les modèles de classeur, vous pouvez rapidement obtenir des insights grâce à la visualisation.
Pour obtenir la documentation du produit, consultez Fonctionnalités de chasse dans Microsoft Sentinel.
Microsoft Defender for Cloud offre une analyse des vulnérabilités pour différents domaines technologiques. Pour plus d’informations, consultez Activer l’analyse des vulnérabilités avec Gestion des vulnérabilités Microsoft Defender - Microsoft Defender pour le cloud.
La pratique de DevSecOps intègre les tests de sécurité dans le cadre d’une mentalité d’amélioration continue et continue. Les exercices de jeu de guerre sont une pratique courante intégrée au rythme des affaires chez Microsoft. Pour plus d’informations, consultez Sécurité dans DevOps (DevSecOps).
Azure DevOps prend en charge des outils tiers qui peuvent être automatisés dans le cadre des pipelines d’intégration continue/déploiement continu. Pour plus d’informations, consultez Activer DevSecOps avec Azure et GitHub - Azure DevOps.
Liens connexes
Suivez les règles d’engagement pour vous assurer que l’accès n’est pas mal utilisé. Pour obtenir des conseils sur la planification et l’exécution d’attaques simulées, consultez les articles suivants :
Vous pouvez simuler des attaques par déni de service (DoS) dans Azure. Veillez à suivre les stratégies décrites dans les tests de simulation Azure DDoS Protection.
Liens de la communauté
Test de sécurité des applications : outils, types et meilleures pratiques : GitHub Resources décrit les types de méthodologies de test qui peuvent tester les défenses au moment de la génération et du runtime de l’application.
Penetration Testing Execution Standard (PTES) fournit des instructions sur les scénarios courants et les activités requises pour établir une base de référence.
OWASP Top Ten | OWASP Foundation fournit les meilleures pratiques de sécurité pour les applications et les cas de test qui couvrent les menaces courantes.
Liste de contrôle de sécurité
Reportez-vous à l’ensemble complet de recommandations.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour