Friday, March 16, 2007

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…