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.]

Comments

[Richard]

This is a very enlightening piece! Security solutions will soon adapt to the virtualization environment. There are so many new products coming out that one of them has to be promising. Within the last few weeks we've seen three new virtual firewalls hit the press. Montego Networks has a v-switch but it has a great deal of firewall capabilities. TBD Networks and Altor Networks have similar products. It will be interesting to see how the environment changes in next few years.