PCI DSS 4.0 : quels sont les changements apportés au SAQ A ?

C’est avec la récente sortie du nouveau standard PCI DSS (Payment Card Industry Data Security Standard) dans sa version 4.0 qu’ont été publiées les nouvelles versions des SAQ (Self Assessment Questionnaire) qui l’accompagnent.

Ceux-ci, comme le référentiel complet, entrent en vigueur dès le 31 mars 2024. Certaines exigences ne sont toutefois qu’à l’état de bonnes pratiques (donc facultatives) jusqu’au 31 mars 2025.

Qu’en est-il de l’un des principaux d’entre eux, le SAQ A ?

Le SAQ A est un formulaire d’auto-évaluation destiné aux marchands et centres de traitement des commandes téléphoniques ou e-mail (MOTO pour mail order, telephone order) ne traitant pas directement les données de cartes bancaires de leurs clients (voir Article « Les questions fréquentes autour du SAQ A »).

En effet, une société est éligible à ce SAQ lorsque cette dernière :

• Réalise moins de 6 millions de transactions par an
• A recours à un prestataire de paiement (payment service provider ou PSP) pour traiter, à sa place, la réception, le stockage et la transmission des données de cartes bancaires.

Cette version très allégée du standard (28 exigences dans le SAQ A contre 250 dans le référentiel complet) se veut simple pour permettre aux entreprises de s’auto-certifier.

Dans les faits, cela s’avère plus complexe et il est souvent nécessaire de passer par un cabinet QSA (Qualified Security Assessor) en capacité d’auditer, mais aussi d’accompagner les clients dans leur stratégie de certification.

Qu’est-ce qui change dans ce nouveau SAQ A avec PCI DSS 4.0 ?

Tout d’abord un point majeur en tête du document : le marchand doit désormais s’assurer de la conformité PCI DSS de ses prestataires en leur demandant une AOC (Attestation of Compliance, document certifiant la conformité PCI DSS d’une entité).

On parle ici de TPSP (Third Party Service Provider), c’est-à-dire de prestataires portant des exigences du SAQ A.

Pour les prestataires de paiement, cela ne change rien : ceux-ci sont déjà certifiés PCI DSS et auront la capacité de fournir une AOC à leurs marchands.

Pour les autres prestataires en revanche, notamment les infogérants, là où il était suffisant de contrôler leur conformité pour les exigences qui les concernaient, il leur faudra désormais certifier leur service de façon complète et être en mesure de fournir une AOC.

Pour l’heure, le PCI SSC ne fournit pas de précisions quant à cette nouvelle formulation, et il est encore possible que la formulation change dans une nouvelle version.

Il est à noter qu’un marchand peut s’appuyer sur la conformité en version 3.2.1 de ses prestataires pour se certifier en version 4, jusqu’à l’expiration de la version 3, le 31 mars 2024.

Par ailleurs, la version 4.0 apporte la notion de customized approaches, qui permet aux clients de répondre différemment à une exigence donnée tout en satisfaisant l’objectif de sécurité que l’exigence cherche à faire atteindre.

Aucun SAQ ne permet l’utilisation de customized approaches à l’heure actuelle. Ce mode est donc réservé aux certifications complètes.

Les changements majeurs du SAQ A

Plusieurs changements sur la version 4.0 sont notables.

Les scans de vulnérabilités (exigences 11.3.2 et 11.3.2.1)

Le SAQ A v4.0 impose désormais un scan de vulnérabilités externe trimestriel « tamponné » ASV (Approved Scanning Vendor, c’est-à-dire un éditeur de scanners de vulnérabilités approuvé par le PCI SSC) sur l’ensemble des URLs publiques du marchand. Les vulnérabilités identifiées par le scan doivent être corrigées et le scan soumis à l’éditeur pour approbation ASV. Sur les versions antérieures, ces scans étaient occasionnellement demandés par les banques en complément de l’Attestation Of Compliance mais rien n’était clairement défini dans une exigence du standard.

Un scan supplémentaire doit être effectué à chaque changement majeur (comprendre, un changement structurant dans le système d’information) sur le périmètre impacté par le changement. Ce dernier, en revanche, n’a pas besoin d’être soumis à l’éditeur pour approbation ASV. Attention à bien faire réaliser le scan par une personne différente des acteurs responsables du changement.

À noter que cette exigence ne devient obligatoire qu’à partir du 31 mars 2025.

Le chargement des iframes (exigences 11.6.1)

Un mécanisme anti-tampering assurant l’intégrité des en-têtes http et des contenus des pages dont le rôle est de charger les iframes du prestataire de paiement doit désormais être présent.

Le moyen le plus simple d’y répondre à l’heure actuelle réside dans la mise en place d’une politique CSP (Content Type Policy) chargée de restreindre les ressources qui vont être appelées par le navigateur (notamment les scripts de construction des iframes). 

Un mécanisme de détection des changements doit être présent sur les reverse proxies ou les CDN (Content Delivery Network).

À noter que cette exigence ne concerne que les marchands utilisant des iframes au moment du paiement et ne devient obligatoire qu’à partir du 31 mars 2025.

Le chargement des ressources externes (exigence 6.4.3)

Tous les scripts chargés sur la page du marchand au moment du paiement ou au moment de la redirection vers la page du prestataire de paiement doivent être inventoriés, autorisés et leur intégrité contrôlée.

Là encore, la politique CSP tout comme la fonctionnalité de SRI (Sub Ressource Integrity) permettent, en partie, de répondre à l’exigence.

À noter que cette exigence ne devient obligatoire qu’à partir du 31 mars 2025.

La politique de mots de passe (exigences 8.3.5, 8.3.6, 8.3.7, 8.3.9)

La politique de mots de passe (password policy) se renforce avec PCI DSS 4.0.

Lorsqu’un mot de passe est affecté à un compte par les administrateurs (lors de la première connexion de l’utilisateur associé ou dans le cas d’une réinitialisation de mot de passe), le nouveau mot de passe renseigné doit être unique et voir son changement imposé dès la première connexion. Il s’agit là d’éviter qu’un attaquant puisse facilement deviner que tous les mots de passe des nouveaux arrivants sont de type « Entreprise2023! ».

La politique PCI DSS 4.0 impose désormais 12 caractères qui doivent au moins être alphanumériques (contre 7 dans la version actuelle de PCI DSS). Toutefois, pour les systèmes historiques ne supportant pas une telle longueur, cette dernière est ramenée à 8 caractères.

La politique de mots de passe PCI DSS 4.0 inclut également un renouvellement des mots de passe tous les 90 jours et une notion de non-réutilisation : un mot de passe ne pourra être identique à l’un des 4 derniers utilisés pour un même compte.

Attention, bien que l’exigence de longueur des mots de passe ne soit effective qu’à partir du 31 mars 2025 (pour le SAQ A), le renouvellement, l’unicité avant la première connexion et la non-réutilisation entrent en vigueur dès le 31 mars 2024.

Les changements mineurs du SAQ A dû à la version 4 du PCI DSS

Gestion des mises à jour (exigences 6.3.1, 6.3.3)

La gestion des correctifs de sécurité (patch management) se complète et contient désormais les notions de veille en vulnérabilités (l’ensemble des moyens permettant de se tenir informé de la publication de nouvelles vulnérabilités) et de qualification (c’est-à-dire l’évaluation de la criticité d’une vulnérabilité en fonction du périmètre affecté et des risques associés). Un score associé à chaque vulnérabilité affectant le périmètre doit permettre d’identifier les sévérités haute et critique.

À noter que celle-ci peut se faire par des services professionnels tel que le service de veille Yuno de notre cabinet.

Comptes génériques et partagés (exigences 8.2.2)

L’utilisation de comptes non-nominatifs (génériques ou partagés), auparavant interdite en dépit des besoins de la production, est désormais encadrée. L’utilisation de ces comptes ne peut se faire qu’en cas d’incident, doit être approuvée explicitement et les mots de passe associés ne peuvent être ceux fournis par défaut par les éditeurs.

Stockage papier (exigence 9.4.1.1)

Et enfin, pour les marchands qui stockent des données de carte au format papier, il leur faudra désormais les ranger dans un lieu sécurisé (secured location), c’est-à-dire un lieu accessible uniquement au personnel autorisé.