Operate Sophos XDR Custom Detection and Suppression Rules

Under Security Operations > Rules, you can operate custom detection rules and Suppression Rules. Detection rules create new detections from normalized events; suppression rules mark matching detections as suppressed early in processing. Both change the ongoing investigation process and require an approved, narrowly defined condition and an owner.

The cases and Classic rules guide explains the still-different Classic view. Its Super Admin, quantity, or 20-minute requirements are not transferred to Security Operations.

Before creating a rule

First define purpose, source, schema, expected matches, and deliberately excluded cases. Use suitable historical events in Data Lake Search to verify that the condition makes sense. An approved test uses a dedicated account or other authorized test data; do not generate actual malicious activity.

A match in a historical search does not prove identical behaviour in a running rule. Search and rule engines differ; some enriched fields are only created later. Acceptance therefore requires both an expected match and an expected non-match. Before a change, record the query, name, description, severity, enabled state, and previous matches.

Create a Custom Detection Rule

For a detection rule, first create a suitable Advanced Search query in Security Operations > Data Lake Search. It should match normalized events in an appropriate schema. Then:

1. Copy the validated query text and open Security Operations > Rules.
2. Select Create Rule above the Custom Rules table.
3. Paste the query into Rule Criteria.
4. Enter a clear Name, suitable Mitre Attack Categories, and an understandable Description.
5. Select a justified severity and create it with Create Rule.

A new Custom Rule is enabled when created. Approval and ownership must therefore be established beforehand. This differs from the default for a newly created custom parser. Do not enable an unbounded condition in production just to experiment.

Streaming is not a saved search

Custom Rules process streaming data. Primitive fields do not automatically receive the default values that may exist later in the data lake. NULL conditions must therefore account for genuinely missing values. Glob patterns are unsupported; regex constructs such as backreferences, recursive patterns, arbitrary look-around-style zero-width assertions, and embedded code are also restricted. Do not present a working search expression as a guaranteed working rule without checking it.

Logical fields such as @user can expand to fields within the selected schema. A rule matches only one schema. Certain fields added later are unavailable: for example, hostname, geo/blacklist enrichments for auth/netflow/dns_query, and WHOIS for the DNS schema. Check the exact required fields in the current rule context rather than substituting similarly named search fields.

Circuit breaker and customer responsibility

Custom Rules may create at most 5,000 detections per hour or 100,000 within 24 hours. If the limit is exceeded, the circuit breaker disables the rule and Sophos emails its author. Narrow the scope afterwards; do not re-enable the unchanged rule. A stopped alert stream can therefore mean a disabled rule, not proof that risks have been resolved.

Cases automatically created from customer rules are customer-managed and do not trigger automatic MDR investigation. The Antivirus, Email, NIDS, and Thirdparty schemas also describe is_custom_alert=true: these custom alerts go to the tenant for handling rather than the MDR service queue; their severity is unchanged. This does not exclude every custom-parser record from MDR. Creating and validating parsers explains the preceding normalization stage.

Keep suppression deliberately narrow

Suppression is for confirmed legitimate repetitions, not for hiding unexplained activity. Tenant rules affect only the current tenant; Global rules are managed by Sophos and read-only. Record the details of questions about a global rule and clarify them through the normal support process.

A suppressed detection is assigned the corresponding status early, before it can trigger downstream automated response. Playbooks or host isolation may therefore not run. Before approval, establish which legitimate activity is matched and which security response is deliberately prevented.

Create suppression from a query

1. Test the condition against existing detections in Data Lake Search.
2. Select Create Rule under Security Operations > Rules > Suppression Rules.
3. Enter the condition in Rule Criteria.
4. Use See potential matches with current data as a plausibility preview.
5. Set name, description, and the intended resolution status, then create with Create Rule.

New suppression rules are also enabled by default. Scope, approval, and rollback must therefore be established before Create Rule.

Alternatively, open a specific detection and Actions > Create Suppression Rule. Select prepopulated entities deliberately; multiple conditions are combined with AND. Escape regex special characters appropriately when entering them manually. Do not derive universal suppression from a single expected match.

Why the preview and running rule can differ

The preview uses Advanced Search against finished, enriched detections. Suppression runs while they are being created. Fields such as enrichment_details, status, and case are unavailable; use the thirdparty event schema rather than third_party_details for third-party values. All criteria must be true together at suppression time. A finished record may combine conditions that were only true separately earlier.

See potential matches is therefore not a guarantee of effect. After creating, editing, enabling, or disabling a suppression rule, wait at least ten minutes before evaluating the result. Detections generated immediately after the change are not reliable tests of the new state.

IPv4 CIDR works in suppression even though Detection Search itself does not support CIDR searches. Test the query without the range first, then adapt it for the rule. IPv6 addresses can be compared in normalized form; IPv6 CIDR and IPv4-mapped IPv6 are currently unsupported for suppression. Do not transfer firewall network-range syntax without checking it.

Validate, document, and roll back

Clicking a rule name shows criteria and details. If there were matches in the last seven days, the count, last match, and history appear. Suppression also provides an edit history under History. A missing activity chart can simply mean the matching event has not occurred.

Include detections from Custom Rules using Custom Detections in the detection list. Suppressed detections already triaged become visible with Triaged Detections; a relevant search can be opened from rule details. Check expected matches, expected non-matches, schema/source, and the response that should or should not occur.

The Enabled switch turns a rule on or off. Archive disables it and removes it from the default list. Open archived rules with Showing Archived Rules; Restore brings them back disabled. Do not enable a restored rule without renewed acceptance. The documented propagation delay for suppression also matters when disabling it.

If acceptance fails, disable only the affected rule you own and check the previously documented state. Cases, exports, or suppressed detections already created do not disappear automatically. Suppressed detections can be added to cases and have their label changed when needed. Do not disable a global protection feature or somebody else’s rule to make your test fit.

Operational handover includes source/schema, criteria and version, author, approval, match/non-match evidence, severity/resolution, enabled state, circuit-breaker monitoring, and a review date. Integration acceptance remains a prerequisite: a silent rule does not repair a missing data source.