What's wrong with the ANSI RBAC standard? Part 2 - Role-Role SOD is just too simple to work
By jeff.shukis on Aug 08, 2008
The ANSI INCITS 359-2004 specification (get your copy for a few dollars here) spends a good number of pages talking about something very near and dear to me: Separation of Duties (SOD). The specification describes “constrained” RBAC generally and then outlines two types of constraints – static SOD and dynamic SOD.
I am very glad that SOD made its way into the ANSI specification. I am also glad that the specification allows SOD rules that consist of role sets and not just role pairs – nice work guys. I’m not so happy about restricting SOD policies to sets of roles. In the “real” world, I have found that this approach is highly problematic. My view is that SOD policies should allow Role-Role, Permission-Permission and possibly even Role-Permission sets within SOD policies. A simplified scenario should illustrate the point.
Ignoring dynamic SOD for today, a static SOD policy defines a set of two or more roles and declares that a given user can’t be assigned to more than n of those roles where n is at least two. The simplest case is a set of exactly two roles – for example the almost famous “check requestor” and “check issuer” roles. A static SOD rule using these roles says, in business terms, “someone can’t be both a check requestor and a check issuer”.
The World's Smallest Bank
Imagine an oddly simplified retail bank. They do business with just three types of employees: Tellers, New Account Managers, and Branch Managers. Tellers deal with day-to-day transactions while New Account Managers rope in new accounts. Branch Managers supervise and develop exciting new marketing programs. This month you’ll get a shiny new toaster if you open a new account and then visit the branch again at least once. The special offer works like this: when the New Account Manager opens your account (via a button on a green screen of course), you are automatically authorized to receive a toaster at a later visit to the branch. When you next show up, the Teller gets an alert on their screen and can hit a button (another mainframe transaction) to “Gift” you the toaster, which is shipped to you immediately. It’s just an example – don’t over-think it.
Just Three Roles
The bank uses three Roles, “Teller”, “New Account Manager”, and “Branch Manager”, along with two relevant permissions “Open Account” and “Send Gift”. The New Account Manager role gets the Open Account permission while the Teller role gets the Send Gift permission. To prevent toasters from walking away, there exists a simple little SOD rule: Someone who has the New Account Manager role cannot also have the Teller role – no authorizing fake new accounts for yourself and them loading up on toasters.
Works Great At First, Then Breaks
For a while, the giveaway program runs like clockwork and the SOD rule successfully guards against errant toaster gifting. The offer itself is right on target; new accounts are flooding in, so much so that the Tellers are getting overwhelmed. Someone back in HQ steps in and declares that Tellers should be drafted to help open new accounts alongside New Account Managers. IT Security updates the Teller role to include the Open Account permission and new account wait time goes away instantly. Everyone is happy.
There is, however, one big problem. Tellers now have both the Open Account and Send Gift permissions. Toasters start disappearing (they must be really nice toasters). IT initially says that nothing is their system can be wrong because the SOD rule is still in effect.
The issue of course is that the SOD rule specifies a toxic role set while the real toxicity is a pair of individual permissions. In fact, the toxicity is always at the permission level and not at the role level. Declaring that a set of roles conflict is in reality a shortcut way of saying that some of the Permissions granted by those roles conflict. Defining role-role SOD rules can be useful at times (e.g. with abstract roles), but permission-permission SOD rules are more often the right solution.
To model SOD properly, one must be able to define SOD rules that reference individual permissions and these rules must be enforced when assigning users to roles, when assigning permissions to roles, and when assembling role hierarchies. Only then will our SOD rules survive the inevitable, even frequent, reshuffling of duties that we see in our organizations.
A Very Sincere Product Pitch
One possible reason that the ANSI ignored permission-permission SOD rules: it’s hard. The thorny problem when defining fine-grained SOD rules is that of hierarchical permissions. An ERP system can contain ERP instances consisting of modules that contain menus that launch screens that contain buttons that grant access to data sets. A given Permission might grant access at the instance, module, screen, or any other level of granularity. Unless your SOD system understand these hierarchical permissions in exquisite detail, it’s not possible to accurately define and enforce the needed SOD rules.
If you are working on SOD, I highly recommend that you check out Oracle Application Controls Governor (OACG). While not an RBAC product per-se, it’s the only system of which I am aware that gets an A+ from me for it’s spot-on way of doing SOD - including rules with hierarchical permissions. Brilliant stuff.
For reference, here are the roles, permissions, rules, etc. described above:
New Account Manager
Open Account (triggering gift opportunity on next in-person visit)
Not Open Account and Send Gift
New Account Manager – Open Account
Teller – Send Gift
New Account Manager – Open Account
Teller – Send Gift, Open Account
A role change has rendered the SOD rule useless. Tellers can now open accounts and send a gifts (a violation of company policy) without violating the SOD rule.