The 11th (and most important) reason security products don't work

Submitted by Mike Rothman on Wed, 2006-08-30 11:26.

I was interviewed and even quoted in Dark Reading's 10 Reasons Why Security Products Don't Work. I've heard that the Dark Reading folks always (as in ALWAYS) have an agenda when they do an article, so if you can give them a sound bite they are interested in, they'll use it. If not, oh well. What's 30 minutes between friends?

I can now say that it's true. I spent about 30 minutes on the phone with the reporter and we spoke about lots of things, very little of it was what I actually got quoted on. Now I didn't just fall off the turnip truck, so I know how the game works. And if I thought the article had much merit, I'd let it go. But, as opposed to Shimel (here) who liked it. I thought there were many inconsistencies (like how many of your own policies is cool before you are tuning too much?) and ultimately the article isn't helping the security practitioner do their job any better.

Why? Because they forgot the 11th reason, which actually explains many of the preceding 10 reasons. Of course, the 11th reason isn't sexy, it doesn't generate page views, and doesn't really create that much conflict. All of which makes Dark Reading thrive. So I'm not surprised they left it out of the discussion.

I know, I'm killing you with the suspense. So here goes: The REAL reason most security products don't work is because both vendors that sell them and the users that buy them FAIL TO MANAGE EXPECTATIONS. See, wasn't that easy? It's true. Most of the problems in the world today are because of unrealistic expectations, and our little corner of the universe is no different.

Let's go through their list and figure out where this is applicable:

  1. Too many false alarms - Vendors go out there with a positioning based upon zero false positives, and you know what? They are lying. So of course a customer is disappointed when the box shows up and it pretty much sounds like a air raid alarm in Beirut. Expectations are clearly not in line.

  2. Products are riddled with holes - This is software right? Do you know of any bulletproof software? Right, it doesn't exist. Of course there will be problems and patches will be required. It's how the vendor deals with the patches that matters. Any user that buys something and thinks it won't have problems needs the "Mike 2x4 treatment." You can imagine what that is.

  3. No protection against zero-day attacks - Hmm. Again, vendors selling customers a bill of goods. Never seen that before. Defense in depth is important because no product (or technique for that matter) will be effective 100% of the time. Just isn't going to happen. Again, failure to set realistic expectations.

  4. Products don't work well together - This is just naiveté on the part of the user community. Of course the products should work together and of course they never will. Why? There is a HUGE economic disincentive for standards until a market is so commoditized that it doesn't matter any more. Vendors will not to the "right" thing if there is more money in doing the wrong thing. NAC will be the latest, greatest example of that.

  5. Security tools are too complex - Well security is a complex problem and requires complex tools to really fix it. Sure we can do better, but again this is users wanting to write a check, plug something in, and have the problem go away. Unfortunately the real world doesn't work like that. Expectations once again.

  6. Users don't understand the product's capabilities - Actually the way to phrase this is that users DON'T CARE about the product's capabilities, and this is true. Users want the problem to go away. They expect that what they buy will solve their problem. They expect wrong. There is still a lot of customer integration required to make all of this stuff work. Expecting anything less is not grounded in reality.

  7. Users fail to install/deploy the product correctly - Didn't the vendor say you just set it and forget it? Again, expectations. Sales folks will tell the user anything to get them to sign on the dotted line. Vendors also expect customers to read the manual, or even walk upright. Probably misplaced optimism. A lot of the time the knuckle-draggers that actually run the box are going to get it wrong.

  8. Users do too much product tuning - If there are knobs, the users will turn them. Usually they'll screw them up. And then the vendor will get blamed. Vendors expect customers to act rationally. They won't. But this is kind of inconsistent with #7. We want the customers to implement policies for their environment, but not too many policies. Is that the message here?

  9. Users fail to update the product - Doesn't it do that automatically? We are all spoiled by patch management offerings and things like Microsoft Update. What do you mean I have to manually update anything? Having to manually update software (like I had to do with Java last night) is ridiculous. If your product needs to be updated, for God's sake, make it automatic. Make the customer TURN IT OFF, if their change control process won't allow it. And then blame them when something screws up. Speaking of blame...

  10. The Blame Game - This one is all about expectations. Users expect to get products and support from vendors to make their job easier. Vendors expect users to send a check and never to hear from them again (until it's time to sell them a new product from their new company). Neither is realistic. It needs to be a mutually beneficial relationship and both users and vendors need to expect such. Pointing the finger doesn't help, nor does flipping the bird.

You see? It isn't really sexy is it? But it's true. If users and vendors would ignore the swan song of the drunken, end of quarter, last call procurement dance, realize that everyone is a liar and ultimately they are going wake up next to Medusa the next morning (not Heidi Klum), life gets a lot easier.

Ultimately the reason most security products "don't work" is because they don't meet the mismatched expectations of both sides.