PCI DSS v4 a renforcé les exigences en matière de tests de pénétration. Les marchands et prestataires de services qui maintiennent un CDE sont soumis à des obligations précises concernant la fréquence, la couverture et la documentation de ces tests. Comprendre ces obligations — et comment les alléger — est essentiel pour maîtriser les coûts de conformité.
Les obligations de tests de pénétration sous PCI DSS v4
L'exigence 11.4 de PCI DSS v4 établit un cadre détaillé pour les tests de pénétration. Les principaux points sont : les tests doivent être effectués au moins une fois par an et après tout changement significatif du périmètre ; ils doivent couvrir les couches réseau et applicative du CDE ; le testeur doit être indépendant du système testé et posséder les qualifications requises ; les résultats doivent être documentés et les vulnérabilités corrigées dans des délais définis.
PCI DSS v4 a introduit une obligation spécifique concernant la validation de la segmentation réseau : si le marchand utilise la segmentation pour réduire son scope, les tests de pénétration doivent vérifier que cette segmentation est effectivement étanche. Cette exigence a ajouté une couche de complexité et de coût pour les marchands qui utilisent la segmentation comme principal mécanisme de réduction du scope.
Types de tests de pénétration requis
PCI DSS distingue plusieurs types de tests selon l'environnement testé. Les tests de pénétration réseau externe simulent les attaques d'un acteur externe essayant de pénétrer dans le CDE depuis Internet. Les tests de pénétration réseau interne simulent les attaques d'un acteur ayant déjà un accès au réseau interne — un employé malveillant ou un attaquant ayant compromis un système non CDE.
Les tests de pénétration applicatifs visent les applications web et les API qui font partie du CDE ou y sont connectées. PCI DSS v4 exige explicitement que ces tests couvrent toutes les vulnérabilités de l'OWASP Top 10, notamment les injections SQL, les failles XSS, les problèmes d'authentification et les mauvaises configurations de sécurité. Un test applicatif complet nécessite généralement une analyse du code source en plus des tests dynamiques.
Structure et coûts d'un engagement de test de pénétration
Un engagement de test de pénétration PCI DSS type se déroule en plusieurs phases : préparation et collecte d'informations, analyse des vulnérabilités, exploitation (tentatives d'intrusion contrôlées), post-exploitation (évaluation de l'impact d'une intrusion réussie) et rédaction du rapport. Pour un CDE de taille moyenne (10-20 composants), cet engagement dure généralement entre 5 et 10 jours, ce qui correspond à un coût de 5 000 à 20 000 €.
Le rapport final doit documenter toutes les vulnérabilités découvertes, leur criticité, les preuves d'exploitation et les recommandations de remédiation. Après la correction des vulnérabilités critiques et élevées, un test de re-validation (re-test) est généralement effectué pour confirmer l'efficacité des corrections — un coût supplémentaire à prendre en compte dans le budget annuel.
Comment la réduction du CDE réduit la charge des tests de pénétration
La relation entre la taille du CDE et le coût des tests de pénétration est directe : moins il y a de composants dans le périmètre, moins il y a de systèmes à tester et moins le test coûte cher. Un marchand qui tokenise les données de carte et maintient un CDE minimal réduit proportionnellement le périmètre de ses tests de pénétration.
Dans le cas extrême d'un marchand utilisant un SAQ A — sans CDE propre — il n'y a pas de tests de pénétration à effectuer : l'ensemble de la charge revient au prestataire certifié (PCI Proxy EU dans ce cas) qui effectue ses propres tests dans le cadre de sa certification annuelle PCI DSS Level 1. Le marchand bénéficie ainsi indirectement des tests de pénétration sans en supporter le coût.
Planification et mise en œuvre des tests de pénétration
Pour tirer le meilleur parti d'un test de pénétration, la préparation est essentielle. Il convient de définir précisément le périmètre du test avant de contacter les prestataires, de préparer la documentation de l'architecture réseau et des flux de données, et de s'assurer que l'environnement de test est représentatif de l'environnement de production. Un périmètre mal défini peut entraîner un test incomplet ou, à l'inverse, un test excessivement large et donc coûteux.
Il est également recommandé de planifier les tests en dehors des périodes de forte activité pour minimiser l'impact sur les opérations. Certains types de tests, notamment les tests d'exploitation actifs, peuvent générer un trafic réseau inhabituel qui pourrait perturber les services si le personnel n'est pas informé à l'avance.
Vous souhaitez réduire le périmètre de vos tests de pénétration PCI DSS ? Découvrez comment PCI Proxy EU minimise votre CDE.