Segregation of duties (SoD) is a pretty fundamental tool used to prevent fraud and other bad behaviour.
Fundamentally SoD works because it prevents one user on your network from having all of the entitlements that are required to do something bad. In other words, having effective SoD engine means that the bad guys have to collude to do bad things. It takes more than just one bad guy to do harm.
SoD policies are generally defined as toxic combinations of entitlements. The classic example: a user who can create vendor records cannot also issue payments to vendors. The toxic combination here is two entitlements: (a) creating vendors and (b) issuing payments.
In general, an SoD rule may specify that a single user should not be assigned more than N of M entitlements, where N is less than or equal to M. For example, you might define 20 entitlements and define an SoD rule that prevents any one person from having more than one of them.
So far so good — what’s so tough about that?
First, entitlements might appear on different systems. For example, no user should be assigned both this Active Directory group and that SAP role. That means that SoD enforcement needs to be in the identity management infrastructure, rather than locked into a single application’s silo.
Second, entitlements might be grouped into roles. A role is nothing more than a set of entitlements — which themselves are security groups on systems and applications, login accounts on systems and applications, or other roles. Keep that last bit in mind — roles can be nested, which means that role definitions can be quite complicated.
An SoD rule might be expressed in terms of individual entitlements, in terms of aggregates (roles) or both. It’s natural, for example, to create a role called “Vendor management” which includes all sorts of entitlements to do with looking at, creating, modifying and deleting vendors in a financial system. You could similarly create a “payment management” role on the same financial system. The natural question is then: “how do I prevent a user from getting both the vendor and payment management roles?” Do you define an SoD policy in terms of specific entitlements, such as “create vendor” and “issue payment,” or do you write it in terms of the two roles, or perhaps you need both kinds of policies?
If you define the SoD rule in terms of individual entitlements, you’d better make sure that your SoD engine will detect and block users from getting a combination of roles that includes a toxic set of entitlements.
Conversely, if you define the SoD rule in terms of roles, you’d better make sure that your SoD engine will detect and block users from getting a set of fine-grained entitlements that are equivalent to the roles you said were not simultaneously allowed.
I know that we got it right in the Hitachi ID Identity Manager, but I’ve been told that some of the SoD engines — embedded in other user provisioning products — will miss some SoD scenarios.
If your SoD engine doesn’t reliably catch all violations, then it’s worse than having no SoD engine at all — you have a false sense of security but your controls are actually not effective at all!
If you’re not sure, here’s a little test you can run:
- Create four entitlements — say Active Directory groups — in your environment. Call them Ea, Eb, Ec and Ed.
- Create two roles on your user provisioning system: R1 which includes Ea and Eb and R2 which includes Ec and Ed.
- Define an SoD rule in your user provisioning system that prevents users from having both R1 and R2.
- Create a new user and assign Ea and Ec to that user.
- Add Eb to that user — this should not violate your policy, so should be allowed.
- Add Ed to that user — this should violate your policy, so should be blocked, since the user will now effectively have R1 (he already has Ea and Eb) and R2 (he already has Ec and you’re adding Ed).
I bet you’ll find that the last step — adding Ed to the user, won’t set off any alarms. If it doesn’t, you should start worryiing, because your SoD engine is broken.
Have fun! Ping me if you find that your system works (or doesn’t) — I’m quite interested to learn which SoD engines out there are effective and which ones aren’t.
We gave a webinar about this stuff a while ago — if you’re interested, you can access it here: