This post will be a little outside the norm for my blog in that I’ll be reviewing software, an Alpha release from a company called Keybase.

Let’s start out by looking at public key cryptography between two individuals.  A work flow that is somewhat common and in today’s day and age, where privacy should be of the utmost concern between even the most basic of Internet users, but still somewhat difficult to achieve for anyone that’s not an advanced user.

Before we go any further, a level set.  This post will not dive into the working of public key cryptography, the differences between certificate based and an approach such as GnuPG, or the pros and cons of each beyond what’s needed to illustrate various points.  There are multiple posts online that cover these topics and I encourage you to become familiar with them if you are not already.  I am also simplifying some aspects of how public key cryptography works in order to convey a point to the widest possible audience.

Continue reading

For too many years the responsibility of security in software has landed squarely in the lap of the customer.  That’s YOUR lap, if you’re keeping track, but I’m not telling you anything you don’t already know.  I’ve been there and I know that pain, all too well.

The process typically looks like this.  You install a product then you spend days or weeks tweaking it to a hardening guide from the company that wrote the software.  Even worse if you’re hardening to a guide or instruction that the vendor had absolutely no hand in writing at all.  We call that Hardening in the Blind, and that’s a whole other topic I’ll save for another post.  It happens far more often than you think, especially in the DoD community.

So if there are hardening guides for a product why can’t those requirements be inherent within the platform?  Why must they be bolted on to the product, an afterthought if you will?  I’ve been asking myself that question for years, and I know it has crossed your minds as well.

Continue reading

Discussed in my previous post, Nutanix NOS 4.1.1 and the SecDL, we have released three new Nutanix Security Technical Implementation Guides (STIGs) embedded within NOS 4.1.1.  In this post we will take a quick look at what the Nutanix methodology is around the creation of all three.

Those of you in the Federal or high-governance spaces are more than familiar with NIST and DISA provided security requirements.  NIST being in the form of Special Publications (SP) and DISA providing Security Requirements Guides (SRG).  These are the building blocks of all STIGs and hardening guidelines in the industry.  Typically a great deal of research and development goes into the documentation of these requirements by the respective parties.  That being said they are, for all intents and purposes, general purpose guidelines only.  That is exactly what they are meant to be.  However, we do not function daily in a world of general purpose.  We need to take the general purpose and abstract into the specific purpose to be truly beneficial in the data center.

Continue reading

Yesterday Nutanix released version 4.1.1 of the Nutanix Operating System.  Current customers can download and upgrade free of charge with no down time what so ever to their workloads.

New releases come with new features… so what’s in the box?

  • Metro Availability
  • Encryption Support
  • VM Management for KVM
  • Prism Central Scalability to 100 Clusters/10K VMs; added support for Hyper-V
  • Security/STIG Enhancements
  • One Click Hypervisor Upgrade

I’m being a little transparent above with the bold tags I suppose.  That’s right, security, and not just the word itself.  Version 4.1.1 introduces three new STIGs with a total rule count on the platform to over five hundred and thirty!  By itself that may not seem all that impressive, well 530 should, but you need some foundation in order to appreciate what we are doing at Nutanix around security as a whole.

Continue reading

In case anyone missed it DISA posted a brand spank’n new ESXi 5 STIG revision on Friday, January 24th.

ESXi 5 STIG Version 1 Revision 4

Now, I want to point out a few things about this revision.  First off I teamed up with a great engineer working for DISA FSO to basically rewrite most of the ESXi 5 Server portion of this STIG.  We put a lot of work into that section and I was proud of the result.  If you’ve had trouble implementing the ESXi 5 Server piece in the past please take a look at the changes in revision 4.  You can see from the release notes alone that dozens of checks were changed, and several deleted all together.

Additionally, a lot of the posts on this blog are now moot if you’re using revision 4.  Why?  Because we essentially used this blog as a point of reference in the rewrite.  I’ll be leaving the posts up here, but note in them that it was pre-revision 4 information.

Finally I wanted to mention our Community Project for ESXi STIG Automation.  If you haven’t signed up for this project yet, please do so.  We will use revision 4 as the focal point for its development.

As I’ve eluded to in some previous articles I’ve started up a community project on ESXi 5 STIG automation.  Why  Well, quite simply to help with credibility.  The best way to apply the ESXi 5 STIG settings is by way of a VIB, and in order for one to create and deploy a VIB in this fashion it will be unsigned but have a higher than Community acceptance level.  That is, as you know, a STIG issue itself.  Bit Chicken and Egg if you know what I mean.  So to help combat that I decided to post this as a community project on  If this is to be useful it must be trusted by the IA community within DoD.

Now, all that aside, let’s talk business.  First thing you need to do is go join the project!  Even if you do not plan to directly participate please join the project anyway.  This way we can show numbers and interest from the DoD community.  Trust me, things like this gain a life of their own and contribute a great deal to decisions made in development within VMware (you’d think).  Additionally, numbers and involvement will help drive IA acceptance of the tool as well.  NOW JOIN!

Project Site: ESXi STIG Toolset (CAC Required)

Now, you’ve joined the project, right?  Ok, next… read.  Take a look at the project charter and get familiar with project controls.  You’ll notice there’s a Discussion tab in the project console.  Use it.  Post questions, code snipits, and general information here.  That way everyone involved will benefit.

Next take notice of the Tracker tab.  This is a bug / feature tracker if you will.  As we progress along we should place features and bugs in this tracker.  Again, it helps everyone if we follow a standard.

File Releases is next.  Here is where we will place pre-built VIB versions for download, along with their code.  If you are familiar with source control we will build a branch and tag it as a release, those artifacts will go here.

Finally is the Source Control tab.  Within this tab you will see a Development repository.  This is where we will keep all the project files.

Now let’s get to building.  I’ll post a followup article on my ideas as to how we move forward.  What I ask of you is involvement.  Share your scripts and ESXi STIG settings within the project discussion group.  This is a community project.  I’ll be working on the build automation and documentation.  I need help with the rest of it.  I’ll cover what that is in the next article.  Until then, join the project!  I’ll be posting updates here and via e-mail through the project group itself.

Note: As of right now, only the project site itself and a minimum repository file structure has been established.  The real content will come.  Keep an eye here for a follow-up post and join the group for e-mail notification.

Anyone that has tried to apply the ESXi STIG knows the pain it can cause, especially across multiple hosts.  Settings don’t stick, special scripts must be created, and local files need to be changed.  Doing this once is a pain, doing it across your data center will drive one to drink.  How can this be made easier?

The answer could be a custom VIB.  Using a VIB can resolve the missing or non-sticky file issue, and populate the settings for you, but is that really a viable solution for the Federal data center?  Short answer, it depends.  Let’s dive into the reasons.

Continue reading

That’s right, revision 4 of the ESXi 5 STIG is right around the corner. You should see it in mid to late January, barring any issues during sign off at DISA.

So, what are the changes you ask?  Well, there are quite a few, and I shouldn’t derail the DISA FSO process by posting them early. However, I can tell you this. The assigned DISA engineer and I sat down for several hours and pretty much rewrote a large majority of the platform portion of the STIG. A special thanks should go out to that engineer, Joe. He absolutely set out to make a much more user friendly and accurate document, and I believe he did.  Well done and thanks Joe!

Another thing you will notice is a striking resemblance to this blog and it’s guidance in the check/fix(s) of the next revision!  Each and every one of you helped to contribute to that knowledge. So, in a sense, you all had a hand in the rewrite since a large portion of the content was pulled from this site. Thanks to all of you for correcting and adding to what I provided here.  I absolutely consider this not only a community effort, but a success at that.

Kudos and all that aside this will undoubtedly not make everyone out there happy, nor will it cover each and every use case. The intent in this revision was to provide content that was achievable and possible to implement. You could say I was trying to work myself out of a blog. 🙂  The revision will not address everything for everyone, but it does work!  Remember, as always, the STIG is an implementation guide to controls that do not fit into every situation. Work with your IA teams and DAA on a plan that fits within your agencies goals and security procedures.

Happy Holidays to all!


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.

Had a colleague point out to me that I gave a pass on a STIG finding for ESXi 5 Server that is, in fact, not that straight forward.  I wanted to take a moment to break that finding out and give some additional guidance.

SRG-OS-99999-ESXI5-000158 – Unauthorized Kernel Modules Must Not Be Loaded on Host

So the key word here is “unauthorized”.  What do they mean?  Well, they are talking about unsigned kernel modules, but there’s a trick to even that.  Per the STIG no kernel module may be loaded that lacks a digital signature… so lets look at how we can do this check.

Right off I’ll tell you there’s at least two ways, likely more, to knock this out.  By default there are a LOT of kernel modules on a default ESXi Server install, too many to go through by hand per the instructions in the STIG.  How can we make this easier.

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.

In this article I’m going to cover how you can setup the cron jobs necessary in ESXi 5.x to monitor for setUID, setGID, and device file changes per the ESXi 5 STIG.  I will walk you through adding a few scripts to your system that will provide log files that are date/time stamped.

Note: The following is unsupported by VMware.

The scripts outlined below are for educational purposes only to assist in your compliance efforts.  They are in no way meant to be a singular solution nor a replacement for a commercial OS baseline monitoring tool.

GEN002400-ESXI5-10047, GEN002460-ESXI5-20047, GEN002260-ESXI5-000047 – setUID, setGID, and Extraneous Device File Monitoring

First off, as before, the changes we are about to make will not persist across reboots without our help so please reference Blog Series: ESXi 5 STIG – File and Setting Persistence.  Keep that handy in the next tab over for reference.

So, we need to add some automated scripts to your ESXi host to parse the file system for suid, guid, and device files.  The method in which you review and/or determine changes have been made is up to you, ESXi provides you no mechanism to accomplish this.  All we are doing here is setting up the automated process of dumping the data required per the STIG.

Continue reading