A scenario that I see occasionally come across the support-line is when the addition of a Custom Rule winds up having a negative impact on the performance of an endpoint. The primary reason this can happen (assuming the rule syntax is correct) is what happens behind the scenes for a Custom Rule; rule expansion.
My scenario looks something like this:
I have a several processes, doing actions on files in several locations, and I try and restrict the use of those processes to several users. A real-world example would be "My developers are checking out code with several tools, and those tools put files all over the place".
In the Bit9 Console, for a Custom Rule, I'd create a rule that looks like:
For this simple example, I'll have 4 paths, 4 processes, and 4 users. If I save that, from the Bit9 Console, it appears as if I've just created 1 rule.
However, in order for the agent to digest that, a process called rule expansion actually converts that rule into 64 rules (4 x 4 x 4) because you have to account for all of the combinations of those users/paths/processes.
This is a small example, but we've easily seen Custom Rules created with 30 paths, 20 processes, and 25 users = 15,000 rules!
Not only would each agent need to download 15,000 rules from the server, but many of the endpoint operations now need to be analyzed against 15,000 rules to see if there is a match.
Something to consider when creating your Custom Rules! In practice, we don't recommend having more than a few thousand expanded Custom Rules for agents to have to enforce. When possible, also narrow scope by Policy so that not all agents are impacted.
Macro Effect
The use of macros in rule paths can also cause the number of actual rules to mushroom.
Macros provide a powerful way to specify paths that are independent of Windows version or configuration by using elements like <Windows>, <ProgramFiles>,
<InternetCache> and <MyDocuments> in rules. But some of these, like <Windows> are specific.
A system-specific rule will get expanded only once (for each of the conditions that Matt describes). However, user-specific rules will be expanded for every user account active on a system, including interactive users and accounts for services.
Consider a rule like the following:
On a typical desktop system with one interactive user, this rule will be expanded into at least eight separate rules with the following targets:
- \device\harddiskvolume2\windows\system32\config\systemprofile\appdata\local\temp\*.bat
- \device\harddiskvolume2\windows\serviceprofiles\localservice\appdata\local\temp\*.bat
- \device\harddiskvolume2\windows\serviceprofiles\networkservice\appdata\local\temp\*.bat
- \device\harddiskvolume2\users\chris\appdata\local\temp\*.bat
- \device\harddiskvolume2\windows\system32\config\systemprofile\appdata\local\temp\*.cmd
- \device\harddiskvolume2\windows\serviceprofiles\localservice\appdata\local\temp\*.cmd
- \device\harddiskvolume2\windows\serviceprofiles\networkservice\appdata\local\temp\*.cmd
- \device\harddiskvolume2\users\chris\appdata\local\temp\*.cmd
On a terminal server, this could result in hundreds of rules.
An alternative is to balance the use of per-user macros with path expressions that cover per-user paths as part of a wildcard expression. For example, instead of <LocalAppData> paths we could use:
C:\Users\*\AppData\Local\temp\*.bat
C:\Users\*\AppData\Local\temp\*.cmd
Such expressions are more difficult to maintain and subject to platform and system differences (for example, the above only work on Windows Vista and later and don't apply to user accounts that are located elsewhere), but they always produce two rules regardless of the number of users.
This document was generated from the following discussion: Rule expansion
