Phase 3 – Launch and execution

Review the CyberArk system requirements for the CyberArk Digital Vault servers and component servers. Ensure dedicated servers will be provisioned accordingly and identify the system capacity based on meet design requirements.

CyberArk’s guidance on how to properly secure the CyberArk Digital Vault server. Note that third-party connections from the CyberArk Digital Vault server to outside software can increase the attack surface of the CyberArk Digital Vault server. As such, CyberArk provides built-in tools to enable secure backup and monitoring so that third-party software is unnecessary.

Key recommendations for protecting your CyberArk deployment, and therefore your privileged accounts.

It is highly recommended that organizations leverage the built-in SNMP and syslog tools to monitor the health of the CyberArk Digital Vault server as well as all activity on the server.

The CyberArk Digital Vault Server Security Standard dictates that no third-party software be installed on the CyberArk Digital Vault Server. To retrieve logs for troubleshooting while adhering to this standard, it is recommended that you use the PrivateArk Client to retrieve logs from the CyberArk Digital Vault Server and then use Notepad ++ on your desktop machine to view the logs.

CyberArk recommends that organizations use a hardware-based load balancer of their choice. If the organization is unable to use an existing load balancer, they may also use Microsoft Network Load Balancing (NLB), which is included on each operating system. For those who choose this option, CyberArk documentation includes information on how to configure NLB for CyberArk solutions.

To validate user identities before allowing access to PVWA. Review list of supported authentication options (RADIUS, SAML, RSA, etc.) in the document Privileged Access Security System Requirements

To securely store the CyberArk Digital Vault server key

To monitor and alert on the health of the CyberArk Digital Vault and components

To monitor activity on the CyberArk Digital Vault Server, on the component servers and within the CyberArk Privileged Access Security Solution itself. Alerts on privileged accounts (whether they are sent to a SIEM from CyberArk Privileged Threat Analytics, or generated from a SIEM directly) should be closely monitored to help ensure the security of both the CyberArk Privileged Access Security Solution and your privileged accounts

To leverage existing processes for controlled change requests on target systems

To enable email notifications for reports and Event Notification Engine integration

To enable time synchronization on the Vault and DR Vault servers

Vault Administrators should be native CyberArk users, meaning they should have individual accounts that are managed within the CyberArk Privileged Access Security Solution directly.

End Users, Auditors and Safe Owners should be managed using an external directory (AD, LDAP, etc.). This division allows for large scale user management via external directories while maintaining additional security for high-privileged users such as Vault Administrators. Vault Administrator credentials can be stored within the CyberArk Enterprise Password Vault so that organizations can audit Vault Admin account usage as well as secure administrative access to PVWA and PrivateArk client sessions using via CyberArk Privileged Session Manager.

Users and groups from an attached directory service will be used to grant safe access. Each group will be configured as a “safe member” with the appropriate access rights. As users are added to defined groups in the directory, they will automatically gain access to the configured safes. Similarly, users who are removed from defined groups will automatically be removed from the CyberArk Digital Vault.

The CyberArk Privileged Access Security Solution offers comprehensive management of internal users. If there is no directory service available or an organization prefers to not rely on it, they can create local users and groups in the CyberArk Digital Vault. This can either be done manually or automatically using one of the many APIs CyberArk offers (i.e. REST API, Command Line Interface, etc.). When managing users locally, CyberArk can support local authentication as well as any external authentication service that is configurable (LDAP, RADIUS, SAML, etc.).

Require users to submit a request to management whenever an account is needed

Require users to specify a ticket number for informational purposes or for verification

Force accounts to be checked in and out and only one user can be in possession at a time

Credentials automatically change after every use

The Accounts Feed scans the Active Directory for machines and then reaches out to all machines to scan for accounts. The Accounts Feed can also scan a defined list of UNIX systems to discover accounts and credentials. Following the scan and discovery, privileged accounts and credentials are placed into a “Pending Accounts” page, from which one can select specific accounts to onboard into specific safes. The Accounts Feed continually scan OUs and machines to automatically onboard privileged accounts from newly created servers. The Accounts Feed allows for a more flexible discovery of the following accounts and retains the ability to analyze and provision them with service account dependencies:

• Windows Local Accounts;

• Domain Accounts;

• Windows Services and Scheduled Tasks;

• UNIX Local Accounts;

• SSH Keys and their trusts.

Password Upload Utility takes a .csv file of accounts and places them into safes as defined within the file itself. This is the most common approach when the CyberArk Privileged Access Security Solution is displacing another password vaulting solution.

This process enables automatic provisioning via:

• Windows Local Accounts;

• VMWare Unix/Linux guest machines;

• VMWare ESX Host root accounts;

• Local and Domain Service account usages;

• Application accounts based on directory queries.

Verify and/or acquire Terminal Server Licenses and RDP Services CAL licenses. CyberArk Privileged Session Manager is based on Microsoft Terminal Server Technology and thus requires the appropriate Microsoft licenses. It’s important to ensure there are sufficient CAL licenses and a licensing server available.

Review the PSM for SSH OS requirements to ensure the ability to run and operate a supported OS. PSM for SSH is a Linux-based system supported on several – but not all – versions of RHEL, SUSE and CentOS. Note that PSM for SSH operates similarly to an appliance after installation. As such, default management processes and tools may require certain exceptions (such as OpenSSH) in order to remotely support the PSM for SSH server.

Organizations should ensure sufficient storage capacity for session recordings on the CyberArk Digital Vault Server and CyberArk Privileged Session Manager servers. A basic estimation of required storage is usually 250kb/min per recorded RDP session and 60kb/min per recorded SSH session. Most storage will be required on the CyberArk Digital Vault server. However, depending on the Master Policy and the number of sessions chosen for recording, a large amount of storage on CyberArk PSM/PSM for SSH servers may be required.

Group policy settings should be configured to allow the CyberArk Privileged Session Manager to work securely. Since these servers are usually domain members, an organization’s GPOs will apply to them. Be aware of common GPO settings that can stop the CyberArk Privileged Session Manager from functioning. For example, “AllowLogonLocally” should include the local CyberArk Privileged Session Manager group. CyberArk can supply GPO files to set all necessary policies so that CyberArk Privileged Session Manager is able to work properly. Additional information can be obtained from CyberArk Security Services engineers.

Load balancing should be configured to handle peaks in access. CyberArk Privileged Session Manager will most likely become the only way for administrators to remotely access target systems. Load balanced farms can help handle load peaks and avoid system outages.

Over time, application security becomes increasingly important. While application integration can be a big project, there are some quick wins that can be easily achieved:

• Vulnerability scanners. CyberArk partners with vulnerability and inventory scanning vendors to deliver out-of-the box integrations for joint customers. These scanning solutions typically need privileged access to run properly, and that access can be securely enabled through the CyberArk Digital Vault with minimal effort;

• Application Server Credential Provider (ASCP). CyberArk offers pre-compiled modules for the major Java Application Servers (WebSphere, JBoss, WebLogic, Tomcat). With ASCP, there is no need to alter any application code; a new authentication provider is simply added to the application server and the configuration changed from the default authentication provider to the CyberArk ASCP module;

• Securing for the future. It is much easier to build security in up-front than to retrofit existing applications. Organizations should consider policies that require securing all new application credentials used to communicate with other servers, services, databases, etc., in the CyberArk Digital Vault.

When considering application security, one of the most important steps in each of these processes is to work with the application teams (managers, developers, owners, etc.) as early as possible, showing them the benefits of application security, understanding their existing processes, and getting their buy-in before making any changes.

When deploying AAM, it is beneficial to engage certified CyberArk experts in conducting a workshop to prepare for integration of the solutions into organization’s development life-cycle. Organizations should consider having technical overview that includes:

• Understanding how the products will address the existing challenges;

• Enabling the developers with best practices and decision matrix;

• Defining the provisioning process for providers, safes, accounts, etc.;

• Integrating with the existing software development lifecycle (SDLC) in areas of change management, integration, and deployment;

• Managing the project for component installations and/or credentials retrieval.

Organizations should learn what is legitimately needed within their environments, and start by restricting privileges that are not needed. Rules can become more restrictive over time while still allowing for seamless privilege elevation as needed, based on policy. An immediate revocation of all administrator privileges at once can result in user frustration and an overwhelming influx of calls to the help desk, as many users may legitimately need administrator privileges to complete day-to-day business tasks.

When deploying CyberArk Endpoint Privilege Manager, organizations should consider the best practices for privilege management and application control. One can begin with solution architecture, inbox settings, and policy creation along with the deployment and rollout methodology. CyberArk Endpoint Privilege Manager Quick Start Guide, CyberArk Endpoint Privilege Manager Solution Guide, and CyberArk Endpoint Privilege Manager Installation Guide are good references to review.

CyberArk’s recommended control is to remove workstation administrator privileges from end users and provide temporary elevation of privilege when required.

• Detect advanced threats with CyberArk Privileged Threat Analytics (commonly deployed with CyberArk Enterprise Password Vault).

  • CyberArk Privileged Threat Analytics looks for signs of lateral movement or privilege escalation in real time. It works by establishing a baseline of normal and using that baseline to detect anomalies. To gain the most insightful results, it’s recommended to let CyberArk Privileged Threat Analytics start learning as early as possible.

  • CyberArk Privileged Threat Analytics also integrates out of the box with CyberArk Enterprise Password Vault to help organizations automatically contain threats and onboard unmanaged privileged accounts. It provides a “single pane of glass” view, correlating intelligence from privileged credential management with privileged threat analytics. Considerations for this integration include:

    • Threat containment. As CyberArk Privileged Threat Analytics detects potentially compromised credentials, it can send alerts to CyberArk Enterprise Password Vault to trigger an automatic password change. Depending on the phase of a deployment, it may be preferable to review the alert, decide if a change is needed, and then manually click a button to prompt the rotation. (If all account dependencies have not yet been onboarded, an automated password change could potentially result in account lockouts). However, once all dependencies have been onboarded, this automated rotation can save time for the security team.

    • Account discovery and onboarding. When integrated with a SIEM solution, CyberArk Privileged Threat Analytics can detect privileged logons that originated from accounts not managed by CyberArk Enterprise Password Vault or CyberArk SSH Key Manager and send the account information for easy onboarding. It’s recommended that each unmanaged privileged account first be evaluated to ensure the account is not malicious. Users should be notified in advance that their accounts will be onboarded to the CyberArk Privileged Access Security Solution, and ensure that these users have the necessary access to it.

Control user privileges in UNIX using CyberArk On-Demand Privileges Manager. When managing privileges with CyberArk On-Demand Privileges Manager, it’s recommended to start by restricting the most “destructive” commands first (i.e. “rm –rf /*” or “visudo”, etc.). If an organization is already using sudo, they can simply re-build the existing sudo rules in CyberArk On-Demand Privileges Manager.