Rote Based Access Control

I think RBAC is, next to firewalls and SSL, the biggest silver bullet misconception in infosec. I cannot count how many times I have heard managers say if we just had rbac all our identity problems would be solved. These same managers work in companies that reorg every 6 months and outsource anything that moves. Not that RBAC is useless, it can solve some problems, but introduces some too, Pamela Dingle

Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare - they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site. ... What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

The other silver bullet fallacy the RBAC introduces is the idea that objects, subjects, and sessions can be bundled so nicely enterprise wide. People look at their nice org charts and assume that you just plug that into your directory and go. Works great in a domain with hard edges like a call center where discreet groups of people execute the same tasks the same away across many sessions. Not so good once you step above the rote task level. Interestingly "God level" access works well with roles too, but we are not supposed to be building systems with that stuff any more, right?

Comments

[Ben]

I think where people get into trouble with RBAC is in taking it too literally and too strictly. Dingle hits the nail on the head when she talks about the importance of mapping roles and rules. I'm currently in the midst of my first IAM engagement where I'm trying to help my client get a start on RBAC. However, rather devolve into turgid rhetoric on subjects, objects, etc., I've instead focused on roles being logical groups of people with a shared set of access needs. Who gets that role is then based, in part, on the rules associated with accessing those resources, while also co-signed by a responsible manager who can attest to an individual's legitimate business need for access. Thus, I have individuals mapping to roles, resources mapping to access groups, and then roles having multiple access groups to their credit, with the corresponding business rules governing who can have the role. I think this diverges from the traditional RBAC approach, but feels much more effective to me.