I am always looking for segregation of duties (SOD) cases on DevOps context

Implementations seem to range from "requiring any 2+ people to approve a change" (like any code review) to "require 2 or 3 people from 2 or 3 different roles" (dev and ops and biz)

I always interpreted this as, ‘it should take an act of collusion to commit fraud’, or ‘no one person should be able to commit fraud’.

Historically implemented as dev can’t deploy with the idea that if only Ops can deploy the code then no dev can sneak stuff in.

More recently though folks use the ‘four eyes’ principal (code reviews) to approve code changes which is much more effective.

https://nvd.nist.gov/800-53/Rev4/control/AC-5. Though to be clear, it does not explicitly mandate separate people/roles. But the language walks so close to requiring it that most people implement it that way. (Even though it has more to do with auditing vs building than the deployment process) Agree that 'four eyes' or what I call the "nuclear code" model (two keys required to launch) is a better system.

The NIST definition really walks very close to require separate roles. Point (ii) seems the most strong on it. And most definitions/descriptions I've seem from regulations (or interpretations/guides to regulations) do walk that close.

Do you have knowledge of any material that specifically discuss the validity of the "four eyes" approach to separation of duties?

The Acellerate book show a case like that (four eyes review for SOD), but it does not dive much in "convincing material" for discussing it with auditors/etc.. It always seems a understading that you will have to build with your governance team and auditors. One that won't be easy to build 😄

@dmorales I've never seen someone commit to writing that 'four eyes' is a control - but there is where partnership with your auditor is key. In a past life, we were able to show an auditor that developer could deploy - only through the automated tool - and only after reviews/automated checks - and that the pipeline was immutable (developers could not circumvent it) and the audit log was immutable (developers did not have rights to change it) so it had the effect of meeting the separation of concerns by having different people for development vs audit. Make friends with your auditor, is what I'm saying 😅

To keep the discussionn going after events like this 😄

All Day DevOps has a slack community that is open all year. Within that workspace there is a DevSecOps channel.

You can access it at http://alldaydevops.com and click on the Slack logo at the top of the page.

I would also do google searches for other Slack communities as there are many to find out there.

Thanks, I'll take a look!

interested in this we are talking about this today

I am guessing that would be subjective. Other than general IT controls, its hard to have a common framework for scoring

Agree. In our experience we found Risk scoring not to be that helpful. Instead we created cross functional safety teams who engaged across 1 or more value streams on a continual basis. Instead of a Risk score the team agreed through discussion which quarterly Outcomes needed their attention and what Risk Stories to place in the backlog.

That is interesting approach @mylesogilvie

More detail in Sooner Safer Happier (one of the free download books)

we scaled across 15,000 people in a traditional UK bank

..that processes 30% of UK GDP every day.