Un éditeur de logiciels de santé a fourni son dernier rapport de test d’intrusion comme preuve de la maturité de ses tests de sécurité. Le rapport ne comportait aucun constat critique et deux constats de gravité moyenne, tous deux liés à la configuration TLS d’un point de terminaison de préproduction. L’équipe de sécurité de l’éditeur l’a présenté comme la preuve que son environnement avait été testé et jugé sécurisé. Un examen attentif de la section du rapport consacrée au périmètre racontait une autre histoire. Le test avait été mené selon une méthodologie externe en boîte noire, simulant un attaquant externe non authentifié, et portait uniquement sur l’application web exposée au public. Les exclusions du périmètre comprenaient : le réseau interne de l’entreprise, tous les serveurs de bases de données, tous les points de terminaison API nécessitant une authentification, l’infrastructure cloud AWS hébergeant les données des clients, l’environnement de développement et les propres systèmes d’accès administratif de l’éditeur. Le test de deux jours avait évalué la page de connexion, les parties non authentifiées de l’API et le portail de documentation public. Les environnements les plus pertinents pour le risque du client (l’API authentifiée où les données de santé des clients étaient traitées, l’infrastructure AWS où elles étaient stockées et les systèmes d’administration par lesquels le personnel de l’éditeur y accédait) se trouvaient tous hors du périmètre. Le rapport sans faille décrivait un périmètre externe sans faille. L’environnement interne et l’infrastructure cloud n’avaient pas été testés.
Qu’est-ce que le problème de la profondeur des tests des contrôles, réellement ?
La profondeur des tests des contrôles est la mesure dans laquelle les tests de sécurité éprouvent les contrôles, les systèmes et les chemins d’attaque les plus pertinents pour le modèle de menace réel, plutôt que ceux qui sont les plus faciles à tester dans un budget et un calendrier définis. La profondeur des tests comporte deux dimensions : la profondeur du périmètre, c’est-à-dire la part des systèmes et environnements pertinents inclus dans le test, et la profondeur technique, c’est-à-dire le degré d’approfondissement avec lequel les systèmes inclus sont testés au moyen des techniques qu’emploieraient de véritables attaquants.
La limitation du périmètre est le problème de profondeur des tests le plus lourd de conséquences. Les tests d’intrusion à périmètre étroit (externe uniquement, application web uniquement, chemins non authentifiés uniquement) produisent des constats qui reflètent fidèlement la sécurité du périmètre testé sans apporter aucune assurance sur les systèmes non testés. La surface d’attaque que privilégient les attaquants sophistiqués (points de terminaison API authentifiés, configuration de l’infrastructure cloud, chemins de déplacement latéral internes et systèmes d’accès administratif) correspond souvent aux systèmes exclus du périmètre des tests d’intrusion pour en limiter le coût et la complexité. Un test sans faille sur un périmètre étroit ne prouve pas que l’environnement est sécurisé ; il prouve que la partie testée de l’environnement ne présente aucun problème détecté.
Le problème des limites techniques est la seconde dimension de la profondeur. Même dans un périmètre défini, la profondeur des tests détermine ce que le test peut détecter. Une analyse automatisée des vulnérabilités détecte les CVE connues et les mauvaises configurations courantes. Un test d’intrusion manuel mené par un testeur expérimenté peut mettre au jour des vulnérabilités logiques, des contournements de l’authentification et des chemins d’élévation de privilèges que les outils automatisés ne voient pas. Les vulnérabilités de logique métier, c’est-à-dire les failles d’autorisation qui permettent à un client d’accéder aux données d’un autre client par des appels API apparemment légitimes, exigent une compréhension propre à l’application que les outils automatisés ne peuvent pas fournir. Les tests qui reposent principalement sur une analyse automatisée dans un périmètre limité trouveront les vulnérabilités que les outils automatisés détectent. Ils passeront à côté des catégories d’attaques qui exigent une expertise humaine et une connaissance propre à l’application.
- Périmètre limité au périmètre externe : réseau interne, infrastructure cloud et chemins authentifiés exclus
- API authentifiée non testée : l’environnement où les données des clients sont les plus accessibles est exclu du périmètre
- Infrastructure cloud exclue : l’environnement AWS, Azure ou GCP où se trouvent les données n’est pas évalué
- Tests uniquement en boîte noire : aucun test authentifié ni en boîte blanche des systèmes internes
- Analyse automatisée sans tests manuels : une profondeur technique insuffisante pour détecter les vulnérabilités complexes
Pourquoi c’est important
La profondeur des tests des contrôles compte pour la TPRM, car les rapports de test d’intrusion figurent parmi les preuves les plus demandées et les plus déterminantes dans les évaluations de sécurité des fournisseurs. Un résultat de test d’intrusion sans faille portant sur un périmètre étroit envoie un signal positif fort dans l’évaluation sans apporter aucune assurance sur les systèmes les plus pertinents pour le risque du client. Le client qui s’appuie sur le rapport de test pour comprendre la posture de sécurité du fournisseur s’appuie sur des preuves dont le périmètre a été délibérément éloigné des systèmes les plus à risque.
La lacune des tests d’API authentifiées est particulièrement importante pour les fournisseurs qui traitent les données de leurs clients au moyen d’API. La plupart des relations modernes de traitement de données reposent sur des appels API authentifiés : le système du client appelle l’API du fournisseur avec des identifiants d’authentification, et le système du fournisseur traite la requête et renvoie des données. Les contrôles d’authentification et d’autorisation de ces points de terminaison API déterminent si les données du client A peuvent être consultées par le client B, si un identifiant client compromis peut donner accès à plus de données que prévu et si les contrôles d’accès aux données du fournisseur fonctionnent comme prévu. Tester la surface externe non authentifiée tout en excluant les points de terminaison API authentifiés, c’est réaliser un test qui a évalué la serrure de la porte d’entrée sans tester la pièce où sont conservées les données du client.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à examiner les rapports de test d’intrusion sous l’angle de la gravité des constats sans examiner la couverture du périmètre. Un rapport sans constat critique portant sur un périmètre étroit apporte moins d’assurance qu’un rapport comportant des constats moyens portant sur un périmètre complet. Le périmètre détermine ce que le test pouvait trouver. La gravité des constats décrit ce qu’il a trouvé dans ce périmètre.
- Examiner la gravité des constats sans examiner la couverture du périmètre
- Exclusions du périmètre non évaluées : la section sur le périmètre n’est pas examinée pour repérer les systèmes pertinents exclus
- Couverture de l’API authentifiée non confirmée
- Périmètre de l’infrastructure cloud non vérifié
- Technique de test non évaluée : automatisée, manuelle ou propre à l’application
À quoi ressemblent les bonnes pratiques
Les programmes matures de gouvernance des tests d’intrusion définissent des exigences de périmètre couvrant les systèmes les plus pertinents pour le risque du client (environnements API authentifiés, infrastructure cloud et chemins de déplacement latéral internes) et exigent des techniques de test adaptées aux catégories de vulnérabilités du périmètre.
- Exigences de périmètre alignées sur le modèle de menace : API authentifiée, infrastructure cloud et chemins internes inclus
- Tests authentifiés exigés : tests des systèmes nécessitant une authentification, et pas seulement du périmètre exposé au public
- Infrastructure cloud dans le périmètre : évaluation de la configuration AWS, Azure ou GCP incluse
- Tests manuels exigés pour les systèmes critiques : tests de la logique métier et du contournement des autorisations menés par des testeurs expérimentés
- Examen de la couverture du périmètre avant d’accepter un rapport de test : vérifier que les systèmes concernés sont dans le périmètre
Outils
Normes de test d’intrusion : PTES, Testing Guide de l’OWASP, NIST SP 800-115
Les normes méthodologiques de test d’intrusion définissent un périmètre et des techniques de test complets. Le Testing Guide de l’OWASP traite précisément des tests d’authentification et d’autorisation des applications web et des API, c’est-à-dire de la profondeur technique nécessaire pour détecter les vulnérabilités qu’une analyse superficielle ne voit pas. Pour les professionnels TPRM, exiger que les tests d’intrusion des fournisseurs suivent la méthodologie de l’OWASP ou du PTES fixe un niveau de référence pour la profondeur technique.
Tests de sécurité du cloud : AWS Inspector, évaluations Azure Security Center, tests d’intrusion cloud réalisés par des tiers
Les évaluations de sécurité propres au cloud couvrent la surface d’attaque liée à la configuration que les tests d’intrusion traditionnels excluent généralement : mauvaises configurations IAM, politiques d’accès au stockage, paramètres des groupes de sécurité réseau et vulnérabilités d’authentification natives du cloud. Pour les professionnels TPRM, exiger que les fournisseurs fassent évaluer leur infrastructure cloud en plus des tests d’intrusion applicatifs permet de poser une question précise sur la couverture du cloud.
Enjeux de gouvernance
En matière de profondeur des tests des contrôles, l’enjeu de gouvernance tient à l’arbitrage entre coût et périmètre. Un test d’intrusion complet couvrant les API authentifiées, l’infrastructure cloud, les réseaux internes et plusieurs techniques de test coûte nettement plus cher qu’un test externe en boîte noire de deux jours. Les fournisseurs qui maîtrisent eux-mêmes le périmètre de leurs tests choisiront par défaut le périmètre minimal permettant de satisfaire à l’exigence contractuelle d’un test d’intrusion annuel. Les clients qui souhaitent un périmètre plus large doivent le préciser, soit dans les exigences contractuelles, soit dans des demandes de preuves comportant des questions sur la couverture du périmètre.
- Examiner la section sur le périmètre avant la gravité des constats dans tout rapport de test d’intrusion
- Demander précisément si les points de terminaison API authentifiés ont été testés
- Demander si l’infrastructure cloud était dans le périmètre
- Exiger une couverture du périmètre qui inclut les systèmes les plus pertinents pour les données des clients
- Distinguer la méthodologie de test : analyse automatisée, tests manuels ou tests propres à l’application
Si vous êtes une petite équipe
Pour le dernier rapport de test d’intrusion de votre fournisseur le plus à risque, lisez la section sur le périmètre avant de lire les constats. Listez les systèmes et environnements explicitement inclus et explicitement exclus. Puis demandez-vous : l’environnement où les données de mon organisation sont traitées et stockées figure-t-il dans le périmètre inclus ? Si la réponse est non ou incertaine, les constats du test, quelle que soit leur gravité, ne décrivent pas la sécurité des systèmes qui vous importent le plus.
- Lire la section sur le périmètre avant les constats dans tout rapport de test d’intrusion d’un fournisseur
- Confirmer que les environnements API authentifiés sont dans le périmètre
- Confirmer que l’infrastructure cloud est dans le périmètre
- Poser des questions sur la méthodologie de test : automatisée ou manuelle
Ce qu’il faut exiger
Demandez directement :
« Pour votre dernier test d’intrusion, le périmètre était-il limité aux systèmes exposés à l’extérieur, ou incluait-il les points de terminaison API authentifiés, la configuration de l’infrastructure cloud et les chemins du réseau interne ? Plus précisément, les systèmes qui traitent et stockent les données de notre organisation figuraient-ils dans le périmètre du test ? »
Preuves attendues
- Documentation du périmètre du test d’intrusion, avec les systèmes inclus et exclus
- Confirmation que les environnements API authentifiés sont dans le périmètre
- Confirmation de l’évaluation de l’infrastructure cloud
- Description de la méthodologie de test : composantes automatisées et manuelles
Un fournisseur qui présente un rapport de test d’intrusion sans faille doit être interrogé précisément sur l’inclusion, dans le périmètre du test, des systèmes qui traitent les données du client. Le rapport décrit ce qui a été trouvé dans les systèmes testés. Le périmètre définit quels systèmes ont été testés.
Comment le prouver
- Évaluation de la couverture du périmètre des rapports de test d’intrusion des fournisseurs
- Confirmation des tests de l’API authentifiée et de l’infrastructure cloud
- Dossiers d’évaluation de la méthodologie
- Exigences de périmètre dans les contrats fournisseurs
À retenir
L’absence de constat critique sur un périmètre étroit n’équivaut pas à l’absence de vulnérabilité critique dans l’environnement. Le test d’intrusion n’a rien trouvé de critique parce que l’API authentifiée où les données des clients sont traitées, l’infrastructure AWS où elles sont stockées, le réseau interne et les systèmes d’administration étaient tous hors du périmètre. Le test était sans faille. Les systèmes concernés n’avaient pas été testés. L’assurance qu’apporte un test d’intrusion est bornée par son périmètre. Lire la section sur le périmètre avant celle des constats indique ce que le test peut vous apprendre sur la posture de sécurité du fournisseur. Ne lire que les constats vous apprend ce qui a été trouvé dans les systèmes que le fournisseur a choisi de faire tester.