CyberArk Endpoint Privilege Manager is the authority in endpoint group policy management, with an ever-growing toolset used to empower end-users and strengthen security simultaneously. EPM is robust enough to manage any organization size, while being configurable to match each organizations goals and plans. Defining a business organization’s goals is pivotal to developing the proper strategy for deployment and integration.
We will dive into common situations any organization will experience with implementation as well as understand the culture shifts that occur in alignment with security integration.
Defining Core Business Goals
Most of us were introduced to the CyberArk EPM application as a method for managing the removal of local admin rights. CyberArk EPM can also manage Ransomware Protection, Threat Detection, immediate default-deny, white list integration and provide robust data to assist with enterprise maintenance.
Is your organization experiencing Ransomware attacks? We will enable this immediately to lock down common file types attackers use for ransomware. Threat detection to prevent LSASS credential theft, denying all new applications after deployment and application use data are all features to be implemented depending on the business’ needs.
Many organizations may want some, if not all the features CyberArk EPM has to offer, however we must define what is most crucial first, to devise a proper strategy for rollout, that is conducive to the organization’s timeline.
It may be an organizations directive, to move remove local administrative rights as quickly as possible to meet strict SLAs in accordance with their stakeholders. Understanding the timeline requirement, will allow for proper strategy surrounding deployments, acceptable troubleshooting SLAs and resource allocation.
Another situation may call for the removal of local administrative rights, application inventory, threat detection and access management entitlements. Be sure to understand current company objectives and devise a plan that will meet target deadlines; while being transparent with common pain points and culture changes. It is important to ease our customers into changes that will affect their daily workflow.
Pre-Deployment Enterprise Configuration
CyberArk EPM is best defined as a suit of armor that protects your endpoint user base in your enterprise. In a perfect world, where an organizations’ AD environment is clean and properly structured, software deployment methods are in place and User Account Control is properly set via GPO, the rollout of EPM becomes very smooth.
Of course, in the real world, businesses are always upgrading, managing acquisitions and attempting to move forward with the best tech products and security.
There are several things to be done, to prepare an organization for EPM deployment. First, we must define whether an on-prem or SaaS solution will be used to manage the SQL server. Depending on the businesses’ needs, this will differ.
For example; The on-prem solution allows for simple Splunk integration, while the SaaS solution requires API calls that will need to be routed to your Splunk solution.
There is also no disaster recovery solution for a SaaS solution, as the backend AWS servers managing SQL are not in your control.
Active Directory implementation has improved with the SaaS solution, such as in AD user/computer group implementation and as upgrades of EPM are released, the SaaS solution continues to improve in its ability to match any on-prem environment.
Secondly, we want to ensure that we whitelist all 3rd party security applications that currently exist in the enterprise, to ensure that we are not creating conflicts with existing security tools.
Next, we want to ensure that we define our AD security groups, so that delegation of policies can be distributed easier. For example, we should have a CyberArk EPM AdminsAD security group, containing users that will access the on-prem or SaaS portal and who will use the CyberArk OPAG tool for one-time application elevation.
EPM utilizes event collection, both old and new, to gather data of all applications used since inception on a user endpoint. In order to see these events, the endpoint must have User Account Control (UAC) enabled with specific GPO security settings. UAC enables Windows security to manage the elevation of events and these app triggers allow EPM to see and manage the event via policy.
UAC also protects Microsoft Windows protected directories. Therefore, completing this step first in advance will allow users to migrate files and data to their user profile, rather than wherever they want, to ensure proper app execution, should their files require write access.
A common pain point when enabling UAC in an environment, are users who are used to having local admin rights. This is especially true for developers who create their own build folders for coding. This implementation often represents the first major culture shift in your organization, and it is important that this is properly communicated to affected end-users.
It is suggested that much like EPM, the GPO for UAC enablement should be deployed in a phased approach across all OUs in the organization. A first time 10% push to each OU will ensure that each organization would only experience a 10% impact should an issue occur, in addition we will receive feedback from our users. This feedback will let us know which OUs maybe need a slower deployment approach due their user’s file management, allowing their teams a timeline to become UAC compliant.
Based on our initial feedback after the first deployment, scale up or down and assess a proper timeline for completion.
Finally, we want to setup a single test workstation. This can be a standard image endpoint from the business or a VM, but we want to ensure there are both a standard and admin user profile added to this endpoint as well. This will allow us to deploy the agent and test the differences in workflow between the two accounts, while applying policy. We will enforce policy on this test workstation, to experience the same results our end-users will experience once we enable policy enforcement in production, across the enterprise.
Without a VM or a test workstation, EPM engineers will find it difficult to create policies based on applications they may not have full insight into; this creates a lot of one on one troubleshooting situations with end users, especially with robust developer applications that may require child elevation, admin menu abilities, etc.
Does your organization store their software on network shares? Is there a central repository for applications in the organization? If so, work with the Software distribution teams to install these applications on your test machine. This way, you can quickly edit policies and test immediately and make your policies as granular as possible while still having full functionality. This creates a lot less back and forth troubleshooting with you and your customers.
Don’t forget! After our first deployment, we will want to rollout to a larger group, maybe for a proof of concept or simply to collect more data, to continue building policies and testing further. Utilize the groups in your organization that are easy to reach, people that are on your team perhaps. IT and R&D users will generally match these criteria.
Privilege Management Inbox Settings for Deployment Phase
It is very important to understand, that with the removal of local admin rights, the business in question will go through a culture change and many developers and app specialists who are used to doing things a certain way, may have to drastically change their workflow.
EPM makes this process as painless as possible. The privilege management inbox displays events from user endpoints that require elevation. Set the inbox to monitor all events, while simultaneously allowing all of them to elevate.
This will allow the organization’s users to continue working as normal, while EPM admins build policies according to the events being collected.
There may be events in troubleshooting with end-users where the software needs to be uninstalled for troubleshooting purposes and we may leave agent itself unprotected from uninstallation to allow this to happen during this phase.
Policy Management for Deployment Phase
After deploying to IT and R&D team members, we will very quickly see a lot of events that need review in our inbox and there are a few things to keep in mind. First, our goal is to whitelist the products and applications that we know are safe and used abundantly in our organization.
Almost every organization (if sorted by events largest to smallest) will see Google Chrome towards the top of their inbox. This is an example of an application we know is widely used and trusted. By sorting our Privilege Management by events, we will begin whitelisting applications globally and manage the majority used applications via policy quickly.
Going after the big applications first will eventually get your organization to a state, where one off applications and advanced policies are being created to manage specialty apps, usually from your developer teams. This means after ‘going live’ (policy enforcement) the impact to organization will be very minimal in single digit percentile range.
Utilizing the Trusted Source option for a policy means, (for example), I trust Google LLC as publisher, so please allow Chrome.exe to run and elevate if necessary. In addition, we will ensure that child processes follow their own policies, so that Chrome.exe doesn’t become an elevation platform for ransomware.
Second, be sure to also name your policies appropriately, as we will come back and make these more granular later. For example, we name our advanced policy for SQL installers; SQL Installation Packages and use this advanced policy for SQL installation builds. Proper naming conventions will ensure a much better management process for your EPM Console.
Simply right-click on an event in our inbox and elevate it by checksum, but we are creating more work to deal with in the future. Rather than making many individual policies, start to think about how many applications could be combined into one advanced policy.
For example, we know our organization will most likely have Microsoft Office Suite installed. Rather than making a MS Word, Outlook, Access, Excel, etc. policy, make one Microsoft Office Applications advanced policy and place all these apps into this singular policy. This is also a great way for handling installation packages. Most organizations will have one or more teams that manage software updates and rollouts. Communicate with these teams and get copies of these installation packages. Create advanced policy and place all your standard installation packages that are global into this policy.
This will make it much easier to update your policies in the future, when deployment package versions and possibly locations of these packages change.
After Full Enterprise Deployment
We want to limit the impact to our business’ end-user workflow as much as possible, and as a result more open policies will initially be in place. For example, instead of placing the from and to versions of a software into policy, leave this blank until we have reviewed our application usage across all end-users.
Over time, utilizing EPM’s great reporting structure, we see every application that is being used, frequency of use and who it is being used by. We may also see every version being utilized and begin to get more granular with our policies, weeding out unnecessary old versions of Java or ensuring we aren’t using more instances of an application than we have licenses for.
As suggested above, think ahead. Create advanced policies (which allow multiple application GPOs) to manage what you anticipate seeing a lot of.
COM Objects and Windows Admin Tasks are one of your initial advanced policies you will implement and there should be one named DEV ADMIN TASKS and STANDARD ADMIN TASKS. Set Windows Admin Tasks to run normally (without elevation) to the entire enterprise (via STANDARD ADMIN TASKS), while the DEV ADMIN TASKS policy elevates Windows Admin tasks and allow only the user groups we want to have these privileges, such as the help desk.
As discussed in Pre-Deployment Enterprise Configuration, we live in an imperfect world, where businesses are constantly growing and changing. Ensure that while we implement security controls to protect our environment, we are simultaneously limiting workflow impact. Users need to be protected from themselves and attackers, while also continuing their jobs daily. Consider the 80/20 rule, where deployment and implementation (80%) represents more open policies and 20% represents the improved granularity of these policies after full enterprise deployment.
Communicate and work with your application teams! You will find the majority are enthusiastic to be a part of a secure environment than empower their tools while protecting them attacks.