Skip Navigation

Creating custom detection rules

To meet your organization's security needs and requirements, you can use the
Optics
rule editor to clone and modify the detection rules that are available in the management console, or you can create your own custom detection rules. You can use the flexibility and logic of the Context Analysis Engine (CAE) to detect suspicious or malicious activity, including monitoring for broad behavior characteristics (for example, files that use certain naming patterns) or a targeted series of events (for example, a process with a certain file signature thumbprint that creates files and initiates network connections). Custom detection rules use the same workflow as the detection rules offered by
BlackBerry
, and you can configure automated response actions, user notifications, and package playbooks for your custom rules.
The rule editor uses JSON and provides built-in validation tools. When you validate a rule, the editor will check the syntax to identify any issues. If the rule passes the syntax check,
Optics
will then use a CAE service to verify that the rule will compile and run on a device. If either validation process discovers an issue, it will provide information about the errors that you must correct. After a rule passes both validation checks, you can publish the rule and add it to detection rule sets.
This section provides guidance and reference information for building your own CAE rules. CAE rules support the following data and filters:
Item
Description
States define the flow of a CAE rule, allowing
Optics
to statefully observe a series of events that can occur on a device. States represent a "1, then 2, then 3" scenario that might occur.
Functions define the logic that is required to successfully fulfill a state. This logic applies directly to the defined field operators and represents the attributes of an event that occurs on a device (for example, “A, and B, and C” or “A, and B, but not C”).
Field operators define how operands (facet value extractors) are evaluated. Field operators include actions like equals, contains, and is true.
Operands are the values that
Optics
compares. Operands allow for the extraction of specific pieces of data about an event (for example, file paths, file hashes, and process names) and compares those with literal values (for example, string, decimal, boolean, and integer).
Artifacts of interest define the artifacts that
Optics
can target when it executes automated response actions (for example, terminating processes, logging off users, or deleting files).
Paths define how the CAE interprets the flow of multiple state objects within a rule.
Filters narrow or expand the scope of a state with a smaller or larger number of events to analyze.
To address performance issues in environments that generate abnormally high numbers of events (for example, server systems or software engineering systems), the CAE supports exclusion rules that you can use to exclude certain events from the
Optics
data pipeline.
Optics
does not analyze or record excluded events. You can use preconfigured exclusion rules that are available in the management console, or you can use the rule editor to create your own exclusion rules using the same JSON structure as detection rules. The goal of an exclusion rule is to satisfy the rule based on processes that you want to exclude.
After you publish an exclusion rule, you can associate it with the whitelist process response action in a detection rule set. With this response action, the CAE will automatically exclude any events and processes that match the associated rule logic. Use caution when you use exclusion rules, because they have the potential to reduce the overall security of
Optics
devices.