Identity Management and Its Role in Security Strategy of Enterprise Environments

Enterprise environments are usually anything but homogeneous.

So IT folks get confronted with many different operating systems, often many of them are not using the same user and group databases or any compatible processes for configuring for access control.  This is a reason why Identity and Access Management, IDM or IDAM is a term that we run into quite often and companies are spending a lot of money on it.

Why do I think, this is worth to be an article in 2600?  We are all interested in IT and security and in my humble opinion everyone at least should have a little background knowledge on what the whole thing is about and why it should be part of a complete and efficient security strategy.

Identity management sees the whole identity of an employee, instead a single account within a system.

Important information about an identity stored in various, independent places is not easy to consolidate and report on, so several data stores make it hard to control who has access, where, when, to what and for which reason.  This is the reason, why IDAM should be part of security strategies, not only in enterprise environments, but in any heterogeneous environment.  The more different systems there are, the harder it gets to keep track of user entitlements and accounts.

Having different data stores for user accounts requires several administrative interfaces to manage them, which might require additional resources for account management.  Now picture this in a bigger company and mostly we will find departments being responsible for one system each: Windows, Active Directory, UNIX, Linux, SAP, and so on.

All the IT personnel is responsible for creating and managing accounts in the different systems, but the data within the systems is mostly not owned by IT, but by other departments.  In many companies we will find a huge variety of process landscapes built around how access rights are being granted and created.  Wouldn't it make life a lot easier and the whole account and entitlement administration more secure if all actions could be done through one single interface, which can be operated by anyone in the business?  The data owners could decide, approve and manage who needs access, recurring attestation for user entitlements could be automated and again being handled by the accountable employees without having to involve IT.  This not only improves efficiency, but also security because there are no processes involving more people than necessary and we have a single source of information.  This way reporting on access rights becomes child's play.

This is where IDAM kicks in.

A basic IDAM solution will be the single point of administration for all accounts and access rights of an identity.  Of course, it is necessary to have connectors to each and every target system which will ensure the IDAM solution will be able to take the necessary actions within the target systems and directories.  Basic connectors to the most common systems and directories usually come with the IDAM solution either included right away or as add-on modules.  Connectors to non-covered systems can be created either via external APIs or even from within the IDAM solution itself.  The complexity creating connectors is not only based on the IDAM solution, but also on the API and documentation that comes with the target system or directory.  A very rudimentary connector could just import a text file on a regular basis.

With the most basic IDAM solution, the challenges of several administrative interfaces has been removed, but most likely this won't help with the involved processes and the fact that it will most likely be mainly administered and maintained by the IT department.  So taking it a step further, the solution will come with flexible Role-Based Access Control (RBAC), automation, workflows and modules that will allow self-service and delegation.

RBAC will allow you to define roles within the IDAM solution, entitling users to create, update, disable or delete identities, accounts, departments, groups and equivalents.  Roles allowing you to create other roles and assigning them to users, populate departments and groups.  Roles defining workflows.  Roles, roles, roles.  You now realize that this doesn't have to be done by the IT department anymore, right?

Parts of it of course will remain in the responsibility of IT and that should never change.  Many duties and responsibilities can now be taken over by other departments.  Not IT, but business.  Those are the people who know which user should be granted access to R&D, financial, manufacturing, or other data.

How should someone from IT know if Debby still works in HR and therefore still needs access to the employee database, or if Alan, who is a contractor hasn't already changed projects, but is still able to VPN into the companies network?  IT usually doesn't know, business does.  Direct reports, sponsors, project managers, supervisors, team leaders.  Those are the people who know who is still working in their projects, departments or manufacturing sites.  So shouldn't those be the ones to decide who is able to access the network, systems, files or folders?

No, they shouldn't.  Why?  Because they don't necessarily see, realize, or understand what networks, systems, files or folders are.  But what they understand are job titles, departments, they know their direct reports and who is working for them.  Now, let them decide and attest who is still working in their team, who is still involved in the project and therefore who needs to be in their groups.  We see that this is an important chapter of an IDAM solution as well.  Translating access rights to something that is recognized and understood outside of IT, even by those who are not interested in how it all works.  A good IDAM solution will take care of this and will even go one step further by: automating processes like adding all users in a department in the appropriate groups, granting all access needed for people with a specified job title, like VPN access for consultants often working from remote locations, etc.  Basically granting as many rights as needed, but as little as possible to do their job.  This is a basic principal in IT security.

A well-known example of what is common practice in enterprises: Bob moves from Helpdesk to Datacenter Operations.  He already has several entitlements like updating user accounts within AD, resetting passwords, etc.  One of his colleagues in the Datacenter Operations is Jim.  He has a list of entitlements needed to get the job done.  If there is no definition of what access is needed, someone will most likely request the same access rights for Bob as Jim does.  No one remembers to remove all the rights Bob still has from his position in Helpdesk.  Jim retires a couple of month later and a new colleague, Tony joins the company.  Well, Tony will most likely get all the entitlements Bob has, including all the stuff Bob used to have working in the companies Helpdesk.  This is not needed for Datacenter Operations though, but who knows this?

Managers, supervisors and other data owners should review access rights on a regular base.  This way even without an automation engine, it is more likely to find and eliminate wrongly assigned entitlements.

There are IDAM solutions out there that will even automatically manage assets like mobile phones, computers, desks or wastebaskets setting off an order as soon as someone new joins the company or changes jobs.  Not exactly a security feature, but still a very nice functionality feature improving efficiency.

Another aspect which should be considered during a complete IDAM strategy is data governance.  Data owners, retention policies and access rights are important and should be known, managed and reportable.  An IDAM solution should support the business and employees by data- and role-mining.  Finding out who has access and who actually accesses data regularly helps to determine ownership.  Data owners are important as they are responsible to decide who should have access and who shouldn't.  Supporting data owners by reminding them to check access lists and retention policies will help to meet internal or legal regulations.  This is nearly impossible to automate completely.

Let's look at another challenge which often is forgotten when planning IDAM strategies: generic accounts.  Many generic accounts are high privileged accounts, but since there is no identity connected to them, they are hard to handle and manage.  Frequent password changes and control over passwords spreading is not easy when there are no efficient and reliable processes in place.

Picture the following scenario: Bob knows some root passwords and passwords to service accounts from his job in Datacenter Operations.  Root passwords are not changed frequently, even worse are the passwords to service accounts that haven't changed throughout the last years.  It's just too much effort changing the passwords on all machines the service actually runs on.  Bob leaves the company for whatever reason.  All of his accounts get automatically disabled and deleted after a while, as they are managed by an IDAM solution.  But no one changes the passwords to all of the root or service accounts Bob still knows.  Some of the system owners don't even know that Bob knows the password as they changed into the position after Bob joined the department.  There is no guarantee that all of the passwords can be changed when Bob leaves and shouldn't be able accessing any system in the network anymore.  And on top of that, he knows the root password to some R&D workstations still from his time in the Helpdesk.

We all know this is nothing we would like to account for, right?  And this doesn't fit into the only as many privileges as necessary, as few as possible principal described earlier.  A proper delegation model, not only for roles but for generic account's privileges as well should be implemented.  This is just as important as a working, reliable strategy on handling generic, privileged accounts and their passwords.

Not only RBAC is important to become compliant to rules and regulations, but segregation of duties.  Making sure the one who requests access isn't the one approving it.  This would defeat all principals of the best RBAC design.  And wouldn't it be nice of the IDAM solution to check on compliance during request time already?  As always and anywhere in life there are some exceptions.  These should be covered in the workflows as well.  Maybe with an extra approval by a CIO or a security and compliance officer or both in a four eyes principal having to re-attest the exception after a given time so the exception won't be a constant temporary arrangement.

Some comfort making the user's life easier comes in the form of Single Sign-On (SSO).  Users have to remember a lot of passwords and keep track of changing them as well.  Not only passwords used at work, but also their personal ones.  This is not only stressing the users themselves when having to login to several systems each day, but as well the IT (Helpdesk) staff who have to reset forgotten passwords, reactivate expired accounts and so on almost daily.  It is so much more comfortable to log in to your workstation then being able to use any system you need without having to enter your password another time.

For sensitive systems, SSO might not be the best thing, but then a strong authentication solution using tokens, smart cards, biometrics or something similar is always better than just entering a password.  Users tend to write down passwords and hide them in easy-to-find hideouts.  During my time in Helpdesk I've really seen Post-it notes under keyboards and yes, even sticking to the screen!  In addition to that a self-service portal for password resets will ease users' and IT staff's life a lot.

Last, but not least logging and reporting should not be neglected.  In combination with alerting, it's not only used to reconstruct what happened, but also to limit the damage that could have been done.  There are not many people I know who like reading log files.  Being able to easily filter line noise and making the log human readable is just as important as creating customized reports for auditors or anyone else who needs to audit what's going on.  Alerting on changes of attributes that shouldn't be changed will enable you to prevent worse happening afterwards.  Some changes won't have an immediately obvious impact, but might just be the precursor to a real problem.  When alerted right away on the change, instantaneous actions can be taken.

There are a lot of aspects that should be understood when thinking about a complete Identity and Access Management Strategy.  Most of them are not even new, but being looked at from another perspective, more connected and more integrated than in the past.

I hope I was able to draw a picture about IDAM and what it means to the security strategy not only in enterprise environments.

Thank you.