Is DevOps security about behavior or process?

One of my main roles is improving the security of the software produced by my employer, and it was in that role that I attended the annual gathering of the security industry in San Francisco last week. The RSA Conference is one of the two global security conferences I attend, the other being Blackhat. While Blackhat has become more corporate, it’s still dominated by hackers and focuses more on vulnerabilities, whereas RSA is very much a corporate event focused on enterprise security and security policy.

Several of the tracks at RSA this year covered the area of security in the development process. I was most interested in the Advanced Security & DevOps track. DevOps is a hot topic in the industry, and now we have SecDevOps, or perhaps DevSecOps as the new security buzzword spinoff. Behind the buzzwords, however, I learned some useful lessons, a few of which I’d like to discuss here.

Two of the learnings I mulled over on the long flight back to Europe seem initially to be mutually exclusive:

1. Security is a process, not a product.
2. Security is about behavior, not process.

However, when viewed in the context of security in the development process, they do start to make sense. It’s perhaps best to view them when placed end to end rather than side by side, and reversing the order, so:

Security is about behavior, not process. Security is a process, not a product.

Now, they start to make more sense (at least to me). You have to start with behavior.

One of the fascinating stats I learned last week was that most organizations have 1.6 folks dedicated to security for every 100 developers (anecdotally this holds up when I look at my own experience). Based on this axiom, it becomes clear that the only way the security team can make an impact is not by imposing processes, but by changing the security culture to create a security “mindset” in the development team.

There are many ways to go about this; training in foundational security concepts is a good place to start. Once the developers understand why they should care about security, then you can start to think about the how.

Establishing a security process and finding the right tools

Having established a security culture, the work begins to establish a security process (this is the “how”). I won’t list all the components of such a process, although you could do a lot worse than the security process described by Microsoft. Once you have a process (and it’s best to start simple and build from there), you can think about tooling.

I have seen a lot of companies jump straight to the tooling, i.e. “We must have X product from Y vendor.” While tools are important (especially when integrated into continuous integrations (CI) and build processes), they should have a way to improve your process, not be a replacement for it. And they will fail completely unless you have developer support for the process in the first place.

A good example I saw was at a previous employer. We deployed a static analysis tool whose output of thousands of issues was completely ignored by the developers even while management was very happy with the pretty graphs it generated. It was the classic case of too much effort to fix, not enough time to build the process.

One of the added complexities I face is trying to coordinate a security process for an open-source software company, where contributions come not just from the employees, but from a community of contributors from all over the world. However, the fundamentals are precisely the same, and again, start with getting buy-in from the community about the importance of embedding security into every aspect of the software development lifecycle.

So, now that I’m back home and (mostly) recovered from jet lag, I need to start practicing what I preach. I’ll look at where I could be helping the engineering team with its security culture and subsequent security processes. I hope this blog encourages you to do the same at your organization.