Announcing the GA release of the vSphere Security Configuration Guide!
Rename
As I mentioned in my previous blog post where I announced the availability of the Security Configuration Guide (SCG) Release Candidate, the term “Hardening Guide” will no longer be used starting with vSphere 6.5. Only an increasingly small subset of the settings are truly “hardening”. It’s mostly about configuration and auditing of settings.
Review, Change, Repeat
One of the things I always heard from customers over the years is “Why can’t you ship things secure out of the box”. While we are moving in that direction for those settings we can set, one thing to note is that 65% of today’s guide contain settings that VMware can not set for you or settings that we have already set that should be audited to check to see if the default value has been changed.
Every release we (myself and engineers) review all the settings and “clean house”. Everything is questioned. I started this review process for the 6.0 release and quite frankly, it upset a few apple carts. The guide at that time had grown like a set of firewall rules. As the guide grew over the years, nobody wanted to change anything because they didn’t know what the fallout would be. In my opinion, that is NOT a way to run your security operations. Security in this era DEMANDS that you always question the status quo.
To learn more about the changes in 6.0, I highly recommend you read this blog and the blogs it references. (1st & 2nd)
Because of this review process, we are making great progress towards shipping “secure by default” and that effort will be ongoing .
Deleted guidelines
With 6.5, we went line by line through all of the settings, especially all of the VM.* settings. The items deleted this time around are a result of this ongoing review process. We delete settings for many reasons. Maybe an engineer has made changes to how they operate? Or code was removed? Or we changed the default setting to the “hardened” value? I won’t get in to the specifics of each deleted setting but I will give some examples of our process.
The first example would be the VM.disable-VMTools-autoinstall guideline. This was removed for two reasons. One was because in 6.5 the tools process will only mount tools ISO that is digitally signed, ensuring. Second, the upgrade policy on ESXi is to force a manual install! So, the setting wasn’t really doing what the vulnerability discussion intended!
Another example was vCenter.verify-nfc-ssl. This was removed because we no longer support the C# client. This setting was originally put there because even though the default value in the code was to use SSL for Network File Copy transactions, the C# CLIENT ignored that unless the value was set explicitly! Now that we don’t support the C# client anymore, that guideline was removed.
Here is the list of deleted settings:
1
2
3
4
5
6
7
8
9
VM.disable-VMtools-autoinstall
VM.disable-unexposed-features-biosbbs
VM.disable-unexposed-features-getcreds
VM.disable-unexposed-features-toporequest
VM.disable-unexposed-features-trashfolderstate
VM.disable-vix-messages
VM.prevent-device-interaction-connect
VM.prevent-device-interaction-edit
vCenter.verify-nfc-ssl
New Columns
One of the main changes you will see with the new SCG is a few new columns.
We’ve added a DISA STIG guideline ID’s column, a “Hardening” column and a “Site Specific Setting” column. The first helps out the team working on the DISA STIG‘s and for those in the US Federal space so they can cross reference.
The Hardening and Site Specific columns are there to help show you which settings are actual hardening settings and which are clearly settings that VMware can’t necessarily provide default values for.
Finally, we added the “Audit Setting” column. This should guide you towards which settings are those that require you to check that the default value may have changed.
Now, there are a number of these types of settings, specifically the *timeout settings, that you may wish to change to be different from the default VMware values. These changes may be corporate standards or regulatory standards that demand the change from the shipped values. That’s ok! The default VMware values are those prescribed by VMware’s Security Team and are considered “secure by default”. In these cases, both “Audit Setting” and “Site Specific” will be checked.
New Settings
One of the new settings I’ve added for this guide is ESXi.Audit-SSH-Disable. SSH is disabled by default for ESXi and this setting essentially says “Make sure someone hasn’t changed that”. This would be considered an “Audit” setting.
In the 5.5 Update 1 Hardening Guide I had added two settings that, for some reason, didn’t make it over to the 6.0 guide. They are VM.Enable-VGA-Only-Mode and VM.disable-non-essential-3d-features.
The first one, enable VGA Only mode, disables the SVGA functionality for this VM. You should only use this setting for systems than can be managed without needing an SVGA driver. An example would be a VM that only has a console and not a GUI. This is a Site Specific setting and as such, it’s left up to you to decide whether to implement it. I did not mark it as a “hardening” setting because I don’t want people setting this on all VM’s and finding out they can’t log in!
The second, disable 3D, is a default setting in ESXi so this means it’s an “Audit Only” setting for most VM’s. Its purpose is to ensure that you know exactly which VM’s have 3D enabled and ensure only those VM’s that need it would have that. It makes no sense to enable 3D on a Windows Server virtual machine IMHO.
What the Security Configuration Guide is not
I’d like to take this opportunity to remind folks what the vSphere Hardening Guide and/or the vSphere Security Configuration Guide is and is not. It is not meant to be used as a “compliance” tool nor a set of boxes to check. It is not a set of mandates. Blanket application of ANY changes to a system should be carefully reviewed before being made. It is a set of guidelines that attempts to explain risk and start a risk management conversation between IT and security and “guide” both teams into setting up the product in a secure fashion.
The guide should not be used as a barrier to implementing a deployment. Especially now that so few settings are actual “hardening” steps. There are no gaping holes as I pointed out in the previous blog! Standard settings like configuring logging, applying patches, using Lockdown Mode, ensuring things like promiscuous mode are turned off, etc will be there for every release. Any dramatic changes from a security standpoint will only be to enhance security, not open up holes that need to be closed. Any additions going forward will, as API’s become available, be used to set things that need to be done by hand today. The guide is about automation because only through automation can we secure at scale.
Wrap Up
There have been no major/technical changes between the Release Candidate and the GA version of the guide. Minor updates in grammar and wording of remediation and assessment steps were the primary changes.
One of the things I always heard from customers over the years is “Why can’t you ship things secure out of the box”. While we are moving in that direction for those settings we can set, one thing to note is that 65% of today’s guide contain settings that VMware can not set for you or settings that we have already set that should be audited to check to see if the default value has been changed.
