Earlier this month we got our Attestation of Compliance (AoC) for the shiny new PCI DSS v3.1. – one of the first hosting providers to do so and offer v3.1 compliant hosting. But it does rather beg the question: what’s new in v3.1, and why is it important?

Why update?

PCI doesn’t always do non-integer version updates. It’s expected to get a new integer version every three years, and v4.0 will be with us before we know it, so why bother with 3.1? Well, to put it in simple terms, it’s all to do with stamping out SSL.

SSL Hell

SSL is insecure and had to go. It was, quite simply, putting payment data at risk. Removing SSL means PCI compliance combats the high-profile BEAST and POODLE type vulnerabilities1. This applies to all versions of SSL and even early versions of its successor protocol, TLS.

Affected Controls

2.2.3 - Encryption for VPNs, NetBIOS, file sharing, Telnet, FTP and similar services
2.3 - Encryption for web-based management and other non-console administrative access
4.1 - Encryption of cardholder data during transmission over open, public networks

The ‘No SSL’ rule will become mandatory in PCI DSS as of 30th June 2016, so the clock’s already ticking. An interesting caveat is that PoS and PoI terminals may continue to use SSL/early TLS after the 2016 deadline if they can prove they're not vulnerable to SSL-based attacks.

What else is changing in v3.1?

There are additions to both the Clarifications and Additional Guidance sections, and some more detailed requirement about PANs. A PAN is the long (12 or 14 digit) card number and is usually stored in truncated or salted hash from, meaning it’s not technically considred ‘cardholder data’. However, there’s still the opportunity for an infosec headache, so and the following controls have been tightened:

Control 3.4 grows a new sub-control: 3.4e. This one's a bit interesting, if fiddly. If a PAN is stored twice (one hashed and one truncated version), it must not be possible to use these two pieces of information to reconstruct the full PAN.

Control 4.2 adds SMS to the list of media that must be encrypted when sending PANs. By adding SMS, it brings GSM, CDMA and TDMA networks into the fold


The changes that have been made make a lot of sense from a security standpoint, and the main ‘No-SSL’ rule should already be implemented by all companies that take security seriously. We have our v3.1 AoC to prove that we practice what we preach – can your PCI-complaint hosting provider say that?

1 Why haven’t I mentioned the mega-famous Heartbleed? Well that was a problem within OpenSSL; POODLE was a flaw in SSL itself.