What is separation of duties, anyways?

As we build more complex approval and review requirements in Oblique, I’ve been digging into compliance frameworks. We want to make sure that we can support any reasonable requirement an organization might have, especially if they’re being mandated to follow it. Compliance frameworks rarely tell you exactly what to do — most requirements are short, vague, and left to interpretation. So it's worth digging into what's actually being asked.

Separation of duties is one that comes up occasionally. It also turns out to be one of the most misunderstood. For example, NIST CSF 2.0 requires that access permissions "incorporate the principles of least privilege and separation of duties." Which sounds reasonable until you try to figure out what it actually means.

Separation (or segregation) of duties is the principle that a risky workflow shouldn’t be able to be completed by a single individual. The prototypical example is that the individual who processes payments shouldn’t be the one approving them. And this makes sense in fraud generally, but that’s really the only example you see come up in the literature.

When you dig into the payments processing example to understand the underlying thinking, you can break it down a few ways:

• Don’t let the same individual have both roles
• Don’t let the same individual have both roles at the same time
• Don’t let the same individual have both roles for the same transaction

The industry tends to focus on the first interpretation (flagging the "toxic" combination of roles — yes, that's really what it's called), when what we actually care about is the third: that the individual cannot unilaterally approve their own transaction. (Some people shouldn't be able to approve transactions at all, but that's not properly implementing least privilege — it has nothing to do with separation of duties.)

How does this apply to a more modern workflow? You can't easily configure your repo so Alice only reviews code and Bob only opens PRs (at least, not without custom roles). Nor can you control that Alice doesn’t have both of these permissions at the same time. But branch protection rules make sure that Alice can’t approve her own PR — which is what actually matters. And we see similar controls in banking, so that individuals can’t approve their own expenses.

This isn't really a ‘traditional’ access management problem. The systems where these high value or risky transactions take place (like for payment processing or production changes) already require a second reviewer. The control isn’t implemented using roles, but rather implemented at the transaction level, and decides whether or not an individual can approve their own transactions.

Implementing separation of duties as blocking toxic role combinations is a reasonable control. But it really exposes that you don't have the control you actually want: to limit self-approval at the transaction level. And if a SaaS app doesn't give you a way to block self-approval, I have no reason to think its role-level controls are any better.