Hitachi ID Systems, Inc.

Hitachi

Free White Papers Hitachi ID Privileged Password Manager Overview
certification

Hitachi ID Privileged Password Manager Overview

Abstract
Hitachi ID Privileged Password Manager (formerly ID-Archive) is a system for securing privileged passwords across large numbers of devices. It works by regularly randomizing privileged passwords on workstations, servers and applications. Random passwords are encrypted and stored on at least two replicated servers. Passwords may be disclosed:
  1. To administrators, after they have authenticated and their requests have been authorized.
  2. To applications, replacing embedded passwords.
  3. To Windows workstations and servers, which need them to start services.

Password changes and disclosure are closely controlled and audited, to satisfy policy and regulatory requirements.

Privileged Password Management

Privileged passwords must be protected more vigorously than any other data in an organization:

  1. Sensitive data:
    Privileged passwords are arguably the most sensitive data in an organization, since they unlock all other data. Inappropriate disclosure can be catastrophic.
  2. Business interruption:
    Loss of access to privileged passwords means that the systems which the privileged passwords control cannot be managed, at least until they are powered down and "hacked into." Consider the impact on IT support of a disaster where every root or Administrator password in a company is permanently lost.
  3. Constant change / data backup:
    If privileged passwords are changed regularly, then scheduled backups will contain mostly historical data rather than current passwords and so provide little value.

Hitachi ID Privileged Password Manager enables organizations to secure privileged passwords:

Technical Challenges for Privileged Password Management

The obvious solution to the security vulnerability of static and shared administrator passwords is to change these passwords so that each one is unique and changes regularly. Doing this can be technically challenging, however:

Functional Requirements for a Privileged Password Management System

A privileged password management needs a set of well-integrated features to function:

  1. It must randomize passwords regularly -- sensitive passwords should be unique and short-lived.
  2. It must be able to disclose passwords to appropriate users and software agents, but only under the right circumstances:
    1. To IT staff, if they have been assigned appropriate access rights.
    2. To IT staff who have not been assigned permanent access rights, but have been granted one-time permission.
    3. To programs that start services (Windows Service Control Manager, Scheduler, IIS and others) so that they can start services after a password change.
    4. To applications, to replace embedded passwords in programs and scripts.

  3. Both a static access control model and a dynamic authorization workflow are required.
  4. The system must log both password updates and disclosure. Failed updates can be used to identify infrastructure problems while logs of password disclosure create accountability.
  5. The system should be able to control concurrent disclosure of a given password -- for example to limit the number of people concurrently able to manage a server.

Hitachi ID Privileged Password Manager Password Randomization

Hitachi ID Privileged Password Manager secures sensitive passwords by periodically randomizing them:

  1. On push-mode servers and applications:
    1. Periodically -- for example, every night between 3AM and 4AM.
    2. When users check passwords back in, after they are finished using them.
    3. When users request a specific password value.
    4. In the event of an urgent termination of a system administrator.

  2. On pull-mode workstations and other devices:
    1. Periodically -- for example, every day.
    2. At a random time-of-day, to prevent transaction bursts.
    3. Opportunistically, whenever network connectivity happens to be available from the workstation to a central server.

Hitachi ID Privileged Password Manager can enforce multiple password policies. There is a global policy and local, override policies applied to resource groups. Password policies specify the complexity of both randomly chosen and manually selected passwords. In addition to mandating character types (lowercase, uppercase, digits, punctuation), the policy can specify minimum and maximum password lengths and other characteristics, especially relevant to manually-chosen passwords, such as dictionary and history checks.

Hitachi ID Privileged Password Manager Password Disclosure

Hitachi ID Privileged Password Manager is designed to not only randomize and securely store, but also to disclose privileged passwords to people and programs after appropriate authentication and authorization. It includes the following password disclosure capabilities:

  1. To users, via a web interface, subject to access control policy.
  2. To users who do not have pre-programmed password disclosure rights, after approval by pre-defined authorizers.
  3. To applications, in order to replace embedded passwords, using an API (application programming interface) where applications authenticate using an OTP (one time password) and may only connect from a pre-defined range of IP addresses.
  4. To service launching programs, such as the Windows Service Control Manager, by writing new password values to the appropriate locations after a successful password change.

Note that all disclosure is subject to SSL encryption, strong, personal authentication, access controls or workflow approval and audit logs.

Access Controls for Regular Users

The most common form of access control in the Hitachi ID Privileged Password Manager is based on resource groups. Resource groups are named collections of devices where privileged passwords are managed and to which policies are applied.

Resources can either be attached to a group explicitly (e.g., "attach workstation WKSTN01234 to resource group RGWKSTNS") or implicitly, using an expression. Expressions may be based on the operating system type, IP address, MAC address or workstation name (e.g., "attach every workstation running Windows XP in subnet 10.1.2.3/24 to resource group X")

Policies applied to resource groups include:

  1. Which accounts' passwords to randomize.
  2. How to compose random passwords (e.g., length, complexity, etc.).
  3. What actions to take after successful or failed attempts to disclose a password.

Resource groups may be nested, as a mechanism to more naturally represent groups of devices.

Hitachi ID Privileged Password Manager users are likewise grouped into console user groups, either explicitly or implicitly (i.e., via membership in a user group on a target system, such as Active Directory). Groups of console users are granted specific rights to resource groups. Rights include the right to display member devices, to view passwords and to view access history.

Business policies, such as segregation of duties between different groups of IT administrators, can be enforced by assigning users to distinct user groups, each with access to different (non-overlapping) sets of passwords.

Workflow for One-Off Disclosure

Hitachi ID Privileged Password Manager includes the same authorization workflow engine as is used in other Hitachi ID Systems products -- Hitachi ID Identity Manager (formerly ID-Synch), Hitachi ID Access Certifier (formerly ID-Certify) and Hitachi ID Group Manager (formerly ID-Access). Workflow enables one user to request release of a given password. When this happens, one or more other users are invited (via e-mail) to review and approve the request. Approved requests trigger an e-mail to the password recipient, including a URL to Hitachi ID Privileged Password Manager where he or she can re-authenticate to display the requested password or launch a login session to the device in question.

The workflow process is illustrated by the following series of steps:

  1. User UA signs in and requests that the then-current password to login account LA on system S be made available to user UB at some later time T. UA may or may not be the same person as UB.
  2. Hitachi ID Privileged Password Manager looks up authorizers associated with LA on S.
  3. Hitachi ID Privileged Password Manager may run business logic to supplement this authorizer list, for example with someone in the management chain for UA or UB. The final list of authorizers is LA. There are N authorizers but approval by just M (M <= N) is sufficient to disclose the password to AZ.
  4. Hitachi ID Privileged Password Manager sends e-mail invitations to authorizers LA.
  5. If authorizers fail to respond, they get automatic reminder e-mails.
  6. If authorizers continue to fail to respond, Hitachi ID Privileged Password Manager runs business logic to find replacements for them, effectively escalating the request and invites the replacement authorizers as well.
  7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Hitachi ID Privileged Password Manager web login page, review the request and approve or reject it.
  8. If any authorizers reject the request, e-mails are sent to all participants (UA, UB and AZ) and the request is terminated.
  9. If M authorizers approve the request, thank-you e-mails are sent to all participants. A special e-mail is sent to the recipient -- UB with a URL to a password disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Hitachi ID Privileged Password Manager and displays the password.
  11. UB clicks on a button to "check-out privileged access."
  12. UB then may click on a button to do one of the following (the options available will vary based on policy):
    1. Display the password.
    2. Place a copy of the password in the operating system copy buffer.
    3. Launch an RDP, SSH or similar remote control session to the server in question.

    In other words, display of a sensitive password is not a mandatory part of the solution.

Concurrency Controls -- Checkin/Checkout

Hitachi ID Privileged Password Manager can be configured to track and control the number of people to whom a given password is disclosed at any given time. This is done using the concept of password checkout and checkin.

  1. Rather than simply disclosing a managed password, a user may be required to check it out. Checkout is subject to policy control:
    1. A counter is incremented whenever a password is checked out, indicating that one more person is in possession of the password.
    2. The number of users who may concurrently check out a password is limited -- for example, up to two at a time.
    3. The time interval for which a user may hold a password is limited -- for example, no more than two hours.

  2. Users are asked to check-in passwords when they are done using them:
    1. The password's checkout counter is decremented.

  3. If the maximum allowed password checkout time has elapsed, Hitachi ID Privileged Password Manager may automatically check the password back in, which causes it to be randomized again.
  4. Checkin and checkout supports coordination among IT workers:
    1. Hitachi ID Privileged Password Manager can notify users who already possess a password of new checkouts, for example to let them know that someone else will now be working on the same system on which they are already working.
    2. Hitachi ID Privileged Password Manager can show requesters who already has a given password.

  5. Password checkout is time limited, and passwords may be automatically checked back in after the allowed time has elapsed.
  6. Passwords can be automatically randomized whenever the checkout counter returns to zero, meaning that no users will know the new password after a given amount of time has elapsed.

Checkin/checkout supports easier coordination between IT workers who need to collaborate.

API for Progammatic Disclosure

Hitachi ID Privileged Password Manager includes an API, which enables applications to disclose passwords and eliminates the storage of static, plaintext passwords. Hitachi ID Privileged Password Manager periodically randomizes service passwords, while applications use the API to retrieve passwords as/when required.

The Hitachi ID Privileged Password Manager API is accessed using SOAP over HTTPS.

For example, Hitachi ID Privileged Password Manager may randomize an Oracle DBMS login password every 24 hours. Web applications which use the password to establish database connections can periodically sign into Hitachi ID Privileged Password Manager with their own credentials (see below) and retrieve the current Oracle login password.

An important design consideration when implementing a privileged password retrieval API is how the client which requests password disclosure (the web application in the above example) authenticates itself to the API service. Hitachi ID Privileged Password Manager secures this process with a combination of ACLs, one-time passwords and IP subnets:

  1. API clients have their own IDs, used to sign into Hitachi ID Privileged Password Manager.
  2. These IDs are attached to console user groups and assigned ACLs, allowing them to disclose certain passwords.
  3. API client login IDs are assigned one-time passwords (OTPs). In effect, the password used by the service to sign into the Hitachi ID Privileged Password Manager API changes to a new, random string on each API connection.
  4. API client login IDs are bound to IP subnets. They can only sign into the API from given IP ranges.

In addition, application writers are encouraged to protect OTP strings using both encryption (fixed key, embedded in the application) and filesystem access controls.

Updates to Service Passwords

On the Windows operating system, service programs are run either using the SYSTEM login ID, which possesses almost every privilege on the system (and consequently can do the maximum harm), and which has no password, or using a real user's login ID and password, in order to execute with reduced privileges. This means that on each Windows workstation and server there are a number of service accounts, each with its own password, which are used to run service programs such as web servers, backup agents, anti-virus software, etc.

Service account passwords differ from administrator passwords in that they are stored in at least two places:

  1. Hashed, in the security database -- e.g., the local SAM database or Active Directory, just like all users.
  2. Reversibly encrypted, in the registry or elsewhere, where the program that starts the service (e.g., Service Control Manager or similar) can retrieve it when it needs to start the service.

Other Windows components besides the Service Control Manager also store passwords twice:

  1. Virtual directories used to access web content from the IIS web server.
  2. Programs scheduled to be run by the Windows Scheduler.

Third party programs may also require passwords to be stored outside the Security Accounts Manager (SAM) database.

Of the above passwords, all but those used in IIS are static and may represent a security vulnerability.

Hitachi ID Privileged Password Manager can be configured to secure service account passwords. This means two things, depending on the mode of operation:

  1. In pull mode, the Hitachi ID Privileged Password Manager workstation service periodically scrambles service account passwords locally, in coordination with the central Hitachi ID Privileged Password Manager server cluster.
  2. In push mode, Hitachi ID Privileged Password Manager servers periodically connect to Windows servers in order to change the passwords of service accounts.

In both cases, Hitachi ID Privileged Password Manager notifies the program that launches service accounts of the new password value, so that it can successfully launch the service at the time of the next system restart or when an administrator manually stops and restarts the service in question.

In push mode, Hitachi ID Privileged Password Manager runs an exit program which remotely connects to the server in question and updates the secondary storage of the service password. Exit programs are provided to remotely update:

  1. The Windows Service Control manager.
  2. The Windows Scheduler.
  3. The IIS web server.

Hitachi ID Privileged Password Manager implementers can write additional exit programs to update service passwords used by other programs, stored in other locations. These are typically command-line programs (Win32 executable or script) that run on the Hitachi ID Privileged Password Manager server.

In pull mode, the Hitachi ID Privileged Password Manager workstation service can use a DLL to update local passwords. DLLs are provided for the same Windows components as the exits above, and implementers can write new DLLs to update other passwords.

Strong Authentication

(1)Hitachi ID Privileged Password Manager can be configured to take advantage of an existing directory of users for authentication and authorization:

  1. Users may sign into Hitachi ID Privileged Password Manager with their Active Directory or LDAP login ID and password.
  2. Users may be required to authenticate with a two-factor technology, such as an RSA SecurID token.
  3. User membership in Hitachi ID Privileged Password Manager security groups, and consequently user privileges, may be based on user membership in AD or LDAP groups.

Externalizing user identification, authentication and authorization can significantly reduce the administrative overhead of managing a Hitachi ID Privileged Password Manager deployment.

(2)Administrators (IT staff) authenticate to the Hitachi ID Privileged Password Manager web GUI as follows:

Auditing and Regulatory Compliance

Hitachi ID Privileged Password Manager logs all attempted and completed password updates. This data can be used to track not only current administrator passwords for workstations and servers, but also device IP addresses and network status. Hitachi ID Privileged Password Manager also logs all attempts by users to look up devices and to display passwords. This creates a chain of accountability, making it clear who accessed what device and when, and also who attempted to access a device and was blocked by policy or failure to get approval.

Hitachi ID Privileged Password Manager includes event reports, which make it possible to see, among other things:

By recording administrative access to key systems, and in some cases by requiring multiple people to approve such access before it happens, Hitachi ID Privileged Password Manager can both limit and record access to sensitive systems that contain privacy-protected or financial data. These controls assist in complying with regulations such as HIPAA, SOX, PCI and more.

Hitachi ID Privileged Password Manager Architecture

Network Architecture

Figure [link] illustrates the network communication paths in a typical Hitachi ID Privileged Password Manager deployment, where Hitachi ID Privileged Password Manager pushes passwords to fixed target systems -- servers, applications, network devices, etc.

figure

    Hitachi ID Privileged Password Manager Push-Mode Network Architecture Diagram (3)

In the diagram:

  1. Three distinct physical sites are shown, each surrounded by a dotted-line border.
  2. Two Hitachi ID Privileged Password Manager servers are deployed, to two different sites. Real-time replication provides for resiliency in the event of a hardware failure on a single server or a complete outage at either site.
  3. The Hitachi ID Privileged Password Manager servers run on Windows 2003 or Windows 2008. This platform provides the widest possible range of client software, making Hitachi ID Privileged Password Manager easy to integrate with many kinds of target systems.
  4. Stored passwords are encrypted (using AES). The encryption key is kept in the registry of each Hitachi ID Privileged Password Manager server, and is itself encrypted using a key embedded in the Hitachi ID Privileged Password Manager software.
  5. Each Hitachi ID Privileged Password Manager server has a complete, local copy of the entire password database along with all configuration information.
  6. Data replication traffic between the two servers is encrypted, making it resistant to snooping or tampering by a man-in-the-middle attacker.
  7. Periodically, each Hitachi ID Privileged Password Manager server connects to target systems and pushes new passwords to them. The protocol used depends on the type of target system, with two examples shown: LDAPS or NTLM for Windows servers, SSH to Unix or Linux servers and an encrypted TCP/IP connection to Unix targets that do not have an SSH service but do have a local Hitachi ID Privileged Password Manager listener.
  8. Some target systems may be unreachable directly, because of intervening firewalls. These may be contacted indirectly using an Hitachi ID Privileged Password Manager proxy server, co-located with the target system. In this scenario, communication from the primary Hitachi ID Privileged Password Manager server to the target system is via an arbitrarily-numbered TCP/IP connection and AES encryption using a shared key. The connection is forwarded to the target system by the proxy, using that target system's native protocol.
  9. Hitachi ID Privileged Password Manager clients, such as IT workers or applications that use Hitachi ID Privileged Password Manager in place of embedded passwords, connect to Hitachi ID Privileged Password Manager over HTTPS. Since multiple Hitachi ID Privileged Password Manager servers are available and each of them contains a full data set, this connection can be load balanced.

Push and Pull Modes

Hitachi ID Privileged Password Manager supports both server passwords, in "push mode," and workstation passwords, in "pull mode:"

When managing passwords on servers, Hitachi ID Privileged Password Manager normally operates in "push mode." This means that periodically the Hitachi ID Privileged Password Manager server will initiate communication with each target system, using an agent program installed locally on the Hitachi ID Privileged Password Manager server and randomize the administrator passwords on that target system.

The new password(s) will be encrypted and archived in the Hitachi ID Privileged Password Manager server's replicated storage, where IT staff may retrieve them.

When managing passwords on workstations, Hitachi ID Privileged Password Manager normally operates in "pull mode." This means that a local agent is installed on each workstation and this agent software periodically contacts the central Hitachi ID Privileged Password Manager server, over HTTPS, to request a new administrator password.

Once the local password has been set, a confirmation is sent to the Hitachi ID Privileged Password Manager server, which stores the new value. The new password(s) are encrypted and archived in the Hitachi ID Privileged Password Manager server's replicated storage, where IT staff may retrieve them.

The same approach can be used not just on workstations, but also to any type of device which is numerous (e.g., tens of thousands of devices), and/or which is only sporadically reachable over the network. Examples include "server farms" of Windows or Unix servers or target systems at remote locations.

Hitachi ID Privileged Password Manager Host Platform

Hitachi ID Privileged Password Manager must be installed on a Windows 2003 or Windows 2008 server.

Installing on Windows 2003 or Windows 2008 allows Hitachi ID Privileged Password Manager to leverage client software for most types of target systems, which is available only on the "Wintel" platform. In turn, this makes it possible for Hitachi ID Privileged Password Manager to manage passwords and accounts on target systems without installing a server-side agent.

The Hitachi ID Privileged Password Manager server must also be configured with a web server. Since the Hitachi ID Privileged Password Manager application is implemented as CGI executables, any web server will work. The Hitachi ID Privileged Password Manager installation program can detect and automatically configure IIS or Apache web servers, but other web servers can be configured manually.

Hitachi ID Privileged Password Manager is a security application and should be locked down accordingly. Please refer to the Hitachi ID Systems document about hardening Hitachi ID Privileged Password Manager servers to learn how to do this. In short, most of the native Windows services can and should be removed, leaving a very small attack surface, with exactly one inbound TCP/IP port (443):

  1. IIS is not required (Apache is a reasonable substitute).
  2. No ASP, JSP or PHP are used, so these engines should be disabled.
  3. .NET is not required on the web UI, so should be disabled on IIS.
  4. No ODBC or DCOM are required inbound, so these services should at least be filtered.
  5. File sharing should be disabled.
  6. Remote registry services should be disabled.
  7. Inbound TCP/IP connections should be firewalled, allowing only port 443 and possibly terminal services (if required for some configuration tasks).

Hitachi ID Privileged Password Manager is designed to be secure. It is protected using a multi-layered security architecture, which includes running on a hardened OS, using file system ACLs, providing strong application-level user authentication, filtering user inputs, encrypting sensitive data, enforcing application-level ACLs, and storing log data indefinitely.

Hitachi ID Privileged Password Manager never requires plaintext passwords to be stored in configuration files or scripts and does not store plaintext passwords anywhere. Hitachi ID Privileged Password Manager does not ship with a default administrator password -- one must be typed in at installation time.

These security measures are illustrated in Figure [link].

figure

    Network architecture security diagram (4)

Supported Target System Types

Hitachi ID Privileged Password Manager supports management of passwords on workstations, which may be mobile, have dynamic addresses, get unplugged, etc. This client software works by "pulling" new, local administrator passwords from the Hitachi ID Privileged Password Manager server cluster. Client software is available for:

  1. Windows 2000, XP, Vista, 2003 and 2008.
  2. Unix (various vendors) and Linux (IA86).

The Windows pull-mode service includes plug-ins to update passwords on the Windows Service Control Manager, Windows Scheduler and IIS. Other plug-ins can be added with minimal effort.

Push mode agents, installed on the Hitachi ID Privileged Password Manager server and designed to write new passwords to fixed-address target systems, are included for:

(5)

Directories

File/print

Mainframes
LDAP (any), Active Directory, Windows NT domains, Novell eDirectory, Novell NDS, Unix NIS and NIS+, Kerberos/DCE (any)

Windows NT/2000/2003/2008, Novell NetWare, OS2 LanManager, Samba

z/OS, RACF, CA-ACF2, CA-TopSecret, VM/ESA, Siemens BS2000, Tandem NonStop, Unisys MCP

Unix

Midrange

Database
AIX, DGUX, Digital Unix, HPUX, IRIX, Linux, NCR, OSF4, SCO OS, Solaris, SunOS, Tru64, UnixWare, Unisys, passwd, shadow, Trusted Computing Base

HP MPE, OS/400/iSeries, OpenVMS

DB2/UDB, Informix, MSSQL, ODBC, Oracle, Sybase

ERP

Messaging

WebSSO
SAP R/3 4.0+, PeopleSoft 7.5+, Oracle Applications 11i+, JDE OneWorld

MS Exchange 5.5, MS Exchange 2000/03/07, Novell GroupWise, Lotus Domino/HTTP, Lotus Notes/ID files, HP OpenMail

IBM TAM, RSA ClearTrust, Entrust getAccess, CA SiteMinder, Oracle COREid, SAP portal

Flexible agents

Hardware tokens and Smartcards

Miscellaneous
API (application programming interface) integration, LDAP attributes, MQ Series, SQL commands, Telnet/TN3270/TN5250 sessions, Unix/Windows cmd-line integration, web forms, web services (SOAP, XML)

RSA SecurID, Secure Computing SafeWord, Vasco Digipass, GemPlus, Precise Biometrics

BMC Service Desk Express, Clarify eFrontOffice, Connected Backup, IBM OLAP, IBM Tivoli Access Manager, Local and cached Windows passwords, HP Service Manager, RADIUS (various), BMC Remedy ARS and Tivoli ADSM,