Security Fundamentals for your

Privileged Access Security

Deployment

January 2019

Copyright © 1999-2019 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-PASSF 4/17/2019
2 Table of Contents

Table of Contents

Security Fundamentals 3
Recommendations for Protecting your CyberArk Deployment 4
Digital Vault Security Standard 8
The CyberArk Digital Vault Server security standard 8
Requirements 9
Handle Exceptions to Enterprise Policy 11
Non-conformance 15
Security implications 15
Support implications 16

Privileged Access Security

 3

Security Fundamentals

Compromising privileged accounts is a central objective for any attacker, and CyberArk’s
Privileged Access Security Solution is designed to help improve your organization’s
ability to control and monitor privileged activity. As with any security solution, it is essential
to deploy the CyberArk Privileged Access Security Solution in a secure manner and
ensure the controls you have implemented are not circumvented by an attacker.
The eight controls described in this document are all key recommendations for protecting
your CyberArk 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 recommendations
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, page 8.
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. Please review your CyberArk deployment on a regular basis to
ensure it complies with industry best practices, including those outlined in this document.
For questions or assistance with designing and implementing these controls or support in
reviewing your deployment, contact your CyberArk or partner representative.

Privileged Access Security

Security Fundamentals for your Privileged Access Security Deployment 4

Recommendations for Protecting your CyberArk

Deployment
Isolate and harden the Digital Vault Server
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. For more information, see Digital Vault Security Standard, page 8.
Critical principles of this control:
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 the Integrate the
Digital Vault with a Windows Patch Server (WSUS) section in the
PAS Installation Guide
CyberArk strongly recommends using a dedicated WSUS Server for
updating the Digital Vault
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, it is strongly
recommended that Digital Vault servers be physical servers.

Use two-factor authentication

Using two-factor authentication to the CyberArk Privileged Access Security Solution
for all users and product administrators enables you to mitigate common credential
theft techniques, such as basic key loggers or more advanced attack tools that are
capable of harvesting plaintext passwords. CyberArk recommends that customers
deploy two-factor authentication to the CyberArk Digital Vault, preferably over
RADIUS protocol.

Restrict access to component servers

Like the Digital Vault server, CyberArk components, including the Password Vault
Web Access, Central Policy Manager and Privileged Session Manager, are sensitive
assets. The core principle of this control is to treat CyberArk infrastructure with the
highest level of sensitivity.

Privileged Access Security

5 Recommendations for Protecting your CyberArk Deployment

Critical principles of this control:

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 more information, refer to 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.
CyberArk does not recommend installing all the components on the same server
in the DMZ.
CyberArk does not recommend 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 CyberArk Privileged Session Manager and
the local administrator account to access component servers
Deploy application whitelisting and limit execution to authorized applications
Apply Microsoft security updates regularly using WSUS

Limit Privileges and Points of Administration

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.
Critical principles of this control:
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 CyberArk Privileged Session Manager to isolate and monitor CyberArk
administration
Require two-factor authentication for all avenues of administrative access

Protect sensitive accounts and encryption keys

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 (e.g. the
Master user), to be used when the normal administration methods are not available.

Privileged Access Security

Security Fundamentals for your Privileged Access Security Deployment 6

Furthermore, the CyberArk Digital Vault 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.
Critical principles of this control:
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

Use Secure Protocols

The use of insecure protocols can easily render other controls void. 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 Password Vault
Web Access, LDAPS for the Digital Vault LDAP integration, RDP/TLS for
connections to the CyberArk Privileged Session Manager and SSH (instead of telnet)
for password management.

Monitor logs for irregularities

In order to detect problems early, it is essential to monitor the logs generated by both
the CyberArk Privileged Access Security Solution 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.
Critical principles of this control:
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 Privileged Threat Analytics for automated
analysis and alerting on anomalies in CyberArk’s audit logging

Create and periodically test a CyberArk Disaster Recovery Plan

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 should 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,
Privileged Access Security in particular, are included and accounted for as a vital step

Privileged Access Security

7 Recommendations for Protecting your CyberArk Deployment

in recovery as part of your general disaster recovery process, throughout the

enterprise.

Privileged Access Security

 8

Digital Vault Security Standard

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.

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.

Privileged Access Security

Security Fundamentals for your Privileged Access Security Deployment 9

Requirements
The CyberArk Digital Vault Security Standard requires the following:

Install the CyberArk Digital Vault software on a dedicated physical machine

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.

Harden the Digital Vault Server operating system

The Digital Vault Server operating system must 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)

The Digital Vault Server must 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.

Privileged Access Security

10 Requirements

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
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.

Store the Digital Vault keys securely

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 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 Digital Vault software must manage the Microsoft Windows firewall
The Microsoft Windows firewall must be managed exclusively by the Digital
Vault software, with only authorized inbound and outbound traffic permitted.

Privileged Access Security

Security Fundamentals for your Privileged Access Security Deployment 11

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.

DNS must not be used on 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.
DNS must not be enabled on the Digital Vault Server.
CyberArk recommends using PABackup over other third-party backup tools.

The Digital Vault Server installed on the cloud must be hardened

Installing the Digital Vault on AWS or Azure requires hardening.
For details on AWS security, see the Security Overview section in Deploying
Privileged Access Security on Amazon Web Services.
For details on Azure security, see the Security Overview section in Deploying
Privileged Access Security on Microsoft Azure.

Handle 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.
Various enterprise solutions may conflict with the CyberArk Digital Vault Security
Standard and customers might inadvertently create risk by not conforming to the
standard.

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

Privileged Access Security

12 Handle Exceptions to Enterprise Policy

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.

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.

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.

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

Privileged Access Security

Security Fundamentals for your Privileged Access Security Deployment 13

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.

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.

Privileged Access Security

14 Handle Exceptions to Enterprise Policy

■ 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.

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. Automatic 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.

Privileged Access Security

Security Fundamentals for your Privileged Access Security Deployment 15

■ 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.

Non-conformance
This topic describes security implications of not conforming 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 following security risks:

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

Privileged Access Security

16 Non-conformance

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.

Place 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.

Privileged Access Security