This chapter describes Registry rules, which control what happens when there is an attempt to make changes in the Windows Registry at locations that match paths you specify. If you choose, you can limit enforcement of the rules to specified users and/or processes.

Note: Registry rules can be centrally managed for multiple servers through the Unified Management feature. For more information on this feature, see Unified Management of Multiple Servers.
Note: PLATFORM NOTE: Registry rules affect only computers running Windows operating systems.

Registry rules enable you to block, report, allow, or prompt the user for a choice when there are attempts to write to Windows Registry locations matching paths you specify. Creation, modification, and deletion of keys or values all count as writes.

You can view a list of related events, including any blocks caused by Registry rules, by going to the Events page and choosing Registry on the Saved Views menu.

Note: For computers in Visibility mode policies, Registry rules that block writing or prompt users for a decision are treated as report-only rules, and therefore do not block or prompt.

Rule Scope

You can create registry rules that apply to all users and all processes that try to make a registry change on any Windows computer. You also can create a more focused rule scope by specifying one or more of the following criteria:

  • Process-specific – You can make a rule apply only when certain processes attempt to write to the specified location.
  • User- or group-specific – You can make the rule apply only to a particular user or group of users.
  • Policy-specific – You can choose to limit a rule to computers in specified policies.
  • Server-specific –If you have Unified Management enabled, you can choose to limit a rule to computers reporting to specified servers in the management group. This is described in Unified Management of Rules.
  • Rule order – Registry rules are evaluated in order of Rank, a column that is displayed by default on the Registry Rules table. The rule ranked ‘1’ has the highest rank, ‘2’ is next, and so on. You can change the order of rules. For example, you can create a rule that applies when a particular user attempts to access a specified Registry path, and put that before a rule that applies when any other user attempts to access that path.
  • Conditional Macros – You can use certain macros to restrict the conditions under which specific parameters in rules are applied. Only agents meeting the “test” described in the macro will attempt to match the parameter prefixed with the macro. Most of these macros are OnlyIf macros with different arguments, such as <OnlyIf:OSVersionIs:10.6.8> and <OnlyIf:HostName:*SMITH-1*>.
Important: Registry rules must be as narrowly targeted as possible to avoid unintended effects.

Sample Rules

A new installation of an Carbon Black App Control Server is pre-configured with built-in Registry rules, disabled by default, which you can view by clicking the Registry tab on the Software Rules page. Some of these rules are samples that you may either enable as is or use as a guide to creating your own rules. The Autostart rule, which also is disabled by default, protects a long list of registry locations potentially affected on startup. For an example of how a rule can be configured, see Sample Registry Rules.

Exporting and Importing Registry Rules

You can export registry rules from one server and import them to another. There are buttons for this purpose on the Registry Rules page. For more information, see Exporting and Importing Rules.

Specifying the Notifier for Registry Rules

The Carbon Black App Control Agent provides notifiers that can be displayed when a rule blocks an action or prompts the user for a decision to allow or block an action. For each Registry rule, you can choose one of the two sources for the notifier:

  • Use Policy Specific Notifier – Each policy includes an Advanced Setting, “Enforce registry rules”, which is always on. This setting has a Notifier field in which you can specify the notifier that appears on agent computers when a registry rule blocks an action.

    If you select Use Policy Specific Notifier for a rule, it is possible that the policy specifies <none> as the Notifier for Enforce registry rules. In this case, a notifier does not show, even for a Prompt rule. Unless you are certain that you never want to prompt the user for a response to a rule, selecting <none> for the custom rule notifier in a policy is not recommended. For more information, see Advanced Settings .

  • Custom Notifier – If you do not choose the policy-specific notifier, you can choose (or create) a different notifier for a registry rule. The choices appear on a menu on the Add/Edit Registry Rule page.

    When you select Block as the rule action, you can select <none> on the Custom Write Notifier menu since it is possible you want the rule to block actions without notification. A Prompt rule requires a user choice, so when you choose Prompt as the rule action, the Custom Notifier menu does not include <none>.

Note: If you are using Unified Management and create a Registry rule that applies to more than one server, client servers use default notifiers, even if a custom notifier is specified on the management server.

For the registry rule notifier settings, see Registry Rule Fields. For more on notifiers, see Endpoint Notifiers and Approval Requests.