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.
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.
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.
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.