Blogger: Pete Lindstrom
It happens with every new technology and/or security fad (think wireless, handhelds, NAC, DLP) – people want to make their solution buzzworthy and so work hard to explain why they are in this “product category” that isn’t really a product category and have some unique characteristics that differentiate them from the crowd of others making the same claims at the same time (try being an analyst amidst these frenzied marketing messages ;-)). The latest buzzworthy term is virtualization security.
The first thing to recognize when evaluating your security vendors’ support for virtualization is that virtualization is designed to be transparent. That means that virtual machines (VMs) running traditional host operating systems are intended to look and feel just like physical OSes and therefore any security solution running on the host will almost certainly run on a corresponding VM (please let me know if you find an agent that doesn’t). You get this automatically. (Congratulations! ;-)).
From a network perspective VM transparency also applies, though network-based solutions must be able to run on OSes that have been ported to the virtual environment. Ironically, the network security solutions that were developed using proprietary hardware and software (typically to meet performance needs) are going to be much more difficult to port to a VM. Software-based solutions that operate on network traffic and security appliances that sit on Linux or FreeBSD, for example, should port over nicely as well.
The only reason any of this matters is to assess the speed for which you need a security solution and the availability of solutions that support that need. There is nothing wrong with having a solution that is virtualization-agnostic, but it is useful to know how unique the solution actually is if it is a differentiator in your evaluation process. In addition, in the near-term security solutions should be able to leverage the characteristics of virtualization for beneficial features such as patching a VM that is not in service or isolating a host agent from the host it is monitoring. That is essentially the VMsafe story.
As vendors pick up and elaborate on their virtualization messages, it may be helpful to have a set of questions to ask them in support of your evaluation. Here are some basic ones (Note: most of these are VMware-oriented since almost all security solutions are starting with VMware integration):
- 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?
It is worth noting that there are other security solutions that leverage “virtualization” that sometimes mean something different – for example, many network security vendors are providing virtualization on their network devices to provide for more separation options. Also, there are companies like Phoenix Technologies’ HyperCore or Neocleus that will add virtualization capabilities that leverage hardware virtualization from Intel and AMD.