Keep Tier-One Applications Out of Virtual Environments

COMMENTARY

For at least the past 20 years, virtual machines and enterprise-ready hypervisors were marketed, sold, and adopted as the future of server-based computing. Dedicated power-hungry servers sitting in racks on a raised floor were replaced by systems architected to host multiple virtual servers simultaneously and to optimize resources based on load. The time of idle RAM, underutilized networks, and free hard disk storage was transformed by load-balancing technology, shared resources, and CPU prioritization to minimize costs, energy, and footprint. The goals were achieved, and the technology worked.

When organizations began shifting their tier-one mission-critical servers to virtual machines, the need to provide redundancy and high availability to meet uptime service-level agreements became paramount. Virtual machine hypervisors introduced redundancy technology, mirroring, real-time backups, cold spares, and myriad other solutions to mitigate the risks of an outage both in hardware and software. This technology even included mitigations for the hypervisor itself, just in case it became fully unavailable.

However, what happens if all of your hypervisors become unavailable — in essence, if all of your virtual data centers went offline, including all redundancy? This risk was not a consideration in the past, based on the maturity of virtualization, but today it poses a real threat and is why tier-one applications should no longer be virtualized. Why? Read on.

Hypervisor Attacks on the Rise

In the past few years, hypervisors have been targeted in high-profile malware and ransomware attacks. Instead of just attacking the data on a server, or a server or workstation operating system, threat actors have become brazen in attacking hypervisors and encrypting all the virtual machines hosted by the system. And if the attack vector is crafty enough, it can infect all virtual machines and hypervisors, regardless of their geolocation and backup status, simultaneously. This essentially renders all technology hosted as a virtual machine — including your tier-one applications — useless and unable to complete their mission.

So how did this change come about? Vulnerabilities, exploits, poor identity security, malware, social engineering, and, of course, ransomware. To understand this risk, let us look at some exploits that affected VMware, a leading enterprise virtualization technology, and some of its key components.

According to CVE Details, since Jan. 1, 2020, there have been 334 reported vulnerabilities for all VMware solutions. Of those, 19% were critical and, if exploited, could lead to a compromise of the affected VMware solution.

However, at least two are especially important to this discussion, despite their age: CVE-2021-21974 and CVE-2020-3992. Each could lead to a full hypervisor outage if exploited. The obvious answer from many security professionals is to patch. However, when patching these vulnerabilities, the entire hypervisor generally needs to be taken offline and all virtual machines paused or stopped to complete the upgrade. If the environment is large, potentially dozens or even hundreds of virtual machines may need to come offline. That type of outage is typically lengthy and unacceptable for tier-one applications.

Migrate to a More Fitting Solution

Most organizations will avoid patching due to the downtime alone, instead using other mitigations to avoid exploitation. This, however, does not solve the problem. If the hypervisor or any of its components are exposed to the Internet, these vulnerabilities are ticking time bombs. Not patching critical vulnerabilities will lead to exploitation at some point. The rise in hypervisor-based vulnerabilities is increasing and will continue to escalate, as shown by CVE Details data.

Therefore, organizations have four potential solutions:

Choosing your path requires some analysis and decisions before taking down your unpatched virtualized tier-one applications. First, categorize all applications by mission criticality. Is it a tier-one application, where any outage is unacceptable to the business, or a tier-two application, where downtime is acceptable (if it's minimal) for hypervisor patching? Next, which tier-one applications can be cloud-washed — that is, directly moved to a hypervisor in the cloud and maintained by the provider — or replaced by a modern SaaS solution? Most organizations prefer a SaaS solution because it does not need virtual machine maintenance like their on-premises counterparts. That is one of the biggest benefits of SaaS.

Once you have made these decisions, your organization needs to separate tier-one applications from on-premises hypervisors. Like any other technology migration, document all planning, testing, requirements, service-level agreements, and so forth so that you can measure success. In the end, however, the risk mitigation is priceless, since the business no longer has to accept the risk of unpatched hypervisors and the potential for mass exploitation of ransomware.

In my opinion, tier-one applications should not depend on hypervisors to ensure availability. Points of failure for such applications should be minimized. In recent years, attacks against hypervisors have proved that the risks are real and may no longer be acceptable to a business. This is why I believe tier-one applications should no longer be implemented using on-premises virtual machines.