Security Configuration Guide? What’s that you ask? That’s what now used to be called the “vSphere Hardening Guide”. Well, I didn’t come up with that name, folks who created it many, many years ago called it that. But like everything else in this world, change comes and change is good.
History
When the Hardening Guide was conceived the world was a different place. There was no ESXi with its limited attack surface and small size. It was what became “ESX Classic”. A hypervisor with a full blown Linux VM that ran all of the management functions. When we stripped that out and went to ESXi we dropped the number of security issues by around 90%.
When the guide was conceived security wasn’t quite the “thing” it is today. Workloads were only just getting moved to production on ESX back then. Security folks were only just barely starting to notice this and started asking good questions. Our marketplace started on its path to maturity. Not unlike the many changes in our industry that have happened before (If you were around for the start of the PC revolution it was the wild, wild West in terms of security!). Time to market and the excitement of selling and nobody really asking too much about security was the modus operandi.
Evolution
My how times have changed. Now everyone is asking about security out of the gate. The threat vectors and attacks have changed and the targets are constantly shifting. But we here at VMware have been responding. Especially so over the past 3 to 4 years. First, we started by moving to a “secure by default” mindset when it came to security. Security was always there but it usually meant “tightening the screw” to achieve the desired results.
Today, we ask ourselves “Can we ship this “hardened” and then it’s up to the customer to loosen the screws if he/she sees fit?”. Second, we are constantly evolving our architecture. We track all the latest research and come up with strategies to mitigate future threats. That’s why you see actions like the disablement of Transparent Page Sharing a couple of years ago. These efforts are done under an abundance of caution, long before the threat can be made into something actionable.
Is it really hardening?
So, with all of this work to make things more secure, is the guide really “hardening” things? Based on my findings, not nearly as much as you would think. For vSphere 6.5, only 35% of the settings are “hardening”.
“Non-Hardening” means that either the default setting is the desired setting or the setting is a “Site Specific” setting meaning it’s something VMware can’t set for you. An example would be the IP Address for your NTP server.
Ok, you might think that 35% is a lot. After all, it’s 24 settings out of 68! Well let’s break down those settings.
Of these settings 18 are under the VM.disable-unexposed-features.*banner. These are all “Risk Profile 1” settings and as I called out in a previous blog, they have little to no code in the ESXi hypervisor and are mainly interesting only to those customers who believe every setting must have a value even if there is no code backing it. (In other words, NOT a gaping hole situation)
That leaves 6 more settings. Let’s break them down.
3 are to set a standard vSwitch’s settings from accept to reject.
1 is for the BPDU filter setting
1 is “Apply your ESXi patches”… Not exactly “hardening” but whatever
1 is “Disable TLS 1.0/1.1”
The last, disabling TLS 1.0/1.1 , is not turned on by default because if we did that and you had 3rd party software that accessed systems using TLS 1.0 or 1.1, the connection would break. We offer a simple tool to disable these versions so running that tool would technically be considered “hardening. You would run this tool only after you’ve determined that 3rd party software accessing your infrastructure (Backup, monitoring, etc) supported TLS 1.2.
What this shows is that we’ve made great strides towards “secure by default”. There are many settings VMware can’t set and those are “Site Specific”. There are very few that fall under the classification of “hardening” and 75% of those don’t have a big attack surface. We will continue our move to even more “secure by default”. Security is part of our DNA and I can say that because I see the real interest when I discuss things with engineers who are VERY proud of the code they write and strive to make it the best they can.
Together we spent a lot of time diving deep into the settings in the guide, reviewing code paths and validating settings. We do every time I release a new version and we continue make great strides each time we go through this exercise. That process never stops. That’s because security will always be a journey. We’ll never get to that mystical place called “Secure”. There will always be new and evolving threats. What you should expect of us is to evolve and respond to those threats. We’re not sitting still. Neither should you.
Details
There are three new columns in the SCG. “Hardening”, “Site Specific” and “DISA STIG”. The first two are self-explanatory. The last references the matching guideline in the Defense Information Systems Agency’s Security Technical Implementation Guide. More info on that is here: https://www.stigviewer.com/stigs
Deleted Guidelines
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
These are the result of the code reviews I did with our engineers. There are solid reasons for each of them and they vary from “no longer implemented” to “we closed that years ago”. The final one, verify-nfc-ssl, was removed because we dropped support for the C# client. NFC SSL has always been turned on but the code in the C# client looked for an explicit “TRUE” value before it would do the SSL handshake. Seeing as we dropped the client, we could drop the setting.
Wrap Up
It’s for these reasons I decided to rename the Hardening Guide to the Security Configuration Guide. And with this blog post I’m happy to report that the Release Candidate of the vSphere Security Configuration Guide is now available.
Please respond here, in the Communities forum or via email (mfoley at vmware dot com) with your feedback ASAP. I want to release the final on Thursday April 13th. At that time it will go up on the normal “Hardening Guides” location at vmware.com.
