Hypervisor security is still theoretical in nature, since the preoccupation so far has been with securing the virtual machines (VMs) running on the hypervisor. With hypervisors being used extensively today from embedded consumer electronics to high-end data centers,
A hypervisor is a layer, so to speak, between the VMs and the physical infrastructure they operate on. The hypervisor, being a common connection, is a potential carrier of risks – both in terms of getting compromised and propagation of risk. With the emphasis being on securing the environment for tenant VMs, hypervisor security has been largely neglected.
Risks associated with hypervisor
An inherent problem of running a hypervisor is the lack of operational logs and audit trails, which are shallow as far as operations like hypercalls are concerned — making the enforcement of hypervisor security a painful task. This is one reason why enterprises do not find a hypervisor setup feasible for risk-intensive applications. Unlike physical architectures, performing essential proactive functions such as penetration testing and scanning is difficult in virtual environments.
With the focus in this space being on performance, hypervisors aren’t always security hardened. Performance expectations from physical machines do not hold up when the same machine hosts multiple tenant systems, in terms of scalability. In addition, when speaking of hypervisor security, it is important to remember that vulnerabilities on a hypervisor, which is based on the open server architecture, can potentially be exploited like any code flaw on other platforms.
Planning for hypervisor security
The following tips will help you frame an effective hypervisor security policy for your organization:
Hypercall vulnerabilities and privilege escalation: Exploitation of hypercall vulnerabilities involves using methods such as buffer overflows to exploit system calls made by VMs to the hypervisor. To prevent this, VMs should run on a hardened hypervisor. While this does not directly address hypercall vulnerabilities, this can prevent compromise of VMs, which can lead to a privilege escalation issue — giving attackers privileged access to the hypervisor. The steps leading to such a scenario are largely product dependent; nevertheless, VM patching is a must. Add-ons like host-based antivirus systems are not recommended for hypervisor security, since this can adversely affect performance. Instead, a network threat management system is more suitable.
Segregation of duties: This is an important compliance requirement in most mature information technology (IT) setups. With issues of privilege escalation among users rising, it is essential that domains of operation be defined when planning for hypervisor security. Legitimate access to the hypervisor should be the domain of the VMware administrator. This can protect against any intentional or unintentional mis-configuration of the hypervisor/VMs. An absence of such a division of labor can lead to situations where conflicting instruction/polices are issued to the system or situation where VMs get dropped from the scope of policies by mistake, leaving them wide open to attack. For a more detailed exposition on segregation, see here.
Performance calibration and need for planning: There is a need for performance validation when planning for hypervisor security, as unsuitable allocation of resources for process layers like network anti-viruses and firewalls can lead to faltering of the entire virtualized setup. For example, when planning VM capacity for a machine with eight physical cores, the assumption that all cores will be available for use in tandem with the security layers can spell trouble. Allocating a single core exclusively for security however, can free up seven cores for other purposes, while ensuring smooth functioning of the security layer. The same principle applies to memory.
Dealing with system clusters: Clustering of physical machines in virtual setups leads to greater complexity, while multiplying risks manifold. In the case of multiple physical machines running a virtual environment under a single hypervisor, any oversight can have serious consequences in terms of vulnerability and availability. Considered security solutions should be validated for compatibility with the underlying clustering technology to put effective hypervisor security controls in place.
About the author: Ramandeep Singh Walia is the head of system engineering - Indian subcontinent at Check Point Software Technologies.
This was first published in May 2011