PCI v3.1 - turn off your SSL server support

Financial Fraud Action UK reports that last year credit card fraud online (CNP, or card not present fraud) rose by 10 percent to £331.5 million in the UK – but for companies in compliance with the Payment Card Industry Data Security Standard (PCI DSS), these losses were covered by the card issuing banks.

Ecommerce providers and others accepting cards had until the end of this year to fully implement the new version of PCI standards, 3.0 to stay in compliance, but this month they will have to quickly comply with a mandated updated standard – PCI 3.1. PCI DSS says this is because: “Upgrading to a current, secure version of TLS, the successor protocol to SSL (secure socket layers ), is the only known way to remediate the SSL vulnerabilities which have been most recently exploited by browser attacks including POODLE and BEAST," though Heartbleed, Shellshock have also been cited as giving cause for concern.

The plan was quietly announced 13 February this year, but clearly the PCI SSC didn't want to draw attention to the vulnerability ahead of an official response being agreed, as versions 3.0 wasn't scheduled for an update until Q3 2016.

It is understood from the IT governance blog, currently live but dated 15 April, that PCI DSS requirement 4, sub-requirement, 4.1, now mandates that strong cryptography and security protocols are used to safeguard sensitive cardholder data during transmission over open, public networks and gives as examples SSL/TLS, IPSec and SSH. It points out that some protocol implementations such as SSL version 2.0 have documented vulnerabilities and should be avoided. So for SSL/TLS to be acceptable for the encryption of cardholder data to comply with the requirement 4 of the PCI DSS, a strong cipher needs to be used, ie the server should support versions of SSL and TLS that do not have well known vulnerabilities and use cipher suites based on strong cryptography.

As a result companies accepting card payments online will have to ensure that their web servers are configured to work with TLS and turn off their SSL support. Since TLS is an evolution of SSL and both use the same certificates for security, most businesses will not need to have their trusted CA certificates reissued.

In an email to SCMagazineUK.com, Michael Aminzade Trustwave VP of global compliance and risk services, said that the biggest challenge will be payment applications as many of them use SSL to move payment transactions from the merchant to the processor. TrustWave's PCI compliance scanner was reported to have experienced issues with BEAST on certain ciphers quite some time ago.

Revisions to the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS) are needed and PCI DSS v3.1 and PA-DSS v3.1 are intended to address this issue. When published, PCI DSS v3.1 will be effective immediately, but the PCI says that impacted requirements will be future-dated to allow organisations time to implement the changes. The Council says it will provide guidance on risk mitigation approaches to be applied during the migration process.

For PA-DSS v3.1, the Council is also looking at how to address both future submissions and currently listed applications. Ahead of publication the council warned: “In the interim, as there is no known way to remediate vulnerabilities inherent in the SSL protocol, the PCI SSC urges organisations to work with your IT departments and/or partners to understand if you are using SSL and determine available options for upgrading to a strong cryptographic protocol as soon as possible.”

On 25 March a PCI SSC FAQ was issued on impending revisions to PCI DSS, PA-DSS to address SSL protocol vulnerability.

This states that: “Upgrading to a current, secure version of TLS, the successor protocol to SSL, is the only known way to remediate the SSL vulnerabilities."

All PCI DSS and PA-DSS v3.0 documentation will be affected. Although the Council says it plans to publish the revision for PCI DSS in April, with the PA-DSS revision to follow shortly after, a date has not been given.

The revised standards will be accompanied by a summary of changes document for each standard, as well as supporting guidance to help clarify the impact of these changes, including interim risk mitigation approaches, migration recommendations and alternative options for strong cryptographic protocols.