IBM Security Policy Framework (DPF)

This topic outlines a legacy policy set and deployment methodology for IBM Security Verify Privilege Manager.

With Verify Privilege Manager version 11.4.1, an updated set of Workstation policies were developed for use in the Policy Wizard, that takes a stepped approach to defining and implementing policy sets. IBM Security recommends the use of these Workstation policies going forward. Workstation policies are also referenced along with the predefined Computer Groups in the isvp-manager Tutorial.

Approach

The biggest risk when implementing Endpoint Privilege Management (EPM) solutions like IBM Security Verify Privilege Manager is impacting user productivity. This approach has several key aims, which are highlighted below:

Take the best practices learned from thousands of successful implementations and make them available to all customers.
Provide reduced time to value, with a policy set that can be enabled in seconds.
Simplify and reduce the overhead of day-to-day management of endpoint privilege and application management.

As an example, where a user’s admin rights are removed on a Monday and they come into work on a Tuesday to discover that applications they need to run to perform their core job function cannot run or are missing functionality without administrative privileges. This approach mitigates that risk by ensuring that during the initial stages of a deployment users are provided with flexible ‘on demand’ elevation to run applications with elevated privileges where required.

This means that admin rights can be removed without the need for lengthy discovery phases meaning customers get more value from the solution from the point of implementation.

One Size Does Not Fit All

Different users and communities of users require very different application sets and privilege levels in their endpoint environment. The IBM Security policy approach allows customers to define users or groups of users into a high, medium, or low privilege filter based on Active Directory group membership or by targeting individual users. A high-level summary of the out of the box user experience is provided below.

High Privilege: Provides users with a 'Pseudo Admin' experience, any application can be elevated on demand by right-clicking and selecting run as administrator. This policy set is typically aimed at the most technical users such as Developers and IT administrators.
Medium Privilege: Provides users with a highly flexible experience where most applications can be elevated on-demand. High risk applications such as scripting engines require approval for elevated execution. This policy set is typically aimed at technical users.
Low Privilege: Provides a highly secure application environment where users are unable to run any application with elevation without approval. This policy set is typically aimed at non-technical users who do not regularly need to install new applications.

The out-of-the-box user experience can be changed in a few clicks by replacing messaging. Customizable messages can be used to change the effective privilege levels at any point from a warning message to a justification or approval workflow.

Application Control

The approach also utilizes an intelligent approach to application allow-listing that leverages the core security concept of trusted file ownership.

Applications with trusted ownership (owned by Local System, Trusted Installer, Administrators by default) that are commonly found in the enterprise environment, will be allowed to execute out of the box. Applications that don't match against the allow list will hit a catch-all policy. The catch-all policy starts with a 'soft' audit approach, which allows customers to monitor unknown applications and refine allow listing before hardening the catch-all to an appropriate level for different user communities.

Policy Set Overview

The following section provides a high-level overview of the policies included in the TPF policy set.

Priority	Policy Name	Behavior Description
5	THY - Malware Protection Policy	Catches any unsigned and untrusted application that runs as a child process of high-risk applications such as Microsoft Office applications, email clients and browsers.
6	THY - LOLBAS Attack Protection	Protects vulnerable applications from being exploited using 'Living off the Land Binaries and Scripts' attack vectors.
11	THY - GLOBAL - Blocked Applications	Targets explicitly defined applications and denies execution with a visible message. All applications matching this policy are audited.
12	THY - GLOBAL: Silently Elevated Applications	This policy targets explicitly defined executable applications and elevates the application with no visible messaging.
13	THY - GLOBAL: Silently Elevated Installers	This policy targets explicitly defined Microsoft Installers and elevates silently.
14	THY - GLOBAL - Allow List (Explicit)	This policy targets explicitly defined applications that are approved for non-elevated execution.
21	THY - HIGH PRIVILEGE - Silently Elevated Applications	This policy targets explicitly defined executable applications for high privilege users and elevates the application with no visible messaging.
22	THY - HIGH PRIVILEGE - Silently Elevated Installers	This policy targets explicitly defined Microsoft Installers for high privilege users and elevates the application with no visible messaging.
23	THY: HIGH PRIVILEGE: High Risk Applications	This policy targets a list of powerful, high risk applications. Users will be prompted for justification when elevating these applications. All applications matching this policy are audited.
24	THY - HIGH PRIVILEGE - High Risk Windows Settings	This policy targets high risk windows settings areas and presents a justification message which needs to be completed before execution is possible. All applications matching this policy are audited.
25	THY - HIGH PRIVILEGE - UAC Replacement (Signed Applications)	Targets any signed application that generates a User Account Control (UAC) dialogue. A warning message is displayed prior to elevated execution. All applications matching this policy are audited.
26	THY - HIGH PRIVILEGE - UAC replacement (Unsigned Applications)	Targets any unsigned application that generates a User Account Control (UAC) dialogue. A warning message is displayed prior to elevated execution. All applications matching this policy are audited.
27	THY - HIGH PRIVILEGE - Allow List (Trusted Owners)	This policy will allow applications with a trusted owner or that are explicitly defined to run with standard user rights, no messaging is displayed.
28	THY: HIGH PRIVILEGE - Catchall	This policy targets any application that has not matched against a previous policy for users defined within the High Privilege filter. This policy should not be enabled without High Privilege - Allow List also being enabled, doing so will generate large amounts of feedback data.
31	THY - MEDIUM PRIVILEGE - Silently Elevated Applications	This policy elevates targeted applications for users defined within the Medium Privilege Filter.
32	THY - MEDIUM PRIVILEGE - Silently Elevated Installers	This policy elevates targeted installers for users defined within thee Medium Privilege filter with no messaging displayed.
33	THY - MEDIUM PRIVILEGE - High Risk Applications	This policy targets high risk applications and presents an approval workflow prior to elevated execution.
34	THY - MEDIUM PRIVILEGE - High Risk Windows Settings	This policy targets high risk windows settings areas and presents an approval workflow prior to elevated execution. All applications matching this policy are audited.
35	THY - MEDIUM PRIVILEGE - UAC Replacement (Signed Applications)	Targets any signed application that generates a User Account Control (UAC) dialogue. A warning message is displayed prior to elevated execution. All applications matching this policy are audited.
36	THY - MEDIUM PRIVILEGE - UAC replacement (Unsigned Applications)	Targets any unsigned application that generates a User Account Control (UAC) dialogue. A warning message is displayed prior to elevated execution.
37	THY - MEDIUM PRIVILEGE - Allow List (Trusted Owners)	This policy will allow applications with a trusted owner or that are explicitly defined to run with standard user rights, no messaging is displayed.
38	THY - MEDIUM PRIVILEGE - Catchall	This policy targets any application that has not matched against a previous policy for users defined within the High Privilege filter. This policy should not be enabled without High Privilege - Allow List also being enabled, doing so will generate large amounts of feedback data.
41	THY - LOW PRIVILEGE - High Risk Applications	This policy targets high risk applications and presents an approval workflow prior to elevated execution.
42	THY - LOW PRIVILEGE - High Risk Windows Settings	This policy targets high risk windows settings areas and presents an approval workflow prior to elevated execution. All applications matching this policy are audited.
43	THY - LOW PRIVILEGE - UAC Replacement (Signed Applications)	This policy targets any application that generates a UAC prompt and has a valid digital certificate. Elevated execution requires approval.
44	THY - LOW PRIVILEGE - UAC replacement (Unsigned Applications)	Targets any application that generates a UAC prompt and does not have a valid digital certificate. Elevated execution requires approval.
45	THY - LOW PRIVILEGE - Allow list (Trusted Owners)	Targets any application that is owned by a trusted owner or explicitly defined applications and allows non-elevated execution with no visible messaging.
46	THY - LOW PRIVILEGE - Catchall	Targets any application that has not been matched against a higher priority policy. This policy allows on-elevated execution with no visible messaging. All applications matching this policy are audited.

Deployment Steps

Download the latest version of the Thycotic Policy Framework (TPF) from the Config Feeds. Once installed, the policy set is available in the Thycotic Policy Framework folder, usually at https://[yourprivilegemangerinstance]/TMS/PrivilegeManager/#/folders/all/dfa7db45-f75c-4e31-be53-6281b1d4ce39].

Initial Configuration Steps

In addition to installing the config feed with the policy set and following the general initial setup guidelines, the following configuration should be performed:

Set up Active Directory / Azure AD integration for administrative console access and policy targeting.

To allow users to authenticate with the Verify Privilege Manager administrative console using their AD or Azure AD identity you should configure the AD or Azure AD integration. This can also be used to target TPF policies to specific users or security groups.

Build User Context Filters and or Resource Targets for Policy Targeting

Verify Privilege Manager policies can be targeted at the user and or computer level. To target policies to specific users or security groups User Context filters can be created. The TPF set comes with three out of the box user context filters for High, Medium and Low Privilege Users.

Adding Users to High, Medium, or Low Privilege User Context Filters

In the Verify Privilege Manager console search for High Privilege Users or select the High Privilege Users filter from any of the high privilege policies.
Search for and add local or domain users or Active Directory Security Groups to the filter:
Click Save Changes.

Verify Privilege Manager also provides the ability to build resource targets, which are groups of computers that policies can target.

Policy Management and Refinement

Before deploying any policies, you should add any known applications to relevant policies. For example, if you are aware of corporately approved applications that are used by all users which require admin rights, you can add application filters to the THY: GLOBAL: Allow List (Explicit) policy.

There are a number of ways application targets can be created:

Manually by creating a blank win32 filter and targeting specific application metadata fields.
By uploading an application file.
Waiting for the TPF policies to generate application audit events and creating filters directly from the event.

Policy Refinement after Deployment

On a regular basis (as frequently as possible during the initial stages of the deployment) open the Policy Events Report:
From the left-hand menu, select Policy Events.
The report should default to sorting by the # of events field.
For each application in the list, review and decide how you want to handle the application. There are a number of options to consider:
- Add to Global: Silently Elevated Applications or Installers to allow silent, elevated execution for all users.
- Add to High/medium: Silently Elevated Applications or Installers to allow silent, elevated execution for users within the scope of the chosen policy.
- Add to restricted applications to allow execution with approval workflow.
- Do Nothing (User will continue to receive UAC replacement messaging, which will likely be hardened).
- Add to Global: Block List.
  
  Note: The key consideration in making this decision, is the number of users executing the application and the number of times they are executing it. The higher these numbers the more impactful gating the application with an approval workflow would be.
Once number of new applications hitting UAC replacement plateaus, add more users to scope OR harden UAC replacement.
If application Control is required, review applications hitting catch-all, review and perform one of the following actions:
1. Add to High/Medium/Low Allow List.
2. Add to Global - Block List.
3. Do nothing (Application will be gated with approval workflow when catch-all is hardened).
4. Once number of unknown applications hitting the catch-all plateaus, add more users to scope AND/OR harden catch-all.

Frequently Asked Questions

Q1. Why is there no user context filter for low privileged Users?

A1: This is by design, as the Low Flexibility policy set does not have any user context inclusion filters. It will apply to any user that is not in the scope of the High or Medium Flexibility policies. Effectively, the Low Privilege policy set functions as a catch-all policy set and avoids the risk that user is not included in a filter and has no policies applied.

Q2. Why are there no Silent Elevation policies for low privilege users?

A2: It is highly unlikely that applications need to be elevated for low privilege users without being elevated for all users. Typically, any application requiring elevation for low privilege users can be targeted in the global elevation policies.

Q3. Why is the catch-all policy configured to allow unknown applications to run?

A3: Any policy set that attempted to block or gate unknown applications at the point of deployment would be highly disruptive to users and/or generate high volumes of approval requests to support teams. Catch-all policies are intended to quickly collect audit data that can be used to refine allow listing before being hardened.