Audit PCI-DSS — Tests d'Intrusion Obligatoires pour la Conformité Paiement

PCI-DSS (Payment Card Industry Data Security Standard) est le référentiel de sécurité créé et maintenu par le PCI Security Standards Council, consortium fondé par les principaux réseaux de cartes bancaires (Visa, Mastercard, American Express, Discover, JCB). Il définit les exigences de sécurité minimales pour toute organisation qui stocke, traite ou transmet des données de titulaires de carte.

La version 4.0, publiée en mars 2022, est devenue le standard obligatoire depuis avril 2024. Elle introduit plusieurs nouveautés importantes par rapport à la version 3.2.1 : une approche personnalisée permettant aux organisations de démontrer qu'elles atteignent l'objectif de sécurité par des méthodes adaptées à leur contexte, des exigences renforcées sur l'authentification (MFA étendue, politique de mots de passe), une attention accrue à la sécurité des scripts côté client (skimming e-commerce), et des exigences explicites sur la gestion des identités et des accès.

PCI-DSS v4.0 est structuré en 12 exigences regroupées en 6 objectifs : construire et maintenir des réseaux et systèmes sécurisés, protéger les données du titulaire de carte, maintenir un programme de gestion des vulnérabilités, mettre en œuvre de solides mesures de contrôle d'accès, surveiller et tester régulièrement les réseaux, et maintenir une politique de sécurité des informations. Les tests d'intrusion s'inscrivent principalement dans l'objectif de surveillance et de test régulier.

La conformité PCI-DSS est vérifiée soit par un Qualified Security Assessor (QSA) pour les niveaux 1 (plus de 6 millions de transactions par an), soit par un Self-Assessment Questionnaire (SAQ) pour les niveaux 2 à 4. Dans tous les cas, les tests d'intrusion de l'exigence 11.4 sont obligatoires et doivent être réalisés par un testeur qualifié indépendant.

L'exigence 11.4 de PCI-DSS v4.0 est l'une des plus prescriptives du standard en matière de tests de sécurité. Elle impose des tests d'intrusion complets sur l'environnement de données du titulaire de carte (CDE — Cardholder Data Environment) et les systèmes qui interagissent avec lui.

L'exigence 11.4.1 définit la méthodologie que doit respecter le programme de tests d'intrusion : une approche acceptable dans le secteur (PTES, OWASP, NIST SP 800-115 ou équivalent), une couverture du périmètre complet du CDE et des systèmes connexes, des tests depuis l'extérieur du réseau et depuis l'intérieur des différents segments, des tests de la segmentation réseau, et une vérification annuelle des contrôles de segmentation.

L'exigence 11.4.2 impose des tests d'intrusion externes au moins une fois par an et après tout changement significatif de l'infrastructure ou des applications. Les tests externes simulent une attaque depuis Internet contre les composants du CDE exposés.

L'exigence 11.4.3 impose des tests d'intrusion internes avec la même fréquence. Ces tests simulent une attaque depuis l'intérieur du réseau de l'organisation, ce qui est pertinent pour tester la segmentation entre le CDE et le reste du réseau.

Un point souvent mal compris : les tests doivent être réalisés par une ressource interne ou externe qualifiée. Si c'est une ressource interne, elle doit être organisationnellement indépendante des systèmes testés. Dans la pratique, le recours à un prestataire externe comme Atlas RedConsult est la solution la plus simple pour satisfaire cette exigence d'indépendance tout en garantissant la qualité des tests.

La première étape de tout audit PCI-DSS est la définition précise du périmètre (scope). Le périmètre PCI-DSS comprend tous les composants du système d'information qui stockent, traitent ou transmettent des données de titulaires de carte, ainsi que tous les composants du réseau qui se trouvent dans le même segment réseau que les composants du CDE, ou qui peuvent communiquer avec eux.

En pratique, le périmètre inclut typiquement : les serveurs de paiement et de traitement des transactions, les bases de données stockant des données de carte (numéros PAN, données de validation, données sensibles d'authentification), les applications web et API exposant des formulaires de paiement ou traitant des données de carte, les systèmes de gestion des clés de chiffrement, les équipements réseau (pare-feu, routeurs, switches) délimitant le CDE, les terminaux de point de vente (TPE) et les systèmes qui les gèrent, et les prestataires tiers ayant accès au CDE.

La réduction du périmètre est une stratégie clé pour simplifier la conformité PCI-DSS. La tokenisation et l'externalisation du traitement des paiements à des PSP certifiés PCI-DSS permettent de réduire drastiquement le nombre de composants dans le périmètre. Nous vous aidons à analyser les opportunités de réduction de périmètre avant de définir le plan d'audit.

Notre méthodologie d'audit PCI-DSS est alignée sur les exigences de l'exigence 11.4 tout en intégrant les meilleures pratiques du marché (OWASP Testing Guide, PTES, méthodes CREST). Nous adaptons l'intensité et la profondeur des tests au niveau PCI-DSS et au profil de risque de votre organisation.

La phase de cadrage définit précisément le périmètre CDE, les systèmes connexes, les règles d'engagement (plages horaires, systèmes exclus, contacts d'urgence), et le planning des tests. Nous travaillons en étroite coordination avec votre QSA si vous êtes soumis à une évaluation de niveau 1 pour garantir que nos tests répondent à ses attentes.

Les tests externes couvrent : la reconnaissance des composants exposés sur Internet, les tests d'injection (SQL, LDAP, OS command), les tests d'authentification et de gestion des sessions, les tests de contrôle d'accès, les tests de cryptographie (protocoles, chiffrement des données de carte en transit), la recherche de vulnérabilités connues sur les composants identifiés, et les tests spécifiques au skimming e-commerce (code malveillant côté client, intégrité des scripts de paiement).

Les tests internes ajoutent : la vérification de la segmentation réseau entre le CDE et les autres zones, les tests de mouvement latéral depuis une position compromise dans le réseau interne, les tests d'escalade de privilèges sur les systèmes CDE, et la vérification des contrôles d'accès entre le CDE et les systèmes tiers.

PCI-DSS v4.0 impose des tests d'intrusion au moins une fois par an. Cette fréquence minimale ne doit pas être confondue avec la fréquence optimale pour votre programme de sécurité. De nombreuses organisations optent pour des tests semestriels ou trimestriels sur les composants les plus critiques, notamment les applications de paiement exposées sur Internet.

Des tests supplémentaires sont obligatoires après tout changement significatif de l'environnement CDE. Les changements déclenchant un nouveau test incluent : la mise en production d'une nouvelle application de paiement ou d'une nouvelle version majeure, la migration de l'infrastructure vers un nouveau datacenter ou vers le cloud, la modification de l'architecture réseau du CDE (ajout d'un pare-feu, modification de la segmentation), l'intégration d'un nouveau prestataire de services ayant accès au CDE, ou toute autre modification substantielle affectant la surface d'attaque.

Nous vous recommandons d'intégrer les tests PCI-DSS dans votre cycle de release et de gestion des changements. En définissant des seuils de criticité des changements déclenchant un test, vous évitez les mauvaises surprises lors des évaluations PCI-DSS annuelles et vous maintenez un niveau de sécurité constant tout au long de l'année.

Atlas RedConsult propose des contrats de tests récurrents qui facilitent cette intégration : tarifs préférentiels sur volume, délais d'exécution réduits grâce à la connaissance préalable de votre environnement, et reporting consolidé facilitant le suivi de conformité PCI-DSS dans le temps.