Stratégies d’architecture pour les tests de sécurité

S'applique à cette recommandation de la liste de contrôle du Framework Azure Well-Architected Security :

Les tests rigoureux constituent la base d’une bonne conception de sécurité. 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. Incluez des perspectives de l’intérieur vers l’extérieur qui testent la plateforme et l’infrastructure, ainsi que des évaluations de l’extérieur vers l’intérieur qui testent le système comme le ferait un attaquant externe.

Les stratégies clés de cet article reposent sur les pratiques de test fondamentales décrites dans les stratégies d’architecture OE :09 pour les tests. Passez d’abord en revue cet article. 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.

Terminologie

Collaborer avec des experts de sécurité pour concevoir des tests

Participez à la planification des tests. Souvent, une organisation centralise cette tâche. Assurez-vous que votre équipe est impliquée dans ce processus de conception afin que les garanties de sécurité s’alignent sur les fonctionnalités de l’application.

Adoptez un état d’esprit partant du principe qu’une compromission a déjà eu lieu. Concevez vos cas de test avec l’hypothèse que le système est en cours d’attaque et que l’attaquant fonctionne à l’intérieur de l’environnement. Simulez vos tests pour refléter des scénarios d’attaque réalistes tels que la validation de l’endiguement du mouvement latéral au sein d’une machine virtuelle d’application compromise. De cette façon, vous pouvez découvrir les vulnérabilités potentielles et hiérarchiser les tests en conséquence.

Partagez les diagrammes architecturaux, le modèle de menace et d’autres documents pertinents pour tester la charge de travail de manière significative.

Hiérarchiser les tests en fonction de la modélisation des menaces et des flux critiques

La modélisation des menaces est une pratique essentielle pour identifier les menaces et les vulnérabilités potentielles dans votre charge de travail. Utilisez les évaluations de gravité de votre modèle de menace pour hiérarchiser et étendre vos efforts de test. Les menaces de gravité les plus élevées contre vos flux les plus critiques méritent la plus grande couverture.

Couvrez toute la surface d’attaque de la charge de travail. Évaluez l’identité, le code d’application, les contrôles d’infrastructure, les composants tiers, les bibliothèques et les services, ainsi que les processus automatisés et humains tels que les flux de travail d’approbation et les révisions d’accès.

Commencez par les contrôles d’identité et d’accès, car une identité compromise contourne la plupart des défenses en aval. Ensuite, validez les limites du réseau et enfin les défenses de couche application.

Hiérarchiser les flux qui gèrent l’authentification, les données sensibles ou les transactions financières. Pour chaque flux critique, identifiez les menaces avec l’évaluation de gravité la plus élevée dans votre modèle de menace. Créez des cas de test pilotés par les risques qui mappent chaque menace au contrôle destiné à l’atténuer.

Un bon exercice de modélisation des menaces pointe vers des zones clés pour 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.

Risque : les modèles de menace obsolètes peuvent entraîner des efforts de test mal alignés. Mettez régulièrement à jour votre modèle de menace pour refléter les changements dans la charge de travail et le paysage des menaces en constante évolution.

Tirer parti de l’expertise tierce

Les équipes internes peuvent avoir des angles morts. Les experts externes et les chercheurs participatifs examinent votre environnement comme le ferait un attaquant. Apportez des experts spécialisés pour tester votre charge de travail du point de vue d’un adversaire et fournir des insights sur les dernières techniques et tendances d’attaque.

Évitez de donner un accès trop permissif à votre charge de travail. Donnez aux testeurs externes uniquement l’accès dont ils ont besoin. Un test d’intrusion en boîte noire ne nécessite ni code ni accès interne, tandis qu’une analyse en boîte blanche nécessite le code source, des documents de conception ou des journaux.

Déterminez si votre équipe a la capacité de trier les rapports externes avant de lancer un programme. Ensuite, établissez un programme de primes de bogues ou un mécanisme permettant à la communauté de signaler les problèmes de sécurité. Évaluez et classez chaque problème signalé, réintégrez les vulnérabilités confirmées à votre modèle de menace et ajoutez un cas de test pour détecter toute régression.

Tester les contrôles de conformité et générer des preuves prêtes pour l’audit

La conformité n’est pas une révision ponctuelle. Traitez chaque contrôle réglementaire comme une exigence testable afin que vous ayez toujours de nouvelles preuves pour les auditeurs.

Identifiez les réglementations que votre charge de travail doit satisfaire. Mappez chaque contrôle réglementaire à un cas de test spécifique. Planifiez l’exécution des tests à une cadence périodique et avant chaque mise en ligne. Stockez la sortie de test dans un emplacement auditable afin de pouvoir produire des preuves à la demande.

Compromis: Les tests pour les contrôles réglementaires peuvent ralentir les opérations. Par exemple, les tests de prédéploiement ajoutent une latence de pipeline. Il existe également un coût supplémentaire d’exécution de ces opérations. Donnez la priorité aux tests concernant les contrôles ayant l’impact le plus élevé en matière d’audit et de risque.

Risque : la preuve d’audit est elle-même sensible. Sans protection de l’intégrité et journalisation des accès, le magasin de preuves devient à la fois une cible d’attaque et une violation de conformité potentielle.

Protéger les ressources de test

Les ressources de test sont elles-mêmes une surface d’attaque. Protégez leur confidentialité, leur intégrité et leur disponibilité afin que vos tests n’exposent pas d’informations sensibles ni n’ouvrent de nouveaux vecteurs d’attaque.

• Utilisez des données désinfectées ou synthétiques qui ne contiennent aucune information personnellement identifiable (PII) ou données de production.
• Conservez les données de test uniquement tant que nécessaire et supprimez-les en toute sécurité.
• Vérifiez que les règles de résidence des données transfrontalières sont appliquées dans les environnements de test qui s’étendent sur des régions.
• Générez des informations d’identification de test dédiées, des clés API et des certificats. Stockez-les dans une instance de coffre de clés distincte avec ses propres stratégies d’accès.
• Configurez des environnements de test isolés qui reflètent les contrôles de sécurité de production tels que les groupes de sécurité réseau (NSG), les stratégies de contrôle d’accès en fonction du rôle (RBAC), le pare-feu et les règles de protection contre la perte de données (DLP). Appliquez les mêmes instructions de segmentation que la production. Pour plus d’informations, consultez Recommandations pour la stratégie de segmentation.

Effectuer des analyses régulières des vulnérabilités sur les ressources de test

Analysez les ressources de test pour détecter les vulnérabilités à la même cadence que les ressources de production, notamment le code de test, l’infrastructure en tant que code (IaC), les images de conteneur et de machine virtuelle, les référentiels et les pipelines. Utilisez des outils qui s’intègrent à vos flux de travail de développement et de déploiement pour automatiser ces vérifications.

Établir un rythme de test continu pour la charge de travail

Traitez les tests de sécurité comme une activité continue qui maintient la posture de sécurité actuelle de la charge de travail en tant que menaces, code et configurations évoluent. Exécutez des tests selon une planification afin que les modifications n’introduisent pas de risques de sécurité ni de régressions. Soyez prêt pour les validations de sécurité organisationnelles qui peuvent se produire à tout moment et pour les tests déclenchés par un incident de sécurité. Les sections suivantes décrivent les cadences à planifier.

Tests de routine

Les tests de routine définissent la base de référence pour la posture de sécurité de votre charge de travail. Effectuez-les à une cadence régulière, dans le cadre de vos procédures d’exploitation standard et pour répondre aux exigences de conformité. Vous pouvez exécuter différents tests à différentes cadences, mais la clé est que vous les effectuez régulièrement et selon une planification.

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. Lorsque vous découvrez de nouveaux problèmes aux mêmes points du cycle de vie, ajoutez de nouveaux cas de test.

Ne vous fiez pas seulement aux tests automatisés. Utilisez des tests manuels pour rechercher des vulnérabilités que seule l’expertise humaine peut intercepter et pour des travaux exploratoires sur des 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 passe à 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. Évaluez ces risques par rapport aux avantages.

Tests d’incident de sécurité

Utilisez des tests qui détectent la cause d’un incident de sécurité à sa source. Résolvez ces lacunes de sécurité pour empêcher l’incident de se périodiquer.

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.

Valider les contrôles de sécurité sur la surface d’attaque

Utilisez une variété de méthodologies de test pour obtenir une couverture complète et découvrir les lacunes dans les contrôles de sécurité, les mauvaises configurations et les faiblesses de l’observabilité et de la détection. La plupart des tests décrits dans cette section peuvent s’exécuter en tant que tests de routine. Toutefois, la répétabilité peut entraîner des coûts et provoquer des interruptions. Tenez compte de ces compromis avec soin.

Tester les contrôles de chiffrement. Les échecs de chiffrement sont silencieux. Les données semblent protégées jusqu’à ce qu’une faille révèle le contraire.

• Vérifiez que le chiffrement est appliqué, pas seulement configuré.
• Retestez après chaque rotation de clé, renouvellement de certificat et modification de l’infrastructure.

Tester les contrôles réseau. Les limites du réseau sont celles où votre segmentation est appliquée.

• Testez-les après toute modification de topologie réseau.
• Vérifiez que les règles de refus par défaut sont respectées et que les chemins de trafic autorisés correspondent à l’architecture prévue.

Tester le code de l’application. Les défenses de couche application sont la dernière limite avant qu’un attaquant atteigne les données.

• Vérifiez que les applications déployées résistent aux modèles d’attaque courants plutôt que d’analyser uniquement le code source au moment de la génération.
• Exécutez des techniques de test de sécurité des applications (AST) sur le code source pour confirmer 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ège. Pour plus d’informations, consultez les liens de la communauté.

Simuler des attaques basées sur des identités et vérifier la détection

Les attaques basées sur l’identité sont le vecteur d’attaque initial le plus courant. Simulez ces attaques pour vérifier que vos contrôles d’identité fonctionnent et que votre supervision capture les événements.

Les contrôles d’accès sont la première ligne de défense. Testez-les après chaque modification de rôle ou de stratégie et selon une planification automatisée. Simuler des modèles d’attaque courants et confirmer que vos contrôles appliquent des privilèges minimum et résistent aux tentatives de contournement.

Prenez en compte ces modèles d’attaque lorsque vous concevez des tests :

• Contournement de l’autorisation
• Vol de jetons et relecture
• Déplacement latéral entre comptes ou services
• Escalade de privilèges

Validez les deux côtés de chaque contrôle :

• Cas positifs : les utilisateurs autorisés réussissent.
• Cas négatifs : les tentatives non autorisées sont bloquées et journalisées.

Tester la détection et l’alerte des menaces

La détection qui ne déclenche pas d’alerte fournit peu de valeur. Testez votre surveillance et vos alertes dans le cadre de chaque validation de contrôle de sécurité et vérifiez que les mécanismes conçus pour détecter les attaques fonctionnent comme prévu.

Exécutez des simulations de bout en bout des attaques, puis confirmez chaque étape du pipeline de détection :

• Vérifiez que les événements de sécurité tels que les tentatives de connexion, les modifications d’autorisation et les opérations de jeton sont enregistrés avec suffisamment de détails.
• Vérifiez que votre plateforme SIEM (Security Information and Event Management) ou votre tableau de bord des opérations de sécurité met en corrélation les événements associés.
• Établissez un contrat de niveau de service d’alerte (SLA) et testez que les alertes sont actionnables et surfaces dans ce délai.
• Vérifiez que les journaux ne peuvent pas être modifiés ou supprimés par des comptes non administratifs.
• Vérifiez que le mécanisme de détection pour chaque attaque simulée se déclenche. Par exemple, si vous simulez une attaque par déni de service distribué (DDoS) avec des modèles de trafic valides, vérifiez que la limitation du débit détecte et l’atténue.

Pour les charges de travail matures, validez les garde-fous de gouvernance comme des tests de routine. Introduisez intentionnellement des configurations non sécurisées et vérifiez que le pipeline détecte et répond. Vérifiez que les contraintes de Azure Policy ou de zone d’atterrissage appliquent les protections attendues. L’équipe de plateforme ou de sécurité effectue généralement ce test, et non l’équipe de charge de travail.

Renforcer les défenses avec des tests basés sur des adversaires

Utilisez des tests qui permettent la chasse aux menaces en simulant des attaques réelles. Ces tests 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 apprennent, l’équipe met à niveau ses connaissances et son 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.

Risque : les tests en général peuvent affecter les performances. Les tests destructeurs peuvent supprimer ou endommager les données et provoquer des problèmes de continuité d’activité. Il existe également des risques associés à l’exposition de l’information. Maintenez la confidentialité des données. Vérifiez l’intégrité des données une fois que vous avez terminé le test.

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 mécanismes 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.

Risque : la différence entre les deux types est le coût initial. Les tests de boîte blanche peuvent être coûteux en termes de temps nécessaire pour comprendre le système. Dans certains cas, les tests en boîte blanche vous obligent à acheter des outils spécialisés. Les tests de boîte noire n’ont pas besoin de temps de préparation, mais ils peuvent ne pas être aussi efficaces. Vous devrez peut-être déployer des efforts supplémentaires pour découvrir les problèmes. C’est un compromis en termes de temps d'investissement.

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 des équipes applications de l’organisation effectuent des tests de pénétration ou pentests. 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.

Compromis : les tests de pénétration sont improvisés et peuvent être coûteux en termes de perturbations et d’investissements monétaires, car le test d’intrusion (pentestingà est généralement une offre payante par des praticiens tiers.

Risque : un exercice de test d'intrusion peut affecter l’environnement d’exécution et perturber la disponibilité du trafic habituel.

Les praticiens peuvent avoir besoin d’accéder à des données sensibles dans l’ensemble de l’organisation. ** Suivez les règles d'utilisation pour vous assurer que l’accès n’est pas abusé. 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, deux équipes participent :

• L’équipe rouge agit comme l’adversaire et tente de modéliser des attaques réelles. S'ils réussissent, vous identifiez des lacunes dans votre conception de sécurité et évaluez la contenance du rayon d’explosion de leurs intrusions.

• 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 vérifient les défenses qui protègent les ressources associées aux charges de travail.

Si vous effectuez ces tests régulièrement, les exercices de jeu de guerre peuvent fournir une visibilité et une assurance continues que vos défenses fonctionnent comme conçues. Les exercices de jeu de guerre peuvent tester à différents niveaux au sein de vos charges de travail.

Un choix populaire pour simuler des scénarios d’attaque réalistes est la formation de simulation d’attaque Microsoft Defender pour Office 365.

Pour plus d’informations, consultez Analyses et rapports pour la formation sur la 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 via 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 logs provenant 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, à l’aide de 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 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 Microsoft Defender Vulnerability Management - Microsoft Defender pour 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 que vous pouvez automatiser dans le cadre des pipelines d’intégration/de déploiement continus. Pour plus d’informations, consultez Activer DevSecOps avec Azure et GitHub - Azure DevOps.

Liens connexes

Suivez les protocoles pour vous assurer que l’accès n’est pas incorrectement utilisé. Pour obtenir des conseils sur la planification et l’exécution d’attaques simulées, consultez les articles suivants :

• Règles d'engagement pour le test d'intrusion

• Test d’intrusion

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.

Standard d'exécution des tests de pénétration (PTES) fournit des instructions sur les scénarios courants et les activités requises pour établir un référentiel.

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.