The Payment Card Industry Data Security Standard (PCI DSS) was updated to version 3.1 on April 15, providing an incremental set of enhancements to the PCI DSS 3.0 standard that debuted in November 2013. Among the changes in the PCI DSS 3.1 update is a shift away from Secure Sockets Layer (SSL), which has been proven to be cryptographically insecure.
There is a three-year cycle between major updates of PCI DSS and, outside of that cycle, the standard can be updated to react to threats as needed.
“In this case, the Secure Sockets Layer protocol is broken, and unlike many of the vulnerabilities we see out there, there’s no patch to fix it,” Troy Leach, CTO of the PCI Security Standards Council (SSC), told eWEEK. “This combined with its widespread use makes it a critical vulnerability and one that organizations need to address immediately.”
Among the recent critical flaws found in SSL is Padding Oracle On Downgraded Legacy Encryption (POODLE), which was first reported in October 2014. The POODLE flaw is in the SSL 3.0 cryptographic protocol that first debuted in 1996. SSL 3.0 has since been superseded by Transport Layer Security (TLS) version 1.0, 1.1 and, more recently, 1.2.
“The SSL protocol has inherent weaknesses that when used to protect payment data over public or untrusted communications channels can put this data at risk,” Leach said. “The significant change in PCI DSS 3.1 is the removal of Secure Sockets Layer as an example of strong cryptography in requirements 2.2.3, 2.3 and 4.1.”
PCI DSS 3.1 requires organizations to disable all uses of SSL as soon as possible and upgrade to a secure protocol, Leach added. That said, recognizing it takes time to migrate systems, Leach noted that the standard allows for an implementation window to make changes, but requires organizations to demonstrate they have a migration plan in place and how they are addressing risks in the interim period.
“The goal is to encourage merchants and others that haven’t yet addressed the SSL and early TLS security issues to be aware of the risk and start addressing the problem sooner, rather than later,” he said. “We understand it takes time to migrate, but it’s critical that in the meantime organizations understand the potential risk to their environment so they can mitigate them as much as possible.”
Don Brooks, senior security engineer at Trustwave, is supportive of the new PCI DSS 3.1 stance on SSL. The National Institute of Standards and Technology (NIST) issued an update to its standards some time ago, noting that SSL and early versions of TLS were no longer to be considered strong encryption, he said.
“This was entirely in line with what was expected, and we strongly suggest that organizations implement the required changes as soon as possible,” Brooks told eWEEK.
Merchants are not required to be compliant with the new requirements until June 30, 2016, according to Brooks. In his view, however, that sunset date should be looked at as a “safety net” for issues that arise from legacy or third-party applications that require code changes and not as a statement on the urgency of the issue.
Tod Beardsley, Metasploit engineer manager at Rapid7, said specifically calling out organizations that seek PCI DSS certification to retire old and broken implementations of SSL and TLS is a great move.
“All too often, the compliance regimes around technology are slow to pick up new developments, so to see the PCI folks move relatively quickly on this is definitely heartening,” he said.
Beardsley added that while regulatory compliance is one way to make a case for doing the work necessary to ensure a reasonably secure profile on the Internet, it’s not the only factor in driving a security or IT organization.
“Attackers, after all, don’t first consult a list of PCI-certified organizations and blacklist them out of their attacks,” Beardsley said. “If you’re PCI-certified and insist on using a known-broken SSL implementation, you can certainly expect to get called out on it by any reasonable auditor or attacker.”
The next planned update for the PCI DSS standard is in November 2016. Leach said that if it’s necessary to update the standard sooner to protect against evolving threats, as happened with SSL, it’s possible that another revision could be released before then.
“We work closely with the payment security community on any changes we make to PCI standards, with the aim of pushing for the best security as soon as possible, while also allowing organizations to take a pragmatic, risk-based approach to protecting their data,” Leach said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.
