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.

Typically when a company envisions a product they look at the needs of a general vertical or target demographic then design and build to that set of requirements.  It’s a sound approach to any product design process; however it often falls short to the very general nature of the exercise from its onset.  What do you think happens as new requirements come forward from the Sales or Field teams?  One of two things can occur.  The new requirement could fit into the already ensconced idea of a “general vertical” and be deemed useful for all.  This is what you hope for, but rarely get.  If it’s not considered mainstream enough it is viewed as an outlier, a corner case feature or requirement.  The latter becomes the home for almost all security requirements because the industry, even today, just doesn’t consider some of the most basic platform security requirements as “mainstream enough” for the general population.  That just simply is not the case, not today, and not for our future in the software industry.

When a sales or marketing team is faced with one of these outliers how to they continue to position a sale and meet customer security requirements?  They improvise and bolt on, that’s how.  If the development team doesn’t want to play ball and provide the requirements inherent in the core they must improvise to close the sale.  In the world of platform security this means hardening guides and post-installation tasks, and those always fall to the customer to implement.  Let’s be honest, hardening guides are just that, bolt-on solutions to your security requirements.  Think about the amount of time you’ve spent hardening a system for production.  How would you rather have spent that precious time?

Here at Nutanix, as part of our Security Development Lifecycle (SecDL), we design and intrinsically provide, platform security at the core.  It’s part of our development, our future planning, and our new feature process.  QA teams have no choice but to test our platform with security requirements in place, because it’s inherent in the core product.  This means you can be certain that all platform security requirements we satisfy intrinsically are fully QA tested for both functionality and performance.

How much QA testing do you think goes into a software product that provides security-hardening requirements as a bolt on feature?  I won’t even answer that question, I think you already know.  It should worry you.

For more information on the Nutanix Security process please see our Security page on our Corporate website (

For more articles on the SecDL please see my previous posts Nutanix NOS 4.1.1 and the SecDL and Nutanix NOS 4.1.1 – The STIG Methodology, as well as my call to arms in the need for platform security to because a true mainstream requirement.  It’s up to you to message this to the software companies you rely on daily.  It can no longer take a back seat, nor should you let it.

One thought on “Intrinsic Security vs. The Bolt On Approach

Comments are closed.