Manage a security operations environment
Detection Engineering
CoreTurn validated hypotheses into Defender XDR custom detections and Sentinel analytics, and measure coverage with rule health, ATT&CK mappings, and anomaly behavior.
Aligned to SC-200 skills measured as of July 28, 2026; product behavior verified September 18, 2026.
Why this matters
Detection logic must preserve the entity and time evidence needed for response. Fast execution, attractive coverage charts, or large result sets have little value when a query cannot identify the affected asset or a mapping describes behavior the rule does not detect.
Must Know
- A Defender XDR custom detection starts with an Advanced Hunting query and must return the required timestamp and impacted-entity columns for its schedule and actions.
- Manage rule health, schema changes, response actions, exceptions, and scope throughout a custom detection's lifecycle.
- Use NRT rules for supported low-latency logic and scheduled rules when the hypothesis needs broader KQL, baselines, joins, or longer lookbacks.
- MITRE ATT&CK mappings describe what active detections cover; correct mappings expose gaps but do not create detection logic.
- Anomalies identify statistically unusual behavior and require tuning against legitimate changes in the environment.
Compare and Distinguish
- A hunting query is analyst-driven exploration; a custom detection or analytics rule evaluates repeatedly and creates alerts when criteria match.
- NRT rules minimize latency with tighter execution constraints; scheduled rules offer broader scheduling and query controls.
- MITRE mapping describes technique coverage; anomaly detection finds deviations from learned or defined baselines.
Scenario examples
- Scenario: A validated Defender hunting query must run continuously and identify affected devices. Think: create a custom detection and include required entity columns.
- Scenario: A high-velocity event needs minimal detection latency. Think: evaluate NRT constraints instead of defaulting to a scheduled rule.
- Scenario: Leadership asks where detection coverage is thin. Think: use ATT&CK mapping to find gaps, then verify actual rule quality.
Exam traps
- Aggregating away DeviceId or event identifiers can make a hunting result unsuitable for a custom detection.
- An incident automation rule acts after detection; it is not an analytics rule.
- Renaming a rule or adding an ATT&CK label does not change the behavior it detects.
- Closing anomaly results does not tune the model or prevent recurrence.
Key takeaways
- Choose rule type from latency, lookback, and query requirements.
- Keep entity context intact from hunt through response action.
- Use health and coverage views as evidence for engineering work, not as substitutes for it.
How it works
- Custom detections periodically evaluate Defender Advanced Hunting results and create alerts or supported entity actions.
- Sentinel analytics create alerts and incidents; ATT&CK and anomaly views describe coverage or unusual behavior around those detections.
Objects and administrative surfaces
- Advanced Hunting in the Microsoft Defender portal for query validation and custom detections.
- Microsoft Sentinel Analytics for scheduled, NRT, threat-intelligence, machine-learning, and anomaly detections.
- MITRE ATT&CK views for coverage analysis rather than proof that a control blocks an attack.
When to use it
- Use a custom detection when Defender XDR hunting logic should become recurring detection and response.
- Use anomalies when deviation from a learned baseline is decisive rather than one fixed threshold.
Security and governance implications
- Test response actions on representative assets before broad enablement.
- Require ATT&CK mappings and exceptions to describe the query behavior and approved business context accurately.
Troubleshooting signals
- Open rule health and test current schema references after query failures.
- For noisy detections, compare matches with the stated hypothesis before narrowing scope, thresholds, or exclusions.
More detail
- A Defender XDR custom detection starts with an Advanced Hunting query and must return the required timestamp and impacted-entity columns for its schedule and actions.
- Manage rule health, schema changes, response actions, exceptions, and scope throughout a custom detection's lifecycle.
- Use NRT rules for supported low-latency logic and scheduled rules when the hypothesis needs broader KQL, baselines, joins, or longer lookbacks.
- MITRE ATT&CK mappings describe what active detections cover; correct mappings expose gaps but do not create detection logic.
- Anomalies identify statistically unusual behavior and require tuning against legitimate changes in the environment.
Ready for the quiz?
- Which columns must survive a custom-detection query?
- When should scheduled analytics be preferred over NRT?
- How can an inaccurate ATT&CK mapping mislead a SOC?
Related objectives
- D1.4.S1 — Create custom detection rules by using Advanced Hunting in Microsoft Defender XDR
- D1.4.S2 — Manage custom detection rules in Microsoft Defender XDR
- D1.4.S3 — Configure and manage analytics rules in Microsoft Sentinel SIEM, including scheduled, near-real time (NRT), threat intelligence, and machine learning
- D1.4.S4 — Analyze attack vector coverage by using the MITRE ATT&CK matrix
- D1.4.S5 — Configure anomalies in Microsoft Sentinel