The Laws of Virtualization Security

Editor’s Note: Adoption of virtualization in the enterprise is increasing rapidly, giving rise to concerns about security risks and threats to virtual infrastructures. Burton Group analyst and noted security expert Pete Lindstrom examines the security considerations unique to virtualized IT environments and lays out the Five Immutable Laws of Virtualization Security.

Virtualization of clients and servers and its accompanying impact on networks and storage is a hot topic in IT today, and therefore a hot topic in security.

As with any new technology as broad and comprehensive as virtualization, such security concerns are of paramount importance. Not only that, but the technical details combined with a mix of marketing messages from vendors can create a potent cocktail of ambiguity about the real impact on risk and security of these new architectures.

Amidst all of the superficial discussions of hypervisor-based rootkits and discovery techniques lay the very real issues of allocation of information assets and the relative impact on threats and vulnerabilities. Indeed, virtualization comes with its own set of unique security considerations. The appropriate protection response to these inherent security characteristics is neither one of paranoid negativity around deployment nor delusional access for everyone. The best response is a measured approach with careful consideration of the impact on the existing IT infrastructure, a factored analysis of threats, vulnerabilities, and consequences, and an understanding of the impact on existing security solutions.

Rules of the game

There are five immutable laws of virtualization security that must be understood and used to drive security decisions:

Law 1: Attacking a virtual combination of operating system and applications is exactly the same as attacking the physical system it replicates.

The beauty of a virtual machine is that it acts just like a physical system. In most environments, that means it can be attacked in the same way. Any data on the virtual machine may be stolen, and if the virtual machine has network access it may be used as a stepping stone to attack other systems.

Law 2: A virtual machine poses a higher security risk than an identically configured  physical system running the same operating system and applications.

This corollary to Law #1 accounts for additional vulnerability of a virtual system’s controlling software, known as a hypervisor. Because the hypervisor monitors and responds to a virtual machine, it’s susceptible to attack itself. It’s important to recognize the risks inherent to the virtual environment and to offset that risk in other ways.

Law 3: Virtual machines can be made more secure than similar physical systems when they separate functionality and content.

When two processes share the same memory space, an attack against one process can impact the other. One of the ways to benefit from virtualization is to separate functions and date into isolated operating environments. Such segregation helps reduce the risk added by the virtualization software in Law #2.

Law 4: A set of virtual machines aggregated on the same physical system can only be made more secure than separate physical systems by modifying the virtual machine’s configurations to offset hypervisor risk.

While separating resources reduces risk, combining resources will initially increase risk (see Law #2). So at this level of aggregation, virtual machine’s must be reconfigured to attain the same level of risk achieved through Law #3. Turning off services, adding controls, and separating content can help reduce overall risk.

Law 5: A system containing a trusted virtual machine on an untrusted host poses a greater risk than a system containing a trusted host with an untrusted virtual machine.

Attacks at lower levels have greater risk than those at higher levels since higher-level programs can be tricked into believing assertions about trust and authenticity. It’s important for deployments of trusted virtual machines in untrusted environments to consider the implications and harden the virtual machine image accordingly.