Recommandations pour les tests de sécurité
S’applique à cette recommandation de liste de contrôle azure Well-Architected Framework Security :
| SE :11 | Établissez un régime de test complet qui combine des approches permettant d’éviter les problèmes de sécurité, de valider les implémentations de prévention des menaces et de tester les mécanismes de détection des menaces. |
|---|
Les tests rigoureux constituent la base d’une bonne conception de sécurité. Le test est une forme tactique de validation pour vous assurer que les contrôles fonctionnent comme prévu. Le test est é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 internes qui testent la plateforme et l’infrastructure et les é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 sdl (Microsoft Security Development Lifecycle) qui utilise des méthodologies de test de boîte blanche et de zone noire pour vérifier les vulnérabilités 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 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 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 | 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 prennent en charge les exigences de sécurité et de conformité. |
| Cycle de vie du développement logiciel (SDLC) | Processus multisétage et systématique pour le développement de systèmes logiciels. |
| Test de boîte blanche | Méthodologie de test où la structure du code est connue du praticiens. |
Stratégies de conception
Le test est une stratégie non modifiable, en particulier pour la sécurité. Il vous permet de détecter et de résoudre de manière proactive les problèmes de sécurité avant de pouvoir ê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.
Remarque
Ce guide fait une distinction entre le test 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, il ne doit pas être confondu avec la correction ou l’examen qui est effectué dans le cadre de la réponse aux incidents. L’aspect de la récupération des incidents de sécurité est décrit dans les recommandations de réponse aux incidents.
SDL comprend plusieurs types de tests qui interceptent les vulnérabilités dans le code, vérifient les composants du runtime et utilisent le piratage éthique pour tester la résilience de sécurité du système. SDL est une activité de décalage vers la gauche clé. 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) dès que 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 de 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 avec l’hypothèse 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 des tests de manière structurée et avec un processus reproductible. Créez votre rigueur de test autour de la cadence, des types de tests, des facteurs de conduite et des résultats prévus.
Utilisez l’outil approprié pour le travail. Utilisez des outils configurés pour travailler avec la charge de travail. Si vous n’avez pas d’outil, achetez l’outil. Ne le générez 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 existe un problème, mais qu’ils ne modifient pas les fonctionnalités pour corriger le problème. Les tests destructeurs 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 la plus grande perturbation. Vous avez tendance à effectuer uniquement des tests non destructeurs dans des 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 de manière 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 perdu si les résultats ne sont pas utilisés pour hiérarchiser les actions et apporter des améliorations en 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 renseigne l’équipe sur les différentes façons dont les attaquants peuvent tenter de violer la sécurité. Effectuez une formation de sécurité régulière 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 attendez-vous que le test s’exécute et comment cela affecte-t-il votre environnement ?
Quels sont les différents types de test que vous devez exécuter ?
Tester régulièrement la charge de travail
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’existe aucune 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 d’exploitation standard et pour répondre aux exigences de conformité. Différents tests peuvent être exécutés à différentes cadences, mais la clé est qu’elles sont effectuées régulièrement et selon une planification.
Vous devez intégrer ces tests à votre SDLC, car ils fournissent une défense en profondeur à chaque étape. Diversifier la suite de tests pour vérifier les garanties d’identité, de stockage et de transmission des données et des canaux de communication. Effectuez les mêmes tests à différents points du cycle de vie pour vous assurer qu’il n’y a pas de régression. Les tests de routine permettent d’établir un benchmark initial. Mais c’est juste 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 changé pour détecter l’impact de sécurité de ces modifications. Vous devez améliorer l’efficacité des tests avec l’automatisation, équilibrée avec les révisions 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 test planifiée. Plus vous découvrez les problèmes de sécurité plus tôt, plus il est facile de trouver le code ou le changement 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 seules les compétences humaines peuvent 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 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 une mentalité de pause et de test pour vérifier l’efficacité des stratégies de défense si l’alerte devient une urgence.
L’avantage des tests improvisés est la préparation à un véritable incident. 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 d’avance avec les équipes de sécurité afin de pouvoir vous préparer. Reconnaissez et communiquez à votre équipe et à vos 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 contre la menace potentielle.
Compromis : étant donné que les tests improvisés sont des événements perturbants, attendez-vous à réorienter les tâches, ce qui peut retarder d’autres travaux planifiés.
Risque : il y a 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 lacunes de sécurité doivent être résolues pour s’assurer que l’incident n’est pas répété.
Les incidents améliorent également les cas de test au fil du temps en découvrant les lacunes existantes. L’équipe doit appliquer les leçons tirées de l’incident et incorporer régulièrement des améliorations.
Utiliser un large éventail 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 sécuriser 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 provoquer une interruption. Tenez compte de ces compromis avec soin.
Tests qui valident la pile technologique
Voici quelques exemples de types de tests et de domaines de focus. Cette liste n’est pas exhaustive. Testez l’ensemble de la pile, notamment la pile d’applications, le serveur frontal, 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 vous assurer que les données sont correctement protégées contre l’accès non autorisé et la 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 via des 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 les problèmes de corruption de mémoire et de privilèges. Pour plus d’informations, consultez ces liens de la communauté.
Identité : déterminez 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 vous recommandons de tester la chasse aux menaces en simulant des attaques réelles. Ils peuvent identifier les acteurs potentiels des menaces, leurs techniques et leurs exploits qui représentent une menace pour la charge de travail. Rendre 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 de tester par le biais d’attaques réelles :
Lorsque vous effectuez ces attaques dans une partie 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.
En fonction des leçons qu’ils ont apprises, l’équipe met à niveau leurs connaissances et leur niveau de compétence. L’équipe améliore la sensibilisation à la situation et peut évaluer soi-même son état de préparation pour répondre aux incidents.
Certains exemples de tests simulés incluent des tests de boîte noire et de boîte blanche, des tests de pénétration et des exercices de jeu de guerre.
Test de boîte noire et de boîte blanche
Ces types de test offrent deux perspectives différentes. Dans les tests de boîte noire, les 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 des 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 de l’organisation effectuent des tests de pénétration ou des pentes. Ils examinent le système de la façon dont les acteurs malveillants étenduent une surface d’attaque. Leur objectif est de trouver des lacunes de sécurité en collectant des informations, en analysant les vulnérabilités et en signalant les résultats.
Les praticiens peuvent avoir besoin d’accéder à des données sensibles dans l’ensemble de l’organisation. Suivez les règles d’engagement pour vous assurer que l’accès n’est pas mal utilisé. Consultez les ressources répertoriées dans les 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 trouvez des lacunes dans votre conception de sécurité et évaluez l’autonomie 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 conçues. Les exercices de jeu war peuvent potentiellement être testés sur plusieurs niveaux au sein de vos charges de travail.
Un choix populaire pour simuler des scénarios d’attaque réalistes est la Microsoft Defender pour Office 365 Exercice de simulation d’attaque.
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.
Facilitation Azure
Microsoft Sentinel est un contrôle natif qui combine les 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 la détection anticipée. Grâce à l’analytique et aux requêtes intelligentes, vous pouvez rechercher de manière proactive les problèmes de sécurité. En cas d’incident, vous pouvez automatiser les flux de travail. En outre, avec des modèles de classeur, vous pouvez rapidement obtenir des insights via la visualisation.
Pour obtenir la documentation sur le produit, consultez les fonctionnalités de repérage dans Microsoft Sentinel.
Microsoft Defender pour le 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 qui est intégrée au rythme de l’entreprise chez Microsoft. Pour plus d’informations, consultez 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/de 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éfinies dans les tests de simulation Azure DDoS Protection.
Liens de la communauté
Test de sécurité des applications : outils, types et meilleures pratiques : Les ressources GitHub décrivent les types de méthodologies de test qui peuvent tester les défenses au moment de la génération et au 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 des 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.