4 Comments

Summary:

It took a lot of work to get developers and IT ops people to collaborate. The next step: getting them to factor in security at the beginning of the process.

Snow
photo: Barb Darrow

After all the angst that goes into getting developers and IT operations people on the same page — which is what the devops movement purports to do — is it too much to ask that they also consider security at the beginning of the process?

This is not an idle question in an age where organizations are increasingly paranoid about data leakage or outright theft.

Can security be baked into software?

To recap, devops is the notion of making developers work hand-in-glove with operations people to make sure whatever software gets built is actually deployable and easily updated. In the old model — still used in many companies — developers write chunks of code and throw them over the proverbial wall to operations people, considering their job done. That leads to lots of deployment issues.

In younger, nimbler companies, devops is becoming accepted — after many cultural hurdles were cleared — as the right way to build and develop software. That’s all well and good. But now, with increased focus on security, when you ask devops people if they factor in security from the get-go, the response is pretty much: “Um, nope.”

Photo from Thinkstock/Maxkabakov

Photo from Thinkstock/Maxkabakov

That’s a problem. Jody Brazil, founder and CTO of FireMon, (a security management company) discussed this issue in a recent Devops.com blog post, where he wrote:

“It is interesting to note that in almost no definition of devops is the security process discussed as a key element.  In some cases you will hear mention of improved security through consistent configuration management enabled through automation, but security teams are not at the devops table.  Why is that?”

To be fair, let’s stipulate that one benefit of devops is that resulting software is more easily patched and updated. This is not a trivial point since one of the primary reasons for security failures is the use of old, unpatched software.

But having said that, even devops purveyors admit more can be done. As Nigel Kersten, CIO of Puppet Labs (see disclosure) put it:

” … automation and configuration management tools solve a lot of the same problems as traditional security solutions, but can actually solve problems of inconsistent and unapproved configurations rather than just diagnosing them. That being said, there are definitely roles for more security specific tools in a devops toolchain around governance and auditing output – but only when these tools can interface with the configuration management and automation layer.”

Rajat Bhargava, CEO of JumpCloud, a server management company, agreed that much is already being done in the devops process to batten down the hatches. Most companies that practice devops already focus more on their application and infrastructure architecture security, just not in the context of existing security vendor tools.

Modern developers who cut their teeth on Amazon Web Services already have this mindset. They pick and choose their cloud components with an eye on isolating their workloads as much as possible on a public cloud, for example. “Many use AWS VPC to create a virtual private cloud and then automate the creation and scaling of new servers so their architecture is already behind a firewall  –per AWS security groups,” he said via email.

So … who’s in charge?

Almost everyone seems to agree that security needs to be thought of at the beginning of the process and not tacked on at the end. But not everyone felt it should be the devops crew doing that.

That job should fall to the solutions architect, not devops, said Brian McCallion, founder of Bronze Drum Consulting, a New York IT consultancy. The solutions architect should spec out how network subnets in the VPC should be isolated, define privileges and set authentication. Then it’s up to devops to build from that blueprint, he said.

But things don’t always work out that way.

“Devops teams will make these choices on their own unless they are specifically required to build to a specific design. In my experience devops teams, including developers with root privileges, will ignore security concerns, or even if they attempt to address such concerns simply do not have the domain expertise,” he noted via email.

So we’re all in violent agreement: Security should be firmly in mind before applications and their infrastructure get built. The question then is who drives the process. Stay tuned.

DisclosurePuppet Labs is backed by True Ventures, a venture capital firm that is an investor in the parent company of Gigaom.

You’re subscribed! If you like, you can update your settings

  1. Your summary is dead on Barb: Integrating “security” into the “development” and “operations” elements that comprise DevOps is the next logical step. DevOps processes and tooling will advance to where this is a natural fit… an evolution toward DevOpSec.

  2. Jeff Schneider Wednesday, March 12, 2014

    Hey Barb – There’s some great thinking coming out of the Rugged DevOps community! Check it out: http://ruggeddevops.org/

    Jeff

    1. @jeff will do thanks

  3. Hi Barb, excellent article demonstrating how DevOps traction is triggering more advanced conversations. DevOps integration with security may not be widely baked into ‘roll your own tools’, but is available in DevOps PaaS platforms.

    WSO2 App Factory integrates governance processes and role-based security while isolating deployment management scripts. Net effect, security policies and processes are enforced by the DevOps PaaS environment. Solution architects and operation administrators define both role-based, attributed-based, and topology based security policies and SLA policies applied per project via self-service provisioning.

Comments have been disabled for this post