Today, the PCI SSC released version 3.1 of PCI DSS. The headline objective of 3.1 is to address weaknesses in the Secure Sockets Layer (SSL) protocol. This should not be a surprise as the Internet Engineering Task Force (IETF), deprecated SSL v 3.0 in 1999. Since then, security researchers and attackers have found numerous security vulnerabilities in this protocol, including the POODLE and BEAST attacks.
The key points to the SSL update include:
- PCI DSS v 3.1 will no longer consider SSL or early versions of TLS as strong cryptography, per requirement 2.3 and 4.1 when protecting cardholder data. This applies to the associated sections of PA-DSS as well.
- Organizations with existing implementations have until June 30, 2016 to move to a secure version of TLS. Those organizations must also have a risk mitigation and transition plan.
- Effective immediately, all new implementations of these weak protocols is prohibited, but for a defined exception for specific card reader hardware that uses these protocols and not susceptible to these vulnerabilities.
This gives organizations a very generous window to address this issue, which some organizations may require to address appliances, embedded systems, or large inventories of point-of-sale (POS) devices, which may take considerable time and effort to replace. On the other hand, the standard calls for a risk mitigation plan, which will require these organizations to consider and implement additional controls to prevent attackers from exploiting the vulnerabilities in these protocols in the intervening period.
Additional updates to the standard include:
- Clarified validation procedures for service providers
- Clarified requirement 3.4 that hashed and truncated PAN could not be stored in the same environment
- Adds SMS to the mix of end-user technologies for 4.2
- Added clarification that if Web Application Firewalls are used in monitoring only for 6.6, there needs to be a mechanism for response
- Normal testing procedure consistency, grammar, etc.
Last, there was also an update in the assessment process description to clarify that a ROC, SAQ, or AOC may be submitted without all requirements being “in place”. On its face, this is straightforward. However, when you combine with statements from the Council around moving to a risk-based approach and various groups challenging the historical all or nothing approach for PCI - what we could (emphasis on could…) be seeing here is an entryway for the concept of qualified or less than perfect reports where the acquirer or card brand determines the acceptable level of risk.
Per the Council’s published lifecycle, PCI DSS 4.0 should be released in draft form in the fall of 2016.
About the AuthorMore Content by Jacob Ansari