Security and Engineering

My previous posts showed how virtualization could lower your system’s security potentially. Virtualization introduces higher risks by means of

1. Management of virtual environments, like Mobility and Identity of Virtual Machines
   
2. How Virtual Machines connect to your physical network
3. Virtualization-Technology specific Issues, like DMA (see IO-Virtualization) and Complexity (see CPU-Virtualization)
4. Typical Vulnerabilities, like DoS (see KVM-Thrashing), VM-Escape and Privilege Escalation

Therefore, if an enterprise wants to introduce Virtualization into its systems, it has to enforce measures to enhance security aspects of virtualization technologies and to avoid the pitfalls. As a result of my posts and work, these measures have to be taken:

• Don’t consolidate Guests with different security-needs on the same Host-Machine.

An intrusion into systems with low security-needs is more likely. After this first step, it would be easier for an Intruder to attack sytems with higher security-needs if these systems are located upon the same VMM. This measure is taken to keep isolation between systems of different needs for security. If you have multiple Demilitarized Zones, keep them physically isolated: don’t consolidate hosts of different DMZs upon the same VMM and don’t try to create virtual DMZs instead of physical ones.

• Choose a low-complexity-VMM as a base for your virtual environment

The more complex a VMM, the more likely it’ll contain vulnerabilities. Different Virtualization-Technologies differ very much in complexity as well. Your important systems require low-complexity-VMMs. Such a VMM should be a Bare-Metal VMM. It should use Virtualization-Extensions of modern CPUs or Paravirtualization instead of more complex technologies, like dynamic Binary Rewriting techniques. It should use an IOMMU to avoid DMA-Issues (see Security and IO-Virtualization) and it should focus on Virtualization-Purposes only, because the more you put into the VMM-Layer, the more complex it’ll get. Static allocation of ressources (like RAM) is another way to lower complexity.

• Maximize VMM/Host-Security

If an intruder gains access to a VMM, all Guests of this particular VMM have to be considered as compromised. A VMM is an Operating System. Therefore, you have to apply Best-Practices for this OS to protect it from usual attacks (Remove services you don’t need, …) and you have to patch your OS and all applications running upon it. You have to enhance Isolation and lower sharing of ressources.

• Lower your VMM’s consolidation-potential

A VMM is a Single Point of Failure. Utilization of your VMM’s Server-Hardware will be much higher, because that is what we want virtualization for: higher utilization. Therefore, we have to prepare for a defect by redundancy, because more systems will be effected by this defect. In addition, to lower the risk of attacks on availability (DoS), we could set a limit for the number of guests a VMM should run, because otherwise the Denial of Service of a single VMM leads to a Denial of Service of an arbitrary number of Systems. If you want to take this measure to the next level, don’t consolidate Guests, which don’t need each other to operate, on the same VMM. Indepent systems are no longer independent in terms of VMM-Availability, if they run on the same VMM. But you have to choose measures appropiate for your purposes, of course.

• Don’t lower/remove your already established security measures

Virtual Machines contain the same vulnerabilities like physical machines. Therefore, you have to enforce your existing security measures in virtualized environments as well (patch, harden, monitor them …).

• Less People to administer a VMM

A VMM’s admin has privileged access to every guest running upon it. Therefore, a VMM’s admin has to be considered as trustworthy and you have to lower the number of people to administer a VMM. This measure will lower the risk of insider attacks primarily.

• Less Mobility of Virtual Machines

Deny arbitrary relocation of virtual machines, because a VMM’s admin has privileged access to every Guest. Moving Guests should only be possible where the admin of the source VMM is the admin of the destination VMM as well - or if the admins belong to the same group. In addition, the destination VMM has to enforce a same set of security-measures as the source VMM.

• Define processes for deployment and maintainance of Guests

These processes avoid sporadically used guests, without any associated patch cycle. Every guest has to be registered centerally, to be able to clean them if they get infected by malware. Before you’re using a Roll-Back-Mechanism you have to check for consequences and document such steps (see Management of Virtual Machines - Security Concerns).

In a nutshell and from a management perspective: the more flexibility and consolidation-potential you are willing to loose, the more secure your virtual environments could get. But, flexibility and consolidation-potential is what we want virtualization for. Therefore, our gains of virtualization are up to a point contrary to our system’s security-needs and the steps you have to take depend on your systems and their needs - and to which degree you are willing to loose the benefits of virtualization.

Security is never limited to technical issues only. This is true for Virtualizatiion as well, especially for organizational and management patterns. Virtualization offers a huge degree of flexibility and dynamic deployment of virtual machines, but the freedom has a tradeoff. Highly dynamic deployment and flexibile relocation of virtual machines is contrary to static security architectures often deployed today.

Tal Garfinkel et al. mention these, organizational issues within “When virtual is harder than real: security challenges in virtual machine based computing environments“:

• Scaling. Virtualization simplifies the deployment of machines a lot. Therefore we have to consider that many more machines will be deployed compared to static environments without Virtualization. The effort of Organizational and Management-Tasks, like Patch-Management and Configuration, which often require manual interaction is rising and the attack surface is growing.
• Transience. Machines appear and disappear often sporadically. Therefore the network doesn’t reach a well known, good configuration, which is hard do document because of these frequent changes. A virus infection is nearly impossible to remove in such a scenario, because infected machines appear and disappear frequently, infecting some new machines before disappearing again.
• Software Lifecycle. We usually can reset virtual machines to a specific point through a Roll-Back-Mechanism. We snapshot a virtual machine when we guess it would be appropriate and put them back to that state later when an error occurred or if we have to recover the machine. We do not only recover a well known, working configuration of that machine. We recover already patched vulnerabilities, locked accounts, revoked cryptographic keys and so on.
• Diversity. Virtualization could potentially increase the degree of heterogenicity, which admins usually avoid in means of security, because it complicates patch-management and other tasks.
• Mobility. A machine’s mobility is much higher when dealing with virtual machines. We can live-migrate or copy the whole VM, including filesystem, on an other physical host within minutes. The Trusted Computing Base of a usual machine consists of a software and a hardware-stack. The Trusted Computing Base of a virtual machine consists of all stacks of all machines the virtual machine was ever running on. This could lead to very long trust dependencies. In addition, it could be hard to isolate a compromise or infection of virtual machines, because our virtual machines are highly mobile.
• Identity. A Virtual Machines’s identity is harder to guess, because of its Mobility and Transience. In addition, a person, who responsible for the VM is harder to guess as well. A random MAC-address is assigned to each VM. Therefore, the reason and origin of specific security issues is harder to determine.
• Data Lifetime. The Virtualization-Layer is an additional layer in a system. Operating Systems usually assume to control dedicated hardware. Therefore, Operating Systems assume a direct path to hardware ressources - the place they store data. When we use a VMM, the location and duration of sensitive data is not detectable and determinable by an OS, but sensitive data, like passwords or cryptoraphic keys, should stay as short as possible in a system.

An enterprise usually drives components with different needs for security. A VMM enables us to run all these components on a single VMM potentially (if we don’t take limited ressources into account), but not every VMM is suitable to run machines with high security needs on top of them (compare S.J. Vaughan-Nichols. “Virtualization sparks security concerns”) and a VMM’s need for security is the sum of all its guests.

A VMM’s Administrator has unrestricted access to every Virtual Machine running on that particular VMM, because the admin has unrestricted access to the hardware ressources the Virtual Machines rely on. Therefore, an admin has to be trustworthy and has to be considered as admin (aka root) of all Virtual Machines running on that VMM - that’s maybe hard and not applicable. In addition, a Virtual Machine could be highly mobile (when we are relocating it all the time) and each VMM could be administered by an other person. Therefore, we have to consider all admins of all VMMs we would like to run our VM on as admin of our VM - that is nearly never applicable.