The Payment Card Industry Security Standards Council (PCI SSC) announced the latest version, 3.1, of PCI Data Security Standard (PCI DSS) today (April 15, 2015). This incremental update to v3.0, released in November, 2013, is largely a set of clarifications, with at least one notable exception impacting allowable secure communications protocols. The latter had been anticipated by a prior notification from the SSC to Qualified Security Assessors (QSAs) in a newsletter last January:
In order to address a few minor updates and clarifications and one impacting change, there will be a revision for PCI DSS and PA-DSS v3.0 in the very near future. The impacting change is related to several vulnerabilities in the SSL protocol. Because of this, no version of SSL meets PCI SSC’s definition of “strong cryptography,” and updates to the standards are needed to address this issue. [Bolding of font is mine, for emphasis.]
While SSL and early versions of TLS were considered adequately secure by prior versions of the DSS, this update serves notification that they will not be allowed after the end of June, 2016.
There is a direct backwards line-of-sight from this announcement to the documentation of the POODLE [Padding Oracle on Downgraded Legacy Encryption] exploit of SSL accounced last October by the Google Security team. As noted in that annoucement, while most enterprises will have migrated from SSL to TLS as the more secure protocol, the early versions of TLS are backwards compatible with SSL for scenarios where a fallback is necessary for practical operations.
Fortunately, the SSC is giving notice early enough that impacted organizations should have a full planning cycle before the change is required by DSS regulation. Organizations that handle payment card account data, particularly the regulated values such as PAN or card security code (i.e., Visa CVV, MasterCard CSC, etc.) and are protecting data transfers with SSL, or TLS 1.0 and 1.1, should be planning migrations to TLS 1.2. As stated in the PCI SSC "Information Supplement: Migrating from SSL and Early TLS":
The best response is to disable SSL entirely and migrate to a more modern encryption protocol, which at the time of publication is a minimum of TLS v1.1, although entities are strongly encouraged to consider TLS v1.2. Note that not all implementations of TLS v1.1 are considered secure - refer to NIST SP 800-52 rev 1 for guidance on secure TLS configurations.
If there is a chance that your organization or processes are impacted, the first step should be to identify anywhere that payment card account data is being transferred between applications or locations. Each transfer should be examined to determine if SSL, or TLS v1 or v1.1 protocols are used. Once that list is assembled, the effort required to move to the latest allowed TLS v1.2 should be sized, and the appropriate work scheduled. It's also appropriate to remain alert for announcements regarding TLS v1.3, currently in draft.
PCI DSS remains a useful collection of data protection best practices. Read Walt Conway's thoughts on "Use PCI to Protect All Confidential Data" -- register by clicking the image below.