Selecting a Password Management Product

Selecting a Password Management Product

© 2014 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com/

http://Hitachi.com/

This document is intended to help organizations set out criteria which can be used to select a passwordmanagement product.

The selection process begins with a business case for a password management system. The businesscase is used to develop functional and technical requirements, which in turn drive the product and vendorselection process.

Contents

1 Introduction 1

2 Business Case for Password Management 2

2.1 Support Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Simplified Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Improving Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.4 User Convenience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Functional Requirements 4

3.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Self-Service Password Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6


3.3 Assisted Password Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8


3.4 Target Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


4 Technology Considerations 10

4.1 Scalability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10


4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

i


4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11


5 Deployment and Ongoing Administration 13

5.1 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


6 Vendor Viability and Commitment 16

6.1 Breadth of vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2 Viable business and stable products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.3 Services Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7 Conclusions 18

© 2014 Hitachi ID Systems, Inc. All rights reserved.



1 Introduction

This document is intended to help organizations set out criteria which can be used to select a passwordmanagement product.

The selection process begins with a business case for a password management system. The businesscase is used to develop functional and technical requirements, which in turn drive the product and vendorselection process.

The remainder of this document is organized as follows:

• Business case for password management

Every password management project must begin with a business justification. This is the backgroundfor all subsequent requirements.

• Functional requirements

Basic functions that every password management system should meet.

• Technology considerations

Technical architecture considerations and how they impact a password management system’s usabil-ity.

• Deployment and management

Design considerations that impact the initial deployment and ongoing administration of a passwordmanagement system.

• Vendor quality

The qualities of a successful password management vendor.

• Conclusions

A summary and a reminder to “try before you buy.”

© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1


2 Business Case for Password Management

A password management system should not be deployed based solely on a vendor’s recommendation.Rather, it should address real and measurable business problems and should yield a measurable return oninvestment (ROI).

Following are the most common reasons for deploying a password management system:

2.1 Support Costs

According to IT analyst firms such as Gartner, Forrester and Burton, 20% to 30% of total call volume at theIT help desk in a typical medium to large organization is due to login problems, which are most commonlycaused by forgotten passwords or users who triggered an intruder lockout mechanism.

Collectively, these problems are costly to resolve. They also represent a significant user productivity cost– for every hour spent by the help desk resetting passwords for callers, end users spend two hours copingwith login problems.

A password management system should address this cost, by reducing both problem frequency and thecost to resolve password problems.

2.2 Simplified Administration

Many organizations have multiple user directories. For example, a large company may deploy an ActiveDirectory environment for network login and e-mail a Sun ONE directory for Unix-hosted Intranet authenti-cation and a variety of additional user ID/password databases embedded in other systems and applications.

Provisioning and managing passwords in multiple systems is difficult and a password management systemcan streamline this process.

2.3 Improving Security

Most users prefer to use simple passwords. They prefer to keep the same password for a long time. If theymust have many different passwords, they tend to write them down, because they are too hard to remember.

IT security, on the other hand, prefers that users have complex passwords, change their passwords oftenand never write down or share their passwords. These are often centrally dictated policies.

A password management system can be used to enforce some of these security rules, including rulesthat existing systems cannot enforce. It can also make rules easier for users to follow – e.g., one strongpassword that users can remember rather than ten strong passwords that the user writes down.



2.4 User Convenience

Most users have to authenticate to multiple systems, each of which maintains its own password, its ownpassword policy rules and its own expiration schedule.

When users manage each password separately, they tend to accumulate multiple, different passwordswhich expire on different dates.

A password management system should simplify this: allowing users to manage just one or two passwordsacross all systems, changing all passwords on a single schedule and subjecting all passwords to a single,combined set of rules. This improves the user experience and reduces the frequency of users forgetting orwriting down their passwords.



3 Functional Requirements

The business requirements set out in Section 2 on Page 2 can be mapped to specific functional require-ments:

3.1 Synchronization

Most user login and password problems are due to users forgetting their passwords or typing one system’spassword into another system’s login prompt.

The fundamental solution to this problem is to simplify password management for users and the easiestway to do that is to synchronize passwords.

Most systems store passwords as hashes. Hashes are different from encryption in that they are not re-versible – you can compute the hash of a string, but you cannot get the string back from its hash.

Plaintext passwords are used to calculate hashed passwords. When this is done at different times: whenthe password is set and again when the password is validated, hashing is used to check that the passworda user typed at login time is the same one he typed when he previously chose his password.

The reverse operation – calculating a plaintext password from the hash – is mathematically (almost) impos-sible. Since different systems use different hashing methods, it is also impossible to copy password hashvalues from one system to another.

Use of different hashing algorithms means that password synchronization must happen when users entera new password value – since at that time (and only at that time) the new password is available in plaintextand different password hashes – one for each system where the user has a password – can be calculatedfrom a single plaintext value.

3.1.1 Requirements

A password synchronization must meet the following requirements:

• Provide a way for users to select a new password for all of their login accounts.

• Be easy to use, to support user adoption.

Simplicity and high user adoption be achieved by either extending an existing password change pro-cess or creating a friendly new method for changing passwords:

– Extending an existing password change process to trigger synchronization: For example, whenusers change their Active Directory password, the new password can be automatically forwardedto their other login accounts. (this is called transparent password synchronization)

– Provide a new password change process: Most users are comfortable with web browser, soa web form can be introduced that lets users step through the following process: (web-basedpassword synchronization)

* User types his login ID.



* User types his current login password.

* User types a new, desired password (twice).

* The password synchronization sets the user’s password on multiple systems to the samenew value.

3.1.2 Pitfalls to Avoid

While the above processes are simple, a poor implementation can result in low user adoption or total systemfailure:

• User profiles:

Any password management system must either contain or have access to a database of user profiles.It must, at a minimum, know what user ID each user types to log into each managed system.

If user IDs are consistent (any given user has just one ID, which works on every system), then buildingthis user profile database is simple.

If user IDs are different, as may be the case with legacy systems or after corporate mergers andacquisitions, this data is hard to come by and may require a massive data load at the project outset.

Once user ID profiles are initially loaded into the system, they must be maintained, because users areadded to and removed from every system in the course of normal system management.

A mature password management system must include automation to build, maintain and correlateuser IDs. Failure to include this automation translates into a massive deployment project followed bycostly ongoing administration.

• Web-based password synchronization:

– The process must be extremely simple.

– Users must be automatically prompted to use the synchronization system. Users do not volunteerto change their own passwords.

– Users should be authenticated using a current password:

* The system must not introduce a new password, as that increases complexity.

* The system must not ask users to answer a series of personal questions to authenticate, asthis is awkward and many users may perceive it to be an invasion of privacy.

• Transparent password synchronization:

– The system should be extremely reliable, since users do not interact with it directly. This means:

* Multiple load-balancing servers in a high-availability configuration.

* Automatic retry of failed synchronization.

* User notification of both successful completion and errors.

• Password policy:

A uniform password policy should be developed, to simplify the rule set that users must understand.

• Education:

Users must be educated about how to use the system and how it impacts them.



3.2 Self-Service Password Reset

Password synchronization should reduce password problem frequency, but users will still experience somepassword problems. To address these remaining problems, users should be offered a self-service system,so that they can resolve their own problems without calling the help desk.

3.2.1 Requirements

A self-service password reset system should be:

• Accessible when needed

Users should be able to access the system and should know that it’s available, wherever they mayrequire a password reset. This includes from their workstation login prompt, from a web browserinside and in some cases outside the corporate network and using a telephone.

• Easy to use

The user interface, whether integrated into a login page, embedded in a web browser or accessedusing a telephone, should be easy to use and require no training.

• Secure

When a user forgets his password, some other form of authentication is needed before the usercan be issued a new password. This alternate authentication must be as secure as possible, sinceit effectively substitutes for the user’s password. A password management system should supportauthentication factors such as hardware tokens, biometrics, multiple sets of both pre-defined anduser-defined personal questions, etc.

Other essential security features include encrypted transmission and storage of personal or authen-ticating data, detailed audit logs, intruder lockout if the user fails authentication multiple times andsecurity incident alarms.

• Integrated

Most organizations track IT support incidents in a help desk application. A mature password man-agement system should automatically create incident for both successful password resets and foranomalous events (errors, failed authentications, configuration problems, etc.).

• Flexible

Medium to large organizations often need to adapt off-the-shelf software to meet their unique needs.A successful password management system should cope with unique requirements, such as:

– User interface customization and language translation.

– Supporting various authentication technologies.

– Enforcing various password policy requirements.

– Integrating with incident management systems and implementing appropriate logic regardinghow and when incidents are created, updated and closed.




Self-service password reset is a simple concept, but implementation can be challenging:

• Is it really accessible?

The system should be readily accessible from login prompts and by users both inside and outsidethe corporate network. The system should work across firewalls. It should be able to reset VPNpasswords.

• Is client software required?

Any solution requiring client software to be deployed will impact desktop support. If the softwareis technologically invasive, it may impact the core operating system of user PCs. Deployment andsupport cost for client software can in some cases outweigh the benefit of self-service passwordreset.

• Where does the authentication data come from?

Primarily to reduce cost, most organizations choose a question-and-answer model for authenticatingusers who forget their passwords. This data must come from somewhere: the HR system, a corporatedirectory or self-service registration by users.

If the data already exists, it must be keyed to network login IDs. Mapping this data to login IDs can betime consuming and expensive.

If the data does not exist, then an application is required to ask users to fill in their own profiles, toauthenticate them when they do so and to remind users if they don’t respond to the first invitation.

Authenticating users to register Q&A data using a current password is secure and manageable. Au-thenticating users with PINs or other data distributed by post or e-mail is insecure and difficult tomanage.

• Imprecise matching of authentication data

Users who have registered personal data, such as ancestor surnames, place names, etc., are liableto type this data differently on different occasions. For example, is a user’s mother’s maiden nameSmith, smith or Smythe? The user may have enrolled one of these and later try to authenticatewith another.

A password reset system should tolerate some variations in user input, to ensure a successful userexperience.

• Is there a plan to drive user adoption?

Most users do not automatically use a self-service tool just because it is there. They must be educatedabout it, prompted to use it, rewarded if they use it and in some cases should receive a lower standardof service if they don’t. This requires planning and technical capabilities to monitor and react to usage.

3.3 Assisted Password Reset

Inevitably, users will forget their password (despite synchronization) and call the help desk (despite theavailability of self-service).

A password management system should streamline the resolution of these calls.



3.3.1 Requirements

A password management system should be able to handle every detail of a password problem call, includ-ing:

• Authenticate the help desk support staff.

• Identify the caller.

• Authenticate the caller.

• Get a list of the caller’s login IDs.

• Reset one or more passwords.

• Clear intruder lockout flags.

• Report on results.

• Create (and in most cases close) an incident in the help desk system.

• Report on the activity to the user (normally e-mail).


• Help desk support staff authentication

Help desk support staff have powerful access to a password management system, with the ability toreset any user’s passwords. They should have to authenticate using a strong mechanism, such as astrong password or a hardware token.

Using a personal Q&A profile or a weak or static password is not acceptable for help desk users, evenin cases where it is acceptable for end-users.

Allowing help desk support staff to share accounts is similarly not acceptable.

• Caller authentication

A help desk typically authenticates callers by asking them to respond to a sequence of personalquestions and comparing what they say to data on a user profile system.

Some personal user information may be considered private. Depending on local legislation and cor-porate policy rules, personal data used for authentication may have to be used in one of two ways:

– Different sets of personal data may be used for self-service authentication and for assisted ser-vice.

– Help desk support staff may not be allowed to see personal user data, but must instead type itinto an authentication form.

• Imprecise matching of authentication data

It is important for help desk support staff to be able to mis-type answers to personal user questionsand still get a successful match. This is because users tell the help desk support staff what to typeover a telephone and this transcription is very error-prone.



• Incident management system integrationAn assisted-service password reset system must be able to automatically create incidents in a helpdesk system, as described above.

This integration must be extremely flexible, because the quantity, type and contents of incidents cre-ated and e-mails sent will vary based on circumstances and corporate rules.

Consider an example:

– When a password is reset successfully, a closed incident should be written to the incident man-agement system and an e-mail sent to the user.

– When a password reset attempt fails with an error (for example, managed system unavailable),an open incident should be written to the incident management system about the service event,an e-mail detailing what worked and what didn’t should be sent to the user and a second openincident should be written to the incident management system, assigned to an individual systemadministrator, asking for service.

This degree of flexibility ensures that help desk support staff do not have to manually create incidentsto match the work they already completed in the password management system.

3.4 Target Systems

A password management system is only valuable if it supports the systems where users actually havepasswords. A rich set of included connectors and simple integration with supported types of systems isdesirable.

3.4.1 Requirements

• Broad platform supportThe password management system should support password management on systems that representat least 90% of the password support calls that reach its IT help desk.

• Extensible integrationIntegration with new, custom or vertical market applications should be easy.

• Low/no cost for increased coverageIt should be relatively painless to add integrations to new systems.


• Some vendors only offer a handful of built-in platform connectors / agents.

• Some products require invasive agents to be installed locally on integrated systems and applications(i.e., change control).

• Integration with new target types or applications may require extensive and costly programming.

• Some vendors charge significant amounts of money for additional connectors / agents.



4 Technology Considerations

4.1 Scalability and Availability

A password management system must scale to handle the peak transaction volume generated in an orga-nization. Once established, it normally becomes a core IT infrastructure service and must remain highlyavailable.

4.1.1 Requirements

• Peak transaction ratesSelf-service and help desk password reset features support users who forget their passwords. Thishappens about 2-3 times per user per year and normally on Monday mornings.Password synchronization is triggered by password changes and impact every user every 2-3 months.Again, password changes and synchronization happen in the morning.In practice, a password management system may have to support a peak rate of 3,000 passwordchanges/hour for every 10,000 users. This load is often best served using multiple, load balancedservers.

• Multiple serversFor both the scalability reasons mentioned above and to meet the requirement for high availability,most organizations should deploy at least two password management servers.Servers should include data replication, so that updates to one (e.g., new data in a user profile) shouldbe automatically replicated to the other.Servers should be load-balancing – which means that users should be automatically directed to oneof multiple active servers.Servers should be monitored and failures should trigger automatic removal of a server from loadbalancing circulation.


Implementing a scalable, high-availability transactional system is difficult and many vendors make mistakes.Following are some common problems:

• Multiple servers, single databaseHaving multiple password management servers that use a single back-end database does not improveavailability – it just moves the single point of failure to another part of the architecture (the network).To be truly robust, the system must support one database server per password management server,with real time replication between servers. This eliminates any single point of failure.

• Fail-over rather than fail-outSome systems implement a “hot standby” server rather than load balancing between multiple activeservers and removing malfunctioning servers automatically, if required.Using a standby server is a waste of capacity and a limitation of maximum scalability.



• Attaching users to specific servers

Some systems attempt to scale by assigning specific user groups (e.g., based on the first letter oftheir login ID) to specific servers.

While this approach does scale, it does not address the high availability requirement, is difficult tomanage and may not be user-friendly.

4.2 Security

A password management system is a sensitive part of the I.T. infrastructure because it can reset any user’spassword on any system and because it either contains or can access confidential user profile data.

This sensitivity means that a password management system must be managed securely.

4.2.1 Requirements

• Host platform

The password management server must be able to run on a hardened host operating system, with ahardened web server.

While every operating system and web server has a history of at least some security vulnerabilities,these vulnerabilities are inevitably due to a flaw in one subsystem or another. By disabling non-essential subsystems, it is possible to reduce the likelihood of future problems.

• Use of encryption

All sensitive data, be it transmitted or stored, should be encrypted or hashed, as appropriate. Thismeans using HTTPS from the client web interface to the password server and suitable protocols toencrypt data going from the password server to managed systems or back-end databases.

• User authentication

A password management system that includes self-service password reset in effect makes passwordsand non-password authentication equivalent.

Passwords, especially if they are changed frequently and comply with reasonable complexity rules,are fairly secure. Accordingly, it makes sense to use strong profiles of authentication data or hardwaretokens if possible, as the non-password authentication system.

If Q&A profiles are used as the non-password authentication system, they should include multiple setsof questions, with separate requirements and usage for each. In particular, users should be requiredto answer some pre-defined questions to ensure quality and in addition should have to define someof their own question/answer pairs, to ensure that every profile is unique.

• Trust relationships

The password server should not trust other systems. It should not be possible for the administrator ofanother system to abuse such trust to gain control over the password system. In practice, this gen-erally means that a password management server should not be a member of a NOS domain, wheredomain administrators can also sign into the password management server as local administrators.




• Host platformSome operating system components to avoid or disable, because of their history of security problems,include:

– IIS and in particular Active Server Pages.– File sharing and in particular NFS and SMB.– “Simple network services” such as echo and time-of-day.– Windows services such as COM, DCOM and DDE.

Ideally, a password management system should be able to run on a stripped-down server, with only aweb service running and preferably a web server such as Apache with almost every module disabled.

• Working with web proxies and firewallsIt is desirable to be able to install a password management server in a secure subnet, behind areverse web proxy. This eliminates any possibility that an attacker could connect to any service on thepassword server directly.

This implies that all communication from users to the password server be carried over pure HTTPS.A password management server should not incorporate an application-level protocol from a clientsoftware component (ideally there should be no client software) and the server.

• “API security”Some password management products rely on third-party vendors to encrypt their native communica-tion protocols. They assume that if a native API was used to manage passwords on a given system,then that communication must be secure.

This is nonsense. Many native protocols, such as those used by Oracle (SQL*Net), MSSQL (TDS)and SAP (CPIC), are vulnerable to attacks by packet sniffers and man-in-the-middle attacks.

A password management server must include some provision to protect communication with everytarget system, even when its native protocol is insecure.

Encrypting communication with insecure managed systems can only be done by installing an agenton the managed system or installing a secure application-level proxy server that is co-located in asecure environment with the managed system.

• Strong user authenticationUser authentication should be strong at all times. In practice, this means:

– Using a current password and not a PIN when users sign in to enroll.– Using hardware tokens if possible for non-password authentication.– Using multiple sets of questions, both standard and free-form, for challenge-response authenti-

cation.– Implementing intruder lockout and alarms when there are repeated authentication failures.

• Using a real certificate authoritySome products use SSL to encrypt communication between their clients (web-based) and their ownserver, but use a private, vendor-supplied certificate to initiate this communication.

Password vendors are not certificate authorities and should not issue their own cryptographic certifi-cates!



5 Deployment and Ongoing Administration

5.1 Deployability

The main reason for installing a password management system is normally to achieve cost savings. If thesystem is difficult or costly to deploy, those savings are offset by unreasonably high initial cost and may bedelayed unacceptably.

Accordingly, rapid and inexpensive deployment is essential to a worthwhile password management system.

5.1.1 Requirements

• No requirement for client software

Deploying client-side software in a large organization can be costly. Consider the problems createdby pushing software to thousands of workstations, each of which may run a different operating systemversion or patchlevel and each of which may have a different configuration.

The cost of deploying client-side software may be prohibitive and should be avoided if possible.

• Automatic discovery of managed user IDs

Every password management system must have a profile for each user, that connects that user withhis login IDs on managed systems.

A password management system should construct this profile automatically. Where automatic dis-covery of this profile data is not possible, the password management system should invite users topopulate their own profile data.

• Self-contained system

A password management system should be simple to install, which generally means that it shouldbe self-contained. Reliance on external infrastructure, such as a corporate directory, meta directoryproduct, HR database or incident management system is undesirable.

Self-reliance is also an important attribute for high-availability, as it makes it simpler to engineer aredundant solution, with no single-point-of-failure.

• Minimal change control on integrated systems

Installing agents on production servers is costly, as it normally entails a change control and qualitytesting process. If a password management system can integrate with a system without installing localagents, it will be much simpler to install and administrators of that system will have fewer objectionsto its deployment.


• MSGINA.DLL

A key problem in a password management system is how to empower users who forget their initialnetwork password to access a self-service password reset. Most password management systems areweb-based, but users who forget their initial login password cannot access their own desktop and socannot launch a web browser.



On Windows NT, 2000 and XP workstations, the login screen is implemented by and can be extendedby manipulating the Graphical Identification and Authentication (GINA) DLL.Some vendors address this problem by installing client-side software which replaces or wraps aroundthe Microsoft GINA DLL. This gives their products the ability to introduce new user interface compo-nents at the login prompt – notably a button that users who forget their passwords can click to activatea self-service password reset user interface.Wrapping or replacing the native Microsoft GINA DLL is usually undesirable:

– It requires client-side software, which is undesirable in general.– A bug, failed installation or service-pack-incompatibility in the 3rd-party GINA DLL can render

affected workstations inoperable – such workstations may have to be re-imaged.– Some network operating system1, hard disk encryption2 and authentication technology3 vendors

already replace or wrap the native Microsoft GINA DLL. This raises the problem of compatibilitybetween a 3rd-party GINA DLL provided by a password management vendor and other 3rd-partyGINA DLLs from other software vendors.

The same problem can be resolved without a client-side software deployment (using a secure kioskaccount) or with client-side software that does not replace the GINA DLL (using a service that adds abutton to an already-running GINA screen). Consequently, deploying a GINA wrapper DLL representsan unnecessary project risk.

• A massive data loadAs described earlier, a password management system by definition requires a profile for each user.The profile must include a set of challenge/response data used to authenticate users who forget theirpassword, a list of login IDs that belong to the user and possibly additional data about the state of theuser’s profile.To the extent possible, this data should be produced through a combination of auto-discovery andself-service enrollment.Some vendors approach this data set as an opportunity to sell professional services. Organizationsshould beware costly deployment projects and ongoing data maintenance requirements. A manualdata load by external consultants can easily be the largest cost component of a deployment projectand may delay production roll-out by months.

5.2 Administration

As with deployability, the ongoing cost and effort required to maintain a password management systemshould be minimal.

5.2.1 Requirements

• Database administrationA password management system should not require the ongoing intervention of a database adminis-trator, either to manage the DBMS server infrastructure or to maintain the contents of a user-profiledatabase.

1Novell2Checkpoint3RSA



• Automatic discovery and registration of new users

Organizations onboard (hire), deactivate (terminate) and move people constantly. These businessevents can produce a high volume of changes to the list of users in each security database andconsequently to the list of users that a password management system must support.

A password management system should automatically detect new and deleted users on integratedsystems, so that it can automatically add and remove user profiles and login IDs in its own database.

In addition, users should be able to update their own profiles, to attach existing login IDs that werenot automatically detected or automatically attached by the password management system. This cansignificantly reduce the need for administrative intervention in the day-to-day operation of the system.


• Double entry book-keeping

Some password management systems do not support auto-discovery of users and login IDs on targetsystems or allowing users to attach their own login IDs to their own profiles.

In these cases, the administrator of a password management system must manually make entries toreflect new and removed users on target systems. This is costly, error-prone and undesirable.



6 Vendor Viability and Commitment

Password management systems typically have a lifespan of several years and this time interval spansmultiple infrastructure upgrades addition and removal of applications and changes to business processes.

A password management system must be supported by a capable and stable vendor. A vendor with poorskills or vision will be unable to properly support its product. A vendor whose business may not be viable orwhose focus may shift away from password management will not offer adequate support to customers.

6.1 Breadth of vision

The password management market is a part of a larger user provisioning and identity management market.To be viable, vendors must provide a broader set of functionality beyond just password management.

6.2 Viable business and stable products

A vendor who goes out of business cannot offer long-term support for its products.

Similarly, a vendor who is acquired may not offer support for some products, as some may be retired orreplaced by products offered by the new parent company.

6.3 Services Organization

A password management vendor must support integration with a diversity of existing infrastructure, includ-ing:

• Network operating systems.

• Mainframes and minicomputers.

• Directories.

• DBMS servers.

• ERP and other applications.

• E-mail systems.

• Web infrastructure.

• Incident management systems.

• Authentication hardware (tokens).

• Interactive Voice Response (IVR) servers.



It follows that the vendor should have at least some expertise with each of these types of systems.

This is a difficult challenge for any single vendor to meet. Accordingly, it is prudent to try the product and atthe same time evaluate the vendor’s ability to support these various integrations, before purchasing.



7 Conclusions

As described in this document, a password management system is conceptually simple, but can be difficultto deploy and to manage.

A careful examination of products and their vendors is essential to achieving:

• Rapid deployment.

• Reliable and scalable operation.

• Good user adoption.

• Long term support.

Without meeting these objectives, a password management system will not achieve reduced cost, improveduser service or enhanced security.

The issues raised here are difficult to validate on paper. Hitachi ID encourages prospective customers touse the points raised in this document to construct rigorous laboratory testing conditions and to evaluateprospective products empirically, with vendor assistance.

www.Hitachi-ID.com

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: [email protected]

File: /pub/wp/documents/selecting_pw_product/selecting_pw_product_8.texDate: 2009-05-11


Selecting a Password Management Product

Technology

Transcript of Selecting a Password Management Product