Posts Tagged ‘RBAC’

Modern day IAG delusions

Thursday, March 27th, 2014

“HR is the source of truth” –> Really? Are they reliable? Timely? Do they know about contractors? Vendors? Are they a willing participant in non-HR processes (such as access management)?

“Job title determines role” –> Really? Who defines job titles? What governance process determines what titles are valid and who can get which ones? How are they updated? Is the level of granularity of the random string of text on my business cards really the same as my access rights?

“Just define and assign roles, then all the access rights problems will be solved.” –> Really? You think the access rights of back-office workers are easily compartmentalized, well defined and static, so that they can be trivially assigned via roles?

It’s all about relationships, not roles

Tuesday, June 19th, 2012

Are roles the right way to control access?

In some cases, clearly yes — there’s a whole formal model of role-based access control (RBAC) out there and it’s worked well in some business contexts for years.

But in other cases, just as clearly, RBAC is inadequate.

I raise this because in the context of an identity management system, one of the things we have to do is control who has access to whose profile. For example, can one employee see another’s work phone number? Home phone number? Scheduled termination date? Who can edit these things?

It turns out that pure RBAC is a poor model for access controls in these cases.

If we use RBAC, then we have to define roles for users who can access this data. Whose data can they access? Everyone’s apparently. For example, we might say that “all employees can access the work phone numbers of all users.” Sounds reasonable. Another example might be “only HR can access home phone numbers and scheduled termination dates.” Is that reasonable too?

If we think about these examples, we have to conclude that RBAC isn’t up to the task. For example, do we allow one HR user to see another HR user’s scheduled termination date? What about his own? If Bob in the corner (who happens to work in HR) is going to be terminated on Friday, should he know that? That’s a security problem.

What about usability problems? I would think that co-workers should be able to find one another’s home phone number. What happens if someone is hurt at work and you want to contact their family? How about if there is an emergency off-hours and you want to call someone to see if they can help? Clearly, we want to open up home contact information — not to the entire organization, as this could raise privacy concerns — but perhaps to people in the same department or location.

The same thing applies to scheduduled termination dates. It would be useful for managers to be able to see and change these for their subordinates. For example, a manager responsible for a large segment of the organization might want to periodically see what contractors are due for termination in the coming few weeks and perhaps extend some contracts to allow for unfinished work. On the other hand, the same manager should not be able to see his own scheduled termination date, or that of anyone who does not report to him.

The common thread that runs through these scenarios is relationships. What one user — lets call him the requester — can see of and modify in another’s profile — lets call the second user the recipient — should depend not merely on the requester’s role, but also on the relationship between the requester and recipient.

That’s the context of access control decisions inside an identity management system. In other systems, context may include other things — how is the requester related to the data he wishes to access?

And this is where RBAC falls short. To make access control decisions about what a given user can see or do, we need more than the identity of the requester — we need context for their requested access. In identity management, that context is a relationship.

So why do I bring this up?

In previous releases of Hitachi ID Identity Manager, access control within our software was built on an RBAC model. What I’ve seen of other, competing products is the same — access control decisions are made based on the requester’s role and usually nothing else.

Organizations that wanted to manage sensitive data in their IDM system would then either have to exclude it, reducing the value of their investment, or write lots of custom code, increasing the cost of their system. These were not good options.

Starting with release 8.0 of Hitachi ID Identity Manager, we completely overhauled our internal access control model. Our customers first define relationships and then attach access rights to those relationships. Relationships can be anything — manager/subordinate, same-location, same-department, etc. Really any set of criteria based on each user’s profile attributes and group memberships.

This means that with Hitachi ID Identity Manager 8.0, organizations can easily model their real-world requirements, without resorting to custom logic. Want to allow managers to see/edit termination dates for their subordinates? No problem. Want branch office IT staff to be able to reset passwords for co-located users? Easy. Want to block HR staff from seeing their own termination dates? Simple.

Call us and try it out. You’ll be impressed by the difference a smarter access control model can make.

Does your SoD engine actually work?

Wednesday, January 6th, 2010

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.

— Idan