Tuesday, April 22, 2008

Finally finally PCI 6.6 clarification!

May merchants and vendors all rejoice. The PCI Standard Council has issued press release and a supplement document nicely clarifying most of the ambiguous points we were left to speculate on in section 6.6. Fortunately my analysis of Bob Russo’s SearchSecurity interview comments was WAY off. Trey Ford of WhiteHat Security and PCI extraordinaire provides his insights on the most frequently asked web application security questions. Good stuff.

As we know/knew 6.6 itself has two halves, “code review” (the act of finding/fixing for vulnerabilities) and “application firewalls” (device designed to thwart website attacks) are options that merchants may choose between. Setting aside the fact that these two options should not be perceived as competitive, rather complementary, the Council is giving merchants the choice acknowledging budget constraints. I guess that’s fair.

On the code review side, just about all forms of testing options are still on the table. Black and white box, with or without automated scanning assistance, and that kind of flexibility is a good thing. The catch is the person/firm doing the testing “must have the proper skills and experience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings.” This goes for tool use as well. That’s going to be the little bit fuzzy part since our industry is new and doesn’t really have formalized certification or education processes. So it’ll be up to the merchant to prove the case to their auditor or bank.

As for Web application firewalls, the Council also did an excellent job describing what these devices are, what they should do, how they can be deployed, and how they should be configured (a nice resource in its own right). And the list they provided is quite detailed and extensive requiring a sophisticated product, no marginal network security device with a few webappsec checks is going to cut it here. Hello WAFEC. Of course the catch here is the device must be configured to “block” the attacks, not just alert on them. That’s going to be the most challenging part in my estimation as this is not a trivial process.

While late in coming we'll take it and this is good work on the Councils behalf. In the coming weeks and months I’ll be keen on hearing the experiences of merchants when going through the compliance process. Its from those comments we’ll know where things are headed.

3 comments:

Rory McCune said...

Hi,

Do you read the clarification of "option 1" in section 6.6 as allowing alternatives to code review to achieve it?

I though it seems like they're allowing for "traditional" blackbox Web App. assessment now with the 3rd/4th options..

Jeremiah Grossman said...

Yes, you can do manual line by line source code review if you like, pure static analysis (ala Fortify / Ounce), manual black box vulnerability assessment, or use dynamic scanning tools (WebInspect / AppScan). Essentially 4 option. Of course Im partial to automated black box w/ human expertise to completely the process with Sentinel. :)

info said...

As usual, I am extremely glad the PCI council is allowing flexibility in the solutions that merchants and service providers can use to comply with PCI (notably req 6.6). This allows companies to find workable security solution that fit into their business models.

Because of this flexibility more companies will end up implementing better security measures, and at the same time continuing to allow their customers to actually do business with them (without hindering the work flow).

MBridge, LLC
www.mbridge.com