By Tim Cranny
Panoptic Security Inc.
The recent security breach at Heartland Payment Systems Inc. triggered another round of soul-searching about the Payment Card Industry (PCI) Data Security Standard (DSS). Heartland had recently been through the PCI validation process with a Qualified Security Assessor (QSA) and given a passing mark, so it isn't surprising that many people see this as a problem not just for the breached company itself, but for PCI as well.
Many commentators are asking if PCI is a sinking ship, and what should be done about it.
Unfortunately, many of these comments are based on misunderstandings about what information security really is and how it works. Perhaps PCI doesn't need to be scrapped or even dramatically overhauled - just refined.
With the right guidance, merchants can learn to manage all risks, even those not identified by PCI's formal requirements. To facilitate understanding, let's look at some questions I've been fielding regarding PCI.
The most fundamental answer to this is that you can't treat the idea of "safe" as if it's an on/off switch, with safe meaning zero risk from hackers.
There is no such thing as safe: Everything is risky, even getting out of bed in the morning, so the most you can hope for is to bring the level of risk down to a reasonable level. That is why security professionals don't talk about safety; they talk about risk management.
The same thinking is found everywhere cold reality can't be ignored. One famous example came when the "why didn't they make it safe?" question came up after the Space Shuttle Challenger disaster in January 1986.
Mary Shafer, a Lead Engineer at NASA, eventually ran out of formal bureaucratic language and said it bluntly: "Insisting on perfect safety is for people who don't have the [courage] to live in the real world."
Everything, including PCI, is a compromise. Card processing only exists because it makes business sense for merchants to offer it. We're never going to be able to say, "Your transactions can be incredibly safe at only $100 per transaction."
The goal of PCI is to make cardholder data as safe as possible in a way that is technically and economically viable.
Again, the question really should be: Does PCI make you safer? And the answer to that is yes in almost every case. It doesn't mean organizations should treat the formal requirements of PCI as the upper limit on what they should do. But, for most, moving into compliance with PCI is a dramatic step in the right direction.
The technical details of the Heartland breach are still coming to light, but in almost every case we know about there have been significant failures in following best practices.
PCI contains a broad range of best-practice measures, and when they are fully implemented, it is likely breaches can be either prevented or, at least, greatly reduced in scope. For example, many of the widely publicized, recent breaches would have been much smaller if they had simply been detected more quickly.
Having said that, PCI is not perfect. Every time there is a failure, it should trigger self-examination, as well as improvement of the PCI DSS and its implementation.
It has become clear that, in most cases involving data breaches, the weaknesses were structural and long-term. They should have been detected by a comprehensive, detailed security audit. Smaller merchants may not have the resources to detect their vulnerabilities, but large companies using sophisticated QSAs ought to be able to.
Hopefully, the PCI Security Standards Council will review the entire QSA system because the weaknesses are not just in the security requirements of the standard itself, but in the validation processes surrounding it.
This is a reasonable question because defending against hackers is the same as being in a war, and that means every move you make triggers a reaction from the "bad guys." If they know you've implemented a particular security solution, they will try something else to work around it.
That said, there really is no alternative to laying out a detailed set of best practices. This is particularly true for small merchants, who would be completely lost in the PCI maze if they were given nothing but general statements like, "Conduct a detailed risk assessment and respond accordingly." We need not toss out the specific details embedded in the standard, but rather add a general clause on risk management.
This is obviously a judgment call, but the right answer is probably to further refine it rather than replace it. Many of the complaints about PCI are not really valid, and any replacement would almost certainly end up having the same issues arise. Certainly, any dramatic change would consume a vast amount of time and effort.
Here is a wish list of three changes that would help the industry learn from data breaches and reduce the chances of them happening again.
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.
(In the case of a major processor or financial services company, a proper risk assessment would start with acknowledging the enormity of the organization's transaction volume, which would lead to a particularly comprehensive and aggressive security program, following both the letter and the spirit of the PCI DSS.)
This is how the larger, more sophisticated organizations can make themselves more "waterproof."
These steps will better protect everyone involved in the payments industry, and at the same time, reduce the uncertainty and confusion that all too many people still feel when dealing with PCI.
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 email@example.com or 801-599-3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next