Best Practices for Identity Management Projects

Introduction

This document presents best practices for deploying and operating an identity
management infrastructure. It builds on Hitachi ID Systems's years of experience
in deploying password management and user provisioning into some of
the largest and most complex organizations in the world.

The document is organized as follows:

Overview: Defining Identity Management:

Some basic definitions that help clarify the subsequent
material.

Long Term Commitment:

Identity management is more accurately described as a change in the IT
organization and business processes than a finite project. Deployment
can reasonably be expected to continue indefinitely, with more
features and integrations are added over time.

Focus on Business Drivers:

Given the long-term investment in identity management, it makes
sense to identify and focus the highest priority business drivers
first.

Deliver Early and Often:

To minimize project risk and to ensure a positive return on
investment, it is essential to deliver tangible results early
in the project, and keep delivering new benefits regularly.

Usability and Adoption:

Identity management is focused on the user -- a human being
represented on multiple IT systems, by a combination of identity
attributes and privileges. It follows that user adoption is
a prerequisite to success.

Critical Path and Common Interdependencies:

Some integrations and features depend on others. This
section identifies major interdependencies, which impact
project timelines.

Project Management Methodology:

A typical methodology for delivering a given project milestone.

Typical Timeline and Deliverables:

Pulling all of the above together, a sample project timeline
is developed, step-by-step.

Overview: Defining Identity Management

Identity management and access governance is defined as a shared platform and consistent
processes for managing information about users: who they are, how they
are authenticated and what they can access.

Enterprise Identity and Access Management (IAM) is defined
as a set of processes and technologies to effectively
and consistently manage modest numbers of users and entitlements
across multiple systems. In this definition, there are typically
significantly fewer than a million users, but users typically have
access to multiple systems and applications.

Long Term Commitment

Identity management projects tend to be long, and indeed may never end, as
deliverables are continually added over the life of the system.
Organizations go through both business and infrastructure changes:
reorganizations, hardware upgrades, new operating systems, new applications,
etc. These changes trigger matching requirements in the identity management
infrastructure and consequently lead to implementation and maintenance effort
over the life of the system.

This is not to imply that individual deliverables cannot be implemented
quickly and operated at low cost. Rather, it means that successful
implementation of one feature or integration usually triggers interest by a
wider range of stake-holders, who request further work, to deliver more
features and integrate with more infrastructure.

With this in mind, it can be helpful to think of identity management
implementation in terms of a process of continuous optimization, which is the
responsibility of a permanent team, rather than a single, finite project.

As with any long term project, it is important to have clear buy-in from
stake-holders and an up-front agreement on project scope, deliverables,
duration and cost in order to sustain investment and deliver on business
expectations. Without such early commitment by stake-holders, project work
may be aborted before deliverables are reached.

Identity management automation can impact a wide range of stake-holders,
so it is important to understand who they are and engage them early.
This reduces the risk that an important decision maker learns about
the project later and disrupts it because he or she was not consulted
earlier.

Stake-holders who may be interested in an identity management project
include:

Stake-holder

Impact

The IdM Infrastructure owner(s)

Someone must be responsible for acquiring, deploying and
maintaining infrastructure such as directories, user provisioning
automation, password management, single sign-on, etc.

End user support

Impacts range from reduced password reset call volume to a need
for user education, support and training for new processes.

System administrators

Identity data will be modified on their systems.
They will be asked to hand out administrator-level credentials,
and may be asked to install software on their systems.

IT Security

IT security will have to set policies for the new automation.

Audit

The new automation will enforce rules regarding internal controls
and also enable audits of user privileges and change history.

Need to know about where servers will be racked, what bandwidth
will be consumed, etc.

Human Resources

May be asked to provide a data feed from systems of record.
May receive updates asking them to correct errors in their system.
Are likely the first point of contact for new hires and the last
point of contact for terminated users.

Best Practice

Engage all stake-holders from the project's inception, rather than deferring conversations with some of them until later in the project.

Since there may be a large number of stake-holders, they are likely to
disagree on many issues. To resolve such disagreements and keep
the project moving smoothly, it is important to have strong
sponsorship that can motivate this diverse group of stake-holders to
cooperate, even when decisions are made that contradict their
opinions.

It is important to garner business ownership of the solution. A good sponsorship and governance approach will facilitate this, and help to insure that the project is seen favorably by the non-IT side of the organization.

-- Kevin KampmanSenior AnalystThe Burton Group

Technology used to automate identity management can be quite complex
and vendor services to implement and maintain it can be expensive.
It therefore makes sense to assign a full-time, technical resource
to assist in system deployment and to take responsibility for ongoing
technical work, including adding new integrations, adjusting business logic,
customizing the user interface, performing upgrades and troubleshooting
problems. This reduces project cost, shortens timelines and improves SLA.

Best Practice

Employ a full-time, technical resource from the start of implementation. This resource will assist in deployment and to manage the system in production.

The technical resource tasked with implementation and maintenance of the
identity management infrastructure should have expertise with operating
systems, directories, HTML markup and at least one scripting or programming
language (e.g., Perl, JavaScript, C++, C#, Java, etc.).

Inevitably, this technical resource will have somewhat different
priorities than security officers and architects, such as a strong
interest in ease of maintenance and deployment effort. It makes sense
for the business owner of the identity management infrastructure to be
a part of any product selection and evaluation process, rather than
dropping a pre-determined choice of product and architecture on a
technical resource and hoping that he or she can subsequently resolve
any issues that may come up.

Best Practice

Engage a technical resource who will become the permanent system administrator of the identity management infrastructure in product selection.

Focus on Business Drivers

There are several business drivers for deploying an enterprise
identity management and access governance system, including:

Since it can take a long time to deliver on each and every one
of these drivers, it is important to prioritize. As much as possible,
high priority deliverables should be completed before work begins on
lower priority ones.

For example, if reducing help desk call volume is a primary motivation,
then password synchronization and self-service password reset should
come first. If security risks associated with orphan and dormant
accounts are important, then automated access termination and
access certification should come first. If rapid onboarding of new
employees is important, than automated provisioning of new users
or self-service onboarding requests should be implemented first.

Best Practice

Prioritize business drivers at the start of the project and focus on only the most urgent deliverables.

Along with prioritization of work by business drivers, it is important
to be able to measure success. This is done by establishing metrics
for measuring success in delivering on any given business driver
and by measuring these metrics both before and after deployment.

When communicating the benefits of the solution, it is critical to focus on business value. The emphasis may seem subtle and unimportant, but making users more productive faster, improving the user experience, providing more efficient access, and so on have more meaning to your executives than better security and a lower cost of administration.

-- Kevin KampmanSenior AnalystThe Burton Group

Best Practice

Establish metrics to support each business driver and measure results both before and after deployment.

Some sample metrics include:

Driver

Metric

Measured as

C

HD password reset call volume

Password reset help desk calls per month (average and peak).

C

HD FTEs

Number of FTEs required to support peak password reset call volumes.

C

AD group admin workload

Group membership changes that hit the human service desk, monthly.

C

Admin FTEs

Number of FTEs required to support management of AD group membership.

P

Employee setup authorization

Days from HR trigger to setup a new employee.

P

Contractor setup authorization

Days from manager call to setup a new contractor.

C+P

Setup time

Number of IT work hours required to setup a new user.

S

Deactivation time

Days from HR/manager trigger to deactivate a departed user.

C+S

Deactivation effort

Number of IT work hours required to terminate access for a departed user.

S

Termination delay

On average, days from actual termination to when HR notifies IT.

S

Weak passwords

Number of systems that do not enforce length, character set,
history and dictionary rules.

S

Standard caller authentication

Number of standardized questions asked to authenticate HD callers.

S

Personalized caller authentication

Number of user-defined questions asked to authenticate HD callers.

S

Standard caller auth (2)

Number of available standardized questions from which authentication
process draws random questions.

S

Personalized caller auth (2)

Number of available user-defined questions from which authentication
process draws random questions.

S

Non-expiring systems

Number of systems that currently do not enforce a password expiry policy.

S

User password age

Enforceable maximum age of user passwords.

S

Admin password age

Enforceable maximum age of administrator passwords.

C+S

Orphan accounts

Per enterprise-wide system: number of user objects
divided by the number of employees and contractors.

C+S

Dormant accounts

Per system: number of accounts inactive for at least N days.

C+S

Unassociated systems

Number of systems whose unique user identifiers are not mapped to
a corporate-wide identifier.

S

Admin password change interval

Per system: frequency of change of admin passwords (days).

S

Password replication scope

Per system: number of other systems that share credentials with this one.

S

Password sharing scope

Per system: number of IT users that know the admin credentials at any
given time.

C+P

New user request complexity

Number of different forms used to request new login IDs, on different
systems, or for different locations, or for different classes of users.

C+P

New access request complexity

Number of different forms used to request new security rights for an
existing user.

C+P

Identity change request complexity

Number of different forms used to request changes to user identity
data (name, phone, address, department, location, etc.).

C+P

Passwords per user

Average number of passwords a user must remember for corporation-owned
systems.

C+P

Login prompts per user per day

Average number of times per day that a user must sign into some
corporate system.

In the table above, a "C" in the business driver column means
cost reduction, "P" means user productivity and "S" means security.

Your metrics should also be expressed in terms that are meaningful to the organization. Removing hours and days from the on- or off-boarding cycle is a more compelling success story than consolidating Active Directory groups. Always speak to the business issue that is specific and relevant, even when there is a tremendous amount of technical effort that makes it happen.

-- Kevin KampmanSenior AnalystThe Burton Group

Deliver Early and Often

The time required to implement a featureful and well integrated identity
management system can span into years. Over such a long span of time,
stake-holders may lose interest and withdraw support and/or funding.

Also, requirements change over time, as both business processes and
infrastructure evolve. This means that a lengthy project to implement
a fixed set of deliverables is likely to fail, simply because by when
the work is complete, the original requirements will have changed.

To avoid both of these problems, it is imperative to deliver results
in the implementation project early and to deliver new results regularly.

Best Practice

Deliver functionality that is relevant to the business every 3--6 months.

Since both requirements and priorities will change over time, it
makes sense to kick off a long-term identity management project with
only a rough outline of project milestones. The sequence of priorities,
and which task to undertake next, should be re-evaluated after every
one or two milestones.

Best Practice

Start long identity management projects with a rough outline of business priorities and milestones.

Best Practice

Re-evaluate priorities after every one or two milestones.

To address the fact that both business processes and technical
infrastructure change constantly, it makes sense to capture detailed
requirements and construct a solution design for any given function
only when the implementation team is ready to start work on that
function.

Deferring detailed design until just before a given work phase can commence
eliminates situations where a feature is designed, in great detail and at
great cost, long before implementation can commence. Such early planning is
actually very risky, since requirements are likely to change in the
interval between solution design and implementation, which leads to one of
two undesirable outcomes: redoing the detailed (but premature) discovery and
solution design or implementing a system to meet outdated specifications.

Best Practice

Defer detailed discovery and solution design for each phase until the team is ready to start implementing that phase.

Finally, it makes sense to build up expertise in the implementation
team. Start with small, simple functions and work up to more complex
deliverables in later phases. This reduces overall project risk
and ensures early return on investment.

Best Practice

Start with small, simple deliverables. Work up to more complex functions and integrations.

Usability and Adoption

The function of an identity management system is to manage data about users:
their identity attributes, authentication factors and security privileges.
As might be expected, most identity management systems, sooner or later,
interact with these users. Such interaction is required to manage passwords,
confirm and update identity attributes, request and approve privilege
changes, audit user data, etc.

In many scenarios, the business value of the identity management system
depends on user adoption. For example, a self-service password reset system
only generates user support cost savings if users choose to use it, rather
than calling the help desk. Similarly, a user provisioning system can
only reduce security administrator workload if users make security
change requests through its workflow user interface, and not by
calling a security administrator.

To ensure user adoption, the identity management deployment team must
incorporate activities designed to engage the user community in the
deployment plan:

In addition to engaging users to validate usability, ensure awareness and
verify that users understand how to use the system, it is helpful to organize
a program to drive high user adoption. This includes usability testing
and awareness programs and adds incentives for users to adopt the system and
disincentives to users who do not. Example incentives include synchronized
passwords, reduced signon and offline items such as prize draws, gift
certificates, etc. Example dis-incentives include reduced help desk service
for human (as opposed to automated) service, charge-backs, etc.

Best Practice

Organize a formal program to drive high user adoption for every user-facing component of the identity management system.

An important concept to consider when designing a usable system is that of
"one stop shop." In short, this means that when a user wishes to perform a
function -- for example, to request that a new login ID be provisioned -- the
user should not have to first consider which request input system to visit,
based on which one happens to be in-scope for the identity management
infrastructure, as opposed to managed by a legacy business process.

Since it is impractical to deploy hundreds of integrations at a time
and since some infrastructure may not be cost effective to manage with
automation (example: an application with 20 users does not merit 5 days
of integration effort), partial or "manual" integrations are desirable.
It makes sense to provide users with a single change request user
interface, to automate whatever actions possible, and to forward the
remaining types of changes to human system administrators.

Best Practice

Provide a consolidated change request user interface and identify "implementers" to fulfill change types for which automation is not available.

Another side effect of engaging users is that they must be informed
whenever the system changes. If a system changes often, this creates
a flurry of e-mails in user in-boxes, which users learn to ignore.
Too-frequent user notifications can act to defeat a user adoption
program.

The need to keep users informed means that integrations with target systems
should be grouped, so that users can be informed of new integrations less
often, in a more meaningful way. For example, a quarterly e-mail about five
more systems that have been brought into scope is more helpful than a weekly
e-mail about another directory OU.

Best Practice

To reduce user impact, implement multiple integrations at a time, rather than defining a project milestone around every target system.

The benefits of minimizing user announcements also acts as a counter-weight
to the strategy of multiple, short deliverables. While it makes sense
to define milestones every 3 to 6 months, it does not make sense to
subdivide a project into weekly or monthly deliverables.

Critical Path and Common Interdependencies

When deploying an identity management system, some tasks cannot be started
until others are completed. Such interdependencies may delay high
priority deliverables until items which appear to be less important,
but which are pre-requisite, are completed.

Following are some common implementation tasks that must be performed
early in a project, to support later deliverables:

Integrate with a source of profile IDs:

Every user must have a unique, global identifier. These
identifiers are normally drawn from one or more existing
systems, and these existing systems are referred to as
sources of profile IDs. Integration with sources of profile
IDs, such as Active Directory, e-mail systems or HR data
feeds, generally precede all other integrations.

Reconcile login IDs:

Users normally have records and login accounts on multiple systems
and one of the core functions of an identity management system is
to consolidate management of these user objects. It is impossible
to manage multiple user objects coherently until they are connected
to one another -- in other words, until login IDs on different systems
are reconciled with one another and attached to global profile IDs.

An identity management system may, from time to time, have to contact
users -- either to notify them of an event or to request
some action. Examples of this are asking users to complete a personal
challenge/response profile, notifying users of failed login attempts
relating to their profile, asking authorizers to approve security
change requests, etc.

Communication initiated by the identity management
system is usually implemented using e-mail. One of the first
integrations in a typical deployment is therefore with the e-mail
system, to deliver messages to users.

Construct an org-chart:

Several functions in an identity management system typically depend on
data mapping every user to their direct manager/supervisor:

Escalation: when a given change authorizer repeatedly fails to respond
to a given change request, the simplest choice of an alternate,
escalation authorizer is the first authorizer's direct manager.

Certification: managers are often asked to periodically review
a list of their direct subordinates and their security rights,
in order to identify and remove inappropriate access rights.

Delivering a process to construct and maintain reliable org-chart
data, that covers all users is often an early deliverable
in an identity management project.

Authorization workflow:

Many changes initiated by or passed through an identity management system
require authorization before they can be applied to target systems. This
includes creating new user objects, deactivating existing users, modifying
user membership in security groups and updating identity attributes.

The authentication process itself is often the same regardless of the
change type -- all that varies is the identity of the users asked
to approve or reject a change.

Carry out an impact analysis to gauge results on cost, security
and user service.

Post Deployment:

Monitor and report on system usage and user adoption.

Report on post-deployment metrics to project sponsors.

Periodically produce an impact report illustrating the
change in metrics created by the system and estimating
the business impact of this change.

Typical Timeline and Deliverables

A typical identity management implementation may proceed as follows.
This schedule is intended to illustrate what is possible, rather than
to suggest that this exact sequence is appropriate to a particular
organization.