virtualization.info

As virtualization.info wrote many times, with VMsafe APIs VMware has the unique chance to shake up the security world.
But as long as VMware has this privileged position in the IT industry to drive innovation across so many market segments, its challenges and responsibilities are much bigger than the ones of many other vendors.

The VMsafe initiative was announced exactly one year ago. In these twelve months the only ones that could really see what can and cannot be done with the new APIs are a restricted number of security partners that VMware recruited.

Now that VMsafe is about to be released as part of the vSphere 4.0 platform, more details emerge and at least a couple of them may raise concerns.

The first concerning point is that the security vendors will not fully unlock the capabilities of VMsafe.

At their first release the APIs allow out-of-band inspection of any resource inside the virtual infrastructure: the virtual memory, storage and networking will be fully exposed to any security product sitting outside the protected guest operating systems.

This would allow the security partners to remove their inspection/remediation agents from inside the virtual machines, saving precious resources, preventing any attack that tries to disable them, and granting a 360 degrees vision of where/how the malware is spreading inside the virtual data center.

Unfortunately this is not what the security vendors will do once the VMsafe interface will be public.

As they are developed today, the APIs will provide a huge amount of unstructured data, which basically is the dump of the virtual memory, virtual networking or virtual storage.

Inside this big chunk of information the security vendors don’t have too many problems in finding out the signature of a well-known malware, but they certainly have serious issues in identifying, for instance, the file system structures and the files where the malware is hidden.

For this reason none of the VMware partners will really use VMsafe to remove the malware.
The APIs will be used only for detection while customers will have to install agents as usual to remove any malicious code inside the guest operating systems.
And of course this implies that any attack vector can still try to disable the protections and spread around before it’s fully neutralized.

So before we’ll see a real out-of-band security infrastructure inside our virtual data center some more time will have to pass.

The second concerning point is that not every security vendor will have access to the VMsafe APIs.

At a point in time after the VMsafe GA, VMware will disclose the APIs to the general public, but it will continue to give the execution key only to recognized security vendors.

Right now and for the time to come VMware accepts new VMsafe partners only after they submit some detailed documentation about the vendor identity and its plans to use the APIs.
The review process doesn’t involve money but cannot be skipped.

The company says that this is done to avoid that any untrusted entity can access the interface and develop a new class of attack tools but this basically means that VMware is in control of who can and cannot access its interfaces.

This has some dangerous implications:

• the credibility that the biggest vendors have grants them a competitive advantage over any other firm in the security space, as they can access the APIs before anybody else
• a stealth startup that is trying to protect its innovation before the official launch has no chances to access the VMsafe code unless it discloses its plans
• VMware may directly or indirectly influence the security market slowing down its review process for some applicants

and so on.

If VMsafe will become relevant in the security industry then VMware may be obliged to seriously reconsider this approach.