Don't hire the magician - why you need certification? Road to Governance, part 3.

Let's assume you are responsible for security in your organization and one day a highly recommended magician comes over. He proposes that he can magically make you company secure, sort out all accounts and entitlements so everybody suddenly has only what he needs. Sounds nice, doesn't it? And he offers to do all that for free. Would you go for it? Let's say you would.

What next? Is your job done? For now, yes, but what is going to happen during next year? New people are going to be hired, some are going to change positions, you will have new application, possible responsibilities of some positions will change. This means that in a year from now accounts and entitlements are going to become messy again. What to you do then, call the magician?

The point is that identity management is not about getting accounts and entitlements assigned in a correct way it's about creating a process that keeps them correct in the long run.

This is where we need certification. Identity certification is not exceptionally innovative, it is a process where someone responsible checks, on regular basis, if least privileges concept holds true for your organization. Certification comes in various forms and there are many reasons why it should be considered.

Major reason is of course to keep entitlements of your employees correct at all times. But as I described in previous post, roles are supposed to do that, right? Well, almost. I have never seen a company where all accounts can be assigned purely based on defined roles. There's always a margin, bigger or smaller, where account and entitlements must be assigned based on individual requests and approvals. Now what happens when a person with such privileges moves to another position? She will get new roles and lose the old ones so some of the entitlements will be be taken care of. But what about all that was assigned based on requests? changing roles will not affect these. These entitlements will stay and the only way to address that is to run a certification. All above is based on the assumption that roles are kept up to date. What if the aren't (and very often they change and adapt slower than surrounding environment)? This only increases the need for well orchestrated certification process.

It's important to understand that there are few types of certification based on the goal we are trying to achieve. It's best to distinguish them based on what is being certified and who is responsible for it. There are three major types of certifications: resource owner, manager and role certification.

Information owner (could be known as resource owner) is responsible for managing access to "his" information, hence he needs a tool to perform the job. Resource owner certification will allow owner, on regular basis, to validate who has access to what they are responsible for so they can check if such access is still required for each employee. Similar situation goes for manager. She is responsible for her employees hence the tool to validate whether the current access is justified. Going back to example above, when new person joins manager's team, the manager should perform certification for just that new person to see if current entitlements match requirements for the position. In risk terms, if his team's risk exposure isn't unnecessary extended. During manager's certification both accounts, entitlements and roles should be validated. One could say that if you check the roles and then only entitlements outside the roles then access should be validated. True, but if we check all the entitlements even those outside the roles and revoke some of them we get an extra benefit. Next time someone runs role mining process to validate current status, he will notice that possibly the role has changes since a lot of managers removed the entitlement the was part of role but is no longer needed. This can be additional control in place to mitigate the risk of role not matching business environment (and from what I've seen this is one reason that can make identity system ignored by business and lead to project failure).

Role certification is there to make sure the roles stay correct. This type of certification should be ran by role owners and it's aim is to validate if entitlements and accounts that are part of the role should still be there. With role consolidation and regular role mining, role certification is part of the process that guaranties that roles match business surrounding.

One question remains. Is my organization ready for certification? You can clearly see that this is a necessary process but it is additional work for for managers, resource owners. Will they understand and agree to undertake the extra load? To help that, there are few elements of certification that must be in place.

First of all certification must use business friendly language, business entitlements descriptions that people performing certification understand. If you have don'e your homework you should already have all the names and descriptions in place as described in the first part of the my series.

Another element is the content. Should ALL entitlements and roles be certified every time? Of course not. There are ones that are important and valuable and there are ones that are related to low value information. Again, if we have approached identity governance process in correct way we should have all the entitlements and roles categorized based on risk. We can use it here. On one side certification design can be based on resource risk level. Run the high risk entitlements certification more often than the low risk. On the other hand if we use simple color coded identifiers we can provide simple visual indicators for business people to let them know what to focus on. Send following instructions for example "Please perform certification, focus on the red items as these are critical and livelihood of our organization depends on it, amber ones are also important and the green ones are to be done if time allows". Between the lines you send a message: This is important process that must be don but we value your time so we tell you what to focus on and use the time in best way.

Finally there is one more case for certification where it might be extremely valuable during identity project. When you are at the stage where you need to design the roles you might be tempted to use existing accounts and entitlements to come up with role propositions. But when you start identity management project most likely your entitlements are in chaos and from messy entitlements you will get useless roles. To fix that you could run first major certification to clean up the data and only then do role mining and get much better results to start with.

So, don't hire magician ;-) Design and implement certification process that will keep an order for years to come.

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.