Defining Role Management – Part 2

In part 1 of this multi-post blog, I laid out what I believe are the various disciplines that make up a complete role management solution. In this post, I will tackle the more contentious discipline – that of role definition.

Fundamentally, two camps have evolved around different approaches to the problem of defining roles. There are those that believe in the bottom-up approach of identifying roles based on forensic mining of data, while there are others that swear by the top-down approach of engineering roles based on well-defined rules and criteria. Neither approach is incorrect, and the truth is that for a lot of enterprises, using a balanced combination of both probably offers the quickest path to defining a good set of roles. The key to picking the right balance is in knowing your enterprise.

Knowing your enterprise means having a good understanding of the documented business rules that exist in your enterprise, and having a handle on the cleanliness of the data that will be fed into any mining effort. Sounds simple, right? But too often role engineering projects fail because people think they know these rules empirically, whereas the reality often is that their knowledge of the rules has not stayed in lock step with the evolving enterprise, resulting in outdated results at the end of exercise. The same goes for data cleanliness. If the mining is going to be done based on analysis of access privileges, then any bad data (rogue accounts, orphan accounts, inappropriate privileges) will result in distortion of the roles identified, often resulting in creating roles with bad privileges. As the old saying goes, “garbage in, garbage out”. A lot of our customers who are looking to embark on role mining projects have spent quite a bit of time (using provisioning, reconciliation and attestation mechanisms) cleaning up their access data in preparation of this effort. An interesting effort to undertake is measuring your readiness based on the above two factors.

Role mining is often viewed as a good analyst tool to give the role engineering project a kick start by identifying an initial set of easy roles. There is value, however, in using it in an ongoing manner, as the iterative run throughs can help in identifying outlier roles, special combination conditions, and further optimizations to the role definition. It can also become part of ongoing exception detection that is rolled into monitoring procedures. Mining can also help identify the patterns that will be translated into subscription rules for various roles.

The role engineering process can take these rules and privilege patterns, and create roles based on them. It can also allow customers to deterministically define roles that are more tightly aligned with business procedures than IT ones (which is what the mining process is more likely to reveal). Business rules are easily translated into subscription rules, and can be tied to privilege policies that are desired (as opposed to detected). A newer area of role management is the area of relationship/context based roles. These role decisions are not as deterministic and static in nature, and are less likely to be divined using a mining tool. However, they are much more likely to represent business roles that correctly reflect the state of your enterprise, and the context sensitive needs of your applications.

These roles, once engineered, can be fed back into the mining process to refine the pattern recognition, starting the whole process again, till a suitable equilibrium is reached. This is reflected in the flow below.

Click here for a larger view of the role definition process

Often, the needs of the enterprise will dictate which phase of the role definition flow you start with and put emphasize on. Role engineering definitely gets the call if the priority is to clean house. Conversely, role mining gets the call if the enterprise feels reasonably assured of the stability and correctness of their enterprise, and simply want to introduce automation and better manageability. How many times you iterate through the flow will end up being dictated by
your readiness factor (as described above). But, as stated before, adopting the flow is an invaluable tool in ensuring your enterprise IdM stays up-to-date with the evolution of your business.