The Payment Card Industry Security Standards Council (PCI SSC) has released an out-of-band update to its Data Security Standard (PCI DSS) to address recent vulnerabilities found in transport layer encryption.
The new version 3.1, released this month (April 2015) gives compliant organisations until 30th June 2016 to remove the use of SSL and early versions of TLS from its systems and networks.
Er….requirement 6?
My initial thought on this was “isn’t this covered by requirements 6.1 and 6.2?” Let’s recap what they say:
6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
and
6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Compliant organisations should therefore already have a process in place to identify these issues, rate them and remediate them. Why do the SSC need to issue an updated version to cover a specific set of vulnerabilities? Isn’t that venturing into the world of “security” rather than focusing on slightly more abstract, compliance goals? Are they blurring the lines?
Precedents
SSL and TLS issues often get rated as low risk. There’s many reasons for this, not least the fact that historically they have been difficult to exploit in any real-world scenario. But, just as we saw with wireless security protocol WEP a few years back, initial attacks were relatively slow and complex, yet over time the efficiency and tools available have improved to the point where SSL attacks are viable.
When I sat and reviewed the changes in v3.1, rather than just reading the articles in my newsfeed it became clear pretty quickly that the SSC are not addressing specific vulnerabilities per se, they are just acknowledging that we now know SSL and early TLS are fundamentally broken. If we look at other areas of the standard there are already precedents for these kinds of updates. In 2008 the SSC revised the PCI DSS to prohibit the use of WEP for example. It’s the same thing.
So in conclusion I don’t believe the SSC are blurring the lines between security and compliance any more than they are already were. Compliance to the PCI DSS is supposed to provide some “security” to card data (ok, compliance is supposed to provide a revenue stream to the card schemes but that’s for another time…) and the DSS could not be fulfilling its purpose if it allowed the use of outdated technologies like SSL.
If you want to see what’s change in PCI DSS v3.1 I suggest you start with the summary of changes document at https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf before moving on to the actual PCI DSS itself.
If you’d like some help understanding the implications of this new revision on your organisation’s PCI DSS compliance get in touch with us now and our consultancy team will be happy to help.
