New PCI Rules Address SSL Vulnerabilities

On April 15, the PCI Security Standards Council published version 3.1 of the PCI Data Security Standard (DSS) to address vulnerabilities within the Secure Sockets Layer (SSL) encryption protocol that can put payment card data at risk. The SSL protocol was designed to protect data being sent across an insecure network (such as the Internet) by providing data encryption and authentication between servers and applications. SSL 3.0 was the last version to be introduced before it was replaced with Transport Layer Security (TLS) protocol version 1.0 back in 2011. TLS 1.0 was based upon SSL 3.0 and is considered only marginally more secure.

Versions 1.1 and 1.2 of TLS are significantly more secure and fix many of the vulnerabilities in SSL 3.0 and TLS 1.0. In April 2014, the National Institute of Standards and Technology (NIST) issued guidelines recommending that government agencies use TLS 1.1 and 1.2.

In late September 2014, a Google team discovered a serious SSL vulnerability called POODLE (Padding Oracle on Downgraded Legacy Encryption). POODLE enables hackers to obtain passwords and other confidential information that can be used to access a user’s private account on a website. POODLE is similar to a vulnerability called BEAST (Browser Exploit against SSL/TLS) that was discovered in 2011.

Because of the severity of the POODLE vulnerability, the NIST announced that SSL 3.0 and TLS 1.0 are no longer secure, and security experts warned that organizations should immediately stop using them. Upgrading to a current, secure version of TLS is the only known way to remediate the vulnerabilities that have been exploited by browser attacks such as POODLE and BEAST.

To address this risk, PCI DSS 3.1 removes all references to SSL and early TLS from requirements 2.2.3, 2.3 and 4.1 of the standard. Although the revisions are effective immediately, impacted requirements have a sunset date to allow for organizations with affected systems to implement the changes:

  • SSL and early TLS cannot be used as security controls to protect payment data after June 30, 2016. However, existing implementations that use SSL and/or early TLS must have a formal risk mitigation and migration plan in place prior to this date.
  • Effective immediately, new implementations must not use SSL or early TLS. New implementations are those that have no existing dependency on the use of the vulnerable protocols.
  • Point-of-sale (POS) devices that can be verified as not being susceptible to any known exploits of SSL and early TLS may continue using these protocols as a security control after June 30, 2016.

PCI 3.0 became mandatory on January 1, and brought sweeping changes to the rules organizations must follow in securing payment data. Chief among these is a new mindset that encourages a “continuous compliance” approach to data protection. We discussed some of the requirements of PCI 3.0 last year.

Although PCI 3.0 was published in 2013, many organizations are still struggling to adapt to the new requirements. Version 3.1 adds a new layer of complexity.

If you need help navigating the new PCI rules, we urge you to contact us immediately., your outsourced IT department, can help you map out a strategy for meeting PCI requirements and improving your security posture.