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.
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.
Why don’t all PCI Pen testers simply exploit their targets with an SSL vulnerability? If they penetrate the target, then the PCI test should fail.
They do. Our team reports SSL exploits pretty regularly.
Some time ago, Andrew wrote about executives who just wanted a “check-off” PCI audit. Hopefully all the 2014 breaches have mostly squashed that attitude! If a PCI pen test breaches a client’s network, e.g. using a SSL vulnerability, proving the vulnerability is exploitable, then is the client told “FAIL”? Or, is the tester more polite and merely suggests a fix? PCI DSS 3.0 often seems to soft-pedal non-compliance. 11.3.3 softly states “Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.” A hard nosed attitude on such a breach would indicate a new version 3.1 is not needed to outlaw SSL, unless many testers aren’t exploiting well known vulnerabilities.
I think it is well within the bounds to tell the company they will fail unless they fix the vulnerability and give them some time to fix it. PCI does not have to be a hammer. The goal is to get better, not punish. Places that genuinely want to improve deserve the opportunity to improve.
The 2014 breaches has made some organizations take a more diligent stand on compliance. However, there will always be businesses who do not want an honest audit which means there will always be checkbox assessors.
The hammer is going to be cyber-insurance, which will soon be void without current security certification. Every cyber-insurance company is salivating over the recent Verizon report on retail breaches that says no breached company in 2014 was fully PCI compliant. Future terms are TBD, of course, but I doubt future cyber insurance will pay-off if a breach occurs after the audit and before the fix is in place.