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.

PCI deadlines for compliance seem to be catching up with merchants all the time. Standards adapt, upgrade and tighten for greater security imposing compliance on businesses. The latest compliance deadline is June 30, 2008 and the PCI blog world is buzzing about what this all actually means (there’s even a countdown clock that you can put on your website).

PCI Blog - Compliance Demystified: “What does it mean? In order to understand this you have to take my Attack Vector based Risk Management (AVRM) approach towards the intent behind this requirement. One could easily reference that the intent behind this requirement is to prevent Internet-facing web-application compromises and you would be correct, but also missing the deeper meaning and back story.

Although card-present (typically IPOS) systems account for a greater number of credit cards stolen, about half of all account compromises are a result of web-application data breaches. Of this population, about 90%+ of the data compromises are a result of the top 5-10 web-application vulnerabilities. These include, but are not limited to, SQL injection, cross-site scripting, cross-site request forgery (CSRF) and other input/output validation issues. Knowing this you can now imagine that if we could mitigate the risk of these top attacks we could reduce the population of credit card data breaches by almost half!

This standard is focused on web-applications that process transactions, which is basically right up our alley. Finding the proper (and secure) web-application for your merchant needs can be difficult and you’ll certainly want to find one that meets PCI DSS 6.6 by the end of this month.

We are pleased that E-xact has been fully PCI compliant over the last several years and remains as such.

You can find more information on the official PCI DSS website and feel free to contact us to discover ways that E-xact can alleviate your security risks when using our payment management solutions.