In my post titled "The Four Horsemen Of the Virtualization Apocalypse" I brought to light what I think are some nasty performance, resilience, configuration and capacity planning issues in regards to operationalizing virtualized security within the context of security solutions as virtual appliances/VM's in hosts.
This point was really intended to be discussed outside of the context of virtualizing security in physical switches, and I'll get to that point and what it means in relation to this topic in a later post.
I wanted to reiterate the point I made when describing the fourth horseman, Famine, summarized by what I called "Spinning VM straw into budgetary gold:"
By this point you probably recognize that you're going to be deploying the same old security software/agents to each VM and then adding at least one VA to each physical host, and probably more. Also, you're likely not going to do away with the hardware-based versions of these appliances on the physical networks.
That also means you're going to be adding additional monitoring points on the network and who is going to do that? The network team? The security team? The, gulp, virtual server admin team?
What does this mean? With all this consolidation, you're going to end up spending MORE on security in a virtualized world instead of less.
This is a really important issue because over the last few weeks, I've seen more and more discussions surrounding virtualization TCO and ROI calculations, but most simply do not take these points into consideration.
We talk about virtualization providing cooling, power and administrative cost-avoidance and savings. We hear about operational efficiencies, improved service levels and agility, increased resource utilization and reduced carbon footprint.
That's great, but with all this virtualized and converged functionality now "simplified" into a tab or two in the management console of your favorite virtualization platform provider, the complexity and operational issues related to security have just faded into the background and been thought of as having been absorbed or abstracted away.
I suppose that might point to why many simply think that security ought to be nothing more than a drop-down menu and checkbox because in most virtualization platforms, it is!
When thinking about this, I rationalized the experience and data points against my concern related to security's impact on performance, scale, and resiliency to arrive at what I think explains this behavior:
Most of the virtualization implementations today, regardless of whether they are client, server, production/QA or otherwise, are still internally-facing and internally-located. There are not, based upon my briefings and research, a lot of externally-facing "classically DMZ'd" virtualized production instances.
This means that given the majority lack of segmentation of internal networks (from both a networking and security perspective,) the amount of network security controls in place are few.
Following that logic, one can then assume that short of the existing host-based controls which are put in place with every non-virtualized server install, most people continue this operational practice in their virtualized infrastructure; what they did yesterday is what they do today.
Couple that with the lack of compelling security technologies available for deployment in the virtual hosts, most people have yet to start to implement multiple security virtual appliances on the same host.
Why would people worry about this now? It's not really a problem...now.
When we start to see folks ramp up virtual host-based security solutions to protect against intra-vm threats and vulnerabilities (whether internally or externally-facing) as well as to prevent jail-breaking and leapfrog attacks against the underlying hypervisors, we'll start to see these problems bubble to the surface.
What are your thoughts? Are you thinking about these issues as you plan your virtualization roll-outs?
/Hoff
