Tuesday, April 15, 2008

PCI 1.1 Section 6.6

If you're one of the many practitioners waiting to see how the PCI Security Council clarifies the ambiguous 6.6 requirement, then you may wish to use this interview with Bob Russo, General Manager of the PCI Security Standards Council, as either an inkling towards an interpretation OR just more obfuscation (depending upon your point of view).

Here is the PCI requirement in question:
6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.
Russo's comments on the debate of Web Application Firewalls versus Code Reviews:
"Personally, I'd love to see everyone go through on OWASP-based source-code review, but certainly, that's not going to happen," Russo said, referring to the expensive and time-consuming process of manual code reviews. "So the application firewall is probably the best thing to do, but there needs to be some clarification around what it needs to do. That clarification is coming; that's been the biggest question."
Jeremiah Grossman sounded off on the interview as well.



Even given all of the discourse I have heard and read to date, there are many unanswered questions on this one particular point alone. No doubt the PCI Security Standards Council has realized that application layer problems are going to undermine everything else we have taught security practitioners for the last decade about the idiocy of controlling security at the network layers. And no doubt the PCI Security Standards Council understands they have a mighty hand to influence organizations to handle their custom software with the appropriate level of diligence and quality that cardholders deserve. However ...

Here are my top 7 questions concerning PCI 1.1, Requirement 6.6 that are still left unanswered:

1) Please define "web-facing applications". Does that mean HTTP/S applications? Does that mean anything directly exposed to Internet traffic? Or, does it mean any application that Al Gore created? [PCI Expert, Trey Ford, attempted to define "web-facing", but we need the offical PCI Security Council interpretation.]

2) Please define "known attacks". Known by whom? Who is keeping the authoritative list? What happens when new attacks become "known" and are added to the list? Do we have to go back and perform more analysis to check for the new attacks?

3) Please define "an organization that specializes in application security". Is that a third party or can it be a team within an organization? Can it be a team of one in a smaller organization? What is meant by "specializes"? Does that mean "took a class", "has a certificate", or is that reserved for somebody who leads the industry in the subject matter? "Application Security" as a discipline (sorry, Gary McGraw--you're right, we should call it "software security") is new. Will we have a chicken and egg problem trying to establish people as specialists in application security?

4) Does a blackbox (runtime) scanning approach constitute a "review" of custom application code? Or will only a whitebox (source code at development time) cut the mustard? Can automated review tools be used, or must it be 100% manual (human) code review? To what extent can automation be involved? Are there specific products (vendors) that are preferred or required when selecting automated tools?

5) Does the "review" imply remediation? In the case of PCI Vulnerability Scanning Procedures, some lesser vulnerabilities are allowed to exist, but vulnerabilities that the PCI Security Standards Council rate at a higher criticality must absolutely be fixed. What criticality scale must we use? Is there a taxonomy of vulnerabilities that are categorized by "must fix" criticality versus a "should fix" criticality?

6) Please define "an application layer firewall". Is that a preventative tool or can it be just a detective tool (i.e. must it be active or can it be passive, like an IDS)? What "bad things" must it detect? How tight must it be tuned? Will there be a process to pre-certify vendors, or must we invest in it now and hope that auditors will accept what we choose?

7) Why is that we are (as of today) only a mere 76 days out from when requirement 6.6 becomes mandatory and we do NOT yet have clarification? Large organizations move slowly. Complicated "web-facing applications" may take a long time to properly regression test with either option implemented (remediations found in code reviews OR web application layer firewall deployments). We have little over two months to: 1) Understand the requirement, 2) Budget accordingly, and 3) Implement on time and under budget. With PCI DSS version->next right around the corner, why wasn't this requirement held off until it could be properly flushed out in the next version?

2 comments:

lennykaufman said...

question 4 has apparently been answered. pci ssc released an update yesterday and tyler at ncircle posted part of it on the ncircle blog

http://blog.ncircle.com/

securology said...

Thanks, Lenny. But it appears that the content to which the blogger is referring has not made it back onto the PCI Security Council's website yet. We'll keep watch ...