PCI DSS 4.0 Exigences 11.3 et 11.4: Ce qui est réellement testé

La plupart des cadres de sécurité parlent de tests de pénétration. Ils demandent une "assurance technique" ou une "vérification indépendante" et laissent le reste à l'interprétation. PCI DSS ne le fait pas. C'est le seul cadre dans la famille de conformité qui nomme les tests de pénétration explicitement et fixe un calendrier à lui — et la version 4.0 a serré les vis plutôt que de les desserrer. Si votre fenêtre d'évaluation atterrit cette année, la question n'est plus de savoir si vous avez besoin d'un devis, mais si celui que vous avez survivra à une lecture de l'AQA.

La confusion commence presque toujours au même endroit : les équipes traitent le « scanning » et le « test » comme deux mots pour la même activité, planifient un et découvrent au moment de l'évaluation que la norme voulait les deux. Les prescriptions 11.3 et 11.4 sont délibérément divisées pour cette raison. L'un est automatisé, trimestriel et répond à une case à cocher. L'autre est manuel, annuel, et répond à une question beaucoup plus difficile — peut-on réellement atteindre les données de la carte?

Ce qui compte comme dans la portée

Le périmètre n'est pas "le serveur de paiement". C'est l'environnement de données du détenteur de carte — le CDE — plus tout système qui peut se connecter à lui ou influencer sa sécurité. Cette deuxième clause est celle où la plupart des arguments de portée sont perdus. Les postes de travail administratifs, les systèmes d'authentification, les plates-formes de surveillance et les fournisseurs de services connectés sont tous situés à l'intérieur de la frontière, parce que chacun d'eux est une voie plausible.

Un système qui est réellement à l'extérieur du périmètre doit être à l'extérieur de celui-ci techniquement, pas seulement sur un diagramme. Et cette distinction est prouvée par des tests de segmentation, pas par la documentation. La surprise la plus courante à l'évaluation est un VLAN que le dessin d'architecture appelle "séparer" mais qui atteint encore le CDE par une règle de pare-feu oubliée ou un saut à travers un poste de travail admin. La segmentation non démontrée ne rétrécit pas votre périmètre. Elle l'élargit discrètement et entraîne chaque exigence avec elle.

Attention: Un diagramme de réseau montrant une séparation nette entre l'informatique d'entreprise et le CDE ne prouve rien de lui-même. Si vous ne pouvez pas montrer un testeur qui essaie de franchir cette frontière et qui échoue, l'ASQ doit supposer que la frontière n'existe pas.

Exigence 11.3 : analyse de vulnérabilité

L'exigence 11.3 couvre la numérisation, et il est strict à la fois la cadence et la paternité. Vous avez besoin d'analyses internes et externes au moins trimestrielles, plus une analyse après tout changement important — un nouveau service public, un segment ré-archiqué, un déploiement d'applications majeur. L'horloge réinitialise le changement, et non le calendrier.

Les balayages externes doivent être effectués par un ASV, un fournisseur de numérisation agréé par le Conseil des normes de sécurité de l'IPC. Les scans internes peuvent être effectués à l'interne, mais par le personnel indépendant de l'équipe qui administre les systèmes à scanner. Cette clause d'indépendance n'est pas une formalité; c'est la différence entre un balayage et une autoévaluation. Et un scan "passant" a une signification spécifique : zéro vulnérabilité à haute gravité. Pas "nous les avons tous enregistrés". Pas "nous avons accepté le risque." Zéro.

C'est les équipes d'exigences qui croient le plus souvent qu'elles sont satisfaites quand elles ne l'ont pas fait. Un rapport trimestriel d'analyse rempli d'éléments critiques non reliés n'est pas une preuve de conformité — il est la preuve d'une exposition connue, non traitée, horodatée par votre propre fournisseur.

Requirement 11.4: test de pénétration

Ici, la norme devient inhabituellement spécifique, et il vaut la peine de lire les sous-exigences comme une spécification plutôt qu'une suggestion. L'exigence 11.4 exige une méthodologie documentée, des essais externes et internes au moins une fois par année et après d'importants changements dans l'infrastructure ou l'application, la couverture de l'ensemble du périmètre de l'ECE à la fois sur le réseau et sur les couches d'application, et l'assainissement des vulnérabilités exploitables suivie d'un nouveau test.

Deux clauses soulèvent la barre plus loin pour les fournisseurs de services. L'exigence 11.4.6 exige des tests de segmentation tous les six mois plutôt que tous les ans. L'exigence 11.4.7 ajoute des tests d'isolement entre les clients pour les fournisseurs multilocataires — une exigence qui rattrape précisément la façon dont les plateformes de paiement SaaS fonctionnent réellement, où la mauvaise configuration d'un locataire peut devenir une violation d'un autre locataire.

Lisez ce tableau comme une carte de couverture, pas une liste de contrôle. Une seule note annuelle qui touche le niveau externe du web et s'arrête là ne satisfait pas 11.4.2, qui veut explicitement le réseau interne et la couche d'application ainsi. Les deux couches captent des choses différentes : les tests en réseau trouvent le chemin, les tests d'application trouvent la porte laissée ouverte à la fin.

Ce que demande l'AQA dans le rapport

Le rapport lui-même est celui où les engagements sont gagnés ou perdus. Un QSA ne lit pas vos résultats pour le divertissement; ils vérifient si le travail correspond à l'exigence. Six choses surgissent encore et encore.

• Une méthodologie déclarée qui est reconnue dans l'industrie — PTES, OWASP ou NIST SP 800-115 — pas un processus sur mesure inventé pour l'engagement.
• Une justification du périmètre : pourquoi ces systèmes et non d'autres, liés au diagramme de flux de données du détenteur de carte.
• Une preuve que les tests ont couvert à la fois la couche réseau et la couche d'application.
• Pour la segmentation : quelles mesures de contrôle ont été tentées à l'extérieur du CDE, et le résultat de chaque tentative.
• Revérification documentée de toute vulnérabilité exploitable, avec une date et un statut final.
• Preuve que le testeur était indépendant de l'équipe administrant les systèmes à l'essai.

Ce dernier point est celui qui disqualifie discrètement les engagements. Si le même ingénieur qui exécute les pare-feu exécute également le test contre eux, l'exigence d'indépendance n'est pas respectée, peu importe la qualité des résultats.

Important : le nouveau test n'est pas un nettoyage facultatif. L'exigence 11.4 s'attend à ce que les vulnérabilités exploitables soient corrigées puis réévaluées, le nouveau test étant documenté. Une liste de conclusions sans preuve de clôture est un élément ouvert, et non une exigence remplie.

Le balayage et les tests ne sont pas des substituts

Le modèle mental le plus utile est celui-ci : un scan trouve des vulnérabilités connues sur les services exposés ; un test de pénétration essaie de les exploiter, de les chaîner ensemble et d'atteindre les données de la carte. L'un est un détecteur de fumée. L'autre est quelqu'un qui marche dans l'immeuble la nuit, vérifiant si les fenêtres que vous croyez sont vraiment verrouillées.

Une analyse ASV est automatisée, trimestrielle, externe et les réponses 11.3.2. Un test de pénétration est manuel, annuel et répond 11.4. La norme exige les deux parce que chacun manque ce que l'autre capture. L'automatisation est exhaustive sur le connu et aveugle au roman; un testeur humain est l'inverse. Remplacer l'un avec l'autre est le plus commun — et le plus facile à attraper — raccourci dans une évaluation PCI DSS.

Il y a aussi une conséquence pratique pour la façon dont vous budgétisez et planifiez. Les balayages sont bon marché, fréquents et peuvent être largement opérationnels. Les tests de pénétration sont coûteux, annuels et dépendent de compétences limitées. Les traiter comme une seule ligne signifie que l'un d'entre eux est sous-financé, et c'est habituellement celui qui prend une réelle compétence pour faire bien.

Ce qui a changé de 3.2.1 à 4.0

Les exigences de test ont été renumérotées — 11.3 est devenu balayage, 11.4 est devenu test de pénétration — mais les changements plus conséquents ont été substantiels. De nouvelles exigences sont apparues en ce qui concerne l'isolement de plusieurs locataires et l'authentification de plusieurs facteurs, et un ensemble d'éléments précédemment considérés comme des « pratiques exemplaires » est devenu obligatoire après le 31 mars 2025. L'approche personnalisée est également arrivée, permettant à une entité de répondre à l'objectif d'une exigence par des contrôles alternatifs, mais avec des exigences de documentation et de validation qui sont considérablement plus lourdes que de simplement faire la chose telle qu'écrite.

Pour la plupart des organisations, l'effet pratique est que la période de grâce est terminée. Les exigences qui pourraient être reportées sont maintenant évaluées, et le test de segmentation qui était autrefois une annexe silencieuse au test est devenu un produit livrable central de son propre chef.

Est-ce que cela s'applique à vous?

PCI DSS n'est pas une loi. Il s'agit d'une exigence contractuelle imposée par les systèmes de cartes en acquérant des banques et des transformateurs, et elle s'applique à toute entité qui stocke, traite ou transmet des données de cartes quel que soit le pays. Pour les entreprises en Moldavie, l'obligation arrive généralement par l'intermédiaire de la banque d'acquisition ou d'un processeur partenaire, et le niveau de validation dépend du volume annuel des transactions. Cela signifie que le déclencheur est commercial, pas législatif — vous pouvez être pleinement conforme au droit national et être toujours contractuellement requis pour produire un rapport d'attente prochain trimestre.

Si vous vous préparez à cette conversation, le travail utile se produit avant l'arrivée du testeur: dessiner le flux de données réel, vérifier si votre segmentation tient réellement plutôt que de le supposer, et confirmer que celui qui exécute le test est vraiment indépendant de celui qui exécute les systèmes. Ces trois éléments déterminent plus le résultat de votre évaluation que tout autre outil du rapport.