Six scenario questions. Each presents a situation and asks what you'd do or what you'd conclude. Pick your answer before reading the explanation.
Scenario 1. Your team has a Sigma rule for T1003.001 (LSASS Memory — credential dumping). The rule was written two years ago after a pen test where Mimikatz was run directly. The pen test report showed the rule fired. Since then, no alerts have been generated. A colleague says this means no credential dumping has occurred. What is the most accurate assessment?
The colleague is correct — no alerts means no credential dumping has occurred a
Incorrect. Absence of alerts is ambiguous. It could mean the attack hasn't occurred, or the rule is broken, or the telemetry pipeline has failed. Without testing, you can't tell.
The rule is probably fine but should be reviewed annually as a best practice b
Annual review is better than nothing, but it doesn't validate whether the rule fires. A review checks the logic; a test checks the result. The rule could pass a logic review and still fail against modern variants.
Silence is ambiguous — the rule may not match current attacker variants, the pipeline may be broken, or a field name may have changed. Testing is the only way to know. c
Correct. The rule was tested against one variant (direct Mimikatz). Modern attackers use procdump, comsvcs.dll, NanoDump, and direct syscalls — each produces different telemetry. Without firing multiple variants and checking, silence is not evidence of security.
The rule needs updating because Mimikatz has new versions d
The problem isn't Mimikatz versions — it's that attackers use entirely different tools now. Updating the rule for newer Mimikatz binaries misses the broader issue: the rule matches one tool, not the technique.
Scenario 2. Your detection coverage dashboard shows 47 analytics rules deployed in Sentinel. Your IT director asks what percentage of ATT&CK techniques you can detect. You check the dashboard and calculate that 47 rules cover approximately 35 unique ATT&CK techniques out of the 120 in your threat model scope — roughly 29%. How should you present this number?
Report 29% coverage with confidence — the rules are deployed and the mapping is accurate a
29% is the deployed coverage, not the validated coverage. Deployed means "a rule exists." Validated means "the rule has been tested against the actual technique and confirmed to fire." These numbers diverge significantly in most environments.
Report 29% as deployed coverage, but note that validated coverage — techniques where the rule has been tested in the last 90 days — is likely much lower and needs measurement b
Correct. Deployed coverage and validated coverage are different metrics. The 29% represents rules that exist. Validated coverage requires evidence that each rule fires against the actual technique. Without testing, deployed coverage is a configuration metric, not a security metric.
Report 29% but recommend purchasing additional detection content packs to increase the number c
More rules doesn't mean more coverage if existing rules aren't validated. Adding content packs increases deployed coverage without improving validated coverage — the gap grows larger.
Don't report a number — coverage percentages are misleading and shouldn't be shared with leadership d
Coverage percentages are valuable when they're honest. The problem isn't the metric — it's reporting deployed coverage as if it were validated coverage. A three-tier breakdown (validated, deployed-untested, uncovered) is the honest report.
Scenario 3. After running T1059.001 (PowerShell execution) against your lab, your detection rule fires in Sentinel but you also see 14 additional alerts from the same rule triggered by legitimate PowerShell activity — IT automation scripts, monitoring tools, and scheduled maintenance tasks. How do you classify these 14 alerts?
Environmental false positives — the rule is correct but the environment produces legitimate activity that matches the same pattern. Fix with narrow exclusions scoped to the specific processes. a
Correct. Environmental FPs are the most common type. The rule is detecting the behaviour correctly — the environment has legitimate activity that produces the same telemetry shape. Fix with narrow exclusions (by hash, parent process, or user context), then retest to confirm the exclusions don't also suppress real attacks.
Rule-logic false positives — the rule is too broad and should be rewritten to match only malicious PowerShell patterns b
If the rule correctly detects the attack technique (it did — it fired on the T1059.001 test), the logic isn't too broad for its purpose. The legitimate activity happens to match the same pattern. Tightening the rule might suppress the real attack too.
Benign true positives — the activity is real and authorised, so close the alerts and tune out all PowerShell c
Tuning out "all PowerShell" would suppress the real attack. Benign true positives are handled case-by-case (acknowledge, classify, close) — but 14 per test run is an FP problem that needs exclusions, not blanket suppression.
Noise — disable the rule until a more precise version can be written d
Disabling a working detection rule because of false positives is how coverage rots. The rule works — it caught the attack. The FPs need tuning, not rule removal.
Scenario 4. You measure MTTD for your credential dumping detection rule (T1003.001). The attack executes at 14:32:00. The Sentinel analytics rule is scheduled to run every 5 minutes. The first alert appears at 14:37:12. What is the MTTD, and what does the number tell you?
MTTD is 5 minutes 12 seconds — this is acceptable because the rule runs every 5 minutes a
The MTTD calculation is correct but "acceptable" depends on what happens after the alert fires. 5 minutes of undetected credential access may or may not be acceptable depending on containment automation and response time.
MTTD is 5 minutes 12 seconds — the attacker has five minutes of undetected access, and whether that's acceptable depends on the response time after the alert fires b
Correct. MTTD is a measurement, not a verdict. It becomes meaningful in the context of what happens next — the response time, the containment automation, and the attacker's likely actions during the detection gap. If automated isolation triggers in under a minute, total exposure is six minutes. If the alert sits in a queue for hours, the MTTD is irrelevant.
MTTD is too slow — convert the rule to a near-real-time (NRT) rule immediately c
NRT rules reduce MTTD to seconds, but they cost more in compute and may not be available for all query types. Whether to convert depends on the technique's risk and the containment architecture — not on the MTTD number alone.
MTTD doesn't matter for credential dumping because the credentials are already stolen d
MTTD matters because it determines how long the attacker can use the stolen credentials before containment. Faster detection means faster password reset, session revocation, and lateral movement disruption.
Scenario 5. Your quarterly coverage assessment shows that of 61 techniques in scope: 18 validated in the last 90 days, 27 with deployed but untested rules, and 16 with no rules at all. Your IT director asks whether the programme is working. What do you report?
Coverage is 74% — 45 techniques have rules, the programme is on track a
74% is the deployed coverage, not the validated coverage. Reporting deployed coverage as "coverage" is the exact problem the purple-team programme is designed to fix.
Coverage is 30% — the programme is failing and needs more resources b
30% validated coverage in the first quarter is a starting point, not a failure. The programme is surfacing gaps that were previously invisible. The metrics themselves are evidence of progress.
Report the three-tier breakdown: 30% validated, 44% deployed-untested, 26% uncovered. The programme is working because it's identifying gaps. Prioritise testing the 27 untested rules next. c
Correct. The three-tier breakdown is the honest report. The 27 deployed-untested rules are the highest-value next step — some will pass (raising validated coverage quickly), some will fail (exposing broken rules). The 16 uncovered techniques go to the remediation backlog, prioritised by threat frequency.
Wait until validated coverage reaches 60% before presenting to leadership d
Delaying reporting means leadership doesn't know the real state. The value of the programme is transparency — presenting the honest numbers, the trend, and the remediation plan. Waiting until the numbers look good defeats the purpose.
Scenario 6. Your team ran the weekly technique-of-the-week for eight consecutive weeks. In week nine, a production incident consumed the team's time and the test was skipped. By week twelve, the weekly cadence has not resumed. What is the most effective response?
Accept that purple teaming is aspirational — real-world priorities will always displace it a
If the cadence can't survive one busy week, the scope is too large. The answer isn't to give up — it's to make the weekly test small enough to survive high-load periods.
Catch up by running three techniques in one session to cover the missed weeks b
Catching up produces rushed results with lower quality. The missed weeks are logged in the cadence tracker. Future coverage comes from resuming the rhythm, not compressing it.
Resume immediately with this week's technique. Log the missed weeks honestly. Reduce scope during busy periods — a single 15-minute atomic test beats skipping entirely. c
Correct. Cadence compliance is about sustainability, not perfection. Missing weeks happens. The fix is resumption plus a protocol for reduced-scope testing during busy periods. A reduced-scope test (one atomic, 15 minutes) during an incident week is better than no test.
Assign the weekly test to a different team member so no single person's workload can displace it d
Distributing the load helps but doesn't address the root cause. If the whole team is in incident response, delegation doesn't help. The reduced-scope protocol is the structural fix.
Scoring
If you answered four or more correctly, you have the mindset and vocabulary Module 0 intended to build. Move to Module 1.
If you answered fewer than four correctly, re-read PT0.2 (The Purple-Team Mindset) and PT0.3 (The Vocabulary of Coverage) before starting the lab build. The concepts in those subs are the lens every subsequent module looks through.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You've built the lab and understand the validation gap.
Module 0 showed you why detection rules fail silently — vendor schema changes, attacker tool evolution, environment divergence, tuning drift. Module 1 gave you a working four-environment, three-SIEM purple-team lab. From here, you walk the kill chain technique by technique.
61 ATT&CK techniques across 12 tactic modules — Initial Access through Impact, each walked end-to-end with attack commands, annotated telemetry, and multi-SIEM detection rules
Every detection in four formats — Sigma rule (canonical), Sentinel KQL, Defender XDR Advanced Hunting KQL, and Splunk SPL or Elastic. Tabbed side-by-side in every technique sub
Module 14 Capstone — CHAIN-HARVEST — full purple-team exercise on an AiTM credential-phishing chain. Multi-stage attack, detection results across all three SIEMs, coverage gaps, tuning recommendations
Programme template — coverage matrix, MTTD per technique, FP rates, detection quality scores, remediation backlog. Populated as you work, presentable to leadership by Module 14
Public Sigma rule repo — every detection rule in a GitHub repository. Alumni contribute via PR. The artefacts outlive the course
