Security and Risk Management Strategies Blog

What Does It Mean to be a "Virtualization Security" Solution?

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):

1. 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.
2. Is your solution running on physical memory (i.e. at the hypervisor level) or is it using virtual memory (in its own VM)?
3. 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).
4. 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?
5. Can your solution track VMs that leverage VMotion across physical hosts?
6. How does your solution identify a VM (e.g. by MAC or IP address, by VM ID, etc.)?
7. Can your solution integrate with Virtual Center or other management platform to take actions specific to VMs?
8. 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.

Five Immutable Laws of Virtualization Security

Blogger: Pete Lindstrom

There are many opinions about the impact of virtualization on an enterprise security posture. A recent article in InformationWeek (http://www.informationweek.com/shared/printableArticle.jhtml?articleID=204301246) gives a good example of the variance in opinions. In reality, we can apply traditional security practices to virtualization to determine whether risk increases or decreases with new virtualization architectures. It shouldn’t be surprising that the increase or decrease in risk is predicated on the current architecture. Here are five laws to live by when evaluating your virtualization architectures.

[This content is excerpted from the Burton Group Overview, “Attacking and Defending Virtual Environments.”]

When combining the standard risk principles with an understanding of the use cases of virtualization, a set of immutable laws can be derived to assist in securing virtual environments:

Law 1: Attacks against the OS and applications of a physical system have the exact same damage potential against a duplicate virtual system.

The point here is that, for all intents and purposes, a VM acts like a physical system, and in most environments that means it can be attacked in exactly the same way. The suggestion that because VMs run in user mode and are therefore more secure is insignificant if an attack remains within the VM and has access to the VM’s content and programs as if it is in kernel mode. So, when comparing a physical system with an OS and applications to an identically configured VM, all existing attacks will work the same way. Importantly, many attacks occur in the application stack, often against sensitive information itself. Any data on the VM may be stolen, and if the VM has network access it may be used as a stepping stone to attack other systems just as a physical system might be so used. The only attack that may be original and different is one that breaks the virtualization mechanisms and compromises additional VMs.

It is important to note that although VM and non-VM attacks are largely the same, the ability to recover from an attack may be significantly increased with VMs, and so the response and recovery may be different.

Law 2: A VM has higher risk than its counterpart physical system that is running the exact same OS and applications and is configured identically.

This corollary to the first rule above introduces the effect of the additional attack surface from the hypervisor and VMM. Because the VMM monitors and responds to a VM, it becomes susceptible to attack itself. The same is true for hypervisors. Any addition of software on a platform necessarily increases its risk if all other things are equal (i.e., there are no attack surface reductions performed in conjunction with the migration). Of course, all other things aren’t equal, so it is important to recognize the basically negative impact of the virtual environment on risk and to pay more attention to offsetting that risk in other ways.

Law 3: VMs can be more secure than related physical systems providing the same functional service to an organization when they separate functionality and content that are combined on a physical system.

When two processes share the same memory space, an attack against one process can impact the other. That is, system ownership by an attacker trumps any other security. One of the ways to benefit from virtualization is to separate various functions into their own isolated operating environments. An even better way is to separate data as well. Either type of separation provides an opportunity to reduce the risk added by the virtualization software.

Law 4: A set of VMs aggregated on the same physical system can only be made more secure than its physical, separate counterparts by modifying the configurations of the VMs to offset the increased risk introduced by the hypervisor.

While separating resources reduces risk, aggregating resources will initially increase risk (Rule 2) and so must be reconfigured or hardened to attain the same level of risk or a reduced level (Rule 3). Turning off services, adding controls, and separating content can reduce that risk.

The most obvious examples here are the replacement of a physical demilitarized zone (DMZ) with one built in a virtual environment and the aggregation of multiple physical desktops (e.g., like the military aggregating classified and unclassified desktops) into VMs on the same physical machine. Once again these VMs must be hardened to a level more secure than their physical counterparts in order to meet a similar risk level.

Burton Group’s current view is that subzones of a DMZ (or any other zone of trust) may be consolidated on a physical system yet separated by virtualization technology provided the risk of a breach is considered low. However, Burton Group recommends that virtualization not be used in a massive or systematic way to mingle production resources across zones of trust (e.g., between the DMZ and the trusted zone). Virtualization used in such a way could easily aggregate risks to medium or high, well exceeding the surety level of software VM isolation, which must be assumed at this time to be low.

Law 5: A system containing a “trusted” VM on an “untrusted” host has a higher risk level than a system containing a “trusted” host with an “untrusted” VM.

Broadly, “trusted” systems are managed and have protection controls deployed, while “untrusted” components may or may not be managed but are generally considered to have weaker protection and are therefore more susceptible to attack.

In American football, the general concept of “getting low” while blocking is an advantage to the blocker. In attacking systems, the same is true. Attacks at lower levels have higher risk than those at higher levels. This is primarily due to the ability to spoof or trick higher-level programs into believing assertions about trust and authenticity.

This rule is particularly important with Type 2 virtualization (OS-hosted virtual machine) because the host OS has a ready attack surface. Because client-side architectures involve both of these scenarios, it is important to recognize and understand the differences. Given this rule, it is important for deployments of trusted VMs in untrusted environments to consider the implications and harden the VM image accordingly.

[Addendum: During additional discussion within Burton Group, the question was raised, "Is this a vote against using virtualization?" On the contrary, we feel that virtualization has great benefit. It's just that some vendors and observers in the industry incorrectly and blithely say that virtualized environments improve security. There are many cases this isn't true--as discussed above--and it's important that practitioners think carefully about proper levels of protection as they move forward with such projects. Virtualization has security issues, but don't throw the baby out with the bathwater.]