In this section
DE1 Check My Knowledge
Scenario 1. You are building a detection rule for shadow copy deletion — a ransomware pre-encryption indicator. The attacker typically deletes shadow copies and begins encrypting files within 60 to 90 seconds. Your scheduled rules run every 5 minutes with a 5-minute execution delay. What rule type should you use for this detection?
A scheduled rule with 5-minute frequency — the standard detection cadence is sufficient for most threats, and the full KQL language lets you write a more precise query. a
A 5-minute frequency with a 5-minute execution delay means worst-case detection latency of 10 minutes. The attacker completes encryption in 60-90 seconds. By the time the scheduled rule fires, the damage is done. Section 1.5 teaches that NRT rules are necessary when the attacker completes a critical action within the time between scheduled executions.
An anomaly rule — it will baseline normal vssadmin.exe usage and detect the deletion as anomalous behavior. b
Anomaly rules detect behavioral deviations from baselines, not specific high-confidence indicators. Shadow copy deletion is a specific, known-malicious command — not a behavioral anomaly. You want deterministic detection with sub-minute latency, not probabilistic baselining. Section 1.1 explains that anomaly rules output to the Anomalies table with a score, not directly actionable alerts for time-critical events.
An NRT rule — it runs every minute with a 2-minute delay, detecting shadow copy deletion within 3 minutes of execution, before encryption starts. c
NRT rules are designed for exactly this scenario — time-critical detections where the attacker completes a critical action within the scheduled rule execution window. Shadow copy deletion can be detected with a filter chain (where FileName =~ vssadmin.exe and ProcessCommandLine has delete shadows), which is compatible with NRT restrictions. Section 1.5 identifies ransomware pre-encryption indicators as one of the primary NRT use cases.
A Defender XDR custom detection with automatic device isolation — the detection and response happen in one rule. d
A Defender custom detection with device isolation is part of the correct answer — but it should run alongside the NRT rule, not instead of it. The NRT rule provides the fast Sentinel alert for SOC visibility. The Defender custom detection provides the automated containment. Section 1.5 teaches the multi-engine pattern: both engines fire on the same attack, each serving a different operational purpose.
Scenario 2. Your brute force detection rule maps the Account entity using only the Name identifier — the username without domain context. A separate rule for risky sign-ins maps the same user using FullName (the full UPN). Both rules fire for the same user. What happens in the investigation?
Sentinel merges the two entities automatically because the username matches, and both alerts appear connected in the investigation graph. a
Sentinel cannot reliably merge entities identified with different identifier strengths. Name alone is a weak identifier — "s.chen" could refer to different users across domains. FullName is a strong identifier. Without matching strong identifiers, Sentinel treats them as separate entities. Section 1.3 explains that entity merge only works when both alerts use strong identifiers that Sentinel can match with certainty.
Sentinel creates two separate entity nodes because the weak Name identifier cannot be reliably matched to the strong FullName identifier — the investigation is fragmented. b
This is the entity merge failure that Section 1.3 describes. A weak identifier (Name alone) cannot be reliably correlated with a strong identifier (FullName). The result is two separate entity nodes in the investigation graph for the same person. Two analysts may independently investigate the same user without knowing the other investigation exists. The fix is to upgrade the brute force rule to use FullName or Name + UPNSuffix as a strong identifier combination.
Both alerts appear in the same incident because alert grouping handles the correlation regardless of entity mapping strength. c
Alert grouping operates within a single rule — it groups alerts from multiple executions of the same rule. It does not correlate alerts across different rules. Cross-rule correlation depends on entity mapping with strong identifiers. Section 1.6 explains that alert grouping is configured per rule on the Incident settings tab.
Fusion correlates the two alerts into a multi-stage incident because both involve authentication-related activity. d
Fusion requires both entity mapping and ATT&CK technique mapping to correlate alerts. Even if both rules have ATT&CK mapping, the weak entity identifier on the brute force rule prevents Fusion from reliably matching the entities. Section 1.4 explains that Fusion calculations are affected when incoming alerts have insufficient entity information.
Scenario 3. Your SOC has 40 active analytics rules. Thirty-two are set to Medium severity. The SOC processes incidents chronologically rather than by risk. A credential compromise alert at 3 PM waits behind 14 inbox rule false positives from the morning. What is the root cause?
The SOC needs more analysts — the queue volume exceeds their capacity regardless of severity distribution. a
Adding analysts does not fix a broken priority signal. If 80% of incidents are Medium severity, more analysts still process them chronologically because there is no meaningful way to distinguish urgent from routine. The problem is that severity has not been calibrated, not that the team is understaffed. Section 1.4 explains the three-factor calibration model.
The inbox rule detection needs better KQL to reduce false positives — fixing the noise floor will make the credential compromise visible. b
Reducing false positives is important but does not fix the priority problem. Even with zero false positives, if all incidents are Medium severity, the SOC still lacks a signal for which incidents to investigate first. The credential compromise should be High severity — it should never wait behind inbox rule alerts regardless of queue volume. Section 1.4 teaches that severity calibration is the mechanism that tells the SOC what to investigate first.
The SOC needs an automation rule to auto-close inbox rule alerts — removing low-value incidents clears the queue for real threats. c
Auto-closing alerts is a workaround for uncalibrated severity, not a fix. If the inbox rule alerts are genuinely false positives, the detection query should be tuned. If they are benign positives (real inbox rules that are not malicious), they should be classified as Low or Informational — not auto-closed, which eliminates any visibility into potentially malicious inbox rule activity. Section 1.4 teaches that severity should reflect impact, not convenience.
Severity has not been calibrated to the environment — the credential compromise should be High and the inbox rule alerts should be Low or Informational, giving the SOC a meaningful triage priority. d
When everything is Medium, nothing is prioritized. Section 1.4 teaches the three-factor calibration model: impact if true (credential compromise = High impact), confidence of malicious intent (inbox rule creation by a regular user = Low confidence), and SOC capacity (High severity should mean "drop what you're doing" and occur 2-5 times per week). Calibrating severity so that the credential compromise is High and the inbox rule is Low gives the SOC the priority signal it needs.
Scenario 4. You create a scheduled rule with a 5-minute frequency and a 5-minute lookback. SigninLogs for your tenant has an average ingestion latency of 3 minutes. After a week of operation, the rule has missed 12% of brute force events that you can confirm were present in the data. What is the most likely cause?
Events generated in the last 3 minutes of each window arrive after the rule executes — the lookback needs to exceed the frequency to account for ingestion delay, with ingestion_time() deduplication. a
With a 5-minute frequency and 5-minute lookback, the execution windows are contiguous — no overlap. An event generated at 10:04 with 3-minute ingestion delay arrives at 10:07. The rule execution at 10:10 (with 5-minute delay) looks back to 10:05, missing the event. Section 1.2 teaches the ingestion delay compensation pattern: extend the lookback beyond the frequency (e.g., 7 minutes for a 5-minute frequency) and use ingestion_time() to deduplicate events that appear in overlapping windows.
The alert threshold is too high — the rule is suppressing events that fall below the configured threshold value. b
If the threshold were too high, the rule would miss low-volume attacks consistently — not 12% of all events randomly. The 12% miss rate with confirmed data presence points to a timing issue, not a threshold issue. Events exist in the workspace but the rule does not see them because they arrive outside the query window. Section 1.2 explains the relationship between frequency, lookback, and ingestion delay.
The 5-minute execution delay is consuming part of the lookback window, effectively reducing coverage to 0 minutes of actual data examination. c
The 5-minute execution delay shifts when the rule runs, not what data it examines. A rule scheduled for 10:00 executes at 10:05 but still queries using the configured lookback relative to the scheduled time. The delay does not reduce the lookback window. Section 1.2 explains that the delay exists to allow events to be ingested before the rule queries for them — it is a buffer, not a reduction in coverage.
The NRT rule limit of 50 rules per workspace is being hit, causing some scheduled rule executions to be skipped. d
The 50-rule workspace limit applies only to NRT rules, not scheduled rules. Scheduled rules have no practical execution limit — a workspace can run hundreds. The issue is a timing gap between frequency and lookback, not a capacity constraint. Section 1.5 explains the NRT-specific limits.
Scenario 5. Your detection rule runs every 15 minutes against SigninLogs. An ongoing password spray targets 5 user accounts over 3 hours. Alert grouping is disabled (the default). How many incidents does the SOC see?
One incident — Sentinel automatically correlates related authentication events into a single investigation. a
Sentinel does not automatically correlate alerts from repeated rule executions. Without alert grouping enabled, every alert from every execution creates its own incident. Automatic correlation would require either alert grouping configuration or Fusion detection — neither is active in this scenario. Section 1.6 explains that the default is no grouping.
Five incidents — one per targeted user account, because entity mapping on the Account field naturally groups alerts by user. b
Entity mapping determines which entities appear in the alert and investigation graph — it does not control incident grouping. Even with Account entity mapping, each alert creates its own incident when alert grouping is disabled. Entity-based alert grouping must be explicitly enabled on the Incident settings tab. Section 1.6 distinguishes entity mapping (Stage 3 — enrichment) from alert grouping (Stage 5 — incident creation).
Up to 12 separate incidents per user — one per rule execution that detects activity above the threshold — for a potential total of 60 incidents across 5 users over 3 hours. c
With a 15-minute frequency over 3 hours, the rule executes 12 times. If each execution detects activity for 5 users and event grouping is set to AlertPerResult, each execution produces up to 5 alerts, each creating its own incident. Without alert grouping, 3 different analysts could independently investigate the same user. Section 1.6 teaches that enabling entity-based grouping on Account with a 24-hour window would consolidate all alerts for each user into a single incident.
One incident per rule execution — 12 total — because the default event grouping bundles all results from each execution into a single alert. d
If event grouping is set to the default (group all events into a single alert), each execution produces one alert containing all 5 users. That would create 12 incidents — each containing all 5 users' data mixed together. The analyst would need to parse multiple users from each alert. This is why AlertPerResult is the recommended event grouping for detections where each result row represents an independent finding. Section 1.6 explains how event grouping and alert grouping interact.
Scenario 6. You have 18 active analytics rules. Six have no MITRE ATT&CK technique mapping. Your CISO asks for the organization's ATT&CK coverage percentage. What impact do the unmapped rules have on the coverage report?
No impact — Sentinel calculates coverage from the rule queries themselves, automatically mapping detection logic to ATT&CK techniques regardless of the configured technique tags. a
Sentinel does not analyze query logic to infer ATT&CK techniques. The coverage matrix on the MITRE ATT&CK page counts only rules with explicitly configured technique mappings. If a rule detects T1110 Brute Force but has no ATT&CK mapping configured, the coverage matrix shows zero coverage for T1110. Section 1.4 explains that unmapped rules are invisible to coverage measurement.
The 6 unmapped rules are invisible to the MITRE coverage matrix — they fire and produce alerts, but the coverage percentage understates the actual detection capability because those techniques are not counted. b
The MITRE ATT&CK page in Sentinel shows active coverage only for rules with configured technique mappings. The 6 unmapped rules may detect real techniques, but those techniques appear as uncovered gaps in the matrix. The coverage percentage reported to the CISO is lower than reality — which could lead to unnecessary investment in rules that already exist but are simply unmapped. Section 1.4 teaches that mapping takes 30 seconds per rule and is required for accurate coverage reporting.
The unmapped rules cannot participate in Fusion correlation but still appear in the coverage matrix because Sentinel counts all active rules regardless of mapping status. c
Both claims are partially wrong. Unmapped rules do fail to participate in Fusion correlation (correct), but they also do not appear in the coverage matrix (incorrect). The matrix specifically counts technique mappings, not active rules. An active rule without ATT&CK mapping is invisible to both Fusion and coverage measurement. Section 1.4 explains both purposes of ATT&CK mapping.
Minimal impact — ATT&CK coverage is a secondary metric. The primary metric is rule count, which includes all 18 active rules regardless of mapping. d
Rule count is not a meaningful detection metric. An organization with 100 rules that all detect variants of the same technique has 100 rules and coverage for one technique. ATT&CK coverage percentage — distinct techniques with at least one active detection divided by relevant techniques — is the primary metric for evaluating a detection program. Section 1.4 and DE0 both establish coverage percentage as the foundational metric.
Scenario 7. A colleague builds a detection rule and deploys it without a rule specification. Six months later, the rule fires 15 times per week with a 40% false positive rate. You are asked to tune it. The rule name is "Suspicious Activity Detection" and the description is empty. What is the first problem you face?
You cannot determine the original detection hypothesis — without knowing what the rule was designed to detect and why, you cannot evaluate whether the false positives represent a tuning problem or a fundamentally flawed design. a
The rule specification exists to answer exactly this question. Section 1.7 teaches that the hypothesis is the foundation of the specification — it defines what the rule detects in specific, testable terms. Without it, you must reverse-engineer the KQL to infer the original intent, which may lead you to tune a rule that should be redesigned from scratch. The specification's false positive profile would have documented expected FP sources and the threshold at which the FP rate becomes unacceptable.
You cannot identify the entity mapping configuration — the investigation graph may be empty, preventing effective triage of the alerts. b
Entity mapping is visible in the rule wizard — you can open the rule and check the Set rule logic tab. The entity mapping problem is fixable by inspecting the configuration. The hypothesis problem is not fixable by inspection because the original reasoning exists only in the author's memory. Missing entity mapping is a real issue, but it is the second problem, not the first. Section 1.7 explains that the specification captures reasoning that the wizard does not.
You cannot adjust the threshold because the original baseline data no longer exists — the rule needs to be rebuilt from scratch. c
The threshold can be evaluated by running the query manually and analyzing the current result distribution. You do not need the original baseline — you need the current environment's data. The deeper problem is that without the hypothesis, you do not know whether adjusting the threshold will fix the detection or break it. A rule designed to detect 5+ failed logins has a different tuning approach than a rule designed to detect any encoded PowerShell. Section 1.7 teaches that the specification's maintenance cadence defines how and when to review thresholds.
You cannot determine the ATT&CK mapping — the rule's contribution to coverage measurement is unknown. d
ATT&CK mapping is visible in the rule wizard on the General tab. Like entity mapping, it can be inspected and corrected. The real problem is that without the hypothesis, you do not know which technique the rule was intended to detect, so you cannot evaluate whether the current ATT&CK mapping is correct. Section 1.4 explains that technique mapping should reflect what the rule actually detects, not a best guess.
Scenario 8. You want to detect shadow copy deletion with both fast alerting and automatic device isolation. The detection logic is a filter chain: vssadmin.exe with "delete shadows" in the command line. What is the correct multi-engine deployment?
A single Defender XDR custom detection with device isolation as the response action — one rule handles both alerting and response, eliminating the need for a Sentinel rule. a
A Defender custom detection handles the automated response, but Sentinel NRT provides faster alerting to the SOC. Defender custom detections run at hourly frequency minimum (or continuous/NRT, but with different latency characteristics). The Sentinel NRT rule fires within 2-3 minutes and appears in the Sentinel incident queue where the SOC triages. Relying on a single engine means you get either fast alerting or automated response, but the multi-engine pattern gives you both. Section 1.5 teaches the complementary engine approach.
A Sentinel scheduled rule at 5-minute frequency plus an automation rule that triggers device isolation via a playbook when the alert fires. b
A 5-minute scheduled rule has 10-minute worst-case latency (5-minute frequency + 5-minute execution delay). Ransomware encryption starts within 60-90 seconds of shadow copy deletion. The scheduled rule is too slow for this detection. Additionally, playbook-based device isolation through Sentinel automation adds latency compared to Defender's native isolation action. Section 1.5 identifies NRT as the correct Sentinel rule type for time-critical detections.
Two Sentinel NRT rules — one for alerting and one configured with an automation rule for device isolation — keeping everything in the Sentinel engine for unified management. c
Two NRT rules for the same detection wastes the 50-rule workspace limit. More importantly, Sentinel automation rules invoke playbooks for response actions — they do not natively isolate devices. Device isolation requires either a Defender custom detection response action or a Logic App playbook that calls the Defender API, which adds latency and complexity. Section 1.5 explains that Defender custom detections have native response actions that Sentinel does not.
A Sentinel NRT rule for sub-minute SOC alerting plus a Defender XDR custom detection with automatic device isolation — both fire on the same attack, each serving a different operational purpose. d
This is the multi-engine pattern from Section 1.5. The NRT rule detects shadow copy deletion within 2-3 minutes and creates a Sentinel incident for SOC visibility. The Defender custom detection queries DeviceProcessEvents for the same activity and triggers automatic device isolation — cutting the device off from the network before encryption spreads to network shares. Both rules fire. The NRT rule tells the SOC what happened. The Defender custom detection stops it from getting worse. The detection engineer's job is to choose the right engine for each purpose.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.