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.

The Nutanix NOS STIGs do just that.  We consume the multiple requirement guides, special publications, and existing STIGs that are applicable to the Nutanix platform to provide a specific purpose implementation guide.  In addition to the already published requirements by NIST and DISA we have gone a step further in many cases and expended upon or added additional requirements not currently called for in any requirement.  Items such as HTTP Header Protection are added to our products above and beyond what is called for by the industry standards and considered CAT I, or high, findings if non-compliant.  That is just one example of where the Nutanix product exceeds published requirements.  Many others, such as HTTP Strict Transport Security (HSTS), Cross Site Scripting (XSS), ClickJack, nosniff, and other safeguards are inherent within the product, exceeding the industry standards in place.

The Nutanix STIGs are not bolt-on, or an after the fact, implementation of security.  These requirements are coded within the product.  Development takes place within these requirements, not around or beside them.  This should be absolutely crucial to the security conscious customer because the product is developed and delivered to you hardened and compliant with no effort on your part required.  You would have to work to UNDO the requirements with Nutanix, not work tirelessly to comply with them, like with many other products in the market today would force you to do.

To wrap up this article I’d like to take a moment to make a call to arms, if you will, on the perceived necessity around security hardening and STIG requirements of today.  I’ve worked in this industry for going on two decades now and the prevailing opinion is that STIGs are for the Federal Government vertical only.  This perception, this attitude toward security requirements, and even the very word STIG, must stop.  We no longer live in an age where our Federal Government are the only ones with data worth protecting at this level.  In fact, one might argue that our commercial sector houses and maintains far more damaging information in some cases based upon the millions of people that could come to harm in a breach.  The STIG is not a Federal only discussion to be had, nor should it continue to be looked at as a single vertical requirement.

At Nutanix we have fully embraced the premise above.  Security is of the utmost concern here for not just a specific vertical, but for all customers alike.  This is just one of the reasons that our security requirements are baked in with no implementation necessary on the part of the customer.

One thought on “Nutanix NOS 4.1.1 – The STIG Methodology

Comments are closed.