Last Friday, April 15th, the PCI Security Standards Council published a draft of version 3.2 of the Payment Card Industry Data Security Standard (PCI DSS).
PCI DSS v.3.2 still does not has an official release date, but the draft explicitly states that PCI DSS v.3.1 is valid until October 31, 2016, after which it will be retired. All PCI DSS validations after that date must be v.3.2 or later. Additionally, notes are removed from requirements referring to an effective date of July 1, 2015, as these are now effective.
The core twelve section topics remain the same as version 3.1, but Appendix A now has two new sections, so the old Appendix A (now named A.1) is followed by sections A.2 and A.3.
- Appendix A.1: additional requirements for Shared Hosting Providers
- Appendix A.2: additional requirements for entities using SSL/early TLS
- Appendix A.3: additional requirements to incorporate the “Designated Entities Supplemental Validation” (DESV)
The last Appendix A.3 applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements. Examples of entities that this Appendix could apply to include:
- Those storing, processing, and/or transmitting large volumes of cardholder data
- Those providing aggregation points for cardholder data
- Those that have suffered significant or repeated breaches of cardholder data
When it comes to the Requirements from Section 1 to Section 12, there are three classes of change types:
- Clarification: clarifies the intent of the requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
- Additional Guidance: explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
- Evolving Requirement: changes to ensure that the standards are up to date with emerging threats and changes in the market.
The PCI Council has with this version made several changes and additions that are necessary to meet ongoing risk management activities and evolving security best practices. They also removed examples of “strong” or “secure” protocols for a number of requirements, as these may change at any time and to avoid the same difficult situation as with SSLv.3.
The highlights of the impactful changes and additions to the old version of PCI DSS:
Req. 3.3: updated requirement to clarify that any displays of PAN greater than the first six/last four digits of the PAN requires a legitimate business need. Added guidance on common masking scenarios.
Req. 3.5.1: new requirement for service providers to maintain a documented description of the cryptographic architecture. Old req. 3.5.1 – 3.5.3 are renumbered 3.5.2 – 3.5.4. Effective February 1, 2018.
Req. 6.4.6: new requirement for change control processes to include verification of PCI DSS requirements impacted by a change. Effective February 1, 2018.
Req. 8.3: expanded requirement into sub-requirements, to require multi-factor authentication for all personnel with non-console administrative access, and all personnel with remote access to the CDE.
Req. 8.3.1: new requirement addresses multi-factor authentication for all personnel with non-console administrative access to the CDE. Effective February 1, 2018.
Req. 8.3.2: new requirement addresses multi-factor authentication for all personnel with remote access to the CDE (incorporates former Req. 8.3).
Req. 10.8, 10.8.1: new requirements for service providers to detect and report on failures of critical security control systems. Old req. 10.8 is renumbered 10.9. Effective February 1, 2018.
Req. 220.127.116.11: new requirement for service providers to perform penetration testing on segmentation controls at least every six months. Effective February 1, 2018.
Req. 12.4: new requirement for service providers’ executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program. Old req. 12.4 is renumbered 12.4.1. Effective February 1, 2018.
Req. 12.11, 12.11.1: new requirements for service providers to perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures. Effective February 1, 2018.
All new requirements effective from February 1, 2018 are best practices until that date.
In my opinion, and in agreement with Enrico who addressed this in his blog post last week, the most important change is the new requirement 8.3.1 that requires multi-factor authentication for all non-console administrative access to the CDE. For many organizations, this will not be an easy task to accomplish, as they have to incorporate a new technology where it was not requested before.
The new RoC template, which will explain the testing to be performed in detail, is still not available. Without it is impossible to evaluate the impact on the required effort to conduct a PCI DSS v.3.2 assessment.