Detection rules define what Security flags as an alert. Each rule specifies a pattern to match against incoming event data, a severity level, and a MITRE ATT&CK mapping. The platform ships with a library of built-in rules; you can also create custom rules or clone and modify existing ones.
Rule Types
Security supports three rule types:
| Type | How it works |
|---|---|
| Sigma | Vendor-neutral YAML-based rules that match on normalized event fields. Portable across log sources. |
| KQL | Kusto Query Language rules that query the ADX event store directly. Best for complex multi-field or time-windowed logic. |
| Behavioral | Rules that detect anomalies in patterns over time rather than matching individual events (e.g., unusual login times, rare process lineage). |
Finding and Filtering Rules
- Go to Security and open Rules.
- Use the filters to narrow the list:
- Type — Sigma, KQL, or behavioral
- Severity — Critical, High, Medium, Low
- MITRE Tactic — filter by ATT&CK tactic (Initial Access, Execution, Persistence, etc.)
- Status — Enabled / Disabled
- Click any rule to see its definition, MITRE mapping, hit count, and last hit timestamp.
Enabling or Disabling a Rule
- Open the rule detail.
- Review the definition and expected behavior. Check the Hit Count to understand how often it fires.
- Toggle Enabled to activate or deactivate the rule.
- Disabled rules do not generate alerts. Enable rules conservatively — start with high-confidence, high-severity rules and expand from there.
Creating a Custom Rule
- In Rules, click New Rule.
- Select the rule type (Sigma, KQL, or behavioral).
- Enter a name, description, severity, and MITRE technique mapping.
- Write the rule definition:
- Sigma: provide valid Sigma YAML with detection conditions
- KQL: write a query against the normalized event table; the query should return rows only when the condition is met
- Configure suppression settings if needed (e.g., suppress duplicate hits within a time window).
- Save. The rule starts running on the next event ingestion cycle.
Tuning a Rule
If a rule is generating too many alerts:
- Check the Hit Count and Last Hit time on the rule detail page.
- Go to Alert Tuning. If the rule appears there, the system has a suppression or threshold suggestion ready. Review and approve it.
- To manually adjust: open the rule, modify the definition to narrow the match conditions, or add a suppression scoped to a specific client, device, or asset fingerprint.
- You can also suppress alerts from a specific verdict — marking alerts as False Positive from the alert detail page feeds suppression data back to Alert Tuning.
Suppression
Suppressions are scoped rules that block an alert from being created even when the detection rule matches. Each rule can have one or more suppressions. Suppressions can target:
- A specific client org
- A specific device or asset
- An alert fingerprint (a combination of fields that identifies a recurring pattern)
Suppressions have an optional expiry date. If you suppress an alert because a device is in maintenance, set the expiry to match the maintenance window.
MITRE Coverage
The Fleet Intel section shows a heatmap of MITRE techniques observed across your fleet over the last 30 days. Use the Rules list filtered by MITRE tactic to find gaps — techniques that have no enabled rule covering them.
FAQ
Can I clone a built-in rule to customize it without losing the original? Yes. Open the rule detail and click Clone. A copy is created with "Copy of" prepended to the name. The original remains unchanged. Edit the clone as needed.
What happens to existing alerts if I disable a rule? Existing alerts are not deleted. Disabling a rule only stops new alerts from being created. Open alerts remain in the queue until resolved.
My Sigma rule is enabled but not firing. What do I check? Verify that the fields the rule depends on are present in your normalized events. Field availability depends on which connectors are active and what log levels are enabled at the source. Run a Threat Hunt query to confirm the expected fields are populated.