The PCI SSC published version 3.1 of the PCI DSS on April 15th, 2015, effectively immediately.
As Anitian anticipated, the new version of the DSS states that both “SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.” The grace
period is an important consideration, because the standard additional states that “Prior to this date,
existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and
Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS.”
Anitian’s key take-aways from these changes are as follows:

  • All versions of SSL, and early versions of TLS (currently 1.0 & 1.1) are considered insecure, regardless of if they are public-facing (Internet) or internal (LAN)
  • Legacy deployments can remain through June 30th, 2016, but required documented risk mitigations
  • New deployments may only use the most recent version of TLS (currently 1.2)

This is all pretty straight forward, perhaps with the exception of the risk mitigation plan. Within the “Testing Procedures” column of the effected PCI DSS requirements (2.2.3, 2.3, 4.1) the following items are explicitly required to be included in the documented Risk Mitigation (your mitigating control) and Risk Mitigation Plan (your strategy to migrate to the latest version to TLS):

  • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment
  • Risk-assessment results and risk-reduction controls in place
  • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS
  • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments
  • Overview of migration project plan including target migration completion date no later than June 30, 2016

This is a great example of how the PCI SSC is adopting a risk-based approach to PCI, of which Anitian is a huge advocate. For additional guidance, please review the PCI SSC Information Supplement Migrating from SSL and Early TLS.


Original Post

The Payment Card Industry Security Standards Council (PCI SSC) recently released a bulletin announcing an upcoming revision PCI DSS and PA-DSS v3.0.  You can read the bulletin here . This update will address some clarifications and wording issues in these standards.

However, the most significant change is the prohibition of secure socket layer (SSL) protocol.  This ban is in response to recently disclosed vulnerabilities and cryptographic problems with the SSL protocol.  While the SSC did not specially mention the vulnerabilities in Transport Layer Security (TLS) 1.0 and 1.1 (such as Poodle), we anticipate these being included as well.  This would leave TLS 1.2 as the only approved cryptographic method for services that used SSL.  However, these restrictions do not apply to other transport encryption protocols, namely IPsec.

The publication date for the PCI DSS & PA DSS 3.1 has not been announced.  However, like all new PCI requirements, they will be phased in over time. Typically, compliant entities have a year grace period to meet the new requirement.

Nevertheless, Anitian is recommending that all organization immediately phase out the use of SSL and TLS 1.0 and 1.1 and use TLS 1.2 exclusively.  Not only will this ensure compliance with future PCI standards, but it also is best practice to protect data.  The vulnerabilities to SSL and TLS 1.0 and 1.1 are serious and being actively exploited.

The impact of moving to 1.2 should be minimal.  All modern web browsers have full support for TLS 1.2.  Only older, legacy systems may be affected.  In this case, organizations should consider additional monitoring controls, such as IDS/IPS to detect and automatically block attempts to execute cryptographic attacks such as Heartbleed or Poodle.

One area that organizations should pay close attention to is third-party hosting providers.  While the larger providers, such as Amazon and Azure, have full support for TLS 1.2, smaller providers tend to adopt these changes slower.  Virtual hosted servers may lack the appropriate libraries for TLS 1.2 and be reluctant to add them.

For organizations who wish to perform additional analysis, services using TLS can usually be set to favor TLS 1.2 over 1.0, 1.0 or SSL.  These requests can be logged and the encryption used recorded.  With some log analysis, you can determine the percentage of connections that are reverting to the deprecated versions.

Keep an eye on the SCC website and this blog for notification of the publication of PCI DSS & PA DSS 3.1.