The Green Sheet Online Edition
October 11, 2010 • Issue 10:10:01
The coming changes to PCI
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.
Key changes to PCI
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:
1. Expand the definition of system components to include virtual components
2. Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of the cardholder data environment
3. Update requirements to allow vulnerabilities to be ranked and prioritized according to risk
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?
Keeping pace with new technology
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:
- Core and explore: This is a dubious idea and not my preferred option, but it is possible to reduce this tension by having a core standard that doesn't change quickly, but that is complemented by a more rapidly changing details list or supplement that can be updated every six or 12 months in the face of changing threats and technologies.
- Escape from the details trap: The key problem is that details change, so if you talk about them too much, you're not allowed to stop talking about them. One approach is to step back from details and move to a more complete, but less detail-oriented, approach.
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:
- Identify all assets that need to be protected. (This includes more than money and physical assets; it includes sensitive data, company reputation, legal standing and other assets.)
- Identify which threats apply to those assets. (Threats can include everything from hackers to embezzlement to accidental loss to earthquakes.)
- Decide what constitutes an acceptable level of risk for these threat-asset combinations. (Assigning a value of zero is unrealistic; you need to think in terms of managing risk down to a reasonable level, not extinguishing it completely.) By estimating the likelihood and the consequences of a particular threat, you can calculate a risk rating of that particular threat scenario.
- Address threats that have a risk rating above the level you have determined to be acceptable. This means applying additional security measures to reduce the likelihood or consequences, or both, of the underlying threat, until the risk is acceptable.
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 firstname.lastname@example.org or 801-599 3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.