Reaction: DevOps and Security

Over at TechBeacon, my friend Chris Romeo has an article up about DevOps and security. It’s interesting to me because this is actually an area I’d never thought about before, even though it makes sense. Given DevOps is essentially writing software to control infrastructure (like routers, compute, and storage), and software needs to be written in a way that is secure, then it should be obvious that DevOps software should be developed with good security principles gleaned from software development as part of the foundation.

And here we face a challenge, as Chris says—

There is no standard that defines security for DevOps, and the chances of a standard ever developing is small because different organizations are doing things their own way, and can’t even agree on a standard name. And while there is a standard for the secure development lifecycle (ISO/IEC 27034-1), few organizations are ever validated against it.

The key point in here is that every organization is doing things their own way. This isn’t wrong, of course, because every organization must have some “snowflakiness” to justify its existence, and that “snowflakiness” is often likely to show up, in a large way, in something like handling resources within and attached to the network. But it does mean we face a real challenge where DevOps and Security meet. The right answer, I think, tends to be contained in another point Chris makes—

In any process or methodology, people create the vulnerabilities. Luckily, DevOps is also a culture thing. Teams do DevOps and live and breathe the culture behind it. The hinge to success for DevOps security lies in changing the underlying DevOps culture to embrace security—with no exceptions. As with any other methodology, security must be built into DevOps.

The key is in the culture. Of course, this shouldn’t surprise us, either, because the key to all security is really in the culture. But the culture has to reach beyond the idea of the development process, and into the network that’s being programmed, as well. For far too long, network engineers have taken a view of network security something like this—putting firewalls in the right places, and configuring them with the right policies, creates a magical security blanket over the entire network, and all the devices connected to it. We’ve all bought the old vendor commercials where the network catches, and stops, the virus the CEO’s daughter accidentally downloads while playing on a work computer handed over to “keep her busy.”

The first reality is this—the network can be secured, and the network can help devices attached to it in their security measures, but the network cannot, and never will be able to, secure anything and everything connected to it.

The second reality is this—we need to get out of the “must I secure this,” mindset, and replace it with “you need to prove to me why I should not secure this.”

The third reality is this—firewalls don’t provide security. They provide a set of services that can be used, in some situations, to help provide security. But firewalls are not magic blankets that can smother your network in “security goodness.”

I think Chris is onto something here. DevOps might be a good entry point for securing networks, and the resources connected to networks, in a more general way. If we can drive a security culture into DevOps, we can not only make the applications DevOps is building more secure, but we can also make the network more secure.