Trusted Application (Application Whitelisting) Rules

Each time a file is accessed, Trusted Application Rules are run to determine whether the file accessed should be allowed or blocked.

Rules have a type of file I/O that they can apply to: Read, Write, Delete and/or Rename/Move. A Rename/Move is a file rename, or a move of a file on the same drive. It is possible for a rule to only allow or block Reads or Writes for example. Rules are only run if they match the requested file I/O activity. In other words, if a rule only applies to Reads, but the current file I/O activity is a Write, that particular rule will not be run.

If a rule evaluates to True, the rule's type (Allow or Disallow) is activated. If the rule evaluates to False, the next rule is run. If all rules are run and none ever grant access to a file, the file access is denied.

There are Allow and Disallow rules. As soon as any rule evaluates to true, rule processing stops and the type of rule (Allow or Disallow) determines whether access is allowed or not. Rules are run in order from top to bottom, so rule order is important. If no rule Allows access to a file, access will be blocked.

Rule List

The Trusted Application Rules can be found in the Trusted Applications section of the Console.

There are a list of Rules shown in the Rules List. The Rules will be run in the order shown, from top to bottom. Clicking a rule will show the rule description and a preview of the expression. Any rule can be edited, deleted and new rules can be created.

To the right of each rule is whether it allows + or disallows - I/O, and what types of I/O are impacted (Read, Write, Delete, rename/Move). In addition, an approximate relative cost of running the rule is shown.

Optimizations

Since rules are run in order, you will get better performance by running the faster rules first since they might allow or disallow file access, and then the remaining rules won't need to be run. You can order the rules manually using the up and down arrow buttons on the Rules List.

It is safe to reorder a small set of Allow rules amongst themselves, or a small list of Disallow rules amongst themselves, but since rules run in order, moving an Allow rule past a Disallow rule or vice versa could impact the desitred functioning of the rules.

Individual Statements with rules have differing compute needs, so sorting the statements within an individual rule can make rule execution faster. For example, imagine a rule that indicates a file must be in the Trusted Applications List AND the user must be an administrator. If the rule determines the file is not in the Trusted Applications List, there is no reason to check whether the user is an administrator because we already know that rule will evaluate to false. The Optimize button in the rule editor will re-order the statements to best performance while ensuring the meaning of the rule is not changed.

Rule Editor

The Rule Editor is where you can create the actual rules that will be evaluated when a file access is attempted. Statements evaluate to information for a file access request, and that can be compared with = or != boolean operators to values you specify. AND, OR and NOT boolean operators can also be used to make more complete expressions. Paranthesis can be used for logical grouping/ordering of statements.

The wildcard * character can be used when comparing string values using the = and != operator. Also, comparisons with the = and != operator are case-insensitive.
Example:
(FILE_PATH = "F:\Documents\Chapter*\Notes.txt") OR (PROCESS_PATH = "C:\Windows\System32\*.exe")

Rule Syntax

Rules are boolean expressions that ultimately evaluate to either True or False. The operators AND, OR, NOT, = and != can be used, as well as parentheses to ensure correct order of operations. The IN operator can be used to see if a Statement value is found in a list.

Let's look at an example:

(FILE_IS_COMMAND_HOST = true) AND NOT ((PROCESS_IS_TRUSTED = true) OR ((USER_NAME = "NT AUTHORITY\SYSTEM") OR ((USER_GROUPS = "*,Administrators,*") OR (USER_GROUPS = "*,Domain Administrators,*"))))

FILE_IS_COMMAND_HOST and PROCESS_IS_TRUSTED both evaluate to a boolean True or False, so they are compared against those values. Note that comparisons are case-insensitive. USER_NAME evaluates to a string value, so it is compared to a string value.

In the case of the USER_GROUPS statement, we see the * wild card being used in the comparison. This will match on "Users,Administrators,Printer Operators", but it will not match on "Domain Administrators,Printer Operators,Everyone" because the literal value ",Administrators," is not found in the USER_GROUPS string value.

If your rules start getting long because of many exceptions, it is often easiest to put the exceptions into a Custom List and have the rule refer to the list with the IN operator. For example, imagine the following list of frequently changing programs used by Finance are not digitally signed. They could be added to a Custom List named "CHANGING_HR_FILES":

C:\Finance\MonthlyWrapUp.exe
C:\Finance\Daily*Probe.exe
D:\Data\SalesImport\*.csv

This list could be checked with a simple rule such as:

(FILE_PATH IN CHANGING_HR_FILES) OR (PROCESS_PATH IN CHANGING_HR_FILES)

To easily insert a statement into the Expression, use the Insert dropdown box. The selected Statement will be inserted into the expression editor wherever the cursor is currently at. The expression editor is a simple text editor so you can copy/paste and edit as expected.

You can refer to environment variables using the standard Windows % syntax. For example, %WINDIR% will be expanded to C:\WINDOWS.
Example:
(FILE_PATH = "%WINDIR%\*\ARP.EXE")

That rule would match C:\Windows\System32\arp.exe, or C:\Windows\SysWow64\arp.exe, or even C:\Windows\Servicing\LCU\Package_for_RollupFix~31bf385\wow64_microsoft\r\arp.exe.

The Validate button can be used to ensure the expression is properly formatted. If there is a problem, it will indicate the first position in the expression where there is an error.

The Optimize button will reorder the rule so the fastest statements are executed first.

The Format Text button can be helpful to format the text of a rule to help see the logic more easily.

Many other application whitelisting products on the market can only block executable file execution, and don't check other accessed files (such as script files).

If you want the Trusted Applications feature to work in this simpler (and less safe) way, you can create the following Allow rule:

(FILE_HAS_EXECUTABLE_EXTENSION = False)

This will have the effect of allow access to all non-executable files.

Testing

Testing expressions is recommended. At the bottom of the Rule Editor are a set of fields. Fill these in to simulate a file access request that might happen. The expression will run, with the Statements being evaluated for the given test field values.

Use a full path to an existing file for the target of the test, and a full path to an executable file (ideally to an executable that is running). These need to be paths to existing files because the Statements will be extracting information about the file and process. For this reason, wild-cards cannot be used for the tests fields.

When the test runs, the expression will be evaluated as though the request for the access to the file was actually taking place. The final result of the evaluation will be a True or a False. If the rule is an Allow rule, a True will allow access. If the rule is a Deny rule, a True result will deny access.