Digital Vault Security Requirements
This topic describes the security requirements for the Digital Vault.
The CyberArk Digital Vault Security Standard requires the following:
The Digital Vault software must be installed on a dedicated physical machine.
The dedicated Digital Vault Server should be created based on a clean operating system installation rather than on an organization’s standard image, which likely includes additional software and standard configurations.
A dedicated machine with a clean operating system minimizes the security risks associated with third-party software. Such risks include software vulnerabilities, which could be exploited by attackers, or the need for custom server configurations, which may introduce unnecessary security gaps, to eliminate interoperability issues.
Installing the Digital Vault software in a virtualized environment is covered later in this document.
The Digital Vault Server operating system must be hardened to the configuration and patch level supplied by CyberArk.
The Digital Vault server is a critical asset and must be hardened. The Digital Vault application installation includes hardening of the operating system for a standalone operating system. Setting the Vault as a standalone is a key security gate to protect it against domain attack vectors that can put the Vault and your environment at risk.
Windows Server 2016
The hardening of the operating system is based on the Microsoft Security Compliance Manager (SCM) server hardening recommendations. During application installation, the operating system is further hardened with configurations to meet the specific needs of the Digital Vault software.
For more information on Microsoft’s hardening recommendations, see the Microsoft Security Compliance Manager documentation.
Windows Server 2019
CIS guidelines are used by many organizations as security standards and best practices for defending IT systems of domain-joined machines.
These guidelines were reviewed and taken into consideration when designing the Digital Vault hardening for the standalone Digital Vault servers. Additional hardening configurations were added to meet the specific needs of the Digital Vault server, which are not covered by the CIS guidelines.
For more information about hardening the Vault, see CAVaultHarden utility.
To follow best practices, the Vault server administrator is configured to expire every 30 days. We recommend to rotate the Vault server credentials and store them securely in a physical safe.
For service users, rotate the credentials annually or when a system administrator with knowledge of the password leaves the organization. The password must:
-
Be at least 15 characters long
-
Contain both uppercase and lowercase letters
-
Contain at least one number
-
Contain at least one special character
The password should not be a dictionary password.
The Digital Vault software should only be installed on a workgroup server, as opposed to on a server that is part of the enterprise domain.
Installing the Digital Vault software on a domain member server requires enabling protocols and services that are otherwise disabled and exposes the Digital Vault to the wider array of attacks available against members of a Windows domain, such as pass-the-hash or golden ticket attacks. Exposure to these attacks could enable an attacker to compromise credentials stored in the Digital Vault software.
Furthermore, having the Digital Vault Server as a domain member server could also potentially lead to the following:
-
Malicious or accidental changes in domain GPO, which may directly impact the security level of the Digital Vault Server.
-
The opening of firewall ports, as required by domain membership, which introduces additional external attack vectors.
-
The activation of normally disabled services, which can introduce security vulnerabilities and pivot points that expose the server to additional internal attack vectors. These services may also create additional availability risks due to operational vulnerabilities.
-
Additional, unnecessary risks created by Domain, Enterprise and Schema Administrator access to the Digital Vault Server.
The Digital Vault Server must be built from the original Microsoft installation media, and no third-party software, such as anti-virus or remote management solutions, must be installed.
To avoid the potential for untrusted operating system components or the inadvertent introduction of third-party software, it is important that the Digital Vault Server be built from trusted original media. Any third-party software installed on the Digital Vault Server introduces risks not present in a standard, secure configuration. Such risks include:
-
The opening of firewall ports, which introduce additional external attack vectors.
-
Security vulnerabilities, potentially present in any third-party software, can create pivot points and introduce new attack vectors.
-
Operational risks, including an impact to server availability, stemming from conflict between internal components of the Digital Vault and third-party software. Such conflicts often delay troubleshooting, which impacts CyberArk’s support SLAs and increase the time to resolution.
The Digital Vault Server operating system must be updated with Microsoft's issued security updates on a regular basis, per the organization's policy.
Applying Microsoft's monthly rollups ensures that the highest level of security is maintained on the Digital Vault Server.
CyberArk recommends that customers use the integrated procedure of applying Microsoft updates via the Windows Patch server to ensure smooth and on-going update of the Digital Vault Server while maintaining the security level of the hardened Digital Vault Server.
For more details, see Integrate the Digital Vault with a Windows Patch Server (WSUS).
The Digital Vault Server Key must be stored separately from the Digital Vault Server file system, and the Recovery Private Key must be stored in a physical safe.
To protect the database and data files that reside in the Digital Vault, CyberArk employs AES-256 encryption with a unique encryption key for each object. Since decryption is done only by the client requesting access to the data, the data encryption also protects the information from tampering.
To ensure security of the encryption keys, CyberArk strongly recommends that organizations adhere to the following best practices:
-
The Server Key should be stored on a Hardware Security Module (HSM) that integrates with the Digital Vault, thus separating the Server Key from the data it is encrypting.
-
The Recovery Private Key (Master folder) should be stored in a physical safe.
The Microsoft Windows firewall must be managed exclusively by the Digital Vault software, with only authorized inbound and outbound traffic permitted.
CyberArk utilizes and hardens the Microsoft firewall on the Digital Vault Server machine in such way that it verifies and permits only transmissions that are sent to the dedicated Vault port (by default – 1858), while blocking all other traffic. This restrictive firewall policy dramatically reduces the attack surface of the Digital Vault Server.
Using DNS on Digital Vault Servers can enable C2-based attacks.
To maintain the security and integrity of the Digital Vault, CyberArk requires complete isolation to prevent Command and Control (C2) channels. DNS is known to be used by threat actors as a covert channel to bypass network segmentation and utilize internal resources as an outside interface.
To prevent C2-based attacks, don't enable DNS on the Vault server except for the following use cases:
-
Integrating the Vault to send syslog notifications (see Security Information and Event Management (SIEM) Applications)
-
Integrating the Vault to authenticate with the RADIUS server (see RADIUS Authentication)
If you are using one of these integrations, adhere to the following guidelines so you don't compromise your Vault security:
-
Use the default DNS Cache setting, as described in the Microsoft documentation.
-
Patch your DNS server with all the latest security updates.
-
On the DNS server, open only those ports that will be used by the Vault.
-
For syslog integrations, configure the syslog using TLS.
-
For RADIUS integrations, use a strong RADIUS secret.