Securing Privileged Access with Hitachi ID Privileged Access Manager

Transcription

1 Securing Privileged Access with Hitachi ID Privileged Access Manager 2015 Hitachi ID Systems, Inc. All rights reserved.

2 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 Types of Privileged Accounts 2 3 Technical Barriers to Privileged Password Changes 3 4 Functional Requirements 4 5 Randomizing and Vaulting Passwords 5 6 Access Disclosure Frequent Users: Pre-approved Access Occasional Users: One-time Workflow Approval Concurrency Controls Checkin/Checkout Single Sign-on, Privilege Escalation and Other Disclosure Methods Replacing Embedded Passwords Changing Windows Service Account Passwords An alternative to privileged accounts: temporary group membership A Unix/Linux alternative to password injection: temporary SSH trust Strong Authentication 15 8 Auditing and Regulatory Compliance 16 9 Session capture and playback 18 i

3 10 Hitachi ID Privileged Access Manager Architecture Network Architecture Communicating with managed endpoints: push, pull and proxy Hitachi ID Privileged Access Manager Host Platform Supported Target System Types Hitachi ID Systems, Inc. All rights reserved.

4 1 Privileged Access Management In a typical medium to large organization there are thousands of servers, workstations and network devices. Often, there is a single, shared administrator password for every type of device. For example, one password may be used for each laptop of a given type or for every server built with a given image. This is convenient for data center and desktop support staff: if they need to perform maintenance or an upgrade on a system, 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 trail linking administrative changes to individual IT staff. If someone makes a change to a system that causes a malfunction, it can be difficult to determine who caused the problem. This makes problems harder to diagnose and repair. When the same privileged account and password exists on many systems and is used by many people or software agents, it is difficult to coordinate password changes. As a result, privileged passwords are rarely changed and are often known to former employees and departed contractors. Hitachi ID Privileged Access Manager secures privileged accounts across the IT landscape and at large scale: It periodically randomizes passwords to privileged accounts. Users must sign into Privileged Access Manager before they can access privileged accounts. This is an excellent opportunity to require strong, multi-factor authentication. This also allows organizations to apply a central authorization policy who is allowed access to which account, when and from where? Privileged Access Manager launches login sessions on behalf of users, without displaying passwords single sign-on. Privileged login sessions can be recorded, including screen capture and keyboard capture. This creates strong accountability and forensic audit trails Hitachi ID Systems, Inc. All rights reserved. 1

5 2 Types of Privileged Accounts There are broadly three types of privileged accounts in common use: 1. Administrator accounts: There are accounts, often shared by multiple IT users, which are used to establish interactive logins to systems and applications. These logins are used to manage those systems apply patches, change configuration, manage users, retrieve log files, etc. Examples include Administrator on Windows, root on Unix/Linux, sa on SQL Server, SYSTEM on Oracle databases, and many others at least one per platform. 2. Application to application accounts: These accounts are used by one application to connect, identify and authenticate to another. Common examples include applications used by a web application to connect to a database server, object broker or directory. 3. Service accounts: These accounts provide a security context in which to run unattended processes, such as scheduled tasks, services or daemons. In the context of this document, we are mostly concerned with the management of Windows service accounts, because unlike on other platforms on the Windows operating system, to start a process in the security context of a given account, the password for that account must be provided. This creates the need to manage passwords for service accounts on Windows (on other platforms, service accounts normally do not have a password) Hitachi ID Systems, Inc. All rights reserved. 2

6 3 Technical Barriers to Privileged Password Changes 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 accounts: Automation is required to onboard systems and accounts, schedule password changes and authorize access to accounts. There are many kinds of systems, all with privileged accounts: The automation must include many integrations to client and server operating systems, databases, applications, hypervisors and guest VMs, network devices, health monitoring hardware, web services and more. The majority of privileged accounts are on PCs and laptops. End user PC passwords are hard to manage centrally: PCs may be powered down, disconnected or firewalled. PC IP addresses may change along with physical location and be behind NAT in any case. PCs may be configured to block inbound service connections, including requests to change local passwords. Connectivity to servers and applications. Network-attached systems may not always be running. This is especially true of demand-driven VMs. Routing problems, firewalls and name resolution (DNS) problems may block access to network services. Systems with privileged accounts are heterogeneous a single mechanism or protocol cannot support them all. 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 credential vault would lock out access to every privileged account. Include fine-grained access controls. Only the right people should get access to the right accounts, at the right time, after strong authentication. Log access disclosure. Access to privileged accounts must be logged, to create accountability, both operationally and in the event of a forensic investigation Hitachi ID Systems, Inc. All rights reserved. 3

7 4 Functional Requirements A privileged access management system must have the following capabilities: 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 using a named Windows or AD domain account (Windows Service Control Manager, Scheduler, IIS, etc.) so that services can be started after password changes. (d) To applications, to eliminate embedded passwords in programs and scripts. 3. Regular users, who use certain privileged accounts frequently, should be pre-authorized for this access, whenever they need it. 4. Other users, who only rarely need to use privileged accounts, should be able to request such access, but only gain it subject to one-time approval. 5. The system must log both password updates and access disclosure. Failed updates can be used to identify infrastructure problems while logs of access disclosure create accountability. 6. The system should be able to control concurrent access to a given account for example, to limit the number of people who might perform administrative tasks on a system at the same time and to link changes to few (or one) individual(s) Hitachi ID Systems, Inc. All rights reserved. 4

8 5 Randomizing and Vaulting Passwords Hitachi ID Privileged Access Manager secures sensitive passwords by periodically setting them to new, random values: 1. On systems integrated via "push mode:" (a) Periodically for example, every night between 3AM and 4AM. (b) When users check accounts 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 (randomize all passwords that person may have known). Note that "push mode" normally means that no software is deployed to the managed endpoint system. 2. On systems integrated via "pull mode:" (a) Periodically for example, every day. (b) At a random time-of-day, to even out workload on the Privileged Access Manager service. (c) Opportunistically, whenever network connectivity happens to be available from the managed endpoint to the central privileged access system. Note that "pull mode" implies a local agent on the managed endpoint system. This approach is useful on laptops, on rapidly provisioned/deprovisioned VMs in a cloud environment and in some isolated network segments. 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), each policy can specify minimum and maximum password lengths, prohibit the use of dictionary words, etc Hitachi ID Systems, Inc. All rights reserved. 5

9 6 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. Passwords and/or access can be disclosed to: 1. frequent users, subject to access control policy; 2. infrequent users, subject to a one-time approval workflow; 3. applications, to replace embedded passwords, via a web services API, client-side library, OTP, IP address validation, program fingerprinting and more; and 4. service launching infrastructure, such as the Windows SCM and scheduler, by injecting new passwords and optionally restarting services. All disclosure is subject to user identification, strong authentication, SSL encryption in transit and audit logs. 6.1 Frequent Users: Pre-approved Access 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 system SYS0123 to policy MSP-A ) or implicitly, using an expression such as all systems of type Linux at /24 are attached to MSP-B. Expressions may be based on the operating system type, IP address, MAC address, system name or other metadata. 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 access. 5. What access disclosure methods to offer authorized users e.g., launch a given type of client program with ID/password from the credential vault, display a password, copy buffer integration, temporary group membership or SSH trust, etc. Privileged Access Manager users are organized into user groups, also either explicitly or implicitly. Most commonly, 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 2015 Hitachi ID Systems, Inc. All rights reserved. 6

10 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. 6.2 Occasional Users: One-time 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 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 access to privileged account PA on system S be made available to user UB at some later time T. UA may be the same person as UB (a self-service request). 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, UA or UB s manager. 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 PA. 4. Privileged Access Manager sends invitations to authorizers LA. 5. If authorizers fail to respond, they get automatic reminder s. 6. If authorizers still don t respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request. Privileged Access Manager will invite replacement authorizers next. 7. Authorizers receive invitation s, click on a URL embedded in the invitation, authenticate themselves to the Privileged Access Manager web portal, review the request and approve or reject it. 8. If any authorizers reject the request, s are sent to all participants (UA, UB and LA) and the request is terminated. 9. If M authorizers approve the request, thank-you s are sent to all participants. The sent to the recipient includes a URL to an access disclosure page. 10. UB clicks on the URL and authenticates to Privileged Access Manager. 11. UB clicks on a button in the web portal 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 (rarely allowed). (b) Place a copy of the password in the operating system copy buffer (sometimes allowed). (c) Launch an RDP, SSH, vsphere, SQL Studio or similar login session to PA on S (most common). 6.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 2015 Hitachi ID Systems, Inc. All rights reserved. 7

11 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 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. 6.4 Single Sign-on, Privilege Escalation and Other Disclosure Methods Hitachi ID Privileged Access Manager controls access by users and programs to privileged accounts on managed endpoint systems. In most cases, this means that when a user is authorized to connect to a privileged account, the user is able to launch a login session directly to the managed account without seeing its password. Display of current password values can be enabled through Privileged Access Manager policy configuration but is usually only recommended for users physically in the data center, who need access to a server console. Access disclosure options include: 1. Directly launch Terminal Services Client (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. 2. Place a copy of a sensitive password into the Windows copy buffer. This password is automatically cleared from their copy buffer after a few seconds Hitachi ID Systems, Inc. All rights reserved. 8

12 3. Temporarily place the authorized user s Active Directory account in a local or domain security group. 4. Temporarily append the authorized user s public SSH key into the managed account s.ssh/authorized_keys file. 5. Where password display is required, display the password but automatically clear it from the user s browser display after a few seconds. Policy rules determine which mechanisms are available to what users, managed systems and managed accounts. 6.5 Replacing Embedded Passwords Hitachi ID Privileged Access Manager includes an API that enables applications to disclose passwords as needed, at runtime and eliminates the storage of static, plaintext passwords. Privileged Access Manager periodically randomizes passwords used to connect to network services (DB, FTP, web, etc.), while applications use the API to retrieve passwords when required. The Privileged Access Manager API is accessed as a SOAP web service 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 value of this 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 web service. Privileged Access Manager secures this process with a combination of access controls, onetime passwords and network address validation: 1. API clients each have their own ID, used to sign into Privileged Access Manager. 2. These IDs are attached to console user groups and assigned access rights to privileged accounts managed by Privileged Access Manager. This allows Privileged Access Manager to determine which passwords a given ID is allowed to retrieve. 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 after each successful login by the client application into the Privileged Access Manager web service. 4. API client login IDs are linked to IP subnets. An API client can only sign into the Privileged Access Manager web service from an IP address in the correct range. An "API wrapper" library is provided to simplify use of the Privileged Access Manager web service. Different versions of the library are provided for a variety of runtime platforms and programming languages, such as.net, Java, Linux/C, etc. This wrapper code performs several functions: 1. Storing the one time password (OTP) used to authenticate to the API Hitachi ID Systems, Inc. All rights reserved. 9

13 2. Serializing access to the API, so that the OTP is always valid (avoiding race conditions where two threads receive two OTP values at almost the same time). 3. Keeping cached copies of passwords previously retrieved from the API, along with cache expiry time. This improves system performance as calls to the wrapper library do not always trigger web services calls to Privileged Access Manager. This also ensures service resilience, in the event that Privileged Access Manager becomes temporarily unavailable. 4. Encrypting both the OTP and locally cached passwords. Encryption of the OTP and cached passwords implies an encryption key. The API wrapper libraries support a variety of methods to produce this key, all of which are intended to fingerprint the authorized application and its runtime environment. This includes: 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). 4. Hashes of configuration files and command-line arguments. The objective of these key generation mechanisms is to lock down the application and its runtime, so that only the approved application running on an approved system will be able to retrieve a password from Privileged Access Manager or from the local cache. An attacker who compromises the system running an application should be prevented from adding logging statements to display the retrieved password, from moving the application to another server and retrieving passwords there, from running the program with different command-line arguments or configuration files, so that it prints the password to a log file, etc. Hitachi ID Systems is happy to provide new versions of this wrapper library for different run-times or programming languages based on customer demand. The wrapper library is also provided in command-line form, suitable for use in scripts and for troubleshooting. 6.6 Changing Windows Service Account 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 requires no password or using a named local or domain account. Services are run in the security context of a named account in order to reduce the privileges available to them at runtime. When Windows services are run with a named account, the password for that account is needed to start the service process. This means that the Service Control Manager (SCM), IIS web server, Scheduler, etc. all need to know both the ID and password of service accounts, when they are configured to run jobs, services, application pools or similar contexts as a named account, rather than as SYSTEM Hitachi ID Systems, Inc. All rights reserved. 10

14 Service account passwords differ from administrator passwords in that they appear in at least two places: 1. Hashed, in the security database e.g., the local SAM database or Active Directory, just like any other account. 2. Reversibly encrypted or plaintext, in the registry or a configuration file, where the program that starts the service (e.g., Service Control Manager, Scheduler, IIS,...) can retrieve the password value when starting a new service process. Some Windows components, notably IIS, are able to periodically change the passwords of local service accounts they use. Unfortunately, this capability does not extend to domain service accounts, used to run services on multiple systems and does not apply to all types of service accounts. This means that many Windows service account passwords remain static by default. Hitachi ID Privileged Access Manager can be configured to secure service account passwords. This means two things, depending on the mode of operation: 1. In push mode (i.e., no local agent on the Windows server), Privileged Access Manager servers periodically connect to Windows servers or Active Directory in order to change the passwords of service accounts. 2. If the local workstation service is installed on a Windows system (i.e., the "pull mode" agent), the Privileged Access Manager service periodically changes service account passwords locally, in coordination with the central Privileged Access Manager server cluster. 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 can be configured to restart services after each automated password change. 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 run as the same service account and may therefore require notification after each password change. Privileged Access Manager includes several mechanisms to accomplish safe and secure changes to service account passwords: 1. Auto-discovery of subscriber/account dependencies for a variety of subscriber types: IIS (multiple sub-components may have service accounts/passwords), Scheduler, SCM, DCOM, at various OS and subscriber versions. 2. White-list policy tables: (a) Initialized with discovered data about service accounts and services. (b) Allow organizations to specify a password randomization schedule Hitachi ID Systems, Inc. All rights reserved. 11

15 (c) Allow organizations to name application owners, who will be notified of password changes and any issues. (d) Allow organizations to specify a style of notification. For example, notify the subscriber of new password values before a password change, after or both? Restart the subscriber or not? 3. A mechanism that tests for the availability of all subscribers before each password change. In particular, if some systems where services run in the security context of a domain service account are unreachable, then changes to that account s password will be deferred. 4. Built-in tools to notify subscribers of new password values and restart services if this was specified in the policy. 5. A transaction manager that will retry notifications to subscribers that went off-line after a password was changed and before they could be notified of the new password value. The above are primarily used when managed systems are integrated with Privileged Access Manager in "push mode" i.e., there is no locally installed agent on the target system and Privileged Access Manager initiates all connections remotely, over the network, directly or via a Privileged Access Manager proxy server deployed near the target system. Where 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 local workstation 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. The local workstation service is most often used on laptops and in firewalled network segments (DMZs). Privileged Access Manager is normally configured to contact application owners after each password change and in the event of a problem. This makes troubleshooting easier in the event that notification failed and a service subsequently could not be started. The entire infrastructure mentioned here is extensible. Customers can expand it to support other processlaunching systems, such as third job party schedulers for example. 6.7 An alternative to privileged accounts: temporary group membership Hitachi ID Privileged Access Manager can be configured to provide privilege elevation by temporarily placing a user s (normally unprivileged) personal account into a privileged security group on the target system. This process works as follows, using an Active Directory domain, a Windows server and an RDP connection in our example: 1. Administrator A requests privileged access to system C. 2. The request is approved either because A has been pre-approved for such access (typically via membership in a separate AD group) or because some other user, designated as an owner of system C, approves the request. 3. Administrator A checks out access to system C Hitachi ID Systems, Inc. All rights reserved. 12

16 4. Privileged Access Manager places A s AD account into a privileged group on system C, such as (local group) Administrators. 5. A connects to C using RDP. This connection might be mediated by Privileged Access Manager, which can launch the RDP session directly from its web portal using an ActiveX control. 6. Depending on how Privileged Access Manager and C are configured, A may have to type his personal AD password to establish the RDP connection to C. 7. At some later time, A will either check-in the session or the session will time out. At this time, Privileged Access Manager will remove A s AD account from the privileged group on C. This approach of manipulating group memberships rather than disclosing passwords has the advantage that audit logs on the target system (C in the example above) show activity by the individual administrator (A in the example above) rather than by a generic local administrator account. The limitations of this approach are: 1. It does not help with access to systems that are not linked to a directory (e.g., Windows in AD, Linux in LDAP, etc.) since it presupposes that the user can already sign into the system in question, but not with adequate privileges for the desired activity. 2. It does not help with systems which are disconnected from the network. 3. Users, once granted elevated privileges, can connect from a different client device and therefore bypass any client-based or proxy-based session monitoring infrastructure. If there is a desire to record (keylog, video capture, etc.) user activity, then this approach is not appropriate. 6.8 A Unix/Linux alternative to password injection: temporary SSH trust Hitachi ID Privileged Access Manager can be configured to grant privileged access to Unix and Linux computers by temporarily placing an administrative user s personal SSH public key into the trusted keys file of a functional account on the target computer. This architecture works as follows: 1. The Privileged Access Manager server gets its own SSH public and private keys. 2. Every user who may require privileged access to Unix/Linux systems must have: (a) An SSH client on his PC. (b) A well known SSH public key. 3. A copy of the public SSH key for every user is kept on the Privileged Access Manager server or on a Unix/Linux system which Privileged Access Manager can access. 4. Each managed Unix/Linux computer is configured with: (a) An SSHD listener Hitachi ID Systems, Inc. All rights reserved. 13

17 (b) The SUDO package. (c) A set of functional accounts (see below). 5. The /etc/sudoers file on each managed Unix/Linux computer is configured to grant a set of predefined privileges to each functional account. For example: The account dba might be allowed to perform DB-related tasks. The account backup might be allowed to perform filesystem backups. The account procmon might be allowed to perform runaway processes. The account monitor might be allowed to perform stats from /proc. 6. The.ssh/authorized_keys file of each of the functional accounts is configured to trust the public SSH key of the Privileged Access Manager server. 7. At access checkout time, Privileged Access Manager modifies the.ssh/authorized_keys file of the functional account to which access was granted to include the public key of the user who needs access to that account. 8. At access checkin or expiry time, Privileged Access Manager modifies the.ssh/authorized_keys file of the relevant functional account to remove the public key of the user who had access to that account. The access disclosure process works as follows: 1. Administrator A requests access to functional account F on computer C. 2. The request is approved either because A has been pre-approved for such access (typically via membership in an AD group) or because some other user, with ownership rights to F@C, approves the request. 3. Administrator A checks out access to F@C. 4. Privileged Access Manager retrieves a copy of the.ssh/authorized_keys from F@C, adds A s public SSH key to the file and puts the new.ssh/authorized_keys back in F@C s home directory. 5. A connects to F@C using SSH. This connection is authenticated using an SSH key exchange (not a password). 6. A may have to type a password to access his own SSH private key, depending on how whether his SSH key is encrypted with his password. 7. Eventually A will either check-in the session or the session will time out. When either event happens, Privileged Access Manager will remove A s public SSH key from F@C s.ssh/authorized_keys file Hitachi ID Systems, Inc. All rights reserved. 14

18 7 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 or a token pass-code. Multi-factor authentication is strongly recommended for Privileged Access Manager deployments, as it protects logins into Privileged Access Manager against keylogging attacks on user devices. Administrators (IT staff) authenticate to the Privileged Access Manager web portal 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 Hitachi ID Systems, Inc. All rights reserved. 15

19 8 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. In the context of a forensic audit, Privileged Access Manager enables organizations to see: 1. Who had administrative access to a given system or application in a given time period. 2. Who authorized the access, in the event that it was a one-off request (as opposed to a permanent right to access the system in question). 3. When the access was first used (e.g., password or access check-out) Hitachi ID Systems, Inc. All rights reserved. 16

20 4. When the access was terminated (e.g., password or access check-in). Privileged Access Manager includes a session recording feature, to record the screen display, keyboard input and even web-cam screen shots from the workstations of system administrators while a login session connects them to a privileged account on system integrated to Privileged Access Manager. 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 Hitachi ID Systems, Inc. All rights reserved. 17

21 9 Session capture and playback Hitachi ID Privileged Access Manager can be configured to record screen, keyboard and other data while users are connected to privileged accounts. The recording may be of just the window launched to connect a user to a privileged account or of the user s entire desktop. The session recording system is tamper resistant if users attempt to interrupt recording, their login sessions to privileged accounts are disconnected and an alarm is raised. Session recordings may be archived indefinitely and may serve a variety of purposes, ranging from knowledge sharing and training to forensic audits. Access to recorded sessions is secured through a combination of access control policies and workflow approvals, designed to safeguard user privacy. The Privileged Access Manager session monitoring infrastructure is included at no extra cost. It works using ActiveX components and does not require software to be permanently installed on user PCs. There is no footprint on managed systems and no proxy servers are used. Session monitoring is compatible with all administration programs and protocols, as it instruments the administrator s PC, rather than network traffic. Recordings can be made of SSH, RDP, vsphere, SQL Studio and any other administrative sessions launched via Privileged Access Manager. Recordings can include key-logging, video, webcam, copy buffer and more, based on policy settings and without regard to the type of session (protocol, client tool) that was launched Hitachi ID Systems, Inc. All rights reserved. 18

22 10 Privileged Access Manager Architecture 10.1 Network Architecture The Hitachi ID Privileged Access Manager network architecture is illustrated in general terms in Figure 1. Managed Laptops (mobile) IT User PCs Single sign-on: RDP, SSH, SQL, etc. Download app-launch ActiveX. Upload session capture Target Systems Probe systems, Randomize PWs Assign GRPs Replicated, distributed Hitachi ID Privileged Access Manager Servers Request Disclosure Data Center 1 Request new PWs, GRP changes Load Balancer Replicated Updates Target Systems HiPAM proxy locally Probe systems, Randomize PWs Assign GRPs Corporate WAN Firewall Target Systems D.C. 2 TCP/IP + AES HTTPS Run connectors Various Protocols D.C. 3 Workstation Service Figure 1: Privileged Access Manager Network Architecture Diagram In the figure: 1. There are normally at least two Privileged Access Manager servers, preferably at least two different physical locations. This is so that a server crash or a site disaster does not cause all privileged passwords to be permanently lost or be temporarily unavailable at other sites. 2. Privileged Access Manager server software is installed on Windows Security officers, auditors, IT staff, application owners (authorizers) and others who need to interact with Privileged Access Manager do so using a web UI. This access is typically mediated by a load balancer which sends sessions to one of two or more load balanced Privileged Access Manager servers. 4. If privileged passwords are randomized on mobile devices, there is typically an agent installed on the endpoint device (available for Windows) which periodically requests new password values, group membership changes, etc. for local, privileged accounts (local service mode). On all other systems, password changes are initiated by the Privileged Access Manager servers and there is normally no agent software on the target system Hitachi ID Systems, Inc. All rights reserved. 19

23 5. Each Privileged Access Manager server has its own database which contains encrypted credentials for privileged accounts on target systems, along with policy data, audit logs and a variety of configuration data. The database may be SQL Server or Oracle. 6. All updates to Privileged Access Manager databases are mediated by a Privileged Access Manager database service, which is responsible for reliable replication of these updates to peer Privileged Access Manager servers. This includes a replication queue on each server. 7. Each Privileged Access Manager server is responsible for pushing passwords to a set of target systems. This allows multiple Privileged Access Manager servers to share the work of randomizing passwords on many target systems (as many as 2,000,000 password changes every 24 hours using just three Privileged Access Manager servers). 8. Connectors are provided to push passwords to over 120 types of systems. 9. If connections to some target systems are blocked by a firewall then a Hitachi ID Systems proxy server may be co-located with those systems and the responsible Privileged Access Manager server will ask that proxy to make password updates locally. This reduces the number of ports that must be opened through firewalls when Privileged Access Manager operates in a large, segmented WAN. 10. Requests for access disclosure may be authorized immediately, because the recipient named in the request has been pre-authorized to gain privileged access via group membership and a persistent ACL. Requests are entered via a web portal or API. 11. Requests for access disclosure may require manual approval, using the Privileged Access Manager workflow engine. This includes N of M authorizers, reminders, escalation, and delegation. Authorizers may be statically assigned to groups or managed devices or calculated dynamically. Authorization is invited via and completed via an authenticated web session Communicating with managed endpoints: push, pull and proxy There are three styles of outbound connectivity from a Hitachi ID Privileged Access Manager server to managed systems, as illustrated in Figure 2. In the figure: 1. Direct access is where the Privileged Access Manager server runs a connector locally. This connector connects to the target system over the network. This is also called a push mode target system. 2. Indirect access via a Privileged Access Manager proxy server is where an active Privileged Access Manager server connects to a proxy server. The proxy server runs a connector on behalf of the active server. The connector connects to a target system on the network. Proxy servers are typically colocated with one or more distant or firewalled managed systems. Interaction with target systems via a proxy is still considered push mode, because an active Privileged Access Manager server initiates each connection. 3. Direct or web-proxied connections initiated from a client device, accessing a web services API URL on an active Privileged Access Manager server. This is called local service mode and is typically deployed on user laptops, to allow for the fact that they may be powered off, relocated assigned dynamic IP addresses, firewalled, NAT ed and generally be difficult or unreliable for a central Privileged Access Manager server to find Hitachi ID Systems, Inc. All rights reserved. 20

24 Proxy Connect Set password Connect and set password Laptop Sometimes offline Sometimes powered off Changes location, IP May be behind NAT or firewall Firewall Firewall Server Privileged Access Manager Server Figure 2: Push-mode, pull-mode and proxies to connect to managed systems 10.3 Privileged Access Manager Host Platform Hitachi ID Privileged Access Manager must be installed on a Windows 2012 server. 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 but Apache can be manually configured instead if required. 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. No ASP, JSP or PHP are used, so such engines should be disabled. 2..NET is not required on the web portal and in most cases can be disabled on IIS. 3. No ODBC or DCOM are required inbound, so these services should be filtered or disabled. 4. File sharing (inbound, outbound) should be disabled. 5. Remote registry services should be disabled Hitachi ID Systems, Inc. All rights reserved. 21

25 6. Inbound TCP/IP connections should be firewalled, allowing only port 443 and possibly remote desktop services (often required for some configuration tasks), plus a handful of port numbers between Privileged Access Manager servers, for replication. Each Privileged Access Manager server requires a database instance. SQL 2012 is the most common options, but Oracle database is also supported in the current release. 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 3. Input, output filtering Application-level ACL Server-local session state Random session/page keys. Locked down. No Asp, COM, DDE, etc., Current SPs. Application Web Server Operating System CGI User Interfaces Identity Cache Hitachi ID Services Input, output filtering Application-level ACL Caller authentication Encrypted I/O. Hardened at current patch levels; most services disabled. Services Hardware File system Networking Sensitive data encrypted or hashed. Installed in a physically secure facility. Alarmed and monitored. CPU Storage NICs All traffic in/out is encrypted. Figure 3: Network architecture security diagram 10.4 Supported Target System Types Hitachi ID Privileged Access Manager comes with built-in connectors for most common systems and applications, as illustrated below. All connectors are included in the base price Hitachi ID Systems, Inc. All rights reserved. 22

26 Directories: Servers: Databases: Any LDAP, AD, NDS, edirectory, NIS/NIS+. Windows , Samba, NDS, SharePoint. Unix: Mainframes: Midrange: Linux, Solaris, AIX, HPUX, 24 more variants. z/os with RAC/F, ACF/2 or TopSecret. Oracle, Sybase, SQL Server, DB2/UDB, ODBC, Informix, Progress. 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. SaaS: Miscellaneous: Extensible: Salesforce.com, WebEx, Google Apps, MS Office 365, Concur, AWS, vcloud, SOAP (generic). OLAP, Hyperion, ilearn, Caché, Success Factors, VMware vsphere. Cisco IOS, Juniper JUNOS, F5, ilo cards, DRAC cards, RSA cards, etc. McAfee, CheckPoint (PointSec), Microsoft (BitLocker), Symantec (PGP). SSH, Telnet, TN3270, HTTP(S), SQL, LDAP, command-line. Privileged Access Manager includes a number of flexible connectors, each of which is used to script integration with a common protocol or mechanism. These connectors allow organizations to quickly and inexpensively integrate Privileged Access Manager with custom and vertical market applications. The ability to quickly and inexpensively add integrations increases the value of the Privileged Access Manager system as a whole. There are flexible connectors to script interaction with: API binding: Terminal emulation: Web services: Back end integration: Command-line: C, C++ Java, J2EE.NET COM, ActiveX MQ Series SSH Telnet TN3270, TN5250 Simulated browser SOAP WebRPC Pure HTTP(S) SQL Injection LDAP attributes Windows Power Shell Unix/Linux 2015 Hitachi ID Systems, Inc. All rights reserved. 23

27 Organizations that wish to write a completely new connector to integrate with a custom or vertical market application may do so using whatever development environment they prefer (J2EE,.NET, Perl, etc.) and invoke it as either a command-line program or web service. If the organization develops their own integrations, an effort of between four hours and four days is typical. Alternately, Hitachi ID Systems offers fixed-cost custom integrations for a nominal fee. 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/R2, 2012/R2. 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. 500, Street SE, Calgary AB Canada T2G 2J3 Tel: Fax: [email protected] Date: File: / pub/ wp/ documents/ id-archive/ what-is-hipam-8.tex