One of the most powerful tenants of any modern Identity and Access Management (IAM) system, and arguably a necessary foundational layer from a security perspective, is Identity Lifecycle Management (ILM).
ILM refers to the actual creation and management of user identities, taking appropriate actions for any changes, as well as the removal of identities across all the services and applications end users access within the organization's ecosystem. In fact, ILM is debatably the most important tenet of your entire IAM strategy because it directly ties into all the applications or services your end users access.
Identity Lifecycle Management Overview
Synonymous with automated lifecycle management (ALM), the goal of ILM is to automate identity processes across the organization’s environment. Automation ensures that identities across your organization’s disparate systems are in a state that matches your authoritative sources. Without an ILM engine, manually processing and managing identity changes and ensuring the appropriate actions are taken is very difficult.
While the primary focus of ILM is on the context of users, it can also refer to the identity management of any account that needs access. For example, ILM could be utilized for IoT devices and external services for service to service access.
It’s important to note that there are varying levels of maturity when it comes to ILM capabilities. For some organizations, basic ILM capabilities may be suitable for their needs, but for others with complex user bases that need managed, a higher ILM maturity level is required.
As navigating through these different ILM capabilities can be complex, we’ve developed a maturity model to simplify the process. Using this maturity model can help your organization determine the effectiveness of your current capabilities and also provide a decision path for increasing your ILM capabilities.
Let’s take a look into the capabilities and characteristics of the first half of the ILM Maturity Model: Levels 1 and 2.
Level 1: Homegrown and Manual Processes
While our ILM Maturity Model starts with Level 1, an organization could actually be at Level 0, meaning there are no capabilities currently in place to manage user identities. At Level 0, account provisioning is completely manual and done on an ad-hoc or reactive basis. As each user account is handled independently and manually, account details are prone to human error. In addition, onboarding, and the amount of time it takes to get a new employee online and productive, is often an issue.
On the other hand, organizations in Level 1 of the ILM Maturity Model have begun automating account creation with scripts. A script is defined as “a program or sequence of instructions that is interpreted or carried out by another program.”
In Level 1, an organization has accumulated a number of homegrown scripts that are focused on basic account creation, such as building Active Directory accounts. However, as these scripts are created for specific purposes, they are difficult to generalize for repurposing.
For example, when a new hire is onboarded, scripts can be set up to create their accounts and provide access to the various resources and applications needed for their particular role and department. When the next new hire is onboarded for a different role and team, he or she will need access to some of the same applications, such as apps for email and payroll. However, the new user will also need access to different applications that are specific to their role. This means either new scripts need to be written, or the accounts the second new hire needs will have to be created manually.
That being said, it’s easy to see how an organization can accumulate many scripts over time, which become complex and difficult to manage.
Scripts are typically created to solve ad-hoc requests, but are sparsely maintained, meaning most were likely side projects for the person who created them. Therefore, organizations in Level 1 can get into a real bind when personnel with knowledge of these scripts leaves the company.
When the person who wrote those scripts and knows their in’s and out’s leaves the organization, there is often no one remaining with the ability to maintain them, make changes or modifications, or even who has the knowledge to run them properly. This means normal turnover can put an organization into a situation where they have no ability to support current processes.
Furthermore, scripts do not take a holistic approach to other systems in the organization. For example, scripts can be built to rely on a particular system, but that does not factor in how the script will work for other systems, such as Active Directory, Google Suite, Salesforce, etc.
And while it’s easy to write scripts for applications that run in your own environment, such as Active Directory or applications hosted internally, as you start getting into cloud-based applications, you have to follow the application developer’s methods, which often require application program interfaces (APIs). This means part of the script would have to include some sort of connector or adapter to integrate with the third party, which is very advanced and becomes almost like application or software development.
Even though scripts are preferred over manually creating accounts, they still have inherent security risks. First and foremost, there’s room for human error, and there’s no error logging or test method to determine if a script ran successfully. Therefore, scripts can create a false sense of success, where an assumption is made that the script ran and the identity was created. However, if there was a hiccup and the script did not run to completion, the account would not be created.
Adding to the list of security concerns regarding scripts are that they can be used to create rogue or backdoor accounts. Deprovisioning, or removing access, is also a security issue for organizations in Level 1. If each employee has to be manually provisioned, it’s easy to overlook certain downstream systems or for the task to not be done in a timely manner or at all.
Level 2: Onboarding
At Level 2, Advanced, an organization begins deploying vendor-provided tools to manage their accounts. However, these are single purpose synchronization tools, meaning they only work to automate account creation in that one particular vendor's product, and were not developed to provide complete lifecycle management.
For example, an organization may subscribe to a new application, which allows an administrator to upload an Excel file for a bulk user import. While this import will allow you to create the accounts, that is where the functionality ends.
Generally speaking, most of these vendor-provided tools only create accounts, and there is no capability to remove an identity without manually going through each interface. So, you cannot easily remove the identity if a user leaves or is terminated from the organization, and you can’t make updates, such as transfers or other changes, including re-hires and re-names.
Additionally, these tools have rigid implementation options, and the organization is limited by the number of vendors that provide these tools. In immature organizations, where one person is relied on for creating accounts, processes are extremely manual and prone to human error.
When this contact is out of the office or unavailable, it creates a loss of productivity when a new hire is left waiting to access systems or cannot start working. Oftentimes in these situations, someone circumvents this issue by giving their own login to the new hire. However, this creates security issues, as someone else has access into another user’s data and can be a major issue with compliance in that the wrong person is being tracked on the audit trail.
It’s important for organizations to understand that singular vendor tools are not enough. In order to truly mitigate risk of a data breach, every application or service containing sensitive data should be actively managed.
Tune in to Our On-Demand Webinar to Learn More
At Identity Automation, we see a varied mix in terms of where organizations stand on the ILM Maturity Model. While Level 1 is the most common, organizations that are subject to more compliance regulations tend to be at more advanced levels, which are more responsive to changes in the organization. In Levels 3 and 4 of the ILM Maturity Model, there is very little human intervention.
At these more sophisticated levels of the ILM Maturity Model, the processes become more and more automated. The system can make the appropriate actions based on triggered events, such as when a person is hired in and knows which accounts need to be created, so the new hire is not waiting on other people to create accounts. Additionally, if there’s been a transfer or other change in the organization, the system will appropriately move the identities. Likewise, the system also knows where to remove the identities during offboarding.
Ready to learn more and see what capabilities the next two levels on the ILM Maturity Model have to offer? Make sure to tune into our on-demand webinar: Advancing Your Identity Management Strategy with the IAM Maturity Model, Part 5 - Identity Lifecycle Management.
In this webinar, you will gain actionable insights as IAM expert and Identity Automation Co-Founder, Troy Moreland, will discuss how to evaluate the maturity of your current ILM capabilities as well as providing a prioritization pathway for future goals.
Comments