Friday Mar 06, 2009

RBAC - Reveal to the Business you Always Care

I was recently engaged with an EMEA customer who was starting to evaluate role mining tools and methodologies to allow them to start developing an RBAC model for user access and provisioning.  The organization already had some concept of application specific metagroups or universal groups that allow the pairing of users from different areas to access similar entitlement sets.  Their main driver, as with many customers looking to utilize roles, was to migrate what they already had an application level and attempt to group people together in an easy and time efficient way using role and data mining techniques.

The main focus from the customer then tends to be at the application level.  Performing mining or clustering purely at the application level, looking at entitlements, ACE's, groups, profiles and so on, but taking no interest in the business related characteristics of the users involved.  In my experience this can be quite dangerous.  It can be quite easy to data mine on a group of users within a single application.  You simply select which application attributes you want to analyze and the role generation tool - whether that's Sun Role Manager or not - will simply analyse the data it's presented with and produce a recommended list of roles.

These roles will contain groups of users mapped to values of the attribute you wanted to analyse within the application.  The resulting roles are simply a list of user accounts mapped to potentially several hundred application specific groups.  As a pure data mining exercise I am sure this is quite exciting.  Looking at attribute values, performing a simple boolean evaluation against every subject in the user set, and adding the user to the object listing if it matches.  Then move onto the next user...

In business terms though, what can we do with these roles?  Here's an example.  We take an Active Directory domain which contains 10k users and 30k groups.  We perform application centric role mining.  Looking just at memberOf for example within this AD domain.  We analyze all ten thousand users and come back with - for arguments sake - 500 roles.  Each role contains approximately 20 users and 50 groups.  The roles map well.  No outliers, no users associated where they shouldn't.  But how do you then name these roles?  This may sound like a simple question but how do you name the roles?  The role contains so many groups that it would be impossible, to associate a logical application function to the group.  As we analyzed all users within the domain regardless of their location, job function or position it is impossible to associate a business function to the role.  The roles simply then become a data classification exercise.

Without being able to name the roles and apply some sort of function, it becomes increasingly difficult to use the roles in a provisioning landscape.  How do you know which new users should be associated with the role in the future?  who should 'own' the role?  Who needs to be contacted if the role needs to be changed?  The role will simply remain in the ownership of the IT security administration team.

The end goal of any role mining exercise is to give business value:  Reduce the time costs associated with user provisioning.  Increase audit effectiveness.
 Create a stronger foundation for reporting and access management.  Improve security by imposing work flow management on entitlements with specific owners and actors. And so on.

The main deliverable must always be to give value to the business and the best way to achieve that is to include the non-IT functions of the organization during any role creation and mining processes.  This could be as simple as using HR data during the mining exercise, or consulting team leaders on role membership results.  The main result though is to be able to give a level of business understanding to the roles that are created.  This increases the level of ownership the non-IT functions will have over the role framework and increase the effectiveness of any roles created.

From a practical perspective perform hybrid mining - include HR attributes during application mining.  Or perform business role creation first to group employee's together before analyzing entitlement sets.  Engage non IT teams and functions in access management and role engineering workshops and project initiation.  Just like any software design process, role mining is quite iterative.  It requires customer involvement for feedback and understanding to help bridge the gap between the business and technical streams.  A business analyst role (pun intended) can help with this by bringing together the business requirements to the IT tooling.

Like any technical IT project, no matter how fancy or clever a piece of software is, it MUST give business value.  The best way to do that is include the business in every step practically possible.


The musings, comments and thoughts of Simon Moffatt, EMEA Principle RBAC and GRC Specialist @ Sun. The postings in this blog are my own and not necessarily those of Sun Microsystems or it's partners...


« August 2016