Subscribe in a reader
PCI 6.6 and Fear Mongering
Amazingly enough, every time it starts to look dour for the security business, a new regulation comes down from the heavens to give security marketers another wave of fear, uncertainty, and doubt to throw at unsuspecting customers.
Yes, the recent "clarification" of PCI requirement 6.6 (pdf) is the latest in the ongoing wave of regulations that are meant to keep security professionals on the edge of their seats in Depend undergarments. Given the number of ways you can get killed today (just ask the security marketers for a few examples), there is no shame in a blowout or two every so often.
Though this rant is not about PCI 6.6, which I think is the kind of clarification we need to provide good direction to security professionals about what good practice is. My problem is in how some security companies are using the regulation to try to get some level of urgency, so they can sell their stuff.
I'm a businessman, and I've been in the game long enough to understand how it's played. I know fear-based marketing is part of the process. Security is like insurance and unless you think you are going to die or wreck your car or have a tree fall on your house, you wouldn't buy much insurance. So the job of the insurance salesperson is to convince you that not only will those scenarios happen, but they are even likely.
From a disclosure standpoint, I carry insurance on my life, my cars, and my house -even though I understand statistics and know that it's probably a bad deal. I still buy it anyway because you never know... But security is a bit different. Most folks understand what happens when a tree falls on your house (it isn't good). Most executives can't really envision what it means when a hacker sells your customer database to the Russian Business Network.
Yet again I digress. I got a head's up about a release from Ounce Labs last week when I was about to board a plane. Thankfully they had barf bags on the plane, so I didn't make a mess. The release pretty much made me sick because it represented pretty much everything I hate about security marketing. OK, not everything - but a lot.
Let's start at the title: "Leading Security Expert Asserts that PCI Compliance is Not Achievable Without Source Code Analysis." I hope you haven't eaten yet today because you are about to be served a FUD sandwich. Yummy. The release goes on to talk about how PCI compliance is about more than a firewall and that an organization cannot be truly secure (or PCI compliant) without reviewing their source code.
Let's be very clear. An organization CANNOT be truly secure - even if they review their source code. There is no such thing as "truly secure." But it does provide a good sound bite and some good FUD for security professionals to chew on.
In this case, Ounce is both right and wrong. Since I'm trying my best to be a half-full type of guy - they are right in that source code analysis needs to be part of any security program. You won't get much disagreement about that.
What I object to is saying that you cannot be compliant without source code review. Huh? How do they know? I'm sure there are lots of QSA's out there that will provide the rubber stamp via other methods to secure applications. Like a web app firewall or other compensating controls (like database monitoring and leak prevention).
PCI Assessments (and every audit for that matter) are a totally SUBJECTIVE process. It's based on the judgement of the auditor/assessor that shows up. Sure they have guidelines and even some new quality standards, but at the end of the day, it's based upon whether the auditor buys into your security strategy and believes you can meet the spirit of the regulation.
Anyone who tells you any different is:
- Full of crap
- Trying to sell you something
- Just fell off the turnip truck
- A combination of all 3
Relative to PCI 6.6, I personally believe that the best approach is to deploy a web application firewall (or some other application layer blocking technology) to eliminate the low hanging fruit of application attacks. At the same time, high profile applications should be reviewed for security problems, first with a scanner and then a pen test to isolate logic flaws.
Finally, to complete the secure application triad, the development process should evolve to include things like source code analysis and other secure coding techniques. But in the real world, it's unlikely you get to complete the triad, so you do your best to eliminate the most obvious issues and pray that the less obvious ones don't bite you in the ass.
Ultimately this gets back to money. Since the beginning of time, it's been easier for security folks to throw boxes at the problem, then to change behavior or evolve process. And the 6.6 clarification provides a clear excuse to look for a silver bullet wrapped in a 1U enclosure with flashing lights.
Ounce is just trying to say that a WAF is not a panacea. And that they have a quarter to make and investors to keep happy and customers really should look at source code analysis. Please, pretty please, with sugar on top. I get that, and I empathize with the folks that are trying to sell "solutions," when the market wants to apply a band-aid and make the problem go away.
But leveraging FUD, conjecture, and other marketing tactics like this still annoys the crap out of me. It's disappointing, but I'm a big boy and I know it will always be part of the process. That doesn't mean I won't continue to call it out for what it is.
OK, off soapbox now.
Photo credit: "FUD Truck makes a delivery.... (NEW! Savoring our FUD)" by crmudgeon23
It is an entertaining staple of the security business to question everyone's motives. Mike, while relieving himself of an apparent overdose of self-righteousness into a metaphorical, I hope, airsickness bag, provides an excellent demonstration of the state of that art by overlooking my actual quotes, and focusing on the darker side of my motivations. Reading my quotes, without the flame-colored glasses, might help to create a clearer picture.
While I risk interjecting a couple of facts into Mike's riff, I'm going to send this anyway. Feel free to flame away and condemn me as the shill that I am undoubtedly going to painted as.
Here we go again. You cannot be compliant with PCI without analyzing your source. Period. That doesn't mean that the PCI standard is right, it dowsn't mean that you should use my product to look at your source, it means that when the standard says something like, "you won't ever store the CVC code", you cannot know whether you have ever "stored the CVC code" without looking at your applicaiton from the inside. This has nothing to do with what my company does, this is a simple fact.
Does my company build a source analysis product? Yup. In fact, I have spent almost 6 years of my life creating, funding, and working at this company, because I -believe- (got it? -believe-) that the only way to make applications more secure in important ways is to fix the way that they are written, and to help people get a look inside.
PCI has been, from my perspective, a great introduction for people to thinking more broadly about whether applications are secure. The "I like WAF's! They help with low-hanging fruit!" baffles me. I like WAF's, too, but because they can protect you while you fix your application, and they can protect against dynamic behaviors that the application in many cases cannot be written to naturally defend. A WAF, at least the ones with which I am familar, will have a hard time locating that clear text file with credit card data in it, like the one that allowed a major retailer to lose -my- credit card information when a laptop computer was stolen. On the contrary, when they looked at the applicaiton, they realized that they were doing some unexpected things with temporary files and database dumps. A great WAF will also have a hard time taking a look at the access control and authorization model, as described in PCI.
My point when I gave those quotes was not to say "If you don't analyze source code, then you are a bad person, and will immediately be attacked." It was to get people to think about what they were doing with their applications, and to take the time to look at them, with at least the same level of interest and rigor that they applied when they run a scan of their network or a virus scan of their systems.
It is easy work to look at my business card, and make a statement about my motivations. How about taking a look at PCI, and a look at its requirements, and make a judgement about whether or not you think that applications should be reviewed? If your answer is "No. No need to review." I am anxious to know how you think that PCI compliance can be achieved without it. If your answer is "You can't ask that question, because your company builds a product that makes that possible.", your answer simply doesn't help anyone.
Jack Danahy
jdanahy@ouncelabs.com
I agree with you that people love to fear-monger. It's up to us to provide that clarification and peace of mind.
On the PCI Answers blog we have a few clarifications. One very long post on the details and intent behind requirement 6.6. I like that you linked to the InformationSupplemental on 6.6 which we also clarify and highlight the key parts.
Best!