The hypervisor security patch management process
Enterprises using virtualization must include hypervisor patching in their patch management process. Robbie Higgins explains why.
A strong patch management program is essential for any virtual or physical IT system. When it comes to your virtual environment, the hypervisor (also called the virtual machine monitor or VMM), is probably the most critical component because it allows multiple operating systems, called guests, to run concurrently on a host computer. From a patch management perspective, the hypervisor, like any other part of the IT infrastructure, suffers from vulnerabilities that require periodic updates. Security vulnerabilities in hypervisors are by no means new and it is unknown how many virtualized enterprises actually patch this critical layer of infrastructure on a regular basis. Organizations that have deployed virtualization should add hypervisor security patching/updating to their patch management process.
The worst case scenario is the update/patch actually brings down the very environment you are trying to protect.
The hypervisor offers the guests a virtual operating platform while also monitoring the execution of the guests; it’s basically a very minimalist operating system. Its job is to convince each guest OS that it, and it alone, has access to the host server's physical resources, while managing access to ensure programs and data don't leak between operating systems. Hypervisors are growing in deployment in everything from data centers at the core of an IT organization, to embedded consumer electronics, such as iPads, at the disruptive edge of the IT environment. As their deployment increases, more and more hypervisor security concerns come into play, including a variety of attack methods and the potential dire consequences of a compromised hypervisor.
The primary concern is if the hypervisor has a vulnerability that is exploited; this compromised platform could allow unauthorized individuals full access to all hosted guests on a given machine. Malicious software could easily be installed and hide its presence from security tools that reside in either hosted-OS partitions or on any software layer above the hypervisor.
If an unauthorized attacker owns the hypervisor, he/she owns all data traversing the hypervisor and is in a position to sample, redirect or spoof anything within the environment. Without strong security controls in place, guest operating systems have no way of knowing they are running on a compromised platform. This “hyperjacking” scenario becomes amplified when you consider large-scale virtualization platforms that offer hundreds of hosted servers running on a single piece of hardware. The potential risk for loss of control, revenue and compliance implications are considerable.
Hypervisor patching challenges
So what is the key challenge associated with the hypervisor patch management process? Some may think it is the actual patching of the hypervisor itself; however, in many ways, that’s the easy part. The real challenge is how to deal with the required regression testing to ensure your updates don’t impact the existing environment in any adverse way. The worst case scenario is the update/patch actually brings down the very environment you are trying to protect.
Doing your due diligence prior to pushing out patches/updates is key. You must ensure you have trialed your test and development environments prior to rolling out your production. You really need to assess and measure the compound risk across shared/multitenant environments with respect to patching and its impact if something goes wrong. This is one of the main reasons why many organizations are hesitant to update their hypervisor: While they understand the risks if it’s compromised, they would much rather take on the risk that the hypervisor becomes compromised (low likelihood of occurring) than push out an updated patch that has not been rigorously tested.
Lastly, if you are currently thinking about updating your future virtual environment, you should consider the maturity of your hypervisor. For example, VMware ESX Server has been around for a number of years. Most, if not all, of its key vulnerabilities are known, and patches/updates are available and well tested. Contrast this to a new hypervisor by a new company that was released just in the last 12 months. Obviously this should not be your only decision criteria. However, it is one that is very often overlooked by organizations.
About the author:
Robbie Higgins is vice president of security services at GlassHouse Technologies.