« I'm a Twit(terer) but did you know that the L.A. Fire Department is, too? | Main | Shrdlu's Model Of Virtual(ization) Insanity... »

September 01, 2007

We Used to Worry About Security Appliance Sprawl - Now It's Endpoint Security Software Sprawl!

Endpointcontrolhell_3Over the last 2-3 years, we've seen a lot of consolidation take place in the security industry; physically, functionally and from a business perspective.

Security practitioners have struggled to gain a foothold against the rising tide of threats washing their way while having to deploy and manage security box after security box in response to each new class of threat and vulnerability.

Each of these boxes provides a specialized function and each expects to be in-line with one another sitting in front of the asset(s) to be protected.

It's a nasty self-perpetuating game of security dominoes with each in-line device adding its own latency tax and contributing to an ever-expanding cascading failure domain by adding to the burden of operational complexity, cost and a weaker security posture.

Why a weaker security posture?  Doesn't "defense in depth" make me more secure?  Well, since it's  extremely difficult to understand the effect one device's security policy has on another, this truly exemplifies the notion of a chain only being as strong as its weakest link.  And with everything being encrypted, we can't even make decent decisions on content.  Don't even get me started on the effect this has on change control.

Dominoes_4 As we've continued to deal with this security appliance sprawl across our networks, the natural evolution of the consolidation effect is to combine security functions at arterial points across or in the network taking the form of UTM devices or embedded in routers and switches.

However, we've also come to realize that the locus of the threats and vulnerabilities demands that we get as close to the assets and data we seek to protect, so now in an ironic twist, the industry has turned to instead sprinkle software-based agents directly on the machines instead.

After all, the endpoint is the closest thing to the data, so the more endpoint control the better, right?

What we've done now is transferred the management of a few gateways to that of potentially thousands of endpoints.

Based on an informal survey of security practitioners, the diagram I whipped up above demonstrates various end-point agents that reside on a typical enterprise client and/or server.  It's absurdly obscene:

  • Software Management/Helpdesk  Remote Control
  • Patch Management (OS)
  • Asset Management (Inventory)
  • HIDS/HIPS
  • Firewall
  • VPN
  • Anti-Virus
  • Anti-Spyware
  • Anti-Spam
  • Browser Security Plug-ins
  • Encryption (Disk/eMail)
  • 802.1x Supplicants
  • NAC Agents
  • DLP
  • Single Sign-On
  • Forensic Agents
  • Device Control (USB, CD, etc...)

You generally have to manage each of those pieces of software independently.  So while you may not have a separate "appliance" to manage, these things live on your host; they take memory, processor, disk and sometimes step rather rudely on one another.  They represent the most basic premise of software appliances and they each generally have their own administrative console to manage them.

Sunearthmoonmars_2 Granted, we're seeing the same sort of consolidation occur on the software side with "super agent endpoints," but these pieces of bloatware can be worse than stacking individual agents up, one against the other.  Security in width (not in depth) will become our undoing and the benefits of consolidation wear off when you end up with a "single vendor's version of the truth" that ends up being a jack of all trades and a master of none.

To point out the obvious, this is madness.

We all know that what we need is robust protocols, strong mutual authentication, encryption, resilient operating systems and applications that don't suck.

But because we can't wait until the Sun explodes to get this, we need a way for these individual security components to securely communicate and interoperate using a common protocol based upon open standards.

We need to push for an approach to an ecosystem that allows devices that have visibility to our data and the network that interconnects them to tap this messaging bus and either enact a disposition, describe how to, and communicate appropriately when we do so.

We have the technology, we have the ability, we have the need.  Now all we need is the vendor gene pool to get off their duff and work together to get it done.  The only thing preventing this is GREED.

It's a shame it seems we'll have to wait for the Sun to explode for this, too.

/Hoff

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451be3669e200e54eea42f18834

Listed below are links to weblogs that reference We Used to Worry About Security Appliance Sprawl - Now It's Endpoint Security Software Sprawl! :

» Patchlink Changes Name from Jon's Network
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!Patchlink took my advice - sort of. I suggested changing their name to SecureLink after acquiring SecureWave and STAT, but they chose Lumension Security instead. Thei... [Read More]

» Endpoint Master Agent or Interoperability from Jon's Network
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!Because the truth is nobody cares about standards - everyone cares about what you can do with interoperable systems. Amrit wrote recently about The Birth of the Endpoint... [Read More]

» Sophos Roadmap Revealed from Jon's Network
I dont know how I missed this, but the Sophos roadmap predictions I made last week and last year arent a secret, if they arent well known. I snapped a pic of a public demo today to demonstrate: Uploaded with plasqs Skitch!... [Read More]

Comments

My Photo

Disclaimer

  • The views and opinions expressed here are those of Christofer Hoff only and in no way represent the views, positions or opinions - expressed or implied - of my employer or anyone else.

Categories

May 2009

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31