Doctor Tom Saves the Day, by Murray Barnes

Doctor Tom Saves the Day, by Murray Barnes

The PCI Council announced some highlights to the upcoming changes to PCI DSS 3.0. Here’s an article from TechTarget with comments from Bob & Troy that you might want to check out as well. The Council’s press release and available documentation does give us some insight into what they are thinking with respect to the changes, but as is with most things PCI, the devil will definitely be in the details. Based on the doc, here is a quick good/questionable list of these changes:

  • The Good:
    • Scoping is always an issue with PCI DSS, and now there is a formal requirement to maintain an inventory of system components that are in scope. Frankly, I don’t know how you could manage a PCI environment without that list, but up until this point there has not been a formal requirement for it (it’s implied in the network map and the scoping statement up front).
    • Updating the common vulnerability lists. This is probably more relevant than their new malware requirements. What would be useful would be for them to just point to the publications and not have to update the requirements in every version.
    • From the “Are You Effin Kidding Me” department, a clarification that SAD is still sensitive even if the PAN is not present.
    • Incorporating policy documents near their requirements? FABULOUS!
    • Updating the password flexibility is long overdue, but again, how will that translate?
    • From the “Stop Trying To Evade PCI DSS Controls” department, clarifications on default passwords. Why yes, they should be changed on those!
  • The Questionable (i.e., need to see how these are worded):
    • The malware component is one of those that looks good on paper, but I highly doubt it will be well received in the field. How will that get assessed? Do I just need to subscribe to a list? How hard will people laugh at me when I try to discuss the propensity for z/OS to harbor malware?
    • Physical security of payment terminals is an interesting one. I know of some folks working on things in this space, but how specific will these get? How will it complement/contradict what is already in the PTS?
    • Penetration testing. Ugh. This thing just won’t go away. Two things will be interesting here, 1) the wording, 2) how people try to get around doing proper penetration tests.
    • PCI DSS overstepping its boundary by inserting itself into BAU activities? Didn’t we agree that PCI DSS ≠ Security? This probably doesn’t belong in the standard itself and should be a support document. I mean, if Mobile or Cloud can’t find their way in here, how can this?

So there you have it, a quick review. The Council is teasing us ahead of the meeting with stuff like this, but it certainly is interesting to see what they are thinking. I will see you all in Vegas!

This post originally appeared on BrandenWilliams.com.