While the PCI v4 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.
See also: White Paper: PCI DSS Version 4.0: What You Need to Know
There has been a lot of talk about the upcoming release of the PCI standard–PCI DSS v4.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.
Watch our SecurityMetrics Summit session about PCI DSS v4.0 here.
Surrounding the release of PCI DSS v4.0, the PCI Council has requested more involvement from both the merchant payment community and Qualified Security Assessors (QSAs). The PCI SSC has announced three separate Requests For Comment (RFC) for PCI v4.0 and is expected to wrap up by the end of 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 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:
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.
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:
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
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.
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.
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).
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.
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.
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’!
.svg)
