Virtualized Security: an Oxymoron

Virtualization technology has been making its way into IT departments for years. It started in the datacenter as a means to consolidate servers and has seen increasing viability in an appliance form factor (virtual appliance). Simply, an appliance software solution has everything in one integrated bundle needed to accomplish a singular function.

So the OS, database, web server and application logic are all integrated and cannot be split part for other uses (this is a quick and simplistic explanation). You have virtual appliances made using virtualization technology, hardware appliances that integrate software with the hardware, and software appliances that load on bare bones servers.

The one area virtual appliances have not made much headway is in network security. Network security is still dominated by hardware appliances which today offer superior performance, scalability and function. However, many vendors are starting to tout current or soon to be available virtual appliances for security.

Hmmm. Security that is virtualized… which means it’s not really there. Makes one pause for a moment and wonder if this is a good thing or should “buyer beware.” To make sure my views aren’t biased I visited the blog of Chris Hoff, currently Director of Cloud and Virtualization Solutions, Data Center Solutions at Cisco System, and a security industry honcho.

His views seem to mirror what I’ve found in working with companies in both the security and the appliance solution space. Here are some issues per Chris Hoff:

  • Most of the virtual network appliances, especially those “ported” from the versions that usually run on dedicated physical hardware (COTS or proprietary) do not provide feature, performance, scale or high-availability parity; most are hobbled or require per-platform customization or re-engineering in order to function
  • The resilience and high availability options from today’s off-the-shelf virtual connectivity does not pair well with the mobility and dynamism of de-coupled virtual machines; VMs are ultimately temporal and networks don’t like topological instability due to key components moving or disappearing
  • The performance and scale of virtual appliances still suffer when competing for I/O and resources on the same physical hosts as the guests they attempt to protect
  • Virtual connectivity is generally a function of the VMM (virtual machine manager) (or a loadable module/domain therein.) The architecture of the VMM has dramatic impact upon the architecture of the software designed to provide the connectivity and vice versa.
  • Security solutions are incredibly topology sensitive. Given the scenario in #1 when a VM moves or is distributed across the pooled infrastructure, unless the security capabilities are already present on the physical host or the connectivity and security layers share a control plane (or at least can exchange telemetry,) things will simply break .
  • Many virtualization platforms do not support protocols or topologies that many connectivity and security virtual appliances require to function (such as multicast for load balancing)
  • It’s very difficult to mimic the in-line path requirements in virtual networking environments that would otherwise force traffic passing through the connectivity layers (layers 2 through 7) up through various policy-driven security layers (virtual appliances)
  • There is no common methodology to express what security requirements the connectivity fabrics should ensure are available prior to allowing a VM (virtual machine) to spool up let alone move
  • Much of the basic networking capabilities are being pushed lower into silicon (into the CPUs themselves) which makes virtual appliances even further removed from the guts that enable them

What does this mean?  If you want real security in an appliance form factor, you can’t beat a hardware appliance. At least not today.