virtualization.info

As virtualization.info reported many times in the last couple of years, the current effort to bring security into the virtual infrastructure leaves much to desire.

The best thing that new and consolidated security vendors can do at the moment is:

1. moving traditional tools like firewalls, IDS, anti-virus and so on into virtual machines
2. ask the virtual infrastructure administrator to reconfigure the virtual network so that virtual traffic pass through or pass by the virtualized security tools above
3. offer support for this uncommon new deployment

and all of them are bad things:

#1 is highly inefficient because the admin has to deploy multiple copies of the same tool (it depends on the virtual networking actually, but think about the anti-virus agent in a VDI environment as the worst case) when he could just deploy one that monitors the entire virtual infrastructure at the hypervisor level. And this wastes physical resources big time.

Unfortunately, until VMware releases its VMsafe APIs (and other vendors follow the trend), there’s not much that can be done.

#2 is highly constraining because it breaks the premise of mobility that virtualization brings. As soon as the administrator invokes a live migration for the protected virtual machine, the virtual networking is messed up and the virtualized security tool could be cut out of the game.

VMware is working to mitigate this issue and VI 4.0 will introduce a thing called vNetwork Distributed Switch, preserving the same virtual network configuration even during a live migration.
The technology is interesting but it certainly is just a partial solution of the problem.

#3 is highly unreliable because no matter how committed the vendor is, it will never be able to forecast how many virtual machines are running at the same time on the same virtualization host, and how this will impact on the performance of its virtualized product.

The just released OVF standard allows to define specific characteristics for each virtual machine through a metadata layer, including service level agreements (SLAs), but we are far away from mainstream adoption.

A possible solution (not fully detailed) could be:

• wrapping each virtual machine in a security layer (something that products like VMware ACE, Kidaro Workspaces and Sentillion vThere already do since a while) where the administrator define a specific security policy
• having an independent tier (the virtualization management layer doesn’t seem a good candidate) that acts as security coordinator, reading the policy requirements for each VM security wrapper and querying the hypervisor to see if it has any security product connected that can satisfy the requirements
• having multiple security products that plug into the hypervisor and wait for the a call to action solicited by the security coordinator

Now Altor Networks has just announced what they call Virtual Firewall, which on paper seems to introduce part of the architecture above.

Unfortunately a careful analysis of the most technical brochure available online raises some doubts:

…The Altor VF installs as a virtual appliance on each virtualization host and inspects all traffic to and from each VM guest. Admins use a web-based management console to define and centrally manage traditional firewall rules: allowed and rejected sources, destinations, and protocols; actions to take; etc. Rules can apply to all VMs, a group of VMs with similar connectivity and security needs (such as web servers), or a single VM. Policies built with these rules can also be enforced at the global, group, and per-VM levels…

It really seems that this product, just like any other, requires virtual network reconfiguration (it doesn’t matter if the process is automated by a helpful setup that interacts with VirtualCenter) and that it simply replicates the security policy from one virtual appliance deployed into a virtualization host to another, deployed into a second virtualization host.
In this way the company can claim that virtual machines are protected even during live migrations:

The virtual firewall is “attached” to a VM at all times and travels with it during a VMotion event. This assures continuous security policy enforcement before, during, and after every live migration. Just as importantly, the Altor solution maintains the connected states of all applications within the migrating VM.

Has Altor Networks really found a way to create a security wrapper around ESX virtual machines?