Security as Code? – Automating Rugged DevOps – Part 2

In my last post, I discussed the rationale behind the “Rugged DevOps” idea from Gene Kim and Joshua Corman. To recap, they have argued that to make DevOps “Rugged”, that is – secure, the security team needs to be integrated into the DevOps cycle. In particular, there should be security experts as part of agile sprints, building in security from the very beginning of development. This is a compelling idea. To implement it, technologically, I submitted that we have to secure three separate parts of DevOps: the infrastructure, the “sprint” updates, and the actual DevOps process itself. We’ll discuss the first two in this post.

The first step, subtle but essential, is to separate the “infrastructure” from the “application”. As we have argued here before, this is a natural split for DevOps, as operations is responsible for architecting the more stable infrastructure components, while agile developers handle the application. To accomplish this, you need to be able to automate the provisioning of the platform in a modular fashion, rather than over-reliance on images or virtual templates.

Rugged DevOps.gif

Since the infrastructure changes much less often, the server and application infrastructure should be architected and secured as a baseline for both the whole DevOps cycle (Dev to Prod). This means that developers would work within a secured environment that is locked down to production standards. Where the line is drawn between infrastructure and “code and content” will be different for different organizations. As an example, you would expect that the sprint updates would include configuration changes to the infrastructure (f.ex. tuning parameters), and certain “code” might be static enough to be included in the baseline. Bottom line, they would establish a security standard for the baseline that is monitored from development to production.

This then allows the newly “security enhanced” agile sprint team to focus on the security standards for the “code and content” or application portion. Instead of building a security standard for the whole stack, the agile security team member would validate a modular standard covering just the custom portions of the stack, and that standard would then be released with the actual code. This is the important point – updated security standards should be released as part of the agile sprint “package”. In production, the security state of a system (matching the old way of looking at things) would be a combination of the two – infrastructure compliance and “application” compliance.

So, how does this help us? By delegating different parts of the stack – from a provisioning AND security perspective – to operations and development, we can ensure that there is both accountability for securing the whole server stack, as well as significantly reducing the drag of security audits on the DevOps cycle. I would also contend that this kind of approach could revolutionize the way information security teams approach policy enforcement. Instead of starting from the server (OS) up, this approach forces security teams to treat the application separately, instead of giving the short shrift that so often leads to security holes today.

Part 3 concludes this investigation.

Share This Post