Detection rules

What a rule does #

A detection rule watches your telemetry for a pattern and raises a signal when it matches. A signal carries a severity, the group it matched on, and the attributes that explain it.

The shipped library #

Twenty-four rules ship with the platform. They are grouped by what they read, because that is what decides whether you are getting anything out of them: a rule reading signals needs a rule reading logs to have raised one first.

• Authentication, six rules — brute force against one account, credential stuffing from one address, repeated failures from one address for one account, a successful login, and brute force followed by success.
• Application and API attacks, six rules — exploitation attempts against your services, server-side request forgery towards cloud metadata, attacks that caused a server error, campaigns from one address, and distributed attacks.
• Denial of service, eight rules — request floods, distributed floods, slow-request attacks, and connection floods detected from flow and host metrics.
• Audit and privilege, four rules — an administrator role granted, audit logging disabled, multi-factor authentication turned off, an administrative action from an address not seen before, and bulk data export by one account.
• Discovery, one rule — path enumeration from one client.

Two of them are building blocks. One correlates on another rule’s signal rather than on telemetry, which is what turns brute force followed by a successful login into a single critical finding rather than two separate ones.

Rule methods #

• Threshold — a count crosses a number.
• Value count — the number of distinct values crosses a number.
• New value — a value appears that has not been seen before.
• Anomaly — a metric departs from its own baseline.
• Correlation — one rule's signal is joined with what followed it.

Where rules look #

• Logs
• Spans
• Network flows
• Metrics
• Existing signals

Severity #

• info
• low
• medium
• high
• critical

Critical is held back for the cases where a rule needed a second stage to have happened, which is what makes it worth reading rather than another colour on the list.

A rule may define several cases at different thresholds, so one rule covers a graded range: a handful of events is informational, a flood is high severity.

Grouping and lifecycle #

A rule groups its matches — by user, by address, by host — so each group becomes its own signal rather than everything collapsing into one.

• Window — how far back the rule looks. The shipped rules use between one and sixty minutes, chosen to match how long the attack they look for actually takes.
• Keep alive — how long a signal stays active without new matches. This is what keeps a sustained attack as one signal rather than a new one per evaluation.
• Maximum duration — how long one signal may run before it closes.

Those three together set a signal's rhythm. A new match inside the keep-alive extends the open signal; one arriving after it opens a new one. An archived signal is never extended, so activity after an analyst closes one is reported as new rather than folded into a decision already made.

Building blocks #

A building block is a rule that does not alert on its own. It raises a signal that other rules correlate against, which is how a multi-step attack is assembled from simple parts.

Writing a rule #

• Choose the source signal to read.
• Choose the method that matches what you are detecting.
• Set the grouping so each match is its own signal.
• Set the threshold cases and their severities.
• Set the window, keep-alive and maximum duration.
• Add the tactic and technique so the rule sits correctly in an investigation.

Previewing before you save #

A rule can be run against a past window before it is saved, which returns what it would have raised: the groups, the peak, the severity each would have carried and how many events backed each one. Nothing is written, and the window reaches back up to seven days.

This is the fastest way to find out whether a threshold is right. A threshold picked without looking tells you how often it fires only once it is live, by which point it has already become noise people ignore.

Onward #

The queue these rules fill is Security signals, and Suppressions is how you stop a rule firing on cases you have already decided about. The telemetry they read arrives through App and API protection and Client address attribution, and what a signal costs to keep is Monitor quality in the alerting sense.