Identity and Access Management Considerations in Complex Environments

Identity and Access Management 

Considerations for Complex Environments

by: James Carpenter, CISA, CISM, CISSP

A friend and I were discussing the various opportunities and challenges with the enterprise Identity and Access Management (IAM) solution we implemented years ago in a large, complex environment. There were so many aspects of IAM covered in that conversation that I felt like I had to write it down somewhere so I wouldn't forget just how complex this thing really was! Wouldn't you know it, at about the same time I saw a job posting looking for someone skilled in IAM to assist in the IAM merger of two organizations and that sealed the deal. I had my subject for a blog! Following is my list of the major lessons learned, the opportunities uncovered, considerations in planning, and other anecdotal tidbits to help others along with this complex subject.

It's a Journey!

Firstly, implementing a full-scope IAM solution is a journey. This isn't something you knock out in couple of months. I think of IAM as a journey comprised of several back to back projects; each delivering it's own type of benefit. Additionally, some of these projects are more accurately represented as program components of IAM which are ongoing forever; maintenance, if you will. I modeled it below.

Figure 1

Starting from left to right, the first two things (orange) you'll want to do is set the proper foundations which drive your automation. These foundations are establishing Role Based Access (RBAC) and the HR Actions and Criteria that your HR system will use to drive the IAM engine. These are super critical to get right. There is room for tweaking but the farther you get down the road of automation, the more impact subsequent changes can have and the more complex the analysis becomes prior to implementing those changes. Also, different companies have different HR actions that they wish to automate and some that they don't want automated. I will discuss some situations where not automating may be in your best interests later in the article.

Moving into the green shape we connect our directory. This is where we get our first massive return on investment (ROI).  It is also at this crucial point where staff skillsets start needing to change and where your first technical complexities begin. I will also elaborate on this later in the article as well. Notice that upon connecting the directory we have P1 (Project 1) 'Migrate apps to directory'. This should have been going on all along as part of an overall application strategy but it simply means - "all those other applications that you have that aren't tied to your directory authentication" - those need to be aligned. You increase the power and ROI of your IAM solution when you standardize your authentication to something that is already "hitched" to automation. You won't be building new connectors to applications per-se; rather you'll be writing new logic within existing connectors. P1 is one of those aforementioned 'forever projects'. You will always have applications onboarding in large, complex environments. Thus, the arrow extends perpetually to the right. 

     

    By the model, the next area to hit is your critical applications. You'll have to determine what those are but typically an organization will have 5-10 of these. These are applications that are the backbone of your organization, are subject to heavy controls auditing, or comprise the majority of your authentication and access needs (volume). Once you connect these critical applications, you begin another 'forever project' called 'Access Certifications', or checking the validity of your RBAC decisions on a periodic basis. Times change and so will your IAM logic which maps to your RBAC settings in your IAM. For example: When you initially established your RBAC, you may have build a model that authorized staff in Finance to have Remote Access, Finance Department Network Drive Access, and access to the Financial Application. What happens if, over time, several new applications came on board and/or the network drive structure changed such that the old directory rights are no longer valid? You'll have to update your RBAC list and consequently the logic in your IAM solution. This can be ongoing by some cyclical process or periodically assessed to ensure you don't have 'role drift' - situations where designed network and application access drift from the requirements of the job role. Doing this will take you a long way (to the good side!) in your audits.

The last step is to integrate your remaining applications. This is the last step in my model because as you mature your IAM implementation, you will note that there will be increasing complexity and a decrease in 'apparent' ROI or 'bang for your buck'. The work you do from here on out will be a balancing act best characterized by a favorite phrase of mine - "automate until it becomes painful." See Figure 2 below. The sweet spot is high benefit to the organization and low-medium complexity. 

Figure 2

Three signs of decreasing ROI when automating an IAM solution are:
1. Less bang for your buck. You put in hours, days, or months of labor into automation but only automate a small percentage of users or applications. The effort may not justify the outcome.
2. Complexity becomes unmanageable - similar to point 1 but maybe your efforts should be on the "other side" of automation - an application strategy that reduces/consolidates the number of applications you have or centralizes the authentication to your directory. You might have other problems that you needn't tackle with your IAM solution.
3. You're having trouble justifying further expansion to your leadership. Maybe an IAM technician wants to do it for the sake of your IAM solution becoming a monument to technical awesomeness but if you can't justify it, your leaders won't buy in.

 

Automation and RBAC 

By the model in Figure 1, we're still talking about orange territory here but there's plenty to say about linking your IAM solution into your HR system and directory to create automation. Common automation use-cases are employee resignations or terminations, new hires, leave of absences, and suspensions. What does your company want to do related to access in these situations? This is where your RBAC decisions come into play. Notice that in the model, I started with connecting the directory. In my experience, starting your RBAC with the directory first is a massive win. In most cases, your directory will be Microsoft's Active Directory (AD). By connecting to AD first you instantly gain automation against network file shares leveraging AD, your desktop and laptop environment, and a good chunk of all your applications leveraging AD authentication. This is a big win and here you should write your first rules.

The first rules to get established should be those around access - not necessarily the roles within an application or what network shares can be accessed - just whether the account can log in or not period. Is this account enabled or disabled? So many audit findings and incidents revolve around accounts that were not disabled in a timely manner. Linking your HR system to your directory via the IAM engine creates a rapidly compliant and effective environment for this problem. It's your first big ROI out of the box. See Figure 3 below for how this can be architected.



Figure 3

 

When wouldn't I want to automate?

Earlier, I noted that there are some situations when you don't want to automate. One such situation might be your employee portal where all employees, even former ones, can go to view their paychecks (or past paychecks), W-4, benefits, etc. I've ran into situations where some companies allow former employees to retain access to their HR system. The key here will be to limit what is accessible for former employees. You'll have to be keen on restricting access within the HR system once the employee leaves, something the IAM engine can automate.

Another situation where you might not want to disable access relates to your training system. I've worked for companies where employees and contractors could be suspended until they took mandatory online training. In such cases, their access was disabled. You might be surprised at the number of employees in a large organization that fail to take their mandatory training on time and get suspended. Of course, the real fix here is to ensure all employees take their training but in the case where some don't and have their account flagged for suspension - you'll want to leave the training access enabled so they can work their way out of suspension.

There might be a few of you out there that are saying "Automate everything! Even these two scenarios should be automated." To that I say, "Thank you" because it introduces a nice segway into the next section where I discuss a key concept - flexibility.

Architect to Promote Flexibility

As you clean up your environment and automate by building the IAM engine and adopting an application strategy that centralizes your authentication back to your directory, your directory engineers may start complaining that the directory is running slow. One reason for this is that you are aiming an increasing amount of authentication queries at the directory and it's getting bogged down. There are ways to optimize this; for example, by ensuring your users are organized properly and LDAP queries are not searching the ENTIRE directory. However, even after all optimization is done, you may need to peel off separate authentication directories to promote flexibility. See Figure 4 and 5 below for a before/after example of this.



Figure 4

In the "Before" example we see that all the organization's applications are querying a single directory. Also, there are some inefficient queries going on that are searching authentication requests from the root. Yikes! I bet it takes a long time to log in at this place! And, for all the Directory admins out there, we see the unnecessary OU that exists in every organization. You know it's true!!




Figure 5

Now we see the "After" configuration. We have created a separate directory to store user information and have synchronized it with the root directory. Also, we are only propagating what we need to authenticate the applications we move over to the new directory (Directory2). We have selected a few applications, such as our training and HR application noted above, to move over to this directory. By doing this, we have fixed the "all or nothing" problem related to enabling/disabling accounts and created some flexibility. Also note that the admins still didn't get rid of the unnecessary OU. They'll probably bring in contractors for that. :-)

Technical Complexity and Staff Skillsets

I did note that I would elaborate on staff skillsets and technical complexity. The more you automate, the less staff you'll need on the manual side of things (creating accounts, disabling accounts, modifying accounts) and the more staff you'll need on the automation side of things (managing the IAM solution) although it's not a one-for-one relationship.

One reason for this will be the mechanisms used for account touches (creating accounts, disabling accounts, and modifying accounts) will be form or web based from the IDM engine vs. logging into each application and setting up an account. Access Management staff can enter the data into a form or webpage hosted by the IAM solution and the IAM solution can create the accounts. Your goal will be to standardize on these form or web based entry points to promote consistency. Another good reason to utilize the IAM form or web based entry points is workflow. Most enterprise IAM solutions have some form of workflow. You'll want workflow for your non-RBAC (manual) processes because most access requests will need some form of approval workflow.

Another reason for the shift in skillsets will be the upkeep of the IAM itself. Connectors will need to be built to applications, troubleshot to ensure updates are occurring in a timely manner, forms and web pages developed, etc. This is an opportunity for your organization to grow your access management staff. Access management doesn't have to be a dead-end job. It can lead to IAM and subsequently workflow development which can open all kinds of doors. Once an individual understands that most applications are essentially forms and workflows atop a database and they can develop in those environments - a bright new world opens up. It's much more than programming and testing - it's talking to people, understanding business, and translating that into workflow. Good people skills and business process understanding come in handy. Have any people like that? They will be good candidates.

 

Wrapping Up

 There is much more to say on this subject such as staffing models for transitioning to an IAM, Budgeting for an IAM, project plans for implementation of an IAM, how to sell IAM to your leadership, etc but I've run out of steam!

I will finish with this: If implemented and managed properly, an IAM solution will become the backbone of an organization's access management solution, save money, increase compliance and efficiency, and provide opportunity for growth of IT staff.

If you're interested in learning more about IAM solutions or are implementing an IAM and would like assistance in planning and design please feel free to reach out to me through LinkedIn or email me at iamhelp@98g.us. I would be happy to help your organization get it done right the first time.