PCI DSS Version 3.1—SSL and Early Versions of TLS Are Deemed No Longer Secure

On April 15, 2015, the Payment Card Industry Security Standards Council ("SSC") released Version 3.1 of the Payment Card Industry Data Security Standard ("PCI DSS"). PCI DSS is a set of standards that dictate how merchants and other organizations in the payment cycle are obligated to protect and safeguard cardholder data that they store, process, and/or transfer. The new version of PCI DSS provides critical guidance regarding vulnerabilities presented by the Secure Sockets Layer ("SSL") protocol and early versions of the Transport Layer Security ("TLS") protocol. It also requires the removal of SSL and early TLS versions from cardholder data environments by June 30, 2016, except in limited circumstances, and proscribes altogether new implementations of SSL and early TSL.

The SSL and early TLS protocols are widely used in numerous applications to encrypt data transmitted over the internet. Concerns with the security of these protocols began before the release of Version 3.1 of PCI DSS. For example, in April 2014, the National Institute of Standards and Technology ("NIST") released Special Publication 800-52 Revision 1, which concluded that SSL (all versions) and TLS 1.0 are no longer strong encryption methods and should not be used in connection with servers that support government-only applications. Later that same year, researchers identified a security vulnerability in SSL known as POODLE (Padding Oracle on Downgraded Legacy Encryption) that allows attackers to extract data from connections encrypted by SSL 3.0.

Due to previously identified security vulnerabilities, the SSC has determined that SSL and early TLS protocols are no longer adequate to protect cardholder data. Many of the changes provided in PCI DSS Version 3.1 are specifically designed to address these security issues. Requirement 2.2.3 of the new version is representative of the new encryption requirements:

SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Effective immediately, new implementations must not use SSL or early TLS.

POS POI terminations (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

Other changes implemented by PCI DSS Version 3.1 are relatively minor and designed primarily to clarify PCI DSS language.

Since the release of Special Publication 800-52 Revision 1, many companies have continued to rely on SSL or early TLS to encrypt sensitive information collected and transmitted over the internet. Because PCI DSS Version 3.1 now regards SSL and early TLS versions as vulnerable, however, courts and regulators alike may view these protocols as not "reasonable" for protecting certain types of sensitive information. Accordingly, in-house counsel may wish to consider the following:

• PCI DSS Version 3.1 has broad applicability—it applies to all entities that store, process, or transmit cardholder data. Thus, these changes to PCI DSS have broader applicability than commonly thought.
• IT and other security professionals should be engaged to assess the extent to which their organization uses SSL and early TLS versions. Are all instances known? Can SSL or early TLS be replaced without "breaking" the system? How significant of a risk do these implementations pose to the organization, and are effective compensating controls in place to address the vulnerabilities?
• Implementations of these protocols that are associated with payment card processing—meaning that they are a part of the cardholder data environment—should immediately be addressed to meet the compliance deadline. If a company's annual report on compliance is due after June 30, 2015, the company is required to evaluate its compliance against PCI-DSS Version 3.1. The new standards also require companies to prepare and provide a formal "Risk Mitigation and Migration Plan" in order to certify their compliance in the interim.
• Existing vendors should be asked about the extent to which they use these protocols. Where the vendor supports payment card processing, it should verify that it will meet the compliance deadline. Other vendors that process sensitive, confidential, or proprietary company data should be asked when they will convert to more secure protocols.
• Going forward, counsel may wish to specifically inquire as to a vendor's use of these protocols and contractually require the use of the more secure protocols where appropriate.

The PCI SSC has posted a short online webinar (registration required) that outlines the revisions in PCI DSS Version 3.1 and an information supplement about migrating from the legacy encryption standards.

Lawyer Contacts 

For further information, please contact your principal Firm representative or one of the lawyers listed below. General email messages may be sent using our "Contact Us" form, which can be found at www.jonesday.com.

Gregory P. Silberman
Silicon Valley
+1.650.739.3954
gpsilberman@jonesday.com

Todd S. McClelland
Atlanta
+1.404.581.8326
tmcclelland@jonesday.com

Mauricio F. Paez
New York
+1.212.326.7889
mfpaez@jonesday.com

Jay Johnson
Dallas
+1.214.969.3788
jjohnson@jonesday.com

Rachel A. Geist, an associate in the Atlanta Office, assisted in the preparation of this Alert.

Jones Day publications should not be construed as legal advice on any specific facts or circumstances. The contents are intended for general information purposes only and may not be quoted or referred to in any other publication or proceeding without the prior written consent of the Firm, to be given or withheld at our discretion. To request reprint permission for any of our publications, please use our "Contact Us" form, which can be found on our website at www.jonesday.com. The mailing of this publication is not intended to create, and receipt of it does not constitute, an attorney-client relationship. The views set forth herein are the personal views of the authors and do not necessarily reflect those of the Firm.