Many organizations face the same challenging questions in their initial deployment of the EPM tool.

1. Where do I even start with for the policy design?
2. How can I use EPM to allow and block applications?
3. How do I find local administrators privileges on the endpoints?
4. How can I prevent users from running applications outside of these trusted folders (Windows, Program Files)

EPM is designed with the flexibility to control and elevate applications, many of the above questions can be achieve with the out-of-the box QuickStart policy template that combines BeyondTrust best practices into a set of rules that make it easy to get started with proactive endpoint protection. Out-of-the-box, the user’s security level is immediately improved without degrading the user experience or by “locking them down”. 

This is designed to be successful even with very little knowledge of the applications installed in an environment before deployment.

Workstyle purpose

The QuickStart Policy consists of six preconfigured Workstyles (Windows) four (macOS) ready to be assigned to appropriate user roles within the organization.

All Users (“Global”)

This workstyle contains preconfigured rules that are common across all types of users, regardless of the job role.  These include rules for Block Listing, Isolation, common business applications and OS functions, and EPM support tools. 

High Flexibility

This workstyle is designed to be provided to users who would need a lot of autonomy over their endpoint and would be very difficult to restrict.  e.g. Developers, Engineers etc.

Medium Flexibility

This workstyle is designed to be provided to users who would occasionally install new applications, but when they do – they must justify their actions with a reason.  e.g., Teleworkers, Marketing etc.

Low Flexibility

This workstyle should be provided to users who would never need to install or make any changes to their endpoint themselves.  Any such changes should be managed through a central service desk.  e.g., Kiosk, Call Centers, Sales etc.

Administrators

This workstyle should be provided to users with local administrator rights on endpoints to track users with privileged access.  

User Account Control replacement

Without the client installed, and a policy enabled, the user experience will still be that of a native Standard User with User Account Control (UAC) turned on.

Any attempt with a modification to system settings that has a UAC icon next to it will require the user to input an administrator password.  

Enabling the “All Users” and “High Flexibility” workstyles by selecting them and invoking the same action, the dialogue just opens - this is an example of seamless elevation.  This happens because the “High Flexibility” workstyle, contains a rule allowing these users to make changes to system settings such as Network Adapter Properties as this is an expected activity. If any of the other menu items, that have a UAC shield, are selected - you will be presented with the EPM customized UAC replacement message allowing the user to proceed without having to obtain an administrator password.  This action will now be audited and visible within the Windows Event Log and the Privilege Management Enterprise Reporting dashboards to show if the user accepted or cancelled the prompt.

Most modern applications that need admin rights are programmed to request admin permissions in this way.  This UAC trigger makes it very easy for EPM to capture, and learn, all applications without having to identify them upfront. 

Application control

Having already removed admin rights and gained control of all Privileged Applications, this functionality of EPM allows you to incorporate an Approved List, and control, all other applications on the machine that runs in the context of the Standard User account.  It also provides Block Listing functionality to prevent any targeted apps from running.

Most modern applications can install to disk and execute without ever prompting for Admin rights.  This can happen as the ProgramData and AppData paths provide alternative install locations where only standard user privileges are required to modify.  These areas are heavily exploited by malware and spyware as they do not prompt for permission to install or execute from these paths.

Trusted ownership

Having removed admin rights from the user, we can leverage the NTFS security model by using a combination of attributes identifying application location along with the Trusted Ownership model.  Trusted Ownership is applied to all things installed by System, Administrators & TrustedInstaller and provides a dynamic way of trusting an endpoint without the need to list out every application.  

The Standard User is now the owner which means it lacks Trusted Ownership and does not match the EPM rules for the Trusted Build.  This is now also true for anything the user introduces into the environment.  This includes things executed from removable media and the alternative install folders discussed above.

As with the Privilege Management rules, EPM utilizes a firewall-style rules engine that allows the specific rules for those trusted parts of the build to be positioned higher than the catch-all for all other applications.  Any apps that do not match the first rule will still be allowed to run but audited so that they can be easily reviewed later, or the execution controlled further based on the user’s workstyle.

Policy design

Once the QuickStart policy has been reviewed and understood how policy rules will be applied out-of-the-box, then the next step is to look at Policy Design for Allow Listing. 

The first consideration when designing the policy is the type of Allow Listing approach.  As mentioned in the previous section there are two distinct policy features: Application Control and Privilege Management.  Before piloting a decision should be made if both features are to be included in the policy.  Meaning, should rules be created for applications which require administrative and standard user rights or only focus on applications which require administrative permissions?  Answering this question first acts as the blueprint for policy building during the analysis and configuration phase.

When the approach has been agreed upon, there are several policy configuration items, which should be reviewed and decided upon when building an Allow Listing policy.  If this can be done before piloting, it can streamline the data analysis and policy configuration during the piloting phase. 

When looking at a policy design before pilot, the following decision points should be looked at:

• User Types
• User Profiles
• Trusted Applications
• Miscellaneous Considerations
• Allow Listing Goals

User Types

User types are synonymous with the Workstyle concept.  Similar user roles should be grouped into a Workstyle.  Before deploying the QuickStart policy a review should be done in defining the various user roles to be managed within the EPM policy. Some design considerations around this are:

• Less is better: If roles can be consolidated this will alleviate administrative overhead when it comes to policy maintenance within Workstyles (e.g. IT Admins and Developers make up one Workstyle, while HR, Finance and Marketing comprise another Workstyle).
• Security Roles: Managing groups of users in a Workstyle can be controlled via Active Directory (AD) security groups.  Ideally, new AD Security Groups can be created to map to a Workstyle.  So, if IT Admins and Developers fall into a High-Flexibility workstyle, then a security group could be created called X-EPMHighFlex (where X is the organization name).  EPM policy rules can then be managed by moving users into AD Security Groups. 

If the idea is all users are standard users and Workstyle High-Flexibility users are the exception, then one AD Security Group could be created for this group and let the default EPM filters apply to all other users.  Thus, limiting the number of AD Security Groups to manage.

User profiles

If the user types have been identified (i.e. Workstyle types), the next step is defining what the user capabilities are (e.g. making configuration changes or installing software).  Generally, with user profile building, IT Administrators will require additional flexibility for their job roles (installing software, making configuration changes), and standard users usually need less flexibility around configuration changes.  However, this can and will vary by organization.

When designing user profiles, it should be around Privilege Management aspects first. For standard users this could be changing Wi-Fi settings, or it could be installing an application suite. 

Identifying what the user capabilities are prior to pilot will help with the following:

• Shorten the data analysis cycle as applications and/or settings have been configured within the policy
• A template is built for each user type, which can act as the blueprint for policy building decisions

As part of the Privilege Management Policy Editor (MMC-snap-in) deployment there are several templated applications, which can be exposed within the policy. 

Trusted applications

Once Workstyles and profiles have been defined, another design configuration/consideration is adding known or “trusted” applications to the policy prior to pilot. This can reduce the data analysis process during the piloting phase. If we refer to the Trusted Ownership section in the QuickStart Policy overview, this can act as a guide as to what is inherently trusted within the QuickStart policy.

When looking at sources of truth for known applications, there can be a number of sources to look at. Depending on the Software Asset Management (SAM) maturity level, this can influence where to pull data from. If there is a SAM database, this can be leveraged to pull an extract of installed software and/or trusted applications. 

If there isn’t a database to pull from, another option can be a “Gold” image, which will have core applications represented, as well other application installations (depending on the imaging process).  The installed applications can be extracted by manually reviewing the Uninstall registry key: HKLM Software\Microsoft\Windows\CurrentVersion\Uninstall.

If a gold image or SAM database isn’t available, another potential option could be a software share library where software packages are stored. 

If there are no sources of application data available, then the data collected during the piloting phase can be used to build the policy out.

Miscellaneous considerations

Usually when deploying BeyondTrust Endpoint Privilege Management and moving to an Allow Listing posture, one of the main concerns/goals is removing users as local administrators.  For most users (who are standard users) the impact can be negligible. However, for IT Administrators and/or Developer users the impact may be noticeable in different ways (this can and will vary by the organization). A few items to consider prior to the pilot for mitigation and/or identification:

• Command Line Tools – One of the configuration items within the QuickStart policy is to not allow Child Processes to inherit from a Parent Processes when being invoked from a Command Line tool (e.g. PowerShell or CMD). 
  • A common misunderstanding is when a user executes cmd.exe or PowerShell.exe via the Run As Administrator option, everything else will be elevated.  Due to security concerns, EPM limits this out-of-the-box.  While this can be mitigated easily (by allowing Child Processes to inherit from the Parent Process), the ideal way to mitigate this would be to identify common command line admin functions used.  In the supporting documents see the Windows UAC.txt file, which identifies System32 applications, which require administrative rights.
• Developer Tools – One of the more complicated groups to build an Allow Listing policy for are developers.
  • Usually, developers are local administrators on their machines and can have any number of Integrated Development Environment (IDE) tools installed: Visual Studio, JetBrains, and Eclipse amongst others. In addition to IDE tools, you can expect miscellaneous open source tools to be downloaded for emulators, package managers and other functions. 

When looking at how to mitigate the impact to developers once local administrator rights have been removed in conjunction with Allow Listing, the following can help assist:

• Have discussions with Subject Matter Experts (SME’s) within the organization and understand the tools that are being used for the various development functions.
• Work with SME’s to build a list of “supported” development tools. This needs to be socialized with other developers, so it can be referenced when various 3rd party open source tools are downloaded and asked to be supported.
• Top-down “buy-in” is crucial when deploying an Allow Listing policy to developers. Initially during a rollout; perceived or actual issues can be escalated to management teams without taking the time to validate.  Support may need to come from upper management if necessary. There cannot be enough communication during the pilot phase when working with developers.

Allow Listing Goals

The next part would be defining what Allow Listing will look like (Allow Listing only applications which require administrator or standard user rights). When looking at how an Endpoint Privilege Management Allow Listing policy can be built, there is any number of ways this can be created (all methods can be applied to rules which reflect standard user or administrative rights to run).

The following are ways in which policy rules can be built, with the pros and cons of each approach (combinations of each can be used).

• Hash – This is the most secure method, as each policy item is being generated by a unique hash. However, this method does have its drawbacks.  Each time a version changes or updates occur with the application a policy change needs to be made. Additionally, there is an additional compute cost used to evaluate a policy rule due to the hash.
• File Path – The idea here is like the file hash, where for each unique file path a unique rule is created. As with hash rules there can be significant administrative overhead, due to version changes or application updates.
• Trusted Publisher – The digital signature of the file is evaluated during execution. The pro to this method would be blanket rules can be created for trusted publishers and can be added to elevated and/or standard user rules. The downsides to this method are the digital certificate may have expired, which can change workflow of the expected behavior.  Additionally, there is the outside chance the signing authority being comprised. 
• Source URL – This option will allow applications which have been executed with a source URL to be trusted. This option can be combined with online software distribution libraries (e.g. SCCM) to allow for installations from a specific URL.  The downside to this is not every organization can support this type of management option.  Additionally, there needs to be oversight on what applications have been added to the repository.
• Trusted Location – A server share(s) can be allocated or built, and software packages can be saved there. Using NTFS permissions for user access, software can be downloaded and/or installed from the trusted location.  The downside to this method is the oversight to validate legitimate software resides in the trusted location.

Piloting

Once all the design elements have been completed, the next phase is to deploy the initial policy (either the QuickStart baseline or QuickStart with additional rules built into it). The purpose of the pilot is two-fold:

• Identify through reporting which applications have been executed, either with administrative or standard user rights.
• Gather user feedback based on policy deployment, and as needed removing local administrator rights.

During the pilot phase, the pilot group(s) should be a representation of all users that will have EPM deployed to them. There should pilot members from IT, developers, standard user groups (e.g. HR, Finance) and any other organization specific business unit.  Additionally, if this deployment will be on a global level, there should be representation from those users as well.  Global site contacts should be identified early on to facilitate feedback if there are language barriers.

When piloting, the number of pilot users will depend on organizational strategies for deploying and/or testing enterprise software.  However, if piloting can be targeted to 10-20% of the total deployment this should allow for edge cases, and other potential application specific issues to be identified and a plan to be put in place to remediate.

Analytics reports

The Dashboard is the Analytics landing page. Use the filters to hone in on a specific time period, computer group, or OS. The data points are Top Event Actions and Endpoint User Logins.

• Top Event Actions: Displays a graphical view of the actions data being tracked. Actions include Allowed, Elevated, Cancelled, Self-Elevated, and Blocked. The Count is the number of events. Click the link to drill down to the Events page to learn more.
• Endpoint User Logins: Endpoint User Logins chart shows the Windows users active in your estate, broken down by Domain or Local and Admin or Standard (requires the User Logins general rule).

 Discovery Dashboard (On-prem)

Summarizes all the unique applications discovered. It differentiates between those that used elevated privileges and those that ran with standard privileges. The Discovery reports display the data from different angles such as by the location of the executable or the type of the executable. These dashboards only show new application items in the chosen time interval. For example, the Discovery dashboard can answer the question what’s new this week and how is it affecting my users?

More dashboards are also available for on-prem solutions.

Dashboard and Reports in Endpoint Privilege Management Reporting

​