PCI DSS 3.1: 442 Days to Remove SSL 3.0 and Other Updates

April 15, 2015 Jacob Ansari

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 Author

Jacob Ansari

Jacob Ansari is a Manager at Schellman. Jacob performs and manages PCI DSS assessments. Additionally, Jacob oversees other Payment Card Industry assessment services, namely PA-DSS and P2PE. Jacob’s career spans fifteen years of information security consulting and assessment services, including network and application security assessments, penetration testing, forensic examinations, security code review, and information security expertise in support of legal matters. Jacob has performed payment card security compliance assessments since the payment card brands operated their own standards prior to the advent of PCI DSS. Jacob speaks regularly to a variety of audiences on matters of information security, incident response, and payment card compliance strategy.

More Content by Jacob Ansari
Previous Article
Down with EMV? Yeah, You Know Me.
Down with EMV? Yeah, You Know Me.

Originally published at www.paymentsjournal.com

Next Article
Are You Ready For Some PCI DSS v3.2?
Are You Ready For Some PCI DSS v3.2?

Coming in April 2016, the PCI Security Standards Council (SSC) is releasing an incremental update to the PC...