PCI DSS 4.0 is Out!  Here's What You Need to Know About the Updates

A Summary of the Updated Security Standard to Combat and Address the Latest Threats

The PCI Standard Security Council (PCI SSC) recently published an update (31st March 2022) to the well-known PCI Data Security Standard (PCI DSS). The new version 4.0 brings significant changes to the payments ecosystem, which in short, places an increased focus on:

• Targeted risk analysis,
• Organizational security maturity and
• Risk governance.

It also drives PCI DSS compliance as a continuous effort rather than an “annual snapshot exercise” and presents a customized approach to PCI assessments. Rather than a yes or no compliance, version 4.0 enables companies to implement alternative technical and administrative controls that meet the customized approach objective.

What is PCI DSS?

PCI DSS is the gold standard for safeguarding cardholder’s sensitive data for financial and retail businesses and other organizations that rely on credit card payments. Merchants, service providers, issuers, acquirers, and other companies that store, process, or transmit payment cardholder data should comply with PCI DSS.

The digital world is changing much faster than the cardholder gold standard, looking back to version 3.2.1 of PCI DSS, published in 2018 — the pre-COVID era of cybersecurity. Ever since COVID, online transactions, QRcode payment, and the application of PoS systems have evolved.

What’s more? We now have much more stored cardholder data in cloud platforms. Regarding the attackers’ side, they also have more advanced tactics and attack angles that they can use against the card payment industry. In short, the payment industry now has a broader battlefield and more enemies in the wild before 2020.

Brief History of PCI DSS 1.0

In the early 2000s, with e-commerce evolving into a more significant part of the global economy, credit card businesses started to think about improving their approach to securing the cardholder environment. There were new cyber-threats related to the maturing of web-based transactions, but there is no unified group of security standards to secure credit card data.

As a result, in 2004, a group of credit card companies — American Express, Discover, JCB International, MasterCard, and Visa — came together to release the first version of PCI-DSS. It is also the first standard developed from the “bottom-up” — not from the government or public institutions.

Since version 1.0 was released, in these 15+ years, the founding companies have standardized their role in overseeing credit card transactions by establishing the PCI Security Standards Council (PCI-SSC). Since then, there have been multiple updates to version 1.0 for technological advancements and more sophisticated cyber threats. The PCI-DSS 4.0 will be the 10th released version of the standard.

A Little While Back — Version 3.2.1

The PCI-DSS 3.2.1 (and earlier versions of the standard) is exceptionally prescriptive. It contains not only a series of objectives (i.e., protect cardholder data) but specific and rigid requirements that dictate how companies must achieve those goals.

Businesses that cannot follow these prescriptive steps to compliance must implement a compensating control. This demanding and time-consuming procedure requires an organization to go all the way more than the intent of the primary control itself.

What’s New in PCI DSS 4.0?

The 12 core requirements, which were already there previously, did not change much with PCI DSS 4.0. Therefore, they will still be the most fundamental for protecting payment card data.

By changing the focus to outcome-based, the requirements have been redesigned to focus on specific security objectives. The aims are to guide the security controls on how they should be implemented. Below is the summary of the new changes abstract from the official document.

Increase Flexibility - The New Customized Implementation Approach

PCI-DSS 4.0 does retain the existing prescriptive standard but replaces compensating controls with an alternate option — Customized implementation. When retailers and service providers could not fulfill the prescriptive controls of PCI DSS 3.2.1, they need to propose a compensating control and justify it with:

• A compensating control worksheet (CCW), and

• A risk assessment.

In PCI DSS 4.0, this choice is still valid, while there is also a new option for a customized control approach. Customized implementation regards the intent of the objective and allows organizations to design their security controls.

Once an organization specifies the security control for a given objective, it must provide complete documentation to help its Qualified Security Auditor (QSA) draw a final decision on the effectiveness of that customized control. This customized approach still retains the requirement to evaluate risk, allowing for a more strategic pathway to meet a control.

Instead of compensating for the lack of control, the customized implementation approach fosters the merchant or service provider to document a different and customized control based on the objective. This customized control will then be assessed by the assessor (QSA) of the control that is being substituted. As a result, this approach allows for long-term customization rather than a shorter-term “compensating” control.

Fighting Against Identity Theft

The PCI DSS 4,0 contains modifications to the authentication requirements to reflect the latest industry best practices for password and multifactor authentication. When taking a closer look, the new standard aligns with the NIST guidance on digital identities, which focuses on security control around authentication and identity lifecycle management. The authentication requirements may include the following:

• Multifactor authentication (MFA) use for all accounts that have access to the cardholder data, not just administrators accessing the cardholder data environment.
• A minimum of at least 15 characters containing numeric and alphabetic characters and prospective passwords or passphrases are compared against the list of known bad passwords.
• Passwords or passphrases for accounts used by applications and systems are changed at least every 12 months upon suspicion of compromise.
• Access privileges have to be reviewed at least once every six months.
• Vendor or third-party accounts may be enabled as needed and monitored.

Other Changes

PCI DSS is an extensive change to the previous version. Apart from the two above, some other changes are worth mentioning, including:

• An additional annual PCI DSS scope confirmation,
• More human intervention in risk assessments to avoid the output strictly from tools,
• An expanded scoping of “segmentation” (not only network segmentation), and
• The expanded applicability of data encryption.

Final Words: Migrating from 3.2.1 to 4.0

According to a recent post on Darkreading:

Introducing the customized implementation approach to PCI DSS 4.0 gives businesses more flexibility. Organizations are no longer forced to follow the methods prescribed by the standard or implement a burdensome compensating control.

Instead, they can focus on choosing and implementing solutions that achieve the intended outcome of a specific PCI DSS objective. For example, combining new IAM and multifactor authentication (MFA) solutions with data-at-rest encryption could foster the adoption of Zero Trust Architecture which organizations can overachieve the requirements.

Regarding the timeline, there would be two years to transition from version 3.2.1 to the new 4.0. After that, organizations have until 31st March 2025 to phase in new requirements. In the meantime, both versions of the PCI DSS would be active.

According to the official blog post:

PCI DSS v3.2.1 will remain active for two years after v4.0 is published. This transition period, from March 2022 until 31 March 2024, provides organizations with time to become familiar with the changes in v4.0, update their reporting templates and forms, and plan for and implement changes to meet updated requirements. As of 31 March 2024, PCI DSS v3.2.1 will be retired and v4.0 will become the only active version of the standard.

This transition period, ending 31st March 2024, offers organizations time to familiarize themselves with the transformations, update their reporting templates and forms, and plan for and implement changes to meet updated requirements.

Thank you for reading. May InfoSec be with you🖖.