2.5. Configure Detections
💡 First Principle: A detection rule is a standing question the SOC asks of its data on a schedule: has this suspicious pattern happened since I last checked? Good detection engineering chooses the right question (logic), the right data (table and tier), the right cadence (frequency and latency), and the right output (entities, severity, and grouping) so each alert is actionable and lands in a coherent incident.
Why care: built-in detections cover common attacks, but every organization has specific crown jewels, applications, and attacker interests. Custom detections are how a SOC encodes its own knowledge, including findings from hunting (1.4.2), into permanent coverage. The exam probes rule-type selection constantly: which rule fires within a minute, which one can isolate a device automatically, which one can't alert at all.
The decision runs through a small comparison:
| Need | Best fit |
|---|---|
| Detect on Defender XDR data and take device, user, file, or email response actions automatically | Defender XDR custom detection rule |
| Detect on Sentinel data with full KQL flexibility on a schedule | Sentinel scheduled rule (or custom detection on Sentinel data) |
| Alert within about a minute of ingestion | NRT rule or continuous-frequency custom detection |
| Match your telemetry against threat indicators | Threat intelligence matching rules |
| Surface statistical outliers for investigation and hunting | Anomaly rules (write to Anomalies, no alerts) |
⚠️ Common Misconception: "Custom detection queries can return any columns." A Defender XDR custom detection needs Timestamp (or TimeGenerated) and identifying columns such as DeviceId and ReportId to map entities and enable response actions. Two other traps live here: NRT rules have their own hard limits, and anomaly rules never raise alerts by themselves.
