virtualization.info

When VMware announced the VMsafe APIs more than two years ago, virtualization.info praised the effort and suggested that the advent of the technology was the best thing ever happened to the security industry in a long time. It could have been, assuming a solid strategy behind it, and a proper execution.
But more than two years later, it’s safe to say that VMsafe has gone nowhere so far and that the execution of the strategy has been all but flawless.

This may well depend on the incapability of VMware to approach the security world (their ACE product has been a colossal fiasco that still exists only because it’s being super-slowly integrated into Workstation for free), but the company is not the first one to blame for this failure.
Security vendors in fact did nothing so far to secure virtual infrastructures in a proper, more effective and efficient way.
A large-scale, concrete adoption of hardware virtualization platforms can be tracked back to 2006 so, even accepting that security vendors have been careful in approaching the emerging technology, it’s still true that they had four years to do something. Instead, in 2010, top players like McAfee, Symantec, TrendMicro, and a myriad of smaller others, have yet to address the customers need for security in the virtual data centers.
Worse than that, hardware virtualization is facilitating the advent of Infrastructure-as-a-Service (IaaS) cloud computing platforms, where the security challenges are even bigger, and the security vendors above haven’t demonstrated any commitment on these platforms at all.

Considering this, it’s with extreme skepticism that the new partnership between Citrix and McAfee, announced earlier this week at the Synergy 2010 conference (see virtualization.info coverage), should be welcomed.

What has been announced exactly?

The two vendors started a collaboration to deliver new security solutions for virtualization platforms in two phases. The first one, which is taking place now and will turn into a real product later this year, is focused on securing the virtual desktop infrastructures.

The architecture is only apparently similar to the existing ones: to secure the VDI environment, customers are required to install an endpoint security agent inside each guest operating system, which is remotely connected to a centralized management console to operate synchronized scans, malware removals and virus/rootkits/etc. signatures updates on multiple virtual machines at the same time.

The problem with this approach is that the agents are not optimized to run inside such environment, as each of them includes the same scanning and removal engine, and each of these engines runs without any awareness of what the others are doing.
This redundancy implies a waste of physical resources (which ultimately reduces the VMs density per host) and an unnecessary peek in I/O activity every time the agents run a scheduled scan or update their signatures.

McAfee is solving this problem with an endpoint security agent that is optimized to run on virtual infrastructures: Management of Optimized Virtual Environments (MOVE).
It has a lightweight footprint, it pseudo-randomizes some of its activities on the virtual hard drive, but most of all, it doesn’t carry on the scanning and removal engine.
The core activities are in fact executed out of band, in a remote, dedicated virtual appliance.

What this optimized agent really does is copying the suspicious files from the potentially infected virtual desktop to the security virtual appliance, over a secure channel.

Of course McAfee doesn’t want to copy the whole virtual hard drive of each virtual desktop over the network to analyze and clean it, and to avoid so it uses a lot of tricks.

First of all, all the operating system files that match the signature in a whitelist are not copied. There’s no reason to move well-known Windows files that are not modified.
Secondarily, the optimized agent only copies relevant portions of the files that are potentially infected: McAfee knows in which parts of the file the malware could reside, and that’s the only portion of it that will be analyzed out of band.

To be sure that this approach works even with dynamic resource management in place (read XenMotion), McAfee will keep track of the position and state of each virtual desktop in the multi-host virtual infrastructure, directing the suspicious files that need analysis to the nearest security server.

The whole thing will be coordinated by the existing McAfee ePolicy Orchestrator and will support multiple hypervisors (including Microsoft Hyper-V, VMware ESX and of course Citrix XenServer) as long as they are the backend of choice for XenDesktop.

On top of that Citrix will allow other third parties to do the same by releasing a set of open APIs, part of XenDesktop, that other security vendors will be able to leverage.
What Citrix is basically trying to do here, is to reduce the importance of (and the dependency from) hypervisors (and thus of VMware) by moving the functionality gateway to its connection broker.

The second phase of this alliance, which will take place next year, will focus on providing what seems a VMsafe-like interface in XenServer and XenClient.

One the purposes of VMsafe APIs is to allow malware detection, using the hypervisor as a single point of analysis, which permits to eliminate the redundancy of multiple endpoint security agents.
To do so, VMsafe returns a huge, unstructured dump of information about the virtual infrastructure vRAM that security vendors have to decode, trying to figure out where to search for the values that are relevant in malware detection.

The approach of the API that Citrix and McAfee are co-developing is different: their security API will just return information about specific changes in the state of a virtual machine only when they may imply an attack.
It’s not clear yet if the triggers will be defined by the two vendors, by the customers or both.

The platform will also leverage Intel Trusted Execution Technology (TXT) and AMD Secure Virtual Machine (SVM) to verify virtual machine tampering attempts, as virtualization.info already revealed in a previous article about the new XenClient.

The API will even be included back into the Xen code, as a non-GPL but open source code, and thus will end up also in the Xen Cloud Platform (XCP) branch.

Is the Citrix/McAfee approach more efficient and/or secure that VMsafe? It’s too early to say.
McAfee claims that this offloading technique improves VMs density by 181%, moving from 32 virtual desktops per host to 90.

Will this approach be useful also in the world of IaaS cloud computing: not really. We need a new place to describe security requirements there, and that place is around/inside the virtual machine.

Is McAfee really committed to a new generation of security products in the virtual data center? It must be seen, but it’s certainly remarkable that the company agreed to co-develop an open source API that its competitors will be able to use.

Has been right Citrix in selecting McAfee as its technology partner for this ambitions project? We’ll see how comfortable the security vendor is between open source and a very tight relationship with Microsoft (which has huge ambitions in security).