La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS), qui a fait l'objet d'une mise à jour majeure en mars 2022, a été révisée.

Cette révision limitée, PCI DSS v4.0.1, reflète les commentaires de la communauté et inclut plusieurs corrections et clarifications conçues pour améliorer la convivialité et l'efficacité de la norme pour les organisations qui traitent, stockent, transmettent ou influencent la sécurité des données des titulaires de carte et/ou des données d'authentification sensibles.

Comme il peut être difficile de suivre les dernières modifications des exigences de conformité comme le PCI DSS, Secureframe fait partie de sa mission de tenir les clients informés de tout changement pouvant affecter leur environnement et de maintenir la plateforme Secureframe à jour.

Conformément à cette mission, nous allons expliquer les changements apportés dans le PCI DSS 4.0.1 et ce qu'ils signifient pour votre organisation.

Qu'est-ce que le PCI DSS v4.0.1 ?

Le PCI DSS v4.0.1 est une révision limitée du PCI DSS v4.0 qui répond aux commentaires et questions des parties prenantes reçus depuis la publication de la version 4.0 en mars 2022. Cette révision démontre l'effort continu pour encourager et améliorer la sécurité des données des comptes de paiement et faciliter l'adoption générale de mesures de sécurité des données cohérentes à l'échelle mondiale.

Étant donné que le PCI DSS 4.0.1 est une révision limitée, il n'y a pas de changements majeurs, tels que l'ajout ou la suppression d'exigences. Au lieu de cela, cette dernière version inclut des corrections de mise en forme et d'erreurs typographiques ainsi qu'une clarification de l'objectif et de l'intention de certaines exigences et orientations.

Changements PCI DSS 4.0.1 en un coup d'œil

Tous les changements dans le PCI DSS 4.0.1 se répartissent en deux catégories :

1. Clarification ou orientation : Cela fait référence à toutes les mises à jour de formulation, d'explication, de définition, d'orientation supplémentaire et/ou d'instruction faites pour augmenter la compréhension ou fournir des informations ou des orientations supplémentaires sur un sujet particulier. Ce type de changement constitue la majeure partie des changements dans la version 4.0.1.
2. Structure ou format : Cela fait référence à toute réorganisation de contenu, y compris la combinaison, la séparation et la renumérotation des exigences pour mieux aligner le contenu.

Examinons de plus près ces changements ci-dessous.

Correction ou mise à jour du libellé ou du formatage

PCI DSS 4.0.1 inclut des corrections pour des erreurs typographiques et d'autres erreurs mineures, comme des en-têtes manquants.

Par exemple, toutes les instances de la phrase « impacte la sécurité du CDE » dans la version 4.0 ont été modifiées en « impacte la sécurité des données des titulaires de carte et/ou des données d'authentification sensibles » dans la version 4.0.1. De plus, les procédures de test ont été mises à jour pour s'aligner sur la formulation des exigences mises à jour dans la version 4.0.1.

Le but de ces corrections et ajustements mineurs est d'améliorer la lisibilité et l'efficacité de la norme.

Mise à jour des annexes et suppression des modèles

Il y a également eu plusieurs changements concernant le glossaire ou l'annexe G. Tout d'abord, toutes les définitions incluses dans les conseils qui étaient également incluses dans le glossaire ont été supprimées dans la version 4.0.1. Les conseils se réfèrent désormais au glossaire.

Également dans la version 4.0.1, il y a des références supplémentaires au glossaire pour les nouveaux termes définis (comme « exception légale » et « visiteur ») ainsi que pour les termes existants qui n'avaient pas de références auparavant.

L'autre changement majeur concerne l'annexe E. Dans la version 4.0.1, les modèles d'approche personnalisée ont été supprimés et l'annexe note que les modèles sont disponibles sur le site Web du PCI SSC.

Ajout ou clarification des notes d'applicabilité

Plus particulièrement, PCI DSS 4.0.1 contient des conseils mis à jour et clarifiés pour plusieurs exigences, en particulier concernant les notes d'applicabilité. Ci-dessous, nous donnerons un aperçu des changements d'applicabilité les plus importants :

Exigence 3 : Protéger les données de compte stockées

Qui est concerné : Émetteurs et entreprises soutenant les services d'émission

L'exigence 3.3.1 stipule que les données d'authentification sensibles (DAS) ne sont pas stockées après autorisation, même si elles sont cryptées, et l'exigence 3.3.2 stipule que les DAS stockées électroniquement avant l'achèvement de l'autorisation sont cryptées à l'aide d'une cryptographie robuste. Dans PCI DSS 4.0, il n'était pas clair si les émetteurs et les entreprises soutenant les services d'émission devaient respecter ces exigences.

PCI DSS 4.0.1 clarifie que les exigences 3.3.1 et 3.3.1 ne s'appliquent pas aux émetteurs et aux entreprises soutenant les services d'émission qui ont un « besoin professionnel légitime et documenté » de stocker les DAS.

De plus, la version 4.0.1 clarifie que pour les organisations utilisant des hachages cryptographiques à clé pour rendre les numéros de compte principaux (PAN) illisibles afin de répondre à l'exigence 3.5.1, cette exigence s'applique aux PAN stockés dans le stockage principal (comme les bases de données) et le stockage non principal (comme les journaux d'audit).

Exigence 6 : Développer et maintenir des systèmes et des logiciels sécurisés

Qui est concerné : Organisations avec des vulnérabilités critiques et à haut risque

Dans PCI 4.0, l'exigence 6.3.3 stipule que les correctifs/mises à jour pour les vulnérabilités critiques et à haut risque doivent être installés dans un délai d'un mois après leur publication. La version 4.0.1 est revenue au langage du PCI DSS v3.2.1 qui stipule que la nécessité d'installer des correctifs/mises à jour dans les 30 jours ne s'applique qu'aux vulnérabilités critiques, pas à celles à haut risque.

Qui est concerné : Organisations redirigeant ou intégrant un service tiers pour le paiement

L'exigence 6.4.3 stipule comment gérer les scripts de page de paiement qui sont chargés et exécutés dans le navigateur du consommateur. Dans PCI DSS 4.0, il n'était pas clair si cela s'appliquait aux commerçants intégrant des pages/formulaires de paiement de fournisseurs de services tiers (TPSP) ou de processeurs de paiement. La version 4.0.1 clarifie que cela s'applique à ces commerçants, mais que la responsabilité de la conformité des scripts est partagée entre le commerçant et le TPSP de sorte que le commerçant possède les scripts et les en-têtes en dehors de l'iframe intégré du TPSP et le TPSP possède ceux à l'intérieur de l'iframe intégré du TSPS.

Exigence 8 : Identifier les utilisateurs et authentifier l'accès aux composants du système

Qui est concerné : Organisations avec des comptes utilisateurs uniquement authentifiés avec des facteurs d'authentification résistants au phishing.

La condition 8.4.3 stipule que l'AMF est mise en œuvre pour tous les accès non-console au CDE. La version 4.0.1 de PCI DSS a ajouté une exception, précisant que cette exigence ne s'applique pas aux comptes utilisateurs qui sont uniquement authentifiés avec des facteurs d'authentification résistants au hameçonnage.

Condition 12 : Soutenir la sécurité de l'information avec des politiques et des programmes organisationnels

Qui cela concerne : Les organisations qui engagent des fournisseurs de services tiers (TPSP) pour stocker, traiter ou transmettre des données de compte ou pour gérer les composants du système en périmètre en leur nom, ainsi que les TPSP eux-mêmes.

Les organisations peuvent engager des fournisseurs de services tiers pour stocker, traiter ou transmettre des données de compte ou pour gérer les composants du système en périmètre en leur nom. La condition 12.8 traite de la gestion de ces relations TPSP et la condition 12.9 traite de la manière dont les TPSP soutiennent la conformité PCI DSS de leurs clients.

La version 4.0.1 de PCI DSS clarifie plusieurs points concernant les relations entre les clients et les fournisseurs de services tiers (TPSP).

Par exemple, la version 4.0.1 de PCI DSS précise que, selon la condition 12.9.2, tous les TPSP sont tenus de soutenir les demandes de leurs clients concernant des informations sur l’état de conformité PCI DSS du TPSP en relation avec les services fournis aux clients. En outre, pour les TPSP qui fournissent des services répondant aux exigences PCI DSS des clients ou qui peuvent avoir un impact sur la sécurité des données de compte des clients, ils doivent également soutenir les demandes de leurs clients concernant les exigences PCI DSS qui relèvent de la responsabilité du TPSP, celles qui relèvent de la responsabilité du client, et toutes les responsabilités partagées entre le client et le TPSP.

Quand la version 4.0.1 de PCI DSS entre-t-elle en vigueur ?

La version 4.0.1 de PCI DSS a été publiée le 11 juin 2024 et est en vigueur aujourd'hui. Jusqu'au 31 décembre 2024, la version précédente de PCI DSS—v4.0—restera également active pour donner aux organisations le temps d'adopter la dernière version de la norme.
Après le 31 décembre 2024, la version 4.0 de PCI DSS sera retirée et la version 4.0.1 deviendra la seule version active de la norme.

Comment Secureframe peut vous aider à vous conformer à la version 4.0.1 de PCI DSS

Que vous soyez déjà certifié PCI ou que vous poursuiviez la certification PCI pour la première fois, vous devez prendre les mesures suivantes pour commencer à passer à la version 4.0.1 de PCI DSS.
Pour commencer, consultez le résumé des modifications de la version 4.0 à la version 4.0.1 de PCI DSS, disponible dès maintenant dans la PCI SSC Document Library, pour une comparaison approfondie.

Si vous êtes client de Secureframe, vous pouvez contacter votre responsable de la conformité pour avoir une discussion approfondie sur votre environnement actuel et votre périmètre afin d'aider à déterminer exactement quels contrôles sont applicables à vous et comment vous pouvez les mettre en œuvre dans votre environnement afin de répondre aux changements de la version 4.0.1.

Vous pouvez ensuite utiliser la plateforme Secureframe pour assigner des responsables aux tâches, contrôles et revues, gérer l'achèvement de la formation à la sensibilisation à la sécurité et l'acceptation des politiques, compléter d'autres travaux de préparation, et remédier aux tests automatisés avec le soutien de nos gestionnaires de conformité. Les gestionnaires de conformité Secureframe peuvent également effectuer une évaluation des écarts avec vous avant votre audit afin que vous puissiez être sûr de votre conformité PCI DSS v 4.0.1 avant que votre auditeur ne réalise l'évaluation réelle.

Enfin, vous pouvez sélectionner l'un de nos QSA partenaires pour réaliser les travaux de terrain directement sur la plateforme.

Pour plus d'informations sur la façon dont vous pouvez vous conformer au PCI DSS v4.0.1 d'ici le 31 décembre 2024, planifiez une démonstration avec l'un de nos experts produits dès aujourd'hui.