DE1.14 Check My Knowledge
Check my knowledge
These questions test architectural decision-making — the ability to choose the correct rule configuration for a given detection scenario. If you can answer these without referring back to the subsections, you are ready for DE2.
Question 1 — Rule type selection
You need to detect bulk email forwarding rule creation from sessions with recent identity risk signals. The detection requires joining SigninLogs with OfficeActivity within a 60-minute time window. Which rule type do you use?
Answer: Scheduled rule. The detection requires a cross-table join (SigninLogs + OfficeActivity) with a time-windowed correlation. NRT rules do not support joins or aggregation operators. The scheduled rule runs every 15 minutes (High severity — inbox rule creation from risky session indicates active persistence) with a 60-minute lookback to capture the correlation window. Entity mapping: Account → UserPrincipalName, IP → IPAddress. MITRE: T1137.005 (Outlook Rules).
Question 2 — Lookback configuration
A scheduled rule runs every 30 minutes with a 25-minute lookback. An event occurs at 10:28. The rule runs at 10:00 and 10:30. Will the event be detected?
Answer: It depends on ingestion timing. The 10:30 execution queries 10:05-10:30 (25-minute lookback). If the event at 10:28 was ingested by 10:30, it is detected. But the gap is the problem: events from 10:00-10:05 are NEVER scanned — the 10:00 execution covered 09:35-10:00, and the 10:30 execution starts at 10:05. Any event in the 5-minute gap (10:00-10:05) is permanently missed. Fix: increase lookback to 33-35 minutes (frequency + 10-15% buffer).
Question 3 — Entity mapping impact
Rule A detects password spray and maps only IP entity. Rule B detects suspicious inbox rule creation and maps only Account entity. Both rules fire for the same attack (CHAIN-HARVEST). The spray came from IP 198.51.100.45 and compromised s.chen, who then had an inbox rule created. Will Sentinel correlate these into one incident?
Answer: No. Rule A maps IP but not Account. Rule B maps Account but not IP. There is no shared entity between the two alerts. Sentinel requires at least one shared entity type to correlate alerts from different rules. The fix: Rule A should also map Account (the targeted user), and Rule B should also map IP (the source of the risky session). With both rules mapping both entity types, the shared Account (s.chen) and IP (198.51.100.45) enable cross-rule correlation into a single incident showing the complete attack chain.
Question 4 — Severity assignment
A detection rule identifies PIM activation for Global Admin at 02:00 on a Sunday. The confidence is medium (could be a legitimate emergency — NE has 8 users eligible for Global Admin, and emergency access scenarios occur 2-3 times per month). The impact if this is attacker activity is catastrophic (Global Admin can modify any setting). What severity do you assign?
Answer: High severity. Using the matrix: medium confidence × catastrophic impact = High. Not Critical, because the TP rate will be low — 2-3 legitimate activations per month means most alerts are authorized. Critical severity on a frequently-firing rule trains the SOC to ignore Critical alerts (the most dangerous form of alert fatigue). High severity ensures the alert is triaged within 15 minutes — fast enough to catch unauthorized activation without crying wolf on every legitimate emergency access. The off-hours timing (02:00 Sunday) is a useful enrichment factor that the analyst evaluates during triage — it increases suspicion but does not alone confirm malicious intent.
Question 5 — NRT decision
You build a detection rule for AiTM session token theft. The rule joins SigninLogs with AADNonInteractiveUserSignInLogs to identify non-interactive token refreshes from different IPs than the preceding interactive sign-in. Should this be an NRT rule?
Answer: No. The detection requires a join between two tables (SigninLogs + AADNonInteractiveUserSignInLogs) — NRT rules do not support joins. Additionally, the detection requires comparing the current non-interactive event against the preceding interactive sign-in, which requires either a join or a time-windowed aggregation — both unsupported in NRT. This must be a scheduled rule. At 5-minute frequency (High severity — AiTM leads to full account compromise), the average detection latency is ~5.5 minutes — near-real-time in practical terms, with full correlation capability.
Question 6 — Alert grouping
Your password spray detection rule fires 15 times in 2 hours. Each alert identifies the same source IP but a different target user. Grouping is set to "one alert per incident." How many incidents does the SOC see, and what should the grouping be?
Answer: 15 separate incidents — one for each alert. The SOC sees 15 incidents that are actually the same spray from the same IP. The analyst investigates the first 3, realizes they are duplicates, and starts closing the rest without investigation. Change grouping to "by entity" on IP: all 15 alerts share IP 198.51.100.45 and group into 1 incident. The SOC sees 1 incident containing the complete spray data — all targeted users, timing, and source IP in one investigation target.
Question 7 — Automation tier
A detection rule for "suspicious MFA registration from new device" has a 65% TP rate after 30 days in production. Your SOC lead wants to automate account disabling when this rule fires. What is your recommendation?
Answer: Do not automate containment at 65% TP rate. 35% of the time, the automation will disable a legitimate user registering MFA on a new phone — creating helpdesk tickets, user frustration, and executive escalations. At 65% TP rate, deploy Tier 2 automation: enrich the incident with user context (department, recent sign-in history, device compliance), send a Teams notification to the user ("Did you just register a new MFA method?"), and assign to the on-call analyst. Pursue containment automation only after tuning improves the TP rate above 90% — or change the automated action to something less disruptive (require MFA re-verification rather than account disable).
Question 8 — Rule specification
An engineer deploys a "suspicious PowerShell execution" rule without a specification. Two weeks later: 40 alerts per day (mostly IT automation FPs), no ATT&CK mapping, no entity mapping, no response procedure. Which specification sections would have prevented ALL of these problems?
Answer: Four sections: (10) False Positive Analysis — running the query against 30 days of historical data would have identified the IT automation pattern before deployment, prompting a service account exclusion filter. (3) MITRE ATT&CK Mapping — mapping to T1059.001 (PowerShell) would have included the rule in coverage reporting and provided triage context. (6) Entity Mapping — mapping Account and Host entities would have enabled correlation with other rules. (11) Response Procedure — documenting the triage steps would have given analysts clear guidance on how to investigate and when to escalate. 15 minutes of specification writing prevents 2 weeks of operational pain.
Question 9 — Two-stage anomaly detection
An anomaly rule detects that j.morrison (NE field engineer) had 85 token refreshes from 6 IPs yesterday — 4x his normal baseline. The anomaly score is 0.82. Should the SOC investigate based on the anomaly record alone?
Answer: Not based on the anomaly alone. The anomaly is a behavioral signal — it indicates deviation but not intent. Morrison could be traveling (hotel WiFi rotates IPs), using a new device, or working from a client site. The Stage 2 scheduled rule joins the anomaly with SigninLogs: were the token refreshes from IPs in Morrison's travel history? Did the device details match his enrolled device? Was there a risky sign-in classification? If the anomaly correlates with identity risk signals → investigate as potential CHAIN-MESH Phase 1. If the anomaly stands alone → likely legitimate travel. The two-stage pattern prevents investigating every behavioral deviation while ensuring threat-correlated deviations are escalated.
Question 10 — Defender XDR vs Sentinel
You need to detect CHAIN-MESH Phase 5: WMI remote execution from Bristol to Sheffield. The detection requires joining DeviceProcessEvents (wmiprvse.exe child process on Sheffield server) with CommonSecurityLog (Palo Alto firewall inter-site allow). Which detection platform do you use?
Answer: Sentinel analytics rule. The detection requires CommonSecurityLog — a third-party data table that Defender XDR custom detections cannot query. The cross-source join between endpoint telemetry (DeviceProcessEvents) and network telemetry (CommonSecurityLog) is Sentinel-only. Schedule at 5-minute frequency (High severity — lateral movement to the Sheffield plant indicates active ransomware staging). Entity mapping: Host → target DeviceName (Sheffield server), Account → initiating user, IP → source IP (Bristol server).
Question 11 — Frequency optimization
Your organization has 40 analytics rules, all running at 5-minute frequency. The workspace query execution count is approaching the daily limit. How do you reduce query executions without meaningfully increasing detection latency for critical threats?
Answer: Redistribute frequency by severity. Currently: 40 × 288 = 11,520 daily executions. Audit each rule's severity using the confidence × impact matrix. Typical redistribution: 5 rules at 5-min (Critical/High) = 1,440 executions, 10 rules at 15-min (High) = 960, 15 rules at 1-hr (Medium) = 360, 10 rules at 24-hr (Low) = 10. Total: 2,770 — a 76% reduction. Detection latency for Critical rules: unchanged (5 min). Detection latency for Medium rules: increases from ~5 min to ~33 min average — acceptable because Medium alerts are triaged within 2 hours regardless. The SOC sees no difference in their Critical/High response times while the workspace operates within its query budget.
Question 12 — Complete architecture decision
You are building the ransomware pre-encryption detection for NE (CHAIN-MESH Phase 7). The detection fires on vssadmin shadow copy deletion by non-SYSTEM processes. Design the complete architecture: rule type, frequency, lookback, severity, entity mapping, grouping, automation tier, and whether to dual-deploy in Defender XDR.
Answer: Rule type: NRT (single-event pattern, high confidence, catastrophic impact, every second matters). Frequency: ~1 min (NRT fixed). Lookback: since last run (NRT automatic). Severity: Critical (high confidence — non-SYSTEM vssadmin shadow delete is virtually always malicious; catastrophic impact — ransomware encryption in progress). Entity mapping: Host → DeviceName, Account → InitiatingProcessAccountName, Process → ProcessCommandLine. Grouping: one-per-alert (each device with ransomware activity is an independent critical finding requiring separate containment). Automation: Tier 1 auto-contain — playbook isolates the device via Defender API and sends Teams alert to SOC channel. Dual deploy: Yes — Sentinel NRT for detection + SOC alerting, Defender custom detection (1-hour frequency) for automated device isolation as a backup containment mechanism. Companion scheduled rule: 5-minute frequency joining DeviceProcessEvents with recent DeviceLogonEvents to identify the source of the lateral movement that delivered the ransomware — providing the investigation context that NRT cannot.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You're reading the free modules of Detection Engineering
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.