Security as Code? – Automating Rugged DevOps – Part 1

Rugged DevOps.gifAs the discussion around DevOps has been advancing forward, most of the discussions have been about pushing code faster, more reliability, etc. Security remains a dirty word for many organizations, and DevOps doesn’t necessarily change that.

In their presentation at the 2012 RSA conference – “Security is Dead. Long Live Rugged DevOps […]”, Gene Kim (co-author ofVisible Ops) and Joshua Corman (Director of Security Intelligence for Akamai and co-founder of Rugged Software, presented the idea of “Rugged DevOps”. They showed how security can not only be successfully woven into a DevOps delivery model, it is essential to doing DevOps right.

The vulnerability of code, and the necessity of recognizing that vulnerability is best expressed in the “Rugged Manifesto” they quote from – “I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.” They advocate that secure architectures and design can be incorporated tightly into the DevOps release process by making security part of the team, rather than the dreaded check box at the end of the road.

If I was a security professional I would immediately become a DevOps evangelist, because this could be the best thing to happen to security in decades.

I highly recommend you read through the presentation by Corman and Kim, and I won’t regurgitate that here. What I will do is delve into an interesting area for DevOps automation – automating Rugged DevOps. As you will see in their work, Corman and Kim contend that Rugged DevOps has organizational, strategic, and implementation dimensions – just like plain old vanilla DevOps does. The bias against security is deeply ingrained in many companies – both in Dev and Ops (something they can agree on).

Security testing slows developers down and audits take Ops away from daily duties. The solution for Ops has been to apply standardization, automation, and reporting – get everybody on the same standard, automate as much of the process as possible, and then provide transparency up and down the value chain through reporting. When applied correctly, this formula can bring huge cost savings and a dramatically improved security stance. DevOps seems set to collide head on with these carefully laid plans (for the Ops teams than even apply them).

From a implementation perspective, I would contend the problem is wrapped up in the way we view security. We tend to view security by device, and sometimes by application (not code, but rather infrastructure like JBoss or Weblogic). You build it, then scan the server. You update the app, then scan the server. And on, and on… To truly implement Corman and Kim’s ideal, we need to not only integrate the teams, we also need to view security implementation with DevOps glasses – securing by “Agile Sprints” or deployed “modules”, not by server.

So, how do we do that? I would suggest that we need to secure three separate parts of DevOps: the infrastructure, the “sprint” updates, and the actual DevOps process itself. We discuss how to do that in the next installment

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post