GuestView Column: Does The PCI Security Council Understand Security?
Written by Evan SchumanGuest 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 eadams@securityinnovation.com.
-Marc
March 21st, 2008 at 8:10 am
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?
March 21st, 2008 at 8:40 am
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.
March 21st, 2008 at 1:33 pm
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.