Why SNAC, when you can Cocktail?

Looks like Chris Hoff is back in form, and I'm grateful. There are few people that make me think EVERY TIME they write something, and Chris is one of them. This time he weighs in on the Shimel/Stiennon discussion that I mentioned in today's TDI (here).

Read Chris' post right now. The rest of this post will make no sense until you do. Don't worry, I'll wait...

[Romantic interlude]

See what I mean? Chris is funny and he makes you think. BUT, despite the fact that his points are all well taken, he doesn't take the discussion far enough. This was no draw. It was a KO. After thinking a bit more about it, Stiennon came into the battle with a foundation of quicksand. So it wasn't that tough for Shimel to dunk him under. Not that Alan is entirely right, Chris points that out as well. But on the continuum of correctness, Alan's got him hands down. And I am always right, just ask me. :-)

Basically, there are two key points that make Richard's analysis totally flawed - both of which Chris points out. First, the decoupling of host-based and network security. I said it this AM and I'll say it again. That is just stupid. The point of gathering data is to use it and correlate it in interesting ways. Sure some of the data is unrelated, but not all of it. I'll dig into that in a bit more detail in a minute.

Second, the idea of basing decisions entirely on Netflow is ridiculous. I'm not saying that there isn't value in L2/L3 information, there is. BUT it's no panacea. As Chris says, if you are looking at stopping a DDoS (the main value of anomaly detection solutions today), Netflow is what you need. But most attacks are not DDoS anymore but happen at the upper layers of the stack. Basically you're looking at the culprit only from the waist down. I'm not saying that a lot of motivation doesn't happen below the waist, but I wouldn't say it's based on higher order thinking.

So what's the answer? As opposed to Chris' proffered new SNAC acronym (kind of gives me the munchies, I say) - I'd rather we think about a COCKTAIL. And no, that's not just because I'm an alcoholic.

Since I started this gig back in January, I've been talking about losing the religion (Day of Incite post here, Incite Redux post here), but let me take it one step further and leverage something I know a little bit about - anti-spam.

Basically, there are about 30-40 different techniques you can use to determine if a message is spam. None work all the time, in fact most are downright abysmal across the universe of undesireable messages you get. But each can detect a certain type of spam with pretty good effectiveness. The Spam Assassin folks were really the first (regardless of whatever spin the vendors want to use) to take a bunch of those techniques and correlate them into an anti-spam cocktail that was much stronger than any specific technique on its own. Of course, the vendors have greatly improved the cocktail mixture(s), and given the core concept staying power. No one relies on only a single technique anymore.

So what? We need to see the same approach applied to the network security business. Whether it's data from Netflow, an anomaly detection engine, an IDS/IPS and/or an IP address' "reputation" - we should be gathering all this information, correlating it and using that perspective to figure out if something is amiss. And no, SIM is not the answer because they don't DO ANYTHING with the information beside pump out some reports, which don't help you stop an attack.

Now before I get a bunch of comments saying I'm an idiot and you can't do that, just think about it for a second. I know there are processing limitations of doing this in real time on big pipes that anti-spam boxes don't have to deal with. I know correlating this information is fraught with peril and if you get it wrong, half of your friggin' network will be quarantined. I also know that without some kind of standard for this data interchange, this will only work in a homogenous environment and that's a problem given the best of breed mentality of most large enterprise security folk. But Big is the new small, after all.

So, I'm not saying this is easy, but I also don't think the way we are doing things is working either. I'd love to get a dialog going on why this idea is wrong. It very well could be. But I'd rather some smart folks poke holes in the idea, so all of you brainiacs out there - sharpen your battle-axes and have at it. Why am I wrong? And more importantly, what is the RIGHT ANSWER?