Security Fundamentals

Compromising privileged accounts is a central objective for any attacker, and CyberArk Privileged Access Manager - Self-Hosted is designed to help improve your organization’s ability to control and monitor privileged activity. As with any security solution, it is essential to secure Privileged Access Manager - Self-Hosted to ensure the controls you have implemented are not circumvented by an attacker.

The controls described in this document are the minimal requirements for protecting your Privileged Access Manager - Self-Hosted deployment, and therefore your privileged accounts. Consolidated by our team, these controls reflect our experience in implementing industry best practices when supporting our customers in installing and operating our products. The requirements are also based upon analysis of various reports made by companies that experienced a security incident and other research data generally available in the industry. Details are included in Digital Vault Security Standard.

It is imperative that you follow as many of these steps as practicable in your environment, recognizing there may be other methods that you may wish to use based on your organization’s expertise. Review your CyberArk deployment on a regular basis to ensure it complies with industry best practices, including those outlined in this topic. For questions or assistance with designing and implementing these controls or support in reviewing your deployment, contact your CyberArk or partner representative.

Requirements for protecting your CyberArk deployment

Recent attacks have shown that it is common for threat actors to leverage vulnerabilities in Kerberos protocol to move throughout the environment undetected. It is therefore required that the Digital Vault server run on an isolated and trusted platform.

Minimal requirements:

  • The Digital Vault server is not a member of a Windows Domain

  • Third-party software is not installed on the Digital Vault server

  • Network traffic to the Digital Vault server is restricted to CyberArk protocols

  • Network traffic from the Digital Vault server is restricted to CyberArk protocols and approved integrations such as LDAP for user and group provisioning or SMTP for email alerts

  • The Digital Vault server operating system credentials are unique

  • Any infrastructure hosting the Digital Vault server has the same controls applied to it as those applied to the Digital Vault server

  • Microsoft security updates are applied regularly. For details, see Integrate the Digital Vault with a Windows Patch server (WSUS). Employ the following WSUS best practices:

    • Make sure your WSUS server is configured for Microsoft Security best practices.

    • Use a dedicated WSUS Server for updating the Digital Vault. If this isn't possible, create a dedicated computer group for updates in WSUS with relevant updates for the Vault.

    • Configure WSUS to work with HTTPS and a certificate.

    • Use the actual WSUS IP address (don't use a DNS).

    • Ensure that the connection between the WSUS server and the Vault is disabled when not applying actual updates. The CyberArk Vault installation package includes WSUS scripts for this purpose.

  • Use network-based firewalls to restrict, encrypt and authenticate inbound administrative traffic

Due to the increased risk and complexity of assuring controls on the underlying infrastructure, such as VMWare ESX and the SAN backing it, on-premise Digital Vault servers must be physical servers.

For more information, see Digital Vault Security Standard.

Using multi-factor authentication to Privileged Access Manager - Self-Hosted for all users and product administrators, enables you to mitigate common credential theft techniques, for example:

  • Key loggers
  • Tools capable of harvesting plaintext passwords

Like the Digital Vault server, CyberArk components, including the PVWA, CPM, and PSM, are sensitive assets. The core principle of this control is to treat CyberArk infrastructure with the highest level of security.

Minimal requirements for restricting access:

  • Follow Microsoft’s best-practices for mitigating credential theft and securing Active Directory CyberArk component servers are of the same security level as domain controllers (tier 0). For details , see Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques

  • Consider keeping CyberArk component servers out of the domain

  • Consider installing each component on its own server. However, hardening is available if all components are installed on a single server
  • Do not install all the components on the same server in the DMZ
  • Do not install non-CyberArk applications on the component servers, as this prevents hardening the component server

  • Limit the accounts that can access component servers. Ensure that any domain accounts used to access CyberArk servers are unable to access domain controllers and other member servers and workstations

  • Limit the number of domain credentials that are able to access the component servers

  • Use network-based firewalls and IPsec to restrict, encrypt and authenticate inbound administrative traffic; use the PSM and the local administrator account to access component servers

  • Deploy application allowlisting and limit execution to authorized applications

  • Apply Microsoft security updates regularly

Reducing the number of privileged accounts and/or the extent of their privileges reduces the overall privileged account attack surface. This is true both for the enterprise as a whole and for each solution implemented, including CyberArk. The core principle of this control is that there should only be a few CyberArk administrators, and they should only possess limited privileges, unless elevated through a strong approval process.

Minimal requirements:

  • Eliminate unnecessary CyberArk administrative accounts

  • Reduce privileges of CyberArk administrative accounts

  • Restrict personal accounts to business-as-usual permissions justified for their role. CyberArk administrators do not have justification to access all credentials

  • Require privilege elevation (with Dual Control or Ticketing Integration) for system configuration changes or to access credentials that the CyberArk administrator otherwise does not have justification to access

  • Use the PSM to isolate and monitor CyberArk administration

  • Require multi-factor authentication for all avenues of administrative access

Like many applications, the CyberArk Digital Vault has sensitive accounts and encryption keys. These sensitive accounts come in two forms: business-as-usual administrators (addressed in Control #4) and out-of-band administrators (for example, the Master user), to be used when the normal administration methods are not available. Furthermore, utilizes two encryption keys to secure data: the Operator Key is used for runtime encryption tasks and the Master Key is used for recovery operations.

Minimal requirements:

  • Store the built-in Vault Administrator, OS Administrator and iDRAC/iLo root passwords in a physical safe (distribute copies to two or more locations); ensure that access requires more than one individual

  • Store the Master Password and Master Key in a physical safe (distribute copies to two or more locations) and ensure that access requires more than one individual

  • Do not store the Operator Key on the same media as the data

  • Use a Hardware Security Module (HSM) to secure the Operator Key

The use of insecure protocols can easily render other controls invalid. To reduce the risk of eavesdropping and other network-based attacks, use encrypted and authenticated protocols for all communications.

For example:

  • Use HTTPS for the PVWA and for REST APIs
  • LDAPS for the Digital Vault LDAP integration, RDP/TLS for connections to the PSM, and SSH (instead of telnet) for password management
  • TLS is required for the following:
    • RDP
    • SMTP
    • Syslog

To detect problems early, it is essential to monitor the logs generated by both Privileged Access Manager - Self-Hosted and the infrastructure on which it runs. Early detection is one of the key elements in reducing the impact of any issue, whether security or operational.

Best practices:

  • Aggregate CyberArk application and infrastructure logging within your SIEM

  • Monitor and alert upon excessive authentication failures, logins to the Digital Vault server operating system, logins as Administrator or Master and important infrastructure events

  • Consider implementing CyberArk PTA for automated analysis and alerting on anomalies in CyberArk’s audit logging

Even with extensive controls and best practices in place, as attackers continuously seek evolved, sophisticated attack methods, things can still go wrong. Having a documented disaster recovery plan that specifically takes into account your organization’s CyberArk deployment, and periodically validating it will ensure that you can quickly recover your data and restore operations.

A good disaster recovery plan begins with an assessment of the various risks, the likelihood of occurrence and impact. The disaster recovery plan needs to provide information about the physical infrastructure, key contacts, processes to access out-of-band credentials and procedures to recover from likely and/or high-impact problems. Furthermore, it is important to ensure that your CyberArk solutions, PAM - Self-Hosted in particular, are included and accounted for as a vital step in recovery as part of your general disaster recovery process, throughout the enterprise.