Putting the SEC into DEVOPS

I’ve been pressing for greater speed in security management for many years. “Replace the Deming Loop with the Boyd (OODA) loop” has been my mantra. Yet when I first encountered DEVOPS, I immediately thought it would fail because it broke the segregation of duties principle. Perhaps it would be fine for a small start-up or a vendor, but not for a large enterprise subject to all manner of regulatory demands and frequent audits that inspect segregation of duties arrangements.

I’ve since changed my view, for the following reasons.

DEVOPS is a compelling movement, which enables continuous software delivery through automation and closer coordination of development and production teams. It introduces a powerful cultural change. And faster delivery means quicker bug fixing and therefore faster elimination of security vulnerabilities. This is a big security benefit, but what about those regulatory controls and standards that demand separation of duties and environments for development and production work?

The answer is that we need to bring these traditional ideas up to date. The starting point is to recognize that there is more than one driver behind these requirements. Segregation of duties is an anti-fraud check which applies to financial processes. No one person should be allowed unsupervised, end-to-end control over financial transactions. In contrast, separation of development and production environments is a broader, operational control to preserve the integrity of the production environment from the side effects of untested software.

These requirements are in fact expressed as two separate ISO 27001 controls. Unfortunately, they’re often conflated, with many people interpreting segregation of duties as a need for separate development and production teams. But that that’s not strictly necessary. We do need to separate the processing environments, but we don’t have to segregate the development and operations staff.

In fact, segregation of duties is just one solution to the anti-fraud. It’s often referred to as the “4 eyes principle” which is a broader and better way of expressing the requirement. That can mean simply having a second person authorize any changes (such as a new release), which then opens up a door to DEVOPS teamwork, though we are still constrained by the need for an extra check.

To eliminate potential delays from a secondary check, we need to update our concept of trust and control. The old-fashioned concept of trust was perhaps best summarized by the old Russian quote (equally ascribed to Stalin and Lenin) that “Trust is good but control is better”. Now that might have worked in an over-manned, slow-changing, industrial age environment. But it’s impossible in a fast-moving, empowered, information age world. A better adage is the Ronald Reagan quote (also based on a Russian proverb) of “Trust but verify”, which enables speed and empowerment.

The choice now is how best to implement such an ongoing checking mechanism, and whether, for example, an anomaly detection system might be sufficient to remove or reduce the need for human intervention. That justifies a bit more thinking. But I can envisage that on a small scale (which this is) something along the lines of a self-organizing map (a neural network) might serve as a fast, convenient method of periodic human/machine checking.

There are of course further things we need to achieve secure DEVOPS. Most importantly we need sound design and enforcement of access control policies, profiles and permissions. Interestingly, this is an extremely simple subject which is surprisingly poorly implemented. But that’s for another blog posting.