Identity Correlation - Basic Requirements of Identity Correlation

Basic Requirements of Identity Correlation

Identity Correlation involves several factors:

1. Linking Disparate Account IDs Across Multiple Systems or Applications

Many organizations must find a method to comply with audits that require it to link disparate application user identities with the actual people who are associated with those user identities.

Some individuals may have a fairly common first and/or last name, which makes it difficult to link the right individual to the appropriate account login ID, especially when those account login IDs are not linked to enough specific identity data to remain unique.

A typical construct of the login ID, for example, can be the 1st character of givenname + next 7 of sn, with incremental uniqueness. This would produce login IDs like jsmith12, jsmith 13, jsmith14, etc. for users John Smith, James Smith and Jack Smith, respectively.

Conversely, one individual might undergo a name change either formally or informally, which can cause new account login IDs that the individual appropriates to appear drastically different in nomenclature to the account login IDs that individual acquired prior to any change.

For example, a woman could get married and decide to use her new surname professionally. If her name was originally Mary Jones but she is now Mary Smith, she could call HR and ask them to update her contact information and email address with her new surname. This request would update her Microsoft Exchange login ID to mary.smith to reflect that surname change, but it might not actually update her information or login credentials in any other system she has access to. In this example, she could still be mjones in Active Directory and mj5678 in RACF.

Identity correlation should link the appropriate system account login IDs to individuals who might be indistinguishable, as well as to those individuals who might appear to be drastically different from a system-by-system standpoint, but should be associated with the same individual.

For more details on this topic, please see: The Second Wave: Linking Identities to Contexts

2. Discovering Intentional and Unintentional Inconsistencies in Identity Data

Inconsistencies in identity data typically develop over time in organizations as applications are added, removed or changed and as individuals attain or retain an ever-changing stream of access rights as they matriculate into and out of the organization.

Application user login IDs do not always have a consistent syntax across different applications or systems and many user login IDs are not specific enough to directly correlate it back to one particular individual within an organization.

User data inconsistencies can also occur due to simple manual input errors, non-standard nomenclature, or name changes that might not be identically updated across all systems.

The identity correlation process should take these inconsistencies into account to link up identity data that might seem to be unrelated upon initial investigation.

3. Identifying Orphan or Defunct Account Login IDs

Organizations can expand and consolidate from mergers and acquisitions, which increases the complexity of business processes, policies and procedures as a result.

As an outcome of these events, users are subject to moving to different parts of the organization, attaining a new position within the organization, or matriculating out of the organization altogether. At the same time, each new application that is added has the potential to produce a new completely unique user ID.

Some identities may become redundant, others may be in violation of application-specific or more widespread departmental policies, others could be related to non-human or system account IDs, and still others may simply no longer be applicable for a particular user environment.

Projects that span different parts of the organization or focus on more than one application become difficult to implement because user identities are often not properly organized or recognized as being defunct due to changes in the business process.

An identity correlation process must identify all orphan or defunct account identities that no longer belong from such drastic shifts in an organization’s infrastructure.

4. Validating Individuals to their Appropriate Account IDs

Under such regulations as Sarbanes-Oxley and Gramm-Leach-Bliley Act, it is required for organizations to ensure the integrity of each user across all systems and account for all access a user has to various back-end systems and applications in an organization.

If implemented correctly, identity correlation will expose compliance issues. Auditors frequently ask organizations to account for who has access to what resources. For companies that have not already fully implemented an enterprise identity management solution, identity correlation and validation is required to adequately attest to the true state of an organization’s user base.

This validation process typically requires interaction with individuals within an organization who are familiar with the organization’s user base from an enterprise-wide perspective, as well as those individuals who are responsible and knowledgeable of each individual system and/or application-specific user base.

In addition, much of the validation process might ultimately involve direct communication with the individual in question to confirm particular identity data that is associated with that specific individual.

5. Assigning a unique primary or common key for every system or application Account ID that is attached to each individual

In response to various compliance pressures, organizations have an option to introduce unique identifiers for its entire user base to validate that each user belongs in each specific system or application in which he/she has login capabilities.

In order to effectuate such a policy, various individuals familiar with the organization’s entire user base, as well as each system-specific user-base, must be responsible for validating that certain identities should be linked together and other identities should be disassociated from each other.

Once the validation process is complete, a unique identifier can be assigned to that individual and his or her associated system-specific account login IDs.