At the 2019 Payment Card Industry North American Community Meeting in Vancouver, Canada, the topic that garnered the most conversation among the 1500+ attendees was, of course, the Council’s preview of the long-anticipated Payment Card Industry Data Security Standards version 4.0 (PCI DSS v.4.0).

PCI DSS v.4.0 is the next major evolution of the 15-year old PCI DSS framework. The last significant revision of the PCI DSS (PCI DSS version 3.0) occurred in 2013. Since that time, there have been three minor revisions, resulting in the current version 3.2.1. Emma Sutcliffe, Senior Director, Global Head of Standards from the PCI Security Standards Council, opened her session by announcing, “there are going to be a lot of changes upcoming in 4.0.”

While the RFC version of PCI DSS v.4.0 has not yet been released as of this writing, LBMC was able to capture several insights from the Council’s preview of the upcoming PCI DSS v.4.0 that may be of interest to PCI merchants and service providers. Those details are shared below, as well as additional information about the RFC process and how you can be involved.

Four Goals of PCI DSS v.4.0

Four goals are driving the development of PCI DSS v.4.0:

  1. Ensure the standard continues to meet the security needs of the payments industry
  2. Add flexibility and support of additional methodologies to achieve security
  3. Promote security as a continuous process
  4. Enhance validation methods and procedures

PCI DSS v.4.0 is focused on addressing the evolving threats to the payments ecosystem and how these threats have changed over time, how the technologies used for payments processing have changed since the last major release (with solutions such as ApplePay), and how the security methods and technologies that have been developed to address these threats have evolved.

The planned updates for the standard will focus on strengthening security control requirements and adding flexibility for achieving compliance with the framework via the use of different reporting options.

While the 12 high-level requirements will remain the same, there will be several new control specifications within the requirements that are proposed to address the ever-evolving risks and threats to payment data. The proposed changes are meant to reinforce security as a best practice and to be implemented into the business-as-usual cybersecurity operations process via a continuous audit approach. Additionally, all requirements have been redesigned to focus on the security objectives of each control. This approach is expected to reduce the need for the use of compensating controls and allow for more flexibility for organizations. The specifics of the control changes proposed in version 4.0 will be made available in an upcoming RFC (more details below).

Below are some of the updates to PCI DSS v.4.0 that were revealed during the session:

  1. Scoping – Increased testing and documentation will be required for confirmation of the accuracy and completeness of scope of the cardholder data environment (CDE) and periodic scope validation processes.
  2. CHD Protection – Card encryption requirements will be expanded to include all transmissions of CHD instead of only those across public networks.
  3. Security awareness training – Requirements for training of end users will be enhanced to include more information regarding current threats and phishing, social engineering, etc.
  4. Risk assessment – The Council recognizes that the current PCI DSS requirement that a risk assessment be conducted is not always resulting in useful risk analysis and risk management outcomes. This requirement will be modified to ensure that the risk assessment is not being treated as a “checkbox exercise” by organizations.
  5. Authentication – The new version of the DSS will provide more flexibility for the use of authentication techniques and solutions within the CDE to align them with industry best practices. For example, the current version of the PCI DSS requires password changes every 90 days; however, recent guidance from NIST suggests that longer passwords with less-frequent change intervals are actually more secure. There may also be some additional changes related to multi-factor authentication (MFA) requirements to expand the usage to all accounts that have access to CHD, not just administrators accessing the CDE. When the draft of version 4.0 is released, LBMC will provide additional insights and guidance on this topic, so please stay tuned for some additional guidance regarding how to apply and support this new industry guidance related to password controls.
  6. Cloud environments – Version 4.0 will evolve all requirements to be more accommodating for the use of technologies such as cloud hosting services. 
  7. Sampling – Additional direction for assessors on sampling guidance will be included to verify that controls are in place consistently across the entire population.

Defined Implementation and Customized Implementation of Controls

In the most-talked-about change to the Standards, PCI DSS v.4.0 plans to provide increased flexibility for organizations reporting their compliance state. This new model will provide additional support for organizations who may achieve security objectives and meet the PCI compliance requirements using innovative technologies and leading-practice approaches to cybersecurity risk management. To allow for this, PCI DSS v.4.0 will provide two options for validation of controls: A defined implementation or a customized implementation.

PCI 4.0 - Two implementation options

Slide from 2019 PCI North America Community Meeting

 

The Defined Implementation Approach is based upon the current PCI methodology and is how entities currently assess and report their compliance with PCI DSS. The Customized Implementation Approach provides additional levels of flexibility for assessing and reporting compliance. In this approach, the entity is responsible for understanding the intent of each PCI DSS requirement and demonstrating how its existing security controls achieve the requirement (which may deviate from the PCI DSS control specifications). Organizations can choose to report their compliance via one of these two options or choose a blended approach where some of the control requirements may be assessed under the defined implementation and others using the customized implementation approach.

Validating to the Defined Approach

Entities choosing to validate their PCI compliance using the Defined Approach will continue to assess and validate their compliance in the same manner that they have previously done.  These entities will be responsible for implementing and validating all of the PCI DSS v.4.0 requirements as written, and, entities using a QSA will find that the QSA firm continues to execute the testing procedures as specified in the PCI DSS Report on Compliance.  In this approach:

The Entity:

  • Implements and operates control(s) that meets the PCI DSS requirement.

The Assessor:

  • Plans and conducts the assessment.
  • Follows PCI DSS testing procedures to assess implemented controls.
  • Documents results of testing in the RoC.

Validating to the Customized Approach

Entities choosing the Customized Approach are those that are focused more on security outcomes, risk reduction, and intent of the control.  The goal of this approach is to allow organizations to focus on what they need to achieve rather than how to achieve it, and to give organizations more leeway in how they go about meeting the intent of each PCI requirement.  Organizations using the Customized Approach will have to demonstrate a clear understanding of the intent of a requirement if they choose to validate alternative controls for any requirement.  As a result, in most cases, entities choosing the Customized Approach will be entities with mature risk management processes and, likely, a robust cybersecurity program.

Assessing PCI compliance under the Customized Approach requires several more steps of the entity as well as the QSA assessor:

PCI 4.0 Slide

Slide from the 2019 PCI North America Community Meeting

The Entity:

  • Implements control(s) that meet the intent of the PCI DSS requirement.
  • At a detailed level, the entity will be required to provide documentation that describes the customized implementation for each control objective to include:
    • The who, what, where, when, and how of the controls
    • Evidence to prove how the controls meet the stated intent
    • Evidence of how controls are maintained, and effectiveness is assured.
  • The documentation of customized controls must be supported by the entity’s risk assessment to show how the controls provide equivalent levels of protection.

The Assessor:

  • Plans and conducts the assessment.
  • Reviews information provided by the entity.
  • Develops and derives testing procedures based on controls implemented by the entity and information provided.
  • Documents details of testing procedures and results of testing in the RoC.

Assessor firms conducting Customized Approach assessments will need to spend additional time during the RoC assessment process understanding their clients’ customized control processes and then developing sufficient testing procedures such that the assessor can confirm the effective implementation and operation of the customized controls, as well as that those controls do indeed provide equivalent (or better) security as the defined PCI DSS control.

What does the Customized Approach mean for Compensating Controls?

The PCI Council noted that the original purpose of compensating controls was to provide flexibility for organizations that were unable to meet the original intent of the stated control.  PCI DSS v.4.0’s Customized Implementation builds flexibility into each requirement as opposed to the use of a separate Appendix for reporting compensating controls.  In addition, the use of the Customized Approach does not require the entity to provide a justification of a business or technical constraint (as is currently required in compensating control justification).  As noted in the recently issued blog titled “5 Questions About PCI DSS 4.0” by the PCI SSC, the concept of compensating controls will be removed from the draft version of the v.4.0 standard in the October RFC.  Because entities will be allowed the flexibility to use both the Defined Approach and the Customized Approach within a single PCI assessment, in essence, entities using the Defined Approach that determine a particular control requirement cannot be met would then need to use the Customized Approach for that control requirement.

Recap of PCI DSS Version 4.0

The overall structure of the PCI DSS is retained in version 4.0, and will keep the same 12 high level requirements. Changes to PCI DSS’s layout and descriptions v.4.0 will include:

  • More accurate requirement titles
  • Additional direction and guidance provided in the Overview section
  • Requirements organized into Security Objectives
  • Requirements refocused as objective or outcome-based statements
  • Clear identification of Intent (Objective) for each requirement
  • Expanded Guidance

As with previous iterations of the PCI DSS, LBMC expects that there will be a grace period for organizations to comply with the newly defined requirements, and PCI DSS version 3.2.1 will remain valid for a period of time to support organizations transitioning to the new version of the standard.

RFC Process

While the changes outlined above are expected to be included in the draft of the PCI DSS version 4.0, there is still an opportunity for these elements to change before the final version is released.  The Council will be soliciting feedback from the payments community via a Request for Comments (RFC) process.  The first public RFC of PCI DSS version 4.0 draft will occur in October 2019.  It is expected that the review comment period will be approximately six weeks.  The second RFC period of the v.4.0 draft is tentatively planned for Q2 2020.  After allowing time for incorporation of relevant feedback obtained during the RFC periods, the final version of PCI DSS v.4.0 is not anticipated to be released until late 2020.

Participating organizations, QSAs and ASVs will be receiving a full draft of the PCI DSS v.4.0 and additional supporting documentation in late October and will be invited to submit their comments and feedback during the RFC periods.

Next Steps

So, how can you get involved in the RFC process?  There are two ways: The PCI SSC is opening up the RFC process only to Participating Organizations, QSAs, and ASVs.  If you are not currently a Participating Organization, consider joining now, so that you can provide feedback on the PCI DSS and attend future PCI Community Meetings for no additional cost.  Alternatively, if you are not a Participating Organization, but you are a client of LBMC Information Security, we will be happy to conduct a private briefing with you to obtain your feedback on the draft and provide your comments to the Council during the RFC period.  Simply contact your LBMC Information Security lead QSA to let us know of your interest in reviewing the draft of PCI DSS v.4.0.

Reference Links:

https://blog.pcisecuritystandards.org/5-questions-about-pci-dss-v4-0

https://blog.pcisecuritystandards.org/3-things-to-know-about-pci-dss-v4-0-development

https://blog.pcisecuritystandards.org/pci-dss-looking-ahead-to-version-4.0