PCI: Compliance vs. Security

Last week Shift4 Corporation hosted the 2007 Real Security Summit. There were many sessions on various topics given by speakers with a wide range of expertise. Most of the information given was anywhere from interesting to scary, and all was useful. The range of topics included security, privacy, liability and compliance -- most everything you must know if you do anything with payment or privacy information. The two of the scariest topics were the link between credit card fraud and terrorist funding and the full liability to a merchant in the event of a data breach.

While all the information I would consider valuable, one quote by Heather Mark, stands out in my mind dealing with how many merchants and vendors deal with PCI: "Teaching to the Test." I’ve known what this phrase meant ever since my high school days but have never thought of it in terms of PCI. For anyone who has never heard the term, this is when an instructor does not teach the fundamentals and concepts of a subject but instead focuses on the answers to the test. This is a side-effect of the "No Child Left Behind" program -- many teachers are teaching to the test instead of teaching the subject at hand. Teaching to the test is depriving our kids from a rich education just like teaching to the test will deprive our industry from the overall goal of PCI -- security. Both programs, No Child Left Behind and PCI, are good programs with good intentions but they fail from the same problem, what I call "the compliance factor." If you are only looking at PCI as checkboxes required for compliance, then you are missing the point of PCI.

I’ve always addressed this topic as Security through compliance vs. Compliance through security. Some might think these two terms net the same end result but in reality they do not. Think of compliance as the very minimum that must be met to be considered "secure enough." With Security through compliance, the minimal was done to make the application or data center secure. With Compliance through security, your application or data center is already secure, you allocate resources to security and privacy, you have trained your personal on security and compliance is almost a side-effect of this security.

Sure, go through the PCI requirements and make sure you have every checkbox checked but then go further. Look at your data requirements. The easiest and best way to keep sensitive data out of the hands of hackers is to not store it. Encryption will fulfill some of the PCI checkboxes but if you don’t absolutely need the data, not storing it is a more secure alternative. There are people out there that want your data. What would happen to your company’s reputation in the event of a data breach? Again, think beyond checkboxes.

Yes, privacy and security can be difficult and an ever changing target but I urge everyone to look at this as more than checkboxes. Be vigilant.

Until next time…

PCI Confusion

PCI has one glaring hole that needs plugging. This hole has nothing to do with a missing firewall definition or a some skipped procedure here or there; this issue is much bigger than that. The issue is that PCI does not define the intent of the various requirements and sub-requirements. Instead of stating an intent like "we need a road connecting Las Vegas to Los Angeles," PCI starts the process by stating "acquire umpteen million tons of asphalt and a steamroller and pave in a southwest direction." This leaves much to be interpreted by the reader. It also leaves the poor merchant that must comply with the requirements even more confused. If you don’t believe me, pick any single requirement and ask ten people in the credit card industry how it impacts you as a merchant. Be it banks, processors, security experts, even VISA or MasterCard, I can all but guarantee that you’ll get ten different answers.

In the latest version of PCI requirements, version 1.1, an entire appendix was added to allow for Compensating Controls. The definition of Compensating Control starts out as: "Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk." My problem is that since the intent or the risk associated with each requirement is not defined, what is the definition of "sufficiently mitigated the associated risk?"

Obviously, some of the requirements do not need much stated about intent. Firewalls for example, anyone with any technical knowledge about the Internet knows the intent of requiring firewalls. Other requirements though are not as straight forward in determining the intent: "6.5.7 Improper error handling," I know what I believe to be improper, but the average user probably would have another belief as would a banker or merchant. A brief intent would clarify this: "Verify that all error conditions are trapped and do not leave the application in an unknown or unstable state."

The Open Web Application Security Project guidelines (OWASP), which is referred to in PCI section 6.5, is very good at defining intent with each requirement. It clearly states "here is the problem that needs to be addressed" followed by "here are some solutions that address the problem." The current PCI iteration seems more "you will do this, sit down, shut up, and oh, by the way, we have this compensating control thing if you can’t (provided it meets our undisclosed 'intent')."

I know I sound like an anti-PCI fanatic. On the contrary, I fully believe PCI is a very good thing that the industry desperately needs and it should be required. I just think the intent of each requirement and sub-requirement needs to be defined. If and when this is accomplished, I think much of the confusion in the industry will be eliminated.

That’s my humble opinion. I welcome yours…