The PCI Security Standards Council (PCI SSC) has published a revision to the PCI Data Security Standard (PCI DSS) Version 3.1, which includes minor updates and clarifications, and addresses vulnerabilities within the Secure Sockets Layer (SSL) encryption protocol that can put payment data at risk.
The National Institute of Standards and Technology (NIST) identified SSL as not being acceptable for the protection of data due to inherent weaknesses within the protocol. Upgrading to a current, secure version of Transport Layer Security (TLS), the successor protocol to SSL, is the only known way to remediate these vulnerabilities, which have been exploited by browser attacks such as POODLE and BEAST.
“It’s critical to understand that SSL and TLS are old technologies that pre-date the advanced threats we see today. They only protect data in transit for limited paths,” explained Mark Bower, global director, product management at HP Security Voltage, in an email. “TLS is often terminated at a load balancing tier, for example, before the data then enters cloud or web applications. Given the increasing risk of ‘card not present’ data theft, merchants should also evaluate the newer technologies that are available to provide end-to-end data protection of sensitive data beyond where SSL and TLS stops.”
To address this risk, PCI DSS 3.1 updates requirements 2.2.3, 2.3 and 4.1 to remove SSL and early TLS as examples of strong cryptography. The revisions are effective immediately, but 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 30 June 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. Guidance on interim risk mitigation approaches, migration recommendations and alternative options for strong cryptographic protocols is outlined in the PCI SSC Information Supplement: Migrating from SSL and Early TLS.
Any new implementations must not use SSL or early TLS; but, point-of-sale (POS)/point-of-interaction (POI) terminals (devices such as magnetic card readers or chip card readers that enable a consumer to make a purchase) that can be verified as not being susceptible to all known exploits for SSL and early TLS may continue using these protocols as a security control after 30 June 2016.
“We are focused on providing the strongest standards and resources to help merchants and their business partners protect against the latest threats to payment data. The PCI Standards development process allows us to do this based on industry and market input,” said PCI SSC General Manager Stephen Orfei. “With PCI DSS 3.1 and supporting guidance we are arming organizations with a pragmatic, risk-based approach to addressing the vulnerabilities within the SSL protocol that can put payment data at risk.”
Additional changes to improve understanding and consistency in the standard include: clarification of language, general formatting and typographical corrections; additional guidance in introductory sections and guidance column; and updates to specific testing procedures to align testing objectives with requirements.
“The fact that the PCI Council saw fit to release an out-of-band update underscores the real threat that the recent SSL and TLS vulnerabilities pose to payment security,” said Brendan Rizzo, technical director at HP Security Voltage. “Despite the real and immediate threat, many businesses have annual budgets and resource constraints to contend with which will preclude an immediate response. The 14-month transition time should address this issue; however, companies must begin planning now in order to make sure that they do not overrun this liberal transitionary period.”
He added that if companies do not start to formalize a plan for appropriate security upgrades right away, any breach that they might incur could result in tough questions being asked and, ultimately, in significant reputational damage—even if it occurs before the PCI Council's implementation deadline.