PCI DSS v3.2 – What a Difference a ‘Dot’ Makes

In my continuing struggle to prove once and for all that I am the saddest bastard alive, I have spent an inordinate amount of time performing a side-by-side comparison of the PCI DSS changes from v3.1 to v3.2.

Not just the DSS itself, oh no, that would be too simple and nowhere near as pathetic, I have actually taken the Report on Compliance Reporting Templates and compared them instead! All 1,359 lines of it! You can download my initial draft here: PCI DSS v3.1 – v3.2 Mapping of Changes_v160526

Impressed? No, me neither.

Self deprecating humour aside, I actually had a very good reason for this; Only the validation of compliance really matters, the standard itself is not where the rubber meets the road, the RoC Template is. Even the ‘Summary of Changes from PCI DSS Version 3.1 to 3.2‘ cannot match the level of detail you can obtain from comparing the individual ‘Report Findings’.

I have written frequently on the inadequacy of the PCI DSS, so what is my overall opinion of the changes to v3.2? Actually, they are not that bad. I’m not saying the standard is starting to look like real security, but as far as it CAN go, it’s heading on the right direction in terms of how to both validate and report compliance.

Aside from the new requirements (which I address below), to me the biggest change was the significant reduction in the number of Report Findings for which you need to “describe how”. The consolidation of these descriptions puts the onus back on the assessor to properly validate the requirement, instead of having to spell out everything they did to do so.

However, the issue I can see with constant change from version to version is that it becomes next to impossible to even partially automate validation in centralised tool-sets (like GRC) because the RoC Template still focuses more on WHAT is written than HOW to actually perform the validation itself.

So, to the significant changes for everyone:

  1. Requirement 3.3 – Not sure why anyone would want to see any of the ‘middle 6’ digits and not the full PAN, but this requirement now helps to clarify things for those who do. Basically, you need to put the same controls around the middle six as you would the full PAN.
  2. Requirement 6.4.6 – It’s unfortunate that the SSC feels obligated to insist on validation that any changes to the CDE still conform to the PCI DSS, but it would not be have been added if organisations were actually doing it properly.
  3. Requirement 8.3 – Change from 2-Factor Authentication (2FA) to Multi-Factor Authentication (MFA), and now EVERY form of administrative access to systems must be via MFA, not just remote access (this is by far the biggest ‘blanket’ change). This has always been a best practice as far as I’m concerned, and I’m glad that the SSC has finally written this into the standard. If this is difficult for an organisation, or something they want to avoid, I have to wonder what else they don’t have in place.

…and for the poor Service Providers who rightfully bear the brunt of the changes:

  1. Requirement 3.5.1 – SPs must now provide a ‘cryptographic architecture’, but it’s not clear if it’s only to be given to the the QSA validating the SP’s compliance, or if it’s for client consumption as well. Have to assume the former.
  2. Requirement 10.8 – SPs must now detect and report on system failures. How this was not part of every organisation’s vendor due diligence process, and written into every SLA as a matter of course, is beyond me, but I know for a fact this stuff rarely is.
  3. Requirement – SPs must now perform semi-annual penetration testing on segmentation (if applicable). This should not be an issue for Cloud or VM providers IF, and ONLY if, they have configured their service correctly. However, this requirement does not cover those  SPs who have a bunch of servers on flat network and do not care about segmentation, which I would argue is far less secure.
  4. Requirement 12.4 – Pushing SPs to make protection of CHD an Executive responsibility. Unless there are some kind of penalties attached, SPs will pay limited lip-service to this and just write some kind of charter or policy. Smoke and mirrors basically, but good for the SSC for even trying.
  5. Requirement 12.11 – SPs must now perform QUARTERLY audits against several controls, which is a very good thing IF it’s done correctly. To perform this function well, SPs would need to institute some form of Internal Audit function, as well as a Governance-esque function to oversee it. Good luck with that.

So, overall, I’d say this was a pretty good change as the DSS goes, but with another 20 months until any of it is enforced, I sincerely doubt things will change for the better in the short-term.



2 thoughts on “PCI DSS v3.2 – What a Difference a ‘Dot’ Makes

  1. The reality is that for many companies, even those handling sensitive or non-public information, the unwritten policy is that “Almost any risk is acceptable until it happens. And it has to happen to us, not someone else.”

    Until some teeth get put into protecting NPI in the form of personal liability, nothing will change. Sarbanes-Oxley in the USA got senior management’s attention solely because it put personal jail time in the picture for the most senior of managers. They could no longer rely on “My people lied to me” as a defense; they had to validate personally because they were taking the risk personally. (Yeah, I know it hasn’t actually turned out that way.) SOX also got senior management attention because it mandated that material problems in controls get noted in SEC filings.

    If businesses would simply put the same rigor of controls around electronic transactions and data that they put around physical cash, this problem would go away. But that would remove much of the cost-savings of electronic transactions and if everyone isn’t going to do it, you’re put at a competitive disadvantage for “doing the right thing”.

    And that’s why PCI still has to mandate things that everyone should be doing anyway. Follow the money.

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.