PCI DSS 4.0.1 may have been with us for six months now but the reality is that most entities still won’t have made the transition to the new standard in full. This is because the majority of the requirements (51 out of the 64) are regarded as complex to implement and so are classed as best practice and not mandatory until 1 April 2025. Implementing these requirements will take time, hence the leeway, but the danger is that some entities will embark upon a steep compliance curve that sees a flurry of activity in Q1 prior to the QSA assessment, making the process far more disruptive than it needs to be.
If we look at the requirement to replace disk-level or partition-level encryption with another protection mechanism (3.5.1.2), for example, this will require a substantial overhaul of how Primary Account Number (PAN) data is protected. Unlike file-, column-, or field-level database encryption, these methods of encryption are only an effective way to encrypt PAN when systems are powered down, otherwise anyone with system level access can access the data on the disk, which goes against the ‘need to know’ or ‘deny all’ principles inherent in the standard.
PCI DSS 4.0.1 also compels the application of multi-factor authentication (MFA) more widely (8.5.1). As well as being required for remote network access or non-console admin access in the cardholder environment (CDE), it now needs to be used to secure ALL access to the CDE and so across multiple additional systems and may need to be performed more times as a result. In effect this means MFA will need to be implemented across the infrastructure i.e. in the cloud, on premise and on devices and endpoints as well as on those systems that have a direct connection to the CDE. Again, achieving this will be a major undertaking for some entities.
More automation
The automated audit of log reviews (10.4.1.1) to alert on events that could be suspicious or malicious is liable to trigger an increase in log volumes, for instance, which entities may find their existing SIEM struggles to deal with requiring them to invest in more sophisticated and expensive log management solutions, and experts to write and fine tune the detection and alerting rules. It’s a similar story when it comes to the requirement for authenticated scanning (11.3.1.2) which is able to log on to systems and perform far deeper scanning than the unauthenticated scans used before but in the process is likely to surface far more vulnerabilities, putting new demands on network bandwidth and performance requiring the entity to upgrade to a more resilient and better performing network infrastructure.
Automated detection and response mechanisms will also need to be put in place to meet the requirement to detect, alert and promptly respond to failures in critical security control systems (10.7.2). While this was applicable to service providers in the previous version of the standard it will also now apply to merchants for the first time from 2025 so they’ll have to meet the requirement from scratch.
Deploying change-and-tamper-detection mechanisms for payment pages (11.6.1) is a further change which is expected to dramatically reduce ecommerce fraud. Java scripts on websites can be used to harvest Cardholder Data (CHD), or this function can be performed by the payment page of a Payment Service Provider (PSP) which the merchant redirects to or which uses a PSP generated iframe in a practice known as eskimming. The new requirement prevents this by using mechanisms to detect issues such as iframe overlay and iframe hijacking by assessing the HTTP header/s and payment page scripts on a regular basis (at least every seven days). While it’s a welcome move, it’s going to see the entity need to implement and monitor these mechanisms which will again see them need to select, test, acquire, deploy and monitor new and unfamiliar technology.
Making other changes
Such are the changes advocated by PCI DSS 4.0.1 that it will require entities to perform far more than a rudimentary gap analysis. But moving to the standard also provides a real opportunity to evaluate, to optimise and cut out the chaff. This might be by looking at how the entity is storing its data, if there’s the potential to redesign the CDE to make it less dependent on using CHD, or an opportunity to leverage technologies such as tokenisation and point-to-point encryption. For these reasons, a scope analysis and review should be the first priority.
There may also be some common ground with other standards such as ISO 27001, DORA, and GDPR which will allow the entity to kill two birds with one stone. This will allow the entity to coordinate audits but also deduplicate work with regards to overlapping controls such as access control, encryption, logging, and monitoring etc. and requirements.
Looking to focus effort in this way can also reveal which elements of the new and highly technical PCI controls and requirements might be more better outsourced. Using a third party to fulfil some or all of the requirements can provide advantages, not only by driving down costs and taking away the complexity but also by providing access to cutting-edge technologies and specialist skills, allowing the entity to focus on its core business. Such a decision should take into consideration internal skills, budget, and the overall risk management strategy.
Finally, it’s worth noting that a principle aim of PCI DSS 4.0.1 is to see entities put in place systems and processes that they continually monitor, manage and improve upon. Its outcome driven and so entities need to approach compliance as an ongoing process. So, entities would be well advised to adopt this mindset now and use the remaining six months to appraise and comply efficiently, avoiding the need to climb a compliance hill.
