• United States



Rugged DevOps: In search of the defensible infrastructure

Mar 06, 20124 mins
Application SecurityData and Information SecurityDevops

DevOps moves too fast to build security into the process, some say. Not true, say others who believe one just needs to get a little Rugged.

For years, IT has operated as sets of separate teams (hopefully) working on a common goal. There were development teams, IT operations teams, QA teams, security teams, and those who deploy and manage new services. Rarely did these departments work together in a cohesive fashion.

That was until the so-called DevOps (the coupling of development and operations teams) movement began in Belgium in 2009. It has steadily spread worldwide since. While common sense would dictate that developers and IT operations should always have been working closely together, in practice this wasn’t reality. In big enterprises, it’s the goal of developers to push new deployments and bring systems changes — while operations (and IT security) fair better when systems remain static. For instance, it’s easier to ensure availability and security when things don’t change rapidly.

However, when IT operations and development merge more closely together, it’s possible for the number of deployments to skyrocket. Some organizations, such as Amazon, claim to conduct more than 1,000 deployments a day. This can have a profound impact on systems security — which is already, in traditional operations, running a number of steps behind the organization.

That why — if DevOps is to produce sustainable and secure infrastructures — an important evolution will be to integrate security practices into DevOps principles, if that’s even possible.

That’s where Gene Kim, IT author and former CTO and founder of security firm Tripwire, and Joshua Corman, director of security intelligence for Akamai Technologies, come in. At the 2012 RSA Conference last week, the two dubbed the act of incorporating security practices into DevOps as “Rugged DevOps.”

Rugged DevOps incorporates the similar ideas as Rugged Software Development – and that’s to make sure the process results in a defensible infrastructure, contains operational discipline, includes situational awareness and countermeasures. “Rugged DevOps creates the kind of security the CIO wants,” says Corman.

Part of the challenge, contends Corman, is that organizations hate security. “It’s a tax and prevents IT from doing what it wants to do. Security is a toxic word,” he says. However, because Rugged DevOps strives to build security into organizational processes it’s the kind of security that can succeed, he says.

Part of Rugged DevOps’ ability to improve security, despite DevOps’s mantra to “deploy early and often” is how it can help an organization to whittle down legacy and overly-complex infrastructures and redundant business processes. Kim described an organization in which he was familiar that cut the time for certain processes from six hours to about 45 minutes. “And they were looking for more. For instance, it’s possible to take a complex deployment process of 1,300 steps down to less than 100. One can take any long arduous process and shrink it down, take complexity and work out of the system,” Kim says.

“This can lower the attack surface by retiring their old infrastructures and complexities,” adds Corman.

Another example of how DevOps can help to simplify IT in an organization is through deploying systems in chunks that can be evaluated as to how they will function in the production environment. For instance, in agile application development a single “sprint” is defined as a deployable unit of code. However, as Corman and Kim note, that’s not necessarily enough material to work with to successfully vet how secure that code will be when actually used.

Kim described how that changed with an important shift in approach. “A breakthrough (for security) came when Agile sprints started to include shippable code and the basic components of the environment that it will ship into,” says Kim.

With this practice, even the earliest states of development must have some common processes, and that will include developers, QA, staging and production teams, and security. “Security can now be integrated into the early stages of development. Security is no longer an after-the-fact process, as we engage with these teams security becomes part of the daily process,” says Kim.

“The outcome is a much more defensible infrastructure,” says Corman.

George V. Hulme writes about security and technology from his home in Minneapolis. You can also find him tweeting about those topics on Twitter @georgevhulme.