It's RSA week. Which means we're going to be inundated with security news, and the hype is going to be loud. And a number of research firms predict virtualization security will be near the top of the hype-o-meter this year.There's no doubt that virtualization changes the ground rules for many aspects of IT security. Consider the issue of intrahost traffic: take a few application servers, toss in a database or two, and now you have to worry about all of that intrahost traffic which can travel on the host server oblivious to inline security controls (such as intrusion prevention systems) waiting on the wire. And as I'm talking to CISOs, I'm hearing horror stories of admins shutting down the AV on virtual machines (can't lower CPU load for the sake of security) and what sounds to me as bailing-wire-and-string solutions (v-lan and network segmentation tricks off the host to the physical wire) just so the traffic can be vetted by a firewall or IPS.

The answer, of course, lays within "virtual security solutions." But what's the difference between an actual virtual security solution and just an old-fashioned security solution with the "v" word slapped in front of it?

In a recent blog post, Burton Group is taking a stab at developing an answer.

Here are some questions they suggest you ask any security vendor hawking virtualized security solutions:

What virtualization platforms do you support? If they say "all of them" that is your first indicator that this is a strategy and not a solution. Is your solution running on physical memory (i.e., at the hypervisor level) or is it using virtual memory (in its own VM)? Did you have to rewrite code to integrate into the virtual environment? If so, what components required this? (This is a higher-level question that consumes a lot of the following questions). Does your solution leverage the VMsafe API? On other platforms, does it have access to CPU, memory, network, and file system operations of the physical host? Can your solution track VMs that leverage VMotion across physical hosts? How does your solution identify a VM (e.g., by MAC or IP address, by VM ID, etc.)? Can your solution integrate with Virtual Center or other management platform to take actions specific to VMs? Are you managing configurations (patch/vuln mgt), encrypting communications, "inline" network security (NIPS or firewall), or providing some other security capability?

This list looks like a good start at clearing through the virtual security clutter. More on the post is available on Burton's Web site.