What you need to know about PCI 4.0: Requirements 1, 2, 3 and 4.

The Payment Card Industry Security Standards Council has released its first update to their Data Security Standard (PCI DSS) since 2018.  The new standard, version 4.0, is set to generally go into effect by 2024, but there are suggested updates that are not going to be required until a year after that.  This, of course, creates a couple of problems for those who want to phase in the new standard.  One problem in particular is that the linguistic approach in the new version seems to have a lighter touch than the earlier version. This less-prescriptive language raises some concerns for achieving compliance.

In this series, we will examine various sections to help you get a better understanding of what is new, how it differs from the previous version, and how to best implement these changes.

The first four requirements of version 4.0 fall under two broader categories:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

Requirement 2: Apply Secure Configurations to All System Components

Protect Account Data

Requirement 3: Protect Stored Account Data

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

As with the previous versions of PCI DSS, the predominant aim is to protect the Cardholder Data Environment (CDE).  The new version offers three categories of changes: Evolving requirements, Clarification or guidance, and Structure or format.

Requirement 1 – A New Standard With a New Voice

Requirement 1 is primarily the same as it was before.  The first glimpse of the more generic language of the new standard is displayed in the general description of the network security controls.  Classified as an “evolving requirement” version 4.0 states:

Updated principal requirement title to reflect the focus on “network security controls.”

Replaced “firewalls” and “routers” with “network security controls” to support a broader range of technologies used to meet the security objectives traditionally met by firewalls.

The other evolving requirement is: “Replaced requirement for “Description of groups, roles, and responsibilities for management of network components” with general requirement for roles and responsibilities for Requirement 1.”  In the earlier version, the roles and responsibilities were to be more specifically delineated.

This is an example of how the language of the standard has changed.  While the updated language does not weaken the spirit of what is necessary, it certainly broadens the possible methods to achieve the goal.  However, this can cause some confusion, and be challenging if it does not meet the anticipated expectation of a Qualified Security Assessor (QSA).

Further to this point, although the term “network security controls” specifically mentions the use of firewalls, it also continues, “and other network security technologies that act as network policy enforcement points . . .”

What is quite noticeable is that the technical requirements of version 4.0 are probably going to be very similar to what an organization is already doing compared to the prior version. However, because of the thematic change in how 4.0 has been documented, a lot of the focus is on operational compliance and operational security. Arguably, version 4.0 is seeking to change the mad scramble pre-audit behavior practiced by some organizations. They want organizations to put documented processes in place.  There is a little more emphasis on having all of the procedures to protect the CDE carefully, and fully documented.

Every action need not be approached as if an auditor is looking over one’s shoulder, but there should always be the question: What is my audit justification for a particular action?  It’s also just as important to show that you’re reviewing your procedures on a regular basis. So, establish a review process, document your review process, have specific people listed or roles in the organization listed as the people responsible for deciding if those controls are still adequate, and set a cadence for routinely reviewing whether updates are needed on the defined processes.

Those are the kinds of effort that, though historically were very successful in showing an auditor that your organization was trying to do all the right things, are the kinds of things that I think are going to start to be looked at a little bit more detailed by the auditors themselves. An organization that makes sure that they have the controls in place, that they’ve documented the procedures, and that they have a good review process to show that they are continually updating and evolving their compliance needs based on the changes to their environment, those are the kinds of things that will make an audit go a lot more smoothly and be more successful. That is the big highlight of the revisions to Requirement 1.

Requirement 2 – Beyond the Defaults

Requirement 2 of the new standard directs that secure configurations are applied to all system components. This has a strong focus on having these configurations defined for your organization, rather than using vendor-supplied defaults, yet nowhere does it tell you exactly what qualifies as a secure configuration. The reason for that may be that it forces an organization to focus on routinely reviewing the environment and gives the standard more flexibility to enforce the constantly evolving best-practices of our industry.

The biggest change of Requirement 2 over the earlier version of the Standard is that, in the prior version, the main point was about vendor-supplied accounts and passwords.  While that still exists in version 4.0, the overarching theme is about secure configuration.  Without trying to sound cynical, if you don’t have a configuration documented, that’s when you get one question from an auditor, you answer it, and then you get many follow up questions, each, themselves having more follow up questions. Anyone who has been through an audit will understand exactly what I am describing. Having it documented, having it reviewed, and having a process for how often you review these is very important.

If you’re noticing a pattern, you are correct; it sounds repetitive. Throughout everything in PCI 4.0, there is a lot of focus on processes and procedures, and reviewing and documenting those processes and procedures to make sure that you have a well understood environment.  The PCI Security Standards Council is really pushing for organizations to focus on this compliance routinely.  The new standard doesn’t say you must review your processes every two weeks. It just says that you should have these processes, and they should be reviewed and understood and up to date. Since every organization is different, it’s important for an organization to actually sit down, take a few minutes and think about their compliance program as a whole. Organizations that take the time to clearly document their configurations and review processes will have an easier time proving to the auditors that they are meeting the new standards.

So, with Requirement 2, if your company is already performing secure configuration management, then you will be far ahead of the curve, but it’s not just enough to just review your configurations and make sure that they seem to be secure and that they follow industry standard hardening practices.  It’s also important that there is a clear definition of what those configurations are accomplishing, what they are and why they were chosen. This is especially true if there is something unique about your environment, some reason that it’s been tailored differently.  You should have that documented, and you should have a justification for that.

One of the thematic changes that I would advocate for is that if an organization does not already have a compliance team, they don’t necessarily have to hire people for this, but they should create an internal compliance team with at least one person from their security side of the organization with a position on that compliance team. That team should meet once a month to review the standards, and the policies and procedures. They should make sure that they are being kept up to date and make other people held accountable to what those needs are that will help an organization be successful with the new PCI standard as a whole.

To be clear, while there are some concerns about the toned-down language, this is the first time I recall a compliance standard I’ve read and said, “wow, this is actually really beneficial, not just prescriptive about what to do to the computers and environment. This version is strongly focused on establishing the right mindset into people operating these environments.  This could form a systemic change within the industry, where more people will be thinking about security on an ongoing basis; the idea that your security is driven not just for the sake of compliance, but to achieve security”.

Requirement 3 – A Fundamental and Functional Shift

Requirement 3 is also updated to focus on Account Data, rather than the earlier, narrow focus on Cardholder Data. This is a fundamental change in alignment. The requirement broadens the area, whereas, “cardholder data” is very specific. Account data, on the other hand, encompasses a greater expanse of possible information.  The update to Requirement 3 brings much more in scope for PCI compliance. So, you might have an email system that was never in scope for PCI that suddenly is in scope. Or, you might have entire sections of your network with systems on it for which you never had to consider PCI compliance that – because of how your business operates – might now become part of the CDE.

Functionally, the revisions to Requirement 3 could represent, potentially a large expansion of systems subject to PCI compliance. Some organizations might even have to restructure their network so that they can more thoroughly protect the CDE, or at least consider how they’ve applied the network security controls within their environment.  This requirement could represent a large expansion in effort. Organizations must closely examine this intentional change in the language of this requirement. There is a fundamental difference in how the PCI Council is interpreting what should be protected. Yet, because they don’t define this with very specific terminology of the exact data points that need to be protected, this is going to come down to the auditors’ interpretation. There is a strong budgetary consideration here if an organization needs to expand its PCI compliance program to adhere to this revised standard. From a business perspective, this scope change is very impactful.

Requirement 4 – Encrypt it all, But We Won’t Get Specific

Requirement 4,  the “encryption requirement”, remains very similar to its earlier counterpart. It contains much of the previous terminology. The main difference is that in the past, the PCI Council was a little bit more prescriptive about what it meant to be using strong cryptography. Now they’re not. In the prior version, they indicated that an organization had to use the latest version of SSL, or at least TLS 1.2. In the new standard, they took out that specific language.  One possible reason that this generic language may be used is that when nonspecific language is used in a compliance standard, it makes the standard applicable for more time.

One could say that the new PCI DSS is more of a philosophical document that is aiming more towards the establishment of a solid mindset around an operational security program, and an operational compliance program. So, instead of focusing on specific technical standards, the entire PCI 4.0 is drafted with the idea that an organization should perform secure actions, and keep data secure. With that mindset, an organization is more likely to keep up to date with general industry standards. This makes security a routine part of the daily operations, rather than an annual event.  In the next blog, we will continue our exploration of the new standard.

Stay tuned!