Building empathy and improving security with DevOps

There is ongoing discussion around how DevOps impacts the role of enterprise security. 

Some camps are embracing DevOps, while others see DevOps as the breaking down of all of the processes and controls that have been put into place to help keep enterprises secure. To get perspective from someone who has been involved in information security for about 20 years, we turned to David Mortman. Mortman is currently a contributing analyst at the security research firm Securosis, chief security architect and distinguished engineer at Dell Software. Mortman was also recently the director of security and operations at C3. Previously, Mortman was the CISO at Siebel Systems. Mortman speaks regularly at Blackhat, Defcon, RSA and other conferences.  

Hulme: There still remains a lot of debate out there as to whether DevOps can help to improve security, or if it is actually a hindrance and makes development and processes move too quickly.  What are your thoughts on how DevOps affects system and application security?

Mortman: Complexity is the enemy and DevOps enables you to develop code and applications that are less complex. Less complex things are more secure inherently.

A lot of this is related to continuous deployment. Smaller batch sizes mean not only is the risk of any given deployment being bad lower, but it also means that responding to anything that does break is remedied more quickly. After all, if you've pushed 50 lines of code and something breaks, it's much easier to debug that and figure out what broke something rather when something breaks after pushing out 250,000 lines of code.

That also ties into the reduction of technical and security debt, the reduction of code bloat, and challenges like that. That's another benefit. DevOps, this is actually true both on the Dev and the Ops sides of the house. Essentially, you end up with the continuous deployment and configuration management that accidentally provide you with two great change management databases. For example, on the operations side, your configuration management system becomes your Change Management Database (CMDB). This helps to tremendously manage change in the environment. 

Hulme: Your change management processes built in by default. The traditional way was trying to force the CMDB into the workflow. 

Mortman: Right. It’s built into your workflow. In the ISO world that's your definitive media library, your continuous deployment tools become your definitive media library of what's going on the Dev side. That's huge right there. It avoids configuration drift issues. It just makes everything simpler. In fact, not only do you end up with a more accurate configuration management database, but you actually get one that is more accurate in the timestamp sense of things, but also much more accurate in terms of being easier to tie actions to particular users. In that way, it actually makes auditors lives easier.

Hulme: You speak a lot about the need for empathy in DevOps. Could you explain a little what you mean by that?

Mortman: It’s all about effective empathetic communication. The heart of what we are thinking about is empathy with the user. Empathy is the killer app of DevOps. Many times we speak about the technical benefits, but the thing that makes all the stuff work is the ability to breakdown the silos. Break down the "It's us versus them” mentality

Effective empathetic communication is also about creating a blameless postmortem-we're looking at outcomes, not blame and making this about coaches and tool smiths and just getting to a place of “How can I help us all succeed.” This is a change that's been happening in security for a while now. People are starting to shift that mentality. But I still meet a lot of people in security for whom it's about “no.”

Hulme: Yes, rather than just offer a visceral “no,” go into a room get your brain to hurt a little, and think of a way to make it work that reduces risk.

Mortman: Exactly. I love it when people don't even say no, but move to, "How about we do it this other way?" Earlier in my career, when I was still at Siebel, my big question when someone would say, "Can we do X?" which would inevitably be a technical request like, "Can we open the firewall to do X?" or, "Can we deploy technology Y?" or whatever it happens to be. The big question I always liked to ask was "What is your goal? What are you trying to do by enabling this technology, opening this firewall port? Let's talk about outcomes."

Just by asking the question we often found out that we actually already had something in house that would work. Or, we would find an alternative mechanism to get the job done that would make me happy as the security guy, and would make the user or customer happy as well.