Apr 28, 2017 The Twain Shall Meet: DevOps and Separation of Duties
Although traditional models of separation of duties are incompatible with DevOps, the principle can certainly be applied–and must be, in the long term.
Separation of Duties: The Boogieman?
Today in an interview for our Cloud and Network benchmark, the IT professional on the other end of the line was telling me that he didn’t think they’d be seeing a DevOps initiative in their organization any time soon. “We are so heavily regulated, and separation of duties is paramount here. We airgap not just infrastructure but processes and staff whenever we can.” It’s not the first time I’ve heard the SoD put up as a barrier to all things DevOpsy, and I’m sure it won’t be the last. It seems intuitively obvious, after all, that any methodology and culture built around the idea of breaking down boundaries between developers and operations has to find itself in conflict of SoD. SoD is all about erecting barriers!
But, given how many banks and other also-heavily-regulated organizations we talk to are implementing DevOps, organizatios that we know are deep into SoD, it is increasingly obvious that it’s more of a strawman than a boogieman. You can’t just plunge in and start doing code pushes willy nilly in an SoD environment, but it is possible to adapt DevOps and SoD to each other, and in ways that should actually result in improved security.
Let the Robot Do It
The key is building your processes around a combination of creator/auditor roles and tools that track everything and who did it.
The basic premise is simple: Every push to production, in addition to whatever other automated checks go on, has to pass muster with a human security review by a different human than the original developer.
(Digression: And you’d better believe this makes a microservices approach even more useful, as it breaks auditing into much more manageable tasks. Trying to spot a backdoor wired into 50,000 lines of code covering a broad array of functions will always be harder that spotting one embedded in a few hundred lines devoted to a small and well defined task.)
Robust automation is the key, of course. The code management and test management systems need to be able to track the division of labor between different individuals wearing the appropriate roles–track who was wearing the develop hat, and who the audit hat, for each transaction. That tracking, over time, provides the necessary audit trail and links it directly to the versions of code in question, so any security problem that comes up, once it is traced to code, can be tracked back to people as well.
Note, this requires finally letting go of some long-held behaviors like use of shared accounts, and unmanaged changes to production. Nobody likes to admit there are still shared accounts out there, but they are (our research finds) still common enough. Likewise unmanaged changes to production systems: even in environments that supposedly have strong change management, it is all to easy to get an “emergency” declared that allows changes to rush through without review. Even an urgent situation, though (such as Sven Malek describes here) admits of reasonable but swift change management in a DevOps context.
As tools get better, as best practices and experienced staff spread out further in the enterprise, and as we continue to replace and automate some security-hostile manual processes, the supposed gap separating SoD from DevOps will be seen to be nothing more than an illusion.