Archived Content

The following content is from an older version of this website, and may not display correctly.

The industry forum that develops card payment security standards has updated its encryption recommendations for organizations that process or store payment transaction data. The PCI Security Standards Council has issued a revised Data Security Standard (DSS), version 3.1, that will no longer support use of the Secure Sockets Layer (SSL) encryption protocol to protect payment data. The updated standard recommends the use of Transport Layer Security (TLS) to secure transactions and achieve compliance with the revised standards.

The PCI Council has updated its Data Security Standard
The PCI Council has updated its Data Security Standard – Thinkstock / Marie Fields

Version 3.1 of the PCI DSS requires updating to the current version of TLS 1.2, and will not support early versions such as TLS 1.0 or 1.1. In some cases, it advised, TLS 1.1 can be deployed depending on where it’s used and how it’s implemented. The updated DSS is effective immediately, but the PCI Council has provided a 14-month grace period to update encryption deployments.

The PCI Council advised its community of compliance assessors in February about the revision. It said the changes were necessary because the National Institute of Standards and Technology (NIST) declared the current version of SSL 3.0 “as no longer being acceptable for protection of data due to inherent weaknesses within the protocol” and because of these vulnerabilities, SSL no longer met the PCI Council’s definition of “strong cryptography” required by its data security standards.

SSL cryptography has been widely exploited in recent years, mainly through web browser-based attacks. The highly publicized Heartbleed vulnerability involved flaws in the OpenSSL encryption protocol, and recent data indicates an overwhelming percentage of web servers till remain vulnerable. Both NIST and the PCI Council are recommending TLS 1.2 instead, which was updated to address several security risks. TLS, which protects data in transit by encrypting the network tunnels it travels through, employs stronger cryptographic protocols than SSL.

PCI DSS 3.1 requires organizations involved with payment transactions shift from using SSL or early TLS by June 30, 2016, to achieve compliance with the standard. It also requires that organizations using SSL and/or early TLS before this date have a documented risk mitigation and migration plan, and prohibits – effective immediately – the use of either for any new payment transaction implementations.

“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,” said PCI SSC general manager, Stephen W. Orfei, in a press statement. “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.”

Written Agreements

Revisions to PCI DSS also include new requirements between service providers and customers that accept payments. Service providers must produce a written agreement acknowledging their responsibility to secure cardholder data if the provider “possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”

The PCI Council previously recommended the written agreement as a best practice in version 3.0 of the DSS, but the revised 3.1 version makes this a requirement as of June 30, 2015. This will have an obvious impact on companies that provide infrastructure-as-a-service, managed hosting, and colocation services where the provider’s network could access a customer’s infrastructure – if that customer processes payment-related data.

Bottom line: datacenter, hosting and cloud service providers will need to update their infrastructure for TLS encryption to maintain their PCI-compliant validations within the timeframe established by the revised DSS.