Secure Management of Access to Privileged Accounts

Secure Management

of Access to Privileged Accounts using Hitachi ID Privileged Access Manager

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

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

Passwords for privileged accounts are used to install software, manage the device and perform technical support 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 identifies technical 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.1

Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 5.1

11

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

5.5

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

5.6

Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.7

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

5.8

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

5.9

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

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.

Secure Management of Access to Privileged Accounts

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, one password 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 an upgrade 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 administrative changes to individual IT staff. If an administrator makes a change to a system that causes a malfunction, 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 coordinate password changes. As a result, privileged passwords are rarely changed and are often known to ex-employees.

These problems create security vulnerabilities. For example, if administrator passwords don’t change, then former 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 HIPAA and GLB, as well as legislation regarding corporate governance such as SOX, requires that systems containing sensitive data be secured against unauthorized access. Effective management of access to privileged accounts is therefore not an option, but a requirement.

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

1

Secure Management of Access to Privileged Accounts

2 A Simple Solution: Randomize Passwords The obvious way to eliminate static and shared privileged passwords is to change them regularly. If every sensitive 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 solution. 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 to password values or to the underlying accounts, can be complex. The following section describes some of the technical challenges that must be overcome in order to successfully deploy such a solution.

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

2

Secure Management of Access to Privileged Accounts

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 and fail-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 used in the normal course of business to manage the device, since a local administrator password must be used to 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 applications, midrange servers (iSeries, VMS, etc.), mainframe computers, directories and more. In short, every device 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 addresses, are always on and are continuously connected to the network. It is much harder for a central password 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 of DHCP. • 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 to happen reliably.

To reliably secure local administrator passwords on workstations, a password management system should include 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 IT assets gets a new administrator password daily, the total number of passwords that must be securely © 2014 Hitachi ID Systems, Inc.. All rights reserved.

3

Secure Management of Access to Privileged Accounts

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 managed device 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 of passwords 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 database for a given administrator account always matches the password on the system in question. This should be true 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 a connection failure, it is not clear whether the new or old password is actually in effect – should the value stored in the database be updated?

A robust system for managing administrator passwords must ensure that the password it stores in its database 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 be able 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 fail as 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 be available. This is typically accomplished by running at least two servers, ideally at different sites. This means that if one server or one data center goes offline, IT staff elsewhere will be able to keep retrieving passwords and doing their jobs.

Fault tolerance between servers and sites requires data replication between servers. Such data replication must take place in real-time. The alternative – scheduled, batch replication – is inadequate. Consider, for example, a backup system that runs nightly. If a password management server were to fail just before a backup cycle begins, then the day’s new passwords would be lost. If passwords are changed daily, the current 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 privileged passwords may represent catastrophic business risk. Consequently, a system for securing access to 1 Appliances

are generally just branded x86 servers.

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

4

Secure Management of Access to Privileged Accounts

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

3.7 Connectivity and Firewalls Networks are increasingly being segmented, to create a layered defense against intruders. This creates situations where the privileged access management system is attached to one network segment while an IT 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 must be able to send password updates over the firewall. This may not be simple: many network protocols are insecure by design (e.g., SMB for Windows, SQL*Net for Oracle, plaintext LDAP, plaintext HTTP, etc.) and are blocked by firewall administrators for good reason.

To overcome this problem, an effective password management system must be able to replace network protocols that are native to a given target system with its own protocol. The password management system’s network 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 application passwords, used by one service on one computer to authenticate itself to another service, possibly on another computer.

On many systems, service passwords are static and application passwords are embedded in scripts, programs or text files. These passwords unlock login IDs that are often just as powerful as administrator accounts.

An effective solution for managing sensitive passwords should include mechanisms for managing service and application passwords, in addition to managing the administrator passwords used by IT workers. This calls for two specific capabilities: 1. The ability to automatically notify one program of the new password it should use to run a second program, 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 authenticate itself to another application.

3.9 Access Controls Not every IT worker should be able to access every privileged account. Likewise, applications invoking an API to retrieve a password should only be able to get passwords for services to which they legitimately need to be able to connect.

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

5

Secure Management of Access to Privileged Accounts

To enforce such security policies, a password management system must include a flexible access control infrastructure, 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 and changing access control policies should be auditable. This creates a chain of accountability between users and their actions.

It also makes sense to link auditable events to alerts. For example, if a legitimate user retrieves a given server’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 to anomalous administrator activity, a privileged access management system must include detailed logs of user sessions, must retain its audit data indefinitely and must be able to act on, rather than just record, security events.

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

6

Secure Management of Access to Privileged Accounts

4 Architectural Elements Each of the requirements set forth in the previous section can be addressed with a suitable architectural element in the password management solution. These architectural components are described in the following sections:

4.1 Platform Support 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 central 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 devices with 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 push new 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 behind a 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, a privileged 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 updating stored passwords. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

7

Secure Management of Access to Privileged Accounts

Historical passwords should be retained indefinitely. In the event that an IT asset was damaged and had to be 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 each be able to randomize passwords in a multi-master configuration, but each server should house a complete data 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 performance tuning, by having a local server manage passwords on local assets. It also provides for fault tolerance in the event of a disaster at one data center. If one data center goes offline, the password management servers at 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 with managed devices? Key management is an advanced topic and deserves separate treatment, beyond what this 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 their native 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 communication with some targets.

3. Connections between workstations and the password management system may be encrypted using HTTPS 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 server keys generated for each server.

4.8 Connectivity and Firewalls In order to cross firewalls without exposing insecure protocols, the password management system must have components on both sides of the firewall. To avoid the need to fragment password storage into one database per network segment, it makes sense to provide a proxy server – i.e., a server installed on one network 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 proxy server 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.

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

8

Secure Management of Access to Privileged Accounts

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 to execute plug-in code, after successfully randomizing a password. The function of this installation-specific code 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 web server all store passwords in secondary storage (outside of the security database) in order to execute processes as named users. Since other programs may have the same requirement, the infrastructure for notifying 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 API to get a database password and use that password to connect to a database and read data which is then displayed in a web page.

This type of API creates a circular problem: how does an application which needs a password authenticate 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 (now randomized) back to a static password – but the point of a privileged access management system is precisely 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 password which the calling application must use on for its next authentication.

2. Using environmental characteristics of the calling application. For example, a given application may only be allowed to sign into the API if it connects from a given IP address, or from a device running a particular 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. For example, 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 – there are simply too many relationships.

A more powerful model is to insert security groups between users and managed systems. Essentially users are collected into groups (each user can belong to multiple groups) and groups are assigned privileges to groups. For example, users A, B and C belong to group G. Members of group G are allowed to retrieve the current password for login ID X on system Y and login ID Z on system W. Š 2014 Hitachi ID Systems, Inc.. All rights reserved.

9

Secure Management of Access to Privileged Accounts

This model may also be difficult to manage in large environments – users must be explicitly attached to groups (an administrative burden where there are many users and their responsibilities change often) and large 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 systems R, S and T belong to policy P1. Members of user group UG1 are allowed to connect to privileged accounts on systems in policy P1.

This model provides for maximum flexibility and minimum administrative burden. It can be optimized further by 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 memberships 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 usercentric or system-centric to show event history.

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

10

Secure Management of Access to Privileged Accounts

5 Hitachi ID Privileged Access Manager Hitachi ID Privileged Access Manager is a system for securing access to privileged accounts. It works by regularly 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 privileged 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 regulatory requirements.

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 workstation passwords, in “pull mode:”

5.1.1 Push Mode When managing passwords on servers, Hitachi ID Privileged Access Manager normally operates in “push mode.” This means that periodically the Privileged Access Manager server will initiate communication with each target system, using connectors installed on the Privileged Access Manager server and randomize privileged passwords on that target system.

The new password(s) will be encrypted and archived in the Privileged Access Manager server’s replicated storage, 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 operate in “pull mode.” This means that a local agent is installed on each mobile PC and this agent periodically contacts the central Privileged Access Manager server, over HTTPS, to request new administrator passwords.

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 Access Manager 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

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

11

Secure Management of Access to Privileged Accounts

way of knowing where or when they will next be attached to the network and may be unable to initiate a connection 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 IT infrastructure, since it alone has access to privileged passwords for thousands of networked devices. An interruption to the availability of Privileged Access Manager or its password vault would mean that administrative 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 data replication between multiple physical servers and multiple credential vaults. Any updates written to one database instance are automatically replicated, in real time, over an encrypted communication path, to all other Privileged Access Manager servers and all other credential vaults.

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

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

The Privileged Access Manager data replication system makes it both simple and advisable for organizations to build a highly-available Privileged Access Manager server cluster, spanning multiple servers, with each server placed in a different data center. Replication traffic is encrypted, authenticated, bandwidthefficient 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 for additional Privileged Access Manager servers, and with minimal manual configuration.

Note:

This feature meets the requirement described in Subsection 4.6 on Page 8.

5.3 Scalability Hitachi ID Privileged Access Manager is designed to scale to support over 1,000,000 password changes per 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 replication model. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

12

Secure Management of Access to Privileged Accounts

2. A multi-threaded “push-mode” service that can push out tens of thousands of new passwords to servers, 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 over the hours of the day.

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

Note:

This feature meets the requirement described in Subsection 4.3 on Page 7.

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

To auto-discover systems, most organizations pull data from an Active Directory or LDAP directory. Computer 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, this process also lists services, scheduled jobs, IIS objects (e.g., anonymous users, application pools, etc.) and DCOM objects and see what accounts are used to run each of them. Import rules determine which of these accounts 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 to assign 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 copy of passwords of new password values. A plug-in program is provided to connect to Windows servers after each password change and automatically update Service Control Manager, Windows Scheduler, IIS or DCOM with new password values.

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

In organizations that deploy the Privileged Access Manager workstation service, there is no need to manually configure client devices in the Privileged Access Manager database. Instead, the workstation service is 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

13

Secure Management of Access to Privileged Accounts

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 includes information about the Privileged Access Manager server URL, what managed system policies workstations should be attached to, etc. This means that software installation can be fully automated and does not present a user interface.

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

Note:

This feature meets the requirement described in Subsection 4.4 on Page 7.

5.5 Privileged Access Manager Network Architecture The Hitachi ID Privileged Access Manager network architecture is illustrated in Figure 1. tc. : -on L, e ign , SQ s gle SH Sin DP, S R

IT User PCs Managed Laptops (mobile)

Target Systems

P R rob D As ando e sys sig mi tem Up ownl n G ze loa oad RP PW s, ds Da s s ess appRe ion laun ta Dis que c c C ap h A clo st ent tur sur R e ctive e er X. new eque 1 st GR P P c Ws han , ges Load

Balancer

HiPAM proxy

s, s em yst ze PW s Ps be mi Pro ando n GR R ssig A R loc un co ally nn

ect

ors

D.C

Co rpo rate WA N

Replicated, distributed Hitachi ID Privileged Access Manager Servers

tes da

p dU

Firewall

D.C Target Systems

Target Systems

ate

plic Re

.2 TCP/IP + AES HTTPS Various Protocols

.3

Workstation Service

Figure 1: Privileged Access Manager Network Architecture Diagram

5.6 Platform Support Pull mode agents, installed locally on devices and scalable to thousands of devices, are provided for: Š 2014 Hitachi ID Systems, Inc.. All rights reserved.

14

Secure Management of Access to Privileged Accounts

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 to thousands 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 or TopSecret.

iSeries (OS400), OpenVMS.

ERP:

Collaboration:

Tokens, Smart Cards:

JDE, Oracle eBiz, PeopleSoft, SAP R/3, SAP ECC 6, Siebel, Business Objects.

Lotus Notes, Exchange, GroupWise, BlackBerry ES.

RSA SecurID, SafeWord, RADIUS, ActivIdentity, Schlumberger.

WebSSO:

Help Desk:

HDD Encryption:

CA Siteminder, IBM TAM, Oracle AM, RSA Access Manager.

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

McAfee, CheckPoint, BitLocker, PGP.

SaaS:

Miscellaneous:

Extensible:

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

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

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

Note:

This feature meets the requirement described in Subsection 4.1 on Page 7.

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

15

Secure Management of Access to Privileged Accounts

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 insecure protocol but must cross an untrusted network segment.

To address such connectivity problems, Hitachi ID Privileged Access Manager includes an application proxy server. When a proxy server is deployed, the main Privileged Access Manager server ceases to communicate with one or more (usually distant) target systems directly and instead forwards all communication to those 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, efficient and tolerant of high latency. It uses a single, arbitrarily-numbered TCP port number. Connections are strictly from the main Privileged Access Manager server to the proxy server (never back). A single TCP port supports 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 proxy server mean that firewall administrators will normally be willing and will always be technically able to route or 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 normally 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.

Hitachi ID Management Suite Firewall

c Lo

al

tw Ne

ure ec l s , o st Fa rotoc p

Possible Intruder

ork ol: oc t o ll? pr wa ve e i r t Na low? text? by fi S lain ked P lo c B

Re

Firewall

Hitachi ID Proxy Server

te mo

Target Systems

N

ork w et

TCP/IP + 128-bit Crypto Various Protocols

Figure 2: Target systems connected through a proxy server Note:

This feature meets the requirement described in Subsection 4.8 on Page 8.

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

16

Secure Management of Access to Privileged Accounts

5.8 Access Controls The most common form of access control in the Hitachi ID Privileged Access Manager is based on managed system policies. These policies are named collections of managed systems containing privileged accounts whose 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 to policy 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 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 attached systems (e.g., launch remote desktop, launch SSH, temporarily place user in security groups, display current password to user, etc.).

Privileged Access Manager users are organized into user groups, either explicitly or implicitly. In a typical deployment, users are assigned to Privileged Access Manager user groups by virtue of their membership in Active Directory or LDAP groups. Groups of users are then assigned specific rights with respect to specific managed system policies. For example, “every user in group A may launch RDP sessions to privileged accounts on systems in policy B.” Business rules, such as segregation of duties between different sets of users, can also be enforced. This is done by examining, managing and limiting group membership on reference systems, such as Active Directory or LDAP, that can be simultaneously assigned to the same user.

Note:

This feature meets the requirement described in Subsection 4.10 on Page 9.

5.9 Application Programming Interface (API) Hitachi ID Privileged Access Manager includes an API that enables applications to disclose passwords and eliminates the storage of static, plaintext passwords. Privileged Access Manager periodically randomizes service 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 into Privileged Access Manager with their own credentials (see below) and retrieve the current Oracle login password. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

17

Secure Management of Access to Privileged Accounts

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. Privileged Access 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 Privileged Access Manager.

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

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

4. API client login IDs are bound to IP subnets. An API client can only sign into the API service from a given 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 how long to retain those copies and how long they should be assumed to be valid. This makes the system more performant (due to less frequent API calls) and more reliable (continued operation even if the API 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 a variety of methods to produce this key, including: 1. A static key (e.g., embedded into the application or configuration file) – useful during development or debugging.

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

3. A key generated from characteristics of the program which is calling the API (i.e., a cryptographic hash 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, and usually at no additional cost).

This wrapper is also provided in command-line form, suitable for retrieving passwords efficiently and securely from Privileged Access Manager (with local, encrypted caching) and injecting those passwords on the command-line, into configuration files or into the input of scripts. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

18

Secure Management of Access to Privileged Accounts

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 Privileged Access Manager server is able to store the password value – i.e., a workstation or server can never get a new 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 come to change passwords: If it simply changes passwords and then attempts to contact a central server to upload the new value, it may not manage to connect to Privileged Access Manager and consequently must either undo the password change or store the new password and periodically test for connectivity, in the hopes that the new password can be uploaded before anyone needs to use it.

To avoid this problem, Privileged Access Manager’s “pull mode” mode of operation (used on laptops) works as follows: 1. First, the laptop service connects to Privileged Access Manager and asks it to generate a new, random password for a privileged account.

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

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

In the event that the Privileged Access Manager server did not receive a confirmation message – for example in the event that the workstation was suddenly turned off or disconnected – it will retain both the old and new 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-safe password change process, but also to be able to retrieve old password values in the event that a managed system is restored from archive media in the future.

Note:

This feature meets the requirement described in Subsection 4.5 on Page 7.

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 Access Manager server.

2. Each site has a unique master key, used to encrypt local data. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

19

Secure Management of Access to Privileged Accounts

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

4. Privileged Access Manager servers use an encrypted TCP/IP based protocol to protect data replication 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 Access Manager servers is likewise via HTTPS. All symmetric encryption uses 128-bit AES.

Note:

This feature meets the requirement described in Subsection 4.7 on Page 8.

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

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

Privileged Access Manager also logs auto-discovery and auto-configuration process status as well as manual changes to its own configuration. This means that the health of systems on the network can be inferred from 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 access by 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 memberships 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.

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

20

Secure Management of Access to Privileged Accounts

• Triggering an intruder lockout.

Example uses of exit points include sending e-mails to users or administrators and creating, updating or closing incident records in an incident management application, notifying an IT infrastructure management system 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 Access Manager. They are generally scriptable and simplify the process of creating help desk incidents (e.g., BMC Remedy, 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 are distinct components that serve different functions. Whereas plug-in programs are bidirectional – Privileged Access Manager sends data to the plug-in, the plug-in responds with data that alters Privileged Access Manager’s behavior – exit programs are uni-directional and are used strictly to pass information outbound from Privileged Access Manager to other applications. .

Note:

This feature meets the requirement described in Subsection 4.11 on Page 10.

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/.

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com

www.Hitachi-ID.com

File: /pub/wp/documents/privileged-password-management/privileged-access-mana Date: 2011-03-02