PCI DSS 3.2: Why removing SSL or updating the TLS just isn’t enough

In the past two years there has been a spate of cyberattacks targeting older versions of security technology that establishes encrypted links between web servers and browsers – HTTPS – specifically on SSL 2.0 and 3.0, and TLS 1.0.

These attacks demonstrated that older SSL versions and the TLS 1.0 protocol were unfit for purpose.  The issues were not with buggy code – rather, the protocol design was inherently vulnerable. The POODLE, Heartbleed and FREAK attacks all exploited these vulnerabilities, leading to a number of high-profile breaches and significant financial losses.

When vulnerabilities are inherently designed into application, protocol or device, there is little to be done other than upgrade the version to ensure it is more robustly secure.  As a result, secure versions of TLS (currently v1.1 or higher) have already been developed, implemented and widely deployed (even before the vulnerabilities in earlier versions had been discovered.)

Let’s now turn to PCI DSS, the data security standard in place for any organization that handles payment card data.  Unsurprisingly, as soon as the SSL and TLS vulnerabilities were discovered, the PCI council issued an unscheduled update (3.1) to its standard, that states that any organization using those protocols could no longer consider itself to be using the strong cryptography required to achieve PCI DSS certification.  They set a date of June 30^th, 2016, by which PCI-compliant organizations had to update to one of the later secure versions of TLS and stop using SSL altogether.

So far, so good. But it’s important to understand that removing SSL or updating the TLS protocol on web servers and browsers isn’t enough. Systems and components supporting SSL and TLS are actually installed on many other networked devices that you may not be aware of.

Consider a wireless printer:  many have a built-in web server, and they may or may not support SSL or TLS. In any case, it may well not be re-configurable by the end user to support the new protocol.  Or, moving specifically into the world of payments processing, what about point-of-sale (POS) devices in the supermarket?  These too may incorporate web servers, and unless an IT team has checked each device deployed on their networks, they simply won’t know whether they do or don’t support the PCI-compliant TLS versions.  And there are all manner of web scraping applications and automatic testing programs that automatically connect to websites.  Certain email settings and automatic testing platforms may also include embedded TLS.

In short, the average end user – and the average organization – probably uses far more devices and applications that deploy web technology than they realize.  For an end user, this might mean that they’re not following the good online security practices that they think they are.  For a business, this might mean that they’re not complying with PCI DSS– even if they think they are.

As such, if your organization has upgraded, or is shortly going to upgrade to the new protocol versions, don’t assume that this will be a quick and straightforward process. To ensure it is done properly check your entire infrastructure to identify all devices which have in-built web servers, and ensure they are secured appropriately.

Fortunately, the PCI DSS council has recognized the potential time commitment required to carry out the necessary upgrades.  The recently released PCI DSS 3. 2 has extended the deadline for organizations to migrate to a secure version of TLS 1.1 and remove SSL to June 30^th 2018.

That said, the council is advising organizations not to wait, but to switch as soon as possible – and this is sound advice – it’s never worth taking risks with your customers’ credit card data.