In June I talked about PCI DSS version 4 at RSA Conference 2022 in San Francisco. The title of my presentation was PCI DSS 4: Evolution, Revolution or an Omen of Extinction? The recording of the presentation is here:
My conclusion is that as a standard it is all three things: evolution, revolution and yes, in some ways an omen of extinction.
But what I think is more interesting is what the card brands (Mastercard, Visa, etc.) will do with PCI DSS given the changing nature of the payment landscape. And that is where I think the real extinction and evolution will occur.
1. Why PCI DSS exists
It is useful to remember why PCI DSS exists. When criminals started to use stolen cardholder data to make fraudulent purchases, the card brands had two choices:
To redesign the payment system so that stolen cardholder data could not be used to make fraudulent payments.
To require every organisation that stores, processes or transmits cardholder data to secure it, and therefore reduce the risk of the data being stolen.
You know which one of the two options the card brands took — it is why we have PCI DSS — and that’s certainly due to the fact that it would have taken many years to redesign the entire payment system, whereas imposing PCI DSS on the industry was quicker.
Given this was the brands’ choice, the three reasons why PCI DSS came into existence were:
To prevent US general or state laws being created to fix the problem of stolen cardholder data being used fraudulently.
To redress the asymmetry of risk in the payment ecosystem. What I mean by this is that the direct impact to a merchant of losing payment card data is small when compared to the impact on the entire payment ecosystem (primarily the card holder and the card issuer) - and so brand rules combined with PCI DSS were able to rectify this, providing a real financial impact (i.e. a risk) to a merchant that failed to secure the cardholder data it processed.
To explain to people (remember this was back in 2006) what needed to be done to secure data.
As such PCI DSS was, in its time, revolutionary — and you can criticise it from many aspects, but in the early years it largely did its job. And I bet it was much better than any federal or state security standard that would have been developed if the card brands had not self-regulated.
2. PCI DSS 4: The standard
2.1 Evolution: the new requirements
There are 64 new requirements in DSS v4, and they are mostly evolutionary, either in response to the way that criminals have been stealing cardholder data, or because of general changes in how we ‘do’ information security.
Some of the key evolutionary changes in the standard that I’d highlight are:
The deprecation of plain hashes to protect PANs (keyed hashes are needed).
A focus on managing system and application accounts.
Requiring multi-factor authentication for all access into the cardholder data environment (not just administrators).
Authenticated internal vulnerability scans.
Protection against phishing.
In addition to these, the two evolutionary requirements I’m most proud of in the standard are:
Minimise and manage JavaScript on the payment page.
Monitor the ongoing integrity of JavaScript on the payment page.
These new requirements aim to prevent and detect e-commerce skimming attacks because this the main way that criminals are now targeting cardholder data. The skimming of cardholder data from within the consumer browser is a new class of attack, and so it was especially interesting to develop these new requirements in a way that (it is hoped) allows for technical innovation from the market.
2.2 Revolution: The Customized Approach
PCI DSS has often been criticised because of its prescriptive nature — the requirements are both detailed and prescriptive, as are the testing procedures. And that’s one reason it is a more rigorous standard than something less prescriptive such as ISO27001.
The danger with being prescriptive in a standard is that it can force certain technical decisions: and as technology changes more quickly than a standard is able to, the standard can persist legacy security thinking and solutions in environments where they are not appropriate.
The Customized Approach is a revolutionary idea that allows an organisation to meet the objective of a PCI DSS requirement by selecting and implementing its own controls. For example, instead of requiring anti-malware software to be installed, the Customized Approach objective is “Malware cannot execute or infect other system components”. An organisation could choose to meet this objective by using strict application allow-listing rather than the anti-malware software that defined approach of requirement 5 asks for.
This in itself is not revolutionary, other standards have been written in terms of security outcomes or objectives. What is revolutionary is the process an entity has to follow to prove that their controls meet the objective, and then how those controls are assessed by a PCI SSC approved assessor (QSA or ISA). This means that the same rigour that is used for assessing a prescriptive requirement is also used to assess whether an entity’s self-selected controls actually meet the security objective.
Of course, in 2022 this is all theory. We will have to wait until the standard is used in practice to see if the customised approach actually works and is assessed as promised. But if it does, it has the potential to be revolutionary.
2.3 Extinction: This is not how IT works anymore
When the first version of PCI DSS was released, agile and the cloud didn’t really exist. The standard comes from the era of physical infrastructure, pre-virtualisation and essentially waterfall development.
Although the standard has evolved over time, it hasn’t really adapted to agile, to CI/CD and to a cloud-first way of working, and to do so would require the PCI SSC to throw away PCI DSS and to start again, which practically and emotionally it will struggle to do.
To some degree the objective-based, Customized Approach can compensate for the standard not reflecting modern IT and security practices. But the more that the standard’s approach diverges from the ways we now build and secure technology, the closer to extinction it becomes.
If there is a prescriptive version 5 of PCI DSS, it will need that complete re-write based on how infrastructure and applications are developed, deployed, and managed in the 2020s not the 2000s.
3. The use of PCI DSS by the brands
I’ve separated out my discussion of the actual standard from its use by the card brands because although they may seem one-in-the-same to a casual observer, they are separate.
If tomorrow all the card brands decided that they did not require organisations to comply with PCI DSS then the standard would still exist, but I doubt it would be used by anyone.
3.1 The evolution of the payment ecosystem
Firstly I want to go back to my opening discussion. Faced with fraud due to stolen card data, the brands chose to ask every organisation that stored, processed or transmitted cardholder data to protect it, rather than redesigning their payment system to make stolen cardholder data worthless.
However, although it has happened gradually, the payment system has now been reengineered and adapted to devalue stolen payment card data — and this is the real omen of extinction for PCI DSS. There are four key indicators:
3.1.1 EMV chip cards in face-to-face transactions
The global use of EMV cards has meant that the data stolen from a face-to-face (F2F) transaction1 can no longer be reused to make a fraudulent transaction. The card brands have recognised this, and have effectively removed the requirement for customer-present merchants to comply with PCI DSS.
Mastercard’s exemption program is described here:
Visa’s is called TIP and is described here:
https://usa.visa.com/supporting-info/merchant-qualifications.html
Amex’s is called STEP and is described here:
3.1.2 PCI DSS now only exists to protect 3 digits of a 16 digit card number
Earlier this year I wrote about how the move to 8-digit bank identification numbers (BINs) meant that PCI DSS now only exists to protect three digits from the middle of a card number.
This makes brute-force guessing of numbers easier (and yes, criminals use this attack) and I implied that because of this the brands are more confident that they can detect and block fraudulent transactions more easily, and are therefore less worried about stolen data being used to make a transaction.
3.1.3 Secure Customer Authentication (SCA) and 3DS version 2
In the EU, regulators stepped in to make the card brands’ decision for them by ensuring that data stolen from a e-commerce transaction (PAN, CVC2, etc.) cannot be reused to make a payment transaction.
The snappily named Payment Services Directive No. 2 (PSD2) requires that Secure Customer Authentication (SCA) has to be used by the customer to authorise a transaction.
SCA requires the card holder to use multi-factor authentication as part of the authorisation process which is typically accomplished by entering code received via SMS to a registered device, or by confirming a purchase from within the card issuer’s app on the customer’s smartphone. The card brands worked together within EMVCo to develop the necessary protocols for SCA, and this is called 3D Secure version 2.2
3.1.4 Devices, not cards
Increasingly, payments are being made with devices not physical cards. The device doesn’t contain the actual PAN but a token (that looks like a PAN). Data stolen from transactions initiated by devices using tokens can not be reused.
3.2 Revisiting the reasons for PCI DSS to exist: Extinction
At the start of this discussion, I averred that back in 2005, in order to stop the problem of stolen cardholder data being used to make fraudulent transactions, the card brands had two choices:
To redesign the payment system so that stolen cardholder data couldn’t be used to make fraudulent payments
To require every organisation that stores, processes or transmits cardholder data to secure it, to reduce the risk of the data being stolen.
In 2005 the brands chose the second option. However, now in 2022 they are close to achieving the first:
With EMV chip cards, the face-to-face element of the payment system was redesigned to make stolen cardholder data useless, and that is reflected in the brands essentially removing the requirement for PCI DSS compliance from this channel.
EMV 3DS supporting SCA makes stolen cardholder data from e-commerce transactions useless to make a payment transaction.
Logically then, once these two technologies are present in all global markets, there is no reason for the card brands to require compliance with PCI DSS, because if data is stolen from any channel, it will be valueless to a criminal. And therefore, PCI DSS should become extinct from the perspective of the card brands’ compliance programs.
4. My predictions
4.1 Privacy regulators will continue to be concerned about the security of cardholder data.
A large part of the world has privacy laws or regulations which generally have a requirement for organisations to take the appropriate steps to secure personal data (GDPR) or PII — and cardholder data is personal data / PII.
Even if the card brands stop requiring organisations to comply with PCI DSS, privacy regulators will still expect the data to be protected, and historically PCI DSS has been one of the benchmarks they use. For example, the UK’s Information Commissioner's Office (ICO) guidance3 states:
Although compliance with the PCI-DSS is not necessarily equivalent to compliance with the UK GDPR’s security principle, if you process card data and suffer a personal data breach, the ICO will consider the extent to which you have put in place measures that PCI-DSS requires particularly if the breach related to a lack of a particular control or process mandated by the standard.
I’m sure that the card brands welcome the fact that regulators have now taken the lead in regulating the security of personal data, and that they no longer have to be the source of risk impact in the event of a breach of confidentiality of cardholder data.
4.2 E-commerce transactions will be more attacked.
I predict that criminals will develop new attacks against e-commerce transactions.
Once it becomes impossible to reuse stolen data, we will see criminals pay more attention to attacking the transaction itself and especially the 3DS protocols. Because a transaction occurs in what is essentially an unsafe environment (the consumer’s browser) these attacks will be hard to protect against. I’m thinking of overlay attacks, relay attacks and Adversary-in-The-Browser (AiTB) attacks.
4.3 The card brands will evolve their use of PCI DSS.
My experience of working for two card brands suggests that when these new attacks occur, their initial knee-jerk reaction will be to impose security requirements on merchants and service providers.
My guess is that the new requirements in PCI DSS v4 that aim to prevent4 and to detect5 criminal activity in the consumer browser, will survive any other PCI DSS extinction event and over time we will see more emphasis on securing what happens in the browser.6 At RSA Conference I argued that the consumer browser would be the major focus for criminal attacks because, in time, that will be the only place left where their attacks against the payment ecosystem would be financially successful.
In a few years’ time, what we all now think of as SAQ A and SAQ A-EP may be all that remains in the card brands’ compliance programs - and that is evolution.
Or what I understand US readers may call brick and mortar transactions.
This is a simplification of 3DS v2 - like an EMV F2F transaction, there’s also a unique cryptogram generated that can be validated by the issuer.
Requirement 6.4.3
Requirement 11.6.1
Given that all web pages now are essentially composed of numerous JavaScript files originating from multiple sources — many of which are outside of a merchant’s control.