Three Steps for Integrating Security into DevOps

The fate of CSO John in The Phoenix Project is a good parable for illustrating the dynamic and often conflicted relationship between Security and IT Operations. Security can either become a separate, obscure, and increasingly irrelevant group that everyone else resents-sounds pretty good, huh?-or it can be integrated into broader framework of the development cycle. Security John goes through a mental breakdown before finally understanding how to adapt and survive, but it doesn't have to be that hard.

Security and DevOps

Before the rise of DevOps, strong functional distinctions were supposed to help groups focus on their core competencies. Developers wrote code, operations provisioned and maintained infrastructure, and security found holes and worried about all the vulnerabilities they knew hadn't been fixed yet. This separation of knowledge, however, created inefficiencies. Problems that would have been cheap to fix during development became expensive once they had shipped.

The name "DevOps" can lead to the naive conclusion that it's just about bridging the gap between development and operations. DevOps is much more than that-it's a holistic approach to collaborating and sharing information across functions that makes everyone's lives easier and the business more successful. Or, as Mike Kavis observes, the goal is really just to be better. DevOps provides an umbrella term for a range of techniques that have worked for many people. Any way you slice, it, DevOps means thinking about making quality software quickly-and that definitely includes security.

1. Configuration Hardening

So where does security fit into DevOps? Insomuch as DevOps is associated with tooling, it has largely been about configuration management (CM). Chef, Puppet, Ansible, SaltStack, Docker-these tools commonly come up in conversations about "doing DevOps" because they abstract configuration state into versioned code. Since CM is already a well established and supported component of DevOps, it's as good a place as any to start. Activities like checking for compliance with best configuration practices and applying updates system-wide should be a natural part of the DevOps process.

2. Policy Driven Development

Rather than CM being handled differently by development and Ops-or handled by Ops only--CM with these tools (in theory) provide a means to collaborate on shared concerns. That's not always the case, of course. All too often CM tools become the domain of a specialized "DevOps team" that actually worsens your bus factor. But given that collaboration and shared knowledge is the goal, the same applies to security vis-à-vis CM. A useful model is that of policy driven development: publicly visible, executable documentation of what security compliance means for you. In the same way that test driven development means anticipating user acceptance testing, policy driven development means anticipating and addressing security requirements.

3. Visibility

Strong safety nets like effective rollback/failover plans enable teams to move faster because failures are caught immediately in low-risk environments. This is the philosophy of the Visible Ops Handbook-brakes don't make a car slow, they let it go fast. The same type of detective controls and system scanners that let teams safely adopt a DevOps deployment approach are also the most effective for traversing the harsh, unforgiving landscape of IT security. New vulnerabilities are discovered constantly, whether you're looking at open source or proprietary software. Rather than trying to create an impregnable barrier, gaining visibility into your system state allows you to effectively manage risk. Configuration monitoring should already be part of a DevOps approach. Applying it to vulnerability assessment increases security at a minimal cost.

Conclusion

When someone says you need DevOps, think about what that really means. If your goal is to check a box, then you can probably do whatever you want and say it's DevOps. If your goal is to improve service delivery to your end users, then a little extra planning for security contingencies is in order and can greatly increase your yield. It might sound paradoxical, but having stricter controls for quality-through CM, continuous integration, and configuration monitoring tools-will allow you to ship more frequently and reduce your vulnerability exposure.