PCI 2.0, our highlights of the highlights

So, as Diana tweeted earlier, the PCI Standards Council just put out a summary of (proposed) changes to the PCI-DSS and PA-DSS: the long-awaited 2.0 revision.  It’s an interesting read-through if you haven’t checked it out already.  In the interest of understanding what it means for those of us in the trenches – merchants, QSA’s, processors, etc –  here’s our take.  The “highlights of the highlights”.

But before we get into that, it’s important to point out what this document is and what it isn’t.  The purpose of the document is two-fold:

• to get proposed changes in the hands of interested parties prior to the upcoming community meeting
• pave the way for organizations to get up to speed and evaluate the changes so they are not surprised when the actual changes are published

What that means is that those of you looking for the specific language of the requirements as they will appear in the final document, you’re looking in the wrong place.  This document is intended to be a quick-hit of the upcoming changes, not an exhaustive specification.  The document does give us enough insight into what they’re up to that we can get some good intelligence about where the council is headed – which is generally a good place.  Time will tell about where they’ll go on some of the specific issues, but the evidence is in that they’ve heard community feedback and are making changes in some of the most oft-questioned requirements.

A major revision, but minor changes

Getting into the meat of it, the first thing that will likely strike you about the changes is the fact that there aren’t as many as you would expect.  Some of us (myself included) were thinking that the 2.0 revision would represent a “major revision” – much more so than the dot-revisions we’ve seen to date.  That’s not the case, at least from what we can tell so far.  Sure, there are specific updates to certain requirements (e.g. application standards), but it’s not a sweeping rewrite. The council attributes this to maturity of the standard; i.e., fewer changes are necessary because they’re already in a good state.

For what revisions there are, they’re broken into three categories:

• Additional guidance (25%)
• Clarification (58%)
• Evolving requirements (17%)

So really, it’s mostly about providing more detail for existing requirements.  Only a small percentage of the changes involve “evolving” (new) requirements.  Those are:

• Apply a risk based approach for addressing vulnerabilities. (PCI DSS 6.2)
• Payment applications should facilitate centralized logging. (PA-DSS 4.4)

And that’s it!  The rest of them are all clarifications and additional guidance in and around requirements that exist already.  Time will tell the scope of the impact of the clarifications and guidance, but right now we can speculate that the impact won’t be terribly huge.

SIGs

Secondly, we’re interested to find out how much the feedback from the special interest groups (SIGs) will ultimately be represented in the final standard – it’s not entirely clear from what we see in the document.  Take, for example, virtualization.  They’ve put a stake in the ground saying that they’ve updated the “one function per server” requirement (2.2.1) to account for a virtualized environment (thank goodness).  But that’s not the only question folks have about virtualization…  One question that comes up quite a bit is scope in a virtual environment (e.g., if one VM slice stores/processes/transmits cardholder data, is there a way to scope it so that the host OS and other slices are not in scope) – the summary says that they’ve “clarified scoping”, but will they address the virtualization questions or not?  Unknown at this point.

Or wireless.  Recall the wireless guidance and clarification that the council issued last year.   It’s difficult for QSA’s (not to mention merchants) to keep track of both the standard as well as supplemental guidance; plus the fact that if something is in a supplement rather than the actual standard, the likelihood of everyone involved in the process being versed in it goes down.  Like Diana pointed out this afternoon to SearchSecurity, her fear is that we might start to see “…splintering of PCI with other documents being issued outside of the standard.” That wouldn’t be good – recall that the original intent of the DSS as a whole was to get to unity among card brands on the requirements of their individual compliance programs.

Again, we don’t know to what degree the clarification documentation will get folded into the 2.0 standard yet since the summary doesn’t provide the full details on this point so we’ll have to wait and see.

VISA’s “Best Practices”

Another source of potential confusion (particularly to merchants) is the recent best practice documentation issued from Visa on tokenization and truncation.  Let’s face it, many merchants don’t understand the various roles of the organizations involved – so from the point of view of many of them, the PCI SSC is the same thing as Visa/Mastercard/Discover/JCB/Amex – same thing, just with a different logo.

Now, not everything can be in the final document obviously, but (despite the necessity of clarification on these topics) it’s quite possible that having the VISA guidance and not including that material in the standard might add to the confusion in the field rather than remediate it.

So, to sum up: not a huge drift revision-wise, and most of the changes are around clarification and guidance rather than new requirements.  As far as “competitive” guidance goes, we’ll have to see how it pans out in the final version but it would be good if there’s only one standard to rule them all and not a hodge-podge of rules, clarification, and loosely-related ancillary guidance (I’m looking at you HIPAA).