Rational Survivability

On the tail of my posts from a week or so ago regarding to Cisco’s Data Center 3.0 announcement, Mr. Chamber’s keynote at VMWorld and the follow-on $150Million investment in VMware, here’s something that really gets my goose honking because the force is strong with this one…

Virtualization.info broke the news last week that VMware will "…allow 3rd party vendors to develop their virtual
switches for ESX Server virtual network, and Cisco is expected to be
the first company announcing such product (Virtual Catalyst?)"

This may sound like a no-brain yawner, but it’s quite profound…not just for Cisco, but for any of the switch vendors who want in on the lucrative virtualization market.

For a quick refresher, let’s review the concept of virtual switches (vSwitches).  From VMware’s definition:

A virtual switch, vSwitch,
works much like a physical Ethernet switch. It detects which virtual
machines are logically connected to each of its virtual ports and uses
that information to forward traffic to the correct virtual machines. A
vSwitch can be connected to physical switches using physical Ethernet
adapters, also referred to as uplink adapters, to join virtual networks
with physical networks. This type of connection is similar to
connecting physical switches together to create a larger network. Even
though a vSwitch works much like a physical switch, it does not have
some of the advanced functionality of a physical switch. For more
information on vSwitches, see Virtual Switches.

Given my previous posts on the matter, this offers two interesting and profound perspectives on the virtualization front:

1. If you recall, I blogged back in February about my participation in a Goldman Sachs Security conference where Jayshree Ullal presented Cisco’s vision of virtualized security.  During the Q&A period after her presentation, I asked her a somewhat loaded question that went something like this:

   
   If now we see the consolidation of multiple OS and applications on a
   single VM host in which the bulk of traffic and data interchange is
   between the VM’s themselves and utilize the virtual switching fabrics (ed: software)
   in the VM Host and never hit the actual physical network
   infrastructure, where, exactly, does this leave the self-defending
   "network" without VM-level security functionality at the "micro
   perimeters" of the VM’s?

   I think that this announcement pretty much answers this question.  Cisco will take the concept that I blogged about previously wherein they will abstract the software from the hardware and provide a virtualized version of a catalyst as the ESX vSwitch.  I wager we will see a subset of security functionality in the vSwitch natively that one might expect in the "physical" Catalyst hardware products as much of the capabilities still hinge on new components such as the ACE.

   Now, if the virtual switch is Cisco’s, you can expect a bevy of interaction between the "virtual switch(es)" and the physical ones that the VM Hosts connect to.  This would provide interfaces between all manner of network controls and monitoring capacities such as firewalls, IDS, IPS, SEIM, and solve the issue above by merely "offloading" this functionality via API’s to the physical boxes plumbed into the network.

   Combine that with NAC agents on the hosts and…whether or not it actually works is neither here nor there.  They told they story and here it is.  It’s good to be king.

2. This brings us to point numero dos…and it’s a doozy.  If you think that the current crop of L2/L3 switching and routing infrastructure is fragile enough, just imagine how much fun it’s going to be trying to detect and defend against infrastructure attacks on virtual switches that open up the guts of the VM hosts and hypervisors to third parties.

   We won’t need a Blue Pill, I’ll take one of these below, instead (it’s a cyanide capsule, btw):

   
   Ettercap and arp-twiddling, anyone?  If you don’t have the capability to virtualize the functional equivalent of IDS taps and/or utilize "IPS" plugins to the hypervisors, compromising a single guestOS on a VM could spell disaster that goes undetected.  We already have issues protecting physically isolated critical infrastructure, can you imagine how much fun this is going to be? 

   I’m not talking about application layer attacks here, I’m talking layer 2/layer 3.  The vicious circle begins anew.  You’ll be worrying about XSS and AJAX attacks on your virtualized web servers whilst the same attacks from 10 years ago will give your shiny new virtual infrastructure a wedgie.

   And since it’s likely we’ll see a repeat of architectural car crashes as we have in the past, most of the inter-VM traffic won’t be mutually authenticated or encrypted, either.  So you’ve got that going for you…

So, I think that this model is what Reflex was aiming for with their vIPS (from Virtual Iron) software for the virtual switch which I blogged about here, but Cisco’s going to one-up them because of their investment in VMware, their switching acumen and the unfair advantage of owning both the virtual/logical switching/routing plane as well as the physical.

Good times are comin’, for sure.  I’m trying not to be cynical.  I think it’s fairly obvious as to what ought to be done to secure this mess before it becomes one, but I’m not sure we’re going to be able to step out in front of this train and stop it before it reaches the station.

/Hoff