Rules are used to group rules together under a common condition.
For example, you may want to create a set of rules that only apply to a specific user. To do this you create a new User rule for James and create the rules that you want to apply just for him under executable control, privilege management and browser control. When an event occurs on an endpoint e.g. a user launches an application, the condition on the group is checked; in this case the condition is ‘is the currently logged in user on the endpoint james?’. If this is true then all the rules under the James rule set will be considered, if not then they are ignored for this event.
Note also that certain rules will apply only to certain events, those that don’t apply will just be ignored. For the event when a user launches an application the browser control rules would be ignored. For an event where a user navigates to a new web page the executable control and privilege management rules would be ignored.
In this section:
Rule nodes allow you to create rules targeting specific users, groups, and devices, and assign security level policies, resource access, and resource restrictions that apply to the users, groups, and devices that match the rules. There are six rule types:
Rule nodes provide Security Level settings for specifying the levels of restrictions to execute files. Application Control configuration rule settings security levels specify how to manage requests to run unauthorized applications by the users, groups, or devices that a rule matches:
- Restricted - Only authorized applications can run. These include files owned by members of the Trusted Owners list and files listed in Allowed Items, Trusted Vendors, and Trusted Applications.
- Self-Authorizing - Users are prompted for decisions about blocking or running unauthorized files on the host device.
- Audit only - All actions are permitted but events are logged and audited, for monitoring purposes.
- Unrestricted - All actions are permitted without event logging or auditing settings for specifying the levels of restrictions to execute files.
Rule nodes also provide a further layer of granularity for controlling application use with Allowed Items, Denied Items and Trusted Vendors for specifying lists of files, folders, drives and signature items, network connection items, Windows store apps, and groups that are allowed or prevented from running.
For more information for the relevant options for each Rule Type, see Rule Options.
To display all rules in the configuration, click Rules in the navigation tree. A summary displays all rules listed under the relevant rule type. The security level assigned to each rule is seen and can also be amended.
Apply security levels to control whether the user, group, and devices specified in a rule are fully restricted by Application Control rules, unrestricted, audited only, or granted self-authorization status entitling the user to decide whether to run an application. Self-authorized users can be audited by raising events in the Auditing component and the Windows Event Log.
Set the Security Level
To set the Security Level, select the required node and, using the slider, apply the required security level.
Select to restrict users, groups, and devices in the rule to run only authorized applications. These include files owned by members of the Trusted Owners list and files listed in the Allowed Items node.
Select to prompt users, groups, and devices in the rule to decide whether to allow execute requests for each unauthorized file. Unauthorized files either do not belong to the Trusted Owners list or are not specified in the Allowed Items list of a given rule.
A self-authorizing user prompt includes the following options:
- Allow - Allows the application to run.
- Block - Blocks the application from running.
When a DLL file is allowed to run, a message notifies the user that the application which uses the DLL may need to be restarted. The default message which displays can be modified in the Message Settings dialog on the Global Settings ribbon.
Any untrusted dlls are automatically allowed for executables that have been self authorized.
Users can also decide how long the setting is applied for:
- Remember my decision for this session only - The authorization decision is upheld only for the current session. The user is prompted again for an authorization decision when attempting to run an application in any future sessions.
- Remember my decisions permanently - The user decision is upheld for all future sessions.
If neither of these options are selected, the decision is upheld only for the current instance the user is attempting to run. The self-authorization prompt is reissued for any future attempts to run instances of the application.
Select to permit all actions but log and audit events for monitoring purposes, according to the policy settings in Auditing.
Select to permit all actions without even logging or auditing.
You can test whether Security Levels are being implemented correctly. The following example shows you how to test the Self-Authorizing level.
- Create a rule in the User rules node that applies to a test user account that is not a member of a group that belongs to the Trusted Owners list.
- Set the security control level to Self-Authorizing to allow the test user to self-authorize applications to run.
- Save the configuration.
- Run the Registry Editor. The application is prohibited and a message box displays with a prompt for a decision to allow the file to run and informing that the action will be logged.
You can apply security levels to control whether applications specified in the process rule are fully restricted by Application Control rules, unrestricted, or audited only.
Select the required process rule.
The Process Rule work area displays.
- Click and drag the
Security Level slider to the required
Policy Change Request Options
Configure which request types and features are available to users for each rule. Policy Change Request settings are available for all rule types, apart from Process rules.
- Select a rule in the navigation pane.
- Select the Policy Change Requests tab.
- Select how Policy Change Requests can be made:
- Telephone (Immediate Policy Change)
- Select the methods by which users can initiate Policy Change Requests:
- Access Denied message box - Users click a link in the message box that displays when a user attempts to access a prohibited application.
- Application context menu - Users select an option from the context menu of prohibited applications.
- Desktop icon - Users use a desktop shortcut icon to raise change requests from the Policy Request dialog.
The detail for each setting is configured using the Policy Change Requests dialog, accessed from the Global Settings ribbon.
Was this article useful?
The topic was:
Not what I expected
Copyright © 2019, Ivanti. All rights reserved.