Delays Making Web App Weaknesses Worse

Written by Evan Schuman
May 28th, 2008

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 or visit and click "Register" to join the PCI Knowledge Base.


Comments are closed.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.