Assertions and dependencies are what distinguish multistage rules from other rules. Assertions and dependencies allow rules to create and reference assertions, which allows you to create chains of rules, each of which must fully resolve, before an alert will be generated.
Assertions
An assertion is a variable created by a rule when its TQL query and threshold values match. Assertions must include a name, a time duration, and one or more assertion fields. On their own, assertions do nothing, and exist only to be referenced by dependencies.
A single rule can include an unlimited number of assertions.
First-stage and middle-stage rules must include at least one assertion.
Final-stage rules cannot include assertions.
Edit the rule. See Editing customer rules.
Click Advanced > Add Assertion at the bottom of the Update Rule dialog.
Complete these fields to create a new assertion:
Assertion name: The name of the assertion. This name is used when you reference assertions with dependencies in subsequent rules.
Time valid: The duration of time, in minutes, that the assertion remains active and can be referenced by dependencies.
Assertion field: The field containing the value to be stored by the assertion, such as
srcipv4. Multiple assertion fields can be included.Repeat these steps until you have created all the assertions required for the rule.
Dependencies
A dependency is a variable that causes a rule hit to not generate an alert (or a log) unless an equivalent assertion exists and is active. An assertion and a dependency are equivalent if they have the same name and entry in their respective assertion fields.
A single rule can include an unlimited number of dependencies.
First-stage rules cannot include any dependencies.
Middle-stage and final-stage rules must include at least one dependency.
Edit the rule. See Editing customer rules.
Click Advanced > Add Dependency at the bottom of the Update Rule dialog.
Complete these fields to create a new dependency:
Assertion name: The name of the assertion that must be active in order for this rule to generate another assertion, another dependency, alert, or log.
Applied field: The field value that must resolve in order for this rule to generate another assertion, another dependency, alert, or log.
Repeat these steps until you have created all the dependencies required for the rule.
Using assertions and dependencies
Multistage rules are highly modular, and can be built in a variety of ways to detect many different kinds of attack scenarios. Helix Enterprise does not impose any restrictions on how your multistage rules interact with each other.
You can organize multistage rules in many ways:
One-to-many: one rule provides one or more assertions to be referenced by the dependencies of multiple rules.
Many-to-one: multiple rules generate one or more assertions to be referenced by the dependencies of a single rule.
Many-to-many: multiple rules generate one or more assertions to be referenced by the dependencies of multiple rules.
It is possible to create rules that include assertions but not dependencies, and rules that include dependencies but not assertions.
Rules that include only assertions will store the assertions, but without a dependency that references them, the assertions do nothing, and if the rule is not set to alert then it will also do nothing.
Rules with only dependencies are the last, or final, stage in a multistage rule.