What you need to know about PCI 4.0: Requirements 5, 6, 7, 8 and 9

In Part 1 of this series, we reviewed the first four sections of the new PCI standards. As we continue our examination of PCI DSS version 4.0, we will consider what organizations will need to do in order to successfully transition and satisfy this update.

Requirements 5 through 9 are organized under two categories:

Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

Requirement 6: Develop and Maintain Secure Systems and Software

Implement Strong Access Control Measures

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Requirement 8: Identify Users and Authenticate Access to System Components

Requirement 9: Restrict Physical Access to Cardholder Data

Requirement 5 – Painting with a Broader Brush

The general heading that precedes Requirement 5 has been updated. As described in the comparative guide:

Updated principal requirement title to reflect the focus on protecting all systems and networks from malicious software. Replaced “anti-virus” with “anti-malware” throughout to support a broader range of technologies used to meet the security objectives traditionally met by anti-virus software.

This information falls under the category of maintaining a vulnerability management program. As a whole, this category is similar to PCI 3.2.1. However, there are some notable updates and a thematic change for Requirements 5 and 6 that this is going to represent a potential change in scope for many organizations.

Requirement 5 is now aimed towards protecting all systems and networks from malicious software. The PCI Security Standards Council recognizes that they intentionally changed this wording because they want to place more focus on the organizational level, and to a larger, broader swath of the network. The goal there is making sure that anything that might involve the Cardholder Data Environment (CDE) needs to be protected.

The potential impact of this compulsory scope change is that organizations will need to reevaluate their entire environments. This could significantly increase—or even decrease in some cases—an organization’s scope. There is also the possibility that an organization may have to explain why their scope has remained the same. Obviously, that is going to be very specific to each environment. The best approach for any organization as they prepare for their first PCI 4.0 audit is to have accurate documentation to justify the scope of their CDE under the new guidance, with specific detail to the new wording.

All auditors will receive training in the new standard, so it’s likely that we’re going to see some additional guidance from the PCI Security Standards Council around this. They might publish some opinion articles to help guide people into what the changes mean, but this change of wording is the most notable change on Requirement 5, and it is something that all organizations will need to address.

Also in Requirement 5, the word “anti-virus” has been updated to “anti-malware.” This will probably not have a major impact on most organizations, as anti-virus is not only old terminology, but it is also an outdated technology, from which most products have improved beyond that singular protection mechanism. The important part to remember about this aspect of Requirement 5 is that it must be undertaken with specific attention to the edict against default configurations from Requirement 2.

Requirement 6 – Application Development Graduates to Software Development

In the earlier PCI Standard, the concentration was on application security. In PCI 4.0, the attention has expanded to maintaining secure systems and software. Along with that, the language also changed from “internal and external” applications, to “bespoke and custom” software. “Bespoke” is not exactly a word that speaks to the common person, so that is an interesting, albeit appropriate, choice. To clarify, something that is customized is generally a modification to an existing product, whereas, bespoke indicates a product that is built to a customer’s specifications. A subtle difference, but worth noting.

Along with the new vocabulary, this represents a scope change for many organizations, similar to Requirement 5. For example, when you say “applications,” many people think of heavy software, with a centralized server, requiring an installation process. However, when you say software, the perception gets a little bit more broad. Again, I anticipate that we will probably see some further guidance about this, especially over the next year, but organizations need to think about the effect of this requirement. Perhaps you purchased a tool for your environment, or you’re a software company, and you’re developing a new product. These are probably in scope under PCI 4.0.

It is conceivable that these software products probably should have been in scope before, at least if your auditor was diligent about interpreting the earlier requirement. The potential depends on your organization’s business process. For instance, if your organization is an insurance company that accepts credit card payments through your website, you could have reasoned that under PCI 3.2.1 the only thing that was needed to monitor for an application was the backend processing of that credit card data. However, if we contemplate this new requirement in conjunction with Requirement 3, that credit card processing software now qualifies under the term “account data.” Given this interpretation, it’s very possible that we’re going to see a change in scope, where instead of just strictly requiring you to monitor and prove that your development of that credit card processing on your website is secure and has good protections, the scope could span from user log in to log out. Everything that operates on your website is now part of this system, because now it is part of the account data.

For that hypothetical insurance company, they might have had a really strong development pipeline for that script that literally just takes that credit card data and funnels it off to the payment processor—and that was the only thing they had to care about. But now, they might also have to think about the entire authentication system; they might have to think about their web servers a little differently. So, when we talk about secure systems and software, it’s a little bit more broad, with a more general scope.

This requirement change is more than simply placing more items in scope. Thematically, everything in PCI 4.0 is designed around a mindset. Auditors are going to start thinking more holistically about the CDE, and what’s in it. What is important throughout the new version, is the interplay between the requirements.

Requirement 7 – No “All Access” Passes Allowed

The proclamation of Requirement 7 is very straightforward: Restrict Access to System Components and Cardholder Data by Business Need to Know. However, there is some confusing language that follows. The text says “cardholder data,” but the overall tone of version 4.0 is around “account data.” One has to wonder if this is just about cardholder data, or is this going to be broadened to mean account data? This may require a formal clarification in a future version of the standard.

Aside from that puzzling section of language, Requirement 7 is about access controls: Grant access to only those people who need it for their business function and deny access to everyone else. This is an old cybersecurity practice. This requirement can also create a scope change, because it now pertains to all systems. If an organization was compliant in PCI 3.2.1, this new version applies the control more generally, with a very specific interpretation. That interpretation is that it’s no longer sufficient to classify a system as a whole, and only look at access control lists at the system level. Now you have to understand the component level and how those components flow through the organization.

In PCI 4.0, it’s going to be really important that organizations home in on all of their access controls, and to fully document and justify who has access to these components.

Requirement 8 – Harbinger of a Zero Trust World

Requirement 8 is a direct extension of Requirement 7. It is still in this theme of strong access controls. If we think of Requirement 7 as “make sure the right people have access to the right systems and components,” Requirement 8 is “make sure that you’re identifying those users and you’re actually authenticating their access.” This is not vastly different from the previous version. The sections are reordered, but the big change here is in a couple of terminologies.

Overall, if an organization was compliant with 3.2.1, it might actually still be compliant here. The important part is making sure that there are processes for identifying and authenticating all those who are on those systems. When you take both Requirement 7 and Requirement 8 as a whole, you can hear murmurings of a move toward zero trust architecture. PCI 4.0 doesn’t mention it, but the theme is, changes have broad implications. It is not unreasonable to make the logical leap that zero trust is certainly on the mind of the Security Standards Council.

An organization should use this as a harbinger, and an opportunity to start thinking about how everything in their environment is structured and how they can move towards that future zero trust.

Requirement 9 – The Physical Environment is Also an Asset

Requirement 9 is the physical access requirement. It is safe to say that any organization that was compliant with the earlier version is also going to be compliant with version 4.0. Other than the “Roles and Responsibilities” directive, which flows throughout the entire standard, the only unique “evolving” section in Requirement 9 is to “define the frequency of periodic Point Of Interaction” (POI) device inspections based on the entity’s targeted risk analysis.” Additionally, this requirement is only a best practice until 2025, giving organizations ample time to incorporate this into their compliance activities.

The important part to remember—as with all parts of the standards that reference any asset— is to maintain secure configurations of those assets. In the physical realm, this would now include all the mechanisms that allow access to secure areas, including badge readers, door systems, and even camera systems that monitor those secure areas.

As our examination of the new PCI Data Security Standard unfolds, we see that it is important to adhere to each requirement individually, and to also keep a keen eye on how all of the requirements relate to one another. In the next part of this series, we will complete the overview of the new standard, setting the full stage for organizations to anticipate and maintain adherence with the updated requirements.