Rule exceptions and value lists

To prevent the creation of unwanted alerts, you can add exceptions to any rule. Exceptions contain the source event conditions that determine when alerts are not generated. They provide a convenient way of allowing trusted processes and network activity to function without producing unnecessary noise.

You can add multiple exceptions to a single rule. An exception can also apply to multiple rules.

In addition to defining exception queries for source event values, you can use rule exceptions with value lists. Value lists are lists of items with the same Elasticsearch data type. You can create value lists with these types:

After creating value lists, you can use is in list and is not in list operators to define exceptions.

When creating a value list for a rule exception, be mindful of the list’s size and data type. In general, all rule types support value list exceptions, but there are some limitations for especially large lists or certain data types. The following value list types can only be used with custom query, machine learning, and indicator match rule types:

To create a value list:

To view, delete, or export existing value lists:

You can add exceptions to a rule from the rule details page or the Alerts table. When you add an exception, you can also close all alerts that meet the exception’s criteria.

Like detection rule exceptions, you can add Endpoint agent exceptions either by editing the Elastic Endpoint Security rule or by adding them as an action on alerts generated by the Endpoint Security rule. Elastic Endpoint alerts have the following fields:

You can also add Endpoint exceptions to rules that are associated with Elastic Endpoint rule exceptions. To associate rules, when creating or editing a rule, select the Elastic Endpoint exceptions option.

Endpoint exceptions are added to both the detection rule and the Elastic Endpoint agent on your hosts.

Some Endpoint objects contain nested fields, and the only way to ensure you are excluding the correct fields is with nested conditions. One example is the process.Ext object:

{
  "ancestry": [],
  "code_signature": {
    "trusted": true,
    "subject_name": "LFC",
    "exists": true,
    "status": "trusted"
  },
  "user": "WDAGUtilityAccount",
  "token": {
    "elevation": true,
    "integrity_level_name": "high",
    "domain": "27FB305D-3838-4",
    "user": "WDAGUtilityAccount",
    "elevation_type": "default",
    "sid": "S-1-5-21-2047949552-857980807-821054962-504"
  }
}

Only these objects require nested conditions to ensure the exception functions correctly:

Creates an exception that excludes all LFC-signed trusted processes:

To find out if an exception is used by other rules, select the Rule exceptions or Endpoint exceptions tab, navigate to an exception list item, then click Affects X rules.

The Exception lists table enables you to view and manage all exceptions that have been assigned to rules. To view the Exception lists table, go to Manage → Exception lists.

Exceptions are automatically grouped into exception lists. The table displays each exception list on an individual row, with the most recently created list at the top. Each row contains information such as the name of the rule to which the exception list is assigned, the dates when the list was created and last edited, and options to export or delete it.

To filter exception lists by a specific value, enter a query in the Search bar. You can search the following attributes:

If no attribute is selected, the app searches the list name by default.

To export or delete an exception list, select the required action button on the appropriate list. Note that: