DE0.14 Check My Knowledge

Answer: 18 / 130 = 13.8% coverage. This is slightly above Northgate Engineering's baseline of 10.3% (15 / 145) — but both are in the same range. Having 55 rules instead of 23 did not meaningfully improve coverage because many of the additional rules detected the same techniques through different methods. The headline number (55 rules) masks the reality (13.8% technique coverage). The vendor's "above-average" claim is likely based on rule count, not technique coverage — a vanity metric.

Answer: Layer 2 — the rule exists but does not fire. The rule queries the correct data source (OfficeActivity) and the correct event type (New-InboxRule), but the KQL filter only matches forwarding actions (ForwardTo, RedirectTo). The attacker used a MoveToFolder action, which the rule's logic does not cover. The rule exists, the technique executes, and the rule does not fire because the KQL does not match the specific attack variant. The fix is to broaden the rule to detect ALL inbox rule creation from risky sessions, regardless of the rule's action type — or to build a separate rule specifically for folder-move rules to financial keyword folders.

Answer: Session token anomaly detection. Query SigninLogs for the interactive sign-in (the legitimate auth through the AiTM proxy) and then query AADNonInteractiveUserSignInLogs for subsequent token refresh events. The detection signal: a non-interactive token refresh from a different IP address than the interactive sign-in that created the session, where the device details (browser, OS, device compliance state) do not match the user's baseline. This detects AiTM regardless of geographic proximity because it looks at the session behavior, not the sign-in location.

Answer: Cost per detection: $2,700 / 12 = $225 per threat detected. Whether that is "good" depends on what those incidents would have cost if undetected. If the average incident cost for your industry is $100,000+ (per breach data), then $225 to detect and contain each threat before it escalates represents significant ROI. The more informative answer: "Our detection program identified 12 threats last month at $225 each. Without these rules, those threats would have operated undetected — our CHAIN-HARVEST analysis showed that similar attacks go undetected for 3+ hours, enough time for BEC, data exfiltration, or ransomware staging. As we add more rules and improve technique coverage, the same $2,700 will detect more threats — cost per detection will decrease while the value increases."

Answer: First, false positive flood. Template rules use generic thresholds designed for the broadest possible customer base. In your specific environment, many will fire on legitimate activity — IT admin PowerShell automation, field engineer travel patterns, manufacturing USB usage. Within weeks, analysts learn to ignore the noisy rules, which degrades response to ALL rules (Layer 3 detection failure). Second, false sense of coverage. Having 200+ rules creates the appearance of comprehensive detection, but many templates detect the same techniques through different methods, template logic may not match the specific attack variants targeting your environment, and no template has been validated against your historical data. Assumed coverage is not confirmed coverage. The correct approach: enable templates selectively based on your threat model, and tune each one for your environment before trusting it.

Answer: Level 1 — Reactive. Rules are added after incidents (reactive trigger). No version control. No FP tracking. Vanity metrics (rule count). The single most impactful improvement is starting FP classification. Adding a TP/FP/BTP tag to each incident at closure (2 seconds of effort) provides the data needed to identify which rules need tuning (highest FP rate), which rules are effective (highest TP rate), and enables two real metrics (TP rate and FP rate) that were previously unmeasured. This one change converts unmeasured rules into data-informed rules and unlocks the tuning cycle that defines Level 2.

Answer: Sentinel analytics rule. The detection requires a cross-source join between SigninLogs (identity domain) and EmailEvents (email domain) with a time-windowed correlation. While both tables are available in Defender XDR Advanced Hunting, Sentinel provides: configurable query frequency (including NRT for near-real-time detection), automation rules that can trigger containment playbooks (disable the account, revoke sessions), and incident grouping that correlates the identity alert with the email alert into a single incident for the SOC. The cross-source correlation is the core advantage of building in Sentinel.

Answer: The full-mesh SD-WAN with permissive inter-site firewall rules. RDP is allowed between corporate VLANs at all sites for IT support convenience. The attacker uses this to move: Edinburgh (VPN entry) → Bristol (hub, domain controller access) → Sheffield (target, legacy Server 2016). The detection must correlate: new VPN session for the compromised user (SigninLogs or VPN logs) → RDP connection to Bristol server (DeviceNetworkEvents, DeviceLogonEvents) → WMI or RDP execution on Sheffield server from Bristol (DeviceProcessEvents, DeviceLogonEvents). This cross-site chain requires joining events across multiple device entities with a shared user entity — the kind of multi-hop correlation that templates do not provide.

Answer: Step 1 (Design): Write the rule specification — ATT&CK mapping (T1621 Multi-Factor Authentication Request Generation), data source (SigninLogs, AADNonInteractiveUserSignInLogs), KQL logic (count MFA prompts denied by the user within a rolling 30-minute window, fire when count exceeds threshold), entity mapping (Account, IP), severity (High — MFA bypass leads directly to account compromise), FP analysis (legitimate MFA failures from app updates, device changes), and response procedure (contact user, verify session, revoke if unauthorized). Step 2 (Build): Write the KQL, test in Advanced Hunting against historical data. Step 3 (Test): Validate against the historical MFA bombing events the hunter found — does the rule fire? Estimate FP rate by running the rule against 30 days of data — how many non-malicious MFA denial clusters does it match?

Answer: First, the coverage gap: "Our current analytics rules cover 10.3% of the attack techniques relevant to our industry. An attacker operating in the remaining 89.7% generates no alerts." This is specific, quantified, and alarming. Second, the CHAIN-HARVEST walkthrough: "A standard AiTM phishing attack — the most common attack type against organizations like ours — traversed five phases over nearly four hours without triggering a single alert from our existing rules. The data was in our SIEM. No rule looked at it." This converts the abstract percentage into a concrete scenario the CEO can understand. Third, the ROI argument: "Detection engineering builds rules against data we already pay to ingest. Our Sentinel cost is $2,700/month. Adding detection rules does not increase that cost — it extracts more value from the existing investment. In 90 days, we target 35% coverage with measurable MTTD improvement and a quarterly metrics report." This addresses the CFO's cost concern directly.