For compliance professionals in regulated industries, there’s perhaps no greater challenge than identity management. Call it a program, a best practice, or simply a daily struggle to account for all users and all the systems to which they have access—identity management is a beast that is tough to tame. It can be 99 percent effective, but that nagging, non-compliant one percent can leave a reputational dent if discovered by an audit, or worse, provide the gateway for an insider to wreak havoc, either accidentally or intentionally. There are many applications on the market that make tantalizing claims about solving the identity problems once and for all, but companies should adopt these tools with their eyes open and their expectations in check.

While accounting for a handful of people on a limited number of systems is not terribly daunting, the challenge grows exponentially when the user base is rapidly changing, widely distributed, and drawn from multiple onboarding sources. Combine this user population with a large number of privileged systems, disparate naming conventions and limited capacity for automation, and true identity management seems downright unachievable, no matter how convincing the sales rep.

Companies looking to overcome this challenge should consider the following bits of advice when preparing to launch a new identity management system. Addressing these elements ahead of time can speed the transition and reduce the massive friction that results from implementing a program of such reach and importance.

Identity management is simple in principle but massively difficult in practice. When asking the “what could go wrong” question, the answer is, “nearly everything.” This is why the sponsor of the identity management tool should not tread lightly into its implementation. It should be well advertised, well documented, well tested, and well coordinated upon implementation.

1.    Demand good data … period. Managing data in any new tool deployment is tedious, but bad personnel data is especially toxic in an identity management system. Data inconsistencies, redundancies, and error loops can mean hundreds of manual reconciliation hours performed under fire. Any potential for a single person known as “Thomas Adam,” “Tom Adam,” and “T.R. Adam” to bog the identity administrator down must be considered and accounted for in advance. This person must be assigned a unique user ID with a standard naming convention. Or, conversely, three separate people named Tom Adam must have similarly unique identifiers that leave no question as to who they are (at the same time, do not forget Adam Thomas).

2.    Know which personnel fields to populate. Creating unique users on the network is but one step in leveraging a successful identity management application. The system should be able to render context and to enable collateral management decisions downstream based on the depth of the data. For example, just knowing who Tom Adam is may be short-sighted. Is he a remote worker? Does he reside overseas? Can he be reached in an emergency? Identity managers must look at the big picture and ask stakeholders to consider the extent of the fields that should be included in order to maximize the capabilities of the system and enable smart resource provisioning. Nulling out some fields may be necessary, but some may be worth populating as they help inform user access as systems evolve or regulations change.

3.    Consider grandfathered users. The adage about building the airplane in flight is a perfect simile for identity management. How will the new system pull in existing users without imposing operational disruption? How can a graceful cutover of the new system occur? How will profiles be populated without interruption to the organization? Depending upon the level of automation and the API capabilities of privileged systems, this may be a painstaking process that requires months of transition.

4.    Designate an accountable owner (or two) for each resource. A strong identity management system must tie the right users to the right access levels within the right resources. “Windows Administrators” may be a well understood privileged user group, and easy enough to implement at the inner core of the proverbial onion, but this onion has layers. Applications may require multiple access levels, and those in charge of each layer (and their alternates) must take a leadership position in granting and sometimes challenging access requests. For many organizations, this may come as a culture change as people are suddenly held accountable for “their” application. These newly deputized resource owners may be slow to rise to such a call, arguing that they should not be the gatekeepers for gates they never knew they controlled.

5.    Ensure managers understand their importance. In addition to the resource owners, identity management relies on an active and well-trained management structure. These are the spark plugs of the identity management engine, and must not only be prudent in approving access requests on their employees, but must also be mindful of their responsibilities when it comes to transfers and terminations. Few identity management systems, no matter how automated, will intuitively know if Tom Adam wins the lottery and walks out the door. At some point, identity management depends upon a human broker, and managers are the essential cogs in this human process.

6.    Finally, set up a manual backstop. Once identities are set, application owners assigned and managers trained, the tool must be supplemented by manual user reviews until metrics demonstrate that process deviations are minimal. This could mean a quarterly “stare and compare” exercise against the known user base and the privileged resources assigned. The manual review should check for gaps between what the system sees and who is actually on the network. It should review asymmetric processes such as manual ticketing to see if users are being added and removed as directed and that no privileged system is neglected.

Wrapping it up

Identity management is simple in principle but massively difficult in practice. When asking the “what could go wrong” question, the answer is, “nearly everything.” This is why the sponsor of the identity management tool should not tread lightly into its implementation. It should be well advertised, well documented, well tested, and well coordinated upon implementation.

Topics