Rational Survivability

Firstly, I really like debating elements with Ptacek.  He’s a really, really smart guy.  Somewhat misguided, but a really, really smart guy.  I’m honored that he picks on me.  Really. 

He picked on Bejtlich the other day.  Given this association, I believe I have solved the Poincaré conjecture which has something to do with math, intractability and doughnuts.  Mmmmm.  Doughnuts.

Here, he mentions in response to my post regarding my Chicago presentation, that Cisco will crush Crossbeam.  Privately he gave me a date and time, but I told him that I wouldn’t repeat when because it might affect his Cisco stock value.

Secondly, I can only giggle about Thomas’ choice for his blog entry title ("Cisco can kill Crossbeam any time it wants…") relating how Cisco will assimilate us all…I remember that same Borg-like prediction about how Microsoft would crush the Linux movement and how no other OS would stand a chance.

I believe Thomas is still using a Mac today…

At any rate, I started with Crossbeam almost exactly a year ago.  The funny thing about crossing over from a security practitioner to working for a security vendor is that all your credibility goes out the window instantly.

I get this, it’s part of the game, but I refuse to bow to the notion that the last 15 years of my life and the credibility it has earned is erased by this singular event, so I go on assuming that my opinions count as they always have – like the paper they’re written on.

Almost always, I end up arguing with people who have either only been a vendor or an analyst and short of securing their home networks have never actually been a CISO of a company whose assets have monetary value with the word “billions” preceeding it.  I have.  I argue from that point and the beliefs that come from that perspective.  Yes, I am biased.  I was before I came to Crossbeam, too.

The one thing that makes it difficult to sort out addressing someone who is as long-winded as I am is figuring out which parts of the debate are religious, marketing, technical or dogma.

Thomas is obviously reacting to my post playing the role of Cisco’s VP of Marketing, despite his disclaimers to the opposite.  I will answer disguised as a cabaret dancer from Ohio.  I hope that’s not confusing.  If nothing I say makes sense, I’ll just ask you to rent the movie “Showgirls” and you’ll forget all about this security nonsense.

So I’ve read his retort to my post/presentation, and I’m going to respond to the things I think are worth responding to because a good chunk of his posting doesn’t really address my points – they defend Cisco’s misses.  Yet I digress…

Ptacek starts out all right, doing a good job of summarizing the sentiment of both my post and my presentation:

Chris’ argument has three salients:

• Cisco’s Self-Defending Network Architecture (the successor to SAFE) is just marketecture.
• Cisco hasn’t put its money where its mouth is on integration of security into its mainline platforms (the Cat and routers).
• Security belongs at a “service layer”, virtualized over the entire network, not as point-deployed boxes (IPS) or embedded into the infrastructure (IPS blade).

I really could just stop here because I’ve yet to find anyone (besides Thomas) who would actually disagree with any of those points, so why continue? 😉

But, he did, so I will…

1.    Is SDNA “marketecture”? Of course it is. SDNA is code for “sole-source network security from Cisco”. Sniping at SDNA’s credibility is as silly as sniping at the Cisco SAFE architecture in 2001: absolutely nobody designs networks according to these “schemes”. SDNA is a “why we did it” story that is retrofit onto Cisco’s evolving product lines to make it seem like they have strong management and a real vision.

Roger that.  SDNA = marketing.  Being opportunistic marketing-wise = vision.  Check.

But Chris’ argument isn’t about SDNA. It’s about whether enterprises should sole-source from Cisco, with around $1b in security sales, or consider vendors like Crossbeam that post sales less than 8% of that.

That’s right, my argument is that you shouldn’t sole-source your security solutions from a single vendor who claims competency in 15+ categories of security without demonstrating it, ever, except with a checkbook.

Also, just to double-check, Thomas, in Cisco math, a $200,000 Cat6500 switch with two FWSM blades is still $200,000 of “security sales,” right?   Uh-huh.  How about those “negative margin” deals…

That’s a fine argument to make, but if you’re going to build it on Cisco’s inability to run a real playbook, you can’t cherry pick Cisco’s weakest messages. SDNA may be meaningless. NAC isn’t. Even if it doesn’t work yet, it’s actionable and it’s changed the way people think about securing their network, and when Cisco buys the company that can really deliver on it for large enterprises, NAC is going to cause Crossbeam huge headaches.

Cherry-pick their weakest message?  SDNA is their message, Thomas!   DVVM and Quad-play is dependent upon this underlying message that “security is the network.”  I didn’t make this up, Cisco did.

You just contradicted yourself hugely.  In the first paragraph you said that “…absolutely nobody designs networks according to these “schemes”” but somehow that’s affected the way in which folks secure their networks!?  You’re right…they take a look at the Cisco method and realize it doesn’t work and look for other solutions.

Also, I just love the “…you just wait until Cisco buys something that actually works” sentiment!

By the way, Crossbeam doesn’t have to fear when Cisco gets NAC working (which is the most hysterical comment you’ve made,) because we can simply get a best-of-breed partners’ NAC application running on our platforms…no cash, no development, no fuss.  In fact, we are already in the process of doing that.

Furthermore, when you say NAC, you mean CNAC.  But which CNAC are you referring to?  The one that didn’t completely pan-out (CSA) or the new-and-improved Clean Access?  You know, the same Clean Access that requires ANOTHER appliance to be added to the network to function and is purdy much a Cisco-only solution…

2.    If you’re an indie network security vendor with a pulse, the idea of Cisco embedding IPS and firewalls into every Cat switch and access router puts you in a cold sweat. Is Cisco full of shit about this plan? Reasonable people will disagree, but the answer will be “no”.

See, I don’t think they’re full of shit.  I just think they’re not a security company and aren’t executing on their vision in a manner consistent with the customers they serve outside of the SMB.  The Enterprise strategy is showing cracks and they are very distracted across an immense portfolio.  They’re trying to re-group on the convergence front, but there’s pressure there, too.  All the while, security plods on.

First, the existence proof: the ISR. Large enterprises buy them by the hundreds. It’s one of Cisco’s most successful products ever. And it’s a direct threat to the branch/satellite-office market that is the primary revenue multiplier for indie perimeter security vendors —- Crossbeam’s bread and butter.

The ISR is fantastic…and if you’re a branch/satellite-office company I’d suggest it’s a very good product – still only provides limited security functionality and that’s why Cisco sells ASA’s with them.

Also, if you’re suggesting that the SMB/Branch perimeter is Crossbeam’s “bread and butter” you are completely and absolutely incorrect.  90% of our revenue comes from Large enterprise data center consolidation and service provider/MSSP/mobile operator customers.  Your definition of the “perimeter” needs work as does your understanding of what we do…again.

Cisco does more than $10b a year in Cat switching alone; by revenue, their grip on that market is comparable to Microsoft’s lock on operating systems. All it takes for Cisco to launch completely integrated network security is a credible ASA blade for the Cat6k. How far out can that be? Enterprises already buy the Firewall Switch Module.

Actually, the ASA isn’t their answer to the aging FWSM, the ACE and VSA are…and it’s got a long way to go.   By the way, who said that I’m suggesting we’re out to crush Cisco?  Beating them where they do a lousy job is a very nice living by your own math above.  How far out?  You’ll have to ask them.

The 6500 series is old in the tooth and if you read Gartner’s recent 2006 MQ for Campus LAN, their darling Cisco takes some serious knocks.  That includes the security piece.  Gasp!

And finally there’s the obvious point to be made about NAC and Cisco Security Agent, the alien larvae Cisco is trying implant into host security. NAC is a lot of bad things, but “un-integrated” is not one of them.

You’re right, but you forget that "un-integrated (?)" does not equal “functional.”  You’re also a couple of months late on this argument already…please see above.  I think your a little out-of-date on where Cisco is with CNAC…please see the report above for a very interesting look at the Gartner report.

Basically, every indie vendor has a talking point about how Cisco should just stick to the connectivity that they’re good at. This stuff all sounds good at first, but c’mon. Cisco doesn’t own connectivity because they make the best routers and switches. To claim that their routing (perimeter) and switching (internal) real estate doesn’t give them a dominant position in security is to claim that the perimeter and internal networks aren’t implicated in security. Delusional.

A dominant position or an advantage in hocking their wares because there’s some box that might be a platform to deploy it someday or today in pieces?  I’d say the latter.  Where is my bottle of Zoloft, anyway?

I agree, they haven’t done it yet, but I’ll make a statement that’s sure to get me yelled at: as soon as Cisco decides it’s ready, it can end companies like Crossbeam, Checkpoint, and SourceFire within 18 months. Isn’t not doing that, and running security as a totally seperate business unit, one of the big mistakes they made in the 90s?

Oh, OK.  They haven’t because instead of feeding the hungry, bestowing Linksys DSL routers to everyone in Kentucky or donating to stop the killing in Darfur, they’ve instead decided to give  kindly by not destroying their competitors. 

Jesus, I had no idea!  Thanks for clearing that up.   

Security is now under Jayshree’s organization which is routing/switching, and I don’t believe it has ever been a separate unit.  It should be.  That way if it doesn’t pan out they can just scrap-heap it and say that it’s a feature, not a market.

3.  Does it make sense to deploy security uniformly across the whole network, defending secretary desktops the same way you defend iSCSI servers or server-agent management consoles? No. Security should be focused on assets.

Hey, that’s a great point.  I think I made it! Please tell me how they do that?

But exactly what does this have to do with network architecture? Read Chris’ slides and it seems to mean “the way to architect your network is to hang Cisco boxes off of a couple Crossbeams in your core”.

Not quite, but your extreme-isms are starting to have me think you should write for Al-Jazeera.   How about quoting what I actually talked about…you know, like build a fast, reliable, resilient and responsive network infrastructure and overlay security as a combination of security services which provides the absolute best-of-breed security in combination where you need it, when you need it and at a price tag where the risk justifies the cost.

But that’s what you meant, right? 😉

The points Thomas pins his venom on below are from a single slide in the preso which is basically a Letterman’s top-10 spoof.  Some of them are purposely meant to incite, others are humorous, some are leverage points for the rest of the discussion that the audience and I had.

I’ll respond to some of them because many of Thomas’ objections are out of context and some are just to silly to respond to.  If you really, really want a line-by-line, I’ll do it.  Y’all just let me know 😉

2.  When’s the last time a network guy could perform a byte-level forensic trace of a Botnet C&C channel or a security guy troubleshoot a nasty BGP route-reflector distribution problem?

I don’t know. You might try asking Dug Song at Arbor, Kirby Kuehl at Cisco, or any of the Team Cymru guys. When’s the last time a security guy bought a Cisco product? Hint: it happened 5 times while you read this sentence.

Ummmm…I was referring to the average security and network practitioner in a stove-piped Enterprise or service provider, not the rest of the crew from your Saturday afternoon flag-football squad 😉

These guys, like you, are not representative of the typical folks who have to actually use the stuff we’re talking about.

You know, customers.

  3.  Managing threats and vulnerabilities is not the same as managing risk; networks don’t understand the value of the data traversing it..how can they protect it accordingly?

Cisco is not an ethernet cable. “The network” is whatever your vendor says it is. In Crossbeam’s case, “the network” is Cisco and “security” is everything else, including Checkpoint and SourceFire, both of whom sell products that Cisco has pin-compatible substitutes for.

Do any of these companies “understand the data”? No, I agree, they don’t. Is “understanding the data” important? Then let’s suspend the conversation until Cisco buys Vontu and Crossbeam partners with Vericept.

Pin-compatible?   Label-compatible, perhaps.  I think this is exactly the divergence that’s at the crux of the debate here, as the “quality” of the individual security solutions on their own (appliance or embedded) versus how they work as part of an architecture is the issue.  That’s my point, but it’s not a bullet-in-a-list sort of answer.

Also, I don’t care about Cisco buying Vontu, but what makes you think that we’re not already talking (and haven’t been for some time) to an extrusion prevention/IP Leakage vendor like Vericept?   

Crossbeam doesn’t suffer from having to wait to acquire technology and then spend 18 months butchering it to get it to work within the existing platforms (or build yet another point-solution appliance.)  We do our research in advance and when the time is right – and the customers desire it – we bring a partner’s application(s) onto the platform.

   4.  Just because two things are branded with the same name doesn’t mean they can communicate or interoperate well; just ask my wife

How’s that SourceFire/Checkpoint CPMI integration coming then? You got ISS using Snort signatures yet, or vice versa? Does anyone do app-level integration well?

Nope, and we’re not going to.  Neither will Cisco because they have no reason to if the entire network — and all the security components within — is theirs.  In fact, it’s within their interests to not have this happen.  If it did, it would just make your arguments weaker.

I’m just dinging the message and the messenger.  Our “app-level integration” is approached from a different perspective that starts first with consolidation of functions, virtualization of transport, application and policy then with the capability to flexibly pass flows through combinations of these virtual security stacks managed by the discrete parties charged with their care.  Best of breed functions that can be added to in an open platform without the need for a bunch of point solutions.

In large networks, the people responsible for FW are different than those responsible for IDS, are different than those responsible for XML, etc.   They’re still very, very vertically-stovepiped.

We don’t need to boil the ocean and we don’t.  We still have work to do on providing the overall global view of how traffic moves and is affected through these stacks, but we’re not the one blowing smoke about how this supposedly all works today.

That would be your job 😉

6.  The dirty little secret of embedding security in the “network” is that it’s the same as doing it with point-appliances…a single vendor’s set of appliances

Yes, it’s true: if Cisco succeeds in embedding security into its mainline products, you are going to be using Cisco security products. Diversity and consumer choice are valid arguments against Cisco.

But there’s one way in which using embedded security demonstrably isn’t the same as using point products: you don’t have to deploy point products to do it.

I call bullshit.  If you look at the slides in my preso, I can count over 13 different “point solutions” that aren’t routers and switches which are today relied upon to deploy this supposed “embedded” security.  The only difference between Cisco’s approach to embedded security and the appliance model is that the “appliances” are all Cisco’s.

Just because they have a Cisco label on it doesn’t make it “embedded.”

  7.  Modeling the security of the self-defending network after the human immune system and suggesting that it’s the ultimate analog is a crappy idea; people die

      Yes. What I hate about Cisco’s solutions is that you have to let a few machines on your network get infected for them to generate antigens; also, when Cisco’s security features coagulate around injuries, YouTube gets really slow.

Puff, puff, pass.  Puff, puff, pass.  You’re f-in up the rotation…man!

Please point me to a single customer in the world who has a self-defending network that functions like this.  Oh, that’s right, it’s the marketecture that you referred to in your first point and forgot that it doesn’t, actually, exist.  If YouTube being slow was the biggest problem businesses had today, you wouldn’t be employed either, T.

   8.  Security solely by acquisition does not make you a security company… just like acquiring lots of security “stuff” does not make you secure

You sure this is a good argument to make for a company that delivers 99% of its security value prop through partnerships with other companies?

Let’s ask the mean question: using product space names and market position (ie, “the #5 IPS vendor”), name some of the companies Crossbeam has turned down as partners? Cisco’s kind of picky about what it buys, you know.

It’s absolutely the right argument to make.  I guarantee you that the model of being customer-driven to take the best-in-breed security solutions from true security vendors and integrate it into a delivery architecture that is designed to do this rather than being force-fed into a retro-fit, works.  Today.

Oh, and #5 is a long way from #1, Mr. T.

"I pity the fool who mess wit Cisco.   Unnhnhnhnhh!  I want Balboa.  Sucka!"

Oh, I’d be more than glad to email you the list of 15-20 vendors over the last 6 months that we’ve said “no” to. 

You’re about to hit my threshold trip-limit on how much of our business model you claim inside knowledge to…especially since you’re batting zero at this point.

9.  Security in breadth is not the same thing as security in depth; “good enough” security is not good enough in the data center

What aspect of Cisco’s IPS is not “good enough” for the data center?

…the same one that loses to ISS, Sourcefire, and Enterasys every day.  Want to ask the same about DDoS?  I believe the answer there would be your own beloved Arbor.

People deploy Cisco’s solution usually in conjunction with other products or the same function.  I think I’ve said enough.

Did you run your original post through the Babelfish English → Cisco parser before you copy/pasted it here, or what?

10.  Securing everything, everywhere is not only unnecessary, it’s unachievable

It is if Cisco sells it at 10 points below cost in order to turn the entire network security market into a line-item feature for the Catalyst 6000.

So you admit that this is not about the efficacy of a solution but rather how much shit you have to give away for free to be called a market leader?

Actually, with the example above, Cisco now suggests you buy a completely separate 6509 into which you put all the security functions and turn it into a “security services switch” that is plugged into the “real” switching/routing fabric. 

Sound familiar?  It does to me.

I know it doesn’t sound that way, but I’m neither a fan of Cisco nor a skeptic about Chris. But his arguments don’t take Cisco seriously, and if we’re going to armchair quarterback the security industry, why be nice about that?

You’re right, it doesn’t.  I still love you, though. 

By the way, Lindstrom and I both looked at each other and laughed when we had lunch together at the show realizing that should you ever figure out we were in Chi-town and didn’t call you that you’d be grumpy.  (I had no idea you lived in Chicago so it was all Pete’s fault.)

/Hoff

All this hubbub about third party patching is enough to make one cross-eyed…(read on for the ironic analog)

I’ve written about this twice before…once last month here and the original post from my prior blog written over a year ago!  It’s a different approach (that inevitably and incorrectly gets called an IPS) to solving the patching dilemma — by not touching the host but instead performing virtualized patch emulation in real-time via the network.

Specifically I make reference to a product and service from Blue Lane technologies (the PatchPoint gateway) which so very elegantly provides a layer of protection that is a NETWORK-BASED third party patching solution.

You don’t have to touch the host — no rediculous rush to apply patches that might introduce more operational risk in the hurry to patch them than the risk imposed by the likelihood of the vulnerability being exploited…

You can deploy the virtual (third party) patch and THEN execute your rational and controlled approach towards regression testing those servers you’re about to add software to…

Rather than re-hash the obvious and get Alan Shimel designing book covers to attack my post like he did with Ross Brown from eEye (very cool, Shimmy!) you can just read the premise based upon the link above in the first sentence.

I don’t own any Blue Lane stock but I did happen to buy one of the first of their magical boxes 2 years ago and it saved my ass on many occasion.  Patch Tuesday become a non-event (when combined with the use of Skybox’s amazing risk management toolset…another post.)

Keep your mitts off my servers….

I find it oddly ironic that vendors such as Cisco maintain that the human immune system is a good model for how "network" security ought to function.  Now, I know that John Chambers’ parents are doctors, so perhaps he can’t help it…

In a recent blog entry, Richard Stiennon reviews John Chambers’ recent keynote at the Security Standards show, wherein he summarizes:

The human body is a good metaphor for the way security should be. You
hardly ever notice when your body is attacked because the majority of
attacks are warded off. It is the exception when you catch a cold or
have to go to the doctor.

It’s an unfortunate analog because PEOPLE DIE.

In my Unified Risk Management Part I whitepaper, I specifically suggested that this idea sucks:

Networks of the future are being described as being able to self-diagnose and self-prescribe antigens to cure their ills, all the while delivering applications and data transparently and securely to those who desire it.

It is clear, however, that unfortunately there are infections that humans do not recover from.  The immune system is sometimes overwhelmed by attack from invaders that adapt faster than it can.  Pathogens spread before detection and activate in an overwhelming fashion before anything can be done to turn the tide of infection.

Mutations occur that were unexpected, unforeseen and previously unknown.  The body is used against itself as the defense systems attack both attacker and healthy tissue and the patient is ultimately overcome.  These illnesses are terminal with no cure.

Potent drugs, experimental treatments and radical medical intervention may certainly extend or prolong life for a short time, but the victims still die.  Their immune systems fail. 

If this analogy is to be realistically adopted as the basis for information survivability and risk management best practices, then anything worse than a bad case of the sniffles could potentially cause networks – and businesses — to wither and die if a more reasonable and measured approach is not taken regarding what is expendable should the worst occur.  Lose a limb or lose a life?  What is more important? The autonomic system can’t make that decision.

I’m sick of these industry generalizations and fluffy conference sound bites because they’re always painted with a rosy end, downplaying the realities of the "cons" (pun intended) at the expense of the what everyone knows as the truth.

…and the truth be told, this analog is actually the PERFECT model for the Information Security paradigm because of just how spectacularly the immune systems fails.

Chris

You can forget any amount of nicey-nicey in this response.  I don’t mind debating topics, but generally, I do my homework before I post rather than generalizing or debating via analogy. 

Mitchell Ashley just got my goat with his post since he’s poking the bear with a pretty flimsy stick, all things considered.

Mitchell (and an assembled cast of thousands such as Stiennon, Neihaus, etc…) just can’t get over the fact that their perception and (mis)understanding of what makes an Enterprise/Service Provider UTM solution like the Crossbeam X-Series so phenomenally differentiated and VALUABLE to our customers is NOT about the hardware!

Talk about making me grumpy.  I’m going to sound like Rothman!

It is about the software!  But despite Mitchell’s pleadings like this:

We need some fresh thinking about UTMs or we run the risk of customers thinking the lunatics are on the grass, or something worse.

…he ignores or chooses to remain ignorant about the fact that these "fresh solutions" do exist and how they work and still he continues to eat his own picnic lunch on the lunatic lawn he so dearly hopes to avoid. 🙂

Enterprise/Provider UTM is about the ability to run the best security products on the market in an amazingly scaleable, high-performance, highly-resilient and highly-flexible manner.  It’s about being able to deploy and architecture that allows one to manage risk, improve one’s security posture and deploy on-demand security SOFTWARE solutions where needed, when needed and at a price tag where the risk justifies the cost.

I think it’s fine to be contrarian (God knows I make a career out of it) and I think it’s fine that people continue to generalize about these issues, but I continue to make it my mission to educate those same people that there are solutions that actually solve the very problems they describe in their OTS 1U appliance model hell. 

Of course vendors that base their products on 1U appliances ought to be worried in forecasting the future —  because people are sick of deploying one after another of their darn boxes (even multi-function boxes) to get the value they need…or worse yet, not get the value they need.

The largest enterprises and service providers on the planet are re-evaluating their security architectures and how and why they deploy.  The largest IT/Security project on the planet has evaluated their choices and looked for "fresh solutions" that offer what UTM promises but at levels that support the confidentiality, integrity and availability service levels that they demand.

These folks are not buying Cisco or Juniper and they’re driving vendors who would otherwise have no shot to deploy into their network to run on our boxes.  Out UTM boxes.  They’re buying Crossbeam as an architecture that allows them to deploy a well-planed infrastructure. 

The continued chest pounding about the death of Best-of-Breed and diminishing point of return for the integration of said solutions on "big hardware" are just that — chest pounding.  Why?  Because of the following:

1. Big hardware that scales and does not require forklifts simply provides a stable foundation upon which to deploy and scale your security SOFTWARE.
2. A modular architecture allows the customer to invest over time and simply add blades, add additional SOFTWARE or even upgrade their memory/processors to capitalize on compute requirements
3. Leveraging Best-In-Breed security SOFTWARE solutions allows the customer to choose what the best solution truly is, not settle for one vendor’s version of the truth like Cisco, Juniper, Fortinet or even StillSecure.

I agree that collaboration, interoperatbility and better manageability and useability are needed on ALL platforms, not just UTMs.  Furthermore, one of my biggest missions over the next year is to improve just this on our platforms:

Better appliance hardware’s not the only solution to the customer’s
problem (Sorry Chris and my other hardware friends.)

You’re right, and I never said it was.  You should probably learn about what I did say, however.

They want
solutions that bring needed value by; intelligently identifying and communicating information events,
taking action when specific security actions occur, integrating the
functions on the box for me, and make it manageable and easy. Will I
need a log aggregator software (on a separate box) to analyze the logs
of the different parts of my UTM box? Even worse, what if I have
multiple UTMs? Integrated doesn’t mean co-located businesses with a
common receptionist. Yes, it needs a shiny GUI (well, at least a GUI
any way) but the functions really need to be integrated. And what if
the customer want to expand what the box can do? Make it run other
network software. Our paradigm needs some changing.

Hello!?  Our box runs 25+ applications that our customers asked us to establish a partnership with!  Perhaps "your" paradigm needs changing, but  "my" paradigm  works just fine — in fact it’s the same one you are  promoting!  Have we achieved the level of integration we desire?  No.  We’re working very hard at it, however.

Mitchell, if you’re going to generalize and call for new, "fresh" ideas regarding UTM and basically challenge the facts I’ve put forward, at least spend the 15 minutes as Alan did to learn about my solution before you dismiss it and lump it into the boneyard with the rest of the skeletons, mkay!?

Chris

[Editor’s Note: You should also check out Alan Shimel’s blog entry regarding this meme.  I’ll respond to some of his excellent points in a seperate entry, but he beat the crap out of Mike and my Pink Floyd references!  I guess that comes with age ;)]

Uncle Mike and I today debate his notion that Best Of Breed/Best In Breed is dead — it’s actually a sing-a-long to Pink Floyd’s "The Wall."  Who knew security could be so lyrical?

By the way, in case you didn’t figure it out, that’s Mark Twain to the right, who, in his own right was once Best In Breed, is credited for the (butchered) quote above.

I think Mike missed my point — or more realistically, I didn’t do a good enough job of making it before he turned/titled the discussion into another rambling argument about the dying "perimeter." 

This really is the first time I’ve had trouble following Senor Rothman’s logic.  I think Stiennon planted a trojan via our IM chat the other night and is typing in his stead 😉

This is also probably my first really Crossbeam-centric post, but I’ve been prodded by Mike into ‘splaining/defending what we do (and how we do it) via BoB/BiB, so here goes:

Here’s my clarification:

Mike says:

It is my belief
(and remember I get paid to have opinions) that perimeter best of breed
is a dying architecture. Crossbeam even calls what you do UTM. So maybe
we are just disagreeing about semantics and words. Ultimately isn’t
this abstracted "security services" layer that you evangelize more of
what customers are interested in.

Your definition of the "perimeter" no longer interests me 😉 

If you’re talking about the SMB market and their adoption of Perimeter UTM to consolidate seperate appliances, then this argument is done. 

However, these customers that suffer from box stacking recognize that they bought the best product they could (perhaps it was more than they could afford) at the time, but what they’re looking for now is "good enough" and "reduced cost."  When you purhase a $500 box that does 8 things for $500, you get a "reduction of (device) complexity" as a side effect.  But it’s silly to suggest that these folks were really BoB/BiB targets in the first place.  That’s why BoB/BiB companies such as Check Point have small UTM boxes in this range.  Please see below. 

This abstracted "security services" layer is exactly what I evangelize, however it’s comprised of BoB/BiB solutions and functionality at it’s foundation.  As players commoditize, they move into core technology as a table stakes play, but then we have distinguished BoB/BiB technology that is truly differentiated for some period of time.  Sometimes this technology becomes a market, sometimes it becomes a feature, but either way, it’s an organic process that is still based upon BoB/BiB.

You bet that Crossbeam is a UTM player.  In fact, despite what Fortinet lies (yes, lies) about in their press releases, Crossbeam continues to be the leader in the high-end ($50K+) UTM market.  However, as I’ve said eleventy-billion times, there is an enormous difference between the small SMB $500 Perimeter UTM solutions and our Enterprise and Provider-Class UTM solutions.

I’m not going to re-hash this here again.  You’ll need to reference this post to get the big picture.  Suffice it to say, we’ve been in business for 6 years with revenue doubling YoY doing the thing that is now called UTM — and we do it in a way that nobody else can because it’s damned hard to do right.

I admit/concede/agree that Single-function BoB/BiB solutions that are intended by their creators to be deployed in a singular fashion on their own appliance stacked next to or on top of another BoB/BiB solution is a dying proposition.   This is why you see vendors — even Cisco — combining functionality into a consolidated solution to reduce security sprawl.   That won’t stop them from building BoB/BiB compartmentalized solutions, however.  This is what vendors do.

Typically integrators get to make money from cobbling it all together.  Savvy resellers and integrators don’t have to cobble if they use an architecture that aligns all of these solutions into and onto a platform architecture that is as much a competent networking component as it is a BoB/BiB security layer.  That would be Crossbeam.

That does NOT, however, mean that BoB/BiB itself is dead (at the perimeter or otherwise) because just like IBM buying ISS (the market leader in BoB/BiB IPS,)  this will result in the inevitable integration via service of ISS’ components into a  more robust suite of security services complemented by infrastructure.   

However, when a single vendor does this, you only get that single vendor’s version of the truth and so I assume this is what Mike means when he says a customer has to "settle" for BoB/BiB.

The dirty little secret is that customers are forcing BoB/BiB vendors to work together — or more specifically work together on a platform using an architecture that provides for this integration in an amazingly scaleable, highly-available, and high performance way.

Here are some pertinent examples:

• Next Generation Networks de-couple the transport from the service layers.  You have plumbing and intelligence.  The plumbing is dumb, fast and reliable whilst the service layer providers the value in things such as content delivery, security, etc.

  In this model, the plumbing is made up of the BoB/BiB networking components and the intelligence layer is comprised of BoB/BiB service delivery components.

  NGN’s are driving the re-architecture of some of the biggest networks on the planet — in fact THE largest IT project in the world, BT’s 21CN, calls for this architecture where BoB/BiB components have been selected to be consolidated in a single platform in order to deliver BoB/BiB security as a service layer across the entire network — end to end.  They don’t expect switches or routers to be able to deliver this security — they trust in the fact that BoB/BiB players will — in one platform. 

  By the way, that includes that little thing called "the perimeter."  I’ve said it once and I’ll say it again:

  The perimeter is not going away.  In fact, it’s multiplying.  However, the diameter is collapsing.

Applying dynamic, on-demand and highly-differentiated combinations of BoB/BiB security services at different areas of the network from a single set of carrier/enterprise -class security switches allows you to secure these micro-perimeters as you best see fit.

You don’t "settle" for anything.  The customer has a choice of which BoB/BiB security software he/she wishes to run and like a "Security Service Oriented Architecture" and dynamically and at will apply these choices where, when and how needed.  If vendor A changes strategy or goes out of business, you can add/switch vendor B.

• Virtualization in both the data center and the "network" is dependent upon BoB/BiB to deliver the functionality required for distributed computing.  Just as servers, storage, networking and processing is virtualized, security is too.

  Since many companies are utilizing VLANs to being their virtualization efforts and beginning to abstract the network in VRF terms @ Layer 2/Layer 3, they have two choices: use the still immature security technology present in clumps in their routers/switches (and hold your breath for SNF — which is really just a product like ours connected to a switch — don’t believe me?  I’ll post one of Richard Stiennon’s slides describing SNF) or choose an architecture that delivers EXACTLY the level of security you need at its most potent level as a combined virtualized service layer across the network using BoB/BiB.

• Consolidation and Acquisitions will come and go, but you’ll notice that we are able to do things that nobody else can in the BoB/BiB market.  Take this VARBusiness story for example — just published today — in which an established BoB/BiB Firewall player (Check Point) is combined with a BoB/BiB IPS player (SourceFire) on our platform doing something the two companies could not do otherwise.  By the way, and most importantly, the customer can choose from 15+ other BoB/BiB security applications to combine, also, such as ISS, WebSense, Trend Micro, Forum Systems, Imperva, Dragon, etc.
• Customers (in our world that’s large enterprise and service providers/carriers/mobile operators) are no longer settling for "good enough" and they’re also not settling for having BoB/BiB providers suggest that they need to tear into their networks to integrate their individual wares.  Here’s an interesting one for you:

  While many of them utilize things like FWSM modules in their 6500 series Cisco switches for firewall or even combine Juniper’s ISG2000 IPS devices with the 6500’s to provide FW and IPS together (and both of those are still considered BoB/BiB solutions by the way,) they tell the BoB/BiB purveyors of Web Services/SOA/XML security, gateway A/V, Content Filtering, Web Application and Database security solutions that while they will most definitely want their products, they won’t deploy them unless they run on the big, white, box.  That would be these.

To wrap up, Mike ends with:

To get back to my another brick
analogy, you could say that every new best of breed application you add
to your box is another brick that makes your box more interesting to
customers. No?

Yes, but how does that mean BoB/BiB is dead again?

In the spirit of the Who, here’s an appropriate selection from the Quadrophenia song "I’ve had enough":

You were under the impression
That when you were walking forward
You’d end up further onward
But things ain’t quite that simple.

You got altered information
You were told to not take chances
You missed out on new dances
Now you’re losing all your dimples.

Yours wordily, Mr. Dimples…

Chris

Our online MobCast featuring Martin McKeay, Mike Rothman, Richard Stiennon, Alan Shimel and I regarding our on-going debate regarding NAC and SNF was almost a DNF when we discovered that SkypeCast sucked beyond compare (we jumped to "regular skype") and then Martin’s recording software decided to dedicate its compute cycles to the SETI project rather than record us.

Many thanks to the esteemed Mr. Stiennon who was luckily committing a felony by recording us all without disclosure. 😉  See, there’s a good side to all that government training. 😉

At any rate, we had a lively debate that needed to go on for about an hour more because (surprise!) we didn’t actually resolve anything — other than the two analysts were late to the call (surprise #2) and the two vendors were loud and obnoxious (not really a surprise.)

It was a great session that got passionately elevated across multiple elements of the discussion.  What we really recognized was that the definition of and expectations from NAC are wildly differing across the board; from the analyst to the vendor to the customer.

Take a listen when Martin posts it and let us know if we should have a second session.  I believe it will show up here:

http://www.securityroundtable.com/

Chris

Bear with me here as I admire the sheer elegance and simplicity of what this latest piece of malware uses as its covert back channel: ICMP.  I know…nothing fancy, but that’s why I think its simplicity underscores the bigger problem we have in securing this messy mash-up of Internet connected chewy goodness.

When you think about it, even the dopiest of users knows that when they experience some sort of abnormal network access issue, they can just open their DOS (pun intended) command prompt and type "ping…" and then call the helpdesk when they don’t get the obligatory ‘pong’ response.

It’s a really useful little protocol. Good for all sorts of things like out-of-band notifications for network connectivity, unreachable services and even quenching of overly-anxious network hosts. 

Network/security admins like it because it makes troubleshooting easy
and it actually forms some of the glue and crutches that folks depend
upon (unfortunately) to keep their networks running…

It’s had its fair share of negative press, sure. But who amongst us hasn’t?  I mean, Smurfs are cute and cuddly, so how can you blame poor old ICMP for merely transporting them?  Ping of Death?  That’s just not nice!  Nuke Attacks!?  Floods!?

Really, now.  Aren’t we being a bit harsh?  Consider the utility of it all..here’s a great example:

When I used to go onsite for customer engagements, my webmail access/POP-3/IMAP and SMTP access was filtered. Outbound SSH and other types of port filtering were also usually blocked but my old friend ICMP was always there for me…so I tunneled my mail over ICMP using Loki and it worked great..and it always worked because ICMP was ALWAYS open.  Now, today’s IDS/IPS combos usually detect these sorts of tunelling activities, so some of the fun is over.

The annoying thing is that there is really no reason why the entire range of ICMP types need to be open and it’s not that difficult to mitigate the risk, but people don’t because they officially belong to the LBNaSOAC (Lazy Bastard Network and Security Operators and Administrators Consortium.)

However, back to the topic @ hand.  I was admiring the simplicity of this newly-found data-stealer trojan that installs itself as an Internet Exploder (IE) browser helper and ultimately captures keystrokes and screen images when accessing certain banking sites and communicates back to the criminal operators using ICMP and a basic XOR encryption scheme.  You can read about it here.

It’s a cool design.  Right wrong or indifferent, you have to admire the creativity and ubiquity of the back channel…until, of course, you are compromised.

There are so many opportunities for the creative uses of taken-for-granted infrastructure and supporting communication protocols to suggest that this is going to be one hairy, protracted battle.

Submit your vote for the most "clever" use of common protocols/applications for this sort of thing…

Chris

I have to admit that when I read Alan Shimel’s blog entry whereby he calls out Richard Stiennon on his blog entries titled "Don’t Bother with NAC" and "Network Admission Control is a Blind Alley," I started licking my chops as I couldn’t wait to jump in and take some time to throw fuel on the fire.  Of course, Mike Rothman already did that, but my goal in life is to be more inflammatory than he is, so let the dousing begin!

I’ve actually been meaning to ask for clarification on some points from both of these fellas, so no better time than the present. 

Now, given the fact that I know all of the usual suspects in this
debate, it’s odd that I’m actually not siding with any of them.  In
fact, I sit squarely in the middle because I think that in the same
breath both Richard and Alan are as wrong as they are right.  Mike is always right (in his own mind) but rather than suggest there was a KO here, let’s review the tape and analyze the count before we go to the scorecards for a decision.

This bout is under the jurisdiction of and sanctioned by the Nevada
Gaming Commission and brought to you by FUD — the offical supplier of
facts on the Internet. 😉

Tale of the tape:

Richard Stiennon:

1. Richard Stiennon highlighted some of Ofir Arkin’s NAC "weaknesses" presented at Black Hat and suggests that NAC is a waste of time based upon not only these technical deficiencies but also that the problems that NAC seeks to solve are already ameliorated by proper patching as machines "…that are patched do not get infected."
2. Somewhat confusingly he follows on with the statement based upon the previous statement that "The fear of the zero-day worm or virus has
   proved ungrounded. And besides, if it is zero-day, then having the
   latest DAT file from Symantec does you no good."
3. Richard suggests that integrating host-based and network-based security
   is a bad idea and that the right thing to do is based upon  "de-coupling network and host-based security. Rather than require them to work together let them work alone."
4. Ultimately he expects that the rest of the problems will be fixed with a paradigm which he has called Secure Network Fabric. 
5. Richard says the right solution is the concept he calls "Secure Network Fabric (SNF)" wherein "…network security
   solutions will not require switches, routers, laptops, servers,
   and vendors to work in concert with each other" but rather "…relies most heavily
   on a switched network architecture [which] usually involve[s] core switches
   as well as access switches."
6. SNF relies on the VLANs that "…would be used to provide granularity
   down to the device-level where needed. The switch enforces policy based
   on layer 2 and 3 information. It is directed by the NetFlow based
   behavior monitoring system.
7. Richard has talked about the need for integrating intelligent IDP (Intrusion Detection and Prevention) systems coupled with NBA/NBAD (Network Behavioral Analysis/Network Behavioral Anomaly Detection) and switching fabric for quite some time and this integration is key in SNF functionality.
8. Furthermore, Richard maintains that relying on the endpoint to report its health back to the network and the mechanisms designed to allow admission is a bad idea and unnecessary.
9. Richard maintains that there is a difference between "Admission Control" and "Access Control" and sums it up thusly: "To keep it simple just remember: Access Control, good. Admission Control, bad."

Alan Shimel:

1. Alan freely admits that there are some technical "issues" with NAC such as implementation concerns with DHCP, static IP addresses, spoofed MAC addresses, NAT, etc.
2. Alan points out that Richard did not mention that Ofir Arkin also suggests that utilizing a NAC solution based upon 802.1x is actually a robust solution.
3. Alan alludes to the fact that people deploy NAC for various reasons and (quoting from a prior article) "…an important point is that NAC is not really geared towards stopping the determined hacker, but rather the inadvertant polluter."  Hence I believe he’s saying that 802.1x is the right NAC solution to use if you can as it solves both problems, but that if latter is not your reason for deploying NAC, then the other issues are not as important.
4. Alan points to the fact that many of Richard’s references are quite dated (such as the comments describing the 2003 acquisition of TippingPoint by 3Com as "recent" and that ultimately SNF is a soapbox upon which Richard can preach his dislike of NAC based upon "…trusting the endpoint to report its health."
5. De-coupling network and host-based endpoint security is a bad idea, according to Alan, because you miss context and introduce/reinforce the information silos that exist today rather than allow for coordinated, consolidated and correlated security decisions to be made.
6. Alan wishes to purchase Pot (unless it’s something better) from Richard and go for a long walk on the shore because Mr. Stiennon has "the good stuff" in his opinion since Richard intimates that patching and configuration management have worked well and that zero-day attacks are a non-entity.
7. Alan suggests that the technology "…we used to call behvior based IPS’s" which will pass "…to the switch to enfore policy" is ultimately "another failed technology" and that the vendors Richard cites in his BAIPS example (Arbor, Mazu, etc.) are all "…struggling in search of a solution for the technology they have developed."
8. Alan maintains that the SNF "dream" lacks the ability to deliver any time soon because by de-coupling host and network security, you are hamstrung by the lack of "…context, analytics and network performance."
9. Finally, Alan is unclear on the difference between Network Access Control (good) and Network Admission Control (bad.)

So again, I maintain that they are both right and both wrong.  I am the Switzerland of NAC/SNF! 

I’ll tell you why — not in any particular order or with a particular slant…

(the bout has now turned from a boxing context to a three man Mixed-Martial-Arts Octagon cage-match!  I predict a first round submission via tap-out):

1. Firstly, endpoint and network security MUST be deployed together and ultimately communicate with one another to ultimately effect the most visible, transparent, collaborative and robust defense-in-depth security strategy available.  Nobody said it’s a 50/50 percentage, but having one without the other is silly.  There are things on endpoints that you can’t discover over a network.  Not having some intelligence about the endpoint means the network cannot possibly determine as accurately the "intent" of the packets spewing from it.
2. Network Admission Control solutions don’t necessarily blindly trust the endpoint — whether agent or agentless, the NAC controller takes not only what the host "reports" but also how it "responds" to active probes of its state.  While virtualization and covert rootkits have the capability to potentially hide from these probes, suggesting that an endpoint passes these tests does not mean that the endpoint is no longer subject to any other control on the network…
3. Once Network Admission Control is accomplished, Network Access Control can be applied (continuously) based upon policy and behavioral analysis/behavioral anomaly detection.
4. Patching doesn’t work — not because the verb is dysfunctional — but because the people who are responsible for implementing it are.  So long as these systems are not completely automated, we’re at risk.
5. Zero day exploits are not overblown — they’re getting more surgically targeted and the remediation cycles are too long.  Network-based solutions alone cannot protect against anomalies that are not protocol or exploit/vulnerability signature driven…if the traffic patterns are not abnormal, the flags are OK and the content seemingly benign going to something "normal," it *will* hit the target.
6. You’ll be suprised just how immature many of the largest networks on this planet are in terms of segmentation via VLANs and internal security…FLAT, FLAT, FLAT.  Scary stuff.  If you think the network "understands" the data that is transported over it or can magically determine what is more important by asset/risk relevance, I too would like some of that stuff you’re smoking.
7. Relying on the SNF concept wherein the "switch enforces policy based
   on layer 2 and 3 information," and "is directed by the NetFlow based
   behavior monitoring system" is wholly shortsighted.  Firstly layer 2/3 information is incredibly limited since most of the attacks today are application-level attacks and NOT L2/L3 and Netflow data (even v9) is grossly coarse and doesn’t provide the context needed to effectively determine these sorts of incursions.  That’s why NetFlow today is mostly used in DDoS activities — because you see egregiously spiked usage and/or traffic patterns.  It’s a colander not a sieve.
8. Most vendors today are indeed combining IDP functionality with NBA/D to give a much deeper and contextual awareness across the network.  More importantly, big players such as ISS and Cisco include endpoint security and NAC (both "versions") to more granularly define, isolate and ameliorate attacks.  It’s not perfect, but it’s getting better.
9. Advances in BA/NBA/NBAD are coming (they’re here, actually) and it will produce profound new ways of managing context and actionable intelligence when combined with optimized compute and forwarding engines which are emerging at the same time.   They will begin, when paired with network-wide correlation tools, to solve the holy trinity of issues: context, analytics and performance.
10. Furthermore, companies such as ISS and StillSecure (Alan’s company) have partnered with switch vendors to actually do just what Richard suggests in concept.  Interestingly enough,
    despite the new moniker, the SNF concept is not new — Cisco’s SDN (albeit
    without NAC) heavily leverages the concepts described above from an
    embedded security perspective and overlay security vendors such as ISS
    and Crossbeam also have solutions (in POC or available) in this area.
11. Let’s be honest, just like the BA vendors Alan described, NAC is in just the same position — "struggling in search of a solution for the technology they have developed."  There are many reasons for deploying NAC: Pre and Post-inspection/Quarantine/Remediation and there are numerous ways of doing it: agent-based/agentless/in-line/out-of-band… The scary thing is with so many vendors jumping in here and the 800 pound Gorilla (Cisco) even having trouble figuring it out, how long before NAC becomes a feature and not a market?  Spending a bunch of money on a solution (even without potential forklifts) to not "… stop the determined hacker, but rather the inadvertant polluter" seems a little odd to me.  Sure it’s part of a well defined network strategy, but it ain’t all that yet, either.
12. With Cisco’s CSO saying things like "The concept of having devices join a network in which they are posture-assessed and given access to the network in a granular way is still in its infancy" and even StillSecure’s CTO (Mitchell Ashley) saying "…but I think those interested in NAC today are really trying to avoid infection spread by an unsuspecting network user rather than a knowledgeable intruder" it’s difficult to see how NAC can be considered a core element of a network security strategy WITHOUT something like SNF.

So, they’re both right and both wrong.  Oh, and by the way, Enterprise and Provider-class UTM solutions are combining ALL of this in a unified security service layer… FW, IDP, Anti-X, NBA(D) and SNF-like foundations.

[Tap before it breaks, boys!]

We need NAC and we need SNF and I’ve got the answer:

1. Take some of Richard’s "good stuff"
2. Puff, puff, pass
3. Combine some of Alan’s NAC with Richard’s SNF
4. Stir
5. Bake for 30 minutes and you have one F’N (good) SNAC
   (it’s an anagram, get it!)

There you have it.

Chris

Mike Rothman commented today on another of Michael Farnum’s excellent series on being an "effective security manager."   

Mike R. starts of well enough in defining the value-prop of "Risk Management" as opposed to managing threats and vulnerabilities, and goes on to rightfully suggest that in order to manage risk you need to have a "value component" as part of the weighting metrics for decision making…all good stuff:

But more importantly, you need to get a feel for the RELATIVE value of
stuff (is the finance system more important than the customer
management) before you can figure out where you should be spending your
time and money.

It goes without saying that it’s probably a good idea (and an over-used cliche) that it doesn’t make much sense to spend $100,000 to protect a $100 asset, but strangely enough, that’s what a lot of folks do…and they call it "defense in depth." 

Before you lump me into one of Michael F’s camps, no, I am not saying defense in depth is an invalid and wasteful strategy.  I *am* saying that people hide behind this term because they use it as a substitute for common sense and risk-focused information protection and assurance...

…back to the point at hand…

Here’s where it gets ugly as the conclusion of Mike R’s comments set me
off a little because it really does summarize one of the biggest
cop-outs in the management and execution of information protection/security today:

That is not a technique for the unsophisticated or
those without significant political mojo. If you are new to the space,
you are best off initially focusing on the stuff within your control,
like defense in depth and security awareness.

This is a bullshit lay-down.  It does not take any amount of sophistication to perform a business-driven risk-assessment in order to support a risk-management framework that communicates an organization’s risk posture and investment in controls to the folks that matter and can do something about it. 

It takes a desire to do the right thing for the right reason that protects that right asset at the right price point.  Right?

While it’s true that most good IT folks inherently understand what’s important to an organization from an infrastructure perspective, they may not be able to understand why or be able to provide a transparent explanation as to what impacts based upon threats and exposed attack surfaces really mean to the BUSINESS.

You know how you overcome that shortfall?  You pick a business and asset-focused risk assessment framework and  you start educating yourself and your company on how, what and why you do what you do; you provide transparency in terms of function, ownership, responsibility, effectiveness, and budget.  These are metrics that count.

Don’t think you can do that because you don’t have a fancy title, a corner office or aren’t empowered to do so?  Go get another job because you’re not doing your current one any justice.

Want a great framework that is well-suited to this description and is a good starting point for both small and large companies?  Try Carnegie-Mellon’s OCTAVE.  Read the book.  Here’s a quick summary:

For an organization that wants to understand its information security
needs, OCTAVE^® (Operationally Critical Threat, Asset, and
Vulnerability Evaluation^SM) is a risk-based strategic assessment
and planning technique for security.

OCTAVE is self-directed. A small team of people from the operational (or
business) units and the IT department work together to address the security
needs of the organization.  The team draws on the knowledge of many employees to
define the current state of security, identify risks to critical assets, and
set a security strategy.

OCTAVE is flexible. It can be tailored for most organizations. 

OCTAVE is different from typical technology-focused assessments. It focuses
on organizational risk and strategic, practice-related issues, balancing operational
risk, security practices, and technology.

Suggesting that you need to have political mojo to ask business unit leaders well-defined, unbiased, interview-based, guided queries is silly.  I’ve done it.  It works.  It doesn’t take a PhD or boardroom experience to pull it off.  I’m not particularly sophisticated and I trained a team of IT (but non-security) folks to do it, too.

But guess what?  It takes WORK.  Lots and lots of WORK.  And it’s iterative, not static.

Because of the fact that Michael’s task list of security admins is so huge, anything that represents a significant investment in time, people or energy usually gets the lowest priority in the grand scheme of things.  That’s the real reason defense-in-depth is such a great hiding place.

With all that stuff to do, you *must* be doing what matters most, right?  You’re so busy!  Unsophisticated, but busy! 😉

Instead of focusing truly on the things that matter, we pile stuff up and claim that we’re doing the best we can with defense in depth without truly understanding that perhaps what we are doing is not the best use of money, time and people afterall.

Don’t cop out.  Risk Management is neither "old school" or a new concept; it’s common sense, it’s reasonable and it’s the right thing to do.

It’s Rational Security.

I read with some interest a recent Network Computing web posting by Don MacVittie  titled "The Downside of All-in-One Security."  In this post, Don makes some comments that I don’t entirely agree with, so since I can’t sleep, I thought I’d perform an autopsy to rationalize my discomfort.

I’ve posted before regarding Don’s commentary on UTM (this older story is basically the identical story as the one I’m commenting on today?) in which he said:

Just to be entertaining, I’ll start by pointing out that most readers I talk to wouldn’t
consider a UTM at this time. That doesn’t mean most organizations
wouldn’t, there’s a limit to the number I can stay in regular touch
with and still get my job done, but it does say something about the
market.

All I can say is that I don’t know how many readers Don talks to, but the overall UTM market to which he refers can’t be the same UTM market which IDC defines as being set to grow to $2.4 billion in 2009, a 47.9 percent CAGR from 2004-2009.  Conversely, the traditional firewall and VPN appliance market is predicted to decline to $1.3 billion by 2009 with a negative CARG of 4.8%.

The reality is that UTM players (whether perimeter or Enterprise/Service Provider class UTM) continue to post impressive numbers supporting this growth — and customers are purchasing these solutions.  Perhaps they don’t purchase "UTM" devices but rather "multi-function security appliances?" 🙂 

I’m just sayin’…

Don leads of with:

Unified Threat Management (UTM) products combine multiple security
functions, such as firewall, content inspection and antivirus, into a
single appliance. The assumption is UTM reduces management hassles by
reducing the hardware in your security infrastructure … but you know
what happens when you assume.

No real problems thus far.  My response to the interrogative posited by the last portion of Don’s intro is: "Yes, sometimes when you assume, it turns out you are correct."  More on that in a moment…

You can slow the spread of security appliances by collapsing many
devices into one, but most organizations struggle to manage the
applications themselves, not the hardware that runs them.

Bzzzzzzzzttttt.  The first half of the sentence is absolutely a valid and a non-assumptive benefit to those deploying UTM.  The latter half makes a rather sizeable assumption, one I’d like substantiated, please.

If we’re talking about security appliances, today there’s little separation between the application and the hardware that runs them.  That’s the whole idea behind appliances.

In many cases, these appliances use embedded software, RTOS in silicon, or very tightly couple the functional and performance foundations of the solution to the binding of the hardware and software combined.

I can’t rationalize someone not worrying about the "hardware," especially when they deploy things like HA clusters or a large number of branch office installations. 

You mean to tell me that in large enterprises (you notice that Don forces me to assume what market he’s referring to because he’s generalizing here…) that managing 200+ firewall appliances (hardware) is not a struggle?  Don talks about the application as an issue.  What about the operating system?  Patches?  Alerts/alarms?  Logs?  It’s hard enough to do that with one appliance.  Try 200.  Or 1000!

Content
inspection, antivirus and firewall are all generally controlled by
different crowds in the enterprise, which means some arm-wrestling to
determine who maintains the UTM solution.

This is may be an accurate assumption in a large enterprise but in a small company (SME/SMB) it’s incredibly likely that the folks managing the CI, AV and firewall *are* the same people/person.  Chances are it’s Bob in accounting!

Then there’s bundling. Some vendors support best-of-breed security
apps, giving you a wider choice. However, each application has to crack
packets individually–which affects performance.

So there’s another assumptive generalization that somehow taking traffic and vectoring it off at high speed/low latency to processing functions highly tuned for specific tasks is going to worsen performance.  Now I know that Don didn’t say it would worsen performance, he said it  "…affect(s) performance," but we all know what Don meant — even if we have to assume. 😉

Look, this is an over-reaching and generalized argument and the reality is that even "integrated" solutions today perform replay and iterative inspection that requires multiple packet visitations with "individual packet cracking" — they just happen to do it in parallel — either monolithically in one security stack or via separate applications.  Architecturally, there are benefits to this approach.

Don’t throw the baby out with the bath water…

How do you think stand-alone non-in-line IDS/IPS works in conjunction with firewalls today in non-UTM environments?  The firewall gets the packet as does the IDS/IPS via a SPAN port, a load balancer, etc…they crack the packets independently, but in the case of IDS, it doesn’t "affect" the firewall’s performance one bit.  Using this analogy, in an integrated UTM appliance, this example holds water, too.

Furthermore, in a UTM approach the correlation for disposition is usually done on the same box, not via an external SEIM…further saving the poor user from having to deploy yet another appliance.  Assuming, of course, that this is a problem in the first place. 😉

I’d like some proof points and empirical data that clearly demonstrates this assumption regarding performance.  And don’t hide behind the wording.  The implication here is that you get "worse" performance.   With today’s numbers from  dual CPU/multi-core processors, huge busses, NPU’s and dedicated hardware assist, this set of assumptions flawed.

Other vendors tweak
performance by tightly integrating apps, but you’re stuck with the
software they’ve chosen or developed.

…and then there are those vendors that tweak performance by tightly integrating the apps and allow the customer to define what is best-of-breed without being "stuck with the software [the vendor has] chosen or developed."  You get choice and performance.  To assume otherwise is to not perform diligence on the solutions available today.  If you need to guess who I am talking about…

For now, the single platform model isn’t right for enterprises large
enough to have a security staff.

Firstly, this statement is just plain wrong.  It *may* be right if you’re talking about deploying a $500 perimeter UTM appliance (or a bunch of them) in the core of a large enterprise, but nobody would do that.  This argument is completely off course when you’re talking about Enterprise-class UTM solutions.

In fact, if you choose the right architecture, assuming the statement above regarding separate administrative domains is correct, you can have the AV people manage the AV, the firewall folks manage the firewalls, etc. and do so in a very reliable, high speed and secure consolidated/virtualized fashion from a UTM architecture such as this.

That said, the sprawl created by
existing infrastructure can’t go on forever–there is a limit to the
number of security-only ports you can throw into the network. UTM will
come eventually–just not today

So, we agree again…security sprawl cannot continue.  It’s an overwhelming issue for both those who need "good enough" security as well as those who need best-of-breed. 

However, your last statement leaves me scratching my head in confused disbelief, so I’ll just respond thusly:

UTM isn’t "coming," it’s already arrived.  It’s been here for years without the fancy title.  The same issues faced in the datacenter in general are the same facing the microcosm of the security space — from space, power, and cooling to administration, virtualization and consolidation — and UTM helps solve these challenges.  UTM is here TODAY, and to assume anything otherwise is a foolish position.

My $0.02 (not assuming inflation)

/Chris