A Crucial Change in 4.0.1 of PCI DSS

Scope matters

I know, it’s been quite a while since I wrote here. My last post was about the 2022 North America Community Meeting. Since then we’ve all been to Portland and this week the community will be in Boston. If you are at the event please come and say hello, I’ll be around the Jscrambler booth for most of the Community Meetings in Boston and in Barcelona.

A few months ago version 4.0.1 of PCI DSS was released. As a point-zero-one release it is supposed to be “Limited”,¹ however there are some not insignificant changes that may have a larger effect that you may expect.

One of the most crucial is in respect of scoping decisions. The scope of an entity where the PCI DSS requirements are applicable is a multi-part test which was more clearly laid out on 4.0 than it was in 3.2.1.

To summarise, section four on scoping in version 4.0 stated that the PCI DSS requirements apply to system components, people and processes that either:

“Store, process or transmit account data (cardholder data and/or sensitive authentication data) or

Which have unrestricted connectivity to system components that store, process, or transmit cardholder data”

Together these constitute the cardholder data environment or CDE.

Additionally in 4.0, the DSS requirements also apply to

“System components, people, and processes that could impact the security of the CDE”

Personally I thought this was a sensible clarification to the way the requirement was previously written in 3.2.1 as

1. It cleared up what was meant by “connected to”,

2. Meant that you didn’t have to read the section backwards as it defined the CDE before referring to it.

However, in 4.0.1 there’s a change and depending on how you’d scoped your assessment, this could be a large change.

The definition of the CDE is still the same but the third-leg has changed from:

“System components, people, and processes that could impact the security of the CDE”

to:

“System components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data.”

And there’s a whole world of difference between what could impact the security of the CDE and what could impact the security of cardholder data and/or sensitive authentication data.

Let me give you an example. Imagine you include some third-party JavaScript on the payment page that collects cardholder data from your customers – something like Google Tag Manager (GTM) which is managed by your marketing department. Because a webpage has no inbuilt segmentation or isolation, any JavaScript included on the page can access any data displayed on or entered into the page, including the fields that collect the payment card data.

In the 4.0 scoping definiton, GTM (and your marketing department) are not in scope of the applicable PCI DSS requirements. GTM doesn’t store, process or transmit cardholder data and it can’t impact the security of the CDE (and there are new separate requirements 6.4.3 and 11.6.1 to manage this risk).

Thinking about the 4.0.1 scoping definition, GTM, your marketing department and any JavaScript loaded into the browser certainly “could impact the security of cardholder data and/or sensitive authentication data.” So would GTM, where it is loaded from, and your marketing department be in scope of all applicable requirements?

Here’s another example. If you accept cardholder data over the internet, either on a website or via an API, the client sending you the data is going to rely on the DNS to resolve the host specified in the destination URI to an IP address.

The DNS infrastructure (your DNS servers and domain registrars that hold the authoritative zone records) can’t intrinsically affect the security of the CDE and so would not be in scope of the PCI DSS requirements based on the scoping rules in version 4.0.

But an attack against the DNS infrastructure could redirect a payment from a client to a different API endpoint, or allow an attacker to impersonate your website. An attack against the DNS infrastructure “could impact the security of cardholder data and/or sensitive authentication data”. In the 4.0.1 scoping definition, would the DNS infrastructure be in scope of the PCI DSS requirements?

If you’ve made scoping decisions based on the 4.0 definition,² it’s time to double-check them and talk with your assessor.

---

1. Which should just be changes to sub-requirements and/or testing procedures to clarify intent or address confusing language.

2. Or the version 3.2.1 definition.