Road to successful Identity Governance, part 2. The dark side of RBAC.

I have described the foundation for Identity Governance in my post here. Now it's time to use those pieces and make something use full of them.

The very common problem that often still exists (you would think that after so much has been written on the subject already, that people would understand ;-) is that there is a misconception that identity management is provisioning. I visit a lot of clients and they expect me to talk about how to connect to target systems and create accounts in them. Provisioning and reconciliation are important elements of the whole puzzle but are they certainly not enough?

I like to look at identity management system as a living organism. It has a muscles that can do wonderful things. That's provisioning, reconciliation, request and acceptance workflows, you need them to keep organization alive. But as with any organism, you need brains to tell muscles what to do. The brains of identity management is analytical part. These are the process that support roles life cycle, certification processes, SOD (Segregation of Duties). Without them you end up with very nice integrated system that doesn't know what to do and might be insecure.

How so? Ask yourself what is the main reason for Identity Management system? You might want to  do automation to speed up certain process. It's true but the main reason most of the time is to manage access to information in secure way. There are principals that we may use to help us like, least privileges or sod.

The first element of governance we have to look at are the roles and their life cycle support. Before we dive into the details it's important to understand what roles are. There are many flavors so which ones are we talking about here? There are IT systems that have roles inside them like database for example (DB Admin role). These are technical roles. We are dealing with business roles. They represent collection of privileges, possibly in multiple applications, assigned to an employee that allows him to perform his job. This collection is usually named after the position that person has like analyst role, marketing manager role. Keep in mind that a person might be acting in few roles depending on the task. This means one might have few business roles assigned to him. For example "Employee role" is something all people working in organization have. This role might contain email access and AD account but financial analyst role is assigned to someone performing such job in addition to being employee.

Every identity management system allows you to create and modify roles but is it enough? Obviously the first step in RBAC (Role Based Access Control) is to create roles. It might be much more complicated than it sounds.
You can do this manually but it can be very challenging especially for larger organization with many applications. Imagine excel with a list of all systems, privileges in those systems, accounts, and all the identities. Now you would have to come up with, what some of those users have in common (same positions , similar accounts and privileges). That's only the beginning. Even if you come up with few roles what happens next year when you have to verify if something changed? How easy would that be in excel?
That's why some vendors provide automated role mining tools to help with role discovery. Such tools allow to run data mining algorithms on your identity information and help you discover possible roles that are hiding in side. When organization goes thought changes you can run those algorithms again and see if there are any modifications to existing roles or new roles.
As convenient as RBAC sounds there is a down side to it. If you don't manage your set of roles properly "role explosion" might happen. You might keep adding new roles as business changes without proper validation and you end up with more roles then employees (I have see it with my own eyes). One of the mechanisms to avoid that is to use role comparison. Such tool can compare roles and provide a hints as to similarities. For example 90% entitlements in  Role A and Role B are the same. This might be a candidate to make one role AB and get rid of the 10% entitlements to request and approval workflows. If you perform such validation on regular basis you make sure you don't have unnecessary redundancies.
When you make changes to role you want to know what and when was it changed and be able to roll back to previous state if the new setup goes wrong. This requires versioning and audit. You might also need to keep track of changes for regulatory purposes.

There is one more important aspect to roles that is easily omitted, ownership. Why is it important?
When you have defined a role, once a new person get hired or changes position she will be assigned a role automatically and corresponding accounts and entitlements will follow with no further approval (you can still have approvals with roles but what is the point of having the roles in the first place than?). This means that roles grant access to information. Since all access to information should be governed by business owners (described here) roles should be approved by business owners too. What if the role contains access to information with more than one owner? Naturally such role should be approves by each individual information owner in his or her part.

As a result we have come up with a preferred process of building roles.

1. First we have to gather all identity information in one place.
2. Second step is to come up with role candidates using role mining tools.
3. And third step is to obtain role approvals from information owners that are part of each individual role.

Is there anything missing?
Roles allow automation of access assignment process. But when you currently have a mess in your access if you create roles based on it you will just automate the mess and this is not our goal (remember our goal is "least privileges"). I will write about how to deal with this situation in my next post.
Those of you who read my previous post might ask: Ii took us a lot of work to assign risk levels to entitlements, can we use these in roles somehow?That is an excellent question and answer is yes. Once you have defined a role, you can calculate it's risk level based on the highest risk of all entitlements that are included in it. Role risk level is valuable information for business approves or certifies to guide them on to the possible damage a mistake in a role might cause.

As you can see there are many sides to successful RBAC. Very important thing to remember it that role management is a process not a project. This means that you have to constantly review the roles and make changes according to changes in the environment. You have to monitor the quality of the roles and there is a process for it, it's called certification (but that is a story for next post).

Road to successful Identity Governance, part 1.

A lot has been written about Identity Management but I believe there are a few small pieces taken for granted and not paid attention to, where they have huge impact on over all success.

To find out we need to know, where to start? The very first question that one should ask at the beginning of the IDM quest is "WHO?". Who is responsible for this process? The consequences of the answer are significant and will have huge impact on the way we will design things later. "Who" means what kind of profile will people responsible for managing identities have, what will be their knowledge, will they have technical insight in to application, will they know how the business works and what is the information value for the company. 

To answer this question I always use following analogy: Let's go back in time before we started using computers in our daily business life. Back then, just as today, organization had valuable information requiring protection, just it's form was different, written on paper in most cases. If it was valuable for organization it was kept locked with someone having a key to it. So when you wanted to have a look at it who was the one to grant access to it? Guys responsible for maintaining the furniture, unlikely. It was the business guy responsible for this information. Moving the information "in to computer" shouldn't change a thing. We are a lot more sophisticated when it comes to how we process the information and IT are now the custodians but the information owner stays the same it is the business. It is business people that fully understand the information and it's value and they are the ones deciding who, when and how can access it.

Having established that principal, we came across the oldest problem since IT did their first project for business, mutual understanding. We have all seen a famous picture with a swing (here for example) describing challenges in It projects and the same problem arises within identity management.On IT side we have entitlements for example in the form of LDAP with groups like "cn=fingl13r,ou=fn,OU=example,OU=com" and what business understands is "read access to financial report for year 2013". If business is to manage information access how on earth will they know what this is if we present something like this "cn=fin13r,ou=fn,OU=example,OU=com" (It wouldn't be a good idea to try to teach them either). No matter if it's part of user's request or during certification business people need descriptions in "their" own language. Users need "access to invoices with ability to register and modify new ones" for example not technical representation of such privilege is some application.

This brings us to the first milestone on Identity Governance path, business description of technical entitlements in IT systems. If done right users shouldn't know nor care in what system such account and associated entitlements exist as long as it results with appropriate access to information. We could go one step further and tag all the entitlements with the right keywords. Then a user looking for access to business information could search for access using business vocabulary.

That way we create a translation layer between IT and business. This creates additional advantage. If in future we change the back end system we will not have to do anything (well, not as much) about teaching users on new access rights as long as the information inside stays the same, we will just map business names to different entitlements in the new system.

There is also another side to entitlements. In our daily life we know what are the most important things for us and devote most of our time to them where things that aren't as critical get a lot less attention. What if we could apply the same principal to identity management?

The basis for this is classification. You have to classify entitlements with the risk level each of them is carrying. Administrative account in financial system will have high risk associated with it, and read access to company's employee bulletin will have a low risk. How many levels to use? It depends, but to keep things simple I like to use three values especially since you can use green, amber and red colors for them that everyone understands.

Now, where and how we can use it and most importantly what is the benefit for business? We have to answer the latter one because you will need their help to determine risks for a lot of entitlements. The answer is obvious: We need this to save time and help focus on what is most important for organization. Imagine certification process where data owner or manager needs to confirm access to information she is responsible for to thousand of users. If we have entitlements classified we can filter them based on risk level and define certification policy to force monthly certification process only for high risk level access (which will have a lot less users) and low level only once a year. That will make sense instead of doing all the entitlements each time certification is done. Similar value goes for approvals. When request for access comes in, if it's marked green it will not require second thought and can be finished quickly and when the red request comes in, approving person will notice and might possibly do more detailed validation. It's an ideal situation from the security governance perspective. People are devoting time on security related actions where it is worth it. If we do the classification right, security will be better aligned with business objectives.

As you can see these two seemingly simple elements business entitlements descriptions and entitlements classification build the foundation for any further steps towards successful identity management process.

Next time I will talk about processes you will need not only to build good IDM system but to keep it like that in coming years.