A preview of new requirements and guidance expected later this month from the Payment Card Industry Security Standards Council was announced Thursday. The PCI DSS 3.2 version represents the first update to the standard that the Council has released since 3.1 in April 2015 and 3.0 in November of 2013.
The Council is making more incremental changes in the PCI standard due to the need to stay abreast of both hackers’ fast-changing attack vectors, and the evolving payments security technology space. The Council stated that because the standards are considered mature, they are likely to maintain 1-2 incremental updates a year, versus the previous updates of once every three years.
A brief summary of changes included in the 3.2 update from the Council are:
Two new appendices:
Appendix A2 – Additional PCI DSS Requirements for Entities using SSL/Early TLS
Appendix A3 – Designated Entities Supplemental Validation (DESV)
Support for display of PAN great than first six/last four for specific required business needs
Expand multi-factor authentication requirements (see below)
Additional requirements for Service Providers only:
Documentation of cryptographic architecture
Detect/report on failures of critical control systems
Penetration testing on segmentation controls every six months
Establish a formal PCI DSS compliance program
Confirm at least quarterly that personnel are following security policies and procedures
Multi-Factor Authentication Requirements
The council has decided to change their previous terminology from “two-factor authentication” to the “more modern term” of “multi-factor authentication” (MFA), however, the council’s definition and expectation does not change. The biggest news from the council was that they intend to expand multi-factor authentication requirements to all non-console based remote access to the cardholder data environment (CDE).
From our experience, the implementation of this control will be impactful to most organizations. With few exceptions, most organizations do not require MFA for administrative access to every system within the CDE. Many of our customers have started to include MFA for access to a bastion host. However, based on the information provided, MFA will need to be used for administrative access to every system in the CDE, including network devices, workstations and server infrastructure. We anticipate that this will take some time and investment from our customers to fully implement.
The need for multi-factor authentication was cited because of the continued and expanding attacks on password authentication, as well as the continued use of weak passwords.
Establish a formal PCI DSS compliance program
In PCI DSS 3.2, the council is starting to embed some of their “Business As Usual” controls into specific requirements for service providers. Although limited details were provided during the announcement to the QSA community, Coalfire is anticipating that this will be an area that will require some time, effort and investment for continuous monitoring and improvement. Regardless of the details, organizations should begin to evaluate their management programs and look to improve their security and compliance maturity to focus on ensuring controls are not point in time solutions but sustainable and managed processes. Many breaches these days are caused by controls that were neglected between assessments and not managed on a continuous basis.
Extending the SSL/Early TLS Requirement
The deadline for moving from SSL/early TLS 1.0 to TLS 1.2 has been extended to June 30, 2018 for all service providers, as communicated in the blog post in December 2015. Prior to June 30, 2018, existing implementations must have a formal Risk Mitigation and Migration Plan in place.
Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) protocols have held known vulnerabilities for many years. The extended dates should not be an excuse to delay, but the Council indicated that they understand that service providers also need more time to complete complex migrations.
You can read more about this issue in an earlier blog post: https://www.coalfire.com/The-Coalfire-Blog/January-2016/PCI-Council-Gives-Merchants-Reprieve-on-PCI-3-1
Sunset Dates for PCI DSS 3.1
The new 3.2 standard is expected to be released near the end of April. At that time, service providers and merchants will have six months before the 3.1 standard sunset date.
If you’ve considered starting a PCI compliance project and you know you will not meet the 3.2 standard now, it’s important to contact your QSA to make sure you begin work on the PCI 3.1 standard so it can be completed in the next few months.
PCI 3.2 Updates For ASVs
Another major change to the PCI DSS 3.1 standard was related to SSL/early TLS detection.
ASVs should be focused on detection and reporting vulnerabilities. The council was clear in stating that ASVs are not responsible for evaluation of the merchant’s remediation plan. They only need to validate that one exists.
This leaves most scan customers a little in the dark as to whether or not their remediation plans are adequate to meet the new standard. Coalfire can help you write or evaluate a remediation plan to make sure your company’s security posture is progressing and would meet the expectations of a QSA for a remediation plan.
The new update also states that detection of SSL/early TLS should result in a failed scan, with exceptions handled according to the ASV Program Guide. ASVs may issue a passing scan where the exception process is met. This can be a complex concept to understand, if additional guidance is required, please contact Coalfire for additional guidance in using SSL and early TLS in a compliant manner.
PA-DSS v3.2 Update
The PA-DSS update is much more limited than PCI 3.2 and aligns with the PCI 3.2 changes. A full PA-DSS v3.2 release is expected in May and will include an adequate transition time to complete v3.1 validations.
These updates demonstrate how the council is moving toward making more incremental updates, versus the wholesale update every three years. We’ll keep you informed here about updates as we receive information.