PCI DSS v4.0: What’s Next?

The first version of the Payment Card Industry Data Security Standard (PCI DSS) was introduced by Visa, Mastercard, American Express, Discover, and JCB International in December 2004. The standard was developed to reduce the rising cost associated with security breaches and fraud attributable to exposure and misuse of payment card data, also referred to as cardholder data (CHD).

In 2006, the PCI Security Standards Council, or PCI SSC, was formed to assume responsibility for developing, maintaining and providing support and education for a strategic framework that included security standards, of which the PCI DSS was just one component, focused on protecting CHD.

To meet the challenges posed by an ever-evolving threat landscape and increasingly sophisticated attacks targeting payment card data, the PCI SSC continuously evaluates, updates and improves the PCI DSS. These efforts result in periodic updates, both minor and major, to the PCI DSS, the latest of which being the release of PCI DSS version 4.0 (v4.0) on March 31, 2022. When you review the new and updated requirements in this latest version of the PCI DSS, it is easy to correlate new and enhanced requirements to the common and prevalent attacks and attack vectors the PCI DSS aims to help prevent or mitigate. Ransomware, phishing, stolen credentials, and web application attacks continue to be of utmost concern, regardless of the industry or size of an entity.

Timelines for PCI DSS v3.2.1 to v4.0 Transition

According to current timelines set forth by the PCI SSC, PCI DSS v3.2.1 will be officially retired as of March 31, 2024, after which all entities required to comply with PCI DSS will need to be compliant with and assessed under PCI DSS v4.0.

In recognition of the potential complexity and cost associated with implementing some of the new requirements, a subset of requirements in the v4.0 standard is future-dated. The future-dated requirements are identified within the standard as security best practices until they need to be in place by March 31, 2025.

PCI DSS v4.0 Insights

The focus of this article is not to enumerate the changes between versions 3.2.1 and 4.0; instead, this article intends to share our insights into the nature of the changes and our perception of the purpose of the collective changes.

When we looked at the new and updated requirements in PCI DSS v4.0, we summarized the changes into high-level categories to better understand the intent behind the collective set of new and updated controls rather than focusing on each individual change. It is important to note that, while we categorize the various changes broadly into these categories, in many cases, new and updated controls fall into more than one category. We talk about specific controls within the category we believe is the “primary” category into which it falls.

Changes can be summarized into four high-level categories:

• New or updated technical controls in recognition of technological advancements
• Controls about the direct protection of cardholder data (CHD)
• Process maturity
• Continuous PCI DSS compliance and program management

New or Updated Technical Controls in Recognition of Technological Advancements

The first category consists of new or updated technical controls that demonstrate understanding and recognition of the technological advancements that have changed how entities architect and manage networks, systems and applications. This is evident in the controls themselves and the updated terminology throughout the standard.

For example, in PCI DSS v3.2.1, Requirement 1 specifically focused on firewalls and routers. There are many technologies designed to protect network resources traditionally served by physical firewalls and routers, such as virtual firewalls and routers, cloud-based network controls, platforms providing micro-segmentation, and load balancers. PCI DSS v4.0 has replaced the “firewall and router” terms in favor of ”network security controls (NSCs)” to encompass the collective devices and solutions that provide protections for network resources.

Another example is replacing the term “anti-virus” for the controls in PCI DSS v3.2.1 Requirement 5 with “anti-malware,” which encompasses all types of malicious software, not just traditional viruses.

As it relates to accommodating technological advances since the writing of PCI DSS v3.2.1, we see controls that recognize the effectiveness of current technologies, such as using security levels to allow a system component to serve more than one primary function, real-time scanning and continuous behavioral-based analysis afforded by anti-malware solutions. There are also advanced access control solutions that provide real-time and behavioral analysis to detect abuse of privileges, account bypass and other anomalous events indicative of malicious or high-risk activities. Logging and monitoring solutions have become more powerful, with advanced log analytics tools offering built-in rules, custom rules, advanced dashboards and powerful search capabilities. PCI DSS v4.0 also recognizes that advanced technologies make it possible for organizations to meet the intent of various PCI DSS controls in ways other than those prescribed by the original control. The introduction of the customized approach allows for better accounting in instances where there is no technical or business constraint, as is the case with compensating controls, instead an alternative method of meeting (or exceeding) the intent of the original control. Not all controls are eligible for a customized approach, and PCI DSS v4.0 clearly identifies those controls that are not eligible for a customized approach.

Controls About the Direct Protection of Cardholder Data (CHD)

The second category includes controls explicitly focused on, and solely for, the direct protection of CHD. These include controls such as the specific requirement to change encryption keys suspected or known to have been compromised for wireless networks that connect to the cardholder data environment (CDE) or that are used to transmit CHD, as well as tighter controls for the handling, disposal and encryption of sensitive authentication data (SAD) that is stored prior to completion of authorization. PCI DSS v4.0 also introduces more granular controls around rendering primary account number (PAN) data unreadable at rest, managing encryption keys and related requirements, validating certificates used to protect transmitted PAN data, and managing payment page scripts that are loaded and executed in the consumer’s browser such that the scripts are verified to be authorized, with the integrity of the scripts maintained.

Process Maturity

The third category falls into the area of process maturity. People and the processes they follow are as critical to a strong cybersecurity posture as protecting and securing the technologies themselves. The PCI DSS puts great focus on formalizing and maturing processes around role-based access and account reviews, change control, configuration management, and risk assessment and management.

Implementing role-based access is a great start, but it is equally important to review assigned access regularly to confirm such access is still appropriate and necessary, especially privileged access for both user and service accounts. It would be a terrible waste of time and resources if an entity initially implements strong and secure configurations but fails to tightly maintain those configurations through rigorous change control and configuration management processes. The availability, reasonable cost, improvements in ease of implementation, and advanced features afforded by today’s configuration and change management tools and solutions leave few excuses for not addressing those processes.

Lastly, a solid, ongoing risk assessment and management program helps organizations prioritize budgets and resources where the most benefit can be gained, and thoughtfully assign frequencies to activities not prescribed by the PCI DSS but left to the organization to determine.

Continuous PCI DSS Compliance and Program Management

Closely related to process maturity, we have our fourth category, continuous PCI DSS compliance and program management. PCI DSS v4.0 makes it clear that, while annual PCI DSS compliance validation is a point-in-time activity, maintaining PCI DSS compliance is definitely NOT. There is a very clear logic to the controls we have included in this category, starting with the understanding that one cannot apply PCI-DSS-required controls to all of the people, processes, technologies and data that are in scope if one does not know who, what or where these things are.

A formal, documented verification of scope must be performed, and complete and accurate inventories must be maintained that include system components (physical, virtual, and cloud-based), software, payment page scripts, and dependencies, such as programming languages, libraries, and execution platforms.

Inventories must also include encryption mechanisms and components used to protect PAN data, credentials and other sensitive data, media containing CHD (whether stored off site or not), and both authorized and unauthorized wireless access points. Having an accurate scoping of an entity’s environment and complete inventories are paramount to making sure that PCI DSS controls are applied where they must be used. PCI DSS v4.0 also provides additional guidance for timelines and frequencies prescribed by the standard.

What PCI DSS v4.0 Means for Payments Orchestration

All online merchants that accept credit card payments must be PCI compliant. By leveraging a secure PCI Level 1 card vault, merchants can significantly reduce their PCI scope and help avoid costly and time-intensive, on-site data security assessments.

Staying on top of constantly changing payments regulations like PCI DSS v4.0 is difficult. Payment orchestration solutions like those that Sikich and Spreedly offer, helps merchants to minimize the effort and risk that comes with regulatory burdens. We stay on top of the latest requirements, building support into our platform. That lets our customers focus on delivering a great customer experience and meeting their revenue goals.

With the adoption of PCI DSS v4.0, Sikich will continue to review and enhance our PCI program to ensure we grow and adapt to meet the new requirements. Many of the new requirements already represent how Sikich operates, but this change affords Sikich the opportunity to review key areas and make improvements.

Conclusion

While some new or updated requirements may require significant efforts in terms of cost, implementation complexity or resources, there is some low-hanging fruit. We suggest starting by performing and documenting a formal scope validation exercise, building out roles and responsibilities matrices and updating inventories to address those new requirements. PCI DSS v4.0 also provides useful templates for performing risk assessment activities that can be reviewed for incorporation into your documentation for risk assessment activities and the results and findings from those activities.

It is important to note that each merchant has its own unique needs. This means that there may be additional steps to be compliant with the new PCI DSS v4.0 requirements you must take based on your specific situation.

We’re here to help. Interested to learn more about how Payments Orchestration can help ensure your organization is compliant? Reach out to our Sikich team here. 

To learn more about Spreedly, please visit www.spreedly.com.