En bref : référence des 12 exigences PCI DSS 4.0.1
- Au-delà des 12 : PCI DSS compte 12 exigences de haut niveau. Tout le monde cite ce chiffre et s'arrête là. Le fait intéressant est que 4.0.1 comporte désormais plus de 400 sous-exigences, et les deux que la plupart échouent sont les plus récentes, pour lesquelles personne n'avait de preuves avant 2025.
- Les deux les plus échouées : PCI DSS 4.0.1 est devenu obligatoire en mars 2025. Les exigences 6.4.3 (inventaire de scripts, justification métier, vérification d'intégrité, détection de changement) et 11.6.1 (surveillance des en-têtes HTTP sur les pages de paiement) sont les deux les moins préparées dans les évaluations actuelles. cside produit les deux artefacts en continu.
- Par où commencer : Si vous cadrez une évaluation 4.0.1 sans inventaire de scripts ni surveillance d'en-têtes, commencez par là avant de toucher aux Exigences 3 ou 12. Si vos preuves 6.4.3 et 11.6.1 circulent déjà, concentrez-vous ensuite sur la revue du scope creep et le déploiement MFA sous 8.4.2.
Peu de temps ? Découvrez cside PCI Shield. Elle couvre tout ce qui suit en un seul déploiement.
Les 12 exigences PCI DSS sont le cœur de la norme de sécurité des données de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard). Toute entité qui stocke, traite ou transmet des données de carte doit les respecter. Voici la référence pratique de ce que couvre chaque exigence dans PCI DSS 4.0.1, de ce qui a changé depuis la 3.2.1 et des endroits où la plupart des environnements présentent des lacunes.
La structure : 6 objectifs, 12 exigences
PCI DSS organise ses contrôles autour de six objectifs de sécurité. Chaque objectif regroupe une ou plusieurs des 12 exigences principales. Chaque exigence contient plusieurs sous-exigences, et le nombre total de sous-exigences dans la 4.0.1 dépasse 400.
Objectif 1 : construire et maintenir un réseau et des systèmes sécurisés
Exigence 1 : installer et maintenir des contrôles de sécurité réseau. Les pare-feu, les configurations de routeurs et la segmentation du réseau doivent isoler l'environnement des données de titulaires de cartes des réseaux non fiables. Chaque règle doit s'appuyer sur une justification métier documentée.
Exigence 2 : appliquer des configurations sécurisées à tous les composants système. Pas de mots de passe par défaut, pas de comptes par défaut, pas de services inutiles. Les référentiels de durcissement doivent être documentés et appliqués à chaque système.
Objectif 2 : protéger les données de compte
Exigence 3 : protéger les données de compte stockées. Les données de titulaires de cartes doivent être chiffrées au repos à l'aide d'une cryptographie forte. Les données d'authentification sensibles (CVV, PIN, piste complète) ne doivent pas être conservées après l'autorisation. Si vous n'avez pas besoin de stocker des données de titulaires de cartes, ne le faites pas. Le chemin le plus rapide vers la conformité à l'exigence 3 consiste à ne pas détenir les données.
Exigence 4 : protéger les données de titulaires de cartes par une cryptographie forte pendant la transmission. TLS 1.2 ou supérieur sur les réseaux publics. Les protocoles obsolètes et les chiffrements faibles doivent être inventoriés et supprimés.
Objectif 3 : maintenir un programme de gestion des vulnérabilités
Exigence 5 : protéger tous les systèmes et réseaux contre les logiciels malveillants. Des contrôles anti-malware sur tous les systèmes du CDE. Des analyses régulières et des mises à jour des définitions.
Exigence 6 : développer et maintenir des systèmes et des logiciels sécurisés. Gestion des correctifs, pratiques de codage sécurisé, gestion des changements. C'est ici que se trouve l'exigence 6.4.3 : l'inventaire des scripts côté client et le contrôle d'intégrité qui étaient nouveaux dans la 4.0. Consultez notre guide pratique de mise en conformité avec PCI 6.4.3 et 11.6.1 pour la mise en œuvre concrète.
Objectif 4 : mettre en œuvre des mesures de contrôle d'accès strictes
Exigence 7 : restreindre l'accès aux composants système et aux données de titulaires de cartes selon le principe du besoin d'en connaître. Contrôles d'accès basés sur les rôles, moindre privilège, approbation d'accès documentée.
Exigence 8 : identifier les utilisateurs et authentifier l'accès aux composants système. Des identifiants uniques pour chaque utilisateur, des règles de mot de passe robustes, la MFA sur tous les accès administratifs au CDE (renforcée dans la 4.0.1 au titre de la 8.4.2).
Exigence 9 : restreindre l'accès physique aux données de titulaires de cartes. Des contrôles physiques sur les locaux qui stockent des données de titulaires de cartes ou hébergent des systèmes du CDE.
Objectif 5 : surveiller et tester régulièrement les réseaux
Exigence 10 : journaliser et surveiller tous les accès aux composants système et aux données de titulaires de cartes. Journalisation exhaustive, intégrité des journaux, revue des journaux et synchronisation horaire entre les systèmes.
Exigence 11 : tester régulièrement la sécurité des systèmes et des réseaux. Analyses de vulnérabilités (internes et externes, trimestrielles), tests d'intrusion (annuels + après tout changement significatif) et, point critique pour la 4.0.1, l'exigence 11.6.1 qui couvre la surveillance des en-têtes HTTP sur les pages de paiement.
Objectif 6 : maintenir une politique de sécurité de l'information
Exigence 12 : soutenir la sécurité de l'information par des politiques et des programmes organisationnels. Politique de sécurité, évaluation des risques, sensibilisation à la sécurité, réponse aux incidents, gestion des fournisseurs. L'exigence 12 est l'exigence-cadre qui rattache chaque autre contrôle à un engagement organisationnel.
Ce qui est nouveau dans la 4.0.1 par rapport à la 3.2.1
PCI DSS 4.0.1 est devenue obligatoire en mars 2025. Les changements les plus importants depuis la 3.2.1 :
| Changement | Exigence | Impact |
|---|---|---|
| Inventaire des scripts + intégrité sur les pages de paiement | 6.4.3 | La plupart des environnements n'avaient aucune couverture avant 2025 |
| Surveillance des en-têtes HTTP sur les pages de paiement | 11.6.1 | Idem, nouvel artefact requis |
| Règles de mot de passe renforcées | 8.3.6 | Minimum de 12 caractères |
| MFA sur les accès administratifs au CDE | 8.4.2 | S'applique à l'administration hors console, pas seulement à distance |
| Inventaire cryptographique | 12.3.3 | Documentation des chiffrements et des protocoles |
| Rétention et revue des journaux | 10.7.2/3 | Exigences de revue des journaux étendues |
| Approche personnalisée | Plusieurs | Nouvelle alternative à l'approche définie pour les contrôles |
L'approche personnalisée permet aux organisations de répondre à l'intention d'une exigence avec un contrôle différent de celui que prescrit la norme, à condition de documenter formellement l'analyse des risques et les contrôles. Elle est puissante pour les programmes de sécurité matures et dangereuse pour les organisations qui l'utilisent pour justifier des contrôles plus faibles.
Où les audits se bloquent
En accompagnant des commerçants dans leurs évaluations 4.0.1, trois schémas reviennent régulièrement :
- Exigences 6.4.3 et 11.6.1 : pas d'inventaire des scripts, pas de surveillance de l'intégrité, pas de surveillance des en-têtes HTTP. Consultez le guide QSA pour savoir ce que recherchent précisément les auditeurs.
- Dérive du périmètre : le CDE englobe plus de systèmes que ne le montrait le schéma de périmètre initial, généralement parce que la segmentation est plus faible que supposé
- Preuves manuelles : les QSA ont besoin de preuves continues, pas de captures d'écran prises pendant la semaine d'évaluation
La liste complète des exigences PCI DSS
PCI DSS 4.0.1 s'organise en 6 objectifs et 12 exigences. La liste complète des exigences PCI DSS est la suivante :
- Installer et maintenir des contrôles de sécurité réseau.
- Appliquer des configurations sécurisées à tous les composants système.
- Protéger les données de compte stockées.
- Protéger les données de titulaires de cartes par une cryptographie forte pendant la transmission sur des réseaux publics ouverts.
- Protéger tous les systèmes et réseaux contre les logiciels malveillants.
- Développer et maintenir des systèmes et des logiciels sécurisés.
- Restreindre l'accès aux composants système et aux données de titulaires de cartes selon le principe du besoin d'en connaître.
- Identifier les utilisateurs et authentifier l'accès aux composants système.
- Restreindre l'accès physique aux données de titulaires de cartes.
- Journaliser et surveiller tous les accès aux composants système et aux données de titulaires de cartes.
- Tester régulièrement la sécurité des systèmes et des réseaux.
- Soutenir la sécurité de l'information par des politiques et des programmes organisationnels.
Les exigences 6.4.3 et 11.6.1, toutes deux relevant de l'exigence 6 et de l'exigence 11 ci-dessus, sont le lieu où réside la sécurité des scripts côté client : la 6.4.3 régit l'inventaire et l'autorisation des scripts des pages de paiement, et la 11.6.1 impose la détection des changements et des altérations sur ces scripts et sur les en-têtes HTTP critiques.
Où cside intervient
Les exigences 6.4.3 et 11.6.1 sont le terrain de prédilection de cside. Inventaire continu des scripts, étiquetage par justification métier, surveillance de l'intégrité, détection des changements d'en-têtes HTTP et historique d'alertes prêt pour l'audit proviennent de la plateforme. Le guide de conformité aux exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 détaille ce que produit le tableau de bord et comment un QSA le lit.
Pour une vue d'ensemble de la préparation à une évaluation complète, consultez le guide du Report on Compliance et le guide du SAQ D.
