Are you ready for PCI DSS 4.0?
In just under a year’s time, organizations will have had to comply with several new requirements under version 4.0 of the Payment Card Industry Data Security Standard (PCI DSS).
About PCI DSS
PCI DSS comprises 12 requirements to protect payment card data and has changed very little in the last ten years. But following three years of consultation, it has now undergone a substantial overhaul.
The latest version – 4.0 – was released in March 2022 and currently co-exists with version 3.2.1. It features 63 changes, 13 of which become mandatory in April 2024 when v3.2.1 is retired, with organizations required to fully comply with all the changes by March 2025.
V4.0 places much more emphasis on putting in place processes that are maintained as part of the business-as-usual culture, rather than with the objective of passing an annual assessment, according to the Verizon 2022 Payment Security Report. But what do the new requirements mean in practice and how can businesses begin to make the transition?
Adapting to new technology
PCI DSS 4.0 features four major changes:
The terminology has been updated with respect to network security controls to support a broader range of technologies that can be used to meet the security objectives traditionally met by firewalls
This reflects a move away from traditional server-based and parameterized networks towards distributed architectures, such as cloud and serverless technologies as well as zero trust network architecture (ZTNA) and sees the standard seek to accommodate the control mechanisms specific these new environments, supporting payments via mobile and the IoT, for instance. That said, the standard has always gone to great pains to remain technology neutral, so the aim here is to be all-encompassing while moving with the times.
Requirement 8 has been expanded to include the implementation of multi-factor authentication (MFA) for all access into the cardholder data environment (CDE)
This essentially prevents system components from being accessed without an additional factor of authentication as all accounts must have MFA enabled, not just those use for administration. The same requirement also now aligns with the password guidance outlined in the NIST Digital Identity Guidelines. Passwords must observe a minimum length of 12 characters, observe a minimum level of complexity, and be changed annually or in the event of their suspected compromise. Plus, organizations must document and review cryptographic cipher suites and protocols that they are using within the cardholder data environment.
These authentication and access steps all point towards the standard moving towards the concept of zero trust, whereby networks operate on the principal of “never trust, always verify”. In a ZTNA every access request is regarded as potentially hostile and so needs to be authenticated, authorized, and continually validated which means that protection mechanisms such as MFA will become standard.
There’s increased flexibility for organizations to demonstrate how they are using different methods to achieve the security objectives
Organizations can now use either the “defined” or “customized” approach or a mix of the two to suit their environments. They can even split requirement clauses, so that part of the requirement is met with the defined approach and others with the customized approach, provided the requirement is met.
Although not all the requirements can be met using the customized approach, this does promise to provide organizations with much more flexibility and autonomy. It is likely to prove particularly useful for those that previously had to use compensating controls and to justify them. Customization has effectively replaced these compensating controls which is a positive step as these tended to be regarded as a short-term fix. Those opting for the customized approach will need a qualified security assessor (QSA) to sign-off on the sustainability of their controls.
Organizations have always predominantly used the defined approach and this is likely to continue because few can devote the time and resource to devising bespoke controls. But whereas previously the defined approach focused on the organization proving its control systems were effective and sustainable, irrespective of the control outcome, this has now been reversed.
Before, if they’d taken the necessary steps, the organization would be deemed to have met the requirement even if the outcome was unsatisfactory. That’s all changed under v4.0, as it’s now possible to use security approaches that may differ from those specified in the standard provided the organization can prove the implementation meets the intent and addresses the risk associated with the requirement. In this way, the process becomes much more outcome orientated.
The addition of targeted risk analyses allows entities the flexibility to define how frequently they perform certain activities, as best suited to their business needs and risk exposure
For example, there’s no longer the need to change passwords or phrases every 90 days if the business can dynamically analyze the security posture of accounts and organizations are now able to build their own authentication mechanisms as long as these meet the requirements.
There has also been some cross-over when it comes to the requirements that appertain to service providers versus those that apply to merchants.
Service providers must now also observe controls specific to encryption, password management, external penetration for multi-tenant providers, and are compelled to use intrusion detection/prevention (IDS/IPS) systems. They must re-assess these systems every six months, carry out reviews following significant organizational changes, and fulfil customer requests for information to fulfil the requirement to maintain a program to monitor service provider compliance.
Conversely, a stipulation previously only applicable to service providers has now been extended to include merchants which is the need to promptly respond to failures of any critical security controls. And all organizations must have incident response procedures in place to deal with the detection of PAN leakage.
How to transition
With so many changes to consider, it’s imperative that organizations begin to address compliance now by conducting a gap assessment to determine where they are non-compliant. This can then be used to help decide whether it’s in the interests of the organization to pursue a defined, customized or hybrid approach.
This will of course largely depend on the time and resources the business has, but also its complexity, as there will be more assessments when going down the customized route to show outcomes have been met and controls are sustainable.
The Payment Card Industry Security Standards Council (PCI SSC) has produced updated guidance for the Prioritized Approach which may help here. Originally designed to address the top areas of risk, it effectively identifies which requirements should be addressed first using six milestones.
With respect to the new requirements, organizations should look to priorities the changes based on how long they think it will take to achieve compliance. So, it makes sense to look at encryption (3.3.2 and 3.3.3), protecting personnel against phishing attacks (5.4.1), the management of payment scripts in customer browsers (6.4.3), and password length (8.3.6) and refresh rates of 90 days (8.3.10.1).
Requirement 11 also contains several new elements, such as internal vulnerability scanning with authentication (11.3.1.2), external penetration testing support from multi-tenant service providers (11.4.7), and IDS/IPS techniques (11.5.1.1). Additionally, mechanisms to detect changes to customer-facing HTTP headers and payment pages (11.6.1) have been included and similarly, requirement 12 requires a targeted risk assessment (12.3) and to document and confirm the PCI DSS scope at least annually or upon any significant change (12.5.2).
The Verizon report (cited above) also reveals the top 20 biggest control gaps experienced by organizations in 2020 and this too should help guide effort and resource.
The top four biggest gaps were all in relation to Requirement 11 with respect to examining and implementing changes from penetration testing, running internal and external scans on a quarterly basis, reviewing and addressing internal vulnerability scans, and inspecting firewall and router configurations. Therefore, these areas might also warrant prioritization.
Making PCI DSS BAU
All the changes are likely to prove demanding and require significant project management, so it makes sense to plan these out now month-by-month to meet the deadline. Implementing compliant security controls today will enable the organization to go through one cycle of assessment, effectively practicing compliance for the real thing by submitting control designs to internal security assessors (ISAs) and QSAs with a view to then achieving a report on compliance (ROC) and if passing, an attestation of compliance (AOC).
Importantly, PCI DSS v4.0 emphasizes further that compliance is an ongoing process and one that requires continual monitoring and assessment. It seeks to make these processes become not compliance-driven but business as usual and embedded in the day-to-day processes of the organization.
As the Verizon report shows, businesses still are not doing this day-to-day management so they will need to address v4.0 culturally as well as from a technological point of view. Perhaps this marks the biggest departure from the original standard of all: the need to adopt a new mindset that focuses on data security rather than being simply compliance-driven.