secure management of privileged passwords

Secure Management

of Access to

Privileged Accounts

using Hitachi ID Privileged Access Manager

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

http://Hitachi-ID.com/

http://Hitachi.com/

Every IT asset has at least one local, privileged login account. This includes workstations, servers, net-work devices, databases, applications and more. Some assets also have privileged accounts used to runservices or authenticate one application to another.

Passwords for privileged accounts are used to install software, manage the device and perform technicalsupport functions. They are often “all powerful,” having unlimited access to system functions and data.Consequently, compromise of privileged passwords is effectively compromise of the device.

Secure management of access to privileged accounts is essential to IT security. This document identifiestechnical challenges and offers solutions for effectively managing large numbers of sensitive passwords.

Contents

1 Overview: The Business Problem 1

2 A Simple Solution: Randomize Passwords 2

3 Technical Challenges / Solution Requirements 3

3.1 Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2 Workstations: Location and Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.3 Scalability to Millions of Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.4 Reliable Operation and Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.5 Fault Tolerance: Hardware, Network and Facility Problems . . . . . . . . . . . . . . . . . . . 4

3.6 Encryption in Transit and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.7 Connectivity and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.8 Services and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.9 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.10 Audit Trails and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Architectural Elements 7


4.2 Workstations: Location and Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.3 Scalability to Millions of Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.4 Auto-discovery and Auto-configuration of Managed Systems and Accounts . . . . . . . . . . 7

4.5 Reliable Operation and Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.6 Fault Tolerance: Hardware, Network and Data Center Problems . . . . . . . . . . . . . . . . 8

4.7 Encryption in Transit and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.8 Connectivity and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

i

Secure Management of Access to Privileged Accounts

4.9 Services and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.9.1 Managing Passwords for Service Accounts . . . . . . . . . . . . . . . . . . . . . . 9

4.9.2 Managing Application Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.10 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.11 Audit Trails and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Hitachi ID Privileged Access Manager 11

5.1 Servers and Workstations: Push and Pull Modes . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.1 Push Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.2 Pull Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2 High Availability and Data Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.4 Auto-discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.5 Hitachi ID Privileged Access Manager Network Architecture . . . . . . . . . . . . . . . . . . 14


5.7 Proxies to Cross Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.8 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.9 Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.10 Reliable Password Changes and History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.11 Cryptographic Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.12 Logging and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.13 Learn More . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

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



1 Overview: The Business Problem

In a typical enterprise-scale organization there are thousands of servers, workstations and network devices.Normally, there is a single, shared administrator password for every type of device. For example, onepassword may be used for each workstation of a given type or for every server with a given configuration.This is convenient for data center and desktop support staff: if they need to perform maintenance or anupgrade on a workstation or server, they know how to log in.

Such static and well-known privileged passwords create both operational challenges and security problems:

• When administrator login IDs are shared by multiple IT users, there is no audit log mapping adminis-trative changes to individual IT staff. If an administrator makes a change to a system that causes amalfunction, it can be difficult to determine who caused the problem.

• When the same privileged account and password exists on many systems, it is hard to coordinatepassword changes. As a result, privileged passwords are rarely changed and are often known toex-employees.

These problems create security vulnerabilities. For example, if administrator passwords don’t change, thenformer IT workers retain them beyond their term of employment. This clearly violates internal controls:former employees should not have administrative access to corporate systems.

In most organizations, strong internal controls are mandatory. Privacy protection legislation such as HIPAAand GLB, as well as legislation regarding corporate governance such as SOX, requires that systems con-taining sensitive data be secured against unauthorized access. Effective management of access to privi-leged accounts is therefore not an option, but a requirement.

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


2 A Simple Solution: Randomize Passwords

The obvious way to eliminate static and shared privileged passwords is to change them regularly. If everysensitive password were randomized daily, control problems would be alleviated.

Since IT users often need to sign into privileged accounts, randomizing passwords is only half of the solu-tion. Additional functions are required to control access by IT users to these accounts:

1. Authentication of IT users who wish to gain privileged access to a system.

2. Access control over which accounts IT users may access and when.

3. Audit logs recording such access, to create accountability.

The combined solution, capable of both randomizing large numbers of passwords and controlling access topassword values or to the underlying accounts, can be complex. The following section describes some ofthe technical challenges that must be overcome in order to successfully deploy such a solution.



3 Technical Challenges / Solution Requirements

Describing a basic process for periodically randomizing and archiving administrator credentials is easy,while implementing such a process in a manner that scales well to thousands of devices, that is secure andfail-safe can be challenging.

The following sections describe some of the technical challenges such a system must address.

3.1 Platform Support

Every type of IT asset has a local administrator password. This is true even if network credentials are usedin the normal course of business to manage the device, since a local administrator password must be usedto attach each device to the network in the first place.

To be effective, a system for managing administrator passwords should support a broad array of platforms.This includes workstations, Windows servers, Unix servers, network routers, database servers, ERP appli-cations, midrange servers (iSeries, VMS, etc.), mainframe computers, directories and more. In short, everydevice that contains sensitive data or whose operation is critical to the business should be supported.

3.2 Workstations: Location and Connectivity

A password management system can easily make connections to servers, which have fixed network ad-dresses, are always on and are continuously connected to the network. It is much harder for a centralpassword management server to connect to mobile laptops, for several reasons:

• Laptops frequently move from site to site.

• Even when they remain in one place, laptop IP addresses may change dynamically, due to use ofDHCP.

• Laptops are often turned off and do not respond to network inquiries when deactivated.

• Laptops may be unplugged from the network, either to move them or for periods of disuse.

• Laptops may be protected by a firewall that blocks network connections inbound to the PC.

In short, while it is easy for laptops to contact a central server, it is nearly impossible for the reverse tohappen reliably.

To reliably secure local administrator passwords on workstations, a password management system shouldinclude technology to overcome location, connectivity, address and firewall challenges.

3.3 Scalability to Millions of Credentials

A large organization may have thousands of workstations, servers and applications. If each of these ITassets gets a new administrator password daily, the total number of passwords that must be securely



managed, including historical data, quickly grows into the millions of passwords.

Note that historical passwords need to be stored along with current ones, since in the event that a manageddevice crashes and is restored from backup media, its old password will be needed.

A scalable solution for managing administrator passwords must be able to randomize tens of thousands ofpasswords daily and to keep permanent records of millions of historical passwords.

3.4 Reliable Operation and Race Conditions

A robust system for managing administrator passwords must ensure that the password kept in its databasefor a given administrator account always matches the password on the system in question. This should betrue even if an attempt to change passwords failed in the middle of an update.

For instance, if a password management system sets a new password on an IT asset and experiences aconnection failure, it is not clear whether the new or old password is actually in effect – should the valuestored in the database be updated?

A robust system for managing administrator passwords must ensure that the password it stores in itsdatabase is always the right one – even if a fault occurred in the middle of a password update.

3.5 Fault Tolerance: Hardware, Network and Facility Problems

A password management system must be fault tolerant. If it becomes unavailable, IT workers would not beable to do their jobs – making failure of the system catastrophic.

Hardware servers, including “appliances”1 sometimes fail, due to disk crashes, power supplies burning up,etc. Network connections, especially over wide area links, also sometimes fail. Whole data centers can failas well, due to power outages, earthquakes, hurricanes, tornados, fires or floods.

If one component of a privileged access management system fails, the accounts it secures must still beavailable. This is typically accomplished by running at least two servers, ideally at different sites. Thismeans that if one server or one data center goes offline, IT staff elsewhere will be able to keep retrievingpasswords and doing their jobs.

Fault tolerance between servers and sites requires data replication between servers. Such data replicationmust take place in real-time. The alternative – scheduled, batch replication – is inadequate. Consider, forexample, a backup system that runs nightly. If a password management server were to fail just before abackup cycle begins, then the day’s new passwords would be lost. If passwords are changed daily, thecurrent administrator password for almost every system would be lost: a catastrophic event.

3.6 Encryption in Transit and Storage

Compromise of even a single privileged password represents business risk. Compromise of many privi-leged passwords may represent catastrophic business risk. Consequently, a system for securing access to

1Appliances are generally just branded x86 servers.



privileged accounts must protect these passwords cryptographically. It should protect passwords both whenthey are stored (at rest) and in transit: between users and itself, between replicated servers and betweenitself and target devices.

3.7 Connectivity and Firewalls

Networks are increasingly being segmented, to create a layered defense against intruders. This createssituations where the privileged access management system is attached to one network segment while anIT asset to which it controls access is attached to another segment.

To manage passwords on a system on the far side of a firewall, a password management system mustbe able to send password updates over the firewall. This may not be simple: many network protocols areinsecure by design (e.g., SMB for Windows, SQL*Net for Oracle, plaintext LDAP, plaintext HTTP, etc.) andare blocked by firewall administrators for good reason.

To overcome this problem, an effective password management system must be able to replace networkprotocols that are native to a given target system with its own protocol. The password management system’snetwork protocol must be appropriate to pass over a firewall.

3.8 Services and Applications

Sensitive passwords are not limited to those used by human IT workers. There are also service accounts,used to run attended software such as web servers and application passwords. There are also applicationpasswords, used by one service on one computer to authenticate itself to another service, possibly onanother computer.

On many systems, service passwords are static and application passwords are embedded in scripts, pro-grams or text files. These passwords unlock login IDs that are often just as powerful as administratoraccounts.

An effective solution for managing sensitive passwords should include mechanisms for managing serviceand application passwords, in addition to managing the administrator passwords used by IT workers. Thiscalls for two specific capabilities:

1. The ability to automatically notify one program of the new password it should use to run a secondprogram, after the password on the account used to run the second program has been randomized.

2. An API that allows one application to securely fetch a password that it can subsequently use to au-thenticate itself to another application.

3.9 Access Controls

Not every IT worker should be able to access every privileged account. Likewise, applications invoking anAPI to retrieve a password should only be able to get passwords for services to which they legitimately needto be able to connect.



To enforce such security policies, a password management system must include a flexible access controlinfrastructure, capable of determining whether a given user of the system – human or software agent –should be granted access to a given privileged account.

3.10 Audit Trails and Alerts

Every action in the password management system, including looking up assets and their passwords andchanging access control policies should be auditable. This creates a chain of accountability between usersand their actions.

It also makes sense to link auditable events to alerts. For example, if a legitimate user retrieves a givenserver’s administrator password, the owner of that server might wish to receive an e-mail about the event.

To create accountability, to meet audit requirements and to enable system owners to promptly respond toanomalous administrator activity, a privileged access management system must include detailed logs ofuser sessions, must retain its audit data indefinitely and must be able to act on, rather than just record,security events.



4 Architectural Elements

Each of the requirements set forth in the previous section can be addressed with a suitable architectural ele-ment in the password management solution. These architectural components are described in the followingsections:


A rich set of connectors should be provided, to integrate with a broad range of target system types.

4.2 Workstations: Location and Connectivity

Client software should be available, to be installed on user workstations, which periodically contacts a cen-tral cluster of password management servers and requests new passwords for locally managed accounts.

This “pull mode” approach eliminates the problems with a central server “pushing” out passwords to deviceswith intermittent connectivity and dynamic IP addresses.

4.3 Scalability to Millions of Credentials

Multiple, concurrently-active password management servers should be supported, each of which can pushnew passwords to servers and each of which can provide new passwords to workstations on demand.

As the need for scalability grows, the number of servers can be increased. Servers should be placed behinda load balancer to hide this complexity from users and workstations.

4.4 Auto-discovery and Auto-configuration of Managed Systems and Accounts

It is not feasible to manually configure thousands of devices for periodic password changes. Instead, aprivileged access management system requires an auto-discovery infrastructure to:

1. Automatically find servers and workstations.

2. Automatically find administrator and service accounts.

3. Configure systems and accounts for periodic password updates.

4. Notify software components of new service account passwords.

4.5 Reliable Operation and Race Conditions

A reliable protocol is required, especially for workstations, to confirm password updates before updatingstored passwords.



Historical passwords should be retained indefinitely. In the event that an IT asset was damaged and had tobe recovered from backup media, passwords from the date the backup was made will be available.

4.6 Fault Tolerance: Hardware, Network and Data Center Problems

As mentioned in Subsection 4.3 on Page 7, multiple servers are required. Not only should the servers eachbe able to randomize passwords in a multi-master configuration, but each server should house a completedata set and should replicate all local updates to that data to every other server.

Multiple servers should be installed in different data centers. This provides the opportunity for performancetuning, by having a local server manage passwords on local assets. It also provides for fault tolerance in theevent of a disaster at one data center. If one data center goes offline, the password management serversat other data centers can keep working and will contain a full data set.

4.7 Encryption in Transit and Storage

Design of an encryption system for a password management system revolves around key management:How are keys generated? How are keys associated with data, with servers, with end users and withmanaged devices? Key management is an advanced topic and deserves separate treatment, beyond whatthis white paper can cover. That said, some basic observations can be made:

1. Users can sign into the system with a user interface carried over HTTPS – i.e., HTTP over SSL.

2. Connections between the password management system and target servers will generally use theirnative protocols, whose security will range from strong (e.g., HTTPS, SSH or LDAPS) to weak (e.g.,SQL*Net, LDAP). External measures, such as IPSec, may be appropriate to protect communicationwith some targets.

3. Connections between workstations and the password management system may be encrypted usingHTTPS or using another key handshake protocol.

4. Connections between multiple password management servers may be encrypted using either SSL –which requires one cryptographic certificate to be purchased per server – or using symmetric serverkeys generated for each server.

4.8 Connectivity and Firewalls

In order to cross firewalls without exposing insecure protocols, the password management system musthave components on both sides of the firewall. To avoid the need to fragment password storage into onedatabase per network segment, it makes sense to provide a proxy server – i.e., a server installed on onenetwork segment whose purpose is to run connectors and update passwords on another network segment.

The communication between a primary password management server and a password management proxyserver can be a simple, encrypted protocol over an arbitrarily numbered TCP port. This is robust, secure,bandwidth efficient and easy for firewall administrators to understand and forward.



4.9 Services and Applications

4.9.1 Managing Passwords for Service Accounts

In order to manage passwords used to start services, the password management system must be able toexecute plug-in code, after successfully randomizing a password. The function of this installation-specificcode is to notify network components of the new password value.

Some plug-ins are common. For example, the Windows Service Control Manager, Scheduler and IIS webserver all store passwords in secondary storage (outside of the security database) in order to executeprocesses as named users. Since other programs may have the same requirement, the infrastructure fornotifying programs of new passwords must be extensible (hence plug-ins).

4.9.2 Managing Application Passwords

In order to manage passwords used by one application to authenticate to another, an API must be exposed,to enable applications to acquire current credentials. For example, a web application might use the APIto get a database password and use that password to connect to a database and read data which is thendisplayed in a web page.

This type of API creates a circular problem: how does an application which needs a password authenti-cate itself to the password management system? The obvious answer is that it must have its own (static)password, but this approach is clearly undesirable, as it reduces security of the application password (nowrandomized) back to a static password – but the point of a privileged access management system is pre-cisely eliminate static password.

Some options for authenticating applications to the API include:

1. Using one-time passwords. The API can return not only the desired password, but also a new pass-word which the calling application must use on for its next authentication.

2. Using environmental characteristics of the calling application. For example, a given application mayonly be allowed to sign into the API if it connects from a given IP address, or from a device running aparticular operating system version, or even from an executable with a specific checksum.

4.10 Access Controls

A simple access control model maps privileges between individual passwords and individual users. Forexample, user X is allowed to retrieve the current password for login ID Y on system Z.

As the number of systems, managed user accounts and IT users grows, this model breaks down – thereare simply too many relationships.

A more powerful model is to insert security groups between users and managed systems. Essentially usersare collected into groups (each user can belong to multiple groups) and groups are assigned privileges togroups. For example, users A, B and C belong to group G. Members of group G are allowed to retrieve thecurrent password for login ID X on system Y and login ID Z on system W.



This model may also be difficult to manage in large environments – users must be explicitly attached togroups (an administrative burden where there are many users and their responsibilities change often) andlarge numbers of managed systems must be manually attached to multiple groups.

The best model is to define both user groups and managed system policies and to define access controls(privileges) between the two. For example, users A, B and C belong to user group UG1. Managed systemsR, S and T belong to policy P1. Members of user group UG1 are allowed to connect to privileged accountson systems in policy P1.

This model provides for maximum flexibility and minimum administrative burden. It can be optimized furtherby automating association of users with user groups and managed systems with policies.

1. User membership in groups can be determined based on their identity attributes or group member-ships in a corporate directory (LDAP or Active Directory).

2. Managed system association with policies can be determined based on characteristics of the system– for example based on DNS name, IP address, hardware class, operating system, MAC address,directory OU of the system’s representative computer object, etc.

4.11 Audit Trails and Alerts

Logging is straightforward – record every event as it takes place and provide reports that are either user-centric or system-centric to show event history.



5 Hitachi ID Privileged Access Manager

Hitachi ID Privileged Access Manager is a system for securing access to privileged accounts. It works byregularly randomizing privileged passwords on workstations, servers, network devices and applications.Random passwords are encrypted and stored on at least two replicated credential vaults. Access to privi-leged accounts may be disclosed:

• To IT staff, after they have authenticated and their requests have been authorized.• To applications, replacing embedded passwords.• To Windows workstations and servers, which need them to start services.

Password changes and access disclosure are closely controlled and audited, to satisfy policy and regulatoryrequirements.

Privileged Access Manager was designed to meet the design criteria laid out in this document. It is scalable,reliable and secure.

5.1 Servers and Workstations: Push and Pull Modes

Hitachi ID Privileged Access Manager supports both server passwords, in “push mode,” and workstationpasswords, in “pull mode:”

5.1.1 Push Mode

When managing passwords on servers, Hitachi ID Privileged Access Manager normally operates in “pushmode.” This means that periodically the Privileged Access Manager server will initiate communication witheach target system, using connectors installed on the Privileged Access Manager server and randomizeprivileged passwords on that target system.

The new password(s) will be encrypted and archived in the Privileged Access Manager server’s replicatedstorage, where IT staff may retrieve them.

5.1.2 Pull Mode

When managing passwords on laptops, Hitachi ID Privileged Access Manager may be configured to oper-ate in “pull mode.” This means that a local agent is installed on each mobile PC and this agent periodicallycontacts the central Privileged Access Manager server, over HTTPS, to request new administrator pass-words.

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

Pull mode is often preferable for mobile devices because a server (i.e., Privileged Access Manager) has no



way of knowing where or when they will next be attached to the network and may be unable to initiate aconnection to the mobile device, due to firewalls, NAT, closed ports or other security measures.

Note: This feature meets the requirement described in Subsection 4.2 on Page 7.

5.2 High Availability and Data Replication

Once deployed, Hitachi ID Privileged Access Manager becomes an essential part of an organization’s ITinfrastructure, since it alone has access to privileged passwords for thousands of networked devices. Aninterruption to the availability of Privileged Access Manager or its password vault would mean that adminis-trative access to a range of devices is interrupted – a major IT service disruption.

Since servers occasionally break down, Privileged Access Manager supports load balancing and datareplication between multiple physical servers and multiple credential vaults. Any updates written to onedatabase instance are automatically replicated, in real time, over an encrypted communication path, to allother Privileged Access Manager servers and all other credential vaults.

In short, Privileged Access Manager incorporates a highly available, replicated, multi-master architecturefor both the application and the credential vault.

To provide out-of-the-box data replication, Privileged Access Manager includes a database service thatreplicates updates across multiple database instances. This service can be configured use either Oracleor Microsoft SQL Server databases for physical storage. Hitachi ID Systems recommends one physicaldatabase per Privileged Access Manager server, normally on the same hardware as the Privileged AccessManager application.

The Privileged Access Manager data replication system makes it both simple and advisable for organiza-tions to build a highly-available Privileged Access Manager server cluster, spanning multiple servers, witheach server placed in a different data center. Replication traffic is encrypted, authenticated, bandwidth-efficient and tolerant of latency, making it suitable for deployment over a WAN.

This multi-site, multi-master replication is configured at no additional cost, beyond that of the hardware foradditional Privileged Access Manager servers, and with minimal manual configuration.


5.3 Scalability

Hitachi ID Privileged Access Manager is designed to scale to support over 1,000,000 password changesper 24 hour period, in a physically and geographically replicated (i.e., high availability / disaster-proof)configuration.

This is accomplished using a number of technologies:

1. Concurrent operation by multiple Privileged Access Manager servers – i.e., a multi-master replicationmodel.



2. A multi-threaded “push-mode” service that can push out tens of thousands of new passwords toservers, routers and applications every hour.

3. A workstation service that can “pull” new passwords onto devices such as laptops at random intervals,in order to support devices unreachable from a central server while distributing server workload overthe hours of the day.

4. A data replication protocol that is tolerant of both low-bandwidth and high-latency.


5.4 Auto-discovery

In organizations with large numbers of servers or other systems (e.g., databases, routers, etc.), clearly itis desirable to auto-discover and auto-maintain a list of systems and lists of accounts to manage on eachmanaged system, rather than manually adding and maintaining thousands of separate target systems andaccounts.

To auto-discover systems, most organizations pull data from an Active Directory or LDAP directory. Com-puter objects discovered in the directory are classified based on their attributes and automatically managed(or not) and attached to appropriate managed system policies, which specify password change frequency,access control rules, access disclosure methods, etc.

A second auto-discovery process probes each managed system to find accounts that should be managed.On most systems, a list of local users and groups is generated. Specifically on Windows systems, thisprocess also lists services, scheduled jobs, IIS objects (e.g., anonymous users, application pools, etc.) andDCOM objects and see what accounts are used to run each of them. Import rules determine which of theseaccounts will be managed by Hitachi ID Privileged Access Manager (e.g., based on account attributes,group membership, security IDs, account/service relationship, etc.) and which managed system policies toassign to each managed account.

Alternatives to Active Directory- or LDAP-driven computer object lists include DNS queries or zone transfers,IP port scans of specific subnets and data imports from an inventory management system.

Privileged Access Manager also includes an automated mechanism to inform programs that store a copyof passwords of new password values. A plug-in program is provided to connect to Windows servers aftereach password change and automatically update Service Control Manager, Windows Scheduler, IIS orDCOM with new password values.

The Privileged Access Manager auto-discovery process is able to list, classify and probe over 10,000 sys-tems per hour. It is normally scheduled to run daily.

In organizations that deploy the Privileged Access Manager workstation service, there is no need to man-ually configure client devices in the Privileged Access Manager database. Instead, the workstation serviceis installed on devices through one of several means:

1. By being made a part of the standard workstation software image.

2. By being distributed through a system such as SMS.



3. By being distributed using an Active Directory Group Policy Object (AD GPO).

Once installed, the Privileged Access Manager workstation service automatically starts and registers itself,along with all local user accounts with the central Privileged Access Manager server cluster.

The software installation MSI package is constructed on the Privileged Access Manager server and includesinformation about the Privileged Access Manager server URL, what managed system policies workstationsshould be attached to, etc. This means that software installation can be fully automated and does notpresent a user interface.

A similar approach is used to deliver .tar format installation packages to Unix and Linux workstations.


5.5 Privileged Access Manager Network Architecture

The Hitachi ID Privileged Access Manager network architecture is illustrated in Figure 1.

LoadBalancer

Requestnew PWs,

GRP changes

RequestDisclosure

TCP/IP + AES

HTTPS

IT UserPCs

ManagedLaptops(mobile)

HiPAM proxy

D.C. 3

TargetSystems

D.C. 2

Replicated Updates

Probe systems,

Randomize PWs

Assign GRPs

Single sign-on:

RDP, SSH, SQL, etc.

TargetSystems

Data Center 1

TargetSystems

Various Protocols

Workstation Service

Replicated, distributedHitachi ID Privileged Access ManagerServersProbe systems,

Randomize PWs

Assign GRPs

Run connectors

locally

Corporate WAN Firewall

Download app-launch ActiveX.

Upload session capture

Figure 1: Privileged Access Manager Network Architecture Diagram


Pull mode agents, installed locally on devices and scalable to thousands of devices, are provided for:



1. Windows 2000 and XP workstations.

2. Windows Vista and Windows 7 workstations.

3. Windows 2000, Windows 2003 and Windows 2008 servers.

4. Unix and Linux servers and workstations.

Plugins are currently provided to update passwords, after randomization, in:

• The Windows Service Control Manager.

• The Windows Scheduler.

• The IIS Web Server.

Note: This feature meets the requirement described in Subsubsection 4.9.1 on Page 9.

Push mode agents, installed on the Hitachi ID Privileged Access Manager server itself and scalable tothousands of devices, are provided for:

Directories: Servers: Databases:

Any LDAP, AD, NDS,eDirectory, NIS/NIS+.

Windows 2000–2012,Samba, NDS, SharePoint.

Oracle, Sybase, SQL Server,DB2/UDB, ODBC, Informix.

Unix: Mainframes: Midrange:

Linux, Solaris, AIX, HPUX,24 more variants.

z/OS with RAC/F, ACF/2 orTopSecret.

iSeries (OS400), OpenVMS.

ERP: Collaboration: Tokens, Smart Cards:

JDE, Oracle eBiz,PeopleSoft, SAP R/3, SAPECC 6, Siebel, BusinessObjects.

Lotus Notes, Exchange,GroupWise, BlackBerry ES.

RSA SecurID, SafeWord,RADIUS, ActivIdentity,Schlumberger.

WebSSO: Help Desk: HDD Encryption:

CA Siteminder, IBM TAM,Oracle AM, RSA AccessManager.

BMC Remedy, BMC SDE,ServiceNow, HP ServiceManager, CA Unicenter,Assyst, HEAT, Altiris, Clarify,Track-It!, RSA Envision, MSSCS Manager.

McAfee, CheckPoint,BitLocker, PGP.

SaaS: Miscellaneous: Extensible:

Salesforce.com, WebEx,Google Apps, MS Office365, SOAP (generic).

OLAP, Hyperion, iLearn,Caché, Success Factors,VMWare vSphere.

SSH, Telnet, TN3270,HTTP(S), SQL, LDAP,command-line.




5.7 Proxies to Cross Firewalls

In some cases, the connection to a target system may be slow, insecure or simply blocked by a firewall.This is often true when the connection is made over a wide area network or requires the use of an insecureprotocol but must cross an untrusted network segment.

To address such connectivity problems, Hitachi ID Privileged Access Manager includes an application proxyserver. When a proxy server is deployed, the main Privileged Access Manager server ceases to commu-nicate with one or more (usually distant) target systems directly and instead forwards all communication tothose systems through one or more proxy servers, which are co-located with the target systems in question.

Communication from the main Privileged Access Manager server to the proxy server(s) is encrypted, effi-cient and tolerant of high latency. It uses a single, arbitrarily-numbered TCP port number. Connections arestrictly from the main Privileged Access Manager server to the proxy server (never back). A single TCP portsupports an arbitrarily large number of target systems at the proxy server’s location.

These characteristics of the communication between a Privileged Access Manager main server and a proxyserver mean that firewall administrators will normally be willing and will always be technically able to routeor forward a TCP port from the main server IP address to the proxy server IP address.

Communication between the proxy server and target systems continues to use native protocols. It is nor-mally physically secured, in a high-bandwidth, low-latency, high-security data center network.

Deployment of the secure Privileged Access Manager proxy server is illustrated in Figure 2.

Firewall

Remote Network

Firewall

Local Network

Target Systems

PossibleIntruder

Native protocol:

Slow?

Plaintext?

Blocked by firewall?

Fast, secure

protocol

TCP/IP + 128-bit Crypto

Various Protocols

Hitachi IDManagement Suite

Hitachi IDProxy Server

Figure 2: Target systems connected through a proxy server




5.8 Access Controls

The most common form of access control in the Hitachi ID Privileged Access Manager is based on managedsystem policies. These policies are named collections of managed systems containing privileged accountswhose passwords may be randomized and access to which is controlled.

Managed systems may either be attached to a policy explicitly (e.g., “attach workstation WKSTN01234 topolicy RGWKSTNS”) or implicitly, using an expression. Expressions may be based on the operating systemtype, IP address, MAC address or workstation name (e.g., “attach every workstation running Windows XPin subnet 10.1.2.3/24 to policy X”)

Managed system policies are configured with operational and access control rules, including:

1. Which accounts’ passwords to randomize on attached systems.

2. How often to change passwords.

3. How to compose random passwords (e.g., length, complexity, etc.).

4. What actions to take after successful or failed attempts to disclose a password.

5. What access disclosure methods to offer users who wish to sign into privileged accounts on attachedsystems (e.g., launch remote desktop, launch SSH, temporarily place user in security groups, displaycurrent password to user, etc.).

Privileged Access Manager users are organized into user groups, either explicitly or implicitly. In a typicaldeployment, users are assigned to Privileged Access Manager user groups by virtue of their membership inActive Directory or LDAP groups. Groups of users are then assigned specific rights with respect to specificmanaged system policies. For example, “every user in group A may launch RDP sessions to privilegedaccounts on systems in policy B.”

Business rules, such as segregation of duties between different sets of users, can also be enforced. Thisis done by examining, managing and limiting group membership on reference systems, such as ActiveDirectory or LDAP, that can be simultaneously assigned to the same user.


5.9 Application Programming Interface (API)

Hitachi ID Privileged Access Manager includes an API that enables applications to disclose passwords andeliminates the storage of static, plaintext passwords. Privileged Access Manager periodically randomizesservice passwords, while applications use the API to retrieve passwords as/when required.

The Privileged Access Manager API is accessed using SOAP over HTTPS.

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



An important design consideration when implementing a privileged password retrieval API is how the clientwhich requests password disclosure (the web application in the above example) authenticates itself tothe API service. Privileged Access Manager secures this process with a combination of ACLs, one-timepasswords and IP subnets:

1. API clients have their own IDs, used to sign into Privileged Access Manager.

2. These IDs are attached to console user groups and assigned ACLs, allowing them to disclose somepasswords but not others.

3. API client login IDs are assigned one-time passwords (OTPs). In effect, the password used by theclient software to sign into the Privileged Access Manager API changes to a new, random string oneach API connection.

4. API client login IDs are bound to IP subnets. An API client can only sign into the API service from agiven IP range.

Wrapper code is provided for the SOAP API for a variety of platforms / programming languages, such as.NET, Java, Linux/C, etc. This wrapper code manages several functions:

1. Storing the one time password (OTP) used to authenticate to the API.

2. Serializing access to the API, to support use of the OTP.

3. Keeping cached copies of passwords previously retrieved from the API, along with data about howlong to retain those copies and how long they should be assumed to be valid. This makes the systemmore performant (due to less frequent API calls) and more reliable (continued operation even if theAPI is temporarily unavailable).

4. Encrypting the above, sensitive data so that it’s not visible – even to locally privileged users.

Encryption of the OTP and of cached passwords implies an encryption key. The API wrappers support avariety of methods to produce this key, including:

1. A static key (e.g., embedded into the application or configuration file) – useful during development ordebugging.

2. A key generated from characteristics of the machine on which the application runs, such as its MACaddresses, IP addresses, hostname, etc.

3. A key generated from characteristics of the program which is calling the API (i.e., a cryptographichash of the program itself).

Hitachi ID Systems is happy to add platform bindings for this wrapper code based on customer demand(i.e., we add support for the programming language and runtime that customers need as required, andusually at no additional cost).

This wrapper is also provided in command-line form, suitable for retrieving passwords efficiently and se-curely from Privileged Access Manager (with local, encrypted caching) and injecting those passwords onthe command-line, into configuration files or into the input of scripts.



Note: This feature meets the requirement described in Subsubsection 4.9.2 on Page 9.

5.10 Reliable Password Changes and History

Error checking is implemented to guard against a password being set before the Hitachi ID PrivilegedAccess Manager server is able to store the password value – i.e., a workstation or server can never get anew password for a privileged account while Privileged Access Manager is unable to store the password.

Consider a laptop on which the local Privileged Access Manager service determines that the time has cometo change passwords:

If it simply changes passwords and then attempts to contact a central server to upload the new value, it maynot manage to connect to Privileged Access Manager and consequently must either undo the passwordchange or store the new password and periodically test for connectivity, in the hopes that the new passwordcan be uploaded before anyone needs to use it.

To avoid this problem, Privileged Access Manager’s “pull mode” mode of operation (used on laptops) worksas follows:

1. First, the laptop service connects to Privileged Access Manager and asks it to generate a new, randompassword for a privileged account.

2. The laptop service then changes the password in the local security database and sends a confirmationmessage to Privileged Access Manager.

3. Privileged Access Manager updates the password in its vault and replicates the update to all otherPrivileged Access Manager servers.

In the event that the Privileged Access Manager server did not receive a confirmation message – for exam-ple in the event that the workstation was suddenly turned off or disconnected – it will retain both the old andnew passwords. The new password is assumed to be current and the old password is archived.

In practice, as a fail-safe, all old passwords are retained in the vault. This is not only to support a fail-safepassword change process, but also to be able to retrieve old password values in the event that a managedsystem is restored from archive media in the future.


5.11 Cryptographic Protection

Hitachi ID Privileged Access Manager makes extensive use of cryptography:

1. A built-in key is used to encrypt a master key, which is stored in the registry of each Privileged AccessManager server.

2. Each site has a unique master key, used to encrypt local data.



3. Each “pull-mode” device has its own key, acquired at installation time and used to authenticate andprotect communication between that device and Privileged Access Manager servers.

4. Privileged Access Manager servers use an encrypted TCP/IP based protocol to protect data replica-tion traffic amongst themselves.

5. User access to Privileged Access Manager is via HTTPS, which uses SSL encryption.

6. Communication between the workstation service, used to implement pull mode and Privileged AccessManager servers is likewise via HTTPS.

All symmetric encryption uses 128-bit AES.


5.12 Logging and Reports

Hitachi ID Privileged Access Manager logs and can report on every disclosure of access to every privilegedaccount. This means that the time interval during which a user was connected to a privileged account orduring which a password was disclosed to a program or person is always recorded, is retained definitelyand is visible in reports.

Privileged Access Manager also logs all attempts by users to search for managed systems and to connectto privileged accounts, even if login attempts were denied. This means that even rejected attempts andrequests to access privileged accounts are visible in reports.

Privileged Access Manager also logs auto-discovery and auto-configuration process status as well as man-ual changes to its own configuration. This means that the health of systems on the network can be inferredfrom Privileged Access Manager reports.

Exit traps can be used to forward copies of Privileged Access Manager log entries to another system (e.g.,an SIEM, typically via SYSLOG) for analytics and tamper-proof archive.

In addition to logging user access to sensitive passwords, Privileged Access Manager can produce reports,in HTML or CSV format, directly on the web user interface or delivered via e-mail, enumerating such accessby user or by managed system.

Privileged Access Manager includes over 189 exit points.

Exit points may be triggered by many events, including:

• Attempts to sign into Privileged Access Manager (successful or failed).• One user looking up the profile of another.• Changes to a user’s profile, such as creating a new account or changing attributes or group member-

ships for an existing account.• Assigning a role to a user or removing a user from a role; changing Privileged Access Manager’s

configuration.• Running a report.



• Triggering an intruder lockout.

Example uses of exit points include sending e-mails to users or administrators and creating, updating orclosing incident records in an incident management application, notifying an IT infrastructure managementsystem of an integration problem or recording a security event to a security incident event management(SIEM) or intrusion detection (IDS) system.

Various pre-built interface programs designed for use with exit points are included with Privileged AccessManager. They are generally scriptable and simplify the process of creating help desk incidents (e.g., BMCRemedy, HP Service Manager and the like) and sending e-mails.

For clarity, it should be noted that exit programs and plug-in programs in Privileged Access Manager aredistinct components that serve different functions. Whereas plug-in programs are bidirectional – PrivilegedAccess Manager sends data to the plug-in, the plug-in responds with data that alters Privileged AccessManager’s behavior – exit programs are uni-directional and are used strictly to pass information outboundfrom Privileged Access Manager to other applications. .


5.13 Learn More

Learn more about Hitachi ID Privileged Access Manager at http://Hitachi-ID.com/Privileged-Access-Manager/.

Learn more about Hitachi ID Systems at http://Hitachi-ID.com/.

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/privileged-password-management/privileged-access-management-4.texDate: 2011-03-02

http://Hitachi-ID.com/Privileged-Access-Manager/



secure management of privileged passwords

Technology

hp service

privileged

access control

user group

local administrator

managing administrator

access disclosure

data center