Skip to content ↓ | Skip to navigation ↓

I was just reading an article by Ted Julian talking about what he thought was a real highlight at Gartner’s IT Security Summit; Neil MacDonald’s presentation titled “Radically Transforming Security in a Virtualized World.” I wish I could have been there as I imagine that this was an excellent presentation where Neil laid out some new ideas around Virtualization Security and how Security Vendors will need to start thinking of new ways to approach security in a virtualized environment where there are management layers and encapsulated network layers that we’ve never had in IT before.

Some of the ideas that Neil presents such as Virtual Security appliances from the vendors (and opensource communities) are perfect for virtualized environments. You need to run a spot check vulnerability scan of your VMs? just bring a VA appliance online, run the scan, collect your results and take the appliance back offline, it’s doing nothing but consuming a little disk space again. Sounds better to me than purchasing a rack appliance, finding power and net access for it and keeping it powered on so you can access it when you need it, same could be said of other ‘occassional’ use technologies like physical asset discovery tools, etc.

Another idea he presents around the notion of ‘VM-spanning’ security applications makes a lot of sense. Being able to install and manage a security application at the hypervisor layer that has access to all the managed VMs (whether they are online, offline, templates, etc.) would be so much easier (and probably somewhat less costly) than having to install and manage sec apps on every managed VM, especially when you think about how quickly you can bring up and burn down VMs. If security apps were managed at the hypervisor layer, new VMs could simply inherit the proper setup and configurations automatically… I’ll bet there is not a Security Admin out there that wouldn’t gladly give up some of their action figure collection for that kind of functionality :).

Hacking Point of Sale
  • Derek:

    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

  • I see why you're a pundit, Chris :) The vNAC approach you talk about (and your post the other day on whether security ends up in the network) make tons of sense. I'm definitely with you on the concepts.

    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.

  • Hey Dwayne:

    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

  • Derek Crawford

    Hi Chris,

    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