Exigences PCI DSS 4.0 : Une exploration approfondie des derniers changements et de leur impact sur votre organisation
Publiée le 31 mars 2022, la dernière version du Standard de sécurité des données de l'industrie des cartes de paiement — PCI DSS 4.0 — est actuellement en vigueur. Elle deviendra la seule version active le 31 mars 2024.
D'ici au 31 mars 2025, les organisations devront également adopter les exigences qui ont été identifiées comme datées futures dans la version 4.0.
Pour respecter ces échéances de conformité, les organisations qui stockent, traitent, transmettent ou impactent la sécurité des données des titulaires de cartes doivent :
- réviser les changements dans la version 4.0
- mettre en œuvre de nouveaux contrôles pour répondre aux exigences mises à jour et nouvelles de la version 4.0
- mettre à jour leurs modèles de rapports et formulaires
- commencer à mettre en œuvre les exigences datées futures pour être évaluées au plus tard le 31 mars 2025
Cela peut être difficile à faire seul. C’est pourquoi Marc Rubbinaccio, un ancien QSA et actuellement expert en la matière pour PCI DSS chez Secureframe, et Jonathan Smith, un QSA chez Moss Adams, ont animé un webinaire d'experts Secureframe Insights le 11 mai.
Ils ont fourni une analyse approfondie des changements les plus significatifs pour PCI DSS 4.0 et des conseils sur la manière de se conformer. Continuez à lire ou regardez la rediffusion vidéo à la demande pour obtenir leurs perspectives.
Exigences PCI DSS 4.0 vs 3.2.1
À mesure que les technologies et les paysages des menaces évoluent rapidement, les cadres de sécurité conçus pour protéger les organisations contre les incidents et les violations de sécurité doivent suivre le rythme. C’est pourquoi des cadres comme PCI DSS sont régulièrement mis à jour.
Bien qu'il puisse être difficile de suivre les derniers changements des exigences de conformité PCI DSS, les organisations qui s'adaptent seront les plus aptes à protéger les données de paiement.
Voici les principales différences entre PCI DSS version 4.0 et 3.2.1 et pourquoi vous devriez vous conformer à la dernière itération.
1. Continuer à évoluer
L'un des principaux objectifs de PCI DSS 4.0 est de continuer à faire évoluer la norme pour répondre aux besoins changeants de l'industrie des cartes de paiement et des nouvelles technologies mises en œuvre quotidiennement. C’est pourquoi PCI DSS 4.0 contient des mises à jour sur l'authentification multi-facteurs, les exigences de mot de passe et de sensibilisation à la sécurité ainsi que de nouvelles exigences pour le commerce électronique.
Exigences d'authentification multi-facteurs et de mot de passe
Un sujet majeur de discussion dans la communauté de la sécurité est la meilleure façon de sécuriser l'authentification sans entraver la capacité des utilisateurs à se connecter aux systèmes et à effectuer leur travail réel.
Un bon exemple de cela est la révision par le NIST de leurs exigences de mot de passe il y a quelques années pour traiter spécifiquement la manière dont les mots de passe étaient piratés dans le monde réel. Le PCI DSS 4.0 a amélioré les exigences d'authentification, imposant l'authentification multifactorielle pour tous les utilisateurs accédant à l'environnement des données des titulaires de carte, pas seulement les administrateurs. Les exigences de longueur de mot de passe ont également été augmentées de 8 à 12 caractères. Enfin, au lieu de devoir faire tourner tous les mots de passe après 90 jours, le PCI DSS donne maintenant aux organisations l'option d'utiliser une analyse dynamique pour déterminer automatiquement l'accès aux ressources.
Exigences de sensibilisation à la sécurité
L'ingénierie sociale, et le phishing en particulier, est encore l'un des moyens les plus répandus pour les attaquants d'accéder aux systèmes et de voler les données des titulaires de carte. Peu importe la force de vos configurations de sécurité cloud et d'application, si un employé ayant accès à des données sensibles tombe dans un piège de spear phishing, les pirates pourraient obtenir le même accès et commencer à divulguer les données des titulaires de carte.
En conséquence, le PCI DSS renforce sa position sur la formation à la sensibilisation à la sécurité en exigeant que des menaces et des vulnérabilités spécifiques soient incluses dans les programmes de formation des organisations. Par exemple, si vous êtes un commerçant en ligne et offrez une assistance par chat, votre personnel de support devrait être conscient des types spécifiques d'attaques de phishing qui pourraient se produire lors de chats en direct.
La formation à la sensibilisation à la sécurité doit également être revue et mise à jour chaque année en fonction des changements dans l'environnement ou des risques potentiels.
Une autre addition aux exigences de sensibilisation à la sécurité est la délimitation de l'utilisation acceptable de toutes les technologies de l'utilisateur final, y compris l'accès et l'utilisation des postes de travail et la compréhension des conséquences de ne pas adhérer à ces politiques d'utilisation acceptable.
Exigences pour le commerce électronique
L'un des changements les plus importants et ayant le plus d'impact dans le PCI DSS 4.0 concerne la gestion et le traitement des scripts dans les pages de paiement et les pages adjacentes aux paiements.
Avant le PCI DSS 4.0, il n'y avait pas d'exigences spécifiques concernant la gestion des scripts exécutés et chargés dans les navigateurs des consommateurs. Cela a conduit à la prévalence des attaques Magecart, qui ciblaient principalement les commerçants en ligne. Les pirates injectaient leur propre code dans les pages de paiement pour détourner les formulaires des titulaires de carte ou rediriger les consommateurs vers des sites web malveillants.
2. Promouvoir la sécurité continue
Un autre objectif du PCI DSS v4.0 est de soutenir des processus continus et à long terme pour protéger les données de paiement.
Un problème courant parmi les organisations poursuivant la conformité PCI est qu'elles investissent massivement dans la mise en œuvre de processus, de procédures et de configurations juste avant leur évaluation – puis elles reçoivent leur certification et le PCI DSS devient une réflexion après coup pour les 11 mois suivants. En conséquence, de nombreuses organisations poursuivant la recertification manquent des examens réguliers tout au long de l'année en raison de contrôles mal organisés. Cela peut conduire soit à la non-conformité au PCI, soit à l'auditeur devant rédiger un contrôle compensatoire basé sur la manière dont l'organisation dépasserait et irait au-delà pour répondre à ce contrôle l'année suivante.
Un écart majeur que le PCI DSS 4.0 cherche à combler est le renforcement de l'attribution de responsabilité pour les contrôles de sécurité. Maintenant, au lieu de simplement indiquer que des scans de vulnérabilité trimestriels seront effectués, l'organisation doit indiquer qui dans l'organisation est responsable de respecter ce contrôle et de diriger tous les autres contrôles de sécurité PCI DSS.
Un autre aspect qui a été précédemment négligé est la portée du PCI DSS. Délimiter votre environnement de données des titulaires de carte est essentiel pour s'assurer que toutes les ressources et le personnel concernés sont inclus dans la portée de l'audit ainsi que dans la portée de tous les contrôles de sécurité, configurations et examens requis. Auparavant, si des modifications étaient apportées au cours de la période d'audit pouvant affecter votre portée, l'auditeur ne le découvrirait que lorsque l'audit de l'année suivante est sur le point de commencer. Avec le PCI DSS 4.0, une organisation est maintenant tenue de revoir et de documenter sa portée PCI DSS tout au long de l'année. Cela garantit que l'organisation maintient la conformité au PCI DSS avec précision.
3. Permettre de la flexibilité
Pour aider les organisations à prioriser la sécurité comme un processus continu, le PCI DSS 4.0 offre également une flexibilité supplémentaire. Cette flexibilité vise à permettre aux organisations de choisir les contrôles de sécurité les mieux adaptés à leurs besoins commerciaux et de sécurité. Cela se reflète de deux manières principales dans le PCI DSS 4.0.
Un changement significatif dans PCI DSS 4.0 consiste à changer l'état d'esprit des organisations en matière de gestion des risques. Auparavant, les organisations étaient tenues de réaliser une évaluation complète des risques annuelle ainsi que des tests d'intervalle définis par le PCI DSS, avec certaines tâches quotidiennes, semestrielles ou trimestrielles. Avec PCI DSS 4.0, non seulement une évaluation complète des risques annuelle doit être effectuée, mais les tests d'intervalle peuvent maintenant être spécifiquement définis par l'organisation en fonction des risques. Par exemple, les revues d'accès peuvent maintenant être effectuées à un intervalle régulier qui a le plus de sens pour l'organisation en fonction des risques définis.
PCI DSS 4.0 a également introduit l'approche personnalisée, une deuxième méthode permettant aux entités de répondre aux strictes exigences de PCI DSS. L'approche personnalisée offre aux organisations la flexibilité de répondre aux objectifs de sécurité des exigences PCI DSS en utilisant de nouvelles technologies et des contrôles innovants. L'assesseur validera que les contrôles personnalisés répondent aux exigences PCI DSS en examinant la documentation de l'approche personnalisée de l'entité et en développant une procédure de validation des contrôles par l'approche personnalisée.
Pour être clair, cela nécessitera un travail et une documentation supplémentaires de la part de l'organisation. Il sera finalement plus facile de répondre à l'exigence telle que définie par PCI DSS, mais certaines organisations matures peuvent opter pour une approche personnalisée.
4. Validation améliorée
Un autre changement majeur apporté par PCI DSS est de permettre désormais aux organisations de réaliser des évaluations partielles.
Auparavant, si une exigence n'était pas testée par l'auditeur, l'organisation était automatiquement considérée comme non conforme. Désormais, avec PCI DSS 4.0, les organisations ont la flexibilité de ne tester qu'un certain aspect de leur service à la demande d'un client et un QSA signera que les contrôles testés étaient conformes à PCI DSS.
Lecture recommandée
Histoire de PCI : Comment la norme est devenue
Lectures recommandées
Accélérer la conformité PCI DSS avec Secureframe
Exigences PCI DSS 4.0 et comment les respecter
Avec les changements dans PCI DSS 4.0, les organisations sont mises au défi de se conformer à des centaines d'exigences mises à jour ou nouvelles d'ici mars 2024 et des exigences à date future d'ici mars 2025. Pour aider, nous avons fourni un aperçu des exigences PCI DSS 4.0 les plus significatives et des conseils sur la manière de se conformer dans les tableaux ci-dessous.
| Must be performed immediately for all 4.0 assessments | What changed? | How to meet this requirement |
|---|---|---|
| All Requirement Sections | Roles and responsibilities for performing activities in each requirement must be documented, assigned, and understood. | Use a responsibility assignment matrix to assign owners. Can be done within a platform like Secureframe. |
| Requirement 8 | Increased the number of invalid authentication attempts before locking out a user ID to ten attempts. | Set threshold for invalid authentication attempts before locking out to ten attempts. |
| Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days. | Use dynamic analysis, a solution that takes multiple data points and determines in real time if an account should gain access. | |
| Requirement 9 | Restrict access to consoles in sensitive areas via locking when not in use. | Lock the login screens of consoles when not in use. |
| Requirement 12 | Added requirement for personnel to formally acknowledge their responsibilities. | Include the security responsibilities of all roles within the organization in your information security policy. |
| Perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. | Implement a controls matrix and risk analysis for controls being met via customized approach (see appendix D/E of PCI 4.0 for more information). | |
| Document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. | Develop a document that contains info related to the storage of CHD (purpose, retention, elements, access, encryption), internal systems and apps consisting of the CDE, and connections to vendors or third parties. | |
| Service providers must support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. | Document a process for obtaining PCI AOC’s from third-party service providers as well as a plan for receiving evidence in case the TPSP is not PCI compliant. |
| Future-dated requirements effective in 2025 | What changed? | How to meet this requirement |
|---|---|---|
| Requirement 3 | Include locations of stored SAD prior to authorization in data retention / disposal policies, procedures and processes. | Inventory SAD data flows to understand where it goes (will involve product/development). |
| Issuers must define business justification for the storage of sensitive authentication data. | In a policy or similar document, state the instances of stored sensitive authentication data, and the justification for the storage of that data. | |
| Encrypt SAD that is stored electronically prior to authorization. | Utilize the same processes to encrypt SAD that is used for PAN (but consider utilizing different keys for SAD vs PAN). | |
| Establish technical controls to prevent copying of PAN when using remote-access technologies. Document a list of personnel allowed to copy or relocate PAN data. | Identify a solution that will help stop the copying of PAN. Can be DLP, PCoIP, blocking of copy/paste functions over RDP, etc. | |
| When hashing is used to render PAN unreadable, ensure all aspects of the hash is documented and the hashing method results in keyed cryptographic hashes of the entire PAN. | When hashing, use cryptographic keys. | |
| If disk level/partition level or transparent encryption is used to render PAN unreadable, it must only be used on removable media devices. | If your cloud solution uses transparent encryption (i.e. the decryption process is tied with user access such that data is automatically encrypted), implement an additional layer of encryption. | |
| Service providers must document the prevention of shared cryptographic keys between production and test environments. | Document how keys are different between production and test environments. | |
| Requirement 4 | Any certificates used to protect PAN data over open / public networks must be confirmed to be valid and not expired. All certificates and trusted keys must be maintained in a documented inventory. | Inventory all card flows over the Internet. Document where you control the encryption (i.e. your website) and where another organization controls encryption (i.e. their website/API). Make sure that your certificates are signed and that you don’t transmit PAN to an organization with an expired certificate. |
| Requirement 5 | Any systems not commonly affected by malware must have a defined periodic risk review. Malware scans must be defined by the organization based on risk. | Perform a risk assessment that can be based upon documented risks - not a knee jerk reaction. |
| Removable media must be reviewed for malware either automatically when attached to systems, or through analysis of those systems when removable media is attached. | Ensure your AV product can support scanning of removable media. | |
| Implement an automated mechanism for detecting and protecting personnel against phishing attacks. | Implement anti-spoofing controls through an email provider and link-scrubbers or anti-malware technology. | |
| Requirement 6 | Maintain an inventory of bespoke and custom software including third-party integrated components. | Utilize tools and/or manual processes to enumerate libraries. (something like Snyk should be able to help). |
| Implement an automated technical solution to detect and prevent web application attacks such as a web application firewall (WAF). Implement methods to determine all payment page scripts are authorized, maintaining integrity, and documented in a script inventory. | The integrity of scripts can be enforced by several different mechanisms including, but not limited to: sub-resource integrity (SRI), a CSP, and proprietary script or tag-management systems, which can prevent malicious script execution. A tool like SourceDefence can help with this. | |
| Requirement 7 | All user accounts and privileges need to be reviewed at least every six months to ensure access is granted based on job function. | Make sure to account for job transfers. Folks who are transferred who don’t need as much access commonly fall through these processes. |
| Application and system accounts must be managed based on least privilege and reviewed periodically based on risk. | Inventory non-user accounts, then ascertain guardrails in how these accounts should be used (limit admin permissions, restricting hours of use, ability to be used for remote access, etc.). | |
| Requirement 8 | Increased minimum password length from seven to 12 characters. | Use passwords with at least 12 characters. |
| If passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or utilize zero trust (Service Providers only). | Analyze if you would like to rotate passwords or implement zero trust (i.e only allowing logon for various parameters, like geolocation, time of day, etc.). | |
| Implement MFA for all access into the cardholder data environment, not just non-console remote access. | The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. | |
| Secure the implementation of the MFA system. | Make sure MFA can’t be bypassed and isn’t susceptible to replay attacks. | |
| Manage the use of system / application accounts with interactive login. | Try to disable interactive use of application accounts. If not, there will be five actions that need to be taken: time limited, business justification, approval, user identity is confirmed, and user attribution is tracked. | |
| Do not hard-code passwords/passphrases into files or scripts for any application / system accounts that can be used for interactive login. | Utilize code repository functions to detect accounts/passwords. | |
| Implement practices for protecting passwords for application and system accounts against misuse. | Prepare to rotate system passwords, and make sure their password/rotation mix makes sense. | |
| Requirement 9 | Perform periodic POI device inspections based on risk. | Define how often this review is to be performed. |
| Requirement 10 | Utilize automated mechanisms to perform audit log reviews. | Make sure any systems you were doing manual logs in can ship logs to your SIEM. |
| Implement controls to detect, alert, and address / respond to failures of critical security control systems (new for merchants). | Service providers have been doing this requirement — now merchants will need to. Figure out how you can detect when a security control fails (ie. who watches the watcher). | |
| Requirement 11 | Manage all non-critical and non-high-risk ranked vulnerabilities found during internal vulnerability scans. | Make sure you start focusing on medium/lower risk vulnerability churn. |
| Perform authenticated internal vulnerability scanning. | Make sure your vulnerability scanning tool can do authenticated scans. Inventory all targets to see if they can accept authenticated scans. Set up credentials, and manage credentials in accordance with requirements in section 8. | |
| Multi-tenant service providers must support their customers' need for external penetration testing. | Set up a contracts process to enable this requirement. | |
| Service providers need to implement intrusion-detection and or intrusion-prevention techniques to detect, alert on / prevent, and address covert malware communication channels. | See if your current IDS/IPS can detect covert malware communication channels. Select an IDS/IPS that can do this. | |
| Implement a change-and-tamper detection mechanism on payment pages to monitor and alert for unauthorized modifications. | Mechanisms include but are not limited to: the report-to or report-uri CSP directives can report violations of the Content Security Policy (CSP), Synthetic user monitoring can detect changes to JavaScript in payment pages and alert personnel, Embedded tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected, Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. A tool like SourceDefence can help with this. | |
| Requirement 12 | Perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently the control is performed. | Each of these are documentation/process-related. Simply review the requirements and begin the documentation processes. Contact your Secureframe compliance manager or QSA to help answer questions. |
| Document and review cryptographic cipher suites and protocols in use at least once every 12 months. | ||
| Review hardware and software technologies in use annually. | ||
| Service providers must document and confirm PCI DSS scope at least every 6 months and upon significant change to the in-scope environment. | ||
| Review and update the security awareness program at least once every 12 months. Include threats, vulnerabilities, and acceptable use of end-user technologies in security awareness training. | ||
| Perform periodic incident response training based on risk. Implement an incident response process for detection of stored PAN anywhere it’s not expected. |
Comment Secureframe peut vous aider à respecter la version la plus récente de PCI DSS
PCI DSS peut être un cadre difficile à organiser, gérer et rester conforme année après année. C'est là que Secureframe intervient.
Un gestionnaire de conformité vous sera attribué et vous aidera à définir votre environnement PCI DSS chaque année, en veillant à ce que vous compreniez ce qu’est votre environnement de données de titulaires de cartes, quels sont les systèmes connectés et quels réseaux sont isolés et hors périmètre. Le gestionnaire de conformité ajustera le rapport PCI DSS pour refléter votre périmètre PCI DSS afin que vous ne voyiez que les exigences qui vous sont applicables.
Tout au long de l'année, les gestionnaires de conformité Secureframe seront disponibles pour vous assister dans les travaux de préparation et effectuer une évaluation des écarts avec vous avant votre audit afin que vous puissiez être confiant dans votre conformité PCI DSS avant que votre auditeur ne réalise l'évaluation réelle.
Les propriétaires et responsabilités des contrôles sont un point crucial dans PCI DSS 4.0. Secureframe vous permet d'assigner des propriétaires aux tâches, contrôles et revues directement dans la plateforme afin que vous puissiez répondre à ces exigences.
Secureframe fournit également une formation à la sensibilisation à la sécurité et une formation au code sécurisé, et nous révisons les formations annuellement pour assurer qu'elles sont à jour. Vous pouvez gérer l'achèvement de la formation à la sensibilisation à la sécurité et l'acceptation des politiques, y compris l'utilisation acceptable, directement dans la plateforme Secureframe.
Puisque les itérations des contrôles sont désormais basées sur les risques, Secureframe vous permet de gérer les intervalles des tests en fonction des risques évalués, donc si vous voulez effectuer des analyses de vulnérabilités mensuellement, vous aurez la possibilité de configurer ce test pour se déclencher mensuellement.
Nous avons également des partenaires pré-évalués pour tout service tiers que Secureframe ne peut pas compléter. Nous avons un réseau de testeurs d'intrusion, de partenaires de scan ASV, ainsi que des partenaires d'audit qui seront ravis de vous aider à devenir conforme PCI DSS.
Pour en savoir plus sur la façon dont Secureframe peut vous aider à atteindre et maintenir la conformité PCI, planifiez une démo.
Que signifient ces changements pour votre organisation et comment réagir ?
Que vous soyez déjà certifié PCI ou que vous poursuiviez la certification PCI pour la première fois, vous devez suivre les étapes suivantes pour commencer à passer à PCI DSS v4.0.
1. Comprendre les nouvelles exigences et les changements apportés à celles existantes
Pour commencer votre transition vers PCI DSS v4.0, consultez la documentation PCI DSS 4.0 pour une comparaison approfondie de chaque contrôle qui change et qui est nouveau.
Si vous êtes client de Secureframe, contactez votre responsable de conformité pour discuter en profondeur de votre environnement actuel et de l'étendue afin de déterminer quels contrôles vous sont applicables.
Vous pouvez également tirer parti de l'expertise de votre QSA et de son expérience avec votre environnement. Si vous n'avez pas actuellement de QSA, Secureframe dispose d'un réseau de partenaires d'audit que nous pouvons vous présenter.
2. Réviser le calendrier de mise en œuvre
Puisque toutes les exigences n'auront pas besoin d'être mises en place d'ici 2024, il est important de prioriser les contrôles en fonction des délais de mise en œuvre. Vous devez comprendre quels contrôles sont immédiatement effectifs pour les évaluations PCI DSS 4.0 et les prioriser afin d'être prêt pour 2024. Ensuite, comprendre et prioriser les contrôles pour les exigences datées futures en 2025.
3. Mettre en place un plan.
Pour assurer une transition en douceur vers PCI DSS 4.0, mettez en place un plan solide, incluant un calendrier de mise en œuvre avec des responsables assignés pour toutes les politiques, processus et modifications de configuration nécessaires pour PCI DSS 4.0. Priorisez les exigences les plus impactantes et celles avec la date de mise en œuvre la plus proche.