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.