The Laws of Virtualization Security (
Page 1 of 4 )
Burton Group’s
Pete Lindstrom lays down the law for
protecting virtual infrastructures.
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.