By Tim Cranny
Panoptic Security Inc.
The PCI Security Standards Council is preparing to release updated versions of the Payment Card Industry (PCI) Data Security Standard (DSS) and the Payment Application DSS. Since these standards are the foundation for everything else in PCI, all players in the industry need to know what is happening and what the short-term and long-term implications are.
This is particularly true for those in the chain of liability, such as acquirers, ISOs and merchant level salespeople.
One bit of good news is that the changes do not represent any sort of upheaval that will generate a lot of emergency-response work. However, there are things that should concern payment professionals, in terms of both what is and what is not being changed. This article will look at the proposed changes, what they say about PCI and what should be done.
Most of the proposed changes are described as clarifications or additional guidance and shouldn't cause anyone angst. For example, the first is "Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN [primary account number]. Align language with PTS [PIN Transaction Security] Secure Reading and Exchange of Data (SRED) module."
These sorts of clarifications reduce confusion and ambiguity. Of the 12 proposed changes, nine are essentially similar.
The other three proposed changes are not so simple. Some are classified as evolving requirements and appear to be the first small steps toward genuine change at the heart of PCI.
The three proposed changes (in my own preferred order) accomplish the following:
None of these initially seem substantial, but they raise key points about what PCI is and isn't, and they hint at how PCI will evolve over time.
Let's start with the first of the three points: virtualization. More than almost any other comparable security standard, PCI is specific and prescriptive about details. Rather than taking an approach of "you have to identify problems and fix them," it lists hundreds of specific issues that have to be dealt with.
This approach has some real value (particularly when the intended user base doesn't know much about security and is hungry for detailed guidance), but it does lock everyone, including the standard creators, into an ugly race to keep up on how those details change.
If the details are the totality of PCI, the council has to ask itself: What details do we have to include now that virtualization is becoming common? What about tokenization? End-to-end encryption? Cloud computing? Mobile computing?
Technology, industry changes and the arms-race nature of security guarantee there will always be something else coming down the pike.
The council can't do a new version of the standards every six months, nor can it just ignore the new details and only talk about the old details (otherwise you would end up with a slogan along the lines of "PCI: protecting you from last year's threats, today").
This tension, between slow-enough-to-be-manageable and fast-enough-to-be-useful, is a real problem, and there aren't many real answers:
In "Rough seas for PCI," The Green Sheet, March 9, 2009, issue 09:03:01, I wrote, "The standard should keep all its specific requirements, but increase the emphasis on general risk management, particularly for service providers and larger merchants (it is mentioned in PCI, but in a low-key, incomplete way).
"The two approaches are complementary: the explicit requirements can lock in specific desirable achievements and give smaller merchants invaluable guidance, while a general risk management requirement could stop larger organizations from hiding behind a 'we did everything you asked' justification."
What is interesting is that the second and third of the evolving requirements show some real signs of PCI moving in precisely that direction.
A risk management approach
A risk management approach requires users to follow a process similar to the following:
This sort of approach, if done correctly, is largely immune to the details trap, but it puts a greater burden on those doing the risk assessment to identify and manage the details. The greatest danger (after laziness and the belief that "it won't happen to us") is failure to anticipate a given risk scenario until it's too late.
For that reason, many standards don't abandon the details; they use an approach like, "Do your own risk management, but at the very least, remember to consider the following details."
This captures the better of the two approaches and is, I believe, the most likely path that PCI will take on the way to maturity.
The upshot of this path for PCI is that it is going to become more complicated and less open to the "check the box" approach that some people use today. ISOs and others who want to handle PCI properly should start thinking now about the dangers of a short-term, quick-and-dirty approach, and consider either developing a sophisticated approach in-house or partnering with a specialist security company that can guide them to that next level of maturity when the time is right.
Taking this smarter approach to PCI is already a good idea (in terms of security and proper portfolio management) and is starting to become a necessity.
Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at cranny@panopticsecurity.com or 801-599 3454.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
