You would think that managing identities and access rights in an organization would be settled, solved and routine by now. But the ebb and flow of disruptive technologies such as cloud-based systems, mobile apps and bring-your-own-devices (BYOD) have made it as elusive as ever.
Identity and access management, or IAM, is the business and technology concerned with effective management of all users’ access to an organization’s assets and facilities. It is difficult to fund IAM projects because they consume resources without actually adding business functionality. IAM is a part of the organization’s plumbing; you take it for granted until you turn on the hot water and nothing happens.
Many organizations do not realize that their IAM is out of control until one of the following occurs:
- Security incident caused by an insider with excessive privileges
- Security incident caused by a former employee who still has access rights
- An external auditor or regulator discovers lapses in IAM processes resulting in too many people having access to too many roles and systems
This is a growth pain—a rite of passage—that practically every organization experiences. Only when the pain becomes great—when the organization experiences an incident or some lapse– is it willing to face the music and fix the problem. (This may not be that different from waking up in a bed-bug infested bed; at first the bites aren’t so bad, but eventually, you can’t deny the infestation.) By understanding the symptoms of a troubled identity management program, an organization can quickly identify and seek to remedy the issues before an identity-related incident can take its toll.
The IAM Problem Defined
There’s no mincing words: organizations in this situation are not in control of their access management policies. Typical scenarios that many enterprises face include ineffective onboarding, accumulation of privileges, failure to terminate user access, and departments that take on their own access management when they start using cloud and SaaS solutions.
Many organizations lack a detailed onboarding policy that specifies which job titles are permitted to have access to systems, roles and resources. As a consequence, access requests for new employees often sound like this: “New employee Rachel needs access to System A like Jody, System B like Phillip, and System C like Alexis. “ Requestors don’t really know what new employees need, but they’re pretty sure that if their access were similar to existing employees, then new employees would be able to get their jobs done. The problem with this approach is that existing employees might have far more access privileges than they actually need, often as a result of job “movers,” who accumulate privileges.
Employees who stay on for more than a couple of years often move from position to position as their skills grow and the organization’s needs change. The result is known as accumulation of privileges: seasoned employees have access to systems, roles and resources needed for their current job, as well as positions they have held in the past. But organizations that become aware of this problem are often unable to effectively deal with it. When employees transfer from one job to another; rarely do they make a clean break in which their old, job-specific roles can be removed. Usually, employees who have transferred to a new position still have responsibilities in their former position, perhaps until a new person is hired, a new hire (or another transfer) is trained, or they have completed some projects. Organizations often forget that those older privileges need to be removed.
When employees leave the organization, their access to all internal and external systems and facilities is revoked immediately. This is particularly critical when workers are being terminated, a circumstance in which the consequences of IT errors can be devastating. It is even more complicated in organizations that utilize systems and applications where each has its own isolated access management systems.
The proliferation of compelling Web-based applications and services has resulted in organizations whose departments have begun to use SaaS and other cloud-based services. Employees often manage access to these services within their own departments. The problem here is that the employees, who manage access to these unsupported services, are usually not aware of corporate IT’s access policies or processes. Moreover, users’ access to these services is not tied to centralized access services such as Microsoft Active Directory, IdentityMinder or SiteMinder. When employees transfer or leave the organization, their access to these unsupported systems will generally persist for months, or even years. Situations like this can go undetected for years until an incident occurs.
Establishing IAM Business Rules
As organizations grow and encounter IAM problems, IT and management generally reach a consensus that business rules must be established. Controls must be effective and reliable if organizations are to regain control of their access management programs. The following is a blueprint for IAM business processes:
- Corporate HR manages the who-works-here system of record. Human resources is the organization responsible for tracking the full-time and part-time employees in the organization. To be effective, HR must also manage the temporary workers including contractors, consultants, interns and temps. This must also include personnel in external service organizations who access the organization’s systems and resources. The information about personnel resides in the HR information system, or HRIS.
- Employee HR data must flow from the HRIS to a central directory service. As the official system of “who works here” record, key transactions from the HRIS flow to the organization’s centralized access directory, through a workflow system.
- A centralized directory service that can scale. Simplicity and scale are the drivers that compel many organizations to rely on a single authentication service, whether it’s a pure directory service such as Active Directory, LDAP, or a cloud-based service such as SafeNet. While the compromise of a user’s centralized credentials means an attacker can reach more applications and systems, consider the alternative: separate credentials for each application. This leads to users choosing poor passwords or writing them down. The overhead of having multiple access control systems to manage adds complexity and introduces more opportunities for errors.
- Automated provisioning to streamline user account setup. The process of setting up user accounts manually is time consuming and prone to error, and may even be subject to abuse. When properly controlled by workflow, additions and changes to user accounts can be automatically fulfilled.
- An IAM system that offers a built-in access matrix. Typically, too daunting to implement manually, an IAM system can have an access matrix that pairs a subject’s job title (and possibly other salient facts such as work location, business unit ID, and so on) to each role in a system. The intersection of job title and role can result in the following potential outcomes:
- Birthright—access is provisioned automatically
- Allowed—access is provisioned on request
- Reviewed—access is provisioned when designated approvers consent
- Exception—access is not provisioned unless executives approve
- Prohibited—access is not provisioned under any circumstances
- A workflow system to manage access requests. Rather than blindly allowing all access requests to be fulfilled automatically (even when they obey access matrix rules), many organizations may opt for one or more levels of review, and require approval of each access request. Depending on risk, sensitivity of data, or the “quality of fit” in the access request, a workflow system can require approval of resource owners, infosec staff, and others as needed.
- Define rules for segregation of duties, and implement them electronically. A centralized access management system will have visibility into all of the access rights that any given subject has. Any new request should examine the request access and compare it with all access rights currently held by the subject, to see whether any “toxic combinations” of access rights would result. (For example, if an employee in the accounting department has the dual roles of payment request and approval, which normally must be held by separate people).
- Detailed recordkeeping is a basic requirement. Every element about an access request, review, approval, and provisioning must be documented in a way that makes it easy to research requests and approvals to see who was involved.
- Reviews and audits need to continue even with IAM systems in place. It is still necessary to periodically review users’ access rights. The primary reason is to determine whether every person in a certain role still requires access to those roles. These periodic reviews should include the master access matrix, workflow and approval rules, and rules for segregation of duties. Another reason for periodic reviews is to verify that approvals were made properly. It’s also a good idea to make sure that the basic worker termination process is working by comparing HR records of existing workers.
Any organization operating a comprehensive controls framework such as COBIT needs to determine which of those controls will be implemented in the IAM system, and which ones will be external to it.
Operating Multiple IAM Environments
Disruptive growth via mergers and acquisitions may result in organizations having an IAM system for some of their applications and manual processes for others, or multiple IAM systems. To achieve better operational consistency and scale, most organizations will try to get back to having a single IAM platform for all of their principle systems and applications. Migrating authentication / authorization, or even just the workflow and provisioning, can be a tricky affair. However, many of today’s IAM tools include the means for acquiring access rights info straight out of target systems (some easier, some less so). Many IAM vendors include these features to make it easier for an organization to bootstrap its first IAM platform, but this also makes it easy to switch from one IAM system to another, or to combine a mixed environment into a single, monolithic system.
Selecting and Operating the System
If your organization intends to implement a centralized authentication and authorization system—SiteMinder, instead of an internal Active Directory, for example—then evaluating internal and cloud-based applications with centralized and cloud-based authentication/authorization systems is essential.
During IAM system evaluation, an on-site proof-of-concept may be useful, but generally the scope is limited, so you need to carefully select applications for IAM system testing. Most organizations that implement IAM systems will have applications that IT chooses not to pipe-in to automatic provisioning.
Organizations that undertake the initiative to acquire IAM systems need to understand how authentication, data flows, workflows and account provisioning will work in their own environments. It may be necessary to survey all in-scope systems to determine the viability of integrating authentication and account provisioning. Each system will have its own integration issues, which you should identify beforehand.
About the author:
Peter H. Gregory, CISA, CISSP, DRCE is an information security manager, computer security specialist, and writer. He is a 30-year IT veteran, having worn every hat and coat in the IT closet. Send comments on this column to firstname.lastname@example.org.