Managing Identities

Security is often an afterthought in designing and maintaining computer systems. In the process a company can often have gaping security holes they are not aware of till it is too late. Also, over time it will end up costing way way more to accomplish what they want. You also end up with a very convoluted system that is difficult to manage and maintain. 

One of the most overlooked areas is in managing identities on the system. This involves creating new accounts, easily assigning rights, and in the end removing accounts when needed. Most companies have more than one system that they have users accounts on. Many companies will send emails around to the admins of the various systems to create accounts and grant rights. It can often take days to provision a new user into the system. During this time the user is unproductive. And it takes so much time from so many people costing the company money in man hours. However, with a good identity management system user provisioning can be easily streamlined. There are a number of products out there like Oracle IDM, IBM Tivoli, Microsoft FIM, Sailpoint, and NetIQ IDM. Interesting side note, NetIQ IDM is the oldest and most established product of the bunch. It started as Novell DirXML way back in 2000 (an eternity in computer years).

So what does an IDM product do for you? Well at a high level it lets you automate user management over multiple systems. You can create the user in a single place, often called the identity store, and the IDM system will automatically send information through drivers or connectors to all the other systems to create the user on all the systems they need to be on. Typically this happens in near real time. So now instead of a new user creation taking days it can take minutes. I worked on one system where the main identity store was connected to three different LDAP directories, four different eDirectory systems, two different Active Directory domains, Lotus Notes, and an IBM mainframe. When a new user was created the account was processed through the entire system to all the different end points in less than 5 minutes. I never really tested for a more granular results, but it was very fast. And they have all the accounts they need. They won't find out that the account on system X was missed. 

User changes are handled the same way. As a user works for an organization they often will be granted new tasks and responsibilities, or change positions. This will mean that their access will change. They might need access to a system, greater access than they had before, or they need access removed from a system because they maybe changed departments. So the change is noted in the IDM system and it will go through processes that will adjust the user accordingly in all the appropriate systems. It might only affect a single website, or it could mean a change in a half dozen different systems. The IDM system can handle all of that. 

Deprovisioning a user, deleting them from the system, is just as easy as creating them. The appropriate person executes the workflow to remove them and in moments the account is dealt with on all the interconnected systems. Now you don't have the issue that they have one account sitting live for weeks because the admin for that account was on vacation. The account has been properly dealt with system-wide. It is not uncommon with systems that use a manual procedure to find accounts that have not been used in months, and sometimes even years. But even more dangerous is a stale account that a hacker or disgruntled ex-employee finds is still active. Because now they can use that account indiscriminately for an extended amount of time with no one noticing. If a hacker gets hold of an active account then the main user will typically notice fairly quickly. But if it is an account left from a former user then no one typically will notice it's use, at least for quite some time. 

The IDM system will use something called drivers or connectors to interconnect systems. These drivers are configurable with what information they will share. You might have one system that you only need the user ID, first and last names, and the users managers name. Another system might need a dozen or more attributes on the user. You might actually need to modify the format of some of the information on it's way to the other system. Drivers are able to be adjusted accordingly. Most IDM systems can also be set up so that they will enforce rules like an identity can only be created in a single place. If they see an account created on an end point system the driver can be set up to reject or roll back the change on the end point system and notify the identity security team of the unauthorized attempt to create the account. It is important to consider where you want the authoritative identity source to be, and how you want to handle possible breaches. You also need to document what information needs to be where so the drivers can be properly configured. 

---

IDM and workflow

So we have been talking at a high level so far about how IDM works. You initiate a new user creation, a change in a user, or removing a user and the system takes care of the task. But sometimes there are complexities to user creations in systems. In larger organizations there are often approvals that need to happen for certain accounts to be created or granted particular rights. This is where workflows become important. A top notch IDM solution will have at it's core the ability to create robust workflows. But what is a workflow? Think of a workflow as a series of rules or actions that need to be accomplished for the action to complete. The workflow is initiated and it will evaluate events, like approvals, and then take appropriate action. 

​So let's say you have a user that has been moved up to an entry level management position. In their new role they need to be able to access the HR records for all of the people that now report to them. They also need to be able to approve vacation requests and time sheets in the HR system. So the workflow is initiated to allow that access. The workflow might be kicked off by an assistant in HR or someone on the help desk. This person does not have authority to authorize the new rights. So the workflow knows it needs approval from another person. It will see the need for the approval and send a notification to that person that an approval is needed. Once the person approves the request then the workflow will proceed with granting the access to the individual and send them notification that they now have the appropriate access. However, what happens if the approver does not respond right away? Well the workflow might have an escalation rule set that says if the approval is not granted in say 4 hours then a notice will be sent to the approvers manager to let them know that the approval is waiting a response and has passed the initial SLA. Depending on the workflow the manager might then give approval, or it might allow for the manager to contact the approver to find out what the hold up is. 

The thing with workflows is that they can be as simple or as complex as the organization needs. One suggestion is that you want to keep the workflow as simple as you can and as complex as you need it to be. Sometimes people make overly complex workflows and they become more of a burden than a help. The more complex anything is the bigger the chance of failure. This is as true in workflow design as it is in any other systems design. Strive for simplicity using the complex abilities only when truly needed. 

When you create a workflow the first thing you should do is to determine the flow on paper of what you need. What is the end point that you need to achieve? What approvals do you need in the workflow. What is the SLA (service level - or timeframe) for the tasks at hand? Who does it need to escalate to? Once you have the flow down on paper then it is a simple job to build the rules into the workflow in the IDM system. Using a flowcharting program like say Visio is a huge help for this. And that flowchart can be added to any documentation you create. It is also a very good idea to document the workflow as you create it and put the documentation in a common depository for the entire IDM team. That way if you need to adjust the workflow down the road you can go back to the documentation and see what the requirements were when it was initially designed. 

---

IDM and roles based security

So workflows allow us to assign users to the system and grant them rights. Good IDM systems will also simplify the granting of rights through the use of roles. What is a role? Well think of your organization and the people in it. Most organizations have fairly standard job titles for different positions within the company. These positions will have a defined list of tasks and responsibilities they have to accomplish. So a receptionist will have a certain, fairly limited, set of tasks and systems they need to access. It might be email, and a corporate directory, and the basic company internal social media site. We could call this a basic role. A help desk technician needs to do certain things and access certain additional systems. They might need access to the servers that hold software to install. Or they might need access to a licensing database for software. They also need access to the basic role. And a manager would need to some parts of the HR system so they can approve vacations, see pay levels for their employees, and recommend raises. Each of these sets of tasks and rights can be grouped together into roles. So if a person is a receptionist they get the basic role just like every other employee. A help desk person gets the basic role as well as the help desk tech role. The manager for say a development team would get the basic role and the manager role amongst some others. 

So the best way to think of a role is to think of all the things this person does because of their position in the organization. It is sort of like groups in a way. The key for good role management is to think of all the things that anyone in that role might need that someone else in the role might not need, but if they get access it would not be a security risk. Again, we have the simplicity/complexity rule here. There is a tendency for organizations to make too many roles because they take the idea of least access to an extreme. There might be a system that not all help desk people will need access to. But there is a certain level of trust the organization has for help desk people that says they could be trusted to handle that information or access to that system. So maybe one help desk person does not currently help with system X, but they could just as easily be cross trained to help with that without changing their position in the company. There is no reason to deny the access to that system. So the role would be set up to grant access to systems A, D, and S, even though they currently only use A and S. 

Down the road maybe the help desk person has gone to school and learned how to program. They get transferred to the development team for the internal Wiki. At that point their account would be adjusted to remove them from the help desk role and added to the Wiki development team role. The workflow for removal from help desk would remove the enhanced access to A, D, and S. The workflow to add them to the development team role which would then add them to the C and Q systems. Initially they might only use the C system, but as they learn more and are given more things to do in the team they start using the Q system also and they already have access to it. 

---

IDM tools

Some final thoughts you want to consider when looking at an IDM solution. IDM solutions are very different in how they work. There are still some systems that will do things in a batch process methodology. This means you create, delete, or modify the user and a job is put in a queue that will be handled maybe once or twice a day. So it might be 12 to 24 hours before the user is created, deleted, or changed. Some systems might have a 15 minute lag in processing. The closer you get to real time processing the better the system. Most systems will handle some if not all tasks in near real time (nothing is instantaneous). The more responsive the system is the more secure your system will be. Also, the more productive your users will be because they will not have to be waiting for the system to process the request. 

Second, how easy or hard is it to implement drivers between systems, and to create workflows? Some systems, like NetIQ Identity Manager use a graphical interface to build out rules. So time to implement new drivers or new workflows is very short. It also means that you don't need special programming skills to create them. Other systems, like Tivoli IDM, might use a programming language like Javascript to create drivers or workflows. Now you need a programmer to be able to write code to build out or change the system. Now you need a much more specialized skill set to implement and manage the system. This will also mean that changes to the system will take much longer to implement. This comes back to the simplicity/complexity rule mentioned above. Make things as simple as possible, and as complex as needed. When you use a programming language you can make something much more complex. But the question is do you really need that complexity. In my experience almost always you don't need it. And the more complex systems often end up with unintended security holes. 

Third, what different platforms do you need to support? Are you only using Active Directory? Then you only need Active Directory connectors. Do you also need to support other LDAP directories? What about a SQL database that needs identity information? Do you want to include Linux systems in account creation? Maybe your a school that has a large influx of new users every fall where you need their account information brought in from a database system in the registrars office. So now you need an LDAP driver, a SQL driver, and a Linux driver as well. Make sure your IDM choice can support all the different platforms you need identity information on. 

Fourth, another feature of a solid IDM system is the ability to track changes on users. Now you can have a solid audit trail on the systems. You might need this for SOX compliance, or for some other regulatory needs. Or someone on the system notices suspicious activity. Now you can track down where the account came from, or who changed it. 

The initial implementation might seem a little overwhelming. You will need to talk with all the stakeholders for systems that need identity. However, once the system is implemented a good IDM system will streamline identity management, reduce overhead, and tighten security.