How to build a logging, detection and triage capability that finds the adversary yourself instead of waiting for someone else to call you — and how to prove honestly what it does and does not cover.
Who needs this: Detection engineers, SOC analysts and leads, security architects, platform and identity engineers, the CISO signing the log-ingest invoice | Read time: 26 min | Maps to: CSF 2.0 DETECT (DE.CM, DE.AE), RESPOND (RS.AN) | CIS Controls 8, 13, 17 | ISO 27001 A.5.7, A.8.15, A.8.16
Welcome back, fellow defenders. This is the chapter where we stop talking about what we would do if we noticed, and start talking about noticing.
In August 2026, the incident response firm Sygnia published work on a China-nexus espionage actor tracked as Fire Ant, which had extended a long-running campaign from VMware hypervisors into Cisco IOS XR routers, TACACS servers and the Linux management hosts that route, authenticate and administer high-value networks. The part that should keep you up is not the router firmware. It is that the actor hijacked the credential and logging path at the same time — stealing credentials while blinding the security logs that would have shown the theft (The Hacker News). Rob the vault and disable the cameras in one motion. MITRE apparently agreed this had become a category rather than a trick: in the April 2026 ATT&CK release, the Defense Evasion tactic was split in two, and TA0112 Defense Impairment became a tactic in its own right (ATT&CK v19 release notes).
Now the number that decides whether any of this matters to your organization. Mandiant's 2026 frontline data puts global median dwell time at 14 days, up from 11. Break that by who found the intrusion and the aggregate dissolves: 26 days when an external party notified the victim, 10 days when the organization detected it itself, and 5 days when the adversary announced themselves with a ransom note. Fifty-two per cent of activity was detected internally, up from 43% (M-Trends 2026). The gap between 26 and 10 is the entire value proposition of this chapter, expressed in days of adversary freedom.
Two more figures set the design constraints. Eighty-two per cent of CrowdStrike's detections in the period were malware-free — meaning your endpoint agent's signature engine was a spectator (CrowdStrike 2026 Global Threat Report). And the median hand-off from initial-access broker to the ransomware operator is now 22 seconds, down from over eight hours in 2022 (M-Trends 2026). There is no longer a comfortable window between "someone got in" and "someone monetised it." Detection that arrives the next business morning arrives after the encryption.
The governing document to cite, and to hand to the finance director who thinks log storage is an IT line item, is "Best Practices for Event Logging and Threat Detection", published 22 August 2024 by ASD's ACSC with CISA, the FBI, NSA and international partners (CISA resource page, PDF). Its retention paragraph is the single most useful thing anyone has written on this:
"Organizations should ensure they retain logs for long enough to support cyber security incident investigations. Default log retention periods are often insufficient. Log retention periods should be informed by an assessment of the risks to a given system. When assessing the risks to a system, consider that in some cases, it can take up to 18 months to discover a cyber security incident and some malware can dwell on the network from 70 to 200 days before causing overt harm."
Note what that guidance deliberately does not do: it sets no single numeric minimum. Anyone telling you "CISA says twelve months" is quoting OMB Memorandum M-21-31, a US federal directive binding on civilian executive-branch agencies and widely borrowed as a benchmark elsewhere (M-21-31, ).
Set retention against your dwell time, not against a compliance floor. The median is 14 days, which flatters everyone. Espionage and DPRK IT-worker cases sat at a 122-day median, and BRICKSTORM intrusions on edge devices averaged roughly 400 days (M-Trends 2026). If you hold 90 days of identity logs and the intrusion started on day 200, your investigation does not produce a partial answer. It produces no answer, and your notification letter has to say "we cannot determine the scope," which is the most expensive sentence in incident communications.
Here is the uncomfortable default picture. These are the vendors' documented retention periods, not folklore.
| Source | Default retention | The trap |
|---|---|---|
| Microsoft Entra ID audit and sign-in logs | 7 days Free; 30 days P1/P2 | Diagnostic settings to Log Analytics/Sentinel/Event Hub/Storage are the only route past 30 days |
| Entra ID risky sign-ins | 7 days Free; 30 days P1; 90 days P2 | Risky users have no limit; risky sign-ins do |
| Microsoft Graph activity logs | Not retained at all unless routed | P1/P2 only, and off until you integrate storage or analytics |
| Microsoft Purview Audit (Standard) | 180 days (raised from 90) | Premium is 1 year; 10 years needs the add-on and a custom retention policy that someone actually created and targeted |
| AWS CloudTrail Event history | 90 days, management events only | Data events (S3 object-level, Lambda invoke) are opt-in and off by default |
| GCP Admin Activity / System Event | 400 days, not configurable, not deletable | Data Access logs are 30 days and off by default |
| Google Workspace admin/login/OAuth/Drive | 6 months | Email log search is 30 days; admins cannot extend any of it |
Sources: Microsoft Entra data retention, Purview audit log retention policies, CloudTrail concepts, Cloud Logging buckets, Workspace data retention and lag times. Chapter 6 owns the cloud control-plane configuration detail; what matters here is the shape of the wall.
And the sentence to tape above the SIEM: log retention changes are not retroactive. Microsoft states it plainly — upgrade from Free to P1 mid-investigation and you get only the data still inside the seven-day window. "Data that has already expired can't be recovered unless it was previously archived" (Microsoft). You cannot buy evidence after the fact. Licensing is a preparation control, and it belongs in the same budget conversation as backups.
The joint guidance publishes an enterprise log-source priority list. The top of it, in the order the authors intended: (1) critical systems and data holdings likely to be targeted; (2) internet-facing services including remote access, their network metadata and their underlying server OS; (3) identity and domain management servers; (4) other critical servers; (5) edge devices — boundary routers, firewalls; (6) administrative workstations; (7) highly privileged systems, explicitly including CI/CD, configuration management, vulnerability scanning and secret management; (8) data repositories; (9) security-related and critical software. Then user computers, application logs, web proxies, DNS, email, DHCP and legacy assets. OT gets its own ordering — safety- and service-critical devices first, then internet-facing OT — with the standing warning that excessive logging degrades memory- and processor-constrained embedded devices, so supplement with network sensors rather than crushing the PLC.
Two requirements from the same document that teams routinely skip. First, PowerShell: "Ensure that logging captures command execution, script block logging and module logging for PowerShell, and detailed tracking of administrative tasks." Second, LOLBins by name — on Linux curl, systemctl, systemd, python; on Windows wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, regsvr32.exe. When 82% of detections are malware-free, these binaries are the attack tooling.
Then the format discipline, which is boring and load-bearing. Timestamps in UTC, formatted to ISO 8601 (2024-07-25T20:54:59.649Z), millisecond granularity ideal, from a validated time source. Structured logs — JSON, consistent schema and field order, with automated normalization, which the guidance calls out as "particularly important" for SaaS logs "that can change over time or without notice." And one rule that is not negotiable in converged environments: time synchronization must be unidirectional — OT synchronises to IT, never the reverse. If your clocks disagree by minutes, your correlation rules produce fiction and your incident timeline will not survive a regulator. Fix time before you fix rules.
Actionable takeaway: Write down your retention period for each of the top five log-source priorities, next to the dwell time you are designing against, and get a named executive to sign the gap. If identity logs are retained for less than twelve months, that is your first budget ask this year — before any new tool.
Fire Ant blinded the logs. Volt Typhoon lived off the land inside critical infrastructure for dwell times measured in years, using minimal malware (CISA AA24-038A). Both share an assumption: the defender's telemetry lives in the same trust domain as the defender's estate, so owning the estate means owning the record.
A log is evidence only if the person it incriminates cannot edit it. That is a plumbing requirement, not a philosophical one.
| Property | What it means concretely | Cheap version |
|---|---|---|
| Different trust domain | The destination does not authenticate against the production identity provider | A separate cloud project or account with its own break-glass admin |
| Different credentials | The forwarder's write credential cannot read or delete | Append-only IAM policy; no Delete verb granted to any pipeline principal |
| Write-once storage | Object lock, immutability, or a WORM tier on the archive | S3 Object Lock in compliance mode on the archive bucket |
| Out-of-band management | Sensors and security devices managed off the production network | A jump host on a separate VLAN with its own MFA |
| Segregated analyst estate | SOC systems segmented from enterprise IT, hardened workstations | Dedicated admin workstations, no email client |
The last two are CISA's own preparation requirements, stated as OPSEC obligations: segment and manage SOC systems separately from broader enterprise IT, manage sensors out of band, use hardened workstations, and avoid tipping off the attacker — do not submit malware samples to public analysis services and do not notify users of compromised systems by email (CISA Federal Playbooks). Chapter 12 covers the same principle applied to backups; the reasoning is identical, and so is the failure.
On S3 Object Lock specifically, one detail decides whether you have immutability or the appearance of it: governance mode is overridable by any principal holding s3:BypassGovernanceRetention, and the S3 console sends that bypass header by default. Compliance mode cannot be overridden by anyone, including the account root (S3 Object Lock). Governance mode plus a console-capable admin is a policy, not a control.
Here is the detection almost nobody writes, and it is the one that catches Fire Ant's whole category. Alert on the absence of logs. A source that stops reporting is either broken or being suppressed, and you cannot tell which from the SIEM's empty result set — which is exactly why an attacker chooses it. The joint logging guidance makes the storage half of this point too: review storage allocations alongside retention, because "many systems will overwrite old logs when their storage allocation is exhausted." A full disk and a hostile actor produce the same silence.
The cheap version costs an afternoon: for every log source, record a normal hourly event-count floor, and raise a ticket when a source falls below it for two consecutive intervals. No product required. Most SIEMs will do this with a scheduled search; if yours will not, a cron job and a webhook will.
Actionable takeaway: Build a source-health dashboard listing every log source, its expected event rate, its last-seen timestamp, and its owner — and page on silence from any source in priority tiers 1 through 3. A dead sensor is an unattended detection failure that has already started.
Every vendor in this space will tell you their category replaces one of the others. None of them do, and pretending otherwise is how organizations end up paying four times for the same telemetry and still missing the intrusion.
| Layer | What it uniquely contributes | What it structurally cannot see | Honest overlap |
|---|---|---|---|
| SIEM | Cross-source correlation, retention, retro-hunting, the query surface for an investigation | Anything you did not ingest; process-level detail unless the endpoint sends it | Substantially overlaps EDR/XDR alerting; the retention and correlation are the non-duplicable part |
| EDR / XDR | Process lineage, in-memory behavior, response actions on the host | Unmanaged devices, network appliances, most SaaS and IdP activity, anything on an OS with no agent | XDR vendors increasingly sell "SIEM-lite"; ingest limits and retention are where that claim breaks |
| NDR | East-west traffic, unmanaged and un-agentable devices, OT segments, C2 beaconing patterns | Encrypted payload content; cloud-native traffic you do not mirror | Overlaps EDR for lateral movement; earns its keep on the assets EDR cannot reach |
| UEBA | Baselines of normal per-identity and per-entity behavior; slow, low-volume anomalies | Anything requiring intent or business context; first-day-of-employment baselines are noise | Frequently a feature of the SIEM you already own, sold again |
Two facts should drive how you weight these. First, 82% of detections were malware-free, so a stack whose centre of gravity is malware identification is aiming at a fifth of the problem (CrowdStrike 2026 GTR). Second, 35% of cloud incidents involved valid account abuse, and attackers bypass MFA by harvesting long-lived OAuth tokens, stealing session cookies and reusing hard-coded keys (CrowdStrike 2026 GTR; M-Trends 2026). Neither of those shows up as a suspicious binary. They show up as identity and control-plane events — priority-3 log sources — behaving in a way that is individually legitimate and collectively wrong.
Rafeeq Rehman's CISO MindMap 2026 names "Consolidate and rationalize security tools" as one of four focus areas for 2026-27, and places the obligation in three separate branches — retire redundant and under-utilized tools under budget, tools and vendors consolidation under governance, and security tools rationalization under M&A (rafeeqrehman.com). Chapter 3 works that map in full. What belongs here is the detection-specific version of the test.
For every product in the detection stack, record five things in a table rather than debating them in a meeting: annual all-in cost including ingest and engineer time (ingest is usually the larger half and never appears on the license line), a named individual owner, the detections it uniquely delivers, the date someone last acted on its output, and what breaks if it is switched off on Friday. An empty "unique detections" column means something else already covers it. Ninety days of no action makes it a subscription, not a control.
If you have no budget and no dedicated analyst, the honest minimum stack is: EDR on every endpoint and server that can run an agent, identity and cloud control-plane logs centralized and retained, PowerShell script-block and module logging on, and a small set of Sigma rules maintained in Git. NDR and UEBA are the second conversation, not the first. CISA's Logging Made Easy (LME) exists precisely for organizations at this end of the budget curve and is named as a companion resource in the joint logging guidance (CISA).
Actionable takeaway: Fill in the five-column table for every detection product this quarter and cancel the first renewal where the "unique detections" column is empty. Spend the saving on log retention, which no vendor will ever sell you as exciting.
A detection is not a saved search. It is a versioned artefact with an author, a test, a documented blind spot and an owner — and if yours are not, you have a folder of tribal knowledge that decays every time someone changes jobs.
Sigma is the vendor-neutral rule format, written in YAML, with a defined schema: title, id (a UUIDv4), status (stable / test / experimental / deprecated / unsupported), description, author, date and modified in ISO 8601, references, tags (MITRE ATT&CK, CAR, TLP, CVE), logsource (product / service / category), detection (named selections plus a condition), falsepositives, and level. Rules convert to platform query languages — Splunk SPL, Sentinel KQL, Elastic DSL and others — through sigma-cli and pySigma backends. SigmaHQ maintains over 3,000 ATT&CK-mapped rules as a public baseline (SigmaHQ, rule format).
The strategic value is not the syntax. It is that your detection logic stops being hostage to the SIEM you happen to be renting. Migrate platforms and you re-run a converter instead of rewriting four hundred rules from memory.
Palantir's Alerting and Detection Strategy (ADS) framework requires nine sections for every detection: Goal, Categorization (ATT&CK mapping), Strategy Abstract, Technical Context, Blind Spots and Assumptions, False Positives, Validation, Priority, Response. Palantir's stated motivation is blunt: "The lack of rigor, documentation, peer-review, and an overall quality bar allowed the deployment of low-quality alerts to production systems" (palantir/alerting-detection-strategy-framework, ADS-Framework.md).
Two sections carry the weight, and they are the two everyone skips. Blind Spots and Assumptions is what tells the responder at 03:00 what this alert cannot tell them — the difference between "the alert is quiet so we are fine" and "the alert is quiet and here is what it never covered." Validation is defined as "the steps required to generate a representative true positive event which triggers this alert. This is similar to a unit test," and Palantir points at Atomic Red Team as one way to satisfy it. Validation is what converts a detection from an assertion into a tested control.
Detections live in Git. Changes go through pull-request review. CI validates and tests. Promotion to production is automated, with rollback (Splunk — What is Detection as Code). A minimum viable pipeline has four gates, and the order is not decorative:
| Gate | What runs | Fails when | Why this order |
|---|---|---|---|
| 1 | Schema and lint on every rule file | Required fields missing, malformed YAML | Cheapest check first; catches most PR mistakes in seconds |
| 2 | Conversion succeeds for every configured backend | A construct is unsupported on a target platform | No point testing logic that cannot compile for production |
| 3 | Rule fires against a stored true-positive sample | The detection does not detect | This is ADS "Validation" made executable |
| 4 | Rule does not fire against a stored benign sample | The detection is noisy by construction | Catches the false-positive flood before an analyst absorbs it |
Run gate 4 before gate 3 and you will pass rules that fire on nothing at all — a rule that never matches anything trivially satisfies "does not fire on benign traffic." Gate 3 must come first so that gate 4 is testing a detection that actually works, not an empty query. Skip gate 3 entirely and you ship detections whose only evidence of function is that the author believes in them.
Every rule needs an owner in the file itself and an entry in a review queue. A detection with no owner is a future false-positive storm with no one to answer the page.
Actionable takeaway: Put your detections in a Git repository this month, even if the repository initially contains exported saved-searches and nothing else. Add the ADS Blind Spots and Validation sections to the ten highest-volume detections first — those are the ones costing analyst hours right now.
An ATT&CK heat map where everything is green is almost always a lie, and it is a lie told in good faith. Three separate mechanisms produce it.
A mapped technique is not a validated detection, and a validated detection is not coverage. Techniques and sub-techniques have many procedural implementations. Covering one procedure does not cover the technique, and an adversary can obfuscate or use a variant nobody has documented. A rule tagged T1078 colors a cell green. Whether it fires on the specific implementation your adversary uses is an entirely separate question that the color does not answer.
Visibility and detection are different problems with different budgets. DeTT&CT exists to score data-source quality and derive technique visibility before any detection logic is layered on top (NVISO Labs, measuring coverage with DeTT&CT). A gap on a technique for which you collect no telemetry is not a detection-engineering problem — it is an ingest and budget problem, and conflating the two is how teams burn a quarter writing rules that can never fire.
Coverage models decay silently. Logging changes, platform migrations, a new SaaS tenant, an identity reconfiguration — each invalidates a map that was accurate six months ago, and none of them generate a notification. There is a concrete, dated example sitting in your repository right now: ATT&CK v19 split Defense Evasion into TA0005 Stealth and TA0112 Defense Impairment, current since 28 April 2026 (ATT&CK versions). Every coverage map, SIEM dashboard and purple-team report built on v18 or earlier now has a stale tactic axis. Version-pin your ATT&CK-derived content and re-baseline deliberately rather than tracking latest.
For each prioritized technique, publish three separate values:
| Value | Question it answers | Evidence |
|---|---|---|
| Telemetry | Do we collect the data at sufficient quality? | DeTT&CT visibility score, data-source last-seen |
| Logic | Does a rule exist and is it enabled in production? | Rule ID in the detection repository, enabled state |
| Validated | Has it fired on a representative true positive? | Date of the last successful validation run |
A technique green on all three is covered. Anything else is a named gap with a named owner and a cost. That last part is what makes the model survive contact with leadership.
Actionable takeaway: Replace every coverage percentage in your reporting with the telemetry / logic / validated triple, and re-baseline your ATT&CK mapping against v19 before your next quarterly review. If a technique has been green for a year without a validation run, treat it as red until proven otherwise.
Threat intelligence earns its budget when it modifies a detection, a block list or an investigation — and not otherwise. ISO/IEC 27001:2022 made this a control in its own right, A.5.7 Threat intelligence, and it is one of the eleven controls new in the 2022 edition, so it is a frequent finding in a 2013-to-2022 gap analysis.
CISA's preparation checklist states the workflow at the right level of abstraction:
Rehman's MindMap places "Integrate threat intelligence platform (TIP)" and "Partnerships with ISACs" under Threat Detection for the same reason (rafeeqrehman.com): intelligence that does not reach the detection layer through a pipeline reaches it through someone remembering, which is not a control.
The failure mode is subscribing to feeds faster than you can operationalize them, and then measuring success in indicators ingested. Three structural rules keep it honest.
Prefer behavior to atoms. Atomic indicators — IPs, domains, hashes — have short useful lives and cheap replacement costs for the adversary. Behavioral indicators and TTPs are expensive for the attacker to change. When the hand-off between access broker and ransomware operator is 22 seconds, an indicator that arrives in tomorrow's feed refresh is documentation, not defense.
Know your ingestion lag before you trust a negative result. Google Workspace OAuth Token log events carry a documented lag of a couple of hours, while admin and login events are near real time (Workspace data retention and lag times). A consent-grant sweep run in the first fifteen minutes of an incident will return clean and be wrong. Write the lag into the playbook step, or the step lies to the responder.
Every new indicator triggers a retro-hunt, not just a block. This is the operational reason retention exists. When an advisory lands, the question is not only "is this blocked going forward" but "was this present in the last N days" — and N is whatever you funded in section 1. CISA's vulnerability playbook builds the same two-question discipline into KEV response: does the vulnerable software exist here, and was it already exploited here (CISA Federal Playbooks). Chapter 10 owns that program; the retro-hunt capability it depends on is yours.
Govern feeds in a table: source, format, refresh interval, what it is allowed to change automatically (block, alert, enrich only), owner, and review date. A feed that only ever enriches is fine — say so, and stop counting it as a detection.
Actionable takeaway: For each intelligence feed, write down the one artefact it is permitted to modify — a block list, a detection rule, or an enrichment field — and delete any feed that modifies nothing. Then confirm your SIEM can retro-hunt a new indicator across your full retention window in a single query, because that is the capability you are actually buying.
Detection produces alerts. Alerts produce work. Work, unbounded, produces attrition — and attrition produces missed detections, which is how this loop eats itself.
CISA's playbooks carry an explicit "When to use this playbook" box before any procedure (CISA Federal Playbooks). The OASIS CACAO playbook standard formalises the same idea in machine-readable metadata (CACAO Security Playbooks v2.0). Chapter 2 owns the metadata specification. What matters at the detection layer is that every playbook has a stated, checkable entry condition and every high-severity detection names the playbook it opens.
Without that mapping, the triage decision is made from scratch, by a tired person, at the worst possible hour. NIST SP 800-61r3 is direct about the underlying constraint: "Because of resource limitations, incidents should not be handled on a first-come, first-served basis" (NIST SP 800-61r3). Prioritization is a design decision you make in daylight, not a judgement call you make at 03:00.
| Detection class | Entry criterion (checkable) | Default severity | Page? |
|---|---|---|---|
| Confirmed EDR detection on a server in a critical system | Alert on an asset tagged critical, status not auto-remediated | SEV-2 | Yes, immediately |
| Impossible-travel or token replay on a privileged identity | Sign-in from two geographies inside physical travel time, account holds a privileged role | SEV-2 | Yes, immediately |
| New OAuth consent grant with mail or file read scopes | Grant created, scopes intersect the high-risk list, publisher unverified | SEV-3 | Business hours unless the identity is privileged |
| Log source in priority tier 1-3 silent beyond threshold | Event rate below floor for two consecutive intervals | SEV-3 | Business hours; SEV-2 if two sources at once |
| Endpoint detection on a single standard workstation, auto-remediated | Alert resolved by the agent, no lateral indicators | SEV-4 | No — queue |
Severity definitions and the escalation-versus-elevation distinction belong to Chapter 13; use its schema, do not invent a parallel one. The rule that matters here is the one PagerDuty states and every mature team eventually learns the hard way: if you are unsure which level it is, treat it as the higher one, and reassess at the post-incident review rather than in the moment (PagerDuty severity levels).
The defensible peer-reviewed anchor is Tariq, Baruwal Chhetri, Nepal and Paris, "Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities," ACM Computing Surveys 57(9), Article 224, April 2025, which reviews alert-fatigue mitigation through an automation / augmentation / collaboration lens and notes cited industry studies reporting false-positive rates as high as 99% (ACM Digital Library).
The widely circulated figures — a specific percentage of alerts ignored, a specific percentage of analysts reporting burnout — come from vendor surveys rather than primary research. Do not quote them. You do not need them: the mechanism is enough, and you can measure your own false-positive rate this week.
The fatigue research makes the consequence precise. Harrison and Horne's review found that simple, well-practiced, rule-based tasks are relatively robust to short-term sleep deprivation — people mobilize compensatory effort — but that sleep deprivation still impairs decision-making involving "the unexpected, innovation, revising plans, competing distraction, and effective communication" (Harrison & Horne, 2000). Read that against a SOC shift: a tired analyst can still run a checklist. What degrades first is noticing that the situation has changed — which is precisely what a novel intrusion requires.
That is the empirical case for writing detections with documented false positives and pre-decided responses. You are converting judgement into rule-following, because rule-following is the cognitive mode that survives hour eleven.
Three operating rules follow:
On the on-call itself, the NCSC has the only government guidance dedicated to responder welfare, and its recommendations are operational rather than sentimental: embed practical stress-reducers such as deputy arrangements and out-of-hours coverage into the plan, build a culture where staff can say they are overwhelmed, plan internal communications, and practice (NCSC — putting staff welfare at the heart of incident response). A rota with no named deputy is a single point of failure wearing a lanyard.
Actionable takeaway: Map every detection at SEV-3 or above to a named playbook and a checkable entry criterion, and start logging false positives as defects against the detection's owner this week. If a single detection generates more than a quarter of your alert volume, fixing it is a higher-value week's work than writing anything new.
Your coverage map tells you what you think you detect. There are exactly three honest ways to find out what you actually detect, and all of them involve someone deliberately doing the thing.
| Method | What it finds | What it misses | Cost |
|---|---|---|---|
| Atomic / unit-level validation (Atomic Red Team, ADS Validation section) | Whether an individual rule fires on a representative procedure | Chained behavior, environmental variation, response quality | Low — engineer time, automatable in CI |
| Purple teaming / adversary emulation | Whether a full attack chain is detected, and whether the response actions in the playbook actually work | Techniques nobody chose to emulate | Medium — coordinated exercise, days not weeks |
| Full red team | Realistic end-to-end failure including the human layer | Systematic coverage; a red team optimises for success, not breadth | High |
MITRE's Center for Threat-Informed Defense publishes an Adversary Emulation Library with both full emulation plans (initial access through exfiltration) and micro emulation plans, modeled on real actors' documented behavior (CTID Adversary Emulation Library). The Purple Team Exercise Framework is the open methodology for running collaborative intelligence-plus-red-plus-blue exercises (PTEF). Chapter 18 owns exercise design and scoring; what belongs here is the detection outcome — every emulated technique ends the day marked detected / detected but not alerted / not detected, and every entry in the second two columns becomes a work item with an owner.
CISA builds emulation into post-incident activity with a caveat worth repeating verbatim in your own procedure: adversary emulation "should be closely coordinated with a blue team to ensure that they are not mistaken for true adversary activity" (CISA Federal Playbooks). There is a practical corollary if you run Microsoft Defender for Endpoint: automatic attack disruption can isolate a device on its own, and it has a separate exclusion mechanism from selective-isolation exclusions (Microsoft — take response actions on a device). Agree a validation-exercise exclusion list before the exercise, or your first purple team will contain half a department and the second one will never be approved.
Deception. CISA lists it as a preparation activity: "establish active defense mechanisms (i.e., honeypots, honeynets, honeytokens, fake accounts, etc.) to create tripwires to detect adversary intrusions" (CISA Federal Playbooks), and Rehman's MindMap carries "deception technologies for breach detection" under Threat Detection (rafeeqrehman.com).
Most of the value needs no product. A dormant privileged-looking account that no legitimate process ever authenticates as. A fake AWS access key pair sitting in a plausible file on a file share. A canary document in the finance folder. These generate approximately zero false positives, because there is no benign reason to touch them — which makes them the highest signal-to-noise detections you will ever deploy, and they cost an afternoon. If you are a small organization with no detection engineering capacity at all, do this before you do anything else in this chapter beyond turning on logging.
Actionable takeaway: Run one micro-emulation against your three highest-priority ATT&CK techniques this quarter and record the result as detected / alerted-only / missed for each — then plant at least three honeytokens across identity, cloud and file storage. Every gap the emulation finds gets an owner and a date, or the exercise was theatre.
Four metrics, precisely defined, because the definitions are where most reporting goes wrong:
| Metric | Definition | How it is computed | The honesty problem |
|---|---|---|---|
| MTTD | Threat onset to detection | detection_timestamp − first_adversary_activity_timestamp, averaged | The second timestamp is only knowable after investigation — MTTD is retrospective and cannot be computed live |
| MTTC | Detection to the point the adversary can no longer act | Sessions revoked, host isolated, credential dead | Tracks damage avoided most closely; the one worth optimizing |
| MTTR | Detection through containment, eradication and recovery | Usually a rolling 30-day window | Improves when you close tickets faster, which is not the same as being safer |
| Dwell time | Total period the adversary was present undetected | Per intrusion, established retrospectively | Related to but not identical to MTTD, which averages over alerts you investigated |
Sources: Prophet Security, Crogl.
Three properties of MTTD that you must state out loud whenever you report it, or you are reporting a number that flatters you:
MTTD is an average over the alerts you investigated — a minority of all activity in the enterprise. It says nothing whatever about what you never detected. A falling MTTD with rising false negatives is a worse SOC that looks better on a slide.
MTTD caps everything downstream. Containment cannot begin before detection. A fast MTTC on a threat you detected late is a fast clock on a fire that has been burning for a week.
MTTD needs a companion measure, and the right one is the internal detection rate — the percentage of incidents you found yourself versus those reported to you by a customer, a partner, law enforcement or the adversary. Mandiant's benchmark gives you the industry comparison and the argument: 52% detected internally in 2025, up from 43%, and a dwell-time split of 26 days external versus 10 days internal (M-Trends 2026). That single ratio is the most defensible justification for detection investment available to you, because it converts a technical capability directly into days of adversary access.
Rule of thumb for what goes where: if a number can go the right way while security gets worse, it belongs on the SOC dashboard with context, not on the board slide alone. MTTR is the classic offender. Chapter 16 owns board reporting and the metrics catalog; Appendix E carries the full definitions. What this chapter owes that chapter is instrumentation that does not lie — timestamps recorded in UTC at the moment of the event, a first-adversary-activity timestamp set during the post-incident review rather than guessed, and detection source recorded on every incident as internal or external.
Actionable takeaway: Add one mandatory field to your incident record — detection source: internal or external — and report the ratio quarterly alongside MTTD. It costs a dropdown and it is the only detection metric that cannot be gamed by closing tickets faster.
Detection is the least glamorous half of security and the half that decides how the rest of the book plays out. Every playbook in Chapter 14 begins with a trigger, and a trigger is a detection that fired. Every containment clock starts when someone notices. Every regulator's first question is when you knew, and the honest answer is written in logs you either kept or did not.
You will not get an alert titled "advanced persistent threat detected." You will get a silent log source, a strange consent grant, a service account authenticating from a country you do not operate in, and a helpdesk ticket about a password reset nobody requested. Build the pipes, write the rules down, test that they fire, and count the ones that do not.
Log everything that matters, keep it longer than they can hide, and check the cameras are still recording.
[IG1] [DE.CM] [CIS 8] [A.8.15][IG1] [DE.CM] [CIS 8] [A.8.15][IG1] [DE.CM] [CIS 8][IG1] [DE.CM] [CIS 8][IG2] [DE.CM] [PR.DS] [A.8.15][IG2] [PR.DS] [A.5.28][IG2] [DE.CM] [DE.AE][IG2] [PR.IR] [CIS 13][IG2] [GV.RR] [ID.AM][IG2] [DE.CM] [ID.IM][IG3] [DE.CM] [ID.IM][IG3] [DE.CM] [RS.AN][IG2] [DE.CM] [ID.IM][IG2] [DE.CM][IG2] [ID.RA] [DE.CM][IG2] [ID.RA] [A.5.7][IG2] [DE.AE] [RS.AN] [A.5.7][IG3] [DE.AE][IG1] [DE.AE] [RS.MA] [CIS 17][IG2] [DE.AE] [ID.IM][IG2] [DE.CM] [ID.IM][IG1] [GV.RR] [RS.MA][IG1] [DE.CM] [DE.AE][IG2] [ID.IM] [DE.CM] [CIS 18][IG2] [ID.IM] [GV.OV]