Phase 4 – Rapid risk mitigation
In the fourth phase, organizations develop a roll-out plan, identify a small group of accounts that will be used as a “pilot,” identify (or create) a group of test accounts for each group and identify issues and update the roll-out plan as needed.
Step 1: Load and Verify
Goal: Populate the CyberArk Digital Vault with privileged accounts identified in Phase 2 (Step 2, Define Scope) from critical assets (Tier 0) systems and set up an automated verification process to confirm account credentials are accurate.
The verify feature of the CyberArk Enterprise Password Vault and CyberArk SSH Key Manager allows organizations to gain assurance that all the account information in the CyberArk Digital Vault is accurate and that accounts are known and ready for use or change. The verify feature does not modify credentials in any way and simply logs in as the account to confirm the credential is correct. This will help users get comfortable with interacting with CyberArk and acts as a prelude to setting up an automatic credential management program.
These accounts may be considered first: Domain Administrator Accounts, Server Administrator Account;
These accounts may be considered next (depending on the organization, these controls may need more time): Workstation Local Administrator Accounts, Root, SYS, Enable, SA, etc.
Goal: Introduce the concept of connecting directly via CyberArk.
In addition to the show and copy options, this functionality provides users with the ability to connect directly to target devices using privileged account credentials. Using the connect button secures account credentials such that they do not need to be visually exposed to be used. This will help set the stage for the revocation of the show/copy options in later phases.
The following workflows can be inserted into any step of the phased approach:
Dual control requires users to submit a request to management whenever an account is needed;
Ticketing integration requires users to specify a ticket number for informational purposes or for verification.
Exclusive accounts forces accounts to be checked in and out; only one user can be in possession at a time;
One-time passwords ensures credentials automatically change after every use;
Email alerts are sent to subscribers any time an account is.
Pilot groups are rolled out with the method identified from the accounts onboarding process.
The rest of the pilot group are rolled out using identified methods, such as Accounts Feed, Bulk Upload - Password Upload Utility, Auto-Detection, REST API SDK etc.
Step 2a: Rotate Credentials
Goal: Begin the process of managing credentials via the CPM.
Select a subset of accounts to manually change using the Change Now button in the CyberArk Digital Vault. This will allow confirmation that CPM is ready to begin changing credentials and help administrators and users adjust to automated credential changes.
Examples: Workstation Local Administrator Accounts & SSH Keys.
Goal: Get the CPM to manage accounts automatically based on enterprise policy.
During this stage organizations turn on the automatic credential management capability of the CPM. Depending on organizational need, this can be done based on a fixed timeline (e.g., every 90 days) or every time an account is used and checked back in (i.e., through one-time passwords). This will help give assurance that systems are in compliance with internal and external requirements and bolster the security of privileged accounts.
Goal: Ensure credentials are correct in CyberArk and automatically change them if out of sync.
By turning on account reconciliation you allow the CPM to ensure that accounts under its management are accurate and that, in the event they are changed externally (whether accidentally or maliciously), the CPM can automatically generate a new password and synchronize the new password to the vault. This will prevent users from taking a privileged account and changing the credential manually to something they know in an attempt to bypass security.
Step 2b: Isolate & Monitor
This should be done in conjunction with Step 2a. The Rotate Credentials process is not dependent on the Isolation & Monitor process, since they are separate modules. While accounts are being managed, organizations can include high value asset credentials that will benefit from CyberArk Privileged Session Manager and CyberArk Privileged Threat Analytics, further expanding the credential boundary.
Goal: Require users to connect exclusively via CyberArk and no longer expose credentials to end users or their machines. Do not allow administrative access to sensitive assets from Internet-connected workstations and limit use of admin accounts to admin tasks only.
The show and copy buttons are removed from end users for Tier 0 accounts. They are required to click connect. The session will be connected via CyberArk’s Privileged Session Manager component without exposing the credentials to the end user or their machine. The CyberArk Privileged Session Manager will create secure brokered sessions to target devices via a ‘ jump server’ that also provides session recording and monitoring capabilities. All sessions are brokered from the CyberArk’s Privileged Session Manager server using native protocols such as RDP or SSH. Additionally, it allows the integration of any application client in use at the organization with a Universal Connector functionality.
CyberArk Privileged Session Manager isolates sessions to Tier 0 assets, isolates workflow enforcement and records user activity.
Examples: Domain Administrator Accounts, Server Administrator Accounts, Workstation Administrator Accounts, SAN Controllers, ESX, Critical Business Applications, Security Appliances, etc.
Goal: Quickly identify anomalous behavior on critical assets and the CyberArk Digital Vault server.
The CyberArk Privileged Threat Analytics virtual appliance is deployed and forwards syslog data from the CyberArk Digital Vault and in-house SIEM solutions. CyberArk Privileged Threat Analytics will then start to create automated baselines for normal user activity on both endpoint assets (e.g., Windows servers, *nix servers, Oracle databases) and the CyberArk Digital Vault itself. Alerts are issued whenever there is behavior that deviates from this norm. Not only will this flag signs of a potential attack in progress, but trigger an automatic password change to slow down the attack progress in cases of a suspected credential theft (where a system was accessed without a prior credential retrieval in CyberArk).
Examples: Irregular Hours, Excessive Access, Irregular IP, Irregular Target, Suspected Credentials Theft, Unmanaged Privileged Accounts, etc.
Enables organizations to block and contain attacks on endpoints and servers to reduce the risk of information being stolen or encrypted and held for ransom. Starting with Tier0 assets helps eliminate irreversible network takeover attacks.
Completely removing all endpoint users from the local administrator group on IT Windows workstations can be a good start to reduce the risk surface of the Pass-the-Hash techniques. Given that IT Windows workstations have higher risk in terms of having elevated permissions and contain local administrator rights for endpoint users, this helps prevent lateral movements in the enterprise.
Step 3: Standardize for production roll-out
During this phase, additional primary groups will be rolled out per the updated roll-out plan. Management functionality, workflows, and permissions should be confirmed along with the solution design—and analysis performed on the use cases/requirements for the next phases based on organization’s roadmap. Organizations will receive review and advice on resolving gaps in the architectural design, solution design, and implementation phases of the project.
Goal: Have Administrators use built-in accounts and access credentials via a vault.
Minimize the use of individually assigned administrative accounts, which can lead to account proliferation.
For some organizations, it may not be feasible to remove individually-assigned Administrator accounts in the short term. An initial approach is to vault the credentials for the individually-assigned Administrator accounts, then, over time, move from using individually-assigned accounts to the built-in accounts.
Examples: Domain Administrator Accounts, Server Administrator Accounts, Workstation Administrator Accounts.
Goal: Extend controls detailed in Step 2b to additional endpoint systems.
In addition to on-premise Tier 1 assets, another area organizations should consider would be secrets used by machine identities and users in DevOps environments (e.g., embedded credentials in CI/CD tools). This reduces the risk of compromising highly privileged API keys that are embedded in code and CI/CD tools.
Examples: Hard-coded credentials on applications, databases, Exchange servers, etc.
How many AWS root accounts and API keys are not vaulted?
Are Ansible, Jenkins and other tools credentials embedded in free text?
Goal: If any applications use Domain Administrator privileges, such as domain rights to multiple servers, remove those privileges.
For some organizations, it may not be feasible to address all of these applications within the short term; work to reconfigure or rewrite applications will continue over time.
Examples: Application Accounts