You can access the Custom rule types from the Rule Type menu in either the Add Custom Rule page or the Edit Custom Rule page.

The Rule Type menu provides the following options:

  • File Integrity Control – Protects specified folders or files from being modified.
  • Trusted Path – Defines folders or files for which file execution is always allowed.
  • Execution Control – Controls behavior when an attempt is made to execute a file matching the rule.
  • File Creation Control – Controls behavior when an attempt is made to write a file matching the rule.
  • Performance Optimization – Specifies folders or files to avoid tracking (execution is still monitored).
  • Advanced – Provides a larger selection of menu options for controlling file execution, creation, and/or tracking.
  • Expert – Provides the greatest selection of rule options via a checkbox-based interface. You can select one or more of the internal actions underlying the other rules types. Expert Rules do not have the error-checking that other Custom rule types have, and it is possible to create unexpected (and unwanted) outcomes without feedback during rule creation. These rules are intended for use by Carbon Black Support or Services representatives, or customers working with them. For more details, see Expert Rules.

The Custom rules table includes several rules marked as [Sample] – these rules are disabled by default. For example, [Sample] Developer - Visual Studio Ignore Intermediate Files is a Performance Optimization rule that instructs Carbon Black App Control to ignore certain intermediate files typical of many build environments. In the Custom rules table, you can click the View Details button next to any of these samples to examine the types of field choices that might be applied to accomplish similar results.

The sections below provide general examples of some of the different rule types.

File Integrity Control

File Integrity Control rules allow you to control modifications to one or more folders (or files) matching your specification. You can write-protect the folder (or file) by choosing Block as the Write Action, or you can monitor (but not block) changes by choosing Report as the Write Action.

The following actions can apply:
  • Write Action Options: Block, Report
  • Execute Action: Does not apply to this rule type (not shown)
  • Users: Applies to all users (fixed value for this rule type, not shown)

For example, perhaps you use an application called ScheduleCreator to generate schedules for everyone at your company and put the results in a Schedule folder in the My Documents folder on each user’s computer. Assume that the ScheduleCreator executable is called makesched.exe. You want to be able to generate the schedule for each user, but you want to make sure nobody can change the schedules in the designated location once generated.

For example, in the Add Custom Rule page, you can select File Integrity Control as the rule type and leave Block as the Write Action. Then you could enter <MyDocuments>\Schedule\ as your Path or File. Note that <MyDocuments> is a macro that maps to the My Documents folder for each user on computers running the agent. Finally, in the Process Exclusion box, you could enter *\makesched.exe so that this process will be allowed to write to the path in the rule. Use of a macro in the Process Exclusion box could further restrict the allowable process to one run from a specific location, such as <ProgramFiles>\Schedule Maker\makesched.exe.

Example of adding a Custom rule with the File Integrity Control rule type.

Trusted Paths

One use of custom rules is designation of a trusted path. You can designate a network location as a trusted path and place installers there so that computers in certain policies or all policies can execute them. A trusted path is an access method, not a global approval method. It allows execution of files in a specific location without globally approving files generated by the executable.

The following actions can apply:
  • Execute Action: Allow, Allow and Promote, Promote
  • Users: Applies to all users (fixed value for this rule type, not shown)

Any files in a trusted path must be executed in the specified location; the destination of the files resulting from an execution can be another computer (i.e., the computer accessing the executable via a trusted path). Computers with access to files on the trusted path cannot execute an installation package by copying it to their own machine and executing it there.

The local state of any files written by a file in a trusted path depends upon the Execute Action command used:

  • If the Execute Action is Allow, an installer is allowed to write files but those files are not locally approved by the action. In this case, if the new files have not been seen by the Carbon Black App Control Server before, they are added to the File Catalog tab of the Files page with a status of Unapproved.
  • If the Execute Action is Allow and Promote, the installer can write files and those files are locally approved (unless already banned).
Important:
  • Any user who is able to write executables or scripts into the trusted path can make any application available to any computer that (a) has access to that location and (b) permits executions from remote drives. Before you enable a trusted path, check the platform’s security settings for that location to ensure that it is properly protected.
  • In the console, one way to help protect a Trusted Path is to create a user-specific File Integrity Control or File Creation Control rule for the same path. If you rank that new rule higher than the Trusted Path rule, you can control writes to the path while still allowing its use as a software distribution location.
  • Whether or not you create a companion rule as suggested above, be careful about the rank of Trusted Path rules. Because new rules are ranked first by default, you must move the rule down in the ranking if you want the internal rules for blocking undesirable activity take precedence.

To create a trusted path for installers, follow the instructions in Creating a Custom Rule, choosing Trusted Path as the Rule Type. Note that when you choose Trusted Path, other fields on the page change to reflect your choice. The Execute Action menu shows Allow, meaning that files matching this rule are allowed to execute.

For example, you might use an application called FileDistributor to distribute your company software via some distribution server. Assume that the FileDistributor application is actually an executable called filedist.exe, and that your company’s software is deployed from a distribution server located at \\FILE2DEPLOY\Apps\. You could choose Trusted Path as the rule type and enter \\FILES2DEPLOY\Apps\* as your Path or File.

If you leave the Process field for this rule set to Any Process, any process on a client affected by the rule can run applications and installers from that location. To reduce the security gaps in your custom rule, you might want to limit the right to execute files in this directory to FileDistributor itself, such that only FileDistributor can install applications from the named directory. By making the Process *\filedist.exe, you create just such a restriction. You can be even more specific by using a macro to identify the file location; for example, <ProgramFiles>\FileDistributor\filedist.exe. A user manually trying to run those same files is blocked.

Example of adding a Custom rule with the Trusted Path rule type

You can further limit trusted paths and any other custom rules to computers in one or more specific policies, using the “Rule applies to” buttons. By combining all of these fields, you have the opportunity to define a rule that allows you to accomplish necessary operations while exposing your systems to as little security risk as you can.

Execution Control

Execution Control rules are exactly what they sound like. They allow you to create a rule that responds in the way you choose when a file matching the rule attempts to execute. They do not have any effect on attempts to write (create, modify, or delete) matching files.

The following actions can apply:
  • Execute Action Options – Allow, Block, Allow and Promote, Promote, Prompt, Report
  • Write Action – Does not apply to this type (not shown)

Execution Control rules are similar to Trusted Path rules, except that Execution Control rules allow you to specify a user or group and they offer more Execute Action options.

For example, perhaps your developers use a tool called MyDevTool to develop and compile DLLs. The MyDevTool application is set up to run the DLLs it creates. You might create a rule that prevents this execution from being blocked.

Since the files created by MyDevTool are all DLLs, you can use *.dll as your Path or File. If you were certain of the location of these files, you can further specify the path, but for this example the location is open.

If you leave the Process field for this rule set to Any Process, any process on a client affected by the rule can run any DLL. To make this rule more secure, you might want to limit the right to execute files in this directory to MyDevTool application itself. To do this, you could use a macro to help specify the exact location of the tool, for example <ProgramFiles>\ToolCo\MyDevTool\runtool.exe.

If you have defined Active Directory groups, you might choose to further restrict the ability to run these DLLs to the group known to have permission to use this tool. To do this, you could choose Specify User or Group... on the User or Group menu and then enter the AD Group name for the permitted group, Developers, for example.

Now you have a rule that allows execution of DLL files in any location as long as they are being executed by user in the Developers group using MyDevTool.

Example of adding a Custom rule with the Execution Control rule type.

File Creation Control

File Creation Control rules allow you to control what happens when there as an attempt to write (create) a file that matches the rule. They do not have affect file execution attempts.

The following actions can apply:
  • Write Action Options – Ignore, Block, Approve, Approve as installer, Prompt, Allow
  • Execute Action – Does not apply to this rule type (not shown)

Like File Integrity Control rules, File Creation Control rules allow you to Block writes. However, File Creation Control rules allow you to specify a user or group and they offer more Write Action options for cases in which you are not blocking file writes.

Example of adding a Custom rule with the File Creation Control rule type

Performance Optimization

Unless instructed otherwise, the Carbon Black App Control Server keeps track of any files written to a computer running its agent. Normally, this is useful for monitoring purposes. However, there are cases in which a particular process writes many files to the same directory as part of its normal operation, and monitoring these write operations uses system and network resources unnecessarily while providing no important information. In cases such as these, you might choose to create a Performance Optimization custom rule for the uninteresting directory.

The following actions can apply:
  • Write Action – Ignore (value fixed for this rule type, not shown)
  • Execute Action – Does not apply to this rule type (not shown)
  • Users – Any User (value fixed for this rule type, not shown)

To create a rule that eliminates tracking for certain files, follow the instructions in Creating a Custom Rule and choose Performance Optimization as the Rule Type. When you choose Performance Optimization, some other fields on the page change to reflect your choice. Note that although not shown, the Write Action for this rule is Ignore, meaning that writing of files matching this rule will not be tracked by the Carbon Black App Control Server.

For example, perhaps an application called MyVirusGuard is writing a lot of temporary files to c:\temp2\.

You could create a Performance Optimization rule that specifies c:\temp2\* in the Path or File field. The Carbon Black App Control Server would not track any files written to, modified in, or deleted from that location by anyone. This reduces processing and information collection, but it also means that you are not tracking any files being written to that directory.

If MyVirusGuard uses the executable MVGuard.exe for its operations, including writing files, you could add *\MVGuard.exe to the rule as the Process, which lets MyVirusGuard write to the directory without tracking. The server continues to track files written to c:\temp2\ by any other process. Specifying the process allows you to accomplish the task you wanted while maintaining as much protection as possible. Note also that because you used the asterisk wildcard and a slash before the process name in the Process field, it does not matter where you installed MVGuard.exe – it is always allowed to write to the designated directory without tracking.

Example of adding a Custom rule with Performance Optimization rule type

Since the (hidden) Execute Action for a Performance Optimization rule is Default, any executions in c:\temp2 are still tracked and executions are still blocked if other rules would block them – only file writing has been allowed and not tracked, and only if attempted by the process you specified.

Pairing Ignore and Block Rules

In one previous example, a Process Exclusion was used to allow a specific process to write to the location normally blocked by the rule. You also can create an exclusion to a rule by pairing it with a second rule and ranking the exclusion rule before the main rule.

Perhaps a program called Super App has a log file called superapp.log in a logs subfolder. You might not want to create an exception for a process but instead only allow the files to be written in the particular subfolder while protecting the rest of the application folder. To do this, you could create two rules with the following characteristics:

  • Ignore Rule – Create a Performance Optimization rule to ignore and allow writes (the automatic action choice) to <ProgramFiles>\superapp\logs\*
  • Block Rule – Create a File Integrity Control rule with a Write Action of Block for the path <ProgramFiles>\superapp\*, and rank that rule lower than the Allow rule.

With the Performance Optimization rule ranked before the Block rule, Carbon Black App Control first checks to see whether a modification attempt matches the exception, and if it does, the Block rule is not evaluated.

The Performance Optimization rule ranked before the Block rule