That did indeed make it a bit clearer for for me personally and yes, I think we are shooting for the same thing but just using some differing terms / definitions. As Dwayne already alluded to,. when I am thinking of the Hypervisor I am really thinking of it in more of a ‘general’ sense as simply a logical point of central control for ensuring that virtual servers, appliances, etc have the required security, access controls (patch levels too maybe?) in place before they are allowed to go completely online.

This could be accomplished at the application layer as well I imagine (Virtual Center, Systems Center, etc) just fine.. but there are those folks that don’t (or can’t) invest in that level of infrastructure and have to just get by with the basic Hypervisor functionality hence why I am a proponent of that as well.

I like what you are saying around your vNAC initiative and I apologize that I am not more familiar with it.. I am in the process of finding out more about it right now. Any links, posts, etc that you could supply would be appreciated.

-Derek

So I should really revise my comment regarding security as delivered by the “hypervisor” because I re-read it and noticed I painted it incorrectly — or at least too coarsely. From a comment I made on my blog:

>> In short, it’s a balance. I really liken the problem to squeezing a balloon —
>> security being the balloon. Regardless of where security exists, it’s really the
>> same problem to solve. you squeeze it in the middle and the air pops out either
>> end… ;)

>> Here’s what I want:

>> 1) I want a secure-as-possible, thin VMM that offers up API’s to allow secured
>> access at various levels of control to certain functions provided by the
>> virtualization layer by third party software. This would provide access to not only
>> control functions like fw, ips, etc., but also management apps and detective
>> functions.

>> 2) I want certain features within the VMM itself to provide functionality —
>> capitalizing on the architectural benefits of virtualization — that aren’t available
>> in the guest OS’s themselves. The memory firewalling/anti-malware stuff we’ve
>> been teased with would be nice.

>> Basically it’s the argument I had with Simon (Crosby). I’m not suggesting that the
>> virtualization platform providers end up as the end-all, be-all of security in the
>> virtualized world, but they ought to give me the flexibility and resiliency options
>> to potentially live up to all those claims of virtualized environments being “more
>> secure” than their physical counterparts…

In my VirtSec preso’s I deliver a run-through of the deployment methodologies and technologies available today through the next couple of years (forecasted.) All of the things alluded to in Gartner’s preso I cover — and more…along with the actual downsides of each of them, which are also important.

As to your point about being “off base,” I think we’re really agreeing we want the same things, we’re just not synched on where/how and that may be a point of semantics.

vNAC is really just a way of opening up the policy definition, validation and enforcement capabilities of the virtualization platform providers to allow third parties to do what they do today for clients using NAC and apply the same methodologies to VM’s before they spin up and connect to the “network.”

Some of that can be enabled by abastracting capabilities of the hypervisor, but don’t actually have to be performed by it directly (hence the birth of VMsafe…)

Don’t know if that made it any clearer ;)

/Hoff

As for what Derek mentions, it seems like having some capability at the “hypervisor” layer would allow you to “inject” security tools, settings, etc. into new VM’s more easily. Am I off base?

And I’m not really talking about simply tying into VMsafe, since that’s a bit lower level (though it could help with the policy-based approach you’d enable with vNAC). I’m more talking about using the “hypervisor” as a control point – maybe working hand-in-hand with vNAC – to actively keep configurations within policy.

Just a quick question: Why do you suggest that in order to provide “VM-spanning” (not a new concept by any stretch, btw) you’d need to do it at the “hypervisor” layer?

You could do it much more simply by providing a binding affinity between VM ID and policies at the configuration level as managed by any of the central management functions.

When a VM begins to spin up and (in the case of VMware) registers with VirtualCenter, it has a unique VM ID. That VM ID is linked to a set of policies that stipulate what controls and configuration requirements are necessary before connecting outside of a “quarantined” vSwitch port group. Once the VM passes the policy checks (such as those offered by your nifty tool) it can connect to the “network” and finish spin-up.

This is the concept behind my vNAC proposal.

This is where I agree with Crosby inasmuch as some security functions need not be delivered as a function of the “hypervisor” — in fact you can support heterogeneous VM’s regardless of which “hypervisor” you deploy…

/Hoff