In progress — this area is still being built; some actions described may not be available yet.
Detections are the raw events that the Defend engine generates when a rule matches or an anomaly is scored above threshold. Every alert in Defend originates from one or more detections. Understanding how detections work helps you triage faster and tune rules to reduce noise.
Detection availability: Detection evaluation is currently limited and may not be live in your environment, so alerts may not appear for activity on enrolled devices. This article describes how the workflow runs when detections are evaluating; it does not promise a working first detection today. No alerts does not mean a device is clean.
How Detections Are Generated
The detection engine evaluates new events from enrolled devices against two sources:
-
Detection rules — a curated library of rules plus any custom rules you have written. Each rule defines a pattern (process behavior, network activity, file access, logon type) and maps to a MITRE ATT&CK technique. When an event matches, a detection fires.
-
Behavioral analytics (UEBA) — the UEBA engine baselines each user and device over time. When activity deviates significantly from that baseline — unusual login hours, new remote access paths, abnormal process volumes — the engine scores the anomaly and creates a detection.
Raw endpoint events flow from agent telemetry into the platform. When detection evaluation is live, the engine runs against incoming events as they arrive.
Detection Types
| Type | Source |
|---|---|
| Rule-based detection | A configured detection rule matched an event |
| UEBA anomaly | Behavioral baseline deviation for a user or device |
| IOC match | An observed indicator (IP, hash, domain) matched a threat intelligence entry |
| Honeytoken trigger | A deception asset was accessed |
Severity Levels
Detections carry a severity that determines their position in the alert queue and, where automated response has been enabled, whether an attached playbook is eligible to run:
| Severity | When to expect it |
|---|---|
| Critical | High-confidence detections, honeytoken triggers, known-bad IOCs |
| High | Strong rule matches; behavioral anomalies with corroborating signals |
| Medium | Moderate-confidence rules; isolated UEBA deviations |
| Low | Informational matches; weak signals that need context |
The dashboard shows open alert counts broken down by critical vs. total.
The Alert Queue
Detections surface as alerts in the Alerts view. The queue is sorted with critical items at the top by default.
From the queue you can:
- Filter by severity, status, device, or time range
- Bulk-update alert status
- Assign alerts to a team member
- Resolve alerts individually or in bulk
Related alerts that the correlation engine has grouped together display as part of an attack chain. Opening the attack chain shows the full sequence of detections in the order they fired.
MITRE ATT&CK Mapping
Every rule-based detection includes the MITRE technique it maps to. This appears in the alert detail and feeds the MITRE coverage map, which shows how many flagged rules you have mapping to each tactic and technique. Detections without a rule mapping (UEBA anomalies, IOC matches) display the event context but do not contribute to MITRE coverage counts.
A flagged rule is not a running rule. The coverage map is a read of your rule store and it names the evaluation arm it was taken on. On the arm in force today the engine's own KQL rule runtime is retired on this arm — it evaluates no rule — so the map reports which techniques you have rules for, not which techniques are being evaluated.
From Detection to Incident
Detections do not automatically become incidents. The flow is:
- Detection fires → alert appears in the queue.
- You triage the alert — it may already be grouped into an attack chain.
- If the alert represents a real attack, click Convert to Incident to escalate.
- If it is a false positive, click Mark False Positive and add a note. The suppression engine uses your feedback for future tuning.
FAQ
Why do I see many detections for one attack? Each rule that matches generates its own detection. The attack chain correlation engine groups detections from the same attack sequence, so you can review the full story without triaging each event individually.
Can I create my own detection rules? Yes. Go to Rules, click New Rule, define the match conditions, and assign a MITRE technique and severity. Custom rules work the same way as curated rules in the detection pipeline.
How quickly do detections appear after an event? When detection evaluation is live, events from the agent are processed as they arrive. Detection evaluation is currently limited, so don't rely on a detection appearing for a given event today.