VMware’s VMsafe: The Good, the Bad, the Bubbly…
Back in August before VMworld 2007, I wrote about the notion that given Cisco’s investment in VMware, we’d soon see the ability for third parties to substitute their own virtual switches for VMware’s.
Further, I discussed the news that VMware began to circulate regarding their release of an API originally called Vsafe that promised to allow third party security and networking applications to interact with functions exposed by the Hypervisor.
Both of these points really put some interesting wrinkles — both positive and potentially negative — in how virtualization (and not just VMware’s) will continue to evolve as the security and networking functions evolve along with it.
What a difference a consonant makes…
Several months later, they’ve added the consonant ‘m’ to the branding and VMsafe is born. Sort of. However, it’s become more than ‘just’ an API. Let’s take a look at what I mean.
What exactly is VMsafe? Well, it’s a marketing and partnership platform, a business development lever, an architecture, a technology that provides an API and state of mind:
VMsafe is a new program that leverages the properties of VMware Infrastructure to protect machines in ways previously not possible with physical machines. VMsafe provides a new security architecture for virtualized environments and an application program interface (API)-sharing program to enable partners to develop security products for virtualized environments.
What it also provides is a way to make many existing older and consolidating security technologies relevant in the virtualized world given that today their value is suspect in the long term without it:
The VMsafe Security Architecture provides an open approach that gives security vendors the ability to leverage the inherent properties of virtualization in their security offerings.
Customers running their businesses on VMware Infrastructure will be assured that they are getting the best protection available – even better than what they have on physical infrastructure.
VMsafe adds a new layer of defense that complements existing physical security solutions such as network and host protection, shielding virtual machines from a variety of network, host and applications threats. This additional layer of protection can help enterprise organizations to dramatically increase the security posture of their IT environments.
There is then hope that a good deal of the visibility we lost in the limited exposure existing security solutions have across virtualized environments, we may get back.
Of course, this good news will be limited to those running VMware’s solutions and re-tooled versions of your favorite security vendor’s software. What that means for other virtualization platforms is a little more suspect. Since it requires the third party software to be re-written/adapted to use the VMsafe API, I can’t see many jumping on the wagon to support 3-4 VMM platforms.
Ack! This is why we need a virtualization standard like OVF and a cross-platform signaling, telemetry and control plane definition!
So how does VMsafe work?
VMsafe enables third-party security products to gain the same visibility as the hypervisor into the operation of a virtual machine to identify and eliminate malware, such as viruses, trojans and key-loggers. For instance, security vendors can leverage VMsafe to detect and eliminate malware that is undetectable on physical machines. This advanced protection is achieved through fine-grained visibility into the virtual hardware resources of memory, CPU, disk and I/O systems of the virtual machine that can be used to monitor every aspect of the execution of the system and stop malware before it can execute on a machine to steal data.
…
VSAFE enables partners to build a virtualization-aware security solution in the form of a security virtual machine that can access, correlate and modify information based on the following virtual hardware:
- Memory and CPU: VMsafe provides introspection of guest VM memory pages and cpu states.
- Networking: Network packet-filtering for both in-hypervisor and within a Security VM.
- Process execution (guest handling): in-guest, in-process APIs that enable complete monitoring and control of process execution.
- Storage: Virtual machine disk files (VMDK) can be mounted, manipulated and modified as they persist on storage devices.
So where do we go from here?
With nothing more than a press release and some flashy demos, it’s a little early to opine on the extensibility of VMsafe, but I am encouraged by the fact that we will have some more tools in the arsenal, even if they are, in essence, re-branded versions of many that we already have.
However, engineering better isolation combined with brokered visibility and specific authorized/controlled access to the VMM is both a worthy endeavor that yields all sorts of opportunities, but given my original ramblings, makes me a bit nervous.
Alessandro from the virtualization.info blog gave us a description of the demo given at VMworld Europe that illustrates some of this new isolation and anti-malware capability:
A Windows XP virtual machine gets attacked with a malicious code that
copies away corporate documents but another virtual machine with
security engine is able to transparently recognize (a virtual memory
scan through VMsafe APis access) the threat and stop it before it
compromises the guest OS.
Steps in the right direction, for sure. Since details regarding the full extent of anti-malware capabilities are still forthcoming, I will reserve judgment until I get to speak with Nand @ VMware to fully understand the scope of the capabilities.
I am sure we will see more claims surface soon suggesting with technology such as this will produce virtualized environments that are "more secure" than their non-virtualized counterparts. The proof is in the pudding, as they say. At this point, what we have is a very tantalizing recipe.
I’d suggest we’ll also see a fresh batch of rootkit discussions popping up soon…I’d really like to see the documentation surrounding the API. I wonder how much it costs to sign up and be authorized to participate with VMsafe?
Some of the Determina functionality is for sure making its way into VMsafe and it will be really interesting to see who will be first first out of the gate to commercially offer solutions that will utilize VMsafe once it’s available — and it’s a little unclear when that will be.
Given who demoed at VMworld Europe, I’d say it’s safe to bet that McAfee will be one of the first along with some of the more agile startups that might find it easier to include in their products. The initial lineup of vendor support makes up some of the who’s-who in the security space — all except for, um, Cisco. Also, where the heck is SourceFire?
When do the NAC and DLP vendors start knocking?
More detailed analysis soon.
/Hoff
Mendel Rosenblum talked about some of this stuff several years ago at VMWorld. i.e. the ability to have something in the hypervisor or hooks in the hypervisor.
I wonder if they will provide a mechanism to authenticate the outside services somehow to prevent spoofed access.
@Raffi: This is ideally what the TPM would be used for.
One of the things I hope to talk to Nand about is really pushing for TPM integration; the challenge will be that much of the current compute architecture doesn't contain a TPM.
Until then, I suspect we'll see brokered auth/crypto using TLS?
/Hoff
VMsafe reactions: revolutionary, tantalizing, exciting, the right thing
More reactions about the VMsafe program introduced at Wednesday's VMworld Europe keynote. The reactions are good, especially considering most people haven't seen the actual technology yet. I think everyone is very conscious that opening up access to th…
Hoff is Still Confused
Chris Hoff is generally right as rain when he rants about technology, but hes still wrong on my