Rational Survivability

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

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

One of the things I spend a lot of time doing these days is talking to
analysts – both market and financial – regarding the very definition of
UTM and what it means to vendors, customers, and the overall impact
that UTM has to the approach to security taken by the SMB contingent,
large enterprises and service providers.

The short of it: it means a LOT of things to a LOT of different people.  That’s potentially
great if you’re a vendor selling re-branded UTM kit that used to be a
firewall/IDS/IPS because it allows for a certain amount of latitude and
agility in positioning your product, but it can also backfire when you
don’t have a sound strategy and you try to be everything to everyone.

It also sucks if you’re a customer because you have to put the hip
waders on in order to determine if UTM is something you should care
about, integrate into your strategy and potentially purchase.

I’ve written about how UTM Messaging is broken
before, that there are TIERS of product offerings that are truely
differentiated.  Ultimately, UTM breaks down into two strata: Perimeter
UTM and Enterprise/Service Provider UTM.

For the sake of brevity, here’s the rundown introducing the differences:

…That’s what Enterprise-class UTM is for.  The main idea here is that
while for a small company UTM (perimeter UTM) is simply a box with a set number of
applications or security functions, composed in various ways and
leveraged to provide the ability to "do things" to traffic as it passes
through the bumps in the security stack.

In large enterprises and service providers the concept of the "box"
has to extend to an *architecture* whose primary attributes are
flexibility, resilience and performance.

I think that most people don’t hear that, as the marketing of UTM
has eclipsed the engineering realities of management,
operationalization and deployment based upon what most people think of
as UTM.

Historically, UTM is defined as an approach to network security in
which multiple logically complimentary security applications, such as
firewall, intrusion detection and antivirus, are deployed together on a
single device. This reduces operational complexity while protecting the
network from blended threats.

For large networks where security requirements are much broader and
complex, the definition expands from the device to the architectural
level. In these networks, UTM is a “security services layer” within the
greater network architecture. This maintains the operational simplicity
of UTM, while enabling the scalable and intelligent delivery of
security services based on the requirements of the business and
network. It also enables enterprises and service providers to adapt to
new threats without having to add additional security infrastructure.

Today, Richard Stiennon (of "IDS is dead" fame) blogged
some very interesting comments ultimately asking if "..your UTM [is] a
Mutt?"  It’s an interesting comment on the UTM market as a whole where
ultimately he gets around to shoring up his question/statement by
referencing Symantec’s exit from the hardware market.

I’d say that most UTM offerings are mutts because that’s
exactly what perimeter UTM delivers — a mashup of every neighborhood
stray that happened to end up humping the same piece of hardware.  Ew.

That’s why unless you want to be king of the pound, sporting papers
which testifies to your pedigree and heritage is really important.
You’re not going to win best of show looking like the sappy little
poodle-chihuahua-dingo-thing featured above.

In his scribble, Richard makes the following statement which I exactly addressed in the comment above:

I have a problem with the idea of Universal Threat Management
appliances.  Leaving aside the horrible terminology (Who wants to
manage threats? Don’t you want to block them and forget about them?)
the question that I always ask is: If best-of-breed is the standard for
large enterprises why would it be good practice for a smaller entity to
lump a lot of security functions such as firewall, email gateway, spam
filter, anti-virus, anti-spyware, IDS, IPS, and vulnerability
management all in one under-powered device?

Firstly, the ‘U’ in UTM stands for "Unified" not "Universal,"
however I *totally* agree with Richard that managing (T)hreats and
vulnerabilities is the WRONG approach and UTM has become this catch-all
for the petty evolution of any device that continues to lump ad hoc
security functions onto an existing platform and call it something
else.  That’s perimeter UTM.

So, intead of manging threats, we should be managing risk.  Call me psychic, but that’s exactly what I wrote about here when I introduced the concept of Unified Risk Management (URM.) 

URM provides a way of closing the gap between
pure technology-focused information security infrastructure and
business-driven, risk-focused information survivability
architectures and does so by using sound risk management practices in conjunction with best
of breed consolidated Unified Threat Management (UTM) solutions as the
technology foundation of a consolidated risk management model.

Moving on, I’m not sure that with where we are in today’s compute
cycles that it’s fair to generalize that the companies Richard mentions
such as Astaro, Fortinet, or Watchguard are actually "under-powered,"
but  one could certainly  argue that extensibility, flexibility and
scalability are certaintly constrained by the practical limits of the
underlying machinery and its ability to perform and clumping lots of
these individual boxes together isn’t really a manageable solution.

That being said, I also wrote about this issue here whereby
I make the case that for the Enterprise and service provider markets,
commoditized general purpose boxes will not and cannot scale to
effectively meet the business and risk management requirements — even
with offload cards that plug into big, fat buses.

The reality is that like anything you do when you investigate
technology, concepts or strategy, you should map your business
requirements against the company’s appetite for risk and determine what
architecture (I didn’t say platform specifically) best fits the
resulting outcome.

If "good enough" security is good enough, you have lots of UTM
choices.  If, however, what you need is a balanced defense-in-depth
strategy invested in best-of-breed (based upon your business
requirements) which allows you to deploy security as a service layer in
an extremely high-performance, scaleable, extensible, flexible and
highly-available way, may I suggest the following: (blatant plug, I
know!)

Finally, Symantec exiting the hardware business is a fine thing
because all it really does is galvanize the fact software companies should produce good software and do what they do best. 

What they (and others, mind you) realize that unifying hardware and software in a
compelling way is hard to do if you want to really offer
differentiation and value.  Sure, you can continue to deploy on commoditized hardware if what you want to do is serve an overly-crowded market with margins lower than dust, but why?

Richard further goes on to  talk about how Symantec is focusing on a more lucrative market:  services.   This, in my opinion, is a fantastic idea:

Evidently Symantec is more interested in software and services going
forward. I think they may be on to something.  If the appeal of
mixed-bread, easy to manage security appliances is so great for small
businesses maybe managed security services are set to take off.

Alan Shimel responded with a follow-on perspective to Mike Rothman’s post in which he said:

If big companies want best-of-breed, why should smaller companies
settle for less than that?  It just doesn’t make sense to me.  Mike Rothman
, in his big is small theory, says that customers are willing to put up
with less than best of breed by getting it all from one big vendor.
But some of the "pile them high" UTM’s are not big companies.  Astaro,
Fortinet, Baracuda are not exactly Cisco, Symantec or McAfee. However,
they are all grabbing market share with UTM’s that do not offer best of
breed applications.

This simply comes down to economics (see "good enough" comment above) where they may want an enterprise-class UTM product, but that doesn’t mean they’ll pay for one.  Doing battle in the SMB UTM space is brutal — don’t let the big, bold numbers impress you that much.  When you’re dealing with ASP’s in the $500 range, even with margins in the 40-50% bracket, you’ve got to sell a BOATLOAD of boxes to make money — then there’s the cost of all those adminstrative assistants-cum-network security administrators who call your support center further burdening the bottom line.

That dove-tails right into the argument regarding managed services and security in the cloud — these really are beginning to take off, so this move by Symantec is the right thing to do.  Let the folks who can deliver BoB hardware running your best-in-breed software do that, and you can have your customers pay you to manage it.  In the case of Crossbeam, we don’t market/sell to the SMB, as they are our customer’s customers…namely our enterprise and service-provider UTM offerings are deployed in a completely different space than the folks you mention above. 

In this case, we win either way: either a large enterprise buys our solutions directly or they sub-out to an MSSP/ISP that uses our solution to deploy their services.  Meanwhile, the perimeter/SMB UTM vendors fight for scraps in the pound waiting to be put down because nobody claims them 😉

We’ll cover the hot topic of security outsourcing here shortly.

/Chris

[Much like Colonel Sander’s secret recipe, the evolution of "pure" IPS is becoming an interesting combo bucket of body parts — all punctuated, of course, by a secret blend of 11 herbs and spices…]

So, the usual suspects are at it again and I find myself generally agreeing with the two wisemen, Alan Shimel and Mike Rothman.  If that makes me a security sycophant, so be it.  I’m not sure, but I think these two guys (and Michael Farnum) are the only ones who read my steaming pile of blogginess — and of course Alex Neihaus who is really madly in rapture with my prose… 😉

Both Alan and Mike are discussing the relative evolution from IDS/IPS into "something else." 

Alan references a specific evolution from IDS/IPS to UTM — an even more extensible version of the tradtional perimeter UTM play — with the addition of post-admission NAC capabilities.  Interesting.

The interesting thing here is that NAC typically isn’t done "at the perimeter" — unless we’re talking the need to validate access via VPN, so I think that this is a nod towards the fact that there is, indeed, a convergence of thinking that demonstrates the movement of "perimeter UTM" towards Enterprise UTM deployments that companies are choosing to purchase in order to manage risk.

Alan seems to be alluding to the fact that these Enterprises are considering deployments internally of IPS with NAC capabilities.  I think that is a swell idea.  I also think he’s right.  NAC and about 5-6 other key, critical applications that are a natural fit for anything supposed to provide Unified Threat Management…that’s what UTM stands for, afterall.

Mike alludes to the reasonable assertion that IDS/IPS vendors are only riding the wave preceeding the massive ark building that will result in survival of the fittest, where the definition of "fit" is based upon what the customer wants (this week):

Of course the IDS/IPS vendors are going there because customers want
them to. Only the big of the big can afford to support all sorts of
different functions on different boxes with different management (see No mas box). The great unwashed want the IDS/IPS built into something bigger and simpler.

True enough.  Agreed.  However, there are vendors — big players — such as Cisco and Juniper that
won’t use the term UTM because it implies that their IDS and IPS
products, stacked with additional functions, are in fact turkeys (following up with the poultry analogies) and
that there exists a guilt by association that suggests the fact that
UTM is still considered a low-end solution.  The ASP of most UTM
products is around the $1500 range, so why fight for scraps.

So that leads me to the point I’ve made before wherein I contrast the differences in approach and the ultimate evolution of UTM:

Historically, UTM is defined as an approach to network security in
which multiple logically complimentary security applications, such as
firewall, intrusion detection and antivirus, are deployed together on a
single device. This reduces operational complexity while protecting the
network from blended threats.

For large networks where security requirements are much broader and
complex, the definition expands from the device to the architectural
level. In these networks, UTM is a “security services layer” within the
greater network architecture. This maintains the operational simplicity
of UTM, while enabling the scalable and intelligent delivery of
security services based on the requirements of the business and
network. It also enables enterprises and service providers to adapt to
new threats without having to add additional security infrastructure.

My point here is that just as firewalls added IDS and ultimately became IPS, IPS has had added to it Anti-X and become UTM — but, Perimeter UTM.   The thing missing there is the flexibility and extensibility of these platforms to support more functions and features.

However, as both Mike and Alan point out, UTM is also evolving into architectures that allow for virtualized
security service layers to be deployed from more scaleable platforms
across the network.The next logical evolution has already begun.

When I go out on the road to speak and address large audiences of folks who manage security, most relay the fact that most of them simply do not trust IPS devices with automated full blocking turned on.  Why?  Because they lack context.  While integrated VA/VM and passive/active scanning adds to the data collected, is that really actionalble intelligence?  Can these devices really make reasonable judgements as to the righteousness of the data they see?

Not without BA functionality, they can’t.  And I don’t mean today’s NBA (a la Gartner: Network Behavior Analysis) or NBAD (a la Arbor/Mazu: Network Behavioral Anomaly Detection) technology, either. 

[Put on your pads, boys, ‘cos here we go…]

NBA(D) as it exists today is nothing more than a network troubleshooting and utilization tool, NOT a security function — at least not in its current form and not given the data it collects today.  Telling me about flows across my network IS, I admit, mildly interesting, but without the fast-packet cracking capabilities to send flow data *including* content, it’s not very worthwhile (yes, I know that newer version of NetFlow will supposedly do this, but at what cost to the routers/switches that will have to perform this content inspection?)

NBA(D) today takes xFlow and looks at traffic patterns/protocol usage, etc. to determine if, within the scope of limited payload analysis, something "bad" has occured.

That’s nice, but then what?  I think that’s half the picture.  Someone please correct me, but today netflow comes primarily from routers and switches; when do firewalls start sending netflow data to these standalone BA units?  Don’t you need that information in conjunction with the exports from routers/switches at a minimum to make the least substantiated decision on what disposition to enact?

ISS has partnered with Arbor (good move, actually) in order to take this first step towards integration — in their world it’s IPS+BA.  Lots of other vendors — like SourceFire — are also developing BA functionality to shore up the IPS products — truth be told, they’re becoming UTM solutions, even if they don’t want to call their products by this name.

Optenet (runs on the Crossbeam) uses BA functionality to provide the engine and/or shore up the accuracy for most of their UTM functions (including IPS) — I think we’ll see more UTM companies doing this.  I am sure of that (hint, hint.)

The dirty little secret is that despite the fact that IDS is supposedly dead, we see (as do many of the vendors — they just won’t tell you so) most people purchasing IPS solutions and putting them in IDS mode…there’s a good use of money!

I think the answer lies in the evolution from the turkeys, chickens and buzzards above to the eagle-eyed Enterprise UTM architectures of tomorrow — the integrated, consolidated and virtualized combination of UTM with NAC and NBA(D) — all operating in a harmonious array of security goodness.

Add VA/VM, Virtual patching, and the ability to control how data is created, accessed, manipulated and transported, and then we’ll be cooking with gas!  Finger lickin’ good.

But what the hell do I know — I’m a DoDo…actually, since I grew up in New Zealand, I suppose that really makes me a Kiwi.   Go figure.

Alan Shimel made some interesting points today in regards to what he described as the impending collision between off the shelf, high-powered, general-purpose compute platforms and supplemental "content security hardware acceleration" technologies such as those made by Sensory Networks — and the ultimate lack of a sustainable value proposition for these offload systems:

I can foresee a time in the not to distant future, where a quad core,
quad proccessor box with PCI Express buses and globs of RAM deliver
some eye-popping performance.  When it does, the Sensory Networks of
the world are in trouble.  Yes there will always be room at the top of
the market for the Ferrari types who demand a specialized HW box for
their best-of-breed applications.

Like Alan, I think the opportunities that these multi-processor, multi-core systems with fast buses and large ram banks will deliver is an amazing price/performance point for applications such as security — and more specifically, multi-function security applications such as those that are used within UTM offerings.  For those systems that architecturally rely on multi-packet cracking capability to inspect and execute a set of functional security dispositions, the faster you can effect this, the better.  Point taken.

One interesting point, however, is that boards like Sensory’s are really deployed as "benign traffic accelerators" not as catch-all filters — as traffic enters a box equipped with one of these cards, the system’s high throughput potential enables a decision based on policy to send the traffic in question to the Sensory card for inspection or pass it through uninspected (accelerate it as benign — sort of like a cut-through or fast-path.)  That "routing" function is done in software, so the faster you can get that decision made, the better your "goodput" will be.

Will this differential in the ability to make this decision and offload to a card like Sensory’s be eclipsed by the uptick on the system cpu speed, multicores and lots of RAM?  That depends on one very critical element and its timing — the uptick in network connectivity speeds and feeds.  Feed the box with one or more GigE interfaces, and the probability of the answer being "yes" is probably higher.

Feed it with a couple of 10GigE interfaces, the answer may not be so obvious, even with big, fat buses.  The timing and nature of the pattern/expression matching is very important here.  Doing line rate inspection focused on content (not just header) is a difficult proposition to accomplish without adding latency.  Doing it within context is even harder so you don’t dump good traffic based on a false positive/negative.

So, along these lines, the one departure point for consideration is that the FPGA’s in cards like Sensory’s are amazingly well tuned to provide massively parallel expression/pattern matching capabilities with the flexibility of software and the performance benefits of an ASIC.  Furthermore, the ability to parallelize these operations and feed them into a large hamster wheel designed to perform these activities not only at high speed but with high accuracy *is* attractive.

The algorithms used in these subsystems are optimized to deliver a combination of scale and accuracy that are not necessarily easy to duplicate by just throwing cycles or memory at the problem as the "performance" of the effective pattern matching taxonomy requirements is as much about accuracy as it is about throughput.  Being faster doesn’t equate to being better.

These decisions rely on associative exposures to expressions that are not necessecarily orthagonal in nature (an orthogonal classification is one in which no item is a member of
more than one group, that is, the classifications are mutually
exclusive — thanks Wikipedia!)  Depending upon what you’re looking for and where you find it,  you could have multiple classifications and matches — you need to decide (and quick) if it’s "bad" or "good" and how the results relate to one another.

What I mean is that within context, you could have multiple matches that seem unrelated so flows may require iterative
inspection (of the entire byte-stream or offset) based upon "what" you’re looking for and what you find when
you do — and then be re-subjected to inspection somewhere else in the
byte-stream.

Depending upon how well you have architected the software to distribute/dedicate/virtualize these sorts of functions across multi-processors and multi-cores in a general purpose hardware solution driven by your security software, you might decide that having purpose-built hardware as an assist is a good thing to do to provide context and accuracy and let the main CPU(s) do what they do best.

Switching gears…

All that being said, signature-only based inspection is dead.  If in the near future you don’t have behavioral analysis/behavioral anomaly capabilities to help provide context in addition to (and in parallel with) signature matching, all the cycles in the world aren’t going to help…and looking at headers and netflow data alone ain’t going to cut it.  We’re going to see some very intensive packet-cracking/payload and protocol BA functions rise to the surface shortly.  The algorithms and hardware required to take multi-dimensional problem spaces and convert them down into two dimensions (anomaly/not an anomaly) will pose an additional challenge for general-purpose platforms.  Just look at all the IPS vendors who traditionally provide signature matching scurry to add NBA/NBAD.  It will happen in the UTM world, too.

This isn’t just a high end problem, either.  I am sure that someone’s going to say "the SMB doesn’t need or can’t afford BA or massively parallel pattern matching," and "good enough is good enough" in terms of security for them — but from a pure security perspective I disagree.  Need and afford are two different issues.

Using the summary argument regarding Moore’s law, as the performance of systems rise and the cost asymptotically approaches zero, then accuracy and context become the criteria for purchase.  But as I pointed out, speed does not necessarily equal accuracy.

I think you’ll continue to see excellent high performance/low cost general purpose platforms to provide innovative software-driven solutions being assisted by flexible, scalable and high performance subsystems designed to provide functional superiority via offload in one or more areas.

/Chris

I need to spend 2 minutes further introducing the concept of Enterprise-class UTM.  I’ll post in greater detail as a follow-on in the next day or so.  I just got back from the Gartner show, so my head hurts and it’s 1am in the morning here in Beantown.  This (blog entry below) was an interesting if not somewhat incomplete beginning to this thought process.

Don McVittie over on the Network Computing Security Blog had some really interesting things to say about the need for, general ripeness and maturity of UTM and the operationalization of UTM technology and architecture within the context of how it is defined, considered and deployed today.

What he illustrated is exactly the breakdown where "traditional" SMB-based, perimeter-deployed UTM messaging is today.  You’d be nuts to try an deploy one of these referenced UTM appliances at the core of a large enterprise.  You’re not supposed to.  There’s simply no comparison between what you’d deploy at the core for UTM versus what you’d deploy at a remote/branch office.

That’s what Enterprise-class UTM is for.  The main idea here is that while for a small company UTM is simply a box with a set number of applications or security functions, composed in various ways and leveraged to provide the ability to "do things" to traffic as it passes through the bumps in the security stack.

In large enterprises and service providers the concept of the "box" has to extend to an *architecture* whose primary attributes are flexibility, resilience and performance.

I think that most people don’t hear that, as the marketing of UTM has eclipsed the engineering realities of management, operationalization and deployment based upon what most people think of as UTM.

Historically, UTM is defined as an approach to network security in which multiple logically complimentary security applications, such as firewall, intrusion detection and antivirus, are deployed together on a single device. This reduces operational complexity while protecting the network from blended threats.

For large networks where security requirements are much broader and complex, the definition expands from the device to the architectural level. In these networks, UTM is a “security services layer” within the greater network architecture. This maintains the operational simplicity of UTM, while enabling the scalable and intelligent delivery of security services based on the requirements of the business and network. It also enables enterprises and service providers to adapt to new threats without having to add additional security infrastructure.

You need a really capable and competent switching platform optimized for virtualized service delivery to pull this off.   That’s what this is for — the Crossbeam X80 Security Services Switch:

You plumb the X-series into the switching  infrastructure as an overlay and provide service where and when you need to manage risk by effectively implementing policies which abstract down to making all flows which match criteria within the rules, to be subject to specific security service layer combinations (firewall, IDS, AV, URL, etc…)  No forklifts, no fundamental  departures from how you manage or maintain the network or the security layer(s) defending it.  Enterprise UTM provides transparency, high performance, high availability, best-of-breed virtualized security services, and simplified deployment and management…

UTM for large networks is designed to provide solutions that deliver the key components required for a UTM security services layer:

•     high performance and high availability,
•     best-of-breed applications
•     intelligent and virtualized service delivery

This enables customers to create an intelligent security services layer that delivers the right protection for any part of the network in accordance with evolving threats and business objectives. This layer is managed as a single consolidated system, thus delivering the operational and cost benefits of UTM while radically improving the overall security posture of the network.

More on the architecture which enables this in a follow-on post.  We’ll discuss the traditional embedded vs. overlay appliance model versus the X-Series perspective as well as the C-series.

Look, we’ll go through the technical details in a follow-on post.  Bear with me.

Chris

[Editor’s Note: I really found myself getting suckered into the darkside of this debate when it turned into a BS marketing spin fest and personal bashing session from the other party.  I shouldn’t have responded to those elements, but I did.  I’m guilty.  It was stupid.  Stupid, but strangely satisfying.  Much like tequila.  I still got zero answers to any of the points I raised, so you decide for yourself…]

Looks like Alex Neihaus, Astaro’s VP of Marketing, can’t be bothered to address technical criticism or answer questions debating the utility of approach for Astaro’s new "virtual UTM appliance," so he feels it necessary to hang his "shingle" out in public and launch personal attacks rather than address the issue at hand.  Well, he is in marketing so why would I expect anything different.

Since my comments back to him may not actually make it up on his site, I figure I’ll respond to them here; they won’t be word for word because I forgot to copy/paste my response in terms of what I sent him. 

Jungian synchronicity always blows me away. I was just reading about "intermittent explosive disorder" this morning. It’s apparently severely undiagnosed.

Except at Crossbeam. Apparently, Christofer Hoff, their brand-spankin’ new "chief security strategist" (aka
"we want a Scoble of our own") is deeply worried about virtualization
and the impact on Crossbeam. Ergo, a demonstration of IED in the
blogosphere via a post on his personal blog.

Funny.  I was just reading about  rectal encephalic inversion and in a Freudian twist of fate, Alex’s slip is showing.

As I let him know, I’ve been at Crossbeam for 8 months and before that, I was a customer for almost 3 years deploying their products in the real world, not preaching about them from behind a web interface.  Prior to that I ran an MSSP/Security Consultancy for 9 years, did two other startups, raised venture capital, and built the global managed security service for a worldwide service provider on 4 continents serving 152 countries.  Yet I digress…

But let me say we don’t mind the heat, in fact, we appreciate it.
But next time, Chris, why not post on the Crossbeam site? Why not
change your bio on your blog to indicate your new role? And before you
impugn Richard Stiennon’s credibility, why not earn some in your new
role? I am, of course, fair game, but to wail on Richard isn’t cricket.

Crossbeam doesn’t have blog capabilities yet.  When we do, it will cross-post.  I don’t try to hide what I do or who I do it for at all.  Where exactly on the Scrapture blog does it say that you are the VP of Marketing for Astaro, Alex?

Also, this ain’t my first ride on a tuna boat, pal.  While I haven’t had the privilege of peddling FTP software for a living, I know a thing or two about security — designing, deploying, managing and using it.  As I mentioned in the comments I sent you, everyone’s a dog on the Internet, Alex, and you’re pissing on the wrong hydrant.

In terms of Richard, I know him.  I talk to him reasonably often.  We’re a client.  Nice reach.  I wasn’t impugning his honor, I was pointing out that the quote you used didn’t have a damned thing to do with Astaro.

I do appreciate you taking umbrage at the "ASIC-free" phrase in the
press release. I put that in to see if it would raise any neck hair.
It’s the crux of the issue.

You apparently think that hardware is the answer. I know it isn’t.

Firstly, Crossbeam doesn’t depend on ASIC’s in our products, so your assumption I was bristling at the comment because I need to be defensive about ASIC’s is as wrong as your assertion/innuendo that ASICs actually make things go slower. 

More importantly, your assertion that I think hardware is the answer is, again, dead wrong.  If you knew anything about Crossbeam, you’d recognize that the secret sauce in our solution is the software, not the hardware.  The hardware is nice, but it’s not the answer.

There’s always a more powerful engine. Always a more powerful
subsystem. Always better, always cheaper. Businesses built on
mainframes can be profitable, but never ubiquitous in the face of
commoditized hardware. IBM learned this in the 1990’s; Crossbeam will
learn it shortly. After you’ve sold the Fortune 500 five-hundred units,
you’ll inevitably be stuck for growth. You’ll cast about for the broad
middle.

Ummm, you know squat-all about Crossbeam — that much is obvious.  We’ve sold many more than 500 units and our customer base is split 50/50 between ISP/MO’s/Telco’s and the Fortune 2000 — doubling revenues year after year for 6 years in a space that is supposedly owned by Cisco and Juniper is a testament to the rediculousness of your statement.   I’m shivering in anticpation of our impending doom…by a bunch of VMWare images running on a DL380 no less.

That broad middle will be using commoditized hardware with
integrated, easy-to-use security solutions.

Hey!  We agree about something.  Again, if you knew anything about our product, our roadmap or our technololgy, you’d recognize this.

You’ll talk about
"enterprise ready" to people who want the UTM equivalent of a fax
machine.

Buhahahaha!  A fax just arrived for you.  It’s titled "It’s sure as hell easier to have a high-end solution and scale down than it is to have a low-end solution and scale up!"  Sound familiar?  VMWare ain’t it, bubba. 

Wail all you want how unfortunate it is that UTM is associated with SMB (I agree that’s wrong, wrong, wrong). But the answer to UTM ubiquity isn’t gonna come from the high end.

Sorry. And don’t let that IED problem get you down.

UTM is associated with low-end perimeter solutions that don’t scale and require forklifts due to the marginalization of commoditized hardware.  When you have a solution that actually scales, can sit in a network for 6 years without forklifts, and is in place at the biggest networks on the planet, step up.

Otherwise, do me a favor and respond in kind technically to my points regarding manageablility, security, and scalability…or have Gert or Markus (Astaro’s CSA and CTO) do it, at least we can have a debate about something meaningful.

/Chris

Blipping through the many blogs I read daily, I came across an interesting announcement from Astaro in which they advertise the "…world’s first UTM virtual appliance."  Intrigued, I clicked over here for a peek.

Before you read forward, you should know that I really like Astaro’s products.  I think that for SMB markets, their appliances and solutions are fantastic.  That being said, the word "virtualization" means a lot of things to a lot of people — there are some liberties taken  by Astaro that we’re going to need to analyze before this sort of thing can really be taken seriously.  More on that later.

I’m nominating this announcement for an Emmy because it’s the best use of humor in a commercial that I have seen in a LONG time.  I mean really…blade server solutions with full-on clustering and virtualized/grid computing management layers complete with virtualized storage have a hard time providing this sort of service level reliably.  You mean to tell me that MSSP’s who have SLA’s and make their lunch money providing security as a service are going to build a business on this malarkey?

Somebody call Crossbeam’s global MSSP/ISP/MO customers who provide services in the cloud to hundreds of thousands/millions of their customers and tell them they can ask for a refund because all they need is a couple of DL380’s, VMware, ASG and a set of really big huevos and you’ve got all the performance, scalability, reliability, high-availability and resiliency you need.

Ah, crap.  I’m just such a cynical bastard. 

Here’s the distillation:

1. Take Astaro’s Security Gateway product (a very nicely-done hardened linux-based offering with re-packaged and optimized open source and OEM’d components)
2. Create a VM (virtual machine) image that can be run under the VMWare VM Player, VM Workstation, VM Server or VM ESX
3. Run it on a sufficiently-powered hardware platform
4. Presto-change-o!  You’ve got a virtualized security appliance!

It’s a nice concept, but again it further magnifies the narrowly focused scope of how UTM is perceived today — a mid-market, perimeter solution where "good enough" is good enough.  It’s going to marginalize the value of what true enterprise and provider class UTM brings to the table by suggesting that you can just cobble together a bunch of VM’s, some extra hardware and whammo!  You’ve got mail!  This is the very definition of scrapture!

However, it seems as though the logic at Astaro goes something like this:

"If one Astaro gateway is "good enough," then running LOTS of virtual Astaro gateways is "even gooder!"  AND you can run hundreds of ’em on the same machine (see rediculous quote section below.)

The marketing folks over at Astaro are off to a wonderful June as they really put in the OT to milk this one for all it’s worth.  Let’s get one thing straight, there’s a real big difference between innovation and improvisation.  I’ll let you figure out what my opinion of this is.

Firstly, this concept in the security space is hardly new.  Sure, it may be the first "UTM" product to be offered in a VM, but StillSecure has been providing free downloads of its Strata Guard IPS product this way for months — you download the VMWare image and poof!  Instant IPS.

Secondly, I’m really interested in what controls one would have to put in place to secure the host operating system that is running all of these VM’s.  I mean, when you run Astaro’s hardened appliance, that’s all taken care of for you.  What happens when Johnny SysAdmin boots up VMWare Server on Windows 2K3 and loads 40 instances of his "secure" firewall?  Okay, maybe he uses linux.  Same question.  What happens when you need to patch said OS and it blows VMware sky-high?

Thirdly, how exactly do you provide for CPU/Memory/IO arbitration when running all these VMWare instances and how would an Enterprise leverage this virtual mass of UTM "appliances" without load balancing capabilities?  What about high-availability?

Fourthly, what happens to all of these VM UTM instances when the host OS takes a giant crap? 

Fifthly, the sheer number of scrapturelicious quotes in this press release is flan-friggin-tastic.:

Astaro Security Gateway for VMware allows customers to flexibly run
Astaro Security Gateway software on a VMware infrastructure. Many
hundreds or thousands of Astaro Security Gateways can be virtualized in
this way, each delivering the network protection and cleaning for which
Astaro is famous.

…ummmm…I can only assume you meant on a hundred or a thousand boxes?

Major benefits for users include simpler deployment in large and
complex environments, better hardware allocation and reduced hardware
expenditures because physical computers can run multiple virtual
appliances. And because Astaro’s unified threat management is
ASIC-free, performance when running in a virtual machine is maximized.

How do you actually plumb one of these things into a network?  How do you configure multi-link trunking utilizing VLANs across the host OS up to the VM instances?  This is simpler, how?  Oh, that’s right…it’s PERIMETER UTM…

And then there’s the fact that because it runs on generic PC’s under a VM, you can ignore the potentially crappy performance and we don’t need no stinkin’ ASICs — they only get in the way.  That’s right, ASIC’s make security applications run SLOWER!

“The ability to virtualize gateway security services opens up major new
capabilities for managed service providers (MSPs) to deliver air-tight
security services to small- and medium-size business customers,” said
Richard Stiennon, founder, IT-Harvest Group. “MSPs can leverage their
hardware investment while providing dedicated security services to
end-user customers, resulting in superior security and manageability.”

Rich, I gotta ask…did you actually say this in regards to Astaro’s VM announcement or security virtualization in general?  Since there’s ZERO reference to Astaro in this quote, I can only assume the latter.  If so, your honor is restored.  If not, you’re buyin’ the beer at Gartner buddy because just in case you haven’t heard, IDS is dead 😉

Look, I like the fact that you can take their product, try it out under a low-cost controlled test and see if you want to buy it.  Great idea.  Suggesting that the MSSP’s of the world and going to run out in droves, buy a DL380 and solve the North American continent’s security woes is, much like my analogy, rediculous.

Folks like Fortinet, Juniper and Cisco are gunning for the low-end market and you can bet your bottom scrapture that they have the will, money and at-bat’s to recognize that there is a lot of money to be made by providing virtualized security services — either in the cloud via MSSP’s or in the Enterprise.

But don’t worry because they have those annoying things called ASICs, so I’m sure Astaro will be fine. 

Virtually yours,

/Chris

I was reading Mike Rothman’s latest blog entry regarding defense in depth and got thinking about how much I agree with his position and how that would seemingly put me at odds given what I do for a living when put within the context of Unified Threat Management (UTM) solutions — the all-in-one "god boxes" that represent the silver bullet for security woes 😉

Specifically, I am responsible for crafting and evangelizing the security strategy for a company that one might (erroneously) expect trumpets that one can solve all security ills by using a single UTM device instead of a layered approach via traditional defense in depth.  I need to clear that up because there’s enough septic marketing material out there today that I can’t bear to wade through it any longer.   And yes, I work for a company that sells stuff, so you should take this with whatsoever a reasonable amount of NaCl you so desire…

There is a huge problem with how UTM today is perceived.  UTM — and in this case the classical application thereof — is really defined as a perimeter play where boxes that were once firewalls that then became firewalls+IDS that then became firewalls+IDS+IPS have now become boxes that are firewalls+IDP+Anti-everything.  IDC defines that the basic definition of a UTM appliance is one that offers firewall, IDP and Anti-virus in a single box.  There are literally tons of options here, but the reality is that almost all of these "solutions" actually fly in the face of defense in depth because the consumer of these devices is missing one critical option: Flexibility.

Flexibility regarding the choice of technology.  Flexibility regarding the choice of vendor.  Flexibility of choice regarding extensibility of functionality.

Tradtional (perimeter) UTM is, in almost all cases, a single vendor’s version of the truth.
Lots of layers — but in one box from one vendor!  That’s not defense in depth,
that’s defense in breadth.

That may be fine for the corner liquor store with DSL Internet access, but what enterprises really need are layers of appropriate defense from multiple best in breed vendors deployed via a consolidated and virtualized architecture that allows for safer, simpler networks.

On the surface, UTM seems like a fine idea — cram as many layers of security "stuff" into a box that you can sprinkle around the network in order to manage threats and vulnerabilities.  Using a single device (albeit many of them) would suggest that you have less moving parts from a management perspective and instead of putting 5 separate single-function boxes in-line with each other to protect your most important assets, now you only need one.  This is a dream for a small company where the firewall admin, network engineer and help desk also happens to be the HR director.

This approach is usually encountered at the "perimeter," which today is usually defined as the demarcated physical/logical ingress/egress dividing the "inside" from the "outside."  While there may well be a singular perimeter in small enterprises and home networks, I think it fair to say that in most large organizations, there are multiple perimeters — each surrounding mini "cores" that contain the most important assets segmented by asset criticality, role, function or policy-driven boundaries.

Call it what you will: de-perimeterization, re-perimeterization, dynamic perimiterization…just don’t call it late for supper.

In this case, I maintain that the perimeter isn’t "going way," it’s multiplying — though the diameter is decreasing.  As it does, security practitioners have two choices to deal with segmented and mini-perimeterized mini-cores:

1. Consolidate & Virtualize
2. Box Stack/Sprinkle

These two options seem simple enough, and when you pull back the covers, there are a couple of options you have to reconcile in either scenario:

1. Single-vendor embedded security in the network infrastructure (routers/switches)
2. Single-vendor overlay security via single-function, single-application devices
3. Single-vendor overlay security via single application/multi-function UTM
4. Multi-vendor embedded security in the network infrastructure (routers/switches)
5. Multi-vendor overlay security via single application/muti-function security applications
6. Multi-vendor overlay security via Best-of-breed security applications

When pairing the deployment option from the first set with a design methodology from the second, evaluating the solution leads to many challenges; balancing a single-vendor’s version of the truth (in one or more boxes) against many cooks in the kitchen in combination with either "good enough" or best in breed.  Tough decisions.

"Good enough" or "best in breed." One box or lots.  The decision should be made based upon risk, but unfortunately that seems to be a four letter word to most of the world; we ought to be managing risk, but instead, we manage threats and vulnerabilities.  It’s no wonder we are where we are…

For a taste test, go ahead and ask your network switch vendor or your favorite UTM appliance maker where their solutions to these very real business-focused security challenges exist in their UTM delivery platforms today:

• Web Application security
• Database security
• XML/WS/SOA security
• VoIP security

They don’t have any.  Probably never will.  Why?  Because selling perimeter UTM isn’t about best in breed.  It’s about selling boxes.  What happens when you need to deploy these functions or others in combination with FW, IDP, AV, Anti-spam, Anti-Spyware, URL Filtering, etc…you guessed it, another box.  Defense in depth?  Sure, but at what cost?

When defense in depth lends itself to management nightmares due to security sprawl, there is a very realistic side effect that could introduce more operational risk into the business than the risk the very controls were supposed to mitigate.  It’s a technology cirlce-jerk.

What we need is option #1 from the first set paired with option #6 from the second — consolidated and virtualized security service layers from multiple vendors in a robust platform.  This pairing needs to provide a consolidated solution set that is infrastructure agnostic and as much a competent network platform as it is an application/service delivery platform.

This needs to be done in a manner in which one can flexibly define, deploy and manage exactly the right combination of security functions as a security "service layer" deployed exactly where you need it in a network to manage risk — where the risk justifies the cost. And by cost I mean both CapEx and OpEx. 

Of course, this solution would require immense flexibility, high availability, scalability, resiliency, high performance, and ease of management.  It would need to be able to elevate the definition of the ill-fated "Perimeter UTM" to scale to the demands of "Enterprise UTM" and "Provider UTM."  This solution would need to provide true defense in depth…providing the leverage to differentiate between "network security," "information security," and "information survivability."

Guess what?  For enterprises and service providers where the definition morphs based upon what the customer defines as best in breed, defense in depth either becomes a horrific nightmare of management and cost or a crappy deployment of good enough security that constantly requires forklifts, doesn’t scale, doesn’t make us more secure, is a sinkhole for productivity and doesn’t align to the business.  Gee, I’ll take two.

We’re in this predicament because an execution-driven security reference architecture to allow businesses to deploy defense in depth in a manner consistent with managing risk has not been widely available, or at least not widely known.

I chuckled when people called me nuts for declaring that the "core"
was nothing more than a routing abstraction and that we were doomed if
we kept designing security based upon what the layout of wiring closets
looked like (core – distribution – access.)  I further chuckle
(guffaw?) now that rational, common sense risk management logic is
given some fancy name that seems to indicate it’s a new invention.  Now
as the micro-cores propagate, the perimeters multiply, the threat
vectors and attack surfaces form cross-hatches dimensionally and we
gaze out across the vast landscape of security devices which make up
defense in depth, perhaps UTM can be evaluated within the context it
deserves.

On the one hand, I’m not going to try and turn this into a commercial for my product as there are other forums for that, but on the other I won’t pretend that I don’t have a dog in this hunt, because I do.  I was a real-world customer using this architecture for almost 3  years before I took up this crusade.  Managing the security of $25 Billion of other people’s money demands
really good people, processes and technology.  I had the first two and
found the third in Crossbeam.

The reality is that nobody does what Crossbeam does and if you need the proof points to substantiate that, go to the largest telco’s, service providers, mobile operators and enterprises on the planet and check out what’s stacked next to the Juniper routers and Cisco switches…you’ll likely find one of these.

Real UTM.  Real defense in depth.  Really.