VSphere 6.5 is a turning point in VMware infrastructure security. What was mostly an afterthought by many IT folks only a few short years ago is now one of the top drivers of innovation for vSphere.

1. Data At Rest Encryption Standard
2. Request Encryption At Rest On Local Machine

Security has become a front and center focus of this release and I think you’ll like what we’ve come up with. Our focus on security is manageability. If security is not easy to implement and manage then the benefit it may bring is offset. Security in a virtual infrastructure must be able to be done “at scale”. Managing 100’s or 1000’s of security “snowflakes” is something no IT manager wants to do.

She/He doesn’t have the resources to do that. The key to security at scale is automation and in these new features you’ll see plenty of that. VM Encryption Encryption of virtual machines is something that’s been on-going for years. But, in case you hadn’t noticed, it just hasn’t “taken off” because every solution has a negative operational impact. With vSphere 6.5 we are addressing that head on. Encryption will be done in the hypervisor, “beneath” the virtual machine.

As I/O comes out of the virtual disk controller in the VM it is immediately encrypted by a module in the kernel before being send to the kernel storage layer. Both VM Home files (VMX, snapshot, etc) and VMDK files are encrypted. The advantages here are numerous. Because encryption happens at the hypervisor level and not in the VM, the Guest OS and datastore type are not a factor. Encryption of the VM is agnostic. Encryption is managed via policy. Application of the policy can be done to many VM’s, regardless of their Guest OS.

Encryption is not managed “within” the VM. This is a key differentiation to every other solution in the market today!

There are no encryption “snowflakes”. You don’t have to monitor whether encryption is running in the VM and the keys are not contained in the VM’s memory. Key Management is based on the industry standard,.

In vSphere vCenter is a KMIP client and works with a large number of KMIP 1.1 key managers. This brings choice and flexibility to customers. VM Keys do not persist in vCenter. VM Encryption makes use of the latest hardware advances inherent in the CPU’s today. It leverages for encryption.

VMotion Encryption This has been an ask for a long time and with 6.5 we deliver. What’s unique about vMotion encryption is that we are not encrypting the network. There are not certificates to manage or network settings to make.

The encryption happens on a per-VM level. Enabling vMotion encryption on a VM sets things in motion. When the VM is migrated, a randomly generated, one time use 256-bit key is generated by vCenter (it does not use the key manager for this key). In addition, a 64-bit “Nonce” (an arbitrary number used only once in a crypto operation) is also generated. The encryption key and Nonce are packaged into the migration specification sent to both hosts. At that point all the VM vMotion data is encrypted with both the key and the Nonce, ensuring that communications can’t be used to replay the data.

VMotion encryption can be set on unencrypted VM’s and is always enforced on encrypted VM’s. Secure Boot support For vSphere 6.5 we are introducing Secure Boot support for virtual machines and for the ESXi hypervisor. ESXi Secure Boot With Secure Boot enabled, the UEFI firmware validates the digital signature of the ESXi kernel against a digital certificate in the UEFI firmware. That ensures that only a properly signed kernel boots.

For ESXi, we are taking Secure Boot further adding cryptographic assurance of all components of ESXi. Today, ESXi is already made up of digitally signed packages, called VIB’s. (vSphere Installation Bundle) The ESXi file system maps to the content of those packages (the packages are never broken open).By leveraging that digital certificate in the host UEFI firmware, at boot time the already validated ESXi Kernel will, in turn, validate each VIB against the firmware-based certificate. This assures a cryptographically “clean” boot.

Note: If Secure Boot is enabled then you will not be able to forcibly install un-signed code on ESXi. This ensures that when Secure Boot is enabled that ESXi will only be running VMware digitally signed code. Virtual Machine Secure Boot For VM’s, SecureBoot is simple to enable. Your VM must be configured to use EFI firmware and then you enable Secure Boot with a checkbox. Note that if you turn on secure boot for a virtual machine, you can load only signed drivers into that virtual machine. Secure Boot for Virtual Machines works with Windows or Linux.

Secure Boot for Virtual Machines Enhanced Logging vSphere logs have traditionally been focused on troubleshooting and not “security” or even “IT operations”. This changes in vSphere 6.5 with the introduction of enhanced logging. Gone are the days where you’ll make a significant change to a virtual machine and only get a log that says “VM has been reconfigured”. We’ve enhanced the logs and made them “actionable” by now sending the complete vCenter event such as “VM Reconfigure” out via the syslog data stream.

The events now contain what I like to call “actionable data”. What I mean by that rather than just getting a notice that “something” has changed you now get what changed, what it changed from and what it changed to. This is data that I can “take action” against. In 6.5, you will get a descriptive log of the action.

For example, if I add 4GB of memory to a VM that has 6GB today, I’ll see a log that tells me what the setting was and what the new setting is. In a security context, if you move a VM from the vSwitch labeled “PCI” to the vSwitch labeled “Non-PCI” you will get a clear log describing that change. See the image below for an example. Enhanced/Actionable Logging Solutions like VMware Log Insight will now have a lot more data to display and present but more importantly, more detailed messages mean you can create more prescriptive alerts and remediation’s.

Data At Rest Encryption Standard

More informed solutions help make more informed critical datacenter decisions. Automation All of these features will have some level of automation available out of the gate. In future blog articles you’ll see examples for encrypting and decrypting VM’s, enabling Secure Boot for VM’s, setting Encrypted vMotion policies on a VM and a script I used to build an Enhanced Logging demo that you can tweak to show the benefits of Enhanced Logging in your own environment.

All of the script example will be released on GitHub. Wrap Up That’s it for vSphere 6.5 security! I hope you are as excited as I am about it! More details on each will be forthcoming in blogs and whitepapers.

One thing to add is the vSphere 6.5 Security Hardening Guide. This will, as always, come out within 1 quarter after the GA of 6.5.

I don’t anticipate major changes to the guide. Features like VM Encryption are not something you should expect in the hardening guide. For more information on the types of information that is now in the guide please reference. As always, I appreciate your feedback and questions. You can reach out to me via email (mfoley at vmware dot com) or on Twitter or mike.

Mike Foley is a Staff Technical Marketing Architect for vSphere Security at VMware. His primary goal is to help IT Admins build more secure platforms that stand up to scrutiny from security teams with the least impact to IT Operations. Mike is also the current author of the vSphere Security Configuration (formerly Hardening) Guide. Previously, Mike was on the evangelist team at RSA where he concentrated on virtualization and cloud security. Mike was awarded a patent (8,601,544) in December 2013 for dual-band authentication using the virtual infrastructure Mike has a personal blog at and contributes to the VMware vSphere and Security blogs as well.

Follow him at @vSphereSecurity on Twitter. October 22nd, 2016 Wow great, The new security feature of vSphere 6.5 is quit amazing. VMware has done a great job. VM encryption, vMotion encryption, ESXi Secure Boot support, virtual machine secure boot and enhanced logging is really a very good security features.

The most amazing security feature which I like the most is vmotion encryption because the encryption happens on a per-VM level. Enabling vMotion encryption on a VM sets things in motion. When the VM is migrated, a randomly generated, one time use 256-bit key is generated by vCenter (it does not use the key manager for this key). Virtual machine secure boot is also great feature because VM secureboot is simple to enable and VM Secure Boot works with Windows or Linux this is a amazing. Thanks for sharing.

The way you explained each and everything is really great. Thanks once again. November 9th, 2016 Partner supported VIB’s will work because they are signed with a cert that chains to the cert in the firmware.

Request Encryption At Rest On Local Machine

Unsigned VIBs or personally signed VIB’s won’t load if Secure Boot is enabled. De-duplication is affected because the encryption happens in the hypervisor before the I/O is written to the storage layer. Each VM has a unique key so they can’t be deduped. Check out the Encrypted vSAN beta keynote from VMworld 2016 in Barcelona for more information on a solution we are working on to provide dedupe, compression and encryption. In that model the datastore is encrypted and I/O’s are deduped/compressed before being written to an encrypted vSAN datastore. Trackbacks/Pingbacks. Comments are closed.