Goingon
goingon
Join GoingOn to activate this toolbar and see your photo here!
It's Free!
Search
Guest
loginSign Me Up
Who's Online
GoingOn
Not a AlwaysOn member? Register Now! Sign-In Now!
Greg Ness

Earlier this week I spoke at a database security event about the inevitable virtsec architectural shift from (layer 4) core deep packet inspection to application protocol context (layer 7). A few hours after my preso a netsec vendor presented a virtsec vision of agents/sensors deployed at numerous key checkpoints across a virtualized infrastructure. It was indeed a beautiful slide. One of the attendees asked if the architecture was layer 7 and he replied “yes, deep packet inspection, layers 1-7, we do everything.”

 

Rather than single out a particular vendor, let me describe what I see taking place in coming months/years for the network IPS space. Those first generation IPS deep packet architectures charged with inspecting ALL traffic passing through them (and warning of suspicions and terminating sessions based on qualified suspicions) will have to really scramble to keep up with the demands of server and VM security. Doing everything, as the vendor claimed, is enigmatic when your core deep packet architecture is based on pattern matching. There are at least two fundamental problems, from which many others spring.

 

The first problem is driven by a fundamental requirement for any core pattern recognition system: accuracy and reliability depend upon stability. A suspicious attack needs to stay suspicious. And past suspicious attacks need to represent most of the future suspicious attacks. Mutation/change when it comes to attacks means an increasing likelihood of obfuscation and evasion for pattern matching architectures.

 

Yet exploits are now mutating at a fast pace; some can even mutate in the midst of an attack. Mutation accelerates the obsolescence of static pattern recognition.   I talked about this in Attack of the Mutant Bots months ago at Always On.

 

The second problem with exploit pattern recognition is that it can become resource-intensive. All traffic (“everything” as the vendor commented) passing through an appliance (or checkpoint) is inspected. As more patterns (and permutations) are added more processing is required to keep up. Now imagine that deep packet inspection IPS deployed via scattered agents at an array of key checkpoints between VLANS, hypervisors and servers in a partially virtualized data center.  Larger and larger libraries are pattern matched in multiple checkpoints against all traffic pulsing back and forth through meshes of VMs and servers.

 


Rhetorical Questions Worth Asking


Exactly how many processor cycles will be needed to operate these scattered full traffic inspection points? How much latency will be produced at how many concomitant places? How many false alarms will ripple through these multiple points and create more noise and confusion? How many sensors will be required between each zone (or fuzzy perimeter) to keep each isolated to its own level of security?

 

This “chokepoint architecture” is a substantial barrier to both the accrual of the benefits of virtualization (movement, flexibility, mutation, utilization, etc) and the effective protection of the data center. It will force Draconian tradeoffs of a massive scale relative to the single point tuning at the outer perimeter, where firewalls function well to limit access to particular ports and segments. 



>>Deep packet inspection within the server or VM mesh means mushrooming processing and security management requirements in a scenario now having to inspect and track mutation inside AND outside multiple new fuzzy perimeters. <<

 

Deep packet-centric inspection intrusion prevention, for this reason, is the enemy of VMware and every vendor betting on the fast adoption of virtualization in the data center. The Draconian tradeoff of the pattern match requirement in a fluid environment is, however, the best friend of an appliance-centric old guard that has monetized specialized hardware and security as a service (complexity equals revenue) models that understands the impact of virtsec on their business models.   I see a similar “when do you virtualize” struggle about to take place between the vendors of commodity and specialized processors. 

 

Everyone agrees that virtualization of the data center is inevitable. The question is when. And the answer to that question will have a substantial impact on market caps across many appliance categories in levels that we perhaps haven’t seen for awhile. 

 

That is why VMsafe at Cannes drew such a reaction. It is a declaration of war on a tired status quo that has produced minimal innovation in recent years (especially relative to the black hats/malicious hackers). It is security’s next big hope or failure, on multiple fronts; and as VMware plans next steps the enemies of virtualization will naturally assemble armies of experts, pundits and partners in defense of a past that is already dying. They will do their best to distract the market with rumors of hypervisor attacks and ongoing risk debates, until they are ready to take the plunge.

 

That is why one blog’s recent description of virtsec as a defibrillator for the security industry resonated soon after VMworld.

 

I also think that it is inevitable that the network intrusion prevention space will bifurcate into packet inspection at the perimeter (integration into exploit-centric next generation firewalls) and advanced layer 7 server IPS systems (in front of servers, databases and VMs) that are more accurate, use less processor cycles and can protect systems without heightened availability risks, latency and detection obfuscation headaches.

 

Now that VMware has crossed the Rubicon and put the data center on notice, every deep packet-centric network IPS architecture (with or without some layer 7 add-ons) will face a choice of where to go (outer or inner perimeter), and it will make all the difference.  For more thoughts on netsec, virtsec and virtualization go to www.archimedius.net.

 

============================================= 

Disclosure: I’m the VP Marketing for Blue Lane Technologies, a winner of the 2007 InfoWorld Technology of the Year for security, Best of Interop 2007 in security and the AO 100 Top Private Company award for 2006 and 2007. Blue Lane is also a 2007 Best of VMworld Finalist in data protection. I’ve been a marketing executive at Juniper Networks, Redline Networks, IntruVert Networks and ShoreTel. I’ve been an Always On blogger/columnist since 2004. My recently launched personal blog is: www.archimedius.net . These are all my opinions, and do not represent the opinions of employers, spouses, kids, etc.
Current Rating : StarStarStarStarStar (2 votes)
Posted by Greg Ness at Mar 13, 08 01:33 PM | Permalink
Technorati this!del.icio.us this!digg this!StumbleUpon ToolbarShare on FacebookEmail this!
Printable View | Comments (5) | Trackbacks (0) | Views : 4483
Become an AlwaysOn Insider

To post a comment, become an AlwaysOn member by filling in the fields below - It's free!

  • Captcha Image: you will need to recognize the text in it.
  • Comment
Stan_Weitzman
About two years ago I was raising money for an Enterprise Security Software start-up. We were looking at inspecting layers 1-3 and maybe 4. However, from the description in the article it sounds like VMWare is using Bayesian statistics to predict behavior. That was our plan as well. But we had an advantage.

We were using the S-Flow MIB to mirror the incoming packets which theoretically did not slow the network down other than for the samples being sent to the security engine. Other technologies like C-Flow won’t permit monitoring of each port. I suspect VMware is counting on using the resident CPU’s to do the deep packet inspection. I’d like to hear from them

The idea of using a VMware virtual machine environment is to get 60% to 80% or even 90% utilization out of each CPU and then create an additional virtual machine on the next CPU. How can you do this if you are probably using over half of your CPU cycles for security?

Saying you are going to inspect every packet in layers 1-4 and the application layer is akin to getting a freighter full of coffee beans and inspecting each bean at the port.

We have learned that statistical analysis will do an adequate job. Is it five nines? Probably not, but it still works by checking each layer perhaps five percent of the time.
Stan_Weitzman – March 14, 2008 05:55 PM
Benoit_Couture
Here is a link to thoughts and letters, writen amongst Value Network people, related to Armageddon and IT's potential to move humanity from self-destruction to self-control and community self-government:
http://www.bbc.co.uk/dna/h2g2/classic/A22477250
The larest entrey was:

""The nature of collectivist says: "It takes the village to raise a child". The nature of individualist says: "Who am I? I need to know!" The nature of knowledge says: "The culture of interdependence in serenity is the health of mutuality between the village and who we each are!"

"Currently, we are at a junction of history when the incompatibilities of the past collectivist ruling units, such as the various war machines and their specific contexts, are resisting the individualism that has taken on a corporate shape, and goes on acting as individuals, competing for survival in an unsustainable village. For both, the individual and the village, the genuine paradigm shift comes from discovering the passage from competing to completing, just like the village needs to do with great dedication when the child becomes a teen, in making room for the teen's deployment in the community."

"Failing to do so keeps the teen from getting to know who she/he is, therefore keeping her/him to take her/his place in the smooth running of the village. Our Western modern society is made of several generations in which the villages have been built to satisfy corporate individualism, supporting competition and forgetting about completion. As a result, the corporate agenda finds itself having to re-invent the wheel of life with artificial intelligence, leaving behind the cultivation needed for the village and the individual's continuity into maturing."

"The vacuum that this is creating is digging a groove which will collapse under the weight of indifference and ignorance merging in reply to injustice, as we see throughout human history. When the collapse becomes inevitable, all the war machines will be forced to merge into the corporate agenda, putting in place the artificial mechanisms to keep the masses of villages from interfering with the powers that be, who never had time to adjust to the assembling of going from competing to completing, but who suddenly, will have to behave according to the teens' uprise against the village."

"Instead of witnessing the beauty of a paradigm shift in serenity, the entity of terror-anti-terror is moving globalization with the forces of extreme tensions, which forces the governance of paradox rule upon humanity. The village and the teens have to learn quickly (and not in a hurry, so as to defeat the stress of extreme tensions), how to fill the vacuum with all that's been denied to get to the top by competing, as opposed to completing."

"My prayer and hope is to see 2.0 to serve the coming of 3.0 in the release of serenity between the village and the child - amen to God's Yes in us all..."

Benoit Couture
Benoit_Couture – March 15, 2008 01:14 AM
Greg Ness
Thanks for your thoughtful comment. A lot can be done from a layer seven architecture, including selectively adding layer 4 rules/policies for enforcement/access/partitioning.

The challenge in migrating upstack from a layer 4 starting point is substantial. A typical pattern match architecture already absorbs plenty of processing power now tracking fuzzy, fluctuating exploits. Add to that the challenge of fully comprehending hundreds of protocols flowing between dozens of applications, operating systems and databases with thousands of known vulnerabilities now in a mesh of servers and mobile, mutating VMs.

The best layer 4 IPS (deep packet) system I've seen has some layer seven protection, most around a subset of MSFT server vulnerabilities. Protection isn't comprehensive for MSFT servers, but its better than protection for UNix/Linux, Oracle etc. Thats probably the best. Without comprehensive layer 7 protection (based on full knowledge of protocols AND vulnerabilities) there will be unneeded exposure.

Bottom line- the deep packet architectures already reeling with accuracy, tuning and processing/throughput challenges at the perimeter will have bigger problems protecting meshes of physical and virtual servers.

Hope that makes sense.

Greg
Greg Ness – March 17, 2008 09:54 AM
Danny_Lieberman
The rhetorical questions are all excellent points - but you've missed a much more fundamental issue. Deep packet inspection is broken today - even without virtualization, morphing of attacks and massive quantities of false positives generated by simple keyword matching.

The fact is - you can do very little with a packet - neither with intrusion prevention nor with extrusion prevention.

You need to examine at the application session level - not the packet level. Since an attack spans an entire session by definition, and since a session will be composed of a number of packets - the security appliance must perform session reassembly.

This is especially true regarding extrusion prevention where simple keyword patching in MS Office files is basically worthless.

Best regards
Danny Lieberman
Danny_Lieberman – April 5, 2008 11:24 PM
Greg Ness
You have teed up my next blog related to where netsec goes from here... with increasing perimeter evasion, more servers and databases facing the public network and the beginning of the end of deep packet as core IPS architecture. I hope to post before RSA or soon after.

Thanks,
Greg
Greg Ness – April 6, 2008 01:39 AM
 
Latest News/Opinion
Author Jonathan_Handel
05.08.08 @ 10:14
Author AO
05.08.08 @ 08:26
Author CNET
05.07.08 @ 22:16
Author joshkopelman
05.07.08 @ 16:15
Author bradfeld
05.07.08 @ 16:08
OnDemand
Author Phil Wainewright
05.08.08 @ 08:05
Author Phil Wainewright
05.07.08 @ 07:18
Author Phil Wainewright
05.06.08 @ 15:41
Author Phil Wainewright
05.02.08 @ 11:09
Author pooh@poetic.com (Anders Bylund)
05.07.08 @ 18:33
Author ars@chrisforesman.com (Chris Foresman)
05.07.08 @ 10:13
OnMedia
05.08.08 @ 12:19
Author Phil Wainewright
05.08.08 @ 08:05
Author Phil Wainewright
05.07.08 @ 07:18
Author Phil Wainewright
05.06.08 @ 15:41
Calendar
«May 2008»
MTuWThFSaSu
1234
567891011
12131415161718
19202122232425
262728293031