A Chilling Bedtime Story About Anti-X Storms

As more and more infrastructure becomes virtualized, the migration to endpoint solutions that are optimized for virtual environments will become increasingly important.  Any security professional will absolutely agree that endpoint is one of the most effective ways to keep corporate assets clean of malware and other fun stuff that is trying to take down your network and retrieve your mission critical data.  However, traditional endpoint really doesn’t work in virtual environments as-is.  Why?  Oh, let me explain this favorite topic of mine.

Traditional Endpoint on a virtual server looks like this:

What you’re looking at is the logical way that someone would put endpoint on a virtual server to protect the individual VMs.  It’s absolutely, without doubt, the most common way to do it.  What happens is that the endpoint program gets installed into every single VM.  The above example is obviously simplified…you could have dozens of VMs on a single hypervisor.  And let’s say that in idle mode (i.e. non-scanning mode) it takes 2% of system resources per instance.  So, across 4 VMs (in the example above) we see 8% off the top in idle mode.  But, what if we are doing a scheduled scan, where it takes 20% of system resources?  Well, times that by the 4 VMs, and you have 80% of system resources.  If that doesn’t start to make your heart rate rise, remember, this is simplified; we could have dozens of VMs running on a single hypervisor.  Even if it’s only 10% of system resources per instance, a scheduled scan would probably cripple the infrastructure, if not take it down completely.

So when the security guys insist on installing endpoint in this model (which again, very logical way to approach it, but oh so destructive from a resource effectiveness standpoint), one of two things will happen:

1)      The infrastructure guys running the VMs say “sure thing boss” and no endpoint will ever touch their servers.  You’d be surprised how often this occurs.

2)      The infrastructure guys say “you know what? I agree, endpoint is such a wonderful thing,” (I like to pretend that is what they say) “but, we need to utilize endpoint that is actually designed for virtual environments.”  I wish this happened more often.

So, what does virtualization-optimized endpoint look like?  It’s really quite brilliant:

As you can see, there is only one red box per hypervisor (no matter how big you scale this model).  What happens is that the endpoint plugs into your management console, and essentially cross-pollinates the server with anti-x goodness.  If we go back to our last model and say that in idle mode, it takes 2% of resources, well, that is all it will take across the board.  Not (# of VMs) x (2%).  And when a scheduled scan takes place, it is only ONE performance hit across the entire hypervisor.  So 20% (in our example) versus crippling death to the infrastructure.  Pretty smart huh?

And these wonderful technologies do exist right now.  VMware, Trend Micro, Symantec, most of the traditional endpoint guys have it.  The key thing to ask if you are using a virtualized environment, such as VMware, is that it plugs into the hypervisor through APIs (application performance interface)  such as VMWare’s vShield APIs, Xen-API for Xen environments and Google APIs.  If it’s not optimized for virtual environments, or doesn’t scale to the extent you need, it’s going to cause problems down the road as you expand your virtualization projects.  But if you get the right solution, it will make the relationship between your security and infrastructure people all that much smoother.

2 thoughts on “A Chilling Bedtime Story About Anti-X Storms

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s