Are you primed and prepared for PCI DSS 4.0? asks Phil Robinson, Principal Consultant and Founder of Prism Infosec.
The Payment Card Industry Data Security Standard (PCI DSS) will be 20 years old next year but it’s remained largely unchanged over the past decade. The latest version 4.0, however, sees a number of significant changes which aim to bring the standard up to date and merchants and providers must comply with the revised version from April 2024 (although some requirements become mandatory from April 2025). So how does PCI DSS 4.0 differ from its predecessor and what do organisations do to comply?
In total there are 63 changes in version 4.0 released in March 2022 but these don’t just reflect the way technology has moved on. The new standard marks a significant departure from version 3.2.1 because it places much more emphasis on instigating processes that are maintained as part of a business-as-usual culture, rather than a compliance oriented approach where the chief goal is to pass an annual assessment. There are four main areas where PCI DSS v4.0 breaks new ground.
Four changes
To start with it’s now geared to reflect modern processing environments with changes to the terminology. So, instead of being geared towards perimeterised networks (which are typically protected by a firewall), other distributed network architectures and control mechanisms are recognised such as cloud environments and Zero Trust Network Architecture (ZTNA). This then allows the standard to accommodate other transaction handling mechanisms, for instance over mobile or Internet of Things (IoT) devices.
Secondly, Requirement 8 pertaining to access to the Cardholder Data Environment (CDE) has been expanded. It states that multi-factor authentication (MFA) should be enabled across all accounts (rather than just administrative accounts)and it also sets out conditions for password strength. In line with the NIST Digital Identity Guidelines, passwords must have a minimum of 12 characters and complexity and should be changed annually or in the event of their compromise. Requirement 8 also compels organisations to document and review their cryptographic cipher suites and protocols within the CDE.
The third big change is that there’s now much more flexibility over how the organisation chooses to demonstrate their compliance. They have the option to use the “defined” or “customised” approach or a mix of the two across the requirements. This will come as good news to those who previously used the compensating controls, which customisation effectively replaces, which were always somewhat problematic. Compensating controls were used when the organisation could not meet a requirement due to legitimate technical or business issues and saw an alternative control used so they were always viewed as something of a stop-gap solution.
In most cases it’s expected that those who used the “defined” controls will continue to do so due to the complexity of ‘sourcing your own’. Regardless of the path taken, however, there is a fundamental change in approach. Before, the emphasis was very much on proving controls were effective and sustainable but under version 4.0 the organisation needs to meet the intents and address the risks associated with the requirement, making it much more outcome rather than process orientated.
The fourth change sees the introduction of risk-based decision making with regards to the frequency under which controls are reviewed. Essentially, organisations are given much more flexibility over how often they adjust controls. If, for example, the risk is deemed low, a business may choose not to update passwords or phrases at the specified frequency provided it can prove it has assessed the security posture of those accounts. Organisations are also able to build their own authentication mechanisms to meet the requirements.
As an aside, it’s also worth noting that there has been some cross pollination of controls with respect to service providers and merchants. Service providers must meet several new demands, including implementing controls with respect to encryption and password management and using intrusion detection/prevention systems (IDS/IPS). Merchants now need to respond to failures of critical security controls, in common with service providers, and all must have incident response in place to deal with PAN leakage.
Meeting the requirements
But while the standard is certainly now more aligned to modern security practices, meeting it is going to require some substantial groundwork as organisations decide where they need to make changes, which elements they will choose to customise, if any, and how they will prove they have met the intents of the requirements rather than just going through the motions.
The Verizon 2022 Payment Security Report makes for interesting reading as it reveals many of the issues organisations have had with achieving compliance under v3.2.1. It features a ‘Bottom 20’ with respect to those they found most challenging and top of the chart is Requirement 11 for testing the security of systems and networks on a regular basis. It’s this requirement that is also likely to pose a challenge going forward because it includes a number of revisions 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), as well as mechanisms to detect changes to customer-facing HTTP headers and payment pages (11.6.1).
Ideally, organisations should be doing the groundwork to meet the compliance this year to enable them to put in place the necessary processes and systems to comply. This will require significant planning and prioritisation, which is why the PCI Security Standards Council (PCI SSC) has produced the Prioritised Approach. This effectively maps six milestones to PCI DSS 4.0 requirements and sub requirements and provides a useful basis for the project management that will be required. Some of the requirements will inevitably take longer than others to achieve depending on the business, so there will inevitably need to be some level of customisation required when prioritising compliance.
When it comes to compliance, for those larger merchants, as well as service providers, an Internal Security Assessor (ISA) or a Qualified Security Assessor (QSA) will need to sign-off the control designs. However, there’s no reason why an organisation can’t approach them before its compliance date to test the ground of how adequately they meet the new requirements. It makes much more sense to do this and iron out any issues now rather than to wait until closer to the compliance deadline.
The changes may seem onerous at first, but they are undoubtedly a real step in the right direction. By accommodating new technologies, new service architectures and making security controls risk and outcome-based, the PCI SSC has ensured the standard remains relevant and pragmatic. It’s now a much more pertinent standard that contributes to the security posture rather than acting as an obstacle to progress, and so those organisations that embrace the changes and take the time to determine how they can fit it to their business processes will certainly reap the benefits.
For a guide to PCI DSS version 4, visit the PCI SSC website.
