Saturday 29 October 2016

Why SecDevOps

I like SecDevOps because it reinforces the idea that is an extension of DevOps. SecDevOps points to the objective that eventually we want the Sec part to disappear and leave us with DevOps.

Ultimately, we want an environment where 99% of the time, DevOps don't care about security. They program in an environment where they either cannot create security vulnerabilities, or it is hard to create them, or it is easy to detect security issues when they occur.

This doesn't mean you don't need security teams, or AppSec experts. It doesn't mean you don't need a huge amount of work behind the scenes, and a huge amount of technology to create those environments.

You don't make security invisible by getting rid of it. You make security invisible by automating the security checks, and by increasing visibility into what is going on.

At the moment, when we look at security activities, we often see security doing things that are the proper responsibility of development, or testing, or infrastructure, or documentation, or even management.

Anybody who works in AppSec for a while always finds themselves asking difficult questions. They interrogate the system rigorously, but the information they seek should already be known and available to them.

AppSec will often create tools to attack an application to visualize what is going on. I have had many experiences of spending time creating technology to understand the attack surface. Once that task is complete, I find a huge number of vulnerabilities, simply because a significant part of the application hadn't been tested. The system owners, and the various players didn't fully understand the application or how it behaved.

So, I think SecDevOps represents an interesting point in history, where we are trying to merge all the activities that have been going on in security with the activities that have been going on in DevOps so we can build an environment where we can create and deploy secure applications.

This relates closely to my ideas about using AppSec to measure quality. Ultimately, the quality of the application is paramount when we are trying to eliminate the unintended consequences of software.

DevSecOps initially sounds better because development goes first. But I agree with the view of DevSecOps as being more about applying development to security operations (SecOps).

This all ties together with the risk workflows that make things more connected and accountable.



(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)