GuestView Column: Does The PCI Security Council Understand Security?

Written by Evan Schuman
March 21st, 2008

Guest Columnist Ed Adams is president of Security Innovation, a vendor that sells application security packages.

PCI DSS may be one of the more prescriptive and comprehensive industry standards aimed at protecting consumer credit card and personal identity information, but that does not mean it is an effective or practical standard. In fact, it still has a long way to go before its intention meets its implementation.

The PCI Security Standards Council is made up of seemingly smart folks from the credit card brands and security industry. Unfortunately, this group of misfits is saddled with a myriad of competitive conflicts of interest and, worst of all, a complete misunderstanding of how to best protect card data and consumer identity.

The PCI DSS does an adequate job of defining audit procedures around policy, network segmentation, access controls, and perimeter defenses such as firewalls. It is woefully inadequate, however, in addressing the biggest risk to cardholder data: the application layer. Sure, there are some new requirements that are slated to take effect in June for web-facing applications, but those new requirements were rushed into the standard and obviously not well thought out.

The requirement 6.6, for example, requires all web-facing applications to either undergo a code review from an organization that specializes in application security or have a web application firewall installed in front of it. What? Any decent application security consultant will tell you that the two are not mutually replaceable. Indeed, they are extraordinarily different in terms of thoroughness, cost, persistence, ease of implementation and, most importantly, what they protect against.

Many merchants, banks and services providers (those who must be PCI compliant) are struggling mightily with this requirement and utterly confused as to its how to best proceed. They face a conundrum: how to bet protect the crown jewels (cardholder data) while doing the least amount required to be compliant to the new standards. Unfortunately, the new application security requirements obfuscate that path rather than make it clearer.

Application security is a highly misunderstood area and not just by the PCI Security Council. Most organizations don’t appreciate the severity and importance of application security as part of their information and risk management strategies. Despite the slew of data breaches caused by application security vulnerabilities over the past few years, companies still don’t practice secure coding as part of their software development lifecycle.

Aberdeen Group published a study in mid-2007 that said that 70 percent of companies today are not applying secure application development techniques in their software development practices.

Seventy percent? Couple that with the fact that anywhere from 75 percent to 92 percent of all security vulnerabilities exist in the application layer and not the network or system layer (sources: Gartner Group and NIST) and we have a powder keg waiting to blow.

You’ve got the most critical data exposed (because applications have to access data in non-encrypted formats so forget about the value of database or on-the-wire encryption) in the most vulnerable location. Talk about a recipe for disaster. And what is the PCI DSS doing about it? Creating new standards that don’t make any sense and confuse merchants more than they help. Great.

The long-awaited PCI PA-DSS (Payment Application Data Security Standard) is due out later this year. I can’t wait to see how this is handled – or mangled – by the PCI Security Council. It is a golden opportunity to create some robust, practical standards for application security that can actually protect cardholder data.

Frankly, we’ve been very lucky as an industry because we’ve spent most of our time and money plugging only 8 percent to 25 percent of the security holes in our information systems. Wake up, people. Wake up, PCI Security Council. There’s an epidemic happening and it’s called application security. You want to protect your data? Look at your applications and be afraid… be very, very afraid.

Care to disagree? Send Ed Adams E-mail at


3 Comments | Read GuestView Column: Does The PCI Security Council Understand Security?

  1. Paula Rosenblum Says:

    We, at RSR have had an epiphany this week. Why in heaven’s name is it the banking commumity’s responsibility to set security standards and validate that they’ve been adhered to?

    Responsible parties for operating system security are the OS vendors, not some odd 3rd party. Banks are good at banking (at least we hope so). They’re not meant to be security-standard-bearers. Shouldn’t it be the same way with networks?

  2. Sean Says:

    While I agree that there needs to be much more done an=bout application security, bemoaning the attention paid to data storage and transportion as missing the biggest threat to customer data is misguided.
    Retailers need to take care of the basic fundamentals before they can move on to the more advanced areas of application development. Where have the largest data breaches to date occurred?
    While the jury is out on the Hannaford breach, TJX and countless other massive breaches have not occurred through applications at all. They have occurred through exploitation of security holes in the network and insecure data storage.
    That isn’t to say that application development doesn’t need to be looked at – but you have to take care of the basics first.

  3. Egog the Terrible Says:

    Not so re. the exploitation of security holes in the network — with TJX this was only how the thieves got in the front door… it was then a SQL injection and db (app) misconfiguration and app-layer vulnerability that allowed them to siphon off millions of credit card numbers over the course of months and months. I agree that the basics need to be taken care of first, but I don’t think that’s the netowrk… if you have a properly written web application, you don’t need a firewall or IDS system at all.


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.