Many vendors have security hardening guides - step-by-step guides to increasing the security posture of one product or another. We alluded to the Cisco guides earlier this month (Day 11), Microsoft also makes a decent set of hardening guides for Windows server and workstation products, as do most Linux distros - you'll find that most vendors have documents of this type.

VMware's vSphere hardening guide is one I use frequently.  It's seen several iterations over the years - the versions considered current are all stored at:  http://www.vmware.com/support/support-resources/hardening-guides.html

The initial guide for ESX 3.x (back in the day) was mostly CLI based, with commands executed mostly within the Linux shell on the individual ESX hosts.  Things have changed quite a bit since then (and no, that wasn't a reference to the amount of grey in my hair!), the current version (5.0) covers the entire vSphere environment, it discusses settings for the ESXi hosts, the Virtual Machine guests, the Virtual Network (and physical network), the vCenter management platform and vCenter Update Manager. 

From an both an auditor and a system administrator perspective, there are a number of "oh so cool" factors to this standard that make it a great example for vendor security documentation:

There is a clear description of why you might make any specific configuration change.  The security exposure is clearly explained for each setting discussed, along with the severity.

Every setting is not a recommended setting.  They are very clear that some security changes are recommended in all cases.  Others might only be recommended for DMZ settings, or some other exceptional circumstances.  For each setting, they discuss in what situation that change would be deemed neccessary

Some security changes will break functionality that you might be expecting, for instance it might disable something in vcenter, or it might break vCLI (a remote cli command line api) functions.  If a setting affects functionality, it is clearly spelled out.

There are several ways to get the job done.  For each benchmark setting, several methods for effecting that change are discussed.  Often there'll be a setting to tweak within vCenter, but whenever possible they'll also discuss how to accomplish the same task from a remote command line, either from Powershell (using the PowerCLI api) or from a remote windows or linux command line (using their VCLi api command set).  For instance, for something as simple as setting NTP (Network Time Protocol), they cover off:

• How to set NTP services up for the ESXi host in the vSphere Client application
• What config file is updated (/etc/ntp.conf)
• From the vCLI (Virtual Command Line), how to audit this setting using vicfg-ntp.  Note that all the vCLI commands are run from a remote host (Linux or Windows), so this is a great audit tool!
• How to update this setting using the vCLI, again, using vicfg-ntp
• How to list the NTP settings from all hsots in an environment using PowerCLI, vMware's Powershell API.  Again, this is remotely run from a Windows host with PowerShell and the VMware PowerCLI installed.
• How to update all hosts in an environment using PowerCL
• And finally, am external link for more information

Audit is not neglected in this document.  Not only do they tell you how to make each change, they show you how to audit that change, to get the current value of the affected settings.  Again, whenever possible, they discuss how to do the audit steps from as many toolsets as possible.  You'll find that if you are an auditor looking at 10 servers, or a consultant working with a different client each week, the CLI approaches have a lot of appeal.  Not only are they much quicker, but they are less prone to error, and you don't have to rekey anything.

So, if you are an auditor, or a consultant who sees many clients, or a System Administrator who just wants to keep tabs on their environment,  from this guide you can easily and simply create your own audit scripts.  With these scripts in hand you are able to get accurate, repeatable security assessments (based on a published standard) of a vSphere environment. 

This means that you are delivering exactly the same security assessment for each client's environment.   However, while the assessment is the same each time, the recommendations will not be - remember that there is a severity value for each assessed value, and also a discussion of in which situation each setting is recommended - the recommendations will vary quite a bit from one client to the next.   Even if you are an auditor within a single organization, you'll find that results will vary from one audit to the next.  Remember that this is an evolving standard - recommended settings change from one version of the guide to the next.  You'll also find that when you combine security assessments with risk assessments (this is almost always desired), the risk equation will change depending on how the impacts are phrased, what has happened in the organization recently, or who is involved in the discussion.

Security is unique in the fact that while the questions will be consistent over time and between organizations, the answers will change.  You'll see them vary over time, across versions of a product, in different deployment situations and between organizations.  I think this benchmark is a good example of a standard that is well equipped to handle this shifting landscape.

(You'll find the vSphere Hardening Guide covered cover-to-cover in SANS SEC579)

If you have any stories this article, or on this or other vendor security guides, please share - use our comment form.

===============
Rob VandenBrink
Metafore