Custom IOA rules
Authoring process, file, network and domain indicator-of-attack rules with typed conditions and MITRE tags — how testing against recent telemetry works today, and why every action is effectively detect from the endpoint's point of view.
A custom IOA rule is a tenant-authored indicator-of-attack rule — a set of typed conditions over process, file, network or domain activity, tagged to a MITRE ATT&CK technique, evaluated natively against every sensor's telemetry as it arrives. Unlike the built-in behavioural detections, these are rules you write yourself, scoped to your own organisation and, optionally, to a host group.
Rule kinds and conditions
A rule has a kind — process, file, network or domain — and one or more typed conditions, each a {field, operator, value} triple. A rule matches when its conditions hold against the normalised event shape the same behavioural-detection engine uses, which is what lets a custom rule and a built-in behavioural rule reason about the same evidence rather than two different vocabularies.
The field vocabulary a condition can reference includes process.image, process.command_line, process.user, parent.image, parent.command_line, file.path, file.extension, network.remote_addr, network.local_addr, network.protocol, network.domain, hostname, platform, and a raw.<key> escape hatch for anything not named explicitly. A regular-expression operator is bounded (RE2, not backtracking regex) so a rule cannot be authored into a denial-of-service against its own evaluator.
Each rule also carries a severity and one or more MITRE ATT&CK technique tags, so a match lands on an incident timeline with the same technique vocabulary the built-in behavioural coverage uses — see Behavioural detections and attack coverage.
Actions: detect, kill, block — and what actually happens today
| Action | What it means | What actually happens on a match today |
|---|---|---|
detect | Raise an alert. No containment intended. | An alert is raised, server-side, on ingest. |
kill | Intended to terminate the offending process on the endpoint. | The same as detect. An alert is raised, server-side, on ingest. Nothing is killed on the machine. |
block | Intended to block the offending activity on the endpoint. | The same as detect. An alert is raised, server-side, on ingest. Nothing is blocked on the machine. |
Testing a rule against recent telemetry — API only, no console trigger
POST .../xdr/ioa-rules/test?last=24h replays a rule you have not saved yet against the organisation's recent xdr_sensor_events and reports which events it would have matched, without writing an alert. This is genuinely useful for checking a rule before you commit to it — but there is no console control that calls this endpoint. The API exists, is complete, and is what the console's own data layer wraps for other purposes; testing a not-yet-saved rule against real telemetry is something you do by calling the endpoint directly today, not by pressing a button in the console.
Host-group scoping, and its one real limitation
A rule can be scoped to a host group the same way a policy assignment can. On the hot ingest path — the per-event check that decides whether a rule applies to the sensor that just reported something — scoping to a static host group is evaluated directly. Scoping to a dynamic host group is not re-evaluated per event (that would mean a database query on every single telemetry event); dynamic membership is resolved instead when a policy bundle is built or previewed for a host. If you scope a rule to a dynamic group, treat that scope as accurate as of the last bundle build for a given host rather than as continuously live.
What the console actually shows
The Custom IOA rules panel on the consolidated /xdr/policy page (see Policy objects and host groups) lists your existing rules — name, event kind, action, enabled — but has no create form. Authoring a new custom IOA rule today means calling POST /api/v1/organizations/{orgID}/xdr/ioa-rules directly; the console is read-only for this surface until an authoring form is built.
Custom IOA rule write access — creating, editing, deleting a rule (xdr:ioa_rules.write) — is admin-only, not granted to the ordinary member role, for the same reason detection-rule authoring elsewhere in the product is admin-gated: a rule that never matches, or that silently matches everything, blinds the SOC either way. Reading rules (xdr:ioa_rules.read) is member-grade.
What to read next
- Indicators of compromise — the other kind of detection content in the bundle, with a different action vocabulary and the same enforcement gap.
- The signed policy bundle — exactly what is and is not enforced locally, across every bundle-delivered surface.
- Behavioural detections and attack coverage — the built-in rule set a custom rule sits alongside.
- Threat hunting — for exploring the same telemetry a custom rule's test endpoint replays against, by hand.