Phase 5 – Mature the Privileged Access Security program
Step 1: Going “wide” with basic controls and “deep” with advanced controls
After the initial implementation of the CyberArk Privileged Access Security Solution, organizations will continue their privileged account security program throughout the enterprise using the same processes – moving to functional accounts, onboarding the new accounts created, vaulting the built-in accounts, rotating them, and then using CyberArk Privileged Session Manager and CyberArk Privileged Threat Analytics for isolation and monitoring.
Goal: Continue to go “wider’ with the controls outlines in steps 1-3.
For coverage beyond Windows accounts, understand the scope of all privileged accounts. Privileged accounts exist for a wide range of technologies such as Oracle databases, UNIX and Apple computers, NAS and SAN storage devices, any device with an IP address, hypervisors and operating services in virtualized environments, and cloud services.
Examples: Network Devices, Web Apps, Out of Band Access (iLO, DRAC), etc
Goal: Apply privileged account security controls to non-human IDs, account usage, privileged sessions, or user behavior analytics.
Organizations should look at enhancing controls to monitor account usage. For the most sensitive accounts, for example, they may add video recording of privileged sessions or user behavior analytics.
Just as human use IDs, controls need to be applied to service accounts as well. Creating an ‘exception’ for service IDs is no longer viable. A good privileged account security program will seek to include the automatic rotation of service ID credentials, as well as possible removal of hard coded credentials to its list of use cases. CyberArk typically recommends that a full-service account management deployment take place after some of the initial use cases detailed in this document are completed. This is to help build confidence in the solution among the user base and organization, and to have a better understanding of key CyberArk concepts before tackling a more technically complex use case.
Examples: Windows Services, Scheduled Tasks, IIS App Pools, Registry Keys, Hard-Coded passwords, Container Based IDs in J2EE platforms
Goal: Apply privileged account security controls to refactor applications.
Applications, especially legacy ones, are often designed to require administrator privileges and have passwords embedded in ways that make password rotation difficult. Organizations need to ensure in general, all applications are granted the minimum necessary privileges and use passwords securely. To address these issues usually requires reconfiguring or rewriting applications. This includes not only homegrown but also third-party applications. In some cases, organizations will have to work with vendors to make changes.
Goal: Granularly control what commands and applications privileged users can access in Windows and *nix.
In addition to simply locking down credentials and isolating sessions, for sensitive systems, it may be necessary to actually restrict what accounts are able to do on endpoints once they get there. Being able to limit what commands or applications can be launched under the context of various user IDs can limit the effectiveness of malware or its ability to be used in the first place.
Additionally, this ensures that internal employees only have permissions commensurate with their job responsibilities to help compliance with regulatory agencies and mitigate the risk of attacks.
Step 2: Formalizing the program with metrics for success
By locking down the credentials, isolating and controlling sessions, and then monitoring behavior, the security posture of an organization is increased in an efficient, and controlled manner, with limited impact to production processes.
Program success can be tracked by many different factors, such as decreasing the average number of credentials per user per team, decreasing the number of privileged accounts without an owner, uncertified privilege accounts, looking at the number of password resets done per time period, and, of course, the percentage of accounts vaulted and managed vs. the number of accounts still existing.
These success factors are based on concrete metrics that are clearly defined. As these metrics are tracked and updated through the reporting tools of the CyberArk Privileged Access Security Solution (as well as other means, such as SIEM reports or account workflow audits via a ticketing solution), organizations will gain a solid grasp on the success of the privileged access security program with tangible results.
Establishing processes for maintaining and supporting the new controls and looking at questions such as “What are the processes for adding new assets to the system and de-provisioning obsolete ones?” help ensure that processes can keep up with changes in the business--and regularly validate that security and business goals are being met.
Measure privileged account security program processes
Perform CyberArk DNA scans once a month to discover unprotected backdoors.
Test and prove effectiveness against real world attacks
Perform periodic attack simulations (e.g., using CyberArk Red Team Services) to verify effectiveness of controls.
Enable Vault Administrators to be certified and become CyberArk SMEs.
Leverage CyberArk Security Services to accelerate program and knowledge transfer.