Exploring the Key Changes in PCI DSS 4.0: What You Need to Know to Stay Compliant
Understanding the Impact on Cloud Environments and How to Adapt to the New Standards
The Payments Card Industry Data Security Standard (PCI DSS) defines the golden standard to protect sensitive cardholder information for retailers, financial institutions and vendors handling credit card data. Starting with version 1.0 on December 15th, 2004, it is now on its 10th iteration with version 4.0 published on March 31st, 2022.
Version 4.0 comes with a slew of changes to address the reality of modern business. A few can be seen right away:
Greater flexibility on how to remediate risks,
Reorganizing control numbers,
Moving away from naming specific technologies (firewalls, antivirus) to broader categories (network controls, protection from malicious software)
These and other control updates are impactful on their own right. However more significant to understanding the new requirements is an underlying change towards maintaining a state of continuous compliance - where instead of companies scrambling to be compliant on a certain date for a point-in-time audit, there is now an emphasis to embedding security controls, understanding risks, and fostering employee security education, aiming towards a holistic approach to enterprise security. The official term for this state is “Business-as-usual processes”.
In this blog post we will cover these changes and their impact in modern enterprise workloads.
Before diving into version 4.0’s changes, though, let’s do a quick recap of PCI DSS and see how we got here.
PCI DSS Overview
In a nutshell, PCI DSS was created as an effort to harmonize the security standards of the major credit card brands. From Wikipedia:
“Originally, the major card brands started five different security programs (…) The intentions of each were roughly similar: to create an additional level of protection for card issuers by ensuring that merchants meet minimum levels of security when they store, process, and transmit cardholder data. To address interoperability problems among the existing standards, the combined effort made by the principal credit card organizations resulted in the release of version 1.0 of PCI DSS in December 2004.(…) PCI DSS has been implemented and followed across the globe.”
The Payment Card Industry Security Standards Council (PCI SSC) is the entity that governs the PCI DSS standard. It is composed of representatives from MasterCard, American Express, Visa, JCP International and Discover Financial Services, besides accepting participation of independent/private organizations after registration.
More information on how to join as an individual participant, organization, or to view the full list of participating organizations, can be found here.
A Few PCI DSS Keywords
CHD: Card Holder Data
SAD: Sensitive Authentication Data
PAN: Primary Account Number
CDE: Cardholder Data Environment (commonly referred as “in-scope”)
TPSP: Third Party Service Providers
QSA/ ISA: Qualified Security Assessor / Internal Security Assessor
SAQ: Self-Assessment Questionnaire
ROC: Report On Compliance
AOC: Attestation Of Compliance
SSL/ TLS: Encryption protocols for data in transit
OWASP: Non-profit foundation that publishes a top 10 list of web app security risks
NIST: US government group that sets standards for technology security. Publishes a cybersecurity framework.
CIS: Industry-led non-profit group that publishes security benchmarks for different cloud platforms and vendors.
Lifecycle Calendar
Before diving into the changes, it is important to understand the time available to help prioritize efforts. The following image shows the traditional PCI DSS version lifecycle, detailing for how many months one version is valid until it is replaced by subsequent version.
Source: PCI DSS Lifecycle
Following the above, PCI DSS version 4.0 should have been released in 2020. However due to the pandemic it was postponed, and then postponed again in 2021, being released in March 2022. The new version will have the following implementation timeline:
Source: Countdown to PCI DSS 4
It is also important to understand that once a new PCI DSS version is published, it still takes some time for it to get settled as auditors work with the different organizations and identify edge cases and accepted implementations. An example is discussed on a later section of this post - “A Note on Strong Cryptography”, covering implementation guidance that goes from “best practices” to “requirements” after March 2025. Because of this it is very important to prepare in advance and start working with your QSA/ ISA team sooner rather than later for a successful experience.
Armed with this very brief overview of PCI DSS and the timelines, let’s go into the changes with version 4.0 in the next section.
PCI DSS 4.0
Types of Changes
There are 3 types of changes from v 3.2.1 to v 4.0:
Structure or format (101 changes): consolidating or splitting existing requirements, overall reorganization and renumbering of requirements.
Clarification or guidance (78 changes): updates in wording or providing further instructions to existing requirements
Evolving requirement (52 changes): changes to reflect updates in technologies and new threats, and changes in the payments industry
A complete description of every change can be found in the Summary of Changes document.
A high level picture can be seen when comparing the 12 Principal PCI DSS requirements for each version:
Source: PCI DSS v3.2.1 and PCI DSS v4.0
At first glance we notice the impact of “clarification” changes - such as “cardholder data” to “account data”, and “applications” to “software”. But we also see the underlying theme of continuous compliance in the change from “maintain a policy that addresses security” to “organization policies and programs”.
After going through each control in the new version, we would be able to see a few key themes surface. The next section goes over these themes.
Key Themes
Security as “Business-as-usual”: One of the most important aspects of PCI DSS 4.0 is that it emphasizes the need for ongoing security. Businesses must not only comply with the standard at the time of a security assessment, but they must also implement ongoing monitoring and reporting to ensure that they remain compliant. This includes regular vulnerability scans, penetration testing, and monitoring for security incidents.
Focus on risk management: The new standard emphasizes the need for businesses to identify and assess their specific risks, and to implement appropriate controls to mitigate those risks. To facilitate adoption, it provides a “Sample Targeted Risk Analysis Template” in appendix E2. It also includes new requirements for incident response and management, where businesses must be able to quickly detect and respond to security incidents.
Secure by default: Another key change in PCI DSS 4.0 is the emphasis on security controls that are built into the design of payment systems. This means that businesses must ensure that their systems are designed with security in mind, rather than trying to add security controls after the fact. This includes using secure coding practices, testing systems for vulnerabilities, and implementing security controls such as secret management and tokenization.
Flexibility: Finally, PCI DSS 4.0 offers an alternative to the opinionated technology requirements and specific mitigation strategies, by providing a flexible approach. This change reflects the reality of a more complex world and security environment, allowing companies to work with their auditors on a satisfactory mitigation strategy of the controls. This format is dubbed “Customized Approach” (as opposed to the “Defined Approach”) and is described in the new Appendices D and E. Note that the Customized Approach does not need to be used for all controls, highlighting its flexibility.
A Note on “Strong Cryptography”
PCI DSS 4.0 Does not specify which encryption algorithms are considered “strong”, other than a generic mention of “AES” in Appendix G - Glossary, and an entry on “Strong Cryptography” mentioning “at least 112 bits, recommended 128 bits for new deployment”. On some controls, it also makes references to external sources, such as NIST SP 800-52 for TLS, and SP 800-57 for key management and FIPS-approved/ NIST-recommended algorithms (hash functions, symmetric and asymmetric algorithms).
This version also shows its flexibility by allowing a generous timeframe for companies to adopt the more stringent controls - for example requirements 3.3.3 and 3.5.1 mention that the use of “strong encryption” is considered best practice until March 2025, after which it will be fully considered during an audit.
Having said that, one should keep in mind that the full PCI DSS recommendations are the minimum requirements for security. From my point of view, I appreciate that the standard does not specify which encryption algorithms must be used, since these can become obsolete (like DES/3DES still being required in credit card machines in certain countries). However the recommendation of at least 112 bits, preferably 128 bits might be a bit too low - in my opinion I do not see why companies looking for securing data wouldn’t use at least AES 256 bits, which is the default for modern security tools, or other appropriate modern encryption algorithm depending on the use case.
Impact on Modern Workloads
Companies with workloads on the cloud and using modern technologies and architectures should be well positioned to achieve PCI DSS v 4.0 compliance, since the updates reflect the latest advances in cybersecurity. In the next sections we will cover a few specific areas.
Cloud Environments
One of the advantages of hosting PCI compliant workloads in the cloud is the ability to delegate many of the security responsibilities to the cloud platform, through the “shared fate” model. All major cloud providers offer this level of security as the baseline, being responsible for the security of everything related to infrastructure and maintenance personnel. It then becomes the company’s responsibility to ensure compliance with the workloads running on the cloud.
Additionally, all cloud providers have some type of identity and management access control through IAM profiles and service accounts, which can be used to meet authorization and authentication requirements and to support the “zero trust” paradigm, as well as network controls and key encryption services.
Kubernetes
Either self hosted or managed Kubernetes solutions (EKS, GKE, AKS) have all the features required to meet the PCI standards. However care must be taken to ensure that the clusters are hardened and follow a robust networking architecture to reduce risks. For reference, the NSA published a cybersecurity report in March 2022 with recommendations on Kubernetes cluster hardening.
In addition to that, care must be taken that the software development and deployment leverages a secure pipeline. This traditionally means a combination of image signing, private repositories, image scanning for known threats and a CICD automation pipeline. A good reference for this concept is the SLSA framework.
SaaS
PCI DSS v 4.0 has a section about Third-Party Service Providers (TPSP), specifying:
If the TPSP receives encrypted data, but does not have access to the key that can decrypt the data, they may be able to consider the encrypted data as out-of-scope if certain conditions are met
The use of a PCI DSS compliant TPSP does not remove the customer’s responsibility for its own PCI DSS compliance
Both are to be expected, but one very important point to keep in mind is that depending on a customer’s business model, they might be the TPSP of another customer that also needs to meet PCI DSS compliance. One example is a company using a cloud platform to host their SaaS application that hosts their customers applications.
This company needs to decide which aspects of the platform will be surfaced to their customers, in order to delegate responsibility, and which aspects they will take ownership as their in-scope requirements.
Next Steps
As seen above, the impact for modern workload shouldn’t be that significant if security best practices are already being followed. Most of the changes reflect updates to the controls to match the modern realities, and the theme of automation and a state of “continuous compliance” reflect the modernization of the controls to the current security landscape.
Three ideas to help organizations reduce the compliance toil are:
Implement a Cloud Governance Model as described here,
Migrate workloads to the cloud in order to delegate platform compliance requirements to cloud providers
Invest in internal education, training and communications to ensure PCI DSS compliance evolves from a “check-the-box” exercise, to one that actually serves as inspiration for a holistic approach to security and focus on identifying and mitigating their specific risks
What about you, do you have an interesting PCI DSS audit story to share? Have you worked on an architecture for a company that was both a consumer of TPSP and also provided services as TPSP to others?
Feel free to add your thoughts, questions and suggestions in the comment section below!