I’m really excited to share with you all of the new security features available now in vSphere 6.7! The goals of security in 6.7 are twofold. Introduce more “easy to use” security features and “meet requirements set by customers IT and Security teams”. With vSphere 6.7 we have achieved both goals. Let’s dive into some of the new features and changes.
TPM 2.0 support for ESXi
As many of you know a TPM (Trusted Platform Module) is a device on your laptop, desktop or server system. It is used to store encrypted data (keys, credentials, hash values). TPM 1.2 support has been around for many years on ESXi but was primarily used by partners. TPM 2.0 is not backwards compatible with 1.2 and required all new device drivers and API development. The Trusted Computing Group has a great overview on what a TPM is and does.
ESXi’s use of TPM 2.0 builds upon our work in 6.5 with Secure Boot. In a nutshell, we validate that the system has booted with Secure Boot enabled and we take measurements and store them in the TPM. vCenter reads those measurements and compares them with values reported by ESXi itself. If the values match, then the host has booted with Secure Boot enabled and all the good stuff such as only running signed code and the inability to install unsigned code is assured. vCenter will provide an attestation report in the vCenter web client showing you the status of each host.
Virtual TPM 2.0 for VMs
In order to support TPM’s for virtual machines our engineers created a virtualized TPM 2.0 device. It shows up in Windows as a normal TPM 2.0 device. Like a physical TPM, it can do crypto operations and store credentials. But how do we secure data stored IN the virtual TPM? We write that data to the VM’s nvram file and secure that file with VM Encryption. This keeps the data in the vTPM secured and it “travels” with the VM. If I copy that VM to another datacenter and that datacenter is not configured to talk to my KMS then the data in that vTPM is secured. All the same VM Encryption rules apply.
Note: only VM “home” files are encrypted, not VMDK’s unless you choose to encrypt them.
Why didn’t we use the hardware TPM?
A hardware TPM has many limitations. It’s a serial device so it’s slow. It has a secured nvram storage size measured in bytes. It’s not designed for accommodating 100+ VM’s on a host. It won’t be able to store all their TPM data on the physical TPM. It would need a scheduler for the crypto operations it does. Imagine 100 VM’s trying to encrypt something and depending on a serial device that can only do one at a time? Ugh.
Even if I could physically store the data, consider a vMotion. I would have to securely remove the data from one physical TPM and copy it to another. And re-sign data with the new TPM’s keys. All of these actions are very slow in practice and fraught with additional security issues and requirements.
Note: In order to run virtual TPM’s, you will need VM Encryption. That means you will need a 3rd party key management infrastructure in place. See the list of supported KMS and my blog on KMS topology.
Support for Microsoft Virtualization Based Security
Your security team will probably ask for/demand “Credential Guard” support. This is it.
Back in 2015 Microsoft introduced Virtualization Based Security. We have worked very closely with Microsoft to provide support for these features in vSphere 6.7. Let’s do a quick overview of what is going on under the covers to make this happen.
When you enable VBS on your laptop running Windows 10 the system will reboot and instead of booting Windows 10 directly the system will boot Microsoft’s hypervisor. For vSphere, this means the virtual machine that was running Windows 10 directly is now running Microsoft’s hypervisor which is now running Windows 10. This is called “nested virtualization” and it is something that VMware has a HUGE amount of experience with. We have been using nested virtualization in our Hands On Lab’s for years.
When you enable VBS at the vSphere level that one checkbox is turning on a number of features.
- Nested virtualization
- IOMMU
- EFI firmware
- Secure Boot
What this will NOT do is enable VBS within the VM’s Guest OS. For that you would follow Microsoft guidance. This can be done with PowerShell scripts, Group Policies, etc.
The point being is that vSphere’s role is to provide the virtual hardware to support enablement of VBS. Combined with a virtual TPM you can now enable VBS and turn on features such as Credential Guard.
If you are building Windows 10 or Windows Server 2016 VM’s today I would HIGHLY recommend you build them with EFI firmware enabled. Moving from traditional BIOS/MBR to EFI (UEFI) firmware after the fact introduces some challenges later on down the line.
UI Updates
In vSphere 6.7 we have made a number of leaps in the functionality of the HTML5 (H5) web client. I use it all the time now. It’s fast, well laid out and complete for just about every task I run in my lab. In order to make things easier for the administrator from a VM Encryption level we have made some changes. In the background we are still leveraging Storage Policies, but we have combined all encryption functions (VM Encryption, vMotion Encryption) into one panel in VM Options. I think you’ll find this to be a more logical workflow.
Multiple SYSLOG targets
This is something I’ve personally wanted for a long time. I helped get the 6.5 logging enhancements out the door a number of years ago and one of the requests I’ve had is the ability, from the UI, to configure multiple SYSLOG targets. Why? Some customers want their SYSLOG stream going to two places. For example, IT and InfoSec teams. IT folks LOVE VMware Log Insight. InfoSec teams typically use Security Incident and Event Management systems that have specialized functions geared directly toward security operations. Now both can have an unfiltered stream of SYSLOG events going to their respective targets. The VAMI UI now supports up to 3 different SYSLOG targets.
FIPS 140-2 Validated Cryptographic Modules – By Default
This is big news for our US Federal customers. Within vSphere (vCenter and ESXi) there are two modules used for cryptographic operations. The VM Kernel Cryptographic Module is used by our VM Encryption and Encrypted vSAN features and the OpenSSL Module is used for things like certificate generation and TLS connections. These two modules have passed FIPS 140-2 validation.
Now, does that mean that vSphere is “FIPS Certified”? Well, some incorrectly use the terms interchangeably. To be “FIPS Certified” actually applies to a full solution of hardware and software that is tested and configured together. What we have done at VMware is make that process a whole lot easier for our partners to certify vSphere for FIPS operations. We look forward to seeing this happen in the near future. What a typical vSphere customer should know is that all crypto operations in vSphere are being done using the highest standards because we have turned on all FIPS 140-2 cryptographic operations BY DEFAULT.
Wrap Up
More info will be coming very soon in the form of blog articles and FAQ’s. For example, there will be a TPM and virtual TPM FAQ available on vSphereCentral. That should address MANY of your questions!
There you have it. LOTS of new security stuff. What you’ll see here is that we introduce new features like Secure Boot for ESXi and VM Encryption and then layer new functionality on top of them like TPM 2.0 and virtual TPM respectively. I expect this pattern to continue going forward.
We are committed to providing best in class security while at the same time paying extra attention to making security easy to implement and manage. I’d like to thank all of the VMware R&D teams for their outstanding work in this release. They do the hard work to make security easier for you to implement and manage! Know this: The future is bright in vSphere Security Land!
Thanks for reading!
mike
