Application Rules are applied to Application Groups. Application Rules can be used to enforce allow, monitor, and assign privileges to groups of applications. They are a set of rules that apply to the applications listed in the Application Group.
You need an Application Group before you can create an Application Rule.
Insert an Application Rule
Click Application Rules to view, create, or modify the following for each Application Rule:
|Target Application Group||Select from the Application Groups list.|
|Run a Rule Script||
This option allows you to assign a rule script that is run before the Application Rule triggers.
You need to import a rule script before you can select it here.
Select the rule script you want to use from the dropdown list. If you select a rule script here, the following options change to Default to indicate that these actions are run if the rule script is not.
|(Default) Action||Select from Allow Execution or Block Execution. This is what happens if the application in the targeted Application Group is launched by the user.|
|(Default) End User Message||Select whether a message will be displayed to the user when they launch the application. We recommend using Messages if you block the execution of the application, so the end user has some feedback on why the application doesn't launch.|
|(Default) Access Token||
Select the type of token to be passed to be used for the target Application Group. You can select from:
Passive (no change): doesn't make any change to the user's token. This is essentially an audit feature.
Enforce User's default rights: removes all rights and uses the user's default token. Windows UAC always tries to add administration rights to the token being used so if the user clicked on a application that triggers UAC, the user would not be able to progress past the UAC prompt.
Drop Admin Rights: removes administration rights from the user's token.
Add Admin Rights: adds administration rights to the user's token.
For more information on access tokens, please see https://docs.microsoft.com/en-us/windows/win32/secauthz/access-tokens .
|Raise an Event||Whether or not you want an event to be raised if this Application Rule is triggered. This will forward to the local event log file.|
|Run an Audit Script||
This option allows you to select an Audit Script to run after the Application Rule.
You need to use Manage Scripts from the dropdown to import your Audit Script before you can select it.
Select the Audit Script you want to use from the dropdown list.
For more information, please see Manage Privilege Management Audit Scripts.
|Privilege Monitoring||Raises a privileged monitoring event.|
|McAfee ePO Reporting Options|
|ePO Threat Events||Select this option to raise an ePO Threat event. These are separate from Privilege Management Reporting events.|
|BeyondInsight Reporting Options|
|BeyondInsight Events||When configured, sends BeyondInsight events to BeyondInsight.|
|Privilege Management Reporting||Select this option to raise a Privilege Management Reporting event. These are available in Privilege Management Reporting.|
After you change the policy, click Submit and then Save to save the policy. In ePO 5.10 and later, if you have McAfee Approvals workflow enabled, this workflow can be modified to change the Save button to Submit for Review based on user permissions.
Application Rule Precedence
If you add more than one Application Rule to a Workstyle, then entries that are higher in the list will have a higher precedence. Once an application matches an Application Rule, no further rules or Workstyles will be processed. If an application could match more than one Workstyle or rule, then it is important that you order both your Workstyles and rules correctly. You can move Application Rules up and down to change the precedence.