The PCI DSS section 6.6 compliance deadline is merely 12 days away, here are some more thoughts about this regulation.

Over on the ModSecurity Blog they closely examine this portion of 6.6:

“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.”

As you can see, the goal of this section is to show that not only were vulnerabilities identified but that they were also fixed. So whether or not the vulnerabilities were identified by source code review or a scanner does not seem to be the main issue from PCI but rather was the vulnerability actually fixed??? It is the process of actually remediating the vulnerabilities that is taking entirely too long for organizations, if it happens at all. I mean, how many times does an Authorized Scanning Vendor (ASV) find the exact same vulns showing up in scan after scan? They are quickly showing the customer what/where the problems are but they just can’t fix them for a variety of reasons. [Read more... ModSecurity Blog]

VeraCode looks specifically at the semantics of the requirement:

Requirement 6.6 of the PCI-DSS becomes mandatory in June 2008 and requires all web-facing applications to either undergo a code review OR be protected by a web application firewall. There were questions on what “web-facing” means, and the Council admitted that it needed rewording. This could be interpreted as any application using HTTP as a transport mechanism, or it could mean only those applications that were Internet-facing. It sounded as if they meant the latter, but they did not say so outright which was confusing. Web services applications would also be within scope. [Read more... VeraCode]

On Search Security they drill home the high complexity of 6.6:

Section 6.6 is the most difficult and controversial part of the PCI DSS. It calls for either a review of all Web application code developed in-house, or the installation of an application layer firewall to protect all Web applications from known attacks. This puts most companies in a difficult position. [Read more... SearchSecurity]

And with a helpful twist, SearchQualitySoftware offers this advice:

…the simplest, least-expensive, and most reasonable way to satisfy PCI DSS Requirement 6.6 application code reviews is to perform automated scanning and manual testing of the application. Do them from the perspectives of both an untrusted outsider and a trusted user. [SearchQualitySoftware]

Section 6.6 is indeed unique as it brings to light the very real challenges that every connected company must face regarding web security. You can read more about section 6.6 on the PCI DSS website and in this supplement PDF.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.