PCI DSS 3.1 grants merchants about 14 months to nix flawed SSL and TLS protocols, but demands they quickly provide detailed new documentation on how they plan to make the transition.

A new version of the Payment Card Industry Data Security Standard (PCI DSS) has arrived, and with it merchants must not only prepare for the imminent move away from vulnerable data encryption protocols, but also provide exacting detail on how they plan to make that transition.

PCI DSS 3.1 updates three key requirements that specifically mention SSL -- 2.2.3 (encryption for VPNs, NetBIOS, file sharing, Telnet, FTP and similar services), 2.3 (encryption for Web-based management and other non-console administrative access) and 4.1 (encryption of cardholder data during transmission over open, public networks) -- to eliminate SSL and "early TLS" as examples of strong cryptography. The SSC defines "early TLS" as TLS version 1.0 and in some cases 1.1, depending on where it's used and how it's implemented.

Effective immediately, merchants are prohibited from implementing new technology that relies on SSL and early TLS; as of June 30, 2016, merchants will no longer allowed to use SSL and early TLS in any way as standalone security controls to protect payment data.

The move was precipitated by last year's update to National Institute for Standards and Technology (NIST) Special Publication 800-52. In that document, NIST stated that only TLS 1.1 and 1.2 are secure enough for government use, signaling that SSL 2.0, SSL 3.0 and TLS 1.0 are no longer acceptable as strong encryption standards. However, many merchants still use the first version of TLS and in some cases even SSL in their cardholder data environments.

Normally updated in three-year intervals, the next version of PCI DSS hadn't been slated to arrive until fall of 2016; PCI DSS 3.0 was released in November 2013. However, the SSC quietly announced in February that the weaknesses in SSL and TLS would require an unscheduled PCI DSS release.

"At the Council we are focused on providing the strongest standards and resources to help merchants and their business partners protect against the latest threats and vulnerabilities," said PCI SSC General Manager Stephen Orfei in a statement. "As we’ve seen with POODLE and other exploits, the vulnerabilities within the SSL protocol present a risk to payment data. With PCI DSS 3.1 and supporting guidance we are arming organizations with a pragmatic, risk-based approach to addressing these threats."

Don Brooks, senior security engineer with Chicago-based compliance and security services firm Trustwave Inc., said he was glad to see that PCI 3.1 provides merchants with adequate time to phase out SSL, citing pre-release industry speculation that they might need to nix SSL and early TLS by the end of the calendar year. However, he suggested that a transition period of more than 14 months may be a double-edged sword.

"My chief concern is the long sunset time," Brooks said. "The more time they have, the less urgent it may appear to the average merchant. They need to make sure they get on top of this right away."

Troy Leach, the SSC's chief technology officer, said as is the case with any change to a PCI standard, the council worked closely with industry stakeholders to determine the best transition timeframe.

"In this case, as SSL is so widely used, we needed to figure out a way to address the seriousness of the issue and its potential risk to payment data, while also providing a reasonable timeframe for organizations to migrate their existing infrastructures," Leach said. "In the end, we decided that the June 30, 2016, date -- combined with the requirement for a risk mitigation and migration plan -- provided the best approach."

New requirement: SSL/TLS risk mitigation/migration plan

While merchants have more than a year to make the transition, PCI DSS 3.1 mandates that merchants using SSL and/or early TLS must take action immediately, specifically by creating a formal risk mitigation and migration plan.

In a statement, the SSC said it will offer guidance on interim risk mitigation approaches, migration recommendations and alternative options for strong cryptographic protocols in a forthcoming PCI information supplement document, "Migrating from SSL and Early TLS."

Within that information supplement -- a copy of the supplement was provided to SearchSecurity -- is detailed guidance and examples of information to be documented in the formal risk mitigation and migration plan.

Specifically, merchants must include descriptions of how vulnerable protocols are used; risk assessment results and risk reduction controls in place; descriptions of processes that are implemented to monitor for new vulnerabilities associated with vulnerable protocols; description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments; and an overview of an organization's migration project plan, including how it intends to meet the mandated target migration deadline of June 30, 2016.

PCI DSS 3.1 mandates that merchants detail their plans for migrating to a secure protocol, and describe their controls to reduce the risk associated with SSL/early TLS until the migration is complete.

Leach said one of the reasons PCI DSS 3.1 calls for a formal risk mitigation and migration plan 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.

"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," Leach said. "This approach provides a method for identifying the risk, demonstrating mitigation tactics and plans for migrating to a secure protocol."

While the revisions in PCI DSS 3.1 are effective immediately, Leach said any organization in the process of completing a assessment against PCI DSS 3.0 has until June 30, 2015, to complete its validation without having to provide a formal risk mitigation and migration plan for SSL and early TLS.

If I were getting this as a retailer, I'd throw up my hands and be completely fed up, but on the other hand, these are reasonable security measures.
Avivah LitanVice president and distinguished analyst, Gartner Inc.

Avivah Litan, vice president and distinguished analyst with Stamford, Conn.-based research firm Gartner Inc., said even though merchants will be required to create this new document on short notice, the information supplement's requirements are reasonable. However, she said it's indicative of how desperately the payment card industry needs a more strategic approach to security.

"If I were getting this as a retailer, I'd throw up my hands and be completely fed up, but on the other hand, these are reasonable security measures," Litan said. "Merchants have to move beyond all this spaghetti code and patching activity and be more strategic."

Specifically, Litan advocated for industry-wide end-to-end encryption for PAN data from the point of sale to the card issuer's network, as well as industry-standard tokenization by all card issuers.

"You can't expect retailers to patch leaky systems all the time, and this patch is reasonable," Litan said, "but what's not reasonable is asking retailers to compensate for a leaky payment system."

Miguel "Mike" Villegas, a PCI QSA and vice president with Houston-based consulting firm K3DES LLC, said while the new documentation will take some work, it's similar to a report on compliance (ROC), in which compensating controls are outlined and detailed, so the process will be familiar to merchants.

"I don't believe it'll be that much effort, other than writing up the documentation itself," Villegas said. "Monitoring will take a little more effort, but for the most part the merchants should be monitoring for those protocols anyway."

In the supplement, the SSC noted that merchants have multiple implementation options regarding additional cryptographic measures, several of which may not necessarily include the removal of SSL/early TLS; those include upgrading to a current, secure version of TLS, using field-level or application-level encryption to encrypt the data prior to sending over SSL/early TLS, or implementing a strongly-encrypted session like an IPsec tunnel before sending data over SSL.

Litan said while the guidelines give merchants more choices for how to mitigate the risk, they won't mean less work in doing so.

"It's still painful to change all your payment systems to encrypt at the field level or implement an encrypted tunnel," Litan said. "It's not less work, it's just offering more options."

In the supplement, the SSC reaffirmed that merchants of all sizes, even small merchants, must implement the changes in PCI DSS 3.1 in order to stave off attempts to steal payment data.

"All entity types are impacted by issues with SSL/early TLS, including small merchants," the SSC said in the supplement. "It is critical that small merchants take the necessary steps to remove SSL/early TLS from their cardholder data environments to ensure their customer data is secure."

Fortunately, according to Brooks, there are many open source and Web-based tools to help organizations assess their use of SSL.

"A lot of people don't think about SSL in all the places it exists," Brooks said, noting VPNs, email digital signatures and secure instant messaging. "The first step is that risk assessment. Find out from your vendors and software providers what their exposure is."

PCI 3.1 states that if devices using SSL and early TLS "can be verified as not being susceptible to all known exploits for SSL and early TLS," then merchants may continue using those devices after June 30, 2016.

In the information supplement, the SSC justified the less-stringent stance by explaining that the currently known vulnerabilities are generally more difficult to exploit against POS systems.

"Some of the current SSL vulnerabilities are exploited by an attacker intercepting the client/server communication and manipulating messages to the client," the SSC said in the information supplement. "The attacker’s goal is to deceive the client into sending additional data that the attacker can use to compromise the session."

Point-of-sale systems, however, often do not support multiple client-side connections, use protocols that limits the amount of data that can be exposed, and do not use Web browser software, JavaScript, or security-related session cookies; at least one characteristic is often necessary to exploit vulnerabilities in SSL and early TLS vulnerabilities.

"It is also important to remember that exploits continue to evolve and organizations must be prepared to respond to new threats," the SSC added. "All organizations using SSL and/or early TLS should plan to upgrade to a strong cryptographic protocol as soon as possible."

Litan, however, doubted whether the SSC's decision was purely risk-based, suggesting that the point-of-sale vendors' ability to rework their products before June of 2016 was also a factor.

"Look at most of the recent malware used to breach merchants like Target and Home Depot -- it resided in payment apps attached to the point of sale," Litan said. "In theory it's hard for attackers to get into POS systems because they're usually closed operating systems, but that doesn't meant they don't get into them."

Instead, she added, the SSC is likely being practical and trying to avoid a situation where large retailers are rushing to update point-of-sale systems that may not be fully tested.

Brooks said Trustwave, which assesses point-of-sale systems for compliance with the Payment Application Data Security Standard (PA-DSS), has observed "some exposure" to SSL/early TLS in POS systems, and that, like merchants, the POS providers are working with the SSC to understand their exposure and develop specific steps to address it.

"Ultimately the POS vendors are going to fix it and put out new versions of their code before the sunset deadline comes, and that may be ultimately what's driving the 14-month transition period," Brooks said. "[The SSC may] want this to drive the next version of the PA-DSS."

To that end, the SSC said a new version of the PA-DSS will be published imminently to reflect the changes in PCI DSS 3.1.

Other notable changes in PCI 3.1 include changing a reference in the introduction to from "protecting cardholder data" to "protecting account data," a clarification in Requirement 11.3.4 stating that the intent of penetration testing is to verify that all out-of-scope systems are segmented (isolated) from systems "in the CDE," and a variety of changes to clarify language around testing procedures.

Editor's note: This article was updated on April 16, 2015, with additional comments from the PCI Security Standards Council.

Join the conversation

1 comment

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

Our problem isn't the PCI support its that 50% of our customers in some cases come from IE 10 an previous which don't natively support TLS 1.1+. So if we end TLS 1 support we cannibalize our sales base.