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.