The CyberArk Digital Vault

Security Standard

March 2016

Copyright © 1999-2016 CyberArk Software Ltd. All rights reserved.

This document contains information and ideas, which are proprietary to
CyberArk Software Ltd. No part of this publication may be reproduced,
stored in a retrieval system, or transmitted, in any form or by any means,
electronic, mechanical, photocopying, recording, scanning, or otherwise,
without the prior written permission of CyberArk Software Ltd.
CAVSEC-DVST-0316
Overview
CyberArk’s products manage organizations’ most sensitive information, including the
keys to the IT kingdom. As such, CyberArk is committed to providing enterprise-
ready products that are designed to provide the highest levels of security to protect
our customers’ most valuable assets.
To help our customers effectively secure their CyberArk solution, CyberArk has
introduced the CyberArk Digital Vault Security Standard. By implementing the
CyberArk Digital Vault in accordance with the Digital Vault Security Standard,
customers will be able to apply the highest levels of protection to this highly sensitive
system. It is imperative that customers implement the security standard described in
this document in order to maintain the level of security that is built-in to Digital Vault
software and used to protect your most sensitive information.

© CyberArk Software Ltd. | cyberark.com 2

The CyberArk Digital Vault Server Security
Standard
The Digital Vault software is the core of CyberArk’s solutions. It is the secure
repository of all sensitive information, and it is responsible for securing this
information, managing and controlling all access to this information, and maintaining
and providing tamper-proof audit records. As such, the security requirements for the
Digital Vault Server, the server on which the Digital Vault software is installed, are
very strict.
To help customers effectively secure the Digital Vault Server, CyberArk has
introduced the CyberArk Digital Vault Security Standard, which defines a set of
security controls and implementation procedures designed to significantly reduce the
system’s attack surface. The high level of security required by the Digital Vault
Server likely differs from commonly used server configurations.
The CyberArk Digital Vault Security Standard requires the following:
 The Digital Vault software shall 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 shall be hardened to the

configuration and patch level supplied by CyberArk.
The Digital Vault application installation includes hardening of the operating
system 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.
Because the Digital Vault Server is configured to serve only CyberArk protocol
requests, the hardening process deactivates many operating system services that
are not required for the operation of the Digital Vault application. As such, it will
not function as a regular domain member in a Windows network.
For more information on Microsoft’s hardening recommendation, refer to the
Microsoft Security Compliance Manager documentation.
(https://technet.microsoft.com/en-us/library/cc677002.aspx)

© CyberArk Software Ltd. | cyberark.com 3

 The Digital Vault Server shall not be a member of any enterprise domain.
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 shall be built from the original Microsoft installation
media, and no third-party software, such as anti-virus or remote
management solutions, shall 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.

© CyberArk Software Ltd. | cyberark.com 4

 The Digital Vault Server Key shall be stored separately from the Digital
Vault Server file system, and the Recovery Private Key shall be stored in a
physical safe.
To protect the database and data files that reside in the Digital Vault, CyberArk
employs FIPS 140-2 compliant 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 that
integrates with the Digital Vault, thus separating the Server Key from the data
it is encrypting.
 The Recovery Private Key (Master CD) should be stored in a physical safe.

 The Microsoft Windows firewall shall 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.

© CyberArk Software Ltd. | cyberark.com 5

Handling Exceptions to Enterprise Policy
The CyberArk Digital Vault Security Standard may conflict with standards, tools and
practices commonly adopted by enterprise organizations. While these enterprise
standards seek to increase the security of the enterprise IT environment, they do not
take into consideration the unique needs of the Digital Vault Server.
To preserve a high level of security on the Digital Vault Server while accommodating
the operational needs of large enterprise organizations, CyberArk provides built-in,
tools for backup, monitoring and remote administration to help organizations manage
the Digital Vault Server.
Customers should use these native solutions rather than implementing their own
enterprise-standard solutions, which may increase the attack surface of the Digital
Vault Server.
This section describes the various enterprise solutions that may conflict with the
CyberArk Digital Vault Security Standard and how customers might inadvertently
create risk by not conforming to the standard.

 Enterprise policy requires anti-virus software on the Digital Vault Server.

Enterprise organizations need to protect systems from malware and, as such,
often require that anti-virus software run on all machines.
The CyberArk Digital Vault Security Standard prohibits the installation of anti-
virus software on the Digital Vault Server because such an installation removes
security enhancements applied during the server hardening process and requires
the server’s Firewall rules to be loosened.
When the Digital Vault Server conforms to the CyberArk Security Standard, it
denies remote access to the server’s file system and does not allow file system
interaction with any potentially malicious content uploaded to the Digital Vault
Server itself. That only remotely accessible network service is CyberArk’s Digital
Vault application. This significantly reduces the risk of a malicious agent infecting
the Digital Vault Server.

 Enterprise policy requires monitoring software on the Digital Vault Server.

As a critical component in the enterprise infrastructure, organizations may want to
install monitoring agents on the Digital Vault Server machine.
To satisfy the need for server and application monitoring, the CyberArk solution
natively supports in the use of SNMP traps to provide operating system health
information both in a “state-full” and “state-less” format. These messages include
CPU, memory, disk utilization, swap memory utilization, Windows OS logs and
internal Vault logs. Additionally, automated e-mail notifications and syslog
messages to the organization’s SIEM tool can notify Vault Administrators of
important system events such as DR and Backup component status, license
utilization and more. Various alerting systems can be configured to accept these
traps and alert Vault Administrators of any actionable event.

© CyberArk Software Ltd. | cyberark.com 6

 Enterprise policy requires backup and recovery software on the Digital
Vault Server.
The Digital Vault Server stores sensitive and critical data, and as such,
organizations require backup and recovery procedures to be in place.
To satisfy this requirement CyberArk provides, a Secure replication solution to
backup Digital Vault data to another servers, where it there becomes available for
standard enterprise backup. This process provides for both a secure method of
backing up the Digital Vault data and a shorter recovery time when compared to
the standard Windows Server recovery process.

 Enterprise policy requires Microsoft updates and patches to be applied

monthly.
As a standard practice, many organizations requires Windows servers to be
patched on a monthly basis.
Every Microsoft patch for relevant operating systems is reviewed by the CyberArk
Security Team. When a patch is deemed necessary, CyberArk notifies
customers, and the CyberArk Support Team is available to assist. With the
greatly reduced attack surface of a standard-conforming Digital Vault Server, a
vast majority of patches released are not required.

 Administrators need to remotely access the Digital Vault Server.

While CyberArk recommends only physical access to the Digital Vault Server,
remote administration of the Digital Vault is a common customer requirement, as
many organizations often have limited physical access to the Digital Vault Server.
The CyberArk Digital Vault Security Standard prohibits direct remote access
(RDP, VNC, etc.) to the Digital Vault Server because it significantly increases the
attack surface of the Digital Vault Server. When direct remote access is
configured, an attacker with any level of access on the network may be able to
open a connection to the Digital Vault Server and potentially tamper with the
server or its data.
To reduce the attack surface, CyberArk requires that the Digital Vault Server only
be accessible via a controlled remote console. CyberArk supports a variety of
available “out-of-band” technologies, such as iDRAC (integrated Dell Remote
Access Card), iLo (integrated Lights-out) or RSA (Remote Supervisor Adapter),
providing complete IP-KVM capabilities. If CyberArk appliances are being utilized,
iDRAC access is configured by default. With a controlled, remote console in
place, an attacker would first need to gain access to the remote console and then
attempt to connect to Digital Vault Server. This extra step makes it more difficult
for an attacker to gain unauthorized remote access to the CyberArk solution.

© CyberArk Software Ltd. | cyberark.com 7

 Organizations prefer to install the Digital Vault software in a Virtual
Environment
Customers may want to install the Digital Vault software in a virtualized
environment. Though the Digital Vault software is designed to install and run
seamlessly in both physical and virtual environments, a virtualized
implementation introduces risks not present in the standard configuration outlined
in the CyberArk Digital Vault Security Standard.
A virtual environment implementation includes remote attack vectors, both from
outside of the virtual host environment and from other virtual guest images,
bypassing physical datacenter security layers. This may allow an attacker to
obtain the whole guest image of the Digital Vault Server, which is a risk not
present in a standard, physical implementation.

The following are potential security risks associated with running a virtualized
Digital Vault Server and CyberArk’s recommendations to mitigate these risks
 An attacker can potentially initiate multiple, simultaneous “brute force”
password attacks against existing CyberArk user accounts. This risk arises
because an attacker can create unlimited copies of the virtual machine, and
with an unlimited number of machines, account lockout mechanisms can be
bypassed.
 There is no mitigating control for the risk of brute force attacks. Customers
who run the Digital Vault Server in a virtualized environment assume this
risk.
 This risk of an attacker successfully reverse-engineering the encryption of the
Digital Vault data is increased in virtual environments. To start the Digital
Vault software, the virtual machine must have access to the Server Key.
Because of this, implementation practices in virtualized environments require
the Server Key to be placed on the Digital Vault Server OS file system. In a
secure physical environment, such as an enterprise datacenter, the risk of
storing the Server Key on the file system can be mitigated by implementing
physical security controls. If an attacker takes possession of a virtual
machine, the attacker could have access to the operating system, Server Key
and encrypted data, making it possible to reverse-engineer the encryption
and gain access to the Digital Vault data.
 There are two mitigating controls available for this risk:
 Use a Hardware Security Module to securely store the Server Key
separately from the Digital Vault Server OS file system.
 Manually mount the Server Key each time it is required. This approach will
improve security, but it will cause the DR Vault instance to not be
available automatically during a disaster.

© CyberArk Software Ltd. | cyberark.com 8

 Organizations prefer to install the Digital Vault software in Amazon Web
Services (AWS)
In addition to the above mentioned risks and mitigations associated with a
virtualized Digital Vault Server, the following are conditions specific to AWS
environments that require consideration:
 Port 80 needs to be opened to specific AWS addresses.
By default, the Digital Vault hardening process ensures that outbound access
from the Digital Vault Server is limited in time and is used only in cases in
which the Digital Vault needs to access a third-party server for uses such as
authentication or provisioning (e.g.: LDAP, RADIUS, etc.). This ensures that
even if the Digital Vault Server somehow becomes infiltrated by a malicious
party, it would be as difficult as possible to exfiltrate any data from the Digital
Vault Server to the outside world. Hence, the opening of ports, as required for
the health of the AWS image, introduces a potential security risk.
The risk can be reduced by opening the port to only the three specific,
required AWS addresses.
 For customers using Syslog / SIEM Integration:
Sending syslog messages via an unencrypted protocol does not present a
risk within an organization’s internal network. However, when running the
Digital Vault Server in AWS, outside the internal network, customers should
use a syslog encryption tool and transmit the Digital Vault’s syslog output via
TLS (SSL) to the SIEM solution.

 Organizations prefer to install the Digital Vault software on Microsoft Azure

In addition to the above mentioned risks and mitigations associated with a VM
Vault, the following conditions are specific to Azure/Cloud environments and
require consideration:
 Port 80 must be opened to specific Azure addresses.
 By default, the Vault hardening ensures that outbound access from the Vault
is limited in time and is used only in cases where the Vault needs to access a
3rd party server for uses such as authentication or provisioning (e.g: LDAP /
RADIUS / etc). This ensures that even if the Vault somehow becomes
infiltrated by a malicious party, it will be as difficult as possible to exfiltrate any
data from it to the outside world. Hence, while opening ports is required for
the health of the Azure image, it introduces a potential security risk.
 Availability can be impacted when planned/unplanned maintenance on Azure
instances is made. Azure instance monitoring enables automatic actions on
the instance for planned/unplanned maintenance. TAutomatic actions include
automatically starting a machine that was stopped, instances moving between
hosts, restarts on updates, etc. All of those can damage server availability,
and we are not sure if there is an additional impact in those scenarios. It is
recommended to have servers in an availability set which can help make sure
that two servers (HA/DR) are not down together.
 Azure VM images may come with unwanted VM extensions, which can
potentially expose vulnerabilities. Use of VM extensions must be carefully
considered from a security aspect.

© CyberArk Software Ltd. | cyberark.com 9

Nonconformance to the CyberArk Digital Vault
Security Standard
Security Implications
It is essential to deploy CyberArk Solutions according to the standards and guidelines
described in CyberArk’s documentation. Adhering to the CyberArk Digital Vault
Security Standard and following CyberArk’s guidelines helps to ensure the security of
your deployment and significantly reduces the risk of an attacker being able to
circumvent the Digital Vault security controls.
Each security layer is built on top of the other, thus the removal of one layer (for
example, installing third-party software) will loosen another layer (for example,
opening the firewall to allow that third-party software to communicate) and eventually
significantly reduce the security of the Digital Vault.
Customers who choose to deviate from the CyberArk Digital Vault Security Standard
should be aware of the security risks detailed below:

Domain Membership
As mentioned above, installing the Digital Vault on a domain member server can
result in the following:
 Added risk of domain level attacks, such as pass-the-hash or golden ticket
attacks
 Malicious or accidental changes in domain GPO
 Vulnerability to external attack vectors due to opened firewall ports
 Vulnerability to internal attack vectors and increased operational risk due to the
enablement of unnecessary services
 Increased risk of inside attacks due to access by Domain, Enterprise and
Schema Administrators

Third-Party Software
As mentioned above, the installation of third-party software on the Digital Vault
Server introduces the following risks:
 Vulnerability to external attack vectors due to opened firewall ports.
 Exposure of the Digital Vault Server to all vulnerabilities and attack vectors
present in third-party software
 Impacted Digital Vault availability due to conflict between internal components
and third-party software
 Impacted support resolution due to the need for non-standard troubleshooting

© CyberArk Software Ltd. | cyberark.com 10

RDP Access
Customers may wish to use RDP as a convenient method of remotely accessing the
Digital Vault Server. However, as part of the hardening process, the Digital Vault
Server blocks communication via RDP. Customers should only remotely access the
Digital Vault Server via a remote console, such as KVM, HPiLO, or Dell iDRAC.
By removing this control, undoing the mentioned hardening, and enabling RDP
connections to the Digital Vault Server, the Digital Vault would become vulnerable to
attacks on Microsoft's RDP protocol.
Customers who wish to open the Digital Vault Server to RDP connections can select
this option during installation time if the Digital Vault is being installed via an RDP
connection. Note, the RDP connection will be configured to the specific IP address
from which the installation originated.

Placing Keys on the Vault

The Digital Vault Server requires access to the Server Key before starting the Digital
Vault application. It may seem obvious to place the Server Key on the Digital Vault
Server OS file system, but this may put the security and encryption of the Digital
Vault at risk. If an attacker were to gain access to the operating system, Server Key
and encrypted data, it would be possible for the attacker to reverse engineer the
encryption and gain access to Digital Vault data.
To mitigate this risk, CyberArk strongly recommends that:
 The Server Key should be stored on Hardware Security Module that integrates
with the Digital Vault, thus separating the Server Key from the data it is
encrypting.
 The Recovery Private Key (Master CD) should be stored in a physical safe.

Support Implications
CyberArk will provide best-effort support for Digital Vault Servers running in a non-
standard configuration.
However, running the Digital Vault application on a server that deviates from the
CyberArk Digital Vault Security Standard significantly reduces the security of the
solution. We strongly advise our customers to conform to the CyberArk Digital Vault
Security Standard so that our solution is able to operate in accordance with its
specifications.

© CyberArk Software Ltd. | cyberark.com 11