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…

4 comments:

  1. Hi there,

    We're just about done on the OWASP Top 10 2007. If you want to see how it shapes up, please mail me

    vanderaj @ owasp.org

    for a later draft.

    We're likely to work with PCI on a forward looking document detailing the intent - acceptable controls - identifying the controls - and unacceptable controls.

    Andrew van der Stock
    One of the lead authors for the OWASP Top 10 2007
    Executive Director, OWASP

    ReplyDelete
  2. Very good! I very much hope that you will be involved in the PCI definition and documentation process. As I stated, OWASP does a great job in this area where PCI is desperately lacking.

    ReplyDelete
  3. Great read Steve!

    Very informative, yet humorous on what can be a dry topic to communicate.

    I enjoyed the "asphalt and a steamroller" analogy.

    Nice work

    ReplyDelete
  4. Understanding the requirements for achieving PCI DSS compliance can prove to be rather confusing. There are a number of good resources out there which can help ease the paid: GFI's free to download white paper PCI DSS Made Easy helps you understand how to become PCI DSS compliant and what the repercussions of non-compliance are. PCI Answers, as well has a very wide range of PCI related resource, which will give you all the info you need... practically :)

    ReplyDelete