Detections

Synopsis

Detections is where you store and manage the detection rules that DataStream uses to decide which events a SIEM actually needs. A detection rule is a query written in a detection language — KQL, YARA-L, or Sigma — that describes the events a detection would fire on.

Rules live here as independent records. Assigning a rule to a target deploys it to that target's smart pipeline, where the Smart Engine processor uses the assigned set to reduce what is shipped: events no assigned detection is scoped to are dropped, and the fields the detections read are preserved.

Navigate to Content Management > Detections. The page opens on a tab per rule language.

Rule Languages

Each language has its own tab, its own rule list, and its own namespace — a rule name must be unique within an organization and language, so the same name may exist once per tab.

Tab	Rule language	Source of rules
KQL	Kusto Query Language	Microsoft Sentinel analytics rules, or queries you write
Yara	YARA-L 2.0	Google SecOps (Chronicle) detection rules
Sigma	Sigma	Sigma community rules

note

The Yara tab takes YARA-L 2.0 rules — Google SecOps rules addressed against the UDM schema, with meta:, events: and condition: sections. Despite the tab label, it is not the byte-pattern YARA used for file scanning. For byte-pattern matching over a payload, use the YARA processor instead.

The language is never inferred from the rule text. It is fixed by the tab you create the rule under, because the dialects overlap on the wire — a Sigma document and a KQL envelope are both YAML.

What Each Language Accepts

KQL accepts either a bare Kusto query or a YAML envelope. A bare query becomes one rule, which you name in the next step — so a query pasted straight out of a Sentinel workbook works as-is. To carry several named rules in one paste, use the envelope: a YAML sequence whose items hold name, an optional description, and the query under query.

Several KQL rules in one paste, using the envelope...

- name: encoded_powershell description: Encoded PowerShell execution query: | SecurityEvent | where EventID == 4688 | where CommandLine has "-enc" - name: suspicious_service_install query: | SecurityEvent | where EventID == 7045

Sigma accepts one or more documents separated by ---, which is how Sigma rule sets ship. A top-level YAML sequence is not accepted: its items would be indented under a list marker, and each stored fragment must remain a standalone Sigma document.

YARA-L accepts one or more rule NAME { ... } blocks. Module imports sit at file scope but each rule is stored on its own, so any imports found in the source are carried into every rule fragment — a stored rule never loses the imports it needs to compile.

Creating Detection Rules

Enterprise

Authoring is what the plan gates. Viewing the rules already running against your own targets, and assigning an existing rule to a target, stay available on every plan.

Select the tab for the rule language, then click Create new [language] detection rule. The wizard has three steps.

Detection Rule Settings

Choose how the rules arrive:

Source type	Use when
Manual entry	Writing or pasting rule text directly into the editor
Import from file	Uploading rule files; one or more rules are detected in each

Uploads accept .txt files only, up to 10 MB per file, 10 files, and 20 MB in total per upload. These are safety nets rather than everyday limits — parsing runs in the browser, and real rule files are a few kilobytes.

For manual entry, click Check configuration to validate before continuing. The wizard will not advance until the source has produced at least one rule: validation reports how many rules were found, or why the text could not be parsed. Imported files are validated as they are read, and a file whose contents cannot be validated is reported individually — one unreadable file in a batch does not invalidate the rest.

A multi-rule source is split. Each rule found becomes its own detection rule record, managed independently from then on. This is a bulk-entry convenience, not a grouping: there is no object representing the document you pasted.

Detection Rule Configuration

Every rule found in the previous step appears as a row for naming.

Field	Required	Notes
Name	Y	At least 3 characters, up to 255. Must be unique within the organization and language
Description	N	Up to 1000 characters

Names extracted from the source are pre-filled — a Sigma title, a YARA-L rule name, a KQL envelope name — so an imported set usually needs review rather than retyping. Unnamed and duplicate-named rules are both called out, and both block the step until resolved.

Duplicate names are also rejected by the API, so a name that collides with a rule created earlier is reported on submit even though the wizard could not see it.

Review and Complete Setup

The final step summarizes the source type, the configuration, and the number of rules found. Complete setup writes every rule in one transaction — either all of them are created or none are. A single request may carry at most 500 rules, and one stored rule's configuration may be at most 1 MB.

Managing a Detection Rule

Selecting a rule from the list opens its detail page, which has four tabs.

Tab	Contents
[Language] Detection Rule Details	Name and description, and the rule's creation and last-updated times
Detection Rule Configuration	The rule's own source, editable
Assigned Targets	The targets this rule is deployed to
Activity Logs	Actions taken on this rule

The overview list also offers a drawer — See detection rule details — showing the same name, description and configuration read-only, with the configuration available to copy.

Editing the Configuration

A detection rule record holds exactly one rule. Editing the configuration re-validates it against that constraint: a configuration that parses to more than one rule is rejected, with the count reported, and must be split or trimmed before it can be saved.

Name and description are managed on the details tab, not in the configuration. If the edited configuration carries embedded details that differ from the saved record — a changed Sigma title, for instance — you are asked whether to apply them to the rule's name and description as well, with both changes shown before you confirm.

Cloning

Clone detection rule opens the create wizard pre-loaded from the rule's stored source. The clone fetches the source itself rather than carrying it from the list, so a clone never writes back a stale copy. The new rule needs its own name.

Deleting

Delete detection rule removes the rule. A rule that is currently assigned to one or more targets cannot be deleted — the deletion is refused and the assigned targets are listed. Remove the rule from those targets first, then delete it.

Assigning Rules to Targets

Assignment is what puts a rule into service. An unassigned rule is stored but does nothing.

caution

Only KQL rules can be assigned, and only to Microsoft Sentinel and Microsoft Sentinel data lake targets. The restriction is enforced when the assignment is saved, not just in the interface.

YARA-L and Sigma rules can be created, edited, cloned and deleted, but have no target to be assigned to. Their Assigned Targets tab reports that there are no targets that can be assigned to the rule type yet.

Assignment is reachable from either side:

• From the rule — the Assigned Targets tab, via Manage assigned targets. Select or remove targets, then save.
• From the target — the Sentinel target's create wizard has a Detection Rules step after Execution Settings, and its detail view has a Detection Rules tab.

Both edit the same assignment. The target is the authority: a rule's assignment is stored as the target's detection rule list, so saving from the rule side updates each affected target.

The picker loads a page of targets per assignable type. When an organization has more targets of a type than one page holds, the tab says so — Select all then covers only the targets currently loaded rather than silently selecting fewer than it appears to.

How Assigned Rules Reach the Pipeline

An assigned rule is written into the target's detection_rules property as its name, its full source, and its language, and the target's smart pipeline compiles that set with the Smart Engine processor.

The assignment is read fresh every time the configuration is generated, so a rule edited here reaches the target on its next configuration update — nothing is denormalized or snapshotted at assignment time. Removing every rule from a target removes the property entirely.

What the target then does with an event that no assigned detection is scoped to is controlled by the target's unmatched_tables property, which defaults to keeping such events. See Microsoft Sentinel for both properties.

Permissions

Detections is governed by its own permission family, so access to it is independent of Pipelines or Library:

Role	Access
User	Read
Contributor	Read, create, edit
Admin	Read, create, edit, delete
Owner	Read, create, edit, delete

Assigning a rule to a target edits the target, so it additionally requires permission to edit targets. See Roles.

Detections has its own edition entitlement, monitoring.detections, split out from the one covering Monitoring Rules so the two can be tiered independently. An organization whose edition does not include it cannot reach the Detections endpoints at all — and an edition that includes alert rules does not necessarily include detection rules.