17 years, 3 months, and 7 days ago, Visa released the first version of the Payment Card Industry Data Security Standard (PCI DSS).
9 versions later, the PCI Security Standards Council (PCI SSC) is on the cusp of releasing the long-anticipated / debated version 4.0. Every organisation to whom this standard applies will be affected in some fashion, but the question of ‘How much?!’ is the only relevant one at the moment.
To answer that, we have to look back at the 17 years of the standard’s ‘evolution’. If you map every new version to the one before it, you can see not only how far it has come (or not), but just how easy it was to minimise the impact of every iteration. Including the next one, and the one after that…
Why?
Because the following statement is as true now as it was 17 years ago; ‘There is nothing in the PCI DSS that you should not be doing already’. And not just on cardholder data (CHD), but on all of your important data assets, CHD is likely only one. From the beginning, the PCI DSS was designed as a minimum set of security controls, and not one version has strayed from that design.
So while version 1.0 was only a 17-page document with roughly 180 high-level controls, and version 4 ‘Stakeholder Preview’ is over 360 pages, has roughly 250 controls and over 450 lines of the testing procedure, they are surprisingly similar. From sheer size difference, you might think that the standard has evolved significantly, but in reality, it’s about 70% the same at the control high level.
To put that another way; If you had implemented PCI properly 17 years ago, you would be 70% of the way there to this day.
So why is it so big now if it’s so similar?
Simple; Testing Procedures’. Before version 3.0, QSAs were supposed to follow the separate ‘ROC Reporting Instructions’ document for testing and validation guidance. With v3.0 these were built into the DSS itself, massively increasing its size, but NOT the level of effort.
For example; v1.0 Requirement 1.1.1 was – “A formal process for approving and testing all external network connections and changes to the firewall configuration”. Version 3.2.1 increased this to 1.1.1. a, .b, and .c and 10 lines of testing, including documentation, interviews, samples, and several ‘free-hand’ descriptions. Multiply this by a few hundred high-level controls and the current size of the DSS starts to make sense.
Though v4.0 will likely be significantly reworded and include several new requirements, it will essentially be the same. But, it will STILL be a minimum standard, so not one new requirement falls outside of a good security practice or framework. This is both good and bad news, of course, it all depends on how you have treated compliance in the past.
Word of warning; Many QSA companies used the transition of v2.0 to v3.0 as an excuse to up their prices, when in reality, if they had been doing their jobs properly previously the additional effort was minimal. No doubt QSA companies will attempt to do the same again this time around. There is more work to do, but make sure you know EXACTLY what that is before shelling out more for what amounts to a gradual evolution of the standard.
Until v4.0 is released officially we cannot provide further detail, but watch this space…
Author – David Froud