WavebreakmediaMicro - Fotolia


Using NIST 800-125-A to understand hypervisor security threats

Expert Paul Henry discusses how the draft NIST Special Publication 800-125-A can help enterprises better understand the threat landscape in a virtual realm.

Hypervisor security has become a recent topic of discussion due to vulnerabilities found in the Xen hypervisor...

that required major cloud providers like Amazon Web Services and Rackspace to reboot parts of their public cloud infrastructure. Thankfully, the recently published draft, NIST Special Publication 800-125-A, discusses 22 vendor-neutral security recommendations for hypervisor baseline functions.

While it does not necessarily provide anything new or earth-shattering, it is a great set of security recommendations that should be considered by any enterprise deploying a hypervisor. This NIST draft publication, in many ways, reaffirms the recommendations from VMware previously found in the VMware Hardening Guide.

When moving services from a physical to a virtual realm, organizations inarguably increase their threat envelope. In a physical realm, most threats are considered from the external network and internal network. In the virtual realm, the attack surface has effectively increased. Attention must be given to the additional threat vectors from within the hypervisor itself, and there are several other security considerations that need to be made to counter the risks of those related threats.

Where the NIST document really stands out and adds tremendous value is in the details provided about the increased threat envelope when operating within a virtual realm.

Where the NIST document really stands out and adds tremendous value, in my opinion, is in the details provided regarding this increased threat envelope when operating within a virtual realm.

Threats from VMs and virtual networks

The NIST 800-125-A document provides several insightful examples of threats from virtual machines (VMs) and virtual networks themselves that are worthy of consideration when developing a secure virtual infrastructure. These include:

  • VM escape (HYP-T1): The threat to any hypervisor is from rogue VMs, which are VMs that manage to subvert the access control function provided by the virtual machine monitor/hypervisor to hardware resources such as and storage. The possible reasons for this threat are misconfiguration of the hypervisor and/or guest VM container, or malicious or vulnerable device drivers. If a rogue VM takes control of the hypervisor, it could potentially install rootkits or attack other VMs on the same virtualized host.
  • Breaking the isolation (HYP-T2): Potential threats to isolation are from attacks such as IP or MAC address spoofing by a rogue VM; VLAN hopping, when a rogue VM escapes the boundaries of its VLAN; or traffic snooping, which involves intercepting virtual network traffic intended for a VM on the same virtual network segment.
  • Resource starvation by rogue VMs (HYP-T3): Misconfigured or malicious VMs may be consuming a disproportionately high percentage of host resources, resulting in other VMs being denied (starved of) service.
  • Privileged interfaces provided by hypervisor: Hypervisors provide privileged interfaces (generally called by the name introspection API) to virtual security appliances (such as intrusion prevention or detection systems). These interfaces could become another target for exploitation by rogue/misconfigured VMs.

Hypervisor threats

The NIST 800-125-A document also breaks down threats to the underlying hypervisor in five example areas from within a hypervisor:

  • HY-BF1: Execution isolation for virtual machines -- Scheduling of VMs for execution; management of the application processes running in VMs, such as CPU and management; context switching between various processor states during the running of applications in VMs, etc.
  • HY-BF2: Devices emulation and access control -- Emulating all network and storage (block) devices that different native drivers in VMs are expecting, mediating access to physical devices by different VMs.
  • HY-BF3: Execution of privileged operations for guest VMs -- Certain operations invoked by guest OSes, instead of being executed directly by the host hardware, may have to be executed on its behalf by the hypervisor because of their privileged nature.
  • HY-BF4: Management of VMs -- Setting configuration parameters for VMs (VM images) and control of VM states (start, pause, stop, etc.).
  • HY-BF5: Administration of hypervisor platform and hypervisor software -- This involves the setting of parameters for user interactions with the hypervisor host, as well as hypervisor software and configuration of virtual network inside the hypervisor.

Consideration is given in the recommendations to both a Type 1 (bare-metal) hypervisor and a Type 2 (installed on top of an OS) hypervisor, with the expected recommendation of using a Type 1 hypervisor to reduce the environment's threat envelope.

One consideration discussed in the draft is for the use of a measured launch environment (MLE) and a trusted platform module (TPM) to expand trust to include overall boot integrity. As I have previously noted, this capability is actually enabled by default in ESXi and cannot be disabled. However, to take advantage of this security feature, it is important to verify that TXT/TPM is also enabled in BIOS. While an event is logged for TXT/TPM, there is no user interface to directly view the actual TXT/TPM measurements that are made of the kernel and the respective loaded modules within the VSphere GUI. Third-party products and services can use an API call to verify that the kernel and those modules that are inspected in the implementation of TXT/TPM by VMware have not been modified.


As expected, the document puts forth the need to provide for segregation, isolation and enforcement of the rule of least privilege. These recommendations would be of value across any platform in any environment to afford the highest levels of risk mitigation.

Where additional value is provided in NIST 800-125-A is in its addressing the expanded threat envelope while operating on top of a hypervisor, along with the threats from within the hypervisor itself.

About the author:
Paul Henry is a senior instructor with the SANS Institute and one of the world's foremost global information security and computer forensic experts with more than 30 years of experience covering all 10 domains of network security. Paul began his career in critical infrastructure/process control supporting power generation, and currently manages security initiatives and incident response for Global 2000 enterprises and government organizations worldwide. He is also a principal at vNet Security LLC, and serves as a retained security expert for multiple financial and healthcare firms.

Next Steps

Having an understanding of server virtualization issues is essential when dealing with network security. Learn about the risks, how to achieve compliance in a virtual environment and how to lock down the hypervisor to maintain hypervisor security.

Virtualization and hypervisor security vulnerabilities present a real threat to organizations. Learn more about how to identify and defend against these threats.

Dig Deeper on Cloud Computing Virtualization: Secure Multitenancy - Hypervisor Protection