Just got this today from our Center for Policy Compliance guys.  🙂

CP&C is pleased to announce the availability of the Defense Information Systems Agency (DISA) VMware vSphere 5.0 compliance toolkit that is aligned to version 1 and release 3 (V1R3). The benchmark availability announcement was made on 30-Sep-2013 and we churned it pretty quickly! You can download the package using CCW tool and begin to use it.

If you use our vCM product you should download the new toolkit for this update.  As stated above it aligns with V1R3 of the STIG.

*** Update ***

The ESXi 5 STIG for ESXi Server and vCenter Server is now at version 1 revision 3.  The only difference between revision 2 and 3 is the removal of some IAVM findings incorrectly included in the previous release.  The certificate requirements have still been pulled and the below information valid for revision 3.


Ok, so yesterday DISA released the ESXi 5 Version 1 Revision 2 of the STIG.  Now this is only Revision 2 of the ESXi 5 Server and vCenter Server STIG, not the VM.  That is still at revision 1.

Why did they do it?  Just one thing, the removal of  the rule The system must not use default self-signed certificates for <ESXi / vCenter> Communication.  So, if you want to follow the STIG, you no longer have to replace the default certificates provided, or you could replace them with an internal CA.

Why did they do this?  Well, there’s a reason, but not one I’m going to put here on a public blog.  If you’d like to know why just ask your SE.  I will have either already informed them, or they can reach out to me for the information internally.

Note: This article covers material present in Version 1 Revision 3 and below.  Topics found below may be mitigated in the most current version of the ESXi 5 STIG.  Ensure you are using the most current version of the DISA STIG documents.

So we need to talk about GEN005537-ESXI-000111 – SSH Daemon Must Use Privilege Separation for a moment.  There’s a lot of confusion around this finding so let us sort through it together.

First off let’s draw a line in this discussion, nothing can be done about this on ESXi 5.0.  The setting just will not work.  The reason?  We did not compile chroot into ESXi 5.0.  However, in 5.1 and 5.5 it is absolutely configurable, with a little finesse and TLC.  Let’s take a look.

Note: The following instructions are not supported by VMware, nor were they tested in any way, shape or form by QA, so I cannot guarantee how they will react in your environment.  Please implement this on an isolated or single host first to make sure there are no unintended consequences.  To date I have not seen any reports of the below settings, if applied correctly, causing issue.

In addition to this article you are going to need to review Blog Series: ESXi 5 STIG – File and Setting Persistence.  This is necessary because we need to create the default chroot location for the privilege separation user.
Continue reading

For years now as VMware has traveled down the path of the Virtual Appliance.  It’s nothing new, but the approach has changed thanks to a few very key people within the company.

The Virtual Appliance of the past typically almost never saw an OS patch, rarely was hardened, and quite frankly scared Federal Admins and IA groups for those reasons.  Truth be told, they all wanted to use them, but getting it approved was just too much of a hurdle.  That is quickly changing, and some of it has already and you didn’t even know it.

With 5.5 on the horizon you’re going to see a new breed of Virtual Appliance for products such as vCenter Server and vCenter Orchestrator that are all based upon a common OS, common set of services, and a common set of hardening.  No more one-offs, everything is going to a standard.  What does that mean for you?  A great deal from both the administrative and security point of view.

Continue reading

Note: This article covers material present in Version 1 Revision 3 and below.  Topics found below may be mitigated in the most current version of the ESXi 5 STIG.  Ensure you are using the most current version of the DISA STIG documents.

Ah the dreaded STIG. For many, a necessity by way of policy, but an implementation headache for all. Sadly the ESXi 5 STIG, released at V1R1 on August 9th 2013, will be no different.

In the spirit of VMFieldTips I will be taking you on a journey over the next few weeks through the ESXi 5 STIG. I will hit the head scratchers, problem points, and the just plain crazy.  Also, where appropriate, I will try and loop in the official VMware Security Hardening Guides if possible.  I know @mikefoley will be proud.

What this blog series is not:  It is not an official implementation guide by any means.  It is a compilation of questions and answers from the field on how to address, or in some cases securely work around, the findings in the ESXi 5 STIG.  It is completely open for comment and can be driven by you.  If I have not covered a specific finding yet, ask me for it.  If you have a better way, throw it into a comment on the article.  I will review, discuss, and possibly even add it into the article itself.  Blogs are a way to learn, share, and in this case overcome and intense feelings of insanity as you muscle through the ESXi 5 STIG.

The ESXi 5 STIG is made up of three parts, ESXi Server, vCenter Server, and VM (vmx).  I will start this series off in the ESXi Server portion of the STIG, a few findings at a time to reduce the time between posts.  Already, just from the start, we are going to have our work cut out for us.

Posts that are a part of this series will be linked below.  I will also provide the full STIG ID(s) in each post for easy searching and Google indexing.  Ok, now let’s get to it.

Blog Series Table of Contents:

Blog Series: ESXi 5 STIG – ESXi Server SSH Daemon

Blog Series: ESXi 5 STIG – File and Setting Persistence

Blog Series: ESXi 5 STIG – ESXi Server SSH Client

Blog Series: ESXi 5 STIG – ESXi Server Password Complexity Requirements