Back in March I released the vSphere 6.5 Update 1 Security Configuration Guide (a.k.a “The SCG”). At that time, I went in to detail on more than just the guide. I covered the topic of why some guidelines are removed or changed. I also covered how more settings were set to “secure by default” now and showed the progress between the 6.5 guide and the 6.5 Update 1 guide.
The first big change is that I have come up with a new category for settings that have been fixed in the code of ESXi or vCenter and no longer need to be manipulated anymore. This new category is called “deprecated”. We recommend that you no longer change these settings. There is no active code in ESXi that these settings change. We fixed them to match previous guide values so that you can stop “managing” them. This is done to lessen the IT burden of security.
All settings fitting this category are released in a separate Excel spreadsheet. By sunsetting these settings and moving them out of the guide the SCG will now be only 50 settings in total. This is a decrease from 68 in 6.5 Update 1. Many of these settings were called out in an earlier blog from June 2017 entitled “Secure By Default – VM.disable-unexposed-features”.
Some customers may wish to consider these deprecated settings as “Audit Settings”, meaning that you may wish to check to see if someone has set them. Setting them adds no value and only increases the management burden. You can safely remove these settings from your configurations.
Risk Profiles Goes Away
The second big change is that I’m sunsetting the use of “Risk Profiles”. Now, I’m sure that this will panic many as some may consider this a big change. Honestly, it’s not. Here’s why. Of the 50 remaining settings in the guide only one was at “Risk Profile 1”. Everything else was at either 2,3 or 1,2,3. The value that Risk Profiles brought just wasn’t there anymore. The work we have been doing to deprecate settings is paying off.
The Risk Profile 1 setting was “ESXi.enable-strict-lockdown-mode”. The companion or flip side of that was the setting “ESXi.enable-normal-lockdown-mode” which was Risk Profile “2,3”. It was either one or the other. You couldn’t do both. That was confusing to some people and the first setting was really the only reason to keep Risk Profiles around. So, instead, I added content to the Vulnerability Discussion of both settings that addresses the risk discussion.
Hardening .vs. Non-Hardening Part Deux
As I mentioned in the 6.5 Update 1 blog article, in 6.5 I renamed the guide from the vSphere Hardening Guide to the vSphere Security Configuration Guide. This was done because the number of “Hardening” guidelines was eclipsed by the number of settings that VMware can’t set for you (a.k.a. “Site Specific”) or settings you should audit to ensure someone hasn’t set them to the non-default value without good reason (e.g. “SSH is enabled on ESXi. It’s off by default”).
For the 6.7 U1 SCG, one of the guidelines I changed from “Hardening” to “Site Specific” was the “vNetwork.enable-bpdu-filter” setting. Why? Because it involves coordination with a hardware switch and the use of BPDU packets within a Windows VM. This is a corner case scenario and as such should actually have been classified as “Site Specific”. Does it provide a “hardening” function? Yes, by adding protection against Spanning Tree Loops. But again, it’s not a “normal” occurrence.
Progress
See this video and you’ll see how far we’ve come.
All of this work has lessened the load on the VI Administrator. In 6.5 we had 24 settings that were considered “Hardening”. This dropped to 10 in 6.5 Update 1 and now down to just 5!
Wrap Up
Going forward, I really want to shrink that to one hardening guideline called “Apply Patches”. Unfortunately, we’re not there yet but I think the progress we’ve shown from 6.0 to 6.5 to 6.7 shows you that we are not standing still! Should any new automation functions appear you may find new settings being added to a future guide. I’m always re-evaluating the capabilities that get added to new releases and updates.
I’d like to thank the engineers that have helped me get the SCG to a better place by fixing code to match the values called out in previous “hardening” guides.
mike
If you have questions that haven’t been answered you can reply here, send them to mfoley at vmware.com or via Twitter to @vspheresecurity. @vspheresecurity is a curated list of vSphere Security specific tweets.
