Securing Privileged Accounts with Hitachi ID Privileged Access Manager

Securing Privileged Accounts

with Hitachi ID Privileged Access Manager

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

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.

Contents 1 Privileged Access Management

1

2 Technical Challenges

2

3 Functional Requirements

3

4 Randomizing Privileged Passwords

4

5 Access Disclosure

5

5.1

Frequent Users: Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

5.2

Occasional Users: Workflow Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

5.3

Concurrency Controls – Checkin/Checkout . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

5.4

Alternatives to Password Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

5.5

API for Progammatic Access Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

5.6

Updates to Service Passwords

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Strong Authentication

12

7 Auditing and Regulatory Compliance

13

8 Hitachi ID Privileged Access Manager Architecture

14

8.1

Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8.2

Push and Pull Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

8.3

Hitachi ID Privileged Access Manager Host Platform . . . . . . . . . . . . . . . . . . . . . . 15

8.4

Supported Target System Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

i

Securing Privileged Accounts With Privileged Access Manager

1 Privileged Access Management 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.

Hitachi ID Privileged Access Manager secures privileged accounts on an enterprise scale: • It periodically randomizes every privileged password.

• Users must sign into Privileged Access Manager when they need to use a privileged account. Multifactor authentication can be required.

• Privileged Access Manager launches login sessions on behalf of users, without displaying passwords – single sign-on.

• Logins to privileged user accounts can be recorded, including screen capture and keyboard logging.

This creates strong accountability and forensic audit trails.

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

1

Securing Privileged Accounts With Hitachi ID Privileged Access Manager

2 Technical Challenges The obvious solution to the security vulnerability of static and shared privileged passwords is to change these passwords so that each one is unique and changes regularly. Doing this can be technically challenging, however: • There are thousands of privileged passwords: Clearly automation is required to manage them.

• There are passwords on many kinds of systems: The automation must include many integrations, with different kinds of systems (Windows, Unix, SAP, mainframe, Oracle, etc.).

• The majority of privileged passwords are on PCs and laptops.

Workstation passwords present special challenges: – Workstations may be powered down.

– Workstations may be disconnected from the network.

– Workstations may not be reachable from a central data center because they are behind firewalls.

• Connectivity to servers.

– Servers may not be up 100% of the time.

– Servers may not be reachable from a single data center network segment. Specifically, they may be on different network segments, blocked off from the password management system by one or more firewalls.

• Secure, reliable storage.

Once automation is implemented to regularly change passwords, technical challenges regarding their storage must be addressed. The password storage system must: – Be secure. An insecure storage system, if compromised, would allow an intruder to gain administrative access to every device in the IT infrastructure.

– Be reliable. A disk crash or facility interruption affecting the password storage system would make every administrator ID unavailable.

– Include fine-grained access controls. Only the right administrators should get access to the right passwords, after proving their identity.

– Log access disclosure. Access to privileged accounts must be logged, to create accountability.

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

2

Securing Privileged Accounts With Hitachi ID Privileged Access Manager

3 Functional Requirements A privileged access management system needs a set of well-integrated features to function: 1. It must randomize passwords regularly – sensitive passwords should be unique and short-lived.

2. It must be able to disclose passwords to or inject passwords into sessions on behalf of appropriate users and software agents, but only under the right circumstances: (a) To IT staff, if they have been assigned appropriate access rights. (b) To IT staff who have not been assigned permanent access rights, but have been granted onetime permission. (c) To programs that start services (Windows Service Control Manager, Scheduler, IIS and others) so that they can start services after a password change. (d) To applications, to replace embedded passwords in programs and scripts.

3. Both a static access control model and a dynamic authorization workflow are required.

4. The system must log both password updates and disclosure. Failed updates can be used to identify infrastructure problems while logs of access disclosure create accountability.

5. The system should be able to control concurrent disclosure of a given password – for example to limit the number of people concurrently able to manage a server.

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

3

Securing Privileged Accounts With Privileged Access Manager

4 Randomizing Privileged Passwords Hitachi ID Privileged Access Manager secures sensitive passwords by periodically randomizing them: 1. On push-mode servers and applications: (a) Periodically – for example, every night between 3AM and 4AM. (b) When users check passwords back in, after they are finished using them. (c) When users request a specific password value. (d) In the event of an urgent termination of a system administrator.

2. On pull-mode laptops and similarly configured devices: (a) Periodically – for example, every day. (b) At a random time-of-day, to prevent transaction bursts. (c) Opportunistically, whenever network connectivity happens to be available from the workstation to a central server.

Privileged Access Manager can enforce multiple password policies. There is a global password policy as well as sets of password rules in each managed system policy.

Password policies specify the complexity of both randomly chosen and manually selected passwords. In addition to mandating character types (lowercase, uppercase, digits, punctuation), the policy can specify minimum and maximum password lengths, prohibit the use of dictionary words, etc. These features are relevant to manually-chosen passwords.

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

4

Securing Privileged Accounts With Privileged Access Manager

5 Access Disclosure Hitachi ID Privileged Access Manager is designed to not only randomize and securely store privileged passwords, but also to connect users and programs to privileged accounts after appropriate authentication and authorization. It includes the following access disclosure capabilities: 1. To users, via a web interface, subject to access control policy.

2. To users who do not have pre-authorized access rights, after approval.

3. To applications, in order to replace embedded passwords, using an API (application programming interface) where applications authenticate using an OTP (one time password) and may only connect from a pre-defined range of IP addresses.

4. To service launching programs, such as the Windows Service Control Manager, by writing new password values to the appropriate locations after a successful password change.

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

5.1 Frequent Users: 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved.

5

Securing Privileged Accounts With Privileged Access Manager

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.

5.2 Occasional Users: Workflow Approval Hitachi ID Privileged Access Manager includes the same authorization workflow engine as is used in Hitachi ID Identity Manager. Workflow enables users to request access to a privileged account that was not previously or permanently authorized. When this happens, one or more additional users are invited (via e-mail or SMS) to review and approve the request. Approved requests trigger a message to the request’s recipient, including a URL to Privileged Access Manager where he or she can re-authenticate and “check out” access.

The workflow process is illustrated by the following series of steps: 1. User UA signs in and requests that the then-current password to login account LA on system S be made available to user UB at some later time T. UA may or may not be the same person as UB. 2. Privileged Access Manager looks up authorizers associated with LA on S. 3. Privileged Access Manager may run business logic to supplement this authorizer list, for example with someone in the management chain for UA or UB. The final list of authorizers is LA. There are N authorizers but approval by just M (M ≤ N) is sufficient to disclose the password to AZ. 4. Privileged Access Manager sends e-mail invitations to authorizers LA. 5. If authorizers fail to respond, they get automatic reminder e-mails.

6. If authorizers continue to fail to respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request and invites the replacement authorizers as well.

7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Privileged Access Manager web login page, review the request and approve or reject it.

8. If any authorizers reject the request, e-mails are sent to all participants (UA, UB and AZ) and the request is terminated.

9. If M authorizers approve the request, thank-you e-mails are sent to all participants. A special e-mail is sent to the recipient – UB with a URL to an access disclosure page.

10. UB clicks on the e-mail URL and authenticates to Privileged Access Manager and displays the password.

11. UB clicks on a button to “check-out privileged access.”

12. UB then may click on a button to do one of the following (the options available will vary based on policy): (a) Display the password. (b) Place a copy of the password in the operating system copy buffer. (c) Launch an RDP, SSH, vSphere or similar remote control session to the server in question.

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

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

6

Securing Privileged Accounts With Privileged Access Manager

5.3 Concurrency Controls – Checkin/Checkout Hitachi ID Privileged Access Manager can be configured to control the number of users who can simultaneously connect to a given privileged account. This is done using a checkout/checkin process, in a manner similar to checking a book out of a library and returning it later.

1. Rather than simply granting access to a privileged account, a user may be required to check out access. Checkout is subject to policy control: (a) A counter is incremented whenever access is checked out, indicating that one more person is allowed to sign into the account in question. (b) The number of users who may concurrently access an account is limited – for example, up to two at a time. (c) The time interval during which a user may be allowed to sign into an account is limited – for example, no more than two hours.

2. Users are asked to check-in access rights when they are done using a privileged account. (a) The account’s checkout counter is decremented.

3. If the maximum allowed checkout time has elapsed, Privileged Access Manager may automatically perform a checkin. This normally causes the account’s password to be re-randomized.

4. Checkout and checkin supports coordination among IT workers: (a) Privileged Access Manager can notify users who have already checked out access to an account of subsequent checkouts (e.g., via e-mail or SMS). (b) Privileged Access Manager can inform users who request a new checkout about already-active checkouts.

5. Passwords are normally randomized whenever the checkout counter returns to zero. This ensures that access does not persist after the last user disconnects from a privileged account.

5.4 Alternatives to Password Disclosure Hitachi ID Privileged Access Manager controls access by users and programs to privileged accounts on systems and applications. By default, that means that when a user is authorized to connect to a privileged account, the user is able to launch a login session directly to that account without ever seeing its password.

Display of current password values can be enabled through Privileged Access Manager policy configuration but is not normally recommended.

Access disclosure options include: 1. IT staff can directly launch Terminal Services (RDP), SSH (PuTTY), VMWare vSphere, SQL Studio, web browser/form login and other connections to target systems from the Privileged Access Manager web user interface, without displaying a password value.

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

7

Securing Privileged Accounts With Privileged Access Manager

2. IT staff can use an ActiveX control embedded in the Privileged Access Manager web portal to place a copy of a sensitive password into their Windows copy buffer, again without displaying the passwords.

This password is automatically cleared from their copy buffer after a few seconds.

3. Privileged Access Manager can dynamically attach a recipient’s Active Directory domain login ID to a local security group on a target system and later remove it. This eliminates the need to disclose passwords even to a software agent on the recipient’s workstation.

4. Privileged Access Manager can temporarily place a user’s public SSH key into the target account’s .ssh/authorized_keys file.

5. Where password display is required (e.g., a target system is currently offline), JavaScript in the Privileged Access Manager web portal removes it from the screen after a few seconds.

A policy defined for each set of managed systems in Privileged Access Manager determines which of these access disclosure mechanisms is available. For example, password display may be allowed for Windows workstations, since they may be inaccessible over the network, but RDP sessions with injected passwords may be mandatory on Windows servers.

5.5 API for Progammatic Access Disclosure 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.

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.

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

8

Securing Privileged Accounts With Hitachi ID Privileged Access Manager

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.

5.6 Updates to Service Passwords On the Windows operating system, service programs are run either using the SYSTEM login ID, which possesses almost every privilege on the system (and consequently can do the maximum harm) and which has no password or using a real user’s login ID and password, in order to execute with reduced privileges.

This means that on each Windows workstation and server there are a number of service accounts, each with its own password, which are used to run service programs such as web servers, backup agents, antivirus software, etc.

Service account passwords differ from administrator passwords in that they are stored in at least two places: 1. Hashed, in the security database – e.g., the local SAM database or Active Directory, just like all users.

2. Reversibly encrypted, in the registry or elsewhere, where the program that starts the service (e.g., Service Control Manager or similar) can retrieve it when it needs to start the service. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

9

Securing Privileged Accounts With Privileged Access Manager

Other Windows components besides the Service Control Manager also store passwords twice: 1. Virtual directories used to access web content from the IIS web server.

2. Programs scheduled to be run by the Windows Scheduler.

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

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

Privileged Access Manager can be configured to secure service account passwords. This means two things, depending on the mode of operation: 1. In pull mode, the Privileged Access Manager workstation service periodically scrambles service account passwords locally, in coordination with the central Privileged Access Manager server cluster.

2. In push mode, Privileged Access Manager servers periodically connect to Windows servers or Active Directory in order to change the passwords of service accounts.

In both cases, Privileged Access Manager must notify the program that launches services – the subscriber – of the new password value, so that it can successfully launch the service at the time of the next system restart or when an administrator manually stops and restarts the service in question. In some cases, for example when domain accounts are used to run services, an immediate restart may be required or advisable, due to Kerberos token expiry.

Privileged Access Manager includes extensive automation to discover subscribers and subscriber-to-serviceaccount dependency. This allows Hitachi ID Systems customers to review what services are run in the security context of what named users, on what systems. This is particularly helpful where services run in the security context of domain accounts, since multiple services on multiple servers may rely on the same service account and may therefore require notification of the same new password in a quick and fault-tolerant fashion.

Privileged Access Manager includes several processes that support safe and secure changes to service account passwords: 1. Auto-discovery of subscriber/account dependencies for a variety of subscriber types: IIS, Scheduler, SCM, DCOM, at various OS and subscriber versions.

2. A white-list mechanism (usually table driven, but a plug-in is available for more complex scenarios) so customers can control which service accounts should have their passwords randomized and when.

3. Built-in tools to notify known subscribers of new password values.

4. A transaction manager that can retry notifications to off-line subscribers.

The above are primarily used when managed systems are integrated with Privileged Access Manager in "push mode" – i.e., there is no locally installed software on the target system and Privileged Access Manager initiates all connections remotely, over the network, directly or via a co-located Privileged Access Manager proxy server. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

10

Securing Privileged Accounts With Privileged Access Manager

In case push mode is inappropriate – for example because the relevant services (remote registry, WMI, etc.) are disabled or firewalled or because the end system is offline or inaccessible due to name resolution or IP routing issues (NAT, etc.), a pull mode service can be installed on the managed system, which performs essentially the same functions but with much simpler connectivity (call home over HTTPS) and no need for network accessible services on the local system.

Pull mode is normally used on laptops and in some cases desktop PCs, but works on any system running any version of the Windows OS. Any problems encountered in updating a service password can and should be configured to trigger an exit trap program on the Privileged Access Manager server, to notify an administrator of an imminent problem when the service in question is next started.

Both the discovery and notification mechanisms described above are extensible. This means that customers who have other types of subscribers – for example, third party job schedulers – can add small programs that discover their account dependencies and notify them of new service account passwords. These are typically command-line programs (Windows executable or script) that run on the Privileged Access Manager server. For pull mode, the equivalent form of extensibility is provided via deployment-specific DLLs.

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

11

Securing Privileged Accounts With Privileged Access Manager

6 Strong Authentication Hitachi ID Privileged Access Manager can be configured to take advantage of an existing directory of users for identification, authentication and authorization of users: 1. Users may sign into Privileged Access Manager with their Active Directory or LDAP login ID and password.

2. Users may be required to authenticate with a two-factor technology, such as an RSA SecurID token.

3. User membership in Privileged Access Manager security groups and consequently user privileges, may be based on user membership in AD or LDAP groups.

Externalizing user identification, authentication and authorization can significantly reduce the administrative overhead of managing a Privileged Access Manager deployment and is recommended.

Privileged Access Manager also supports multi-step authentication. For example, a user may be required to type their AD password and then a PIN which was sent to their mobile phone via SMS. Administrators (IT staff) authenticate to the Privileged Access Manager web GUI as follows: • By typing their current password to a trusted system (e.g., Windows/AD, LDAP, RAC/F, etc).

• By answering security questions.

• Using a security token (e.g., SecurID pass-code).

• Using a smart card with PKI certificate.

• Using Windows-integrated authentication.

• Using a SAML or OAuth assertion issued by another server.

• By typing a PIN that was sent to their mobile phone via SMS. • Using a combination of these mechanisms.

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

12

Securing Privileged Accounts With Privileged Access Manager

7 Auditing and Regulatory Compliance 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.

Privileged Access Manager includes event reports, which make it possible to see, among other things: • • • • •

What users launched login sessions to what accounts.

How often access to any given account was granted.

When and how often passwords were changed on target systems.

How often users attempted to sign into Privileged Access Manager.

What the results of those authentication attempts were.

Reports are also included to examine the set of discovered / managed systems and accounts.

Privileged Access Manager status and process trends are visible in dashboards. For example, how many checkouts are currently active, how many systems are currently under management, how many requests are pending approval, etc. are all visible in a dashboard.

Included reports can also be used to find anomalous activity. For example, there are reports on popular checkouts by system, account, requester and approver. This can be used to identify users with unusually high (are they hacking?) or low (are they getting any work done?) activity. Reports can also be based on time of day. For example, a regularly scheduled report (every morning) can enumerate all checkouts made between 6PM and 6AM and send that data to a security officer.

The Privileged Access Manager schema is well documented and the database is a standard, relational SQL back-end. This makes it possible for Hitachi ID Systems customers to write custom reports using off-the-shelf programs such as Crystal Reports or Cognos BI. By recording administrative access to key systems and in some cases by requiring multiple people to approve such access before it happens, Privileged Access Manager can both limit and record access to sensitive systems that contain privacy-protected or financial data. These controls assist in complying with regulations such as HIPAA, SOX, PCI and more.

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

13

Securing Privileged Accounts With Privileged Access Manager

8 Privileged Access Manager Architecture 8.1 Network Architecture Figure 1 illustrates the network communication paths in a typical Hitachi ID Privileged Access Manager deployment, where Privileged Access Manager pushes passwords to fixed target systems – servers, applications, network devices, etc.

Hitachi ID Privileged Access Manager

Site A

Crypto keys in registry

Password Vault

User

010101 101001 100101

LDAP/S, NTLM

HTTPS

Admin Workstation

Load Balancer

Windows server or DC

SSH, TCP/IP+AES Replication TCP/IP + AES

Unix, Linux

TCP/IP +AES

Password Vault

010101 101001 100101

Various Target Systems

Firewall Proxy

Crypto keys in registry

Hitachi ID Privileged Access Manager

Site B

Site C

Figure 1: Privileged Access Manager Push-Mode Network Architecture Diagram In the diagram: 1. Three distinct physical sites are shown, each surrounded by a dotted-line border.

2. Two Privileged Access Manager servers are deployed, to two different sites. Real-time replication provides for resiliency in the event of a hardware failure on a single server or a complete outage at either site.

3. The Privileged Access Manager servers run on Windows 2008 or later. This platform provides the widest possible range of client software, making Privileged Access Manager easy to integrate with many kinds of target systems.

4. Stored passwords are encrypted (using AES). The encryption key is kept in the registry of each Privileged Access Manager server and is itself encrypted using a key embedded in the Privileged Access Manager software.

5. Each Privileged Access Manager server has a complete, local copy of the entire password database along with all configuration information.

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

14

Securing Privileged Accounts With Privileged Access Manager

6. Data replication traffic between the two servers is encrypted, making it resistant to snooping or tampering by a man-in-the-middle attacker.

7. Periodically, each Privileged Access Manager server connects to target systems and pushes new passwords to them. The protocol used depends on the type of target system, with two examples shown: LDAPS or NTLM for Windows servers, SSH to Unix or Linux servers and an encrypted TCP/IP connection to Unix targets that do not have an SSH service but do have a local Privileged Access Manager listener.

8. Some target systems may be unreachable directly, because of intervening firewalls. These may be contacted indirectly using a Privileged Access Manager proxy server, co-located with the target system. In this scenario, communication from the primary Privileged Access Manager server to the target system is via an arbitrarily-numbered TCP/IP connection and AES encryption using a shared key. The connection is forwarded to the target system by the proxy, using that target system’s native protocol.

9. Privileged Access Manager clients, such as IT workers or applications that use Privileged Access Manager in place of embedded passwords, connect to Privileged Access Manager over HTTPS. Since multiple Privileged Access Manager servers are available and each of them contains a full data set, this connection can be load balanced.

8.2 Push and Pull Modes Hitachi ID Privileged Access Manager supports both server passwords, in “push mode,” and workstation passwords, in “pull mode:” When managing passwords on servers, 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.

When managing passwords on laptops, 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 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.

8.3 Privileged Access Manager Host Platform Hitachi ID Privileged Access Manager must be installed on a Windows 2008R2 or 2012 server.

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

15

Securing Privileged Accounts With Privileged Access Manager

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

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

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

2. No ASP, JSP or PHP are used, so these engines should be disabled.

3. .NET is not required on the web portal and in most cases can be disabled on IIS. 4. No ODBC or DCOM are required inbound, so these services should at least be filtered.

5. File sharing should be disabled.

6. Remote registry services should be disabled.

7. Inbound TCP/IP connections should be firewalled, allowing only port 443 and possibly terminal services (often required for some configuration tasks).

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

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

These security measures are illustrated in Figure 2.

8.4 Supported Target System Types Hitachi ID Privileged Access Manager supports management of passwords on laptops, which may be mobile, have dynamic IP addresses, get unplugged, etc. This is done using client software, which works by ”pulling” new, passwords from the Privileged Access Manager server cluster. Client software is available for: 1. Windows 2000, XP, Windows Vista/7/8, 2003, 2008 and 2008R2.

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

16

Securing Privileged Accounts With Hitachi ID Privileged Access Manager

Input, output filtering Application-level ACL Server-local session state Random session/page keys.

CGI User Interfaces Application

Locked down.

No Asp, COM, DDE, etc., Current SPs.

Web Server

Identity Cache

Input, output filtering Application-level ACL Caller authentication Encrypted I/O.

Hitachi ID Services

Operating System Hardened at current patch levels; most services disabled.

Installed in a physically secure facility. Alarmed and monitored.

Services

File system

Networking

Sensitive data encrypted or hashed.

Hardware

CPU

Storage

NICs

All traffic in/out is encrypted.

Figure 2: Network architecture security diagram 2. Unix (various vendors) and Linux (IA86).

The Windows pull-mode service includes plug-ins to notify operating system components of new service account passwords. Plug-ins are provided for the Windows Service Control Manager, Windows Scheduler and IIS. Push mode agents, installed on the Privileged Access Manager server and designed to write new passwords to fixed-address target systems, are included 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.

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/id-archive/what-is-id-archive-7.tex Date: 2011-03-02