vSphere Security Configuration Guide (SCG)
The hardening is one of those areas of vSphere that doesn’t receive a lot of attention. Probably due to the fact that many administrators feel like their environment is not critical enough to justify implementing extra security measures at the hypervisor level that will drown them in complexity. While it may be partially true in some cases, following the vSphere SGC is not as daunting as it appears. In fact, it has been significantly simplified over the years thanks to Mike Foley’s work.
What is the vSphere Security Configuration Guide?
Called Security Hardening Guides until vSphere 6.0, these are documents that provide guidance and best practices for customers on how to deploy and operate VMware products in a secure manner. It also provides a way of creating compliance objectives and meet regulatory and local security standards. The guides for vSphere come in an intuitive spreadsheet format, with rich metadata to allow for guideline classification and risk assessment.
In the guide, you will find a short and detailed explanation of each security measure, different ways of implementing it whether it is using the UI or CLI. Comparison documents are provided that list changes in guidance in successive versions of the guide. One of the great things is that it specifies VMware’s recommended values, the default value, and if the default value is the recommended one.
During the switch from 5.5 to 6.0, the hardening guide received a good spring cleaning by the security teams over at VMware to make it more relevant and usable for customers. They moved all the “best practice” and “operational” related topics over to the documentation in order to leave in the guide things that can be checked via API’s, CLI’s and other tools for attestable values.
In the earlier versions, there used to be more than 170 settings listed in the hardening. In version 6.5 update there are only 68. This is mainly due to changes made in the code to implement some of them out of the box. This was done towards a goal of achieving a ‘Secure-by-default’ approach in the delivery of VMware products.
Is everything Security Hardening?
What is Hardening?
Hardening can be defined as follows (Wikipedia): hardening is usually the process of securing a system by reducing its surface of vulnerability…
In the case of the security guide, not everything is actually hardening as a lot of the guidelines are related to the environment of the administrator or just have a purpose of Auditing to ‘tick the box’.
Mike Foley over at VMware produced a breakdown of what is hardening and what is not. It turns out most guidelines are not.
Risk profiles
The guidelines of the Security Guide are each assigned a risk profile on a scale going from 1 to 3. 1 being the most secure guidelines that are most likely not needed by most customers and 3 being those considered a “must have”.
- Risk Profile 1: guidelines that only be implemented in the highest security production environments, e.g. top-secret government or military, extremely sensitive data, etc
- Risk Profile 2: guidelines that should be implemented for more sensitive production environments, e.g. those handling more sensitive data, those subject to stricter compliance rules, etc
- Risk Profile 3: guidelines that should be implemented in all production environments
Guideline ID
This is the first column of the guide. It tells you quickly what this guideline is about and what component is concerned. E.g. ESXi.enable-strict-lockdown-mode. The first field tells you whether it’s related to a VM, a Host, the network, vCenter… Some are less obvious than others or related to more obscure settings like VM.disable-hgfs.
In this case, you will find more information in the Description field and the background of why the guideline is here in the Vulnerability Discussion field.
There is a lot to learn from the Vulnerability Discussion fields as they provide in-depth insight and history on settings and best practices that may have been unknown to you until now. I suggest that you have a quick look at all of them out of curiosity, you might uncover a few gems!
Values
The part of the guide that is, in my eyes, one of its greatest, are the values presented by VMware. Only 3 fields here that will help you quickly assess what needs to be done in your environment.
- Desired Value: The value that VMware recommends for this setting. It does not mean that you should absolutely use it. You may think that 900 seconds is too aggressive for the account unlock time (desired value) but 120 seconds is too quick (default) so you may want to go for 360 or something else. Again, the hardening guide provides guidance, not the universal truth
- Default Value: As the name suggests it, this field tells you what the setting will be out-of-the-box straight after installing ESXi. Not much more to say here
- Is desired value the default?: Self-explanatory. Useful to quickly see if you need to consider changing the settings
Again, don’t take the desired value field as what you should use but as what VMware recommends you to set if you are not sure. You may very well have a different opinion than them and that is a good thing because it means you know what you are doing.
Even so VMware cannot make recommendations on the value of all the guidelines as a lot of them are what they call Site Specific. Meaning it will greatly depend upon your environment and your security policies. For instance, VMware cannot tell what NTP server to use as you might use a private one, a European one, an American one, and so on. What they can do is recommend that you set an NTP server.
Negative functional impact
Changing a setting to be compliant with strict security measures is a good thing and it will make your security officer happy to see that you are involved. However, you should always know what will happen when you make the change and what behavioural change will it cause.
Take the Strict Lockdown Mode for instance. It ensures that all interaction occurs through vCenter server by disabling the DCUI… It is classified as a Risk Profile 1 so very few people will make use of it. However, if you do want to use it, be aware that you may have to completely reinstall the host should it lose access to vCenter. The Negative functional impact field helps you avoid surprises like these by warning you of possible consequences.
Assessment and Remediation
Assessing your environment is an important part of the journey towards security compliance. You will see what is currently configured and what should be modified.
When it comes to actually checking your environment and how to configure the guidelines, you have 3 main different methods of doing so that are described in the guide.
- VSphere Web Client
- ESXi Shell Command / vCLI
- PowerCLI
For each of these, you are provided with the procedure or command on how to assess the current value and how to amend it. The most versatile way to work with is probably PowerCLI.
Conclusion
There is plenty more to say about the security but the Security Configuration Guide is a good place to start. However, don’t think that going through the guidelines and checking the box will make you ‘hacker proof’. As mentioned previously a lot of the guidelines from the 5.5 guides have moved to the documentation so make sure to give it a go as well.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
