PDF

swipe to navigate

Organization

To be successful, a password management project must have a mandate, a schedule and a budget. Persons in an organization with a vested interest in password management must be involved early in the project. This ensures that their requirements are met at the design stage, and that they will not object to any part of the project during deployment.

Mandate

A password management project must start with a clear mandate to solve specific business problems. (2) outlines the most likely issues that must be resolved.

Projects that start without this mandate may fail when the time comes to request resources and the support of groups within the organization.

Budget

It is often helpful to verify, at the onset of a password management project, whether or when sufficient funds will be available. The following items require funding:

  • A software license for the selected product.
  • Annual support costs.
  • Training.
  • Hardware and associated software costs (including operating systems, network management software, installation).
  • Professional services -- to install the selected product and to manage a roll-out.
  • Internal resources -- for project management, product selection, installation and ongoing system administration and support.

Participants

Early involvement by all interested parties in an organization ensures that the final design reflects all needs, and that no objections will be raised late in the project.

The following groups are typically involved in a password management project:

  • The help desk / I.T. user support: Must understand how to use the system and its impact on their work. Password management systems typically produce the most tangible cost savings here. Help desk analysts will be the direct users of the system.
  • Desktop support: Must approve any software that will be installed or executed on workstations, as well as any proposed configuration changes.
  • Systems administrators: Must understand the impact of a password management solution on the systems they manage.
  • I.T. security: Must understand the impact on overall security policy and design. Should approve password policies and non-password authentication methods (for example, authentication used for password resets.)

Ownership

It is crucial for a password management project to include the system's long-term owner, as early as possible.

Ideally, the long-term system owner and the system's technical administrator(s) will have a strong influence over product selection. These people will have to work with the system and its vendor, so they are more likely to take the time to make a critical analysis of product documentation, and undertake a technical laboratory evaluation of candidate products.

It is risky, on the other hand, to have one team select a product, and a separate team install and manage it.

Selecting a product

The ideal password management product should meet all of the project's technical requirements, and be supported by a stable, mature and helpful vendor.

The following sections describe the technical and business requirements that a password management system vendor should meet.

Technical requirements

Functionality

A password management system should include functionality for:

  • Password synchronization:

    Users should be able to maintain a single password that applies to most, if not all, of their login IDs. This helps users remember their passwords and reduces calls to the help desk. Users with a single password are less likely to write down or share their passwords.

  • Self-service password reset:

    Users who forget their passwords should be able to quickly resolve their problems without calling the help desk.

  • Help desk password reset:

    Support analysts should be able to authenticate a caller, reset passwords and automatically create or close a help desk ticket from a single screen. This reduces call duration and cost, and improves customer service.

  • Multiple access methods:

    Users should be able to access the system using all methods offered by the organization, including:

    • A web browser and an existing password change user interface, for routine password changes.

    • A web browser from the user's own desktop login screen, for self-service password resets.

    • An interactive voice response (IVR) system, for users who need to reset their remote access password.

  • Profile builders:

    • In some organizations, users have different login IDs on different systems. If no database exists to correlate IDs to users prior to deployment, then a profile builder must be available to collect this information from users.

    • If users will be authenticated for password resets using personal information profiles, then a profile builder may be required to update existing data (for example, in a human resources database) or to create new authentication profiles.

    In most cases, the user profile builders should be tools included in the password management authentication module.

  • Language support:

    Organizations that use languages other than English should be able to deploy the solution with multiple languages.

Target systems

A successful password management system should be able to manage passwords on most or all of the systems to which users login with an ID and password.

If this is not possible, then a threshold for systems that must be supported should be defined. A reasonable approach is to require the solution to manage passwords for systems that generate 95% of password-related calls to the help desk.

Target systems should work "out of the box" in as many cases as possible.

Where this is infeasible (e.g., home-grown applications, vertical market applications, legacy applications), the product should be open enough to make it possible to easily integrate with applications:

  • Some applications include an API for managing passwords. While rare, this is a useful mechanism to integrate a password management system. It's useful to check the language bindings of any such API, and compare these to what the password management system supports.
  • Some applications include command-line tools to manage passwords. The password management system should be able to execute these -- on whatever platform they are available.
  • Some applications store their passwords in a database, where a password management system may manipulate them directly. This includes client/server applications and web applications with DBMS back-ends.
  • Some applications run on midrange or mainframe systems, and can be manipulated by scripting interaction with a terminal login session.
  • Some applications present a web GUI, and a password management system can interact with them by simulating the actions of a web browser.

Integration

A password management system should integrate seamlessly with existing I.T. infrastructure, including:

  • Authentication systems:

    Users should be able to authenticate using existing infrastructure -- be it a network login ID/password (such as a Windows NT domain), security tokens (such as an RSA SecurID) or by answering questions drawn from an H.R. database.

  • Support systems:

    The system should automatically create issues / tickets in any help desk's support system used by the organization (such as Remedy or Peregrine).

  • Electronic mail:

    The system should be able to interact with users by e-mail -- for example, to prompt them to register, or notify them of events related to their login IDs.

  • Telephony:

    Users should be able to access a self-service password reset using existing telephony servers.

  • System monitoring:

    Existing infrastructure should be able to monitor the password management server health, and react to alarm conditions.

Deployment

Deployment should be as simple as possible. Features supporting this objective include:

  • No use of any desktop software components:

    Even very small and simple desktop software must be deployed to thousands of PCs in a large organization. These PCs may not conform to corporate standards, and an installation process that works for one may fail on another.

    Clearly, it is preferable to avoid desktop software deployment entirely, and eliminate the related risks, effort and expenditure.

  • Minimize server agents:

    Installing agents on a production server normally involves a lengthy change control process. Using existing client software to communicate with servers reduces deployment time.

  • Integrate with existing databases:

    A password management system should take advantage of existing user profile databases, which may include information such as a list of which systems each user logs into, or what questions to ask a user to authenticate him if he forgot his password.

  • Automatic discovery of login information:

    The system should automatically detect new or deleted login IDs on the systems where it manages passwords. This reduces both initial deployment and the ongoing administration effort.

  • Self-service registration:

    Users should be able to update their own profiles in the system, including login IDs and authentication data.

Flexibility

The system should cope with both current and possible future requirements for:

  • User interface:

    The user interface should be customizable, and support different appearances for different users (such as multiple languages or user groups).

  • Help desk integration:

    The business logic of updating information in a help desk system should be customizable.

  • Password policy:

    The system must be able to enforce a global password policy.

  • Password reset authentication policy:

    The system must support the organization's policy for authenticating users who require a password reset.

Security

A password management system literally owns the "keys to the kingdom" and consequently must meet the most stringent security requirements:

  • Encryption
    • User access to the system must be encrypted, across every user interface where this is feasible (a notable UI where this is not feasible is the telephone).
    • Any sensitive data stored in the system should likewise be encrypted or hashed, as appropriate. This includes administrative passwords of people authorized to manage the product, as well as passwords used by the product to manage target systems. This also includes any sensitive user profile data (e.g., authentication Q&A).
    • The product should support encrypted communication with all target systems -- including those that do not natively implement an encrypted client/server protocol (e.g., most DBMS servers, mainframes, etc.).
    • Encryption should rely on well-known implementations of well-known, trusted encryption and hashing algorithms.
    • Encryption keys should be managed effectively. For example, public keys must be signed by a real certificate authority (and not by the vendor). Private keys must be obscured and protected by operating system ACLs.
  • Authentication
    • Users must be properly authenticated for every system access. This is done, for example, by asking users to answer multiple personal questions, by having users type their password to some trusted system, or using hardware tokens.

      Some measures that are clearly not secure enough include:

      • PINs -- which can be guessed, may be intercepted in e-mail distribution, and are likely to be forgotten by users in any case.
      • Use of a single challenge/response question.
    • Administrators must be duly authenticated prior to getting access to the system. They should use the most secure means possible -- e.g., hardware tokens or strong passwords. Q&A profiles are generally not strong enough to be suitable for use by administrators.
  • Accountability The system must record every possible event, so that users and administrators alike can be held accountable for their actions.
  • Hardened platform
    • The product should operate on a locked down operating system.
    • The product should support a diversity of web servers, so that if a given web server is deemed to have an unacceptable history of vulnerabilities, it can be avoided.
    • The product should be accessible across web proxies, so that it can be installed in a protected subnet, and accessed across a firewall without opening non-HTTPS ports.
    • The product should not require the installation of (possibly insecure or vulnerable) client software.

Vendor profile

As with any vendor, the company supporting a password management system should offer sound support, effective professional services, good relationships with other relevant vendors, and long term stability.

Financial stability

The five vendors with the largest market share in password management products are all small, and with one exception privately held corporations.

In the interests of long term support for the technology, it is important to verify that prospective vendors are financially sound: growing rather than shrinking, and profitable rather than burning cash reserves.

Quality of support

Quality technical support is crucial to project success. This is best measured by implementing the password management system in a test environment, and evaluating the ability of the vendor to assist in the installation process.

Deployment time

Vendors should be able to offer turn-key or assisted deployments. A good vendor will be able to successfully deploy the system in a minimum amount of time. A good product can be deployed without intrusion -- without installing desktop software, and with limited use of server agents.

The deployment effort in a large organization should not take more than 10-20 supplier person/days.

Single source

It is easier and safer to work with a vendor that can provide all the required technology directly. This eliminates the risks of using third party technology, such as:

  • Increased cost.
  • Uncertain future product availability and revision.
  • Limited, poor or inconsistent technical support.

Future direction

The successful vendor should have a clear direction for future growth and technology advancement. This helps to ensure vendor stability, and a sound future for the product.

Partners

Password management products must inter-operate with other I.T. infrastructure supported by current suppliers. Relationships between a password management vendor and the vendors of other infrastructure or services can streamline interoperability and ongoing support.

In particular, it is helpful if the password management vendor has a working relationship with providers of:

  • Support portal technology.
  • I.T. and help desk outsourcers.
  • Security infrastructure.

PDF

Comment via LinkedIn