Evan Schuman's StorefrontBacktalk

Guest Columnist David Taylor is Research Director of the PCI Alliance, Founder of the PCI Knowledge Base, and a former E-Commerce and Security analyst with Gartner.

Web application vulnerabilities make up more than 60 percent of all software vulnerabilities. They are so well known that the Open Web Application Security Project (OWASP) has published a list of these vulnerabilities. They are so easy to exploit that even the most junior hackers can find lists of popular Web application hacks and use them to break into your Web store.

The PCI 6.6 standard gives merchants a choice of two different controls to reduce the frequency and impact of these vulnerabilities. It was published in September 2006, though it doesn’t take effect until June 30, 2008. Despite widespread awareness of the problems with Web application security, the findings from over 120 hours of interviews for the PCI Knowledge Base indicate that less than 20 percent of merchants are compliant with the 6.6 standard. Why?

Having a separate deadline has lead to postponement of 6.6 compliance. Many merchants we spoke to would prefer to postpone compliance as long as possible, simply because of cost and inconvenience. Even when PCI compliance gave security managers "ammo" to drive compliance, PCI 6.6 got pushed to the side because it didn’t take effect until for nearly 2 years. Now that it’s nearly 2 years later, merchants are not thinking so much about PCI, unless their annual PCI compliance review date happens to coincide with the 6.6 effective date.

Two options are too many for some. Because the PCI 6.6 standard gives merchants and banks the option of either a code review or an application firewall, this has left many companies with the task of trying to compare the risk, cost and effectiveness of two very different types of controls. Since these controls tend to have very different strengths and weaknesses, this has led to a fair amount of internal argument of their relative merits at some organizations. On April 15, the PCI Security Standards Council issued a supplement that clarified when to use which control. But we have found many merchants, banks and service providers that are not aware of its existence. We highly recommend that all readers download and review this clarification and plan on how to meet this standard.

Application firewalls and code reviews are complimentary controls. This is a major issue among the PCI assessors, consultants and security professionals we interviewed. While everyone understands it’s important to save money these days, simply blocking applications with a content monitoring firewall is no substitute for writing secure code. If anything, these two controls should be implemented in phases, with the application firewall being used as an "interim" solution until all the applications containing credit-card data (or, better yet, all confidential data) can have a proper security code review conducted and the code can be fixed or rewritten.

Manual security code reviews are nearly impossible. While an internal, manual code review may be used to satisfy 6.6, per the April 15 standard clarification, they are very difficult to do properly. The task of assembling the necessary staff that knows the application code, the business requirements, the coding requirements of OWASP, the PCI standards and the corporate security policies for a length of time sufficient to review the code is impractical for most businesses. Automated code review tools are a superior alternative, simply because they are more manageable. Plus, they catch things that manual code reviews tend to miss.

PCI Leaders are doing both. One of the main things that differentiates leaders in our recently published "PCI Leadership Report" is that they are not only compliant with 6.6, but they are also implementing both application firewalls and automated code review tools. Some leaders have had security code reviews "baked" into their SDLC for years, but added application firewalls because they know the code reviews can miss things. Other leaders have application firewalls for some (typically purchased or older) applications while doing code reviews on their homegrown applications.

Bottom line: Use the right tool for your job. While intrusion prevention systems (IPSs) and network firewalls might seem to do similar things, these controls are not written to examine the content being communicated in the way that application firewalls and code reviews will. The April 15 clarification by the PCI SSC has a page and a half of "recommended capabilities" that I would encourage you to use as the basis for a requirements document when working with application firewall vendors. As always, if you’re involved in PCI, we’d like to interview you for the PCI Knowledge Base. If you have an opinion or question, send me an email at David.Taylor@KnowPCI.com or visit www.KnowPCI.com and click "Register" to join the PCI Knowledge Base.