Announcing the vSphere 6.5 Update 1 Security Configuration Guide

I am really pleased to announce the availability of the 6.5 Update 1 Security Configuration Guide (SCG). Normally a new guide is done only for numbered releases and not updates but the number of security updates that have made it into 6.5 Update 1 has warranted this SCG release. Also, we want to show how we are progressing in making security configuration easier to implement in vSphere.

You will see in this updated guide and via the graphs below that the number of settings has been decreased dramatically. This is yet another reason why you should consider upgrading to 6.5! But first, a let’s get some frequently asked questions about the Security Configuration Guide answered.

Why do some guidelines get removed or changed?

I hear this question all the time. I’ve pointed out why in other blogs but I’ll repeat here. When I inherited the “vSphere Hardening Guide” in the 5.1 time frame it was a hand-edited Excel spreadsheet. I did my best to clean up that spreadsheet for 5.5. Doing this all in Excel had become an unwieldy task. When 6.0 came along I decided to change not only how the spreadsheet was created but how the guide itself was produced. Security was becoming a “thing” and this meant we needed better discipline in how we produced guidance.

Starting with 6.0, the SCG is now deeply reviewed before every numbered release. I sit down with engineering and we go through every single guideline the same way software engineers go through a code review. Frequently, this means we remove or modify guidelines. Invariably this causes some concerns from IT and Security (mostly Security). Here’s some guidance in what happens “under the covers”.

There are a number of reasons why items are removed from the guide:

1. vSphere code is always reviewed by Engineering and sometimes changes are implemented that render a guideline “mitigated” and no longer considered a threat vector.
   • A great example was the old “disable-intervm-vmci”. This was disabled by engineering after much review and removed from the guide in the 5.5 release.
2. Some guidelines in the past were added based on work that was proposed but never actually fully implemented or shipped. These are typically removed or replaced with guidelines that more accurately reflect the shipping code.
   • Another great example was a guideline called “verify-kernel-modules“. Many years ago that talked about verifying the digital signature of each module or binary. Folks were writing PowerCLI scripts to attempt to meet this guideline. This all changed when we moved to shipping all modules & binaries inside digitally signed VIB packages. No longer was each module needed to be signed, just the package it came in. Because we build a file system in memory that references the contents of the package, we can be assured that the modules in the package are good by just verifying the package itself. Unfortunately, the guideline did not reflect that change for a number of releases.This was replaced with verify-acceptance-level-supported. Note: You can see where we doubled down on leveraging digitally signed VIBs in 6.5 with Secure Boot enablement!
3. Some guidelines were written based on a feature but that feature was mis-understood from a security standpoint.
   • One such guideline is VM.disable-hgfs: This was mistakenly assumed as an attack vector in previous versions of the SCG/Hardening Guide. As part of the review process and with lots of discussions with engineers, it was clarified that this capability is actually only leveraged on hosted platforms (Workstation / Fusion) and not implemented in ESXi.

One of the takeaways I hope you get from this process is that we take security very seriously in the vSphere team. We are moving at a rapid pace to meet security objectives. What is somewhat unusual, to me anyways, is that this pace is faster than typical security guidance normally moves at.

An observation: What I’m finding is that the folks who are most bothered/perplexed/caught off guard by this rapid pace of updated security guidance is the security teams.

Note: You will see vSphere guidance from other industry sources and if you dig deep you will find they are based on OLD guidance. (e.g. 5.5!!) If you want the most current security guidance for vSphere then the SCG is what you should be using.

Results

The SCG review process is really starting to pay off. Many settings called out in a previous blog article were addressed as part of the SCG review for 6.5. During my review with engineering we generated a number of bug reports to correct the default values so they matched the value in the SCG. Many of these fixes show up in Update 1. This updated SCG incorporates those changes.

This has resulted in many of the VM.disable-unexposed-features.* settings being fixed in the ESXi code. Not only in ESXi 6.5 update 1 but also in ESXi 6.0 Patch 5 and 5.5 update 3 patch 11.

• One thing to reiterate here is that these guidelines were created primarily for those customers who saw settings without corresponding values. “If there is a setting there MUST be a value” is what I have been told by these extremely security conscious customers. These settings had no operational code in ESXi. They came from a previous shared code base used by the hosted products like Workstation or Fusion.

We continue to reduce the amount of work that needs to be done out of the box when you are deploying vSphere. As part of even further review, we are adding four more VM.disable-* guidelines to the list of guidelines you no longer need set.

These four are now all disabled by default. You no longer have to manually set them! The value stored in ESXi previously was a “null” value. (No value) We now explicitly set these to TRUE.

Security Configuration Guide Cleanup

Settings where the default value is now considered “secured” will be removed in the next numbered release of the vSphere SCG.

For Update releases to 6.5 these guidelines will continue to remain in the guide but the “Desired Value” and “Actual Value” will now be the same. As pointed out above, this means you do NOT have to manually set them on a per VM basis. They are only remaining in the 6.5 U1 guide with their updated values to provide continuity.

Clearing/removing these settings from a VM and then vMotioning the VM is all you need to pick up the default values.

Hardening .vs. Non-Hardening

I made the argument of changing the name of the guide when we released the 6.5 guide and changed the focus from a “hardening” guide to a “security configuration guide”. With 6.5 Update 1 we are continuing down the path of “Secure By Default”. Let’s take a look at how things have changed from 6.5 to 6.5 Update 1.

Here is the breakdown on the improvements we have from 6.5 to 6.5 Update 1.

As you can see we are building on our goal of “Secure By Default” in 6.5 Update 1. The less changes you are required to make the better the out of the box security configuration becomes and the easier it is to operational-ize security.

Download the 6.5 Update 1 Security Configuration Guide

Wrap Up

My thanks go out to Evin Hernandez from the VMware TAM team. He spent two weeks working with me as part of VMware’s “Take 2” program. This program allows employees in other business units to work on something completely outside of their normal job in an effort to introduce them to new concepts and experiences. Evin has been invaluable in helping me get this release out the door in a short period of time. Thanks, Evin!

Upgrade to 6.5!

Also, as a reminder, 5.5 will soon be end of support as of September 2018. You really should be planning your upgrades to 6.5 sooner rather than later!

Thanks for reading. If you have questions, post them here or find me on Twitter. My work Twitter account is: @vspheresecurity

mike

@mikefoley