Must-Have VMware Security Features You Can’t Ignore

This article aims to delve into the "so what?" aspect surrounding the prominent security features within modern vSphere editions by VMware. It isn't designed as an intricate technical exploration. Instead, its focus is on advocating for these features through three fundamental questions: What is its purpose? Why does it hold importance? What steps should be taken?

Without delay, let's delve into the approximately 5 VMware Security features that are likely indispensable, demanding proper configuration within your vSphere setup:

·       Enhancing Host Security: Trusted Platform Module-enabled Secure Boot

·       Fortifying Hosts: ESXi Host Lockdown Mode Unveiled

·       Advanced Key Management: Exploring the "New" vSphere Native Key Provider

·       Safeguarding VM Data: VM Encryption in Focus

·       Optimizing Performance: VMware Tools and Upgraded VMware Hardware Version

Enhancing Host Security: Trusted Platform Module-enabled Secure Boot

What it is?

Beginning from vSphere 6.5, VMware has undertaken a comprehensive effort to define the essence of "trust" within the vSphere technology framework. This journey commenced by enabling and harnessing UEFI Secureboot for ESXi hosts, subsequently incorporating Trusted Platform Module (TPM) 1.2. Swiftly progressing, VMware transitioned to Secureboot with TPM (2.0), establishing a potent and purposeful mechanism to fortify the integrity of the ESXi host stack from initial boot to subsequent stages.

In the realm of virtual infrastructure, establishing the root of trust hinges on the assurance that each element within the chain, stack, or sequence remains secure and possesses an established, reliable value. This foundation of trust is further fortified through vCenter's validation of the secure boot stack, culminating in a documented "attestation." What emerges is VMware's conceptualization of the "Trusted Platform," signifying the authoritative source for instating a hardware-rooted foundation of trust that spans from the hardware level to the very core of VM workloads themselves.

Why does it matter?

The security and reliable configurations of the underlying physical infrastructure significantly impact all workloads operating within virtual machines (VMs). However, focusing solely on securing the POST, optimizing drivers, or fortifying the ESXi host's operating system (all commendable efforts) falls short. What's imperative is the establishment of a recognized configuration, a bedrock of trust spanning the complete vSphere stack from the initial host power-on stage to the complete VM deployment.

Formulating this foundation of trust and enabling vCenter to relay attestation status regarding the hosts to administrators becomes an essential prerequisite to fulfill this requirement.

What should I do?

Contemplate the decision of establishing a Trust Authority tailored to your existing vSphere setup (ESXi & vCenter). If your organization's ESXi hosts currently lack TPM chips, get in touch with your hardware vendor or provider to procure the necessary component. Subsequently, it becomes of utmost importance to thoroughly absorb the insights presented in the article titled "Preparing an ESXi 6.7 Host for Secure Boot" (courtesy of Mike Foley).

Commence the process by executing the secureBoot.py script (/usr/lib/vmware/secureboot/bin/secureBoot.py -c) PRIOR to activating Secure Boot and enabling TPM on each host. The objective is to ensure that your ESXi hosts satisfy the minimal vSphere Installation Bundle (VIB) host acceptance criteria, denoted as "Partner Supported" in this context, thereby enabling the integration of Secure Boot alongside TPM. Strategize to carry out these installations during your next scheduled maintenance window, capitalizing on the advantages of VMware clustering.

So, in summary:

1.     Identify if you do/do not have TPM chips and order hardware accordingly.

2.     Follow the preparation guidance in this write up and subsequent VMware KB articles for the modern vSphere versions.

3.     Run a local command on each ESXi host to verify that the necessary VIB acceptance level is at minimum “PartnerSupported”.

4.     Plan a maintenance window.

5.     Migrate all VMs off the host.

6.     Install TPM Chip (if applicable)

7.     Enabled Secureboot and the TPM chip (guidance).

8.     vCenter should then be capable of reporting the attestation status of hosts.

Additional Thoughts

VMware has taken a significant stride by expanding the scope of their root of trust, creating an encompassing framework known as the "vSphere Trust Authority" for vSphere 7 and subsequent versions. This framework, alternatively referred to as the "Trusted Infrastructure," amalgamates the foundational components of Secure Boot alongside TPM 2.0, integrating them with an external Key Management Service (KMS) and distinctive host cluster configuration.

This fusion holds promising practical implications. In my opinion, we find ourselves in a phase of observing and awaiting the outcome in terms of its successful implementation. The trajectory of how things progress remains a subject of anticipation and assessment.

Fortifying Hosts: ESXi Host Lockdown Mode Unveiled

What is it?

Host lockdown mode serves as a security measure aimed at confining direct access to hosts, while still enabling selective exemptions for authorized individuals. This approach effectively limits direct interactions with hosts, predominantly channeling access through vCenter, which leverages its comprehensive array of access controls, roles, and permissions.

In the realm of lockdown mode, both ESXi shell and SSH access are deactivated, accompanied by a designated exceptions roster of accounts. This security mechanism encompasses two principal lockdown modes:

·       Normal – The host is accessible through the local console or vCenter Server

·       Strict – The host is accessible though vCenter Server. The Direct Console UI service is stopped

Keep in mind that the list of exempt users can be employed to accommodate service accounts necessitating host access for critical business operations, like backup service accounts. This functionality isn't aimed at establishing an absolute security "black box," but rather aims to curtail access to recognized accounts while affording flexibility for orchestrating precise failure and recovery scenarios.

Why does it matter?

Host Lockdown mode, frequently misconstrued or sidestepped, stands as one of the more enigmatic security technologies. Part of this stems from Administrators being cautious about unintentionally impeding routine administrative or troubleshooting access to hosts through an excess of security measures, oftentimes without grasping the potential ramifications. Gratefully, VMware has taken note of administrators' reservations, and the potential pitfalls associated with Host Lockdown mode. As a result, they have produced an array of informative articles and insightful video presentations to complement the white paper documentation. These resources aid in shedding light on the practical functioning of this feature and offer guidance in determining the most suitable approach for your organization.

What should I do?

Malicious actors often set their sights on direct host access as a means to bypass the access controls typically upheld by a centrally managed vSphere environment through vCenter servers. ESXi hosts become susceptible to various attack vectors, which encompass but extend beyond rootkit exploits. These vectors encompass unauthorized entry into both local and network datastores, DoS (Denial of Service) attacks through the compromise of host memory or device drivers, the unsettling "escape the VM" scenario, and even ransomware attacks. ESXi hosts that remain unpatched and fail to keep up with the latest versions expose themselves to exploitation through well-known bugfix issues and documented vulnerabilities.

To fortify your ESXi hosts against targeted assaults, Host Lockdown mode emerges as a pivotal stratum of comprehensive defense. Familiarize yourself with this feature, gauge your organization's administrative and recovery requisites, and activate Host Lockdown in the suitable mode across all ESXi hosts. This approach forms a critical barrier against potential threats.

Advanced Key Management: Exploring the "New" vSphere Native Key Provider

What is it?

To engage, activate, or execute cryptographic operations linked to functionalities like VM encryption, the utilization of a Key Management Service (KMS) becomes essential. At present, VMware offers three primary methodologies for KMS implementation, contingent upon the specific vSphere version integrated within the environment:

Standard key provider – Utilizing standalone and external Key Management Service (KMS) solutions represents an avenue for enabling cryptographic capabilities within the vSphere ecosystem. Following the configuration of vCenter with a KMS provider, both newly created and pre-existing virtual machines can be safeguarded through VM Encryption.

Trusted Key provider – In vSphere 7 and subsequent releases, the configuration of the key provider can align with the "Trust Authority," provided it exists within the environment. The Trust Authority introduces a dependency on the attestation status of a workload cluster for conditional access to encryption keys. Implementing vSphere Trust Authority necessitates an external key server. While this approach might entail a more intricate planning and implementation process, it simultaneously represents one of the most comprehensive configurations in terms of establishing the overall root of trust within the vSphere environment.

vSphere Native Key Provider – An innovative addition within vSphere 7 Update 2 is the inherent capability of vSphere to furnish keys for its own security functionalities. This advancement eliminates the previous reliance on an external or separate KMS solution, enabling vSphere to independently manage key-oriented security aspects like activating host cryptographic operations (Host Encryption Mode) or fulfilling the prerequisites for VM Encryption.

For comprehensive insights and pertinent information on comparing key providers for deployment considerations, an insightful article is available in the VMware Security guide.

Why does it matter?

For numerous customers, this has presented a considerable hurdle, especially since not all organizations have an implemented Key Management Service (KMS) or have adequately prepared for the associated costs and efforts needed to establish one exclusively for enabling vSphere security functionalities. To address these challenges, VMware has responded with the introduction of a novel feature in the latest iteration of vSphere 7, known as the Native Key Provider.

True to its name, the Native Key Provider is an inherent vSphere feature designed explicitly to fulfill vSphere's key provider requisites. This approach is notably more streamlined and straightforward in terms of planning and implementation compared to the traditional route of a KMS solution. While adoption is still in its early phases, this solution might serve as the catalyst enabling organizations to proceed with configuring essential security features aimed at safeguarding their workloads.

What should I do?

Determine which considerations align with your vSphere design focus for Key Management. If your current KMS solution boasts redundancy and resilience, integrating vSphere with this well-established and well-maintained system would yield direct advantages. Conversely, if there's a hint of uncertainty surrounding your KMS, or if, as the vSphere administrator, you lack visibility into this crucial foundational component that directly influences the stability and effectiveness of your vSphere environment, then consider upgrading to vSphere 7u2 (7.0.2) and strategizing an integration with the vSphere native key provider.

Enabling a key provider facilitates the activation of the following features:

1.     VM Encryption for both newly deployed VMs and virtual disks, as well as existing ones.

2.     Configuring vTPMs on virtual machines.

Safeguarding VM Data: VM Encryption in Focus

What is it?

VM Encryption embodies its name's essence, effectively safeguarding virtual machine (VM) configurations and the respective virtual disk(s) through encryption. However, what sets this encryption apart is its distinctiveness; it isn't just another run-of-the-mill data-at-rest encryption solution (grateful nod to storage providers who simplify that aspect, from a VM Admin). This encryption approach boasts inherent significance by serving as a robust means of natively securing VMs within the vSphere framework. Furthermore, it forms the foundational requirement for advanced VM security features, which are also expounded upon in this article (refer below).

Why does it matter?

Encryption has rapidly evolved into a standard security practice adopted by contemporary enterprises. vSphere's native VM encryption shares similarities, offering the capability to activate encryption on any or all VMs, irrespective of their applications or services—a concept that might ring familiar. However, it transcends mere similarity. VM Encryption serves as the prerequisite for advanced VM security features, particularly the virtual Trusted Platform Module (vTPM). To perpetuate the established root of trust from ESXi hosts and extend it seamlessly to VMs, VM Encryption is a necessity.

Now, transitioning away from my enthusiasm for vSphere's virtual machine-related attributes and the continuum of trust they stem from VM Encryption, let's delve into another aspect that fueled my initial interest in VM Encryption. The introduction of the role "No Cryptography Administrator" empowers individuals with administrative privileges while preventing direct console access to VMs encrypted via VM Encryption. Moreover, it shields VMDK files from being downloaded in unencrypted form—addressing a longstanding security concern in virtualization. In the event an administrator's credentials are compromised, a potential attacker's ability to download, for instance, the virtual disks of Domain Controllers and subsequently attempt offline compromise of the environment is thwarted. This holds true for any critical line of business applications, or even backup servers—an impactful testament to the comprehensive scope of VM Encryption.

In essence, VM Encryption transcends mere encryption; entrusting your security solely to backup solutions or Guest OS disk encryption isn't a comprehensive resolution for safeguarding your environment.

What should I do?

This is where the challenge deepens. The prerequisites for VM Encryption can be quite demanding. However, when you consider the potent native security capabilities that VM Encryption brings to the table, coupled with its role as a prerequisite for even more advanced security features, a compelling argument can be constructed in favor of the effort it entails. And now, I have some positive news to share, which I'll address shortly. It's important to note that while I've outlined the VM-related security features below, not all of them strictly mandate the activation of VM Encryption as a prerequisite. I've chosen to present them here and offer insights into whether VM Encryption (or a Key Management Service, which is an essential requirement for VM Encryption) holds relevance.

Enable Secureboot

Take the leap. It's the subsequent link within the root of trust sequence. It surpasses BIOS configuration in terms of VM security. While VM Encryption isn't mandatory for activation, certain factors must be taken into account:

1.     Virtual hardware version 13 or higher

2.     VMware Tools version 10.1 or higher

3.     Enable EFI Firmware

4.     Enabled Secureboot in Configuration Parameters

5.     Is it required, to allow the use of vTPM

Enable Virtual Trusted Platform Module

Given the limitations of a physical TPM chip, which is constrained by small storage capacity and sluggish serial-based functionality, managing secrets for potentially numerous VMs on a single ESXi host becomes impractical. Additionally, linking VMs to specific physical chips would hinder essential virtual machine functions like vMotion and cluster-based high availability (HA) recovery. Consequently, utilizing a hardware TPM for virtual machine purposes is counterproductive. Enabling vTPM entails contemplation of the following considerations:

1.     Enabled EFI firmware

2.     Enabled Secureboot

3.     Virtual Hardware version 14 or higher

4.     VM Encryption (which itself requires KMS)

5.     Is required or recommended to enabled Windows 10 and Server 2012 security features (i.e., VBS, credential guard)

Enable Virtualization Based Security (support)

Just to clarify, when you modify a virtual machine and activate Virtualization Based Security (VBS), what you're essentially enabling is the "Support for VBS." This action exposes the essential functionality to the guest OS, which then utilizes it. However, a complete VBS implementation entails enabling all VBS-related functions within the guest OS. This point is highlighted for precision.

The ensuing factors should be taken into account when enabling VBS Support on a specific VM:

1.     Enabled EFI firmware

2.     Enabled Secureboot

3.     Virtual Hardware version 14 or higher

4.     Enabled Support for VBS

5.     Configure VBS on the Guest OS

Enabling vTPM – while optional, it comes highly recommended. It's worth noting that vTPM isn't an absolute necessity to activate VBS Support on a VMware virtual machine. However, it's important to consider that omitting a virtualized TPM from the guest OS setup could compromise the security of Windows Defender – Credential Guard functionality (refer to the Microsoft KB article provided below for further insight).

Optimizing Security: VMware Tools and Upgraded VMware Hardware Version

What is it?

VMware Tools comprises a collection of utilities designed to optimize the performance of the guest operating system within a virtual machine and streamline virtual machine management. The hardware version assigned to a virtual machine determines the virtual hardware capabilities it can leverage. These capabilities mirror the tangible hardware components present on the specific ESXi host where the virtual machine is situated.

Why does it matter?

In terms of functionality, there are numerous compelling reasons for both installing and maintaining up-to-date VMware Tools on all individual VMs. Similar rationale applies to the Virtual Hardware version of each VM. However, it's imperative to recognize the specific security-related imperatives tied to meeting the minimum prerequisites for VMware Tools and Virtual Hardware versions, some of which have been elaborated upon earlier in this article.

Regarding the Virtual Hardware version, failing to meet the required minimums translates to the inability to activate pivotal security features, such as vTPM, VBS, EFI firmware, and Secure Boot. On the other hand, the significance of VMware Tools version, in relation to meeting minimum criteria for dependent security features, is even more pronounced. In fact, there exist documented exploits that malicious actors actively employ to compromise virtual machines running outdated versions of VMware Tools.

For instance, consider the scenario where an organization's virtual machines operate with a VMware Tools version older than 10.1.0. In this case, they're exposed to vulnerability through the "older" VIX API, an attack vector enabling unauthorized guest access without authentication challenges. To illustrate the gravity of this, a real-world example comes to mind. During a comprehensive assessment within a client's environment, a notable incident was unearthed. Collaborating with the senior administrator and the CIO's security team, we managed to attain a "blinking cursor" status within the VM and execute commands—a process achieved without any credential prompt. To amplify the concern, the accessed VM served as a Domain Controller, and the user account employed possessed solely vCenter privileges (Domain User).

The crux of the matter is clear: VMware Tools versions and their regular updates carry significant weight in ensuring the security and integrity of your environment.

What should I do?

Ensure the currency of your VMware Tools and Virtual Hardware versions. This necessitates maintaining the patches and versions of both your vCenter and ESXi host (due to their interdependency). Notably, vSphere 6.5 and subsequent iterations have witnessed significant enhancements in creating compatible VMware Tools versions, as well as streamlining deployment and updates. In instances where VMware Tools is managed by vCenter, Virtual Machines can be configured to "update on reboot." Conversely, standalone installations of VMware Tools demand more manual attention and can present some complexities when it comes to staying updated.

To navigate these updates effectively, I recommend treating them as regular candidates for evaluation during Configuration Control Board (CCB) meetings or any mechanism your organization employs for change approval. Subsequently, post-testing, it's advisable to incorporate updates into a routine maintenance or outage schedule, akin to standard application or OS patch cycles. Leverage VM Snapshots as a safety net; in case VMware Tools updates encounter hiccups, these snapshots can aid in rollback scenarios.

When it comes to Virtual Hardware Version updates, exercise a tad more caution. While this update typically involves a simple "click and reboot," it diverges from VMware Tools updates as VM snapshots won't facilitate a rollback in this configuration/update context. Similar to VMware Tools, a robust strategy involves testing, review, approval, and adherence to maintenance windows for patch cycles.

Bonus

This informative article provides guidance on utilizing not only the uncomplicated PowerCLI commands to extract VMware Tools data but also imparts supplementary insights to facilitate the comprehensive collection of all pertinent VMware Tools properties. Prior to deploying any scripts for production workloads, it's strongly advised to conduct thorough testing.

Final Thoughts

While several other noteworthy security features exist, it's important to acknowledge that this article doesn't aim to encompass an exhaustive compilation of all vSphere security elements, nor does it mimic a vBrownBag session or an all-encompassing white paper on the subject. Instead, the focus remains on features that I frequently encounter in various customer environments and during security assessments. Surprisingly, these features often receive inadequate attention, remaining unimplemented, improperly configured, or lacking planned integration. The primary objective here is to underscore these five pivotal security features.

References

·       VMware vSphere 7 Update 2: New features and enhancements (4sysops) 

·       VMware vSphere 7 Update 2: New features and enhancements 

·       Introducing support for Virtualization Based Security and Credential Guard in vSphere 6.7 

·       Windows Defender Credential Guard: Requirements

·       Protect derived domain credentials with Windows Defender Credential Guard

·       VMware vSphere 7 and Encrypted vMotion – All You Need to Know

·       VMware vSphere Security with Encrypted vMotion 

·       Enable or Disable UEFI Secure Boot for a Virtual Machine 

·       About vSphere Security (v6.7)

·       About vSphere Security (v7.0)VMware API Allows Limited vSphere Users to Access Guest OS