The release of PCI DSS v4.0
There has been a lot of talk about the upcoming release of the PCI DSS standard–version 4.0.
While this standard is not expected to be finalized and released until the end of 2020 or the beginning of 2021, the PCI Security Standards Council has made some information available to the general public on what some of the changes might be. As for the exact details of the requirements, that is still under development by the PCI Council.
One exciting thing about the release of PCI DSS v4.0 is that the PCI Council has requested more involvement from both the merchant payment community and the Qualified Security Assessors (QSAs) on this version update. There has been one Request For Comment (RFC) release of the draft standard already, and there is expected to be at least one more RFC session, which will wrap up in 2020.
While those involved in providing feedback to the Council are not allowed to release any details about the current form of the 4.0 requirements, we can all be excited that the requirements will be receiving a thorough review from the assessors and payments community.
Why the update to PCI DSS 4.0?
Why is the PCI Council making a major rewrite of the PCI DSS when it is considered to be a fairly mature standard? There are four major reasons for the changes:
- Ensure the standard continues to meet the security needs of the payments industry
- Add flexibility and support of additional methodologies to achieve security
- Promote security as a continuous process
- Enhance validation methods and procedures
The release of this new 4.0 version at first glance may cause fear in the hearts of those already very familiar with the current PCI DSS requirements.
Rest assured that the 12 core PCI DSS requirements remain fundamentally the same; it’s not a totally new standard.
It is assumed that there will be some wording changes–maybe fairly extensive changes–but this is in an effort to make the requirement statements more “outcome-based” and more clearly define the control objectives for groups of requirements.
Instead of focusing completely on what “must” be implemented to be compliant, the requirements will be stated in such a way that the final security outcome of a requirement is more obvious.
It is also expected that the guidance column on the standard document will be enhanced and expanded, so that is a good thing.
All in all, the changes to the PCI standard are expected to be an improvement that will also include expansion of requirements into a few new security areas.
It should also be noted that the adoption of PCI DSS v4.0 will include an overlapping sunset date for PCI DSS v3.2.1 so that the transition between versions will be smooth. In addition, any new requirements being added to the standard will be future-dated when the standard is released in order to allow merchants to develop new processes before the new requirements are enforced. These future and sunset requirement dates are not yet known since the 4.0 standard is still under development.
What we know so far about PCI DSS v4.0
In this section, I will provide what details I can regarding the proposed changes to the PCI DSS standard. As mentioned above, the changes are focused around four major areas:
1- Ensure the standard continues to meet the security needs of the payments industry
As time moves on, technology changes and so do the attack vectors of bad actors trying to compromise systems. You’ll want to keep up with this changing technology, and the 4.0 version of the standard will address things from scoping to cloud computing. Table 1 below shows some of the expected areas of further guidance and definition. This may not be an exhaustive list but will give you some ideas of what to expect.
Table 1 - Areas of PCI DSS 4.0 evolution, to help the standard stay current and relevant
Desire to make scoping guidance a more integral part of the standard itself and provide more detail on requirements for scoping validation. New requirements are expected to include requirements for organizations to verify their PCI DSS scope and some additional requirements for service providers.
Protection of Cardholder Data Transmissions
We expect to see continued enhancements to requirements for the protection of card data in motion throughout the network.
Anti-Phishing and Social Engineering
The Council is recognizing that phishing and social engineering are becoming bigger vectors for attack. They announced there will be treatment of these topics in the 4.0 standard.
Requirements for performing risk assessments have been in PCI DSS for years; we expect to see these requirements expand and provide more detail for risk management as a whole. Expect to see additional requirements being added to clear up some of the vagueness of the risk assessment process mentioned in section 12 of the standard.
We expect to see the Council aligning more closely with some industry best practices in authentication. Perhaps addressing password length, periodic change guidelines, and multi-factor authentication enhancements. Proposed revisions to requirements on passwords are expected to accommodate different authentication options.
The Council has mentioned that they want to include mentions of cloud technology, where it may apply in the standard. They will also review Appendix A1, which contains requirements for shared hosting providers, in order to update it with cloud technologies in mind.
2- Promote security as a continuous process
From the beginning, PCI DSS requirements were created to help organizations develop habits of security best practices, with the intention that the requirements are followed year round–rather than just during an annual assessment period.
Many organizations have been able to make the transition to the mindset of “security as a lifestyle,” while others are still focused on “passing” an assessment and moving on to seemingly more important things.
We expect to see more details and guidance added to version 4.0 that will further emphasize this transition to security as a business-as-usual process. For example, there may be changes in sampling guidance to include more gathering of validation information over a period of time to encourage continuous security process.
3- Enhance validation methods and procedures
The PCI Council will look at validation methods and procedures to make sure they are meshing with the new 4.0 release.
Currently, there is not much information available on this topic from the Council, but we know that they will be seeking feedback from participating organizations on ways to improve this aspect. For example, it is expected that the SAQ and AOC process and contents will be examined and enhanced. It’s unclear how, or even if, the new Customized Approach methods will be able to apply to the SAQ validation methods.
4- Add flexibility and support of additional methodologies to achieve security
Last but not least, the Council wants to add flexibility for merchants meeting a security objective.
As a QSA, we sometimes get asked the question, “Our methods are secure, can’t I meet this requirement another way?” The response had to be, “We could look at defining a compensating control, but that would be considered a temporary solution until you can meet the requirement the right way.”
Version 4.0 of the standard will try to resolve this scenario by introducing the concept of validation of a security control using a Customized Approach.
It’s important to note that for those companies who already have controls in place that meet the requirement as stated–those controls still work and are a valid way to achieve compliance. This familiar method is the “Defined Approach,” and it’s essentially what we have been doing for the last 15 years. Either approach–Defined or Customized–can be used for a PCI DSS requirement, and both approaches can be used on a single Report On Compliance (ROC).
More on PCI DSS v4.0’s Customized Approach
The biggest “buzz” around the new 4.0 version is the concept that PCI DSS will allow customization of requirements and testing procedures. Using the Customized Approach as a compliance validation mode will present new benefits and considerations.
There are many ways to secure computer systems and networks. Many businesses have security solutions in place that may meet the intent of a security objective but not meet a specific requirement. This approach could let organizations show how their specific solution meets the intent of the security objective and addresses the risk, and therefore provides an alternative way to meet the requirement.
If the solution is viable, organizations would then work with a QSA to develop testing procedures to validate that the proposed solution is in place, mitigates risk, and meets the intent of the objective.
Compensating controls vs. customized validation
This new approach will take the place of compensating controls in the 4.0 standard. The PCI council stated that, “Unlike compensating controls, customized validation will not require a business or technical justification for meeting the requirements using alternative methods, as the requirements will now be outcome-based.”
Sounds simple, right? Well, maybe. This new validation method will most likely result in more initial assessment work for the business in order to prepare documentation and risk assessment data for a QSA to evaluate. It will then require specialized testing procedures, developed by the QSA and agreed upon by the business (see figure 1).
The customized approach will not be for everyone and will be most suited for organizations with mature security and risk assessment processes in place.
At the end of this custom process, the big advantage will be that you have defined a more permanent solution for compliance validation of specialized security controls. This is different from previous “temporary” compensating controls in earlier versions of the standard, where you also have to document a justification for the control using a business or technical constraint.
Figure 1 - Customized Approach Milestones (image from PCI council presentation)
If this new Customized Approach offers more validation flexibility, then what’s the catch? Why won’t this be the most common validation approach used by everyone for PCI DSS compliance?
This can be simply stated with the phrase, “with great flexibility comes great responsibility.”
Using the Customized Approach to validate a security implementation you already have in place may save on new capital expenses, but it will require more tasks on your plate during an assessment cycle. You will need to thoroughly document, test, and conduct risk analysis efforts for presentation to your QSA. The QSA then has to review this information in order to develop custom testing procedures, and more reporting will be required.
Therefore, an assessment using the Customized Approach will likely cost more than an assessment using the defined approach, but it may be a more cost effective method when all aspects are considered. Be sure to look for a QSA with the depth and years of experience necessary to validate custom controls and make appropriate testing procedures.
There is one expectation I would like to set as a long time QSA: the knowledge of the Customized Approach method should not be an excuse to assume that all you have to do is say to your QSA “Here is how I do things. I don’t care how you do it, but make it work for the assessment.” Utilizing the Customized Approach will require working together.
Updating to PCI DSS v4.0
Is the PCI DSS v4.0 update a change to fear? No, it’s a good change. The best way to prepare for v4.0 is to stay compliant with PCI DSS 3.2.1 requirements or keep working towards compliance.
In any security standard, there will always be evolving requirements and process improvements, embrace the changes and be grateful someone is watching the threat environment and updating standards. This helps all of us to better counter the activities of bad actors and hone our skills of defense. So, keep battling and Qapla’!
Gary Glover (CISSP, CISA, QSA, PA-QSA) is the VP of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. Live long and prosper as you visit his other blog posts.