Writing rules | XenXDR docs

The editor

Detections › New rule opens the editor. A rule has:

Field	Meaning
Name and description	What the rule catches, in the language an analyst on shift will read at 03:00.
Severity	Critical, high, medium or low. Sets the SLA clock and the queue ordering.
Data sources	Which catalog sources the rule needs. Shown as a warning when a deployment lacks them.
ATT&CK	Tactic and technique identifiers. Feed the coverage matrix.
Shape	Query, sequence or correlation.
Query, or stages	The query grammar from the Logs page, one per stage for the other shapes.
Entity	The field alerts are grouped by: `host.name`, `user.name`, `source.ip`.
Threshold and window	For count rules: at least N matches within the window.
Cadence and lookback	How often the rule runs and how far back it looks.
Playbook	The playbook to run on each alert, if any.
Tags	Free tags from the tag vocabulary.

Query rules

A query rule is the Logs grammar plus grouping:

text

event.module:sysmon event.code:1
process.command_line:*-enc* process.executable:*\powershell.exe

with entity host.name, threshold 1, window 10 minutes. Test it against the store with Preview, which runs the query over the lookback window and shows the events that would match, grouped by entity.

Sequence rules

Stages are ordered. Each stage has its own query; all stages must match the same entity value within the window, in order:

event.type:logon_failed at least 10 times
event.type:logon_success
event.type:service_installed

with entity user.name and a window of 30 minutes.

Correlation rules

The same stages, matched in any order. Useful when sources arrive with different delays.

Test events

Attach test events to the rule: JSON documents that should fire it. Run test injects them into a scratch scope and shows whether an alert would be produced. Rules in the content pack all ship with test events; rules you write should too, because the efficacy report uses them to prove the rule still works after an upgrade.

Enabling

New rules start disabled. Enable them from the rule page or in bulk from the list. Enabling is audited.

Style

One behaviour per rule. Rules that catch three things produce alerts nobody can name.
Name the entity that should be blamed, not the one that is convenient.
Set the severity for what the match means, not for how rare it is.
Write the description for the person who will read the alert, including what to check first.