#How to Use This Book

Three ways to read a field manual, what the control codes mean, and an honest account of where everything in here came from.

Who needs this: everyone, once | Read time: 8 min | Maps to: —

There are three reasons someone opens a book like this, and they want completely different things.

You are building a program. Start at Chapter 1 for the shape of the 2026 problem, then Chapter 2 for how a playbook is actually built, then work through Part II in whatever order matches your risk. Finish with Chapter 20, which sequences the whole thing into a first 180 days. Use the master checklist in Appendix A as your backlog — it is assembled automatically from every chapter, so it cannot drift out of sync with the text.

Something is happening right now. Go straight to Chapter 14, find the playbook that matches, and run it. Chapter 13 gives you the roles and severity vocabulary the playbooks assume, and Chapter 15 tells you which regulatory clocks just started. Everything else can wait until Thursday. If you are reading this during an incident and you have not yet named an Incident Commander, do that before you read another paragraph.

You have to prove coverage. Appendix A is the master checklist with framework tags. Chapter 16 covers framework selection and the crosswalk. Chapter 3 gives you the Coverage Model — one page of everything you are accountable for, wired to those same controls — which works better in a board meeting than any risk register I have ever seen presented.

#How the controls are coded

Every chapter ends with a checklist. Each item carries a domain code and a number — IAM-04, RES-11, PB-RANSOM — that stays stable for the life of the book, so you can reference it in a ticket, an audit response, or an exercise report without ambiguity.

Each control also carries an implementation tier, borrowed from the CIS Implementation Group model:

Work down the tiers, not across the chapters. An organization with every IG1 control implemented is in materially better shape than one that has done half of Chapter 4 to IG3 and never touched backups. The most common way a security program fails is not that it did the hard things badly — it is that it did the hard things while the easy things sat undone.

Where a control could be verified against a published framework, it also carries a framework tag — a NIST CSF 2.0 category like PR.AA-01, a CIS Control number, or an ISO/IEC 27001 Annex A reference. Only tags that could be confirmed against the source are present. An untagged control is not a lesser control; it means the mapping was not verified, and I would rather leave it blank than tell you something an auditor will contradict.

#Where everything here came from

A security manual that cannot tell you where its claims come from is a blog post with delusions of grandeur. So, plainly:

Every regulatory deadline, framework version, tool command, and threat statistic in this book was checked against a primary or authoritative source, and each chapter ends with the URLs. Where a claim could not be confirmed — and there are several, because 2026 has a lot of rules in motion — it is marked with a Verify callout rather than asserted. Where reporting is directionally well-attested but lacks a primary source, the text says so. Where two sources disagree, the disagreement is described instead of resolved by picking a favourite.

This matters most in three places. CIRCIA's final rule timing has moved more than once and sources conflict; Chapter 15 gives you the status rather than a date to plan around. Vendor-published statistics about alert fatigue and analyst burnout are widely quoted and mostly unsourced; Chapter 9 uses the peer-reviewed anchor and skips the marketing numbers. Command syntax in containment playbooks is reproduced as the vendor documents it, and where exact syntax could not be confirmed the action is described in words instead. A wrong command in a containment procedure is not a typo; it is an outage, so I would rather be vague than confidently wrong.

#Attribution and notices

This book stands on other people's work, and says so. It also has work of its own, and this is where the line between them is drawn.

What is ours. The Coverage Model in Chapter 3 — six Functions, 29 domains, 145 capabilities — is original to this book, © 2026 Intelligent Automation, LLC, along with the 20 chapters, the 14 scenario playbooks, and the 464 controls in Appendix A that the model is wired to. Its spine is the six NIST CSF 2.0 Functions, which NIST publishes freely and intends to be used exactly this way; the domains, the capability decomposition, the control set and the mapping between them are ours. Use it in your own program. If you republish it, credit it.

The CISO MindMap is a separate and earlier artefact, and it is the creation of Rafeeq Rehman, who has built and updated it annually since 2012. The 2026 edition was published on 11 April 2026 and is © 2012–2026 Rafeeq Rehman. It is not the basis of our model and our model is not a version of it — they are organized differently and answer different questions. Chapter 3 discusses his map on its merits and includes a navigable reconstruction of its structure, kept deliberately as a cross-check: a second opinion against which to test our own scope, on the principle that a branch of his map we have no home for is a finding against us. That reconstruction is a derivative reference for study and gap analysis. It is not the original artefact, it is not endorsed by Rehman, it does not replace it, and the color coding by NIST CSF Function on it is this book's editorial addition, not part of his design. Download the real thing — a single beautifully dense page — from rafeeqrehman.com, and put it on a wall.

CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (November 2021, published under Executive Order 14028 §6, marked TLP:CLEAR) is the backbone of Chapters 13 and 10. It is a US Government work in the public domain. Chapters 13 and 10 adapt its process for organizations outside the federal civilian executive branch. CISA scoped the document to FCEB agencies and noted only that future iterations may prove useful to organizations outside it; the adaptation here is this book's, not CISA's. Where this book departs from CISA's model, it says so and says why.

Framework and standards references are the property of their respective bodies: the NIST Cybersecurity Framework, SP 800-61, SP 800-53, SP 800-207 and the AI Risk Management Framework (NIST, US Department of Commerce); the CIS Critical Security Controls and CIS Benchmarks (Center for Internet Security); ISO/IEC 27001, 27002, 27035, 22301 and 42001 (ISO/IEC — the standards themselves are copyrighted and must be purchased, and this book paraphrases structure rather than reproducing text); MITRE ATT&CK, D3FEND and ATLAS (© The MITRE Corporation); FAIR and FAIR-CAM (the FAIR Institute); the Cloud Controls Matrix (Cloud Security Alliance); OWASP project material (the OWASP Foundation); SOC 2 Trust Services Criteria (AICPA); PCI DSS (PCI Security Standards Council); and HITRUST CSF (HITRUST Alliance). All trademarks belong to their owners. Naming a framework here is neither an endorsement by its body nor a claim of certification or compliance.

Product and vendor names — AWS, Microsoft, Google, and every security tool named in these pages — appear because a responder needs to know which console to open, not because anything here is a recommendation, a review, or a commercial relationship. Commands and capabilities are cited to vendor documentation. Vendors change their products; verify before you rely on a command in production.

Incident case studies are drawn from published post-incident reviews, regulatory findings, government reports, and sworn testimony — the British Library's cyber incident review, the US Cyber Safety Review Board, GAO reports, and Congressional testimony among them. They are cited so you can read the primary document. They appear here to be learned from, not to be laughed at. Every organization in these pages was doing its best with what it had, which is exactly what makes their lessons worth your attention.

Reference to a 2015 book. Crafting the InfoSec Playbook by Jeff Bollinger, Brandon Enright and Matthew Valites (O'Reilly, 2015) is a genuinely good book and remains worth reading. This is not a second edition of it, is not affiliated with it, and its authors had no part in this. The overlap is the subject matter and the word "playbook."

Author. Written by Daniel Ramos, CTO, Intelligent Automation, LLC — publisher of Cyber Shield Weekly. Opinions here are his and not those of any client, employer, vendor, or standards body.

How to use this material. Localize it. Every playbook in Part III is a starting point that expects you to fill in your own tool names, contacts, thresholds and authorities. An unlocalized playbook fails at 03:00, which is the only time it matters.

Read it in whatever order your week demands, keep a pen near the checklists, and start with Appendix A if you are the sort of person who reads the last page first.

#Chapter 1 — Why 2026 Broke the Old Playbook

What actually changed between 2024 and 2026, why the playbook you already have will fail against it, and how to read the rest of this book.

Who needs this: Everyone — CISO, Incident Commander, SOC lead, IT director, and the executive who signs the budget | Read time: 18 min | Maps to: CSF 2.0 GOVERN, IDENTIFY (GV.OC, GV.RM, ID.RA)

Hello, cyber warriors. Before we start, a story with no malware in it.

Between 8 and 17 August 2025, an actor tracked as UNC6395 spent ten days quietly exporting records from more than 700 organizations. Cloudflare. Google. PagerDuty. Palo Alto Networks. Proofpoint. Tanium. Zscaler. Not one of them had a vulnerability to patch. Nobody clicked anything. No endpoint agent lit up, because there was nothing on any endpoint to light it up. The attackers had reached Salesloft's GitHub environment months earlier, pivoted into the AWS environment behind the Drift chatbot, and stolen the OAuth refresh tokens that customers had themselves issued to Drift — standing, password-proof, MFA-immune grants of access to those customers' Salesforce, Google Workspace and in some cases Slack data (AppOmni; Cloud Security Alliance).

Then came the part that should keep you up at night. The most valuable thing stolen was not CRM data. It was the API keys, Snowflake tokens, cloud credentials and passwords that customers had pasted into the body of support tickets over the years. A support queue turned out to be a credential vault with no lock on it.

Now open whatever incident response documentation you have and find the step that handles this. Not "contain the threat" — the actual step. There is no host to isolate, no password to reset, no patch to deploy, no malicious binary to submit to the sandbox. The correct first move is to enumerate every OAuth grant in your tenant, revoke the refresh tokens, and go read your own support tickets looking for secrets you wrote down years ago. If your playbook does not have that branch, it is not a slightly outdated playbook. It is a playbook for a different decade.

That is the argument of this chapter. Not that the threat landscape got worse — it always gets worse, that is not news and it does not help you. The argument is narrower and more useful: the specific assumptions that older playbooks were built on have been individually falsified, and you can name them one at a time.

#The clock broke first

Every playbook written before 2025 assumes you have time to think. You do not.

Mandiant's investigations now put the median hand-off from an initial-access broker to the ransomware operator who buys that access at 22 seconds, down from more than eight hours in 2022. Brokers pre-stage the secondary malware and tunnels during the initial infection, so the operator inherits a finished foothold rather than building one (M-Trends 2026). That window — the one where you noticed a commodity infection and had an afternoon to clean it up before anything serious happened — is gone. It was never a plan, but a lot of us were quietly relying on it.

CrowdStrike measured average eCrime breakout time at 29 minutes, 65% faster than 2024, with the fastest observed at 27 seconds (CrowdStrike 2026 Global Threat Report). Sophos found 88% of ransomware encryption events happened outside business hours (Help Net Security on Sophos), which is not a coincidence and not bad luck — it is target selection. Attackers know when your on-call rotation is one tired person with a phone.

Meanwhile the aggregate dwell-time number is a trap. The global median rose to 14 days from 11, which reads like defense getting worse. Split it and the story inverts: dwell time for internally-detected intrusions improved to 9 days, while externally-notified dwell jumped to 25 days, dragged up by espionage cases and DPRK IT-worker fraud. Internal detection accounted for 52% of activity, up from 43% (M-Trends 2026). We are getting better at finding what we are looking for and no better at all at finding what we are not. Espionage cases sit at a 122-day median.

Actionable takeaway: stop measuring mean time to respond as a single number. Split your metric into internally-detected and externally-notified, and report both to the board every quarter. If the second number is larger than the first — and it will be — that gap is your actual detection debt, and it is the number Chapter 9 exists to close.

#The front door moved to identity

Here is the change that reshapes more playbook steps than any other.

Sophos found 79% of ransomware attacks began with an identity-based approach, and 67% of victims confirmed the ransomware incident overlapped with an identity attack. Ninety-seven percent of those organizations had some MFA — just not consistently across VPNs, firewalls and legacy applications (Sophos State of Ransomware 2026). CrowdStrike reports 82% of its detections were malware-free (CrowdStrike). If your triage process starts with "what did the EDR flag," you are searching a room the adversary left years ago.

Four techniques are worth naming, because each breaks a different assumption:

• Adversary-in-the-middle phishing kits — Tycoon 2FA, Evilginx2, Modlishka, Muraena — sit between the victim's browser and the real identity provider and capture the session token after the victim completes genuine MFA. The MFA is not bypassed. It is rendered irrelevant. Infrastructure rotates on 24-to-72-hour domain lifetimes, so blocklists lose structurally (Group-IB).
• Help-desk impersonation. CISA's Scattered Spider advisory documents actors researching employees on business and social platforms, then calling the IT service desk posing as them to obtain password resets and MFA token transfers to attacker-controlled devices, sometimes splitting the request across separate contacts to evade detection (CISA AA23-320A). Your service desk is now a detection surface and a containment target.
• OAuth consent abuse. The FBI warned in September 2026 of an active campaign in which actors register malicious apps with legitimate providers and walk targets through a genuine Microsoft or Google consent screen. The result is persistent mail and file access that a password change does not revoke (Help Net Security on FBI IC3 PSA260901).
• Non-human identity. The Sysdig and LiteLLM cases below were pure machine-credential events — a Kubernetes service-account token and a PyPI publishing token, replayed with no human credential anywhere in the chain.

One honest caveat, because you will be asked about it. Verizon's 2026 DBIR reports the opposite headline: vulnerability exploitation at 31% overtook credential abuse at 13% as the top initial vector, for the first time in nineteen years (SecurityWeek). Both findings are correct for their populations. DBIR's dataset is breach-wide and heavily weighted by mass edge-device exploitation events; Sophos, Coveware and Mandiant are looking at ransomware-specific incident response. Translation for your program: exploitation gets you through the perimeter, identity gets you through the company. You need both branches, and Chapters 4 and 10 own them.

Actionable takeaway: rewrite the first trigger in your ransomware playbook. It should not be "malware detected." It should be "an identity event we cannot explain" — a help-desk-initiated MFA re-enrolment, an impossible-travel token use, a new OAuth grant, or a hit on an infostealer credential dump. And your containment step is revoke sessions and tokens first, reset the password second. Reversing that order leaves a valid token in the attacker's hands for the remainder of its lifetime.

#Extortion stopped needing encryption

Double extortion is the floor now, not the differentiator. The live variable is whether encryption happens at all — and the economics have gone strange.

Coveware's Q2 2026 caseload shows the payment rate for exfiltration-only extortion collapsed to 15%, with the overall payment rate at a record low (Coveware by Veeam). DBIR puts it at 69% of ransomware victims not paying (Help Net Security). Sophos found 48% of encrypted victims paid, with the median demand down 65% over two years to $698K, and — the number that should drive your budget — 66% of encrypted-data cases recovered from backups, up 12 points (Sophos).

That last figure explains the single most important shift in adversary behavior. Mandiant's framing is the sharpest available: the move from data theft to recovery denial. Operators now deliberately target backup infrastructure, identity services, virtualization management planes, AD CS certificate templates and hypervisor datastores. They are attacking your ability to recover, not only your ability to operate (M-Trends 2026).

Read that as a compliment and a warning. Backups started working, so backups became the target.

One number to handle carefully. Coveware's Q2 2026 average payment was $1,880,612, up 176% quarter over quarter, while the median fell 50% to $150,000. The average is distorted by a small number of very large payments, principally a campaign against law firms extorting on exposure of privileged legal records. Do not use the average to set a reserve or an insurance limit (Coveware).

And note who is actually getting hit: 75.8% of Coveware's cases were mid-market, with 101-to-1,000-employee firms the largest single segment. If you have been telling yourself you are too small to be interesting, the data disagrees.

Actionable takeaway: add a recovery-denial pre-check to ransomware triage, executed before you start restoring. Verify the integrity of backup catalogs, the identity plane, hypervisor management and certificate services first. If any of the four is compromised, you are not in a restore scenario — you are in a clean-room rebuild, and Chapter 12 is the chapter you need tonight.

#AI arrived on both sides of the table, unevenly

I use AI tooling every day and I will still tell you that most of what you have read about AI attacks in the last year is marketing. Let us separate what has actually been observed from what is being sold.

What is confirmed. In November 2025 Anthropic disclosed GTG-1002, a campaign it assesses with high confidence to be Chinese state-sponsored, in which its own model was used agentically against roughly 30 targets — technology firms, financial institutions, chemical manufacturers, government agencies. The model performed 80–90% of the campaign, with humans intervening only at decision gates, after operators bypassed safeguards by role-playing as authorized penetration testers and decomposing the attack into individually innocuous tasks (Anthropic). In May 2026 Sysdig observed the second confirmed agentic intrusion, hands-on in a live cloud environment: after exploiting a notebook application, the agent enumerated container escape primitives on its own, mounted the Docker socket, read host credentials, and replayed a projected Kubernetes service-account token to dump the cluster secret store (Sysdig).

Note what that second one did not need: an exploit for the privilege escalation. The agent used only the access its runtime already carried.

On social engineering, the losses are real and named. Engineering firm Arup lost approximately US$25.6 million across 15 wire transfers in a single day after an employee's scepticism about a phishing email was overcome by a video conference in which every other participant was AI-generated (CNN). Three comparable attempts were stopped: WPP, where staff caught a voice clone of the CEO in a Teams meeting (OECD AI Incidents); Ferrari, where an executive challenged a CEO voice clone with a shared-secret question about a recently recommended book (AI Incident Database); and LastPass, where an employee flagged the anomalous channel rather than detecting the fake.

Every one of those three saves came from a human process check, not from detection technology. Not one. That is your control, and it costs nothing.

Vishing is now structurally significant rather than anecdotal: voice phishing was the #2 initial infection vector at 11% of Mandiant's 2025 investigations (M-Trends 2026). The FBI's IC3 recorded $20.877 billion in total 2025 losses across 1,008,597 complaints — the first year over a million — with BEC alone at $3.047 billion, and introduced "AI-related" as a formal crime descriptor for the first time, logging 22,000+ complaints and roughly $900 million in losses (FBI).

And now the counterweight, which belongs in your program's stated assumptions. Mandiant's own conclusion from more than 500,000 hours of 2025 incident response is that 2025 was not the year breaches directly resulted from AI, and that most intrusions still stem from human and systemic failures (M-Trends 2026). And VulnCheck found that of 1,061 vulnerabilities attributable to AI-assisted discovery, only 14 — 1.3% — have been confirmed exploited in the wild (VulnCheck). AI is inflating your patch queue far faster than it is inflating your actual risk.

Actionable takeaway: budget for AI in two places and no others this year. First, a verification procedure for any voice or video instruction that moves money or grants access — a call-back to a number from your own directory, plus a challenge phrase, for every payment or access request above a stated threshold. That is a policy change, not a purchase. Second, an inventory of the AI systems and agents already in your environment, because you cannot defend what you have not counted. Chapter 7 owns the rest; Chapter 14.9 owns the deepfake playbook.

#The edge became the front line, and patching became a containment step

Vulnerability exploitation reached 31% of breaches in DBIR 2026 (SecurityWeek), and exploits were the top initial infection vector in Mandiant's data for the sixth consecutive year at 32%.

Our remediation is going backwards while that happens. Across 13,000 polled organizations, only 26% of CISA KEV-listed vulnerabilities were fully remediated, down from 38%, and median patching time rose to 43 days from 32 (Help Net Security on DBIR 2026).

The speed on the other side is measurable. VulnCheck's first-half 2026 data shows 23.43% of KEV entries had evidence of exploitation on or before the day the CVE was published, and the median time from CVE publication to KEV listing fell from 120 days to 80 (VulnCheck). Nearly one in four times, the disclosure is the news that you are already late.

Concentration makes it worse. The UK NCSC handled 429 incidents in its 2024/25 reporting year, of which 204 were nationally significant — up from 89 the year before, with 18 rated highly significant. Three vulnerabilities alone drove 29 of them: Ivanti Connect Secure CVE-2025-0282, Fortinet FortiManager CVE-2024-47575, and Microsoft SharePoint CVE-2025-53770 (NCSC Annual Review 2025).

And here is the structural point that most vulnerability programs still get wrong. When CISA issued Emergency Directive ED 25-03 for the Cisco ASA campaign — CVE-2025-20333 and CVE-2025-20362, which chain to full unauthenticated device control — it did not simply require patching. Agencies had to collect and transmit memory images, because the actor had modified device ROM to persist across reboot and upgrade. CISA had to re-issue guidance two months later because "patched" devices remained compromised (CISA ED 25-03). The F5 directive, ED 26-01, followed the same shape after nation-state actors spent at least twelve months inside F5's own network exfiltrating BIG-IP source code and undisclosed vulnerability information (CISA).

Actionable takeaway: for internet-facing edge appliances, treat patching as a containment step and not a remediation step. Assume compromise on any KEV-listed edge device that was exposed, and follow the patch with credential rotation, configuration review and — where the vendor advisory supports it — memory capture. Cheap version for a small team: you may not be able to image a firewall, but you can rotate every credential and certificate that device held, review its config against a known-good copy, and check for added SSH keys and non-standard ports. That takes an afternoon and catches the persistence technique used by the Salt Typhoon campaign across 600+ organizations (CISA AA25-239A).

#Your vendor's incident is now your incident

Third-party involvement appeared in roughly 48% of breaches — an approximately 60% year-over-year increase — and only 23% of third-party organizations had fully remediated their MFA issues (SecurityWeek).

The developer supply chain in particular stopped being a theoretical concern. Shai-Hulud, first seen 15 September 2025, was the first true self-replicating worm in npm: it harvested secrets from CI/CD pipelines and cloud metadata endpoints and republished itself into packages under compromised maintainer accounts, prompting a CISA alert (CISA); its November successor reached 25,000+ malicious repositories (Microsoft Security). In March 2026 an actor backdoored a widely-used security-scanning GitHub Action, which LiteLLM's CI auto-installed, which stole LiteLLM's PyPI publishing tokens, which shipped malicious wheels to everyone downstream — a full transitive compromise across GitHub Actions, Docker Hub, npm, PyPI and OpenVSX in five days (Resecurity; LiteLLM). And the Nx "s1ngularity" attack of August 2025 was the first documented weaponization of developer AI agents as an attack tool: malicious package versions detected locally installed AI coding CLIs and invoked them with permission-bypassing flags to enumerate secrets across the filesystem, harvesting 2,349 credentials from 1,079 developer systems (The Hacker News; GitGuardian).

None of these had a customer-side vulnerability to patch. All of them required customer-side action.

Actionable takeaway: create a playbook trigger you almost certainly do not have — "a vendor has disclosed a breach" — whose first three steps are: enumerate every standing token, OAuth grant and API key that vendor holds; revoke and reissue them; then hunt in your own logs for that vendor's identity acting outside its normal pattern. Chapter 11 owns the program; Chapter 14.5 owns the playbook.

#The 2024–25 → 2026 delta

If you keep one page from this chapter, keep this one. The left column is not wrong; it is insufficient.

Actionable takeaway: print this table, take it to your next leadership meeting, and mark each row red, amber or green with evidence — not opinion. The red rows are your roadmap, and Chapter 20 sequences them.

#Why static playbooks fail

Now the uncomfortable part, and I want to be careful here. Every organization below published or testified to what went wrong, at real cost to themselves, so the rest of us could learn from it. That deserves respect, not commentary. These are the most valuable documents in our field.

The policy is universal; the enforcement never is. Change Healthcare's attackers used compromised credentials against a Citrix remote-access portal that did not have MFA enabled, despite company policy requiring MFA on all external-facing systems (Healthcare Dive). Colonial Pipeline's initial access was through "a legacy virtual private network profile that was not intended to be in use," on an account without MFA (Blount testimony). The British Library's published review states it plainly as lesson 3: MFA was in place for all end-user technologies, but not on certain supplier endpoints (British Library review). The shape repeats exactly: the exception is always at the seam with a third party or a legacy system, and a playbook cannot fix it. A preparation checklist that requires periodic enumeration of exceptions can.

The distribution list is a control, and it rots. GAO's Equifax report records that the Apache Struts vulnerability was not identified on the online dispute portal because the recipient list for the patch notice was out of date, so the notice never reached the people who would have installed it. A follow-up scan a week later did not detect it either. Separately, an expired digital certificate meant traffic was not being inspected throughout the breach (GAO-18-559). Two controls that were "in place" on paper and dead in practice.

Safety controls get quietly retired after operational pain. The Cyber Safety Review Board found that Microsoft had stopped its infrequent manual rotation of consumer signing keys in 2021 following a major cloud outage linked to the manual rotation process — a security control abandoned because it caused an incident. The Board concluded the resulting intrusion, which reached mailboxes at 22 organizations and 500+ individuals, "should never have happened" (CSRB report). Every organization has at least one control it silently stopped performing after it broke something. Find yours.

Small intrusions get closed too early. The British Library's lesson 4 is the one I quote most often: an in-depth security review should be commissioned after even the smallest signs of network intrusion, because it is relatively easy for an attacker to establish persistence and thereafter evade routine precautions (British Library review). Mandiant's data agrees from the other direction — "prior compromise" is now the #1 ransomware initial vector at 30%, doubled from 15% (M-Trends 2026). The intrusion you closed last quarter is a leading indicator.

Risk accepted in small pieces is still risk. British Library lesson 7: the Library's processes appropriately escalated out-of-appetite risks, but were less effective in modeling the amount of low-level risk being carried in aggregate. Fifty accepted exceptions do not add up to fifty small problems. Chapter 16 covers aggregation.

The common thread across all five is not incompetence. It is that a document approved in peacetime described a world that had drifted. Actionable takeaway: give every playbook a last_tested date in its header and a rule that an untested playbook reverts to Draft status. If your document control system cannot enforce that, put the playbooks in git where a CI check can. Chapter 2 shows you how; Chapter 18 shows you how to generate the test dates.

#The regulatory squeeze — orientation only

Chapter 15 owns the detail, every clock and every trigger. Here is the shape, so you know what you are walking into.

The change is not that deadlines got shorter. It is that there is no longer one deadline. A single ransomware incident at an EU-regulated financial firm with US operations and personal data in scope can simultaneously run DORA's 4-hour initial notification, NIS2's 24-hour early warning, GDPR's 72 hours, an SEC materiality determination on a four-business-day fuse, US state clocks with a 30-day floor, and — if a payment is made — a fresh 24-hour clock triggered by the business decision, not by the attack.

Five status points worth knowing today, 5 September 2026:

• SEC Item 1.05 remains in force. Four business days from the materiality determination, not from discovery. Rescission has been widely requested in comments on the Regulation S-K reform initiative, but it has not been proposed and not been adopted (SEC). Keep the machinery intact.
• GDPR stays at 72 hours. A Digital Omnibus proposal to move it to 96 hours is pending, not law (Art. 33 GDPR).
• NIS2 is not one obligation. Transposition is incomplete, and the Commission referred Ireland, Spain, France and the Netherlands to the CJEU on 8 July 2026. Thresholds, portals and registration duties differ by Member State (EC).
• DORA is live and enforced, applying since 17 January 2025, with the 4-hour / 72-hour / one-month structure fixed by delegated regulation (EUR-Lex).
• CIRCIA is still not final — the target has slipped repeatedly to September 2026, so CISA reporting remains voluntary. The statutory clocks are 72 hours for a covered incident and 24 hours for a ransom payment: short enough that you should build the capability now (CISA).

One more, six days away as I write, that gets missed because it does not look like a security regulation: the EU Cyber Resilience Act's Article 14 reporting obligations apply from 11 September 2026. If you manufacture a product with digital elements sold into the EU, an actively exploited vulnerability in your product starts a 24-hour clock — regardless of whether your own network was touched at all (European Commission).

Actionable takeaway: capture four separate timestamps for every incident — when you became aware, when you reasonably believed an incident occurred, when you determined it was material, and when any payment was disbursed. These diverge by days, and different regimes run from different ones. A single "incident start" field in your ticketing system cannot carry all four, and your contemporaneous log is the only evidence of when each state arose.

#How to read this book

Three reading paths. Pick the one that matches why you opened this.

Path 1 — Build a program. Read in order, Chapters 1 through 20, and treat Chapter 20 as the sequencing authority rather than doing the domains in the order they appear. Order matters more than coverage here: identity (Chapter 4) precedes detection (Chapter 9), because detections on a compromised identity plane produce confident nonsense; recovery (Chapter 12) precedes response tooling (Chapter 17), because automating a response you cannot recover from is an expensive way to be wrong faster.

Path 2 — Respond tonight. Go straight to Chapter 13 for incident command and severity, then to the specific scenario playbook in Chapter 14, then to Chapter 15 for the notification clocks. Read Chapter 15 in parallel with the technical response, not after it — the clocks do not wait for your forensics. If you have five minutes and an active incident, the sequence is: declare, name an Incident Commander, open the right playbook, start a written timeline.

Path 3 — Prove coverage. Start with Chapter 3 to map your program against the CISO MindMap, then Chapter 16 for framework crosswalks and board metrics, then Appendix A — the master checklist assembled from every chapter — as your evidence register.

The checklist codes. Every chapter ends with testable control statements carrying a domain code and number: LAND-01, IAM-07, RES-12. They are stable identifiers, so you can cite one in an audit response or a remediation ticket and it will still mean the same thing next year. Each is written so an auditor can mark it true or false.

The tiers. Each item carries [IG1], [IG2] or [IG3], using CIS Implementation Group semantics. IG1 is essential cyber hygiene — the minimum any organization needs, achievable without a dedicated security team, and where a small organization should finish everything before starting anything in IG2. IG2 assumes dedicated security staff. IG3 is for organizations facing targeted, sophisticated adversaries. The tiers are cumulative (CIS Implementation Groups). Where a control is expensive, I say what the cheap version is — because a control you cannot afford is not a control, it is a wish.

The checklist below is different from every other one in this book. It is not a control set; it is a triage tool. Each unchecked box points you at the chapter you most urgently need. Answer honestly — nobody is auditing this one, and lying to yourself here costs more than lying to an auditor.

Actionable takeaway: work the checklist below before you read another chapter, and write the result down with a date on it. Then read the chapters your unchecked boxes name, in the order they appear. Not the chapters that sound most interesting. The ones you failed.

Stay patched, stay paranoid, and remember: the attacker does not need to be sophisticated if your exception list is long enough.

#Chapter checklist

Readiness self-assessment. Each unchecked box names the chapter you need most. Work top to bottom — the order reflects what fails first.

• LAND-01An inventory of enterprise assets, software, cloud accounts and internet-facing services exists, is refreshed at a documented interval, and a named role owns it. If false, start at Chapter 6 and Chapter 10 — nothing else in this book works without it. [IG1] [ID.AM] [CIS 1] [CIS 2]
• LAND-02Phishing-resistant MFA (FIDO2/WebAuthn or PKI) is enforced for every account holding a privileged role, with a documented, time-bounded exception list reviewed at least quarterly. If false, read Chapter 4 first. [IG1] [PR.AA] [CIS 5] [CIS 6]
• LAND-03A written procedure exists for verifying the identity of anyone requesting a password reset or MFA re-enrolment through the IT service desk, using out-of-band verification. If false, read Chapter 4. [IG1] [PR.AA]
• LAND-04Identity containment is defined as session and token revocation followed by password reset, and the responder-facing runbook states that order and why. If false, read Chapter 4 and Chapter 14.4. [IG2] [RS.MI]
• LAND-05A restore from backup to a production-equivalent environment has been completed and timed within the last 12 months, and the measured restore time is recorded. If false, read Chapter 12 before anything else — this is the control that decides whether a ransomware incident is a bad week or an existential one. [IG1] [RC.RP] [CIS 11]
• LAND-06Backup integrity, identity services, hypervisor management and certificate services are verified as a named pre-check inside the ransomware playbook, before restoration begins. If false, read Chapter 12 and Chapter 14.1. [IG2] [RC.RP]
• LAND-07Every internet-facing edge appliance is inventoried with its vendor, version and management-interface exposure, and KEV-listed vulnerabilities in that inventory carry a tracked remediation SLA. If false, read Chapter 10 and Chapter 14.12. [IG1] [ID.AM] [CIS 7]
• LAND-08A complete inventory of OAuth grants, connected applications, service principals and CI publishing tokens exists, with an owner and an expiry for each. If false, read Chapter 4 and Chapter 11. [IG2] [PR.AA] [GV.SC]
• LAND-09A documented incident trigger exists for "a vendor has disclosed a breach," and its first steps are enumerate, revoke and hunt — not wait for the vendor's final report. If false, read Chapter 11 and Chapter 14.5. [IG2] [GV.SC] [CIS 15]
• LAND-10A verification procedure applies to any voice, video or messaging instruction that moves money or grants access, requiring call-back to a directory-sourced number plus a challenge the caller must answer. If false, read Chapter 14.2 and Chapter 14.9. [IG1] [PR.AT] [CIS 14]
• LAND-11An inventory of AI systems, models, agents and their tool permissions exists, and each entry names a human owner. If false, read Chapter 7. [IG2] [ID.AM]
• LAND-12Every incident record captures four distinct timestamps — awareness, reasonable belief an incident occurred, materiality determination, and any ransom disbursement — and the notification owner is a named role separate from the Incident Commander. If false, read Chapter 15. [IG2] [RS.CO]
• LAND-13Every playbook carries an owner, a version, a last_tested date and a status, and any playbook untested for more than 12 months is marked Draft rather than Active. If false, read Chapter 2 and Chapter 18. [IG2] [RS.MA] [CIS 17]
• LAND-14The incident response contact list, escalation ladder and out-of-band communication channel exist in printed form, held by every person with a response role, and were tested within the last 12 months. If false, read Chapter 13. [IG1] [RS.CO] [CIS 17]
• LAND-15Mean time to detect is reported separately for internally-detected and externally-notified incidents, and both figures go to the board. If false, read Chapter 9 and Chapter 16. [IG2] [DE.CM] [ID.IM]

#Sources

1. AppOmni — Drift breach, Salesforce, UNC6395: https://appomni.com/blog/drift-breach-salesforce-unc6395-saas-prevention/
2. Cloud Security Alliance — The Salesloft Drift OAuth supply chain attack: https://cloudsecurityalliance.org/blog/2025/09/25/the-salesloft-drift-oauth-supply-chain-attack-cross-industry-lessons-in-third-party-access-visibility
3. Mandiant / Google Cloud — M-Trends 2026: https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
4. CrowdStrike — 2026 Global Threat Report findings: https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
5. Sophos — State of Ransomware 2026: https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026
6. Help Net Security — Sophos identity-driven breaches report: https://www.helpnetsecurity.com/2026/02/27/sophos-identity-driven-breaches-report/
7. SecurityWeek — Verizon DBIR 2026: vulnerability exploitation overtakes credential theft: https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
8. Help Net Security — Verizon 2026 DBIR findings: https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
9. Coveware by Veeam — Cyber extortion payment trends, Q2 2026: https://www.veeam.com/blog/cyber-extortion-payment-trends-q2-2026.html
10. Group-IB — Tycoon 2FA: https://www.group-ib.com/masked-actors/tycoon2fa/
11. CISA — AA23-320A, Scattered Spider: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
12. Help Net Security — FBI warning on OAuth consent phishing (IC3 PSA260901): https://www.helpnetsecurity.com/2026/09/02/oauth-consent-phishing-fbi-warning/
13. Anthropic — Disrupting AI espionage (GTG-1002): https://www.anthropic.com/news/disrupting-AI-espionage
14. Sysdig — Agentic threat actor hits the orchestration plane: https://webflow.sysdig.com/blog/agentic-threat-actor-hits-the-orchestration-plane-ai-agent-driven-container-escape
15. CNN — Arup deepfake scam loss, Hong Kong: https://www.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
16. OECD AI Incidents — WPP deepfake attempt: https://oecd.ai/en/incidents/2024-05-10-e24d
17. AI Incident Database — Ferrari voice clone attempt: https://incidentdatabase.ai/cite/966/
18. FBI — Cryptocurrency and AI scams bilk Americans of billions (IC3 2025): https://www.fbi.gov/news/press-releases/cryptocurrency-and-ai-scams-bilk-americans-of-billions
19. VulnCheck — State of Exploitation, 1H-2026: https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
20. UK NCSC — Annual Review 2025, Incident Management: https://www.ncsc.gov.uk/collection/ncsc-annual-review-2025/chapter-01-cyber-threat-to-the-uk/incident-management
21. CISA — Emergency Directive ED 25-03, Cisco devices: https://www.cisa.gov/news-events/directives/ed-25-03-identify-and-mitigate-potential-compromise-cisco-devices
22. CISA — Emergency Directive on F5 devices: https://www.cisa.gov/news-events/news/cisa-issues-emergency-directive-address-critical-vulnerabilities-f5-devices
23. CISA — AA25-239A, Salt Typhoon joint advisory: https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a
24. CISA — Widespread supply chain compromise impacting npm ecosystem: https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
25. Microsoft Security — Shai-Hulud 2.0 guidance: https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/
26. Resecurity — The LiteLLM supply chain attack: https://www.resecurity.com/blog/article/the-litellm-supply-chain-attack-teampcp-sandclock-cicd-credential-harvesting-campaign-via-a-backdoored-trivy-github-action
27. LiteLLM — Security update, March 2026: https://docs.litellm.ai/blog/security-update-march-2026
28. The Hacker News — Malicious Nx packages in s1ngularity attack: https://thehackernews.com/2025/08/malicious-nx-packages-in-s1ngularity.html
29. GitGuardian — The Nx s1ngularity attack: inside the credential leak: https://blog.gitguardian.com/the-nx-s1ngularity-attack-inside-the-credential-leak/
30. Healthcare Dive — Change Healthcare compromised credentials, no MFA: https://www.healthcaredive.com/news/change-healthcare-compromised-credentials-no-mfa/714824/
31. Joseph Blount — Senate HSGAC testimony on Colonial Pipeline, 8 June 2021: https://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Testimony-Blount-2021-06-08.pdf
32. British Library — Learning Lessons from the Cyber-Attack: https://www.bl.uk/home/british-library-cyber-incident-review-8-march-2024.pdf/
33. GAO-18-559 — Actions taken by Equifax and federal agencies: https://www.gao.gov/assets/gao-18-559.pdf
34. Cyber Safety Review Board — Review of the Summer 2023 Microsoft Exchange Online Intrusion: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewOfTheSummer2023MEOIntrusion508.pdf
35. Jim Aldridge / Mandiant — Remediating Targeted-threat Intrusions, Black Hat USA 2012: https://media.blackhat.com/bh-us-12/Briefings/Aldridge/BH_US_12_Aldridge_Targeted_Intrustion_WP.pdf
36. CISA — Federal Government Cybersecurity Incident and Vulnerability Response Playbooks: https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
37. SEC — Press release 2023-139, cybersecurity disclosure rules: https://www.sec.gov/newsroom/press-releases/2023-139
38. GDPR Article 33: https://gdpr-info.eu/art-33-gdpr/
39. European Commission — Commission calls on 23 Member States to fully transpose NIS2: https://digital-strategy.ec.europa.eu/en/news/commission-calls-23-member-states-fully-transpose-nis2-directive
40. EUR-Lex — Commission Delegated Regulation (EU) 2025/301 (DORA reporting clocks): https://eur-lex.europa.eu/eli/reg_del/2025/301/oj
41. CISA — CIRCIA: https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing/cyber-incident-reporting-critical-infrastructure-act-2022-circia
42. European Commission — CRA reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
43. CIS — Implementation Groups: https://www.cisecurity.org/controls/implementation-groups

#Chapter 2 — Plan, Playbook, Runbook

How to write incident documentation that a tired person can execute at 03:00 without stopping to work out who is allowed to decide.

Who needs this: CISO, IR lead, playbook owners, SOC managers, anyone who has been handed "update the IR plan" | Read time: 18 min | Maps to: CSF 2.0 GOVERN, RESPOND (GV.RR, GV.PO, RS.MA, ID.IM) | CIS Control 17 | ISO 27001 A.5.24, A.5.26, A.5.27

Fellow defenders, let me start with the most expensive email that never arrived.

When Equifax was breached, the company had a process. A vulnerability notice went out. Patching happened across the estate. And the Apache Struts vulnerability on the online dispute portal did not get patched, because — in GAO's words — "the recipient list for the notice was out-of-date and, as a result, the notice was not received by the individuals who would have been responsible for installing the necessary patch." A scan a week later did not find it either. Separately, an expired digital certificate meant traffic went uninspected throughout the breach (GAO-18-559, pp.15–16). None of that is a missing document. Every one of those is a document that existed and was quietly wrong.

That is the actual failure mode of security documentation, and it is not the one people plan for. Teams worry that they have no playbook. The recurring finding in published post-incident reports is that they had one, it was approved, and a field inside it had rotted — a distribution list, a phone number, an authority that moved with a reorg, a runbook referencing a console that was decommissioned two migrations ago. The document was fine. The document was also fiction.

So this chapter is not about what to write. It is about how to build the thing so it stays true. The craft, stripped to one sentence: every structural convention below exists to remove a decision from the moment of crisis and move it into peacetime. Metadata, entry and exit criteria, pre-authorized action lists, severity keyed to business impact, named authorities with named deputies — none of it is bureaucracy. It is all the same move, made repeatedly, because the research on fatigue is unambiguous about which cognitive faculties leave the building first. Harrison and Horne found that well-practiced, rule-based tasks hold up surprisingly well under sleep deprivation; what degrades is handling the unexpected, innovating, revising plans, filtering distraction, and communicating effectively (Harrison & Horne, 2000). Read that list once more. It is a precise inventory of what a novel incident demands and what your responder will not have at hour eleven.

A playbook converts judgement into rule-following. That is the whole trick. Everything else is formatting.

#Three documents, three jobs

There is no single normative taxonomy across the standards bodies, but they converge on a ladder: policy → plan → playbook → runbook. Each rung answers a different question, changes at a different rate, and is approved by a different person. Collapse two rungs and you get a document that is neither approvable nor executable.

CISA defines an incident response plan as "a written document, formally approved by the senior leadership team, that helps your organization before, during, and after a confirmed or suspected security incident. Your IRP will clarify roles and responsibilities and will provide guidance on key activities" (CISA, Incident Response Plan Basics). Note what that definition does not promise: steps. NIST separates the artifacts the same way — the policy carries management commitment, scope, and "roles, responsibilities, and authorities, such as which roles have the authority to confiscate, disconnect, or shut down technology assets," while processes and procedures derived from it "explain how technical processes and other operating procedures should be performed" (NIST SP 800-61r3, §2.3).

NIST then says the useful part out loud: "Many organizations choose to create playbooks as part of documenting their procedures… Formatting procedures within a playbook instead of another format can improve their usability." And AWS draws the last line: "A runbook is the documented form of an organization's procedures for conducting a task or series of tasks," while playbooks "provide prescriptive guidance and steps to follow when a security event occurs" (AWS Security Incident Response Guide).

The most common structural error is collapsing plan and playbook into a sixty-page hybrid that tries to be executable. It fails twice: too operational for the board to meaningfully approve, too abstract for a responder to run. CISA models the separation in its own output — a short plan fact-sheet on one hand, an operational playbook document on the other (CISA Federal Playbooks).

The second most common is the opposite: inlining runbook commands into playbooks. Do it once and you feel efficient. Do it across fourteen playbooks and you have fourteen copies of the same PowerShell one-liner, of which eleven are stale within a year. RE&CT solves this by composing playbooks from a library of atomic, individually-owned response actions, structured deliberately like ATT&CK (RE&CT). That is the best idea in this space: fix "isolate a host" once and the fix propagates to every playbook referencing it.

You do not need fourteen playbooks to start. NCSC's guidance is to build detailed scenario documents — it calls them runbooks; in this book's vocabulary they are playbooks — for the top three to five highest-risk incident types only, covering initial response, containment, evidence preservation, and when to involve legal, HR and PR (NCSC). Three real ones beat fourteen aspirational ones, every time.

Actionable takeaway: Write one plan of no more than fifteen pages that a senior leader can actually read and sign, then move every step, command and decision out of it into playbooks and runbooks. If a page of your plan contains a command, it is in the wrong document — cut it out today and give it an owner.

#The header block: everything you must not have to ask

Open a playbook mid-incident and there are roughly a dozen things you need to know before step one, none of which are steps. Most home-grown playbooks answer three of them.

The most rigorous published schema is OASIS CACAO Security Playbooks v2.0, and even if you never write a line of machine-readable playbook, its property list is the best available checklist for what a header needs: id, name, description, playbook_types, created_by, created, modified, revoked, valid_from, valid_until, derived_from, related_to, priority, severity, impact, labels, external_references, markings, signatures, workflow, and workflow_exception (OASIS CACAO v2.0). Look at what CACAO makes explicit that hand-rolled playbooks almost always omit: a playbook that can expire (valid_until, revoked), a playbook that records its provenance (derived_from), and — the one I have never seen in a home-grown document — what to do when the playbook itself fails (workflow_exception).

Here is a filled-in header. Not a template with angle brackets; a real one, of the kind that should sit at the top of every scenario playbook in Chapter 14.

playbook:        Business Email Compromise and Payment Fraud
id / version:    PB-BEC / v3.2
status:          Active            # Active | Draft | Revoked
owner:           R. Okonkwo — Manager, Detection & Response
                 deputy: Manager, Service Desk
approver:        IR Lead
created:         2025-02-11
modified:        2026-06-30
last_exercised:  2026-05-14  (TTX-2026-02) — 2 gaps found, both closed
next_review_due: 2026-12-30       # CI fails the build after this date
tlp:             TLP:AMBER+STRICT
default_severity: SEV-2
  escalate_to_SEV-1_if: funds have left the account, OR the compromised
                        mailbox belongs to an officer with payment authority,
                        OR mail rules were created on more than five mailboxes
entry_criteria:  see "When to run this"
exit_criteria:   see "When this is closed"
roles:           IC / Ops Lead / Comms Lead / Scribe / Legal Liaison / Exec Sponsor
pre_authorised:  see table §4      # actions requiring no approval
approval_gated:  see table §4      # action → authoriser → out-of-hours reach
evidence:        see §6            # artefacts, order, retention, custody
comms_hooks:     internal / customer / bank / regulator / insurer / counsel
on_playbook_failure: If the identity provider is unavailable or itself suspect,
                     STOP. Switch to PB-IDP and notify the IC. Do not improvise
                     around the missing control plane.
references:      T1078 Valid Accounts; RB-014 revoke-sessions; RB-021
                 mailbox-rule-audit; contact card CC-02 (printed)

Five of those fields do more work than all the rest, and they are the five teams skip.

owner is a person, not a team alias. "SOC" cannot be paged, cannot be asked why a step is wrong, and cannot be held to a review date. A named person with a named deputy can — and when that person leaves, the vacancy becomes visible.

last_exercised is the honesty field. It is the difference between a playbook and a hypothesis. If it is blank, the playbook is Draft. Say so in status, and mean it.

tlp tells the responder at 03:00 whether they may paste this into a vendor's support ticket. That question comes up constantly and gets answered badly under pressure.

on_playbook_failure is CACAO's workflow_exception in plain English, and it separates a playbook from a wish. Every playbook depends on infrastructure. Write down what the responder does when that infrastructure is the compromised thing.

next_review_due is only real if something enforces it. A date nobody checks is decoration.

The full blank template — every field, with guidance notes — is in Appendix B. Do not retype it from this page; copy it from there.

Actionable takeaway: Add owner, last_exercised, next_review_due, status and on_playbook_failure to every playbook you already have, this week, before writing a single new one. If you cannot fill in last_exercised, set status: Draft and let the gap be visible.

#Entry and exit criteria: the two fields everyone skips

A playbook without entry criteria gets opened for the wrong things and then distrusted. A playbook without exit criteria never closes; it just stops having meetings.

CISA's federal playbook carries an explicit "when to use this playbook" box, and — more usefully — a do not use list. Use it for confirmed malicious activity with major-incident potential: lateral movement, credential access, data exfiltration, intrusions involving more than one user or system, compromised administrator accounts. Do not use it for information spills believed to result from unintentional behavior only, users clicking a phishing email where no compromise resulted, or commodity malware on a single machine (CISA Federal Playbooks).

That second list is the one to steal. A "when to use" section alone reads as an invitation; the "do not use" section is what stops your SEV-2 process being invoked for a quarantined attachment at 02:00 on a Sunday for the fourth time this month.

There is a maintenance benefit too. Once entry criteria are written as observable conditions — these alerts, in this combination — every activation that turns out not to meet them is a defect logged against the detection, not a shrug. The peer-reviewed work on alert fatigue describes the mechanism plainly: high volumes with very high false-positive rates desensitize analysts, degrading both detection effectiveness and analyst wellbeing (Tariq et al., ACM Computing Surveys 57(9), 2025). You cannot fix that inside the playbook. You can make every false activation generate a ticket against the thing that caused it.

Exit criteria are harder, because they are gates rather than vibes. CISA's are worth copying in shape. Containment is complete when there are no new signs of compromise — at which point you preserve evidence, adjust detection tooling and move on. Before eradication may begin, three things must be true: all means of persistent access are accounted for, adversary activity is sufficiently contained, and all evidence has been collected. Recovery is validated by enhanced vigilance plus, ideally, "an independent test or review of compromise/response-related activity."

And the loop-back rule, which turns a falsely linear checklist into an honest one: if new signs of compromise appear during containment, return to technical analysis and re-scope; if new adversary activity appears after eradication, contain it and go back to analysis until the true scope and initial infection vector are identified. Write that rule in explicitly, with an arrow back to a numbered step — or your responders will read the numbering as a promise that the incident only travels one way.

Actionable takeaway: Give every playbook a "do not use this playbook for" list and a gated exit condition phrased as an observable absence — "no new signs of compromise," not "we think we got it." Then add one line: if new indicators appear, return to step 4.

#Severity that keys off the business, not the alarm

Severity levels exist to allocate scarce attention. NIST says the quiet part out loud: "Because of resource limitations, incidents should not be handled on a first-come, first-served basis," and prioritization should follow "scope, likely impact, time-critical nature, and resource availability" (NIST SP 800-61r3, RS.MA-02/03).

The most common design mistake is scoring the technical alarm rather than the business consequence. A critical CVSS score on a system nobody uses is not a SEV-1. An adversary with valid credentials on a domain controller is, even though nothing has "broken" yet.

CISA's National Cyber Incident Scoring System is the best public model to borrow from, because it is deliberately multi-dimensional — a weighted mean across eight categories rather than one judgement call. Three of them carry most of the weight for a corporate schema:

• Functional impact — "a measure of the actual, ongoing impact to the organization."
• Information impact — "the type of information lost, compromised, or corrupted."
• Recoverability — "the scope of resources needed to recover," across four levels: Regular (predictable with existing resources), Supplemented (predictable with additional resources), Extended (unpredictable; outside assistance may be required), and Not Recoverable.

(CISA NCISS)

Two further NCISS features are worth importing wholesale. First, location of observed activity, scored on a modified Purdue model running from "unsuccessful" up through business network management (admin workstations, Active Directory, trust stores) to critical and safety systems. That gives you a defensible, non-arbitrary reason why an adversary on a domain controller outranks an adversary on a laptop — a reason that survives an argument with a service owner. Second, the campaign aggregation rule: if three or more component incidents share the same high-water mark, the campaign's priority is raised a level. Most corporate schemas have no mechanism at all for turning many mediums into one severe.

NCISS is candid that its inputs are "a mixture of discrete and analytical assessments" and that "different individual scorers will inevitably have slightly different perspectives." That is the argument for a multi-factor rubric over one person's gut.

Here is a four-level schema you can copy. Take the highest row that applies — severity is a maximum across dimensions, never an average.

And the half everyone forgets — the level is meaningless without an attached obligation:

Three operating rules make the schema work under pressure.

Round up under uncertainty. PagerDuty's public rule is the right one: "If you are unsure which level an incident is… treat it as the higher one," and reassess at the post-incident review, never during (PagerDuty — Severity Levels). Downgrading is cheap and can be done calmly. Under-calling costs you the first two hours, which are the only two hours you will wish you had back.

Separate escalation from elevation. NIST distinguishes them and most schemas conflate them: "Escalation generally refers to increasing resources or time frames, while elevation usually indicates involving a higher level of management" (NIST SP 800-61r3, RS.MA-04). Write them as two separate gates with two separate triggers. "We need three more engineers" and "the CEO needs to know" are unrelated decisions, and merging them means one of the two always happens late.

Keep severity away from materiality. Your SEV number is an operational resourcing signal. It is not a legal determination and it does not start a regulatory clock. Under SEC rules, Item 1.05 disclosure is triggered by a materiality determination, and the four-business-day clock runs from that determination, not from discovery (SEC press release 2023-139). Two different processes, two different owners. Chapter 15 owns the clocks; Chapter 13 sets this book's operative severity definitions for the response lifecycle. This section is about how you design the schema in the first place.

Actionable takeaway: Publish a severity table where every level names who gets paged and what becomes pre-authorized at that level, and write "when in doubt, round up, and reassess at the review" directly into the definition. A severity level without an attached obligation is a label, not a control.

#Decision points a human can follow at 03:00

Most playbooks contain instructions. The good ones contain decisions — and a decision written badly is worse than no decision at all, because it manufactures a pause at exactly the wrong moment.

A well-formed decision point has five parts, and dropping any one of them breaks it:

1. A question answerable from observable evidence, not from judgement. "Is data currently leaving the environment?" is answerable. "Is this serious?" is a committee.
2. A deadline. How long may the team deliberate before the default fires.
3. A named authority — a role, plus a named deputy. Never a person's name; never a team.
4. Both branches, spelled out, with what each one costs.
5. A default under uncertainty, which is what actually happens when nobody can be reached.

CISA builds its federal playbooks around "illustrated decision trees" for exactly this reason. NIST requires the policy to name "which roles have the authority to confiscate, disconnect, or shut down technology assets." NCSC is blunter still: decision-makers must hold actual authority to approve major actions like taking systems offline, and deputies must be named for when primaries are unreachable (NCSC).

One more structural move, borrowed from CISA and badly underused: put the considerations before the actions. CISA's containment section forces three explicit weighings before any containment action is taken — additional adverse impact on mission and services; duration, resources and effectiveness (full versus partial containment, full versus unknown containment); and impact on the collection and preservation of evidence. That block sits above the action list, physically, on the page. It is a speed bump with a purpose.

Here is a worked decision point, rendered as a decision table. Run down the rows in order and stop at the first Yes.

Row 4 encodes the best-documented containment failure in the literature. Mandiant's articulation: "incident responders must recognize that each defensive action may prompt the adversary to react: organizations should delay implementing actions that will directly disrupt the attacker until they are ready to eradicate the threat completely" (Aldridge, Black Hat USA 2012).

Row 1 exists because that rule has an exception, and Aldridge names it himself — piecemeal containment is still correct when the loss is happening in real time. A decision table that encodes only the sophisticated answer will have a responder watching an estate encrypt while they wait for a fuller picture. Both rows, in that order, or neither is safe.

Actionable takeaway: For every decision in every playbook, write the deadline, the authorizing role, the deputy, and what happens by default if nobody answers. If a decision point has no default, it has no deadline either — it just has a queue.

#Pre-authorized versus approval-gated: the most useful table you will build

If you build only one table from this chapter, build this one. Three columns: Action | Who may authorize | Reach path out of hours.

Its purpose is to make the approval question disappear for the eighty per cent of actions where the answer is obviously yes, so that the remaining twenty per cent get real attention.

NIST places leadership decision-making authority on "high-impact response actions, such as shutting down or rebuilding critical services" (NIST SP 800-61r3, §2.2). It also flags an authority boundary that stays undefined in most organizations until the night it is tested: where an MSSP or cloud provider is involved, the contract must state any restrictions on the provider making and implementing operational decisions, such as immediately deactivating services to contain an incident. If you outsource detection, find out today whether your provider can isolate your production hosts at 04:00 without asking, and whether you want that.

The canonical worked example of authority done right is Colonial Pipeline. CEO Joseph Blount testified that the company learned of the attack shortly before 5am and within roughly an hour decided to shut down the entire pipeline; he later stated that "shutting down the pipeline was absolutely the right decision" (Blount, Senate HSGAC testimony, 8 June 2021). The lesson for playbook craft is not "shut down fast." It is that the decision to stop the business was made in under an hour by a named person who already knew it was theirs to make. Nobody spent that hour discovering who was allowed to decide.

So, per critical service, write down four things: who can stop it, who must be told, what evidence justifies stopping it, and what happens by default if that person is unreachable in fifteen minutes. That last field is the one that gets omitted and the one that gets tested.

Actionable takeaway: Build the three-column table this week and get it signed by the person whose revenue you are proposing to switch off. An authority you have not confirmed in peacetime is an authority you do not have. Not "in principle." Signed.

#Playbooks-as-code — and where the effort stops paying

The field has moved, and the evidence is in how the major publishers maintain their own. Microsoft ships its IR playbooks as Markdown in a public git repo with pull-request review (MicrosoftDocs/security). AWS ships a library and a shared template in git with contributing guidelines (aws-samples/aws-incident-response-playbooks). RE&CT keeps its actions as YAML for machines and Markdown for humans (atc-react). Counteractive keeps a whole plan-plus-playbooks repo in Markdown with info.yml metadata, rendering to docx, html and pdf from source via CI (counteractive/incident-response-plan-template).

The benefits are concrete and none of them are aesthetic: a diffable history that answers "when did this step change and why"; ownership as CODEOWNERS, so a change to the ransomware playbook must be reviewed by its owner; pull-request review as the approval workflow, which is auditable evidence that approval happened; tags as approved versions; issues as the improvement backlog.

The highest-value piece is the CI check, and it is small. Lint every playbook on every commit for: owner set and resolvable; last_exercised within N months; next_review_due in the future; every referenced runbook ID exists in the repo; every contact card referenced exists. Fail the build otherwise. A playbook untested for twelve months flips from Active to Draft automatically — not because someone noticed, but because the pipeline noticed.

Now the honest part, because this is where teams over-invest.

CACAO is worth it if you already run a SOAR platform and want playbook portability between tools rather than lock-in to a vendor's UI; open-source CACAO orchestrators exist (COSSAS/SOARCA). CACAO is not worth it if you have five playbooks and one and a half analysts. The machine-readable representation earns its keep when machines execute it. Until then it is a second copy of the truth, and second copies drift.

The cheap version, in full. A private git repository — free. One Markdown file per playbook. A CODEOWNERS file. A scheduled job that greps the next_review_due field and opens an issue when it passes; twenty lines of shell. pandoc to render PDFs. No CI at all? A recurring calendar invitation for each playbook's review date, with the owner as a required attendee and the rendered PDF attached — it does the same job, worse, for nothing.

And then the thing that survives everything else. Print it. CISA is explicit: "Print these documents and the associated contact list and give a copy to everyone you expect to play a role in an incident. During an incident, your internal email, chat, and document storage services may be down or inaccessible" (CISA IRP Basics). This is the paradox of playbooks-as-code and there is no clever way around it: the source of truth lives in a system that an adversary may take from you on exactly the night you need it. The British Library, with its website and intranet down, fell back to social media and email and WhatsApp cascades (British Library, Learning Lessons from the Cyber-Attack).

Your IR tooling, ticketing, contact list, credential vault and backup catalog must not depend on the identity plane you are about to declare compromised. Neither must your playbook. Print it. Date the printout. Reprint it every quarter. Not eventually. Quarterly.

Actionable takeaway: Put your playbooks in git today and add one CI check — fail the build if last_exercised is older than twelve months. Then print the current set with the contact list and hand a copy to everyone with a role. Both halves, or neither works.

#Maintenance: how playbooks actually die

They do not die dramatically. They die by field.

CISA's cadence recommendation is unusually aggressive and worth adopting as a stretch target: "Review this plan quarterly. The best IRPs are living documents that evolve with business changes" (CISA IRP Basics). NIST SP 800-53 IR-8 makes the frequency an explicit organizational parameter — you must choose one and document it, and "when we get to it" is not a parameter (CSF Tools — IR-8).

Calendar cadence alone produces a review that finds nothing. Add event triggers, taken from where NIST says improvements actually come from: evaluations and audits (ID.IM-01); tests and exercises, rated High priority (ID.IM-02); and the execution of operational processes, also High, where improvements are "often identified when creating follow-up reports for incidents or holding 'lessons learned' [meetings]" (ID.IM-03) (NIST SP 800-61r3, Table 2). Add environmental change: new systems, new suppliers, new regulations, a reorganization that moved an authority.

Write those triggers into the playbook header, so the obligation travels with the document:

CISA's hotwash objectives name the one thing to check every single time, and it is on the list because it is a recurring finding: "Reviewing and updating roles, responsibilities, interfaces, and authority to ensure clarity." Authorities rot faster than steps. A reorganization does not send a notification to your playbooks.

What makes post-incident updates real is pairing each finding with an owner and a due date — the after-action report and improvement plan pattern CISA uses in its tabletop packages (CISA CTEP). A finding without an owner is a paragraph. Chapter 18 covers exercise design; the only maintenance rule that matters here is that exercise output becomes tracked issues, not a slide.

Actionable takeaway: Set a documented review frequency, then add the four event triggers to every playbook header with a deadline attached to each. Assign the post-incident update to the playbook owner with a ten-day due date, tracked where you track everything else that has to actually get done.

#The failure modes, from real post-incident reports

Chapter 13 covers how incident response fails. These are the narrower set: documented ways the document fails. Each has a fix that fits in a header field or a table.

CISA's federal playbook adds a structural one worth budgeting for: segment and manage SOC systems separately from broader enterprise IT, so that "IR and defensive systems and processes will be operational during an attack."

Actionable takeaway: Turn every row of that table into one line on your preparation checklist, with an owner and a frequency. If you can only do one, test the contact cascade — it is free, it takes twenty minutes, and a stale recipient list is the documented reason one of the largest breaches on record got its window.

A playbook is not a document. It is a set of decisions you made while calm, written down where a tired person can find them. Every hour spent in a quiet room arguing about who is allowed to shut down the billing system is an hour bought back at four in the morning, at a very favourable exchange rate. Spend it now. Print the result. Stay rehearsed, stay boring, and never let a plan be the only copy.

#Chapter checklist

• CRAFT-01A written incident response plan exists, is formally approved by senior leadership, and is under fifteen pages with no commands or tool-level steps in it. [IG1] [GV.PO] [CIS 17] [A.5.24]
• CRAFT-02Every playbook has a named individual owner and a named deputy — not a team alias or distribution list. [IG1] [GV.RR] [A.5.24]
• CRAFT-03Every playbook header carries: id, version, status, owner, approver, created, modified, last_exercised, next_review_due, and TLP marking. [IG1] [GV.PO]
• CRAFT-04Every playbook states entry criteria as observable conditions, and a "do not use this playbook for" list. [IG1] [RS.MA] [A.5.25]
• CRAFT-05Every playbook states exit criteria as a gated, observable condition (for example "no new signs of compromise"), not a subjective judgement. [IG2] [RS.MA]
• CRAFT-06Every playbook contains an explicit loop-back rule directing responders back to the analysis step when new indicators are found. [IG2] [RS.AN]
• CRAFT-07Every playbook has an on_playbook_failure instruction covering what to do when the infrastructure the playbook depends on is unavailable or itself suspect. [IG2]
• CRAFT-08A severity schema of four or fewer levels is published, keyed to business impact across at least functional impact, information impact and recoverability. [IG1] [RS.MA-02] [CIS 17]
• CRAFT-09Each severity level names who is paged, the declaration deadline, the executive update cadence, and what becomes pre-authorized at that level. [IG1] [RS.MA-03]
• CRAFT-10The severity definition contains an explicit round-up-under-uncertainty rule, with reassessment deferred to the post-incident review. [IG1] [RS.MA-02]
• CRAFT-11Escalation (more resources) and elevation (higher management) are defined as separate gates with separate triggers. [IG2] [RS.MA-04]
• CRAFT-12Severity classification is documented as operationally distinct from any regulatory materiality determination, with different named owners. [IG2] [RS.CO]
• CRAFT-13Every decision point in every playbook states a deadline, an authorizing role, a named deputy, both branches, and a default action if the deadline passes undecided. [IG1] [GV.RR]
• CRAFT-14A pre-authorized actions table exists, listing actions responders may take with no approval and log afterwards. [IG1] [RS.MI]
• CRAFT-15An approval-gated actions table exists with three columns — action, authorizing role, out-of-hours reach path — and is signed by the executive whose services it covers. [IG1] [GV.RR] [A.5.24]
• CRAFT-16For every critical business service, the plan names who may stop it, who must be told, what evidence justifies stopping it, and the default if that person is unreachable within a stated interval. [IG2] [GV.RR]
• CRAFT-17Contracts with any MSSP or managed provider state explicitly whether the provider may take unilateral containment action on your estate. [IG2] [GV.SC]
• CRAFT-18Containment sections place a considerations block — mission impact, containment duration and effectiveness, evidence impact — above the action list. [IG2] [RS.MI]
• CRAFT-19Playbooks are stored in version control with per-playbook ownership and change review recorded before merge. [IG2] [GV.PO]
• CRAFT-20An automated check fails or flags any playbook whose last_exercised date is older than the documented interval, and such playbooks are marked Draft. [IG3] [ID.IM-02]
• CRAFT-21Playbooks reference atomic, separately-owned runbooks by ID rather than inlining commands, so a tool change is fixed once. [IG3] [GV.PO]
• CRAFT-22A current printed copy of the plan, active playbooks and the contact card is held by every person with an assigned response role, dated and reissued at a documented interval. [IG1] [RC.CO] [A.5.29]
• CRAFT-23A documented review frequency exists, plus four event triggers — real activation, exercise, audit finding, and change of tooling/supplier/authority/regulation — each with a deadline and an owner. [IG1] [ID.IM-01] [ID.IM-03] [A.5.27]
• CRAFT-24Post-incident and post-exercise findings are tracked as owned, dated items in the same system used for other committed work, and closure is verified. [IG2] [ID.IM-03] [A.5.27]
• CRAFT-25The response contact cascade is tested against a stated time limit at least annually, and the test result is recorded. [IG1] [RS.CO] [A.6.8]

#Sources

1. GAO-18-559, Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach
2. Harrison, Y. & Horne, J.A. (2000), The Impact of Sleep Deprivation on Decision Making: A Review
3. CISA, Incident Response Plan (IRP) Basics
4. NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
5. AWS Security Incident Response Guide — Runbooks
6. AWS Well-Architected SEC10-BP04 — Develop and test security incident response playbooks
7. CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
8. NCSC, Incident management — Plan: your cyber incident response processes
9. RE&CT Framework and atc-project/atc-react
10. OASIS CACAO Security Playbooks v2.0
11. COSSAS/SOARCA — open-source CACAO orchestrator
12. CISA, National Cyber Incident Scoring System (NCISS)
13. PagerDuty Incident Response — Severity Levels
14. SEC press release 2023-139 — Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
15. Aldridge, J., Remediating Targeted-threat Intrusions, Mandiant / Black Hat USA 2012
16. Blount, J., Senate HSGAC testimony, 8 June 2021 (Colonial Pipeline)
17. MicrosoftDocs/security — incident response playbooks
18. aws-samples/aws-incident-response-playbooks
19. counteractive/incident-response-plan-template
20. CSF Tools — NIST SP 800-53 r5 IR-8, Incident Response Plan
21. CISA Tabletop Exercise Package (CTEP) documents
22. British Library, Learning Lessons from the Cyber-Attack, March 2024
23. Healthcare Dive — Change Healthcare compromised credentials, no MFA
24. CISA — I've Been Hit By Ransomware
25. Cyber Safety Review Board, Review of the Summer 2023 Microsoft Exchange Online Intrusion
26. Tariq, Baruwal Chhetri, Nepal & Paris, Alert Fatigue in Security Operations Centres, ACM Computing Surveys 57(9), 2025

#Chapter 3 — The Coverage Model

A one-page model of everything a 2026 security program is accountable for — six NIST CSF 2.0 Functions, 29 domains, every one wired to a testable control and a named owner — so you can find the work nobody owns before an incident finds it for you.

Who needs this: CISO, security leaders, program managers, anyone writing next year's plan | Read time: 20 min | Maps to: CSF 2.0 GOVERN (GV.OC, GV.RM, GV.RR, GV.OV), IDENTIFY (ID.AM, ID.IM), CIS Controls v8.1 1–2, ISO/IEC 27001:2022 A.5.2

Fellow defenders of the digital realm, there is a moment that arrives for every security leader, usually about four months in, usually at 11pm. You are trying to write next year's plan and you realize you cannot answer a question a competent thirteen-year-old could ask: what, exactly, are you responsible for?

Not what you are working on. Not what is in the SIEM. The full list — everything that would land on your desk if it went wrong, including the parts you have never once discussed, the parts that live in Legal's head, the parts that arrived with an acquisition and were never formally handed to anyone. You cannot assign work you have not written down. You cannot budget for it. And you certainly cannot admit to a gap in it, because a gap requires a boundary, and you do not have one.

So every security leader eventually builds the same artefact: one page showing the whole job. Most of them build it badly, and I include myself in that. The usual failure is an inventory of topics — a poster of nouns arranged by whatever taxonomy felt natural on the day, with no connection to any control anyone can test and no way to tell whether the green things are green because someone did the work or because green is a nice color. It goes on the wall. Nobody looks at it again.

This chapter gives you the version that survives contact. It is called the Coverage Model, it is this book's own, and what follows is how to run it, how to argue with it, and how to check it against the best-known independent map of the same territory.

#What the Coverage Model is, and the three things that make it different

The Coverage Model, edition 2026.1, is a scope and accountability model for a security program: six Functions, 29 domains, 145 named capabilities, published by Intelligent Automation, LLC as part of this book. Every domain has a status bar. Every bar reports something real.

Three design decisions make it useful rather than decorative, and they are worth stating plainly because each one is a rejection of how these things are normally built.

1. It stands on a free public spine. The top level is not ours and was never going to be. It is the six NIST CSF 2.0 Functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER — as published in NIST CSWP 29 on 26 February 2024 (NIST CSWP 29). That buys three things at zero cost: your auditors already speak it, your regulators already reference it, and your board has probably already seen a slide with those six words on it — so you are not spending the first ten minutes of a budget meeting teaching a taxonomy you invented. It also means the model inherits CSF's own logic — GOVERN above the rest because accountability is a precondition, not a control; RECOVER separate from RESPOND because coming back is a different discipline from stopping the bleeding — rather than an arrangement we thought looked balanced.

2. Every node is wired to a testable control. Under the 29 domains sit 145 capabilities, and each domain is bound to the real control codes in this book — 463 controls across the chapter checklists, which assemble into Appendix A. That changes the artefact's nature. A domain is not green because the person who drew the map felt it was covered. It is green because a named human answered a specific, checkable statement — "phishing-resistant MFA is enforced for every account holding a privileged role, with no exception group" — and said yes, on a date, with an evidence artefact behind it. A poster tells you what exists in the world. This one tells you what is true in your organization, and it changes when the truth does.

3. It is navigable. Every domain points at the chapter that tells you how to do the thing. That is not a convenience feature; it is the difference between a scope statement and a plan. When a domain comes back red the next question is always "so what do we do about it," and a model that cannot answer that has handed you an anxiety generator. The crosswalk at the end of this chapter is the full index — the model is the table of contents for this book.

The model does not tell you what to do first. It tells you what exists, who owns it, and whether anyone can prove it. Sequencing is Chapter 20's job. Governing it is Chapter 16's. This chapter draws the boundary.

It helps to be precise about which question this artefact answers, because the other frameworks in this book answer different ones and readers routinely mash them together.

That last question sounds trivial until you try to answer it from memory with a CFO looking at you. CSF 2.0 gives you six Functions and 22 Categories — the right altitude for board reporting and precisely the wrong altitude for noticing that nobody has ever thought about firmware updates for the devices in your warehouse. The Coverage Model operates one storey down, where things get forgotten.

Actionable takeaway: before you score anything, read all 29 domain names out loud with your team and mark each one we do this / we have decided not to do this / we have never discussed this. The third pile is the point of the exercise, and it is always larger than anyone expects.

#A guided tour of the six Functions

Here is the shape of the thing. I am not going to list all 145 capabilities — you have them on the model itself. What follows is what is notable, commonly neglected, or genuinely surprising in each Function.

#GOVERN — someone is accountable, and can prove it

Six domains: Program Governance, Playbook Discipline, Legal and Regulatory, Third-Party Governance, AI Governance, and Organizational Readiness.

Two things stand out. The first is that Playbook Discipline is a governance domain, not an operations one. Whether your plan, playbooks and runbooks are separated, versioned, and carry a severity schema tied to real business impact is a question about how your organization decides under pressure, not about tooling. Put it under DETECT or RESPOND and it quietly becomes the SOC's problem, which is how you end up with fourteen excellent playbooks nobody has the authority to invoke. Chapter 2.

The second is Legal and Regulatory: notification obligations mapped and current, attorney-client privilege posture, legal hold and evidence discipline, ransom payment authority with sanctions screening, regulator and law-enforcement engagement. In most organizations nobody inside the security function owns a single one of those. They are assumed to belong to General Counsel; General Counsel assumes the technical detail belongs to security; and the gap between those two assumptions is where privilege gets waived at 02:00 by a well-meaning engineer typing an incident summary into a shared document. Chapter 15 has the mechanics. This chapter's job is to get a name against the domain before you need it.

Also here: Organizational Readiness, which carries staffing sustainability and burnout as an explicit capability. Not as a wellness initiative. As scope.

#IDENTIFY — you know what you have and what is coming for it

Four domains: Asset and Attack Surface, Threat Model, Data Discovery, and Coverage and Gap Analysis.

Asset and Attack Surface is the domain everybody claims and almost nobody has. Its capabilities separate authoritative asset inventory from external attack surface discovery from shadow IT and unmanaged estate deliberately, because those three fail independently. A CMDB that is 94% accurate for managed laptops tells you nothing about the marketing subdomain still pointed at an expired storage bucket.

Threat Model is the domain most programs skip, and its first capability explains why it matters: current adversary behavior, not last year's. A threat model written at program inception and never refreshed is a document describing a world that has moved on.

And note that Coverage and Gap Analysis — this chapter, domain code MAP — sits inside IDENTIFY as a domain of its own. The model contains the practice of maintaining the model. That is not cuteness: an unmaintained scope statement is worse than none, because it launders staleness as diligence.

#PROTECT — the controls that actually stop it

The largest Function: seven domains and 40 capabilities. Identity and Access, Zero Trust, Cloud and Container, Data and Cryptography, Vulnerability and Exposure, Supply Chain Assurance, AI System Security.

Identity and Access is the biggest single domain at nine capabilities, and that is a statement about 2026. Three of the nine did not meaningfully exist five years ago: machine and non-human identity inventory, AI agent identity, scoping and revocation, and OAuth grant and app-consent control. An AI agent is a principal — it authenticates, holds authorization, can be over-permissioned, and somebody has to be able to revoke it on a Tuesday afternoon without filing a ticket with a vendor. That is an identity problem with an AI flavour, not an AI problem with an identity flavour, which is why it lives in Chapter 4 and not Chapter 7.

Two capabilities here are chronically under-read. Break-glass accounts, tested — most organizations have break-glass accounts and have never once used them, which means they have credentials, not a capability. And help-desk verification procedure, a single line in a model and also the entire initial access route for several of the most expensive intrusions of the last two years.

Data and Cryptography keeps post-quantum migration plan and crypto-agility and cryptographic inventory as separate capabilities, and the separation is the point: the plan is a project, agility is a structural property of your estate. NIST's deprecation frame — RSA-2048 and ECC-256 deprecated by 2030, disallowed after 2035 — is what turns this from research into maintenance (NIST PQC project). Chapter 8.

Vulnerability and Exposure includes one capability that reads like pedantry and is not: patch verification, not patch assumption. Your patch console reporting compliance is a claim by the same system that failed to patch.

#DETECT — you would actually know

Four domains: Telemetry and Logging, Detection Engineering, Identity Threat Detection, Triage and On-Call.

Telemetry's capabilities are ordered by how they fail. Coverage across identity, endpoint and cloud control plane first, because a detection you have no data for is a hypothesis. Retention longer than your dwell time second — if your logs roll at 30 days and intrusions sit undetected longer than that, you have bought a system that guarantees you cannot investigate the incidents that matter most. Logs shipped beyond the adversary's reach third, which people skip until the first time they watch an attacker with domain admin delete the evidence of how they got in.

Identity Threat Detection is split out from Detection Engineering on purpose, and reports into two chapters (4 and 9) because it is genuinely joint custody — which is exactly where things fall through.

Triage and On-Call carries the model's most opinionated line: alert fatigue treated as a defect. Not a fact of life, not a staffing complaint. A defect, with a ticket, an owner and a fix. High alert volumes with very high false-positive rates measurably degrade detection effectiveness and drive turnover (Tariq et al., ACM Computing Surveys 57(9), 2025). A tuning backlog is a detection outage in slow motion.

#RESPOND — you can act under pressure without improvising

Four domains: Incident Command, Scenario Playbooks, Communications, Orchestration.

The first capability under Incident Command is Incident Commander who does no technical work, and it is first because it is what breaks first: the best engineer in the room becomes IC, gets pulled into a terminal, and for the next forty minutes nobody is running the incident. Re-scope on every new indicator is the other line worth memorizing — most bad incidents are ordinary incidents whose scope nobody revisited.

Communications leads with out-of-band channel that exists before you need it. Standing up a secure comms channel while your identity provider is compromised is not a plan, it is a coin flip. It costs nothing in advance, which makes it the highest-return line in this Function for a small team.

Orchestration carries the cleanest guardrail in the model: rollback for every automated containment. Automation that can isolate 4,000 endpoints and cannot un-isolate them has not reduced your risk, it has changed which way it points. Chapter 17.

#RECOVER — you come back, and you come back clean

Four domains: Backup and Immutability, Recovery Execution, Business Continuity, Learning.

Read the first capability of Backup and Immutability carefully: immutable copies, not merely offsite copies. Offsite is a geography answer to an authorization question. If your backup platform trusts the same directory your production estate trusts, an attacker with that directory has your backups too — which is why backup credentials isolated from the production domain is the very next line, and why ransomware operators increasingly target backup infrastructure, identity services and virtualization management planes rather than only your ability to operate (M-Trends 2026).

Recovery Execution leads with identity-first recovery ordering, the most commonly inverted sequence in this book. Restore the file servers before you have rebuilt trustworthy identity and you have restored the attacker's access along with the data. Order of operations is content. Chapter 12.

Learning sits under RECOVER rather than in an appendix, and its last capability decides whether any of this compounds: findings reach a playbook change. A post-incident review that produces insight and no diff is a therapy session.

Actionable takeaway: walk the six Functions with your team in one sitting, in order, and stop at every domain where nobody in the room can name the person who owns it. Write those names down as you go. That list — not the scores — is the output.

#Running the gap analysis

Here is the method. One prepared afternoon, six to ten people, and an artefact you will use for a year.

You score each domain on two independent axes, then record an owner. Two axes, because coverage and confidence fail differently, and the interesting information lives in the disagreement between them.

The cell everyone under-reads is green coverage with red confidence. That is not a documentation problem, and treating it as one is how it survives. It is a belief you have never tested — the backup job that has run green for two years and has never been restored from, the access review that happens reliably and produces no record of what was revoked. Post-incident reviews find their nastiest surprises in that cell, every time.

Who is in the room: the CISO, the executive sponsor, every candidate domain owner, one person from Legal, one person from whichever business function owns your most regulated data, and — the attendee everyone cuts — at least one competent sceptic from outside the security team, whose job that afternoon is to ask "how do you know?" and not stop asking.

The order of these steps matters, and getting it wrong wastes the whole exercise.

Assign owners before scoring. Not after. Reverse those two steps and the same two failures happen every time. Unowned domains get scored optimistically, because no individual feels the score reflects on them — the domain nobody owns is precisely the one that collects a comfortable amber. Then, once scores exist, owner assignment becomes a negotiation about who is willing to inherit a red, and that is a negotiation nobody wins. Owner first. Score second. Every. Single. Time.

And now the punchline: the domains with no owner are more dangerous than the domains scored red. A red score is a known gap with a person attached. It shows up in someone's objectives, it gets a budget ask, it gets argued about. An unowned domain appears nowhere — no advocate, no line item, nobody who notices when it fails. In practice the unowned set is depressingly consistent: Legal and Regulatory, Third-Party Governance, AI Governance, Supply Chain Assurance, Business Continuity, and the security content of anything involving an acquisition. Every one of those has produced a headline incident in the last two years.

Actionable takeaway: finish the session with a one-page list of unowned domains and take it to your executive sponsor as an ownership question, not a funding question. "Who owns this?" is a decision an executive can make in the room, that afternoon. "Fund this" goes into a cycle and comes back next year, in a worse mood.

#Using it in a budget conversation

The same page does org design. Overlay your actual team structure on the 29 domains and the true shape of your organization appears: which domains have three people quietly competing over them, which have one exhausted person spanning five, and which are carried informally by somebody whose job title says something else entirely. When you next open a role, the model tells you what that role is for in a way a job description assembled from the last occupant's duties never will.

It is also a scope-defense tool. When new work arrives — a regulation, a platform, an acquisition — put it on the model, show which domain it lands in, and show what that domain's owner is already carrying. The conversation becomes an explicit trade instead of a silent accumulation.

Actionable takeaway: never present the model without also presenting what comes off it. A scope statement used only to add work trains everyone around you to stop reading it.

#The map that got here first

I would be writing dishonestly if I presented the idea of a one-page map of the security profession as ours. It is not. It belongs to Rafeeq Rehman, and he got there fourteen years before we did.

Since 2012, Rehman has built and annually updated the CISO MindMap, subtitled exactly the right question: What do Security Professionals Really do? The 2026 edition was last updated 11 April 2026, carries a printed expiration date of 30 September 2027, and is © 2012–2026 Rafeeq Rehman. You can download it, free, from rafeeqrehman.com.

Go and do that. Print it at a size you can genuinely read and put it on a wall. Twelve top-level branches and roughly three hundred and sixty nodes, on which attorney-client privilege sits next to SCADA HMIs, cyber insurance, AI agent identity, staff burnout prevention, and corporate politics — because all of those really are somewhere in the job, and the map does not care that your team is four people. The first time you read it properly it is uncomfortable, and that discomfort is the artefact working.

The Coverage Model is better for our purposes: public framework spine, controls you can hand an auditor, an index into a specific book. It is not better in general. Rehman's map is broader than ours in places we deliberately narrowed, it is maintained by someone with no product to sell you, and it has been continuously revised for over a decade — a track record neither this book nor any vendor poster can claim.

That is an interactive reconstruction of the CISO MindMap's structure, included here as a cross-check on our own scope — a second opinion on whether we drew the boundary in the right place. Three things you must know about it. It is derivative: it reproduces the map's branch and node structure for study and gap analysis, and it is not the original artefact. It is not endorsed by Rehman. And the NIST CSF color coding on its branches is this book's editorial addition, not his — with one exception, noted below, where he supplies the mapping himself. If you want the real thing, and you should, get it from rafeeqrehman.com.

#What is notable in the 2026 edition

Rehman's 2026 revision made four kinds of change: a category was removed, the AI material was substantially expanded, legacy items were consolidated, and the visuals were improved.

The removal is the most instructive. Remote Work is gone as a category — not because the risk evaporated, but because work-from-anywhere is now simply work, and a category that describes everything describes nothing. Its substance did not vanish; it dissolved into identity, endpoint, architecture and SASE, where it always belonged. Steal that discipline wholesale. A domain list that only ever grows stops being a scope statement and becomes a museum.

The additions tell you where the profession actually moved:

• Using and Securing AI is now a 28-node branch with a deliberate two-way split — Securing AI (13 leaves, covering AI policy and governance, AI frameworks, ethical and responsible use, LLMs/chatbots/agents/RAG, IP protection, agentic AI frameworks, AI application security testing, AI sovereignty, human-in-the-loop strategies, RAG and vector database security, third-party AI tools) and Using AI (9 leaves, the first of which is train InfoSec teams on AI technologies, ahead of any tool). Defending AI systems and defending with them are two jobs, and the split says so.
• AI Agent Identity now appears under Identity and Access Management, not under AI. Same conclusion our model reaches, arrived at independently.
• Quantum Safe Encryption appears appended to an existing threat-prevention leaf — Encryption, SSL, PKI, Quantum Safe Encryption — rather than as a new branch. Translation: post-quantum is now maintenance on your cryptographic estate, not a research project.
• Legacy items were consolidated, the unglamorous half of the removal discipline: once-distinct concerns collapse into one leaf as the industry stops treating them separately.

One structural detail worth borrowing: for Security Operations — 130 nodes, roughly 36% of the map — Rehman supplies the CSF mapping himself: Threat Prevention (Identify and Protect), Threat Detection (Detect), Incident Management (Respond and Recover). Where he maps, we use his.

#The four focus areas for 2026-27

The map carries a callout with four focus areas for the coming cycle. They are not branches; they are his read on where attention should go. Taken together they make a defensible annual plan for almost any security team.

1. Embrace and adapt to AI. The evidence for taking this seriously is specific. Anthropic disclosed GTG-1002, a campaign it assesses with high confidence to be Chinese state-sponsored, in which AI performed 80–90% of an intrusion campaign against roughly 30 targets with sporadic human intervention at decision gates (Anthropic). Google's threat intelligence group documented malware families that call an LLM at runtime to rewrite themselves (GTIG). The evidence for not losing your head is equally specific: Mandiant concluded from its 2025 investigations that most intrusions still stem from human and systemic failures rather than AI (M-Trends 2026), and VulnCheck found that of 1,061 vulnerabilities attributable to AI-assisted discovery, only 14 — 1.3% — have been confirmed exploited in the wild (VulnCheck). AI is inflating your patch queue considerably faster than it is inflating your risk.

2. Consolidate and rationalize security tools. Rehman places this obligation in three separate places, which is deliberate: retire redundant and under-utilized tools under the Team Management budget node, tools and vendors consolidation under Governance, and security tools rationalization under the M&A sub-branch. Budget, governance, integration — three reasons for the same work. The operative principle is ruthless and simple: no tool should cost more than the risk reduction it delivers. Cost is not the license line. It is license plus the engineer-days to run it, plus the alerts someone must triage, plus the integration it breaks on upgrade, plus the attention it steals from the tool that actually works.

Run the rationalization as a table, not a debate. Per tool: annual all-in cost, named owner, the detections or controls it uniquely delivers, the date someone last acted on its output, and what breaks if it is switched off on Friday. A tool with no named owner is unmanaged; a tool whose output nobody has acted on in ninety days is a subscription, not a control.

3. Old threats have not disappeared. This is the focus area that protects you from the first two. Ransomware and extortion appeared in 48% of confirmed breaches in the 2026 DBIR, up from 44% (SecurityWeek). Phishing and its variants accounted for around 60% of all initial infection vectors across 4,875 EU incidents in ENISA's current threat landscape (ENISA ETL 2025). Third-party involvement appeared in roughly 48% of breaches, a ~60% year-over-year increase, and only 26% of CISA KEV vulnerabilities were fully remediated by polled organizations, down from 38%, with median patching time up to 43 days from 32 (Help Net Security). The Salesloft Drift compromise turned OAuth refresh tokens issued to one vendor into data access across 700+ organizations, with no customer-side vulnerability to patch (AppOmni). Meanwhile the boring control keeps paying: 66% of organizations with encrypted data recovered from backups, up 12 points (Sophos). None of that is an AI problem, and none of it waits while you build an AI program.

4. Take good care of your teams. I want to give this one the weight Rehman gives it, because it is the focus area most likely to be read as a soft closing sentiment and skipped. It is not soft. It is a control, and its failure mode is measurable.

Start with the mechanism. Sleep-deprived people stay reasonably good at well-practiced, rule-based tasks. What degrades is handling the unexpected, revising plans, filtering distraction and communicating clearly (Harrison & Horne, 2000) — which is a precise description of what a novel incident demands. Alert fatigue compounds it (Tariq et al., 2025).

Then look at what a real incident does to real people. The British Library published, as an explicit lesson from its own review, that incident management plans should include provisions for managing staff and user wellbeing, because attacks are deeply upsetting for staff whose data is compromised and whose work is disrupted. The same review recorded that its technology department was already overstretched with staff shortages before the incident (British Library cyber incident review). The pre-incident staffing deficit became the post-incident recovery constraint. That is the whole argument in one sentence.

NCSC publishes the only government guidance dedicated to responder welfare, and its recommendations are concrete enough to implement this month: include all staff in the IR plan with deputy arrangements and out-of-hours coverage; build a culture where people feel safe saying they are overwhelmed and safe raising concerns about colleagues; plan internal communications; be conscious of staff concerns about personal impact and job security; and practice your response. NCSC also names the part nobody plans for — incidents "often start with an intense period of activity, but many also have a 'long tail' with the impact lasting for months" (NCSC).

The 2026-specific piece is that fourth recommendation, aimed squarely at AI. Your team is reading the same headlines you are, and a good share of them are being told their function is about to be automated. You cannot honestly promise nobody's role changes — some will. What you can do is be specific, early, and repeatedly: name which tasks you intend to automate, name what you expect people to do with the reclaimed time, fund the training as a budget line rather than in someone's evenings, and never let an AI capability arrive by surprise inside a tool rollout. Ambiguity burns people out faster than workload does. Most of what gets called emotional intelligence during technological disruption is telling people the truth on a predictable schedule.

And almost none of it needs budget. Rotating incident command duty on a schedule rather than on exhaustion costs nothing. Naming a deputy for every authority costs nothing. Running post-incident reviews as blame-aware investigations costs nothing but discipline, and the practitioner-standard process is published free (Howie guide). Reporting on-call load and unplanned-work hours to your executive sponsor costs one row on a slide — and it is the most effective way to make understaffing visible before it becomes an outage.

Actionable takeaway: put three human metrics on the same dashboard as MTTD and MTTR — on-call hours per person per month, percentage of weeks with unplanned out-of-hours work, and vacancy days for open roles. Report them every time you report the technical ones. A trend line is an argument. "The team is tired" is not.

#How to use two maps without going mad

They do different jobs, so run them on different clocks.

Ours is for accountability and status. It has owners against it, controls behind it, and a color that changes when your assessment changes. It is what you take to a budget meeting and refresh on a cadence.

His is for a scope challenge. Once a year, walk his twelve branches against our 29 domains, asking exactly one question: is there anything on his map that has no home on ours? Not "do we do this" — "does our model even have a place to put it."

And here is the part that has to be honest to be worth anything: if his map has a branch ours has no home for, that is a finding against us, not against him. I already know of two. Our model has no first-class home for physical security, which he carries under Risk Management, and its coverage of IoT, AR/VR and edge computing is oblique at best — reachable only through asset inventory in Chapter 10 and the OT playbook in Chapter 14.14. If either is genuinely in scope for you, this book is not your only source, and pretending otherwise would be the exact failure this chapter is about.

#Honest limitations of the Coverage Model

Overselling this thing is the fastest way to get it thrown out of your organization, so here are the caveats I would want if I were reading someone else's model.

1. It is not a control framework. The model contains no safeguards. The controls live in the chapter checklists and in Appendix A; the model is the index over them. You cannot certify against a scope statement.
2. It is not a maturity model. No tiers, no defined "good." The red/amber/green rubric in this chapter is a rubric, not a standard — do not report it as a CSF Tier, because CSF Tiers are explicitly not a maturity model either (NIST CSWP 29).
3. A green bar means someone asserted a control is implemented. It does not mean it was audited. This is the limitation that matters most, because the model's greatest strength — reading live status from your own assessment — is also the mechanism by which it can lie to you fluently and in color. Self-assessment is exactly as good as the person filling it in and the sceptic sitting across from them. That is why confidence is scored separately, why every green demands a named evidence artefact, and why the outside sceptic is not an optional attendee.
4. It does not prioritize. Every domain is drawn the same size. Right for a scope statement, wrong for your Monday morning. Sequencing is Chapter 20.
5. Applicability varies enormously by industry. A regional credit union and a pipeline operator will legitimately descope different halves of this model. Descoping is supported — but do it in writing, with a named accepting executive and a date, or it is not descoping, it is forgetting.
6. A model maintained by the people it grades has an obvious failure mode. We wrote the model, we wrote the controls, and we wrote the book it indexes. Every incentive points toward a model whose shape flatters the material. Three defenses, and hold us to all of them: the spine is NIST's, so the top level cannot be quietly reshaped to suit a chapter; the annual scope challenge against Rehman's independent map exists precisely to catch what we left out; and the model carries a review date after which it is presumed wrong. Apply the same three tests to your own instance. If your model has never produced a finding that embarrassed the people who maintain it, it is not being used.

Actionable takeaway: use the Coverage Model to find the work and the frameworks in Chapter 16 to govern it. Anyone who tries to make a scope model do CSF's job produces a document that satisfies neither the engineer nor the auditor.

#Crosswalk: the model to this book

Print the model. Assign the owners before you score anything. Find the domains with nobody's name on them — and put a name on them before an incident does it for you.

Stay scoped, stay owned, stay unsurprised.

#Chapter checklist

• MAP-01A documented coverage model covering the full scope of the security program exists, is dated, and is accessible to the whole security team. [IG1] [GV.OC]
• MAP-02Every domain in the coverage model has exactly one accountable owning role recorded, or is explicitly recorded as unowned. [IG1] [GV.RR]
• MAP-03Owners were assigned before any coverage scoring took place, and the assignment record predates the scoring record. [IG2] [GV.RR]
• MAP-04Every domain is marked in-scope or out-of-scope, each with a one-line written rationale approved by the executive sponsor. [IG1] [GV.OC]
• MAP-05Each in-scope domain carries two independent scores — coverage and confidence — refreshed within the last 12 months. [IG2] [ID.IM]
• MAP-06Every domain scored green for confidence names a specific evidence artefact that a third party could inspect. [IG2] [GV.OV]
• MAP-07Every domain scored green for coverage and red for confidence has a dated remediation action with a named owner. [IG2] [ID.IM]
• MAP-08The scoring session included at least one participant from outside the security function whose stated role was to challenge evidence. [IG2] [GV.OV]
• MAP-09A current one-page list of unowned domains exists and has been presented to the executive sponsor with a dated decision against each line (owner assigned, funded, risk accepted, or descoped). [IG1] [GV.RR]
• MAP-10The Legal and Regulatory domain — notification obligations, attorney-client privilege posture, legal hold, ransom payment authority, regulator engagement — has a named owning role and a named legal counterpart. [IG1] [GV.OC]
• MAP-11Coverage-model status is derived from the control checklist responses in the master checklist, not from independent freehand judgement. [IG2] [GV.OV]
• MAP-12Domain scores are reported as a list of specific findings; no aggregate maturity score or average is reported to leadership. [IG2] [GV.OV]
• MAP-13The coverage model has been checked within the last 12 months against at least one independent external scope model, and any branch with no home in our model was recorded as a finding. [IG2] [ID.IM]
• MAP-14Where a domain is descoped, the descoping decision names the accepting executive role and the date it was accepted. [IG2] [GV.RM]
• MAP-15The coverage model carries an explicit expiration or review date, and a calendar entry exists to refresh it before that date. [IG1] [GV.OV]
• MAP-16At least one domain or category has been removed or merged in the last review cycle, or the review record states explicitly that none warranted removal. [IG3] [ID.IM]
• MAP-17New scope arriving from regulation, acquisition or platform change is mapped to a domain and an owner before implementation work begins. [IG3] [GV.OC]
• MAP-18A complete inventory of security tools exists, recording annual all-in cost, owning role, the unique control or detection each delivers, and the date its output was last acted upon. [IG1] [CIS 2] [ID.AM]
• MAP-19Every security tool with no named owner, or with no acted-upon output in the last 90 days, has a documented retain-or-retire decision. [IG2] [ID.AM]
• MAP-20At least one redundant or under-utilized tool has been retired in the last 12 months, with the released budget explicitly reallocated. [IG2] [GV.RM]
• MAP-21An inventory of AI systems, tools and agents in use exists, recording owner, data touched, autonomous actions permitted, and upstream model or vendor. [IG1] [ID.AM] [GV.SC]
• MAP-22The incident response plan includes staff welfare provisions: named deputies for every authority, a duty rotation schedule, and out-of-hours coverage arrangements. [IG1] [GV.RR] [A.5.24]
• MAP-23On-call hours per person, unplanned out-of-hours work, and vacancy days are reported to executive leadership alongside technical security metrics. [IG2] [GV.OV]
• MAP-24Training budget for the security team is a protected, named line item rather than a residual, and includes AI skills development. [IG2] [PR.AT]
• MAP-25Post-incident reviews are run as blame-aware investigations producing documented insights, and each insight is traced to a playbook or control change. [IG2] [ID.IM] [A.5.27]

#Sources

1. NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29 (26 February 2024) — https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
2. NIST, CSF 2.0 PDF — https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
3. Rafeeq Rehman — CISO MindMap 2026 (last update 11 April 2026; expiration 30 September 2027; © 2012–2026 Rafeeq Rehman) — https://rafeeqrehman.com
4. CIS, Critical Security Controls v8.1 — https://www.cisecurity.org/controls/v8-1
5. CIS, Implementation Groups — https://www.cisecurity.org/controls/implementation-groups
6. CISA, Zero Trust Maturity Model v2.0 — https://www.cisa.gov/zero-trust-maturity-model
7. NIST Post-Quantum Cryptography project — https://csrc.nist.gov/projects/post-quantum-cryptography
8. SecurityWeek on the Verizon 2026 DBIR — https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
9. Help Net Security on the Verizon 2026 DBIR — https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
10. Mandiant / Google Cloud, M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
11. Sophos, State of Ransomware 2026 — https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026
12. VulnCheck, State of Exploitation 1H-2026 — https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
13. Anthropic, Disrupting AI espionage (GTG-1002) — https://www.anthropic.com/news/disrupting-AI-espionage
14. Google Threat Intelligence Group, threat actor usage of AI tools — https://cloud.google.com/blog/topics/threat-intelligence/threat-actor-usage-of-ai-tools
15. ENISA Threat Landscape 2025 — https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf
16. AppOmni, Salesloft Drift / Salesforce (UNC6395) analysis — https://appomni.com/blog/drift-breach-salesforce-unc6395-saas-prevention/
17. NCSC, Putting staff welfare at the heart of incident response — https://www.ncsc.gov.uk/guidance/putting-staff-welfare-at-the-heart-of-incident-response
18. British Library, Cyber Incident Review (8 March 2024) — https://www.bl.uk/home/british-library-cyber-incident-review-8-march-2024.pdf/
19. Harrison & Horne, The Impact of Sleep Deprivation on Decision Making (2000) — https://fatiguemanagersnetwork.org/wp-content/uploads/Harrison-et-al.2000_-The-Impact-of-Sleep-Deprivation-on-Decision-Making.pdf
20. Tariq, Baruwal Chhetri, Nepal & Paris, Alert Fatigue in Security Operations Centres, ACM Computing Surveys 57(9), 2025 — https://dl.acm.org/doi/10.1145/3723158
21. Howie: The Post-Incident Guide (PagerDuty) — https://howie-guide.pagerduty.com/

#Chapter 4 — Identity and Access: The New Perimeter

How to build an identity control plane that a modern adversary cannot phish, socially engineer, or replay — and how to take it back in the right order when they get in anyway.

Who needs this: CISO · IAM lead · IT service desk manager · Cloud platform owner · SOC lead · Incident Commander | Read time: 30 min | Maps to: CSF 2.0 PROTECT (PR.AA), DETECT (DE.CM), RESPOND (RS.MI); CIS Controls v8.1 — 5 (Account Management), 6 (Access Control Management), 8 (Audit Log Management); ISO/IEC 27001:2022 A.8.15, A.8.16

Cyber-survivors, take a seat. This is the chapter that pays for the book.

Here is the state of play. Sophos found that 79% of ransomware attacks began with an identity-based approach, and that 67% of victims confirmed the ransomware incident overlapped with an identity attack — despite 97% of those organizations having some MFA deployed, just not consistently across VPNs, firewalls and legacy apps (Sophos, State of Ransomware 2026). CrowdStrike reports 82% of its detections were malware-free (CrowdStrike 2026 Global Threat Report). Microsoft reports that 97% of identity attacks are password attacks, and — the number to write on the whiteboard — that phishing-resistant MFA blocks over 99% of identity-based attacks even when the attacker already holds a valid username and password (Microsoft Digital Defense Report 2025).

Honesty first, because you will get asked about this in a board meeting: the two big datasets disagree at the headline. Verizon's 2026 DBIR reports vulnerability exploitation at 31% overtaking credential abuse at 13% as the top initial vector, the first change in nineteen years (SecurityWeek on DBIR 2026). That is not a contradiction, it is a population difference. DBIR counts all breaches and is dominated by mass edge-device exploitation. Sophos, Coveware and Mandiant count hands-on-keyboard incident response, which is dominated by identity. Both are true. Patch the perimeter (Chapter 10) and defend the identity plane (this chapter), and stop arguing about which one is number one.

The thing that actually changed is speed. Mandiant measured the median hand-off from initial-access broker to ransomware operator at 22 seconds, down from over eight hours in 2022 (M-Trends 2026). There is no longer a window between "someone stole a credential" and "someone is inside your environment doing damage." Which means your identity controls are not a compliance exercise with a quarterly review cycle. They are the load-bearing wall.

#1. What "the perimeter" actually is now

The old perimeter was a place. The new one is a decision: should this principal, on this device, in this context, be allowed to do this thing right now? Everything in this chapter is either making that decision correctly, proving you made it, or reversing it fast when you got it wrong. Three consequences follow, and each breaks a habit most programs still have.

Your identity population is not your headcount. It is your headcount plus service principals, app registrations, workload identities, CI publishing tokens, Kubernetes service-account tokens, every OAuth grant an employee clicked through, and — new for 2026 — every autonomous agent you have deployed. Most organizations can count the first number and not the rest.

Your containment primitive is token revocation, not password reset. Microsoft says it about as plainly as a vendor ever says anything: for consented OAuth applications, "normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack, because these apps are external to the organization" (Detect and remediate illicit consent grants). Section 10 is the whole procedure.

Your service desk is an attack surface with a phone number. CISA's Scattered Spider advisory documents helpdesk impersonation as a primary technique — research the employee, call IT posing as them, obtain a password reset and an MFA token transfer to an attacker-controlled device, often splitting the request across separate contacts so no single agent sees the whole thing (CISA AA23-320A). Section 9 gives you a script.

Actionable takeaway: Before you buy anything, produce one number — the total count of identities in your environment, human and non-human, with an owner named for each. If you cannot produce it in a week, that gap is your first project, not your third.

#2. Phishing-resistant MFA: what it means and what it does not

#Why push and SMS fail

Push-notification MFA asks a tired human to make a security decision at 2am, and attackers know it — that is the entire business model of MFA fatigue. CISA lists push bombing and SIM swap among Scattered Spider's confirmed techniques, alongside forging MFA credentials post-compromise (CISA AA23-320A). Every approve prompt is a coin flip you are letting someone else call.

But fatigue is the easy failure. The hard one is adversary-in-the-middle. AiTM reverse-proxy kits — Tycoon 2FA, Evilginx2, Modlishka, Muraena — sit between the victim's browser and the real identity provider and capture the session token after the victim completes genuine MFA (Group-IB; Proofpoint). Nothing is bypassed. The MFA works perfectly. It is simply irrelevant, because the attacker did not want your second factor — they wanted the cookie you got for passing it. The infrastructure is disposable by design, with rotating hosts and short domain lifetimes, so blocklist-based defense fails structurally, not occasionally.

And note what CISA is explicit about: number matching is a push-fatigue mitigation, not phishing-resistant MFA (CISA phishing-resistant MFA resources). Number matching is a speed bump on the road to the destination. Do not let anyone in your organization report it as arrival.

#What "phishing-resistant" means cryptographically

The property that matters is origin binding. In a FIDO2/WebAuthn registration, the authenticator generates a key pair scoped to a specific relying-party identifier — your real domain. At sign-in, the authenticator signs a challenge together with the origin the browser actually connected to. If the browser is talking to login.micros0ft-sso.com, the authenticator either has no credential for that origin or produces a signature bound to it, and the real identity provider rejects it. The user cannot be tricked into approving the wrong thing, because approval is not a human judgement about a screen — it is a machine assertion about a domain. The private key never leaves the authenticator, so there is nothing in the phishing proxy's hands worth replaying.

That is why Microsoft's ">99% of identity-based attacks blocked even when the attacker holds valid credentials" figure is credible rather than marketing. The attacker's whole toolkit — sprayed passwords, fatigue prompts, proxy pages — operates on a channel the protocol simply does not use.

CISA's own mitigation list for Scattered Spider names it precisely: phishing-resistant MFA (FIDO/WebAuthn or PKI) (CISA AA23-320A).

#The 2026 wrinkle: synced passkeys are not device-bound passkeys

Passkeys come in two shapes, and treating them as one thing is the mistake of the year. A device-bound passkey has a private key that is generated on and never leaves a hardware authenticator — a security key, a TPM, a secure enclave. A synced passkey has a private key that is replicated through a cloud credential store so it lands on all of a user's devices. Both are phishing-resistant at the protocol level. They have different recovery models, different blast radii, and different answers to the question "who else can reach this key material?" A synced passkey's security floor is the security of the cloud account holding the sync store and the account-recovery path attached to it — which is, once again, a help desk with a phone number.

The control response does not depend on resolving that. For privileged roles, require attested, device-bound authenticators and do not accept a synced credential. For the general workforce, synced passkeys are an enormous improvement over passwords and push, and you should ship them. Two tiers, one policy document.

#A realistic migration sequence

The order matters here, and the reason is boring and correct: if you enforce before you enrol, you lock out your own administrators, and the emergency you create is indistinguishable from the one you were defending against.

Step 9 is where programs actually die. Sophos's finding was not that victims had no MFA — 97% had some. It was that coverage was inconsistent across VPNs, firewalls and legacy apps. An adversary does not attack your average; they attack your minimum.

The cheap version. Hardware keys cost money, and two per privileged user costs twice that. Here is the honest budget arithmetic: you do not need keys for everyone on day one. You need them for the accounts that can change the world — global/tenant admins, domain admins, cloud organization management accounts, the backup console, and the identity provider itself. In most small organizations that is under fifteen people. Two keys each is a three-figure purchase, not a project. Everyone else gets platform passkeys, which are free and already in the operating systems and browsers you own. Do the fifteen this month. Do the rest this year.

Actionable takeaway: Set a calendar date for killing push and SMS on privileged accounts, put a named owner against it, and enrol break-glass accounts before that date arrives. Not "eventually." A date, on a calendar, with an owner.

#3. Privileged access: no standing admin rights

Standing privilege is a stored credential that is valuable 24 hours a day and used for perhaps twenty minutes a week. Just-in-time (JIT) elevation shrinks the window in which stealing that credential is worth anything. JIT is not a product. It is five requirements, and you can meet them at very different price points:

1. Separation. Privileged work happens under a distinct administrative identity that does not read email, browse the web, or hold a mailbox. The daily-driver account never holds a privileged role.
2. Eligibility, not assignment. A person is eligible for a role; they hold it only after activating it. The default state of the directory shows zero active privileged assignments.
3. Time-bounding. Activation grants the role for a defined window and expires automatically without anyone remembering to remove it.
4. Justification and approval. Activation requires a stated reason, and for the highest tiers, a second person's approval. Approval by the requester's own manager who is asleep is not approval; name a role that is actually reachable.
5. An audit record that survives the incident. Who activated what, when, why, approved by whom, and what they did during the window — retained past your log-retention floor (Section 5).

That warning is the single most under-appreciated fact about JIT, and it is why Section 10 exists.

The cheap version for an organization that cannot buy a PAM platform. You can get most of the value with things you already own:

• Separate admin accounts for every person who administers anything, with different credentials and phishing-resistant MFA. Free, and it is the largest single reduction in blast radius available to a small org.
• Empty the standing groups. Domain Admins, Global Administrator, AWS organization management admin: get them to zero permanent members plus your break-glass accounts. If your identity platform includes eligible-role activation in a tier you already pay for, use it. If it does not, keep the group empty and put membership behind a documented, logged manual step.
• A privileged-access log as a spreadsheet. Date, account, role, business reason, approver, start time, end time. It is not elegant. It produces exactly the evidence an auditor asks for and exactly the timeline an incident responder needs, and it costs nothing but discipline.
• Alert on the elevation itself. A directory role assignment or an AWS AddUserToGroup / PutUserPolicy event outside a recorded activation window is one of the highest-signal, lowest-noise detections you will ever write. GuardDuty ships PrivilegeEscalation:IAMUser/AnomalousBehavior for exactly this class, covering AssociateIamInstanceProfile, AddUserToGroup and PutUserPolicy (GuardDuty IAM finding types).
• Admin work from a dedicated browser profile or workstation. Not a full privileged access workstation program — one hardened profile that does not carry the user's general browsing session.

Actionable takeaway: Get the standing membership of your three most powerful groups to zero this quarter, and pair every de-elevation step in your runbooks with an explicit session revocation, because group changes alone are not fast enough to contain anything.

#4. ITDR: watching the identity plane like it is a network

Identity threat detection and response is the discipline of treating your identity provider as a monitored system rather than an assumed-good utility. Chapter 9 owns detection engineering as a practice — the Sigma format, the ADS documentation standard, coverage measurement. This section owns what specifically to watch in identity, and where the data actually lives.

#The detections that earn their place

Two ML caveats you must build into expectations. First, GuardDuty documents that if it observes continued activity from a remote host, its model will learn the behavior as expected and stop generating the finding — so persistent exfiltration goes quiet in the console. Do not treat finding volume as a proxy for activity (GuardDuty IAM finding types). Second, Confirm-MgRiskyUserCompromised is not a cosmetic label — it raises the user to high risk, which is a Continuous Access Evaluation critical event and feeds the risk model (Entra ID Protection and Graph PowerShell).

Working the risky-user queue from PowerShell, with the scopes Microsoft documents — and then the queue almost nobody works, the risky workload identities. Entra ID Protection scores service principals as well as people, for leaked credentials, anomalous service-principal sign-ins and suspicious API traffic. Nobody gets an MFA prompt on that population, so risk scoring is most of the detection you have.

# Requires Security Administrator plus delegated IdentityRiskEvent.Read.All and
# IdentityRiskyUser.ReadWrite.All. Returns risk detections and current risky users.
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All","IdentityRiskyUser.ReadWrite.All"

Get-MgRiskDetection -Filter "RiskType eq 'anonymizedIPAddress'" |
  Format-Table UserDisplayName, RiskType, RiskLevel, DetectedDateTime

Get-MgRiskyUser -Filter "RiskLevel eq 'high'" |
  Format-Table UserDisplayName, RiskDetail, RiskLevel, RiskLastUpdatedDateTime

# Confirm compromise. This raises the user to high risk and is a CAE critical event.
Confirm-MgRiskyUserCompromised -UserIds "<id1>","<id2>"

# Risky workload identities. Needs the additional delegated scope
# IdentityRiskyServicePrincipal.Read.All (ReadWrite to dismiss or confirm),
# and workload identity risk is a separately licensed Entra capability —
# confirm your tenant carries it before you depend on this queue.
Connect-MgGraph -Scopes "IdentityRiskyServicePrincipal.Read.All"

Get-MgRiskyServicePrincipal -Filter "RiskLevel eq 'high'" |
  Format-Table DisplayName, AppId, RiskLevel, RiskDetail, RiskLastUpdatedDateTime

Work that second queue on the same cadence as the risky-user queue. A high-risk service principal has no help desk to call and no human to notice a strange prompt; if you are not reading the list, nobody is.

#The retention reality — check this before you need it

You cannot detect or investigate in a window you did not retain. These are the numbers, and they are unforgiving.

Sources: Microsoft Entra data retention, Manage audit log retention policies, Google Workspace data retention and lag times, CloudTrail concepts, Cloud Logging retention.

Three sentences that belong on a wall somewhere. Microsoft: "Log retention changes aren't retroactive. When you upgrade from Free to P1 or P2, only data still within the free retention period (up to seven days) is available. Data that has already expired can't be recovered unless it was previously archived." Google: "Administrators cannot delete log event data or change the length of time that the data is available" — good for evidence integrity, unhelpful if you need more than six months. And AWS: "By default, trails and event data stores log management events, but not data or Insights events."

Two lag figures will produce false negatives in a rushed investigation if you do not know them. Purview Audit search: "It can take from 30 minutes up to 24 hours for the corresponding audit log entry to be displayed in the search results after an event occurs" (Detect and remediate illicit consent grants). Google Workspace OAuth Token log events lag by a couple of hours. A consent-grant hunt run five minutes after the grant will come back clean, and clean will be wrong.

Actionable takeaway: Today, check what your identity logs actually retain and route them to storage that outlives your median dwell time. Retention is the only security control that you cannot apply retroactively.

#5. Machine and non-human identity

This is the fastest-growing identity population in every environment I have looked at, and most organizations cannot produce a count. Chapter 6 owns cloud workload architecture and Chapter 11 owns third-party SaaS integrations; this section owns the identity-plane question — how many non-human principals exist, who owns them, and how you kill one.

Two 2026 incidents make the case better than any statistic. In May 2026, Sysdig observed an LLM-driven actor that, after an initial exploit, replayed a projected Kubernetes service-account token to dump the cluster Secret store — database credentials, AWS keys, API keys. The agent needed no additional exploit; it used the access its runtime already carried (Sysdig). In March 2026, TeamPCP backdoored a GitHub Action; LiteLLM's CI auto-installed the poisoned tool, which stole LiteLLM's PyPI publishing tokens, and malicious wheels shipped to users days later (Resecurity; LiteLLM security update). Both are pure non-human identity events. No human credential was involved at any point, so no password reset and no MFA policy would have touched either one.

Mandiant's list of how threat actors bypass MFA is, essentially, a list of non-human identities: harvesting long-lived OAuth tokens, stealing session cookies, compromising third-party SaaS vendors, and stealing hard-coded keys and personal access tokens (M-Trends 2026).

#The five populations, and how each one actually dies

The GCP trap is the one that catches experienced people. Google documents it directly: "Disabling a service account key does not revoke short-lived credentials that were issued based on the key." The documented remedy is to disable or delete the service account itself, which immediately stops any workload using it (Disable and enable service account keys).

# Disable a specific service account key. This does NOT revoke short-lived
# credentials already minted from it — the service account itself must be
# disabled or deleted for that.
gcloud iam service-accounts keys disable KEY_ID \
    --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --project=PROJECT_ID

Kubernetes has the cleanest revocation semantics of any platform, because modern tokens are bound to an API object. If the referenced object is deleted or does not exist, or its metadata.uid does not match, "authentication with that token fails immediately"; for objects pending deletion with finalizers, tokens fail 60 seconds after deletionTimestamp (Managing Service Accounts).

# Kill every token for a service account. Deleting the SA does NOT remove the
# RoleBindings/ClusterRoleBindings — strip those too, or a recreated SA of the
# same name inherits the grant.
kubectl delete serviceaccount <sa> -n <ns>

# Mint a deliberately scoped, bound token instead of a long-lived one.
kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"

#Secrets management, and the credential store nobody inventories

The Salesloft Drift compromise remains the best teaching case for standing tokens: attackers stole the OAuth refresh tokens customers had issued to Drift and over ten days exported records from 700+ organizations. The highest-value loss was secondary — API keys, Snowflake tokens, cloud credentials and passwords that customers had pasted into support-case text (AppOmni; Cloud Security Alliance).

Treat support tickets, chat transcripts and wiki pages as a credential store, because that is empirically what they are. Scan them. Rotate what you find. Then fix the process that put it there.

The cheap version. A managed secrets vault is the right answer and it costs money. If you cannot buy one yet: (1) turn on secret scanning in your source control — most platforms include it at no cost; (2) replace static CI credentials with short-lived OIDC federation, which is a configuration change rather than a purchase; (3) pin third-party CI actions by commit SHA rather than by tag, which is free and would have blunted the Trivy-to-LiteLLM chain; (4) maintain one spreadsheet of every long-lived key with owner, system, creation date and last-rotated date, and rotate anything over a year old. Not glamorous. Effective.

Actionable takeaway: Produce a non-human identity inventory with a named human owner for every entry, and add a "who owns this and how do I revoke it in one command" column. An unowned service principal is a backdoor that passed a change-approval board.

#6. AI agent identity

The map has a node for it because 2026 demands one. An autonomous agent that acts inside your environment is a principal. If you have not decided what kind of principal it is, you have decided by default — and the default is almost always "it borrows a human's token," which is a confused-deputy problem with a launch date.

Here is the failure mode in one sentence. The agent has more context than the human who invoked it, acts faster than the human can supervise, and carries the human's full authority — so when untrusted content reaches it, the content is executing with your privileges under your name in your audit log. OWASP's Top 10 for Agentic Applications 2026 names the categories directly: ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse (OWASP GenAI). The structural cause, which Chapter 7 develops fully, is that LLMs process instructions and data on the same channel — there is no reliable in-band separation between content and command, so every model-adjacent data source is untrusted input to a privileged executor.

The Sysdig case is the confused-deputy pattern already in production: the agent inherited a service-account token from a mounted projected volume and replayed it. And the Nx "s1ngularity" campaign of August 2025 is the inverse — malicious package versions detected developer AI CLIs on the machine and invoked them with permission-bypassing flags to enumerate secrets across the filesystem, harvesting 2,349 credentials from 1,079 developer systems (The Hacker News; GitGuardian). An agent that will do anything you ask is an agent that will do anything anyone asks.

Four requirements, and they map to the same primitives as every other identity in this chapter:

Add two operational rules. First, short-lived credentials only — an agent that runs for four minutes should not hold a credential that lives for twelve hours. Second, the lethal trifecta: private data access plus untrusted content plus external communication in one agent is the combination that turns prompt injection into exfiltration (Simon Willison; Microsoft, "The state of MCP security in 2026"). Break one leg of it — usually the external communication, by allowlisting egress — and the class of attack collapses.

The cheap version. You do not need an agent-identity platform. You need a register: one row per deployed agent, with its identity, its scopes, its owner, its revocation command, and the date someone last looked at it. If an agent is not in the register, it does not get production credentials.

Actionable takeaway: Ban human-token impersonation for agents in policy this quarter, and give every deployed agent its own scoped, short-lived, revocable identity — then test the revocation command and record how long it took.

#7. Break-glass: the accounts that save you when the identity provider is the incident

Every control in this chapter assumes your identity provider is working and trustworthy. Break-glass is the procedure for the day it is neither.

The requirements are not negotiable and they are not expensive:

Microsoft's guidance is explicit on requirement 2: exclude break-glass and emergency-access accounts from every Conditional Access policy, including Microsoft-managed ones, and use report-only mode before enforcing any new policy (Conditional Access — Block access; Microsoft-managed CA policies).

Extend the same logic to the systems you will need during an identity compromise. The clearest documented statement of the principle comes from backup architecture: the repository is a separate trust domain whose credentials never live in the backup control plane, so compromising the backup server does not compromise the backups (Veeam Hardened Repository). Generalized: backup and recovery infrastructure must not authenticate against the identity provider you are trying to recover. If the backup console uses tenant SSO and the tenant is compromised, you cannot log in to restore. Chapter 12 develops this; the identity-side rule is dedicated non-SSO emergency credentials for backup and recovery systems, stored offline, with MFA that does not depend on the production identity provider.

Actionable takeaway: Schedule the break-glass test as a recurring calendar item with a named owner, and treat a failed or unalerted test as a SEV-3 incident with an after-action item, not as a chore to reschedule.

#8. Help-desk verification: closing the Scattered Spider path

CISA's advisory describes the technique precisely: research employees on business platforms and social media, then call the IT help desk posing as them to obtain password resets and MFA token transfers to attacker-controlled devices, often splitting the request across separate contacts to evade detection (CISA AA23-320A). Vishing is now the number two initial infection vector globally, at 11% of Mandiant investigations (M-Trends 2026).

And the caller now sounds exactly right. In the Arup case, an employee's justified scepticism about a phishing email was overcome by a multi-person video conference in which every other participant was AI-generated, resulting in approximately US$25.6 million lost across 15 wire transfers in a single day (CNN).

Look at what stopped the attacks that were stopped. Ferrari: an executive challenged a CEO voice clone with a shared-secret question — a recently recommended book — that the clone could not answer (AI Incident Database). LastPass: an employee flagged the channel anomaly, calls and WhatsApp voicemail from a supposed CEO, rather than detecting the fake (Adaptive Security). WPP: employee vigilance against a Teams meeting using a voice clone and public footage (OECD AI Incidents). All three were stopped by a human process check, not by detection technology. Encode the process check.

#The verification script

This is written to be read aloud by an agent under time pressure. It contains no jokes for the same reason a fire door contains no window.

Applies to: any inbound request for a password reset, MFA method addition or reset, MFA device transfer, account unlock, or contact-detail change on an account.

Two supporting controls make the script survivable. First, an agent must never be penalized for a refusal that turns out to be a legitimate user. If your service-desk metrics punish handle time, the script loses to the metric every single time. Fix the metric. Second, you need a tenant-wide MFA re-enrolment freeze as a named, pre-authorized capability — a switch the Incident Commander can throw that stops all help-desk-initiated MFA enrolment while an identity incident is live. Write it, test it, and know who can authorize it before you need it at 3am.

Actionable takeaway: Put the verification script on the wall behind the service desk this week, remove handle-time penalties for refusals, and run one unannounced test call per month against your own agents.

#9. OAuth consent and app-consent abuse

This is the persistence mechanism that survives everything you would normally do. Microsoft, again, in the plainest possible terms: "Normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack, because these apps are external to the organization" (Detect and remediate illicit consent grants).

The FBI's IC3 issued PSA260901 in September 2026 describing an active campaign running since late 2025: actors register malicious applications with legitimate OAuth providers, named to resemble file-storage or identity-verification services, then contact targets impersonating journalists, academics or event organisers and induce them to approve permissions through a genuine Microsoft or Google consent screen. The result is persistent read and send mail access plus file access, without the password — and changing the password does not revoke it (Help Net Security reporting IC3 PSA260901).

The enterprise-scale version was the 2025 Salesforce vishing campaign, in which attackers posing as internal IT induced employees to authorize a malicious Connected App granting OAuth access — with no platform vulnerability involved at any point, and roughly 91 claimed victim organizations (Krebs on Security; ReliaQuest).

#Prevention

Turn off end-user consent for applications, or restrict it to a vetted, low-risk permission set with an admin-consent request workflow. Microsoft explicitly recommends against the blunt instrument of turning off integrated applications tenant-wide — so do the surgical version: restrict, review, approve.

#Detection

# Tenant-wide inventory of delegated and application permissions, using
# Microsoft's documented method. Triage the CSV on ConsentType = AllPrincipals
# (the app can reach everyone's content in the tenant), on Permission values
# containing Write or .All, and on unfamiliar ClientDisplayName values.
.\Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

One prerequisite, because that leading .\ quietly assumes a file that is not there. Get-AzureADPSPermissions.ps1 is a community script that Microsoft links to from its illicit-consent-grant page — it is not a cmdlet, not part of any module, and not present on any machine by default. Download it, read it, and stage it in your responder toolkit now, while nothing is on fire. Pulling an unreviewed script off the internet and running it against your tenant mid-incident is not a plan; it is a second incident.

In Purview Audit, search the activity Consent to application and inspect each record for IsAdminConsent: True, which indicates someone with Global Administrator access granted broad tenant-wide access. Remember the 30-minute-to-24-hour indexing lag before you declare the tenant clean.

At scale, Defender XDR advanced hunting exposes the CloudAppEvents table with an OAuthAppId column plus ActionType, AccountObjectId, IPAddress, UserAgent, IsAdminOperation, and the two anomaly-scoring columns LastSeenForUser and UncommonForUser. Critical caveat: the table is populated only if Defender for Cloud Apps is deployed and the Microsoft 365 activities connector is enabled — queries silently return nothing otherwise (CloudAppEvents table). An empty result is not evidence of absence; verify the connector first.

In Google Workspace, OAuth Token audit logs record "each time a third-party application is authorized to access Google Account data," queryable via Activities.list() with applicationName=token (OAuth log events). Retention is six months; lag is a couple of hours.

#Remediation

# Revoke a delegated consent grant.
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId <id>

# Revoke an application-permission role assignment on a service principal.
Remove-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId <sp-id> -AppRoleAssignmentId <assignment-id>

# Google Workspace: revoke one application's token for one user.
# Scope: https://www.googleapis.com/auth/admin.directory.user.security
DELETE https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens/{clientId}

Scoping the blast radius afterwards requires mailbox auditing and admin/user activity auditing to have been enabled before the attack. Microsoft flags this explicitly, and it is the same retroactivity problem as Section 4: you cannot buy the past.

Actionable takeaway: Restrict end-user OAuth consent this quarter, run the tenant-wide permission inventory monthly, and add "enumerate and revoke OAuth grants" as an explicit branch of every identity containment runbook you own.

#10. The containment sequence: revoke tokens before you reset the password

This is the most important operational detail in the chapter. Chapter 14.3 (SaaS and Cloud Account Takeover) and Chapter 14.4 (Identity Provider and Privileged Credential Compromise) are the full incident playbooks. This section is the control-design version: the order, the reason, and the verified commands.

#Why the wrong order fails

A refresh token is an independent bearer credential. It does not care about your password. In Entra ID, a password change is a Continuous Access Evaluation critical event — but CAE reaches only CAE-capable resource providers (Exchange Online, SharePoint Online, Teams, Graph), only after up to 15 minutes of propagation, never for guest accounts, and never for an application's own session cookie or a consented OAuth grant (Continuous access evaluation).

So a reset-only response leaves you with:

1. Access tokens valid until expiry. In CAE sessions, token lifetime increases to long-lived, up to 28 hours, and Configurable Token Lifetime is not honoured for CAE-aware clients.
2. Application-issued session tokens valid until the application expires them. Microsoft: "Microsoft Entra ID can't directly revoke a session token issued by an application" (Revoke user access in an emergency).
3. OAuth grants valid indefinitely, per Section 9.
4. A locked-out user calling the help desk — which tips off the adversary while leaving them logged in.

That is the entire argument. Revocation is the control that matters; expiry is not.

The same asymmetry exists in AWS, expressed differently: "Temporary security credentials are valid until they expire… You can revoke these credentials, but you must also change permissions for the IAM user or role" (Disabling permissions for temporary security credentials). Session duration runs 900 seconds to 36 hours, defaulting to 12. Revoking sessions without changing permissions means the attacker re-assumes the role thirty-one seconds later.

And in Google Workspace: signOut resets sign-in cookies but does not revoke a third-party OAuth grant — the app keeps working. Both calls are needed.

#Why you do not disable first

Disabling is loud, immediate, and irreversible in its effect on your telemetry. It is the moment the adversary learns they are detected — and the moment you stop generating the sign-in logs, mail-access records and API events you were about to use to find their other footholds. In Entra specifically, re-enabling a disabled user has a documented 15-minute lag for SharePoint and Teams and 35 to 40 minutes for Exchange Online, so a premature disable you have to undo costs you most of an hour (Continuous access evaluation).

The sequence below is a synthesis built on those vendor facts, not a vendor statement. Microsoft's own documented per-user emergency order is: disable account → revoke sign-in session → disable registered devices, with the on-premises AD steps first in a hybrid environment. Use Microsoft's order when you already know the scope and want the account gone. Use the sequence below when you are still learning what the adversary touched.

#The ordered containment table

#Verified commands by platform

Microsoft Entra ID / Microsoft 365 — hybrid on-premises steps first. Microsoft's stated reason for the double reset is "to mitigate the risk of pass-the-hash, especially if there are delays in on-premises password replication" (Revoke user access in an emergency).

# On-premises Active Directory (hybrid environments only).
# Disable, then reset the password TWICE to clear the hash history.
Disable-ADAccount -Identity johndoe
Set-ADAccountPassword -Identity johndoe -Reset `
  -NewPassword (ConvertTo-SecureString -AsPlainText "<random1>" -Force)
Set-ADAccountPassword -Identity johndoe -Reset `
  -NewPassword (ConvertTo-SecureString -AsPlainText "<random2>" -Force)

# Entra ID. Requires User Administrator for standard accounts and
# Privileged Authentication Administrator for admin accounts.
# Revoke-MgUserSignInSession invalidates refresh tokens and browser session
# cookies by resetting signInSessionsValidFromDateTime.
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'[email protected]' -ConsistencyLevel eventual

Revoke-MgUserSignInSession -UserId $User.Id
Update-MgUser -UserId $User.Id -AccountEnabled:$false

# Disable the user's registered devices. Requires Cloud Device Administrator.
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
    Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

These next cmdlets are not Microsoft Graph. Get-InboxRule, Get-Mailbox, Set-Mailbox and Search-UnifiedAuditLog are Exchange Online PowerShell cmdlets: they come from the ExchangeOnlineManagement module and need their own Connect-ExchangeOnline session, separate from the Connect-MgGraph session above, and audit search additionally requires an Exchange Online audit-log role assignment. Discovering that at 03:00, via "the term Get-InboxRule is not recognized," is a bad use of an hour. Install the module and prove the connection works in peacetime.

# Exchange Online PowerShell — a separate module and a separate session from
# Connect-MgGraph. Audit search also requires an Exchange Online audit-log role.
# Install-Module ExchangeOnlineManagement   # once, in peacetime
Connect-ExchangeOnline -UserPrincipalName <admin-upn>

# Check for attacker-created mail persistence. Microsoft's named operations are
# exactly three. Mailbox-level forwarding does NOT appear in Get-InboxRule
# output and must be checked separately with Get-Mailbox.
Get-InboxRule -Mailbox <mailbox> | FL Name,Description,DeleteMessage,MoveToFolder,Enabled

# Re-run this call with the SAME SessionId until it returns zero rows.
Search-UnifiedAuditLog -StartDate <start> -EndDate <end> -UserIds <user1,user2> `
  -Operations New-InboxRule,Set-InboxRule,Remove-InboxRule `
  -SessionCommand ReturnLargeSet -SessionId <id> -ResultSize 1000

Do not drop -SessionCommand. Without it the cmdlet returns a maximum of 100 records no matter what you put in -ResultSize, and a truncated result in an investigation reads exactly like a clean one. ReturnLargeSet returns unsorted data in pages and must be re-run with the same SessionId until it yields zero rows; -ResultSize is capped at 5,000 records per call.

AWS. The console's "Revoke active sessions" action attaches an inline policy named AWSRevokeOlderSessions to the role; the required permission is PutRolePolicy. It denies all access to sessions assumed in the past and approximately 30 seconds into the future, to absorb policy-propagation delay (Revoke IAM role temporary security credentials).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}

# Attach the revocation policy programmatically with the timestamp you choose.
aws iam put-role-policy --role-name <role> \
  --policy-name AWSRevokeOlderSessions \
  --policy-document file://revoke.json

# Deactivate a compromised long-term access key. For a COMPROMISED key this
# order is inverted from the normal rotation sequence: deactivate first, then
# create the replacement. Do not delete until you have confirmed nothing broke.
aws iam update-access-key --user-name <user> --access-key-id <AKIA...> --status Inactive

# Attach an SCP from the management account so a member-account admin cannot
# detach it. Target may be a root (r-*), an OU (ou-*), or a 12-digit account ID.
aws organizations attach-policy --policy-id p-examplepolicyid111 \
  --target-id ou-examplerootid111-exampleouid111

Three constraints that break naive AWS playbooks. You cannot revoke the session for a service-linked role. Roles created from IAM Identity Center permission sets cannot be edited in IAM — revoke the active permission set session in Identity Center instead. And if a resource-based policy independently allows the principal, revoking the role session is not sufficient; add an explicit Deny on the resource keyed on aws:PrincipalArn or aws:SourceIdentity. Clients cache credentials, so force a refresh with rm -r ~/.aws/cli/cache.

Google Workspace. Both calls are required — the first kills sessions, the second kills the app grant.

# Sign the user out of all web and device sessions and reset sign-in cookies.
# Scope: https://www.googleapis.com/auth/admin.directory.user.security
POST https://admin.googleapis.com/admin/directory/v1/users/{userKey}/signOut

# Revoke a specific third-party application's OAuth token. signOut alone does
# NOT do this — the app keeps working. Enumerate first with tokens.list.
DELETE https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens/{clientId}

#Domain-wide compromise inverts the order

If you believe krbtgt or a Tier-0 asset is compromised, per-user actions are noise until the domain is dealt with. The krbtgt account is reset twice, because the account has a two-password history, with at least 10 hours between the resets so the first fully replicates — longer if you have modified ticket lifetimes (CISA Eviction Strategies Tool CM0050). Chapter 12 covers identity-first recovery ordering and AD forest recovery in full.

Actionable takeaway: Rewrite every identity runbook you own so that token and session revocation appears before or alongside the credential reset, never after it — and add a verification step that confirms no new tokens were issued. Do it this week. Not next sprint. This week.

#11. Access reviews that produce evidence

An access review that produces a screenshot of someone clicking "approve all" is not a control, it is a rehearsal for an audit finding. A useful review produces three artefacts: a list of what was reviewed, a record of what changed as a result, and a named person who owns the decision.

The mover case is where entitlements quietly accumulate. Someone moves from finance to engineering and keeps both sets of access, and three moves later they can approve a payment, deploy to production and read the HR drive. The reconciliation that catches this is a comparison of role assignments against the HR record of the current job, not against last year's review.

The cheap version. AWS IAM Access Analyzer has unused access analyzers — unused roles, unused access keys, unused passwords, unused services and actions on active principals — and they are not Region-dependent (IAM Access Analyzer). That is your least-privilege lever without buying anything. Access Analyzer's policy generation from CloudTrail activity is also how you rebuild a scoped role after ripping permissions off a compromised one. Pair it with a quarterly export-to-spreadsheet review and you have a defensible program.

Two mechanical details that make reviews stick. Set the default answer to remove, so silence revokes rather than retains — the reviewer has to act to keep access, not to remove it. And review entitlements, not group names: "member of SG-Fin-App-RW" tells a manager nothing, while "can approve payments up to $50,000" tells them everything.

Actionable takeaway: Move privileged access reviews to monthly, set the default outcome to removal, and require that each review produce a dated before-and-after export — because next year the only thing that will exist is the artefact.

#12. Where this connects

Chapter 5 turns the identity decision into a network-level enforcement point. Chapter 6 covers cloud workload identity, IMDS and CIEM. Chapter 7 covers AI governance and the agentic risk categories this chapter only touches. Chapter 9 covers detection engineering and coverage measurement. Chapter 11 covers vendor OAuth integrations as third-party risk. Chapter 12 covers identity-first recovery ordering. Chapters 14.3 and 14.4 are the executable playbooks for account takeover and identity provider compromise. Chapter 20 sequences all of it into a 180-day plan.

If you take one thing from this chapter: identity is the only control domain where the order of your response determines whether it works at all. Everywhere else, doing the right things in the wrong order is inefficient. Here, it is the difference between evicting an adversary and announcing yourself to one who is still holding a valid token.

Stay enrolled, stay revoked, and never reset a password before you have killed the session.

#Chapter checklist

• IAM-01A complete inventory of identities exists — human and non-human — with a named owner for every entry, refreshed at least quarterly. [IG1] [PR.AA] [CIS 5]
• IAM-02Phishing-resistant MFA (FIDO2/WebAuthn or PKI) is enforced for every account holding a privileged role on every platform, with no exception group. [IG1] [PR.AA] [CIS 6]
• IAM-03Push, SMS and voice are removed as registered authentication methods on all privileged accounts, not merely deprioritized. [IG2] [PR.AA] [CIS 6]
• IAM-04Privileged accounts require attested, device-bound authenticators; synced passkeys are not accepted for privileged roles. [IG3] [PR.AA]
• IAM-05Every system reachable from the internet — VPN, firewall management, hypervisor console, backup portal, legacy applications — either federates to the identity provider or carries a documented exception with a named approver and an expiry date. [IG1] [PR.AA] [CIS 6]
• IAM-06Standing membership of the highest-privilege groups on each platform is zero, excluding break-glass accounts; privileged roles are activated just-in-time with justification, time-bounding and an audit record. [IG2] [PR.AA] [CIS 5]
• IAM-07Administrators use separate administrative identities that hold no mailbox and are not used for email or general web browsing. [IG1] [PR.AA] [CIS 5]
• IAM-08Every de-elevation step in every runbook is paired with an explicit session revocation, because group-membership changes can take up to a day to reach resource providers. [IG2] [RS.MI]
• IAM-09Identity logs — sign-in, audit, OAuth token and cloud control-plane — are routed to storage whose retention exceeds the organization's median dwell-time assumption, and the configuration date is recorded. [IG1] [DE.CM] [CIS 8] [A.8.15]
• IAM-10Named detections exist and are enabled for: high-risk sign-in, MFA method change, admin consent grant, new inbox rule or forwarding address, privileged role assignment outside a JIT window, and cloud credential use from outside the environment. [IG2] [DE.CM] [A.8.16]
• IAM-11Every non-human identity — service principal, workload identity, API key, CI publishing token, Kubernetes service-account token — has a named human owner and a documented single-command revocation procedure. [IG2] [PR.AA] [CIS 5]
• IAM-12CI/CD pipelines use short-lived federated credentials rather than long-lived static secrets, and third-party actions are pinned by commit SHA. [IG2] [PR.AA]
• IAM-13Secret scanning is enabled on source control, ticketing systems and wikis, and findings are rotated rather than only deleted. [IG1] [PR.AA] [CIS 3]
• IAM-14Every deployed AI agent holds its own scoped, short-lived workload identity and never authenticates using a human user's token, session cookie or personal access token. [IG2] [PR.AA]
• IAM-15An agent register exists listing every deployed agent with its identity, scopes, owner, revocation command and last review date; the revocation command has been tested. [IG2] [ID.AM] [PR.AA]
• IAM-16At least two cloud-only break-glass accounts exist, are excluded from every Conditional Access policy including vendor-managed policies, are excluded from automated lifecycle jobs, and have credentials split under physical dual control. [IG1] [PR.AA]
• IAM-17Any authentication attempt against a break-glass account alerts the SOC and a named executive, and the break-glass procedure is tested at least twice a year — the IG1 floor, raised to quarterly at IG2 by EX-15 in Chapter 18 — with the test and the alert both logged. [IG1] [DE.CM] [PR.AA]
• IAM-18Backup and recovery consoles authenticate with dedicated non-SSO emergency credentials that do not depend on the production identity provider, and a restore has been tested using only those credentials. [IG2] [PR.AA] [RC.RP]
• IAM-19A written help-desk verification script governs all password reset, MFA reset, MFA device transfer and contact-change requests, requiring out-of-band callback to the number of record and a second identity factor. [IG1] [PR.AA] [PR.AT]
• IAM-20Help-desk agents face no handle-time or satisfaction penalty for refusing an unverifiable request, and unannounced test calls are run at least monthly. [IG2] [PR.AT]
• IAM-21A tenant-wide MFA re-enrolment freeze is documented, pre-authorized to a named role, and has been tested. [IG3] [RS.MI]
• IAM-22End-user OAuth consent is restricted or disabled, and a tenant-wide inventory of delegated and application permissions is reviewed monthly with attention to AllPrincipals grants; any community script or module the inventory depends on is downloaded, reviewed and staged in the responder toolkit in peacetime, along with the ExchangeOnlineManagement module and a tested Connect-ExchangeOnline path. [IG2] [PR.AA] [CIS 6]
• IAM-23Every identity containment runbook places token and session revocation before or alongside the credential reset, includes an OAuth-grant revocation branch, includes a non-human identity branch, and ends with an observation-based verification step. [IG1] [RS.MI]
• IAM-24Privileged access reviews run monthly and general access reviews quarterly, each producing a dated before-and-after entitlement export, a list of removals, and a named accountable reviewer. [IG1] [PR.AA] [CIS 5] [CIS 6]
• IAM-25Joiner/mover/leaver reconciliation runs monthly against HR records, and the exception list — directory accounts with no HR record, and the reverse — is worked to zero. [IG2] [PR.AA] [CIS 5]
• IAM-26The risky workload-identity queue — risky service principals and their leaked-credential, anomalous-sign-in and suspicious-API-traffic detections — is worked on the same cadence as the risky-user queue, with a named owner and a record of each disposition. [IG2] [DE.CM] [PR.AA]

#Sources

1. Sophos, State of Ransomware 2026 — https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026
2. CrowdStrike, 2026 Global Threat Report findings — https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
3. Microsoft, Digital Defense Report 2025 — https://www.microsoft.com/en-us/corporate-responsibility/topics/cybersecurity/reports/microsoft-digital-defense-report-2025/
4. SecurityWeek, Verizon DBIR 2026: vulnerability exploitation overtakes credential theft — https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
5. Google Cloud / Mandiant, M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
6. Microsoft, Detect and remediate illicit consent grants — https://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-illicit-consent-grants
7. CISA/FBI, AA23-320A — Scattered Spider — https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
8. CISA, Phishing-Resistant MFA success story (USDA FIDO) — https://www.cisa.gov/resources-tools/resources/phishing-resistant-multi-factor-authentication-mfa-success-story-usdas-fast-identity-online-fido
9. Group-IB, Tycoon 2FA — https://www.group-ib.com/masked-actors/tycoon2fa/
10. Proofpoint, Tycoon 2FA phishing kit MFA bypass — https://www.proofpoint.com/us/blog/email-and-cloud-threats/tycoon-2fa-phishing-kit-mfa-bypass
11. Microsoft, Continuous access evaluation — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
12. Microsoft, Revoke user access in an emergency — https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
13. Microsoft, Conditional Access — Block access — https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-example
14. Microsoft, Microsoft-managed Conditional Access policies — https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies
15. Microsoft, Microsoft Entra data retention — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
16. Microsoft, Manage audit log retention policies (Purview) — https://learn.microsoft.com/en-us/purview/audit-log-retention-policies
17. Microsoft, Microsoft Graph PowerShell SDK and Entra ID Protection — https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-graph-api
18. Microsoft, Identify who modified mailbox rules — https://learn.microsoft.com/en-us/purview/audit-log-identify-mailbox-rules
19. Microsoft, CloudAppEvents table (Defender XDR advanced hunting) — https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-cloudappevents-table
20. AWS, GuardDuty IAM finding types — https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html
21. AWS, Revoke IAM role temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html
22. AWS, Disabling permissions for temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html
23. AWS, CloudTrail concepts — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html
24. AWS, IAM Access Analyzer — https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
25. AWS CLI, delete-open-id-connect-provider — https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html
26. AWS, Organizations attach-policy reference — https://docs.aws.amazon.com/cli/latest/reference/organizations/attach-policy.html
27. Google, Workspace data retention and lag times — https://knowledge.workspace.google.com/admin/reports/data-retention-and-lag-times
28. Google, Directory API users.signOut — https://developers.google.com/workspace/admin/directory/reference/rest/v1/users/signOut
29. Google, Directory API tokens.delete — https://developers.google.com/workspace/admin/directory/v1/reference/tokens/delete
30. Google, OAuth log events — https://support.google.com/a/answer/6124308
31. Google, Disable and enable service account keys — https://docs.cloud.google.com/iam/docs/keys-disable-enable
32. Google, Cloud Logging retention — https://cloud.google.com/logging/docs/buckets
33. Kubernetes, Managing Service Accounts — https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/
34. CISA, Eviction Strategies Tool CM0050 (krbtgt reset) — https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0050
35. Sysdig, Agentic threat actor hits the orchestration plane — https://webflow.sysdig.com/blog/agentic-threat-actor-hits-the-orchestration-plane-ai-agent-driven-container-escape
36. Resecurity, The LiteLLM supply chain attack (TeamPCP / SANDCLOCK) — https://www.resecurity.com/blog/article/the-litellm-supply-chain-attack-teampcp-sandclock-cicd-credential-harvesting-campaign-via-a-backdoored-trivy-github-action
37. LiteLLM, Security update, March 2026 — https://docs.litellm.ai/blog/security-update-march-2026
38. The Hacker News, Malicious Nx packages in "s1ngularity" attack — https://thehackernews.com/2025/08/malicious-nx-packages-in-s1ngularity.html
39. GitGuardian, The Nx s1ngularity attack — inside the credential leak — https://blog.gitguardian.com/the-nx-s1ngularity-attack-inside-the-credential-leak/
40. AppOmni, Drift breach, Salesforce, UNC6395 — https://appomni.com/blog/drift-breach-salesforce-unc6395-saas-prevention/
41. Cloud Security Alliance, The Salesloft Drift OAuth supply chain attack — https://cloudsecurityalliance.org/blog/2025/09/25/the-salesloft-drift-oauth-supply-chain-attack-cross-industry-lessons-in-third-party-access-visibility
42. Help Net Security, FBI warns of OAuth consent phishing (IC3 PSA260901) — https://www.helpnetsecurity.com/2026/09/02/oauth-consent-phishing-fbi-warning/
43. Krebs on Security, ShinyHunters wage broad corporate extortion spree — https://krebsonsecurity.com/2025/10/shinyhunters-wage-broad-corporate-extortion-spree/
44. ReliaQuest, Threat spotlight — ShinyHunters, Salesforce, Scattered Spider — https://reliaquest.com/blog/threat-spotlight-shinyhunters-data-breach-targets-salesforce-amid-scattered-spider-collaboration/
45. OWASP GenAI, Top 10 for Agentic Applications 2026 — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
46. Simon Willison, MCP prompt injection — https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
47. Microsoft, The state of MCP security in 2026 — https://techcommunity.microsoft.com/blog/microsoft-security-blog/the-state-of-mcp-security-in-2026/4531327
48. CNN, Arup deepfake scam — https://www.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
49. AI Incident Database, Ferrari voice-clone attempt — https://incidentdatabase.ai/cite/966/
50. OECD AI Incidents, WPP CEO deepfake attempt — https://oecd.ai/en/incidents/2024-05-10-e24d
51. Adaptive Security, Deepfake attack examples (LastPass case) — https://www.adaptivesecurity.com/blog/11-deepfake-attack-examples-2026
52. Veeam, Hardened Repository user guide — https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html
53. CIS, Controls v8.1 — https://www.cisecurity.org/controls/v8-1
54. CIS, Implementation Groups — https://www.cisecurity.org/controls/implementation-groups

#Chapter 5 — Zero Trust Architecture

How to build an access architecture where every request is verified regardless of network location, score yourself honestly against CISA's maturity model, and turn "isolate that host" into a policy change instead of a desk visit.

Who needs this: CISO, security architect, network and identity engineering, IR leads, cloud platform owners | Read time: 22 min | Maps to: CSF 2.0 PROTECT (PR.AA, PR.IR), DETECT (DE.CM), RESPOND (RS.MI); CIS Controls 1, 4, 6, 12, 13; ISO/IEC 27001:2022 A.8.9, A.8.15, A.8.16

Welcome to the chapter everyone has already bought a product for, cyber-friends. Let's talk about what you actually bought.

Colonial Pipeline was compromised through what its CEO described in Senate testimony as a "legacy virtual private network profile that was not intended to be in use," without MFA (Blount testimony). One forgotten account on one forgotten remote-access path, and the network behind it treated the resulting connection as an insider. Equifax is the same story from the inside: GAO records that the company's databases "were not isolated from each other," letting attackers move well beyond the online dispute portal and exfiltrate data "without triggering an alarm," reaching a database holding unencrypted credentials for still more databases (GAO-18-559). Neither is a failure of authentication. Both are failures of what happens after it — the moment a flat network converts one valid session into the run of the estate.

That conversion is faster now. CrowdStrike measured average eCrime breakout time — first foothold to first lateral move — at 29 minutes, fastest observed 27 seconds (CrowdStrike 2026 Global Threat Report). Mandiant puts the median hand-off from initial-access broker to follow-on operator at 22 seconds, down from more than eight hours in 2022 (M-Trends 2026). You will not out-run that with a human on a bridge call. The only thing that keeps up with 22 seconds is architecture that never granted the implicit trust in the first place.

That is what this chapter is about. Not the product. The architecture.

#Zero Trust is an architecture, not a SKU

NIST published SP 800-207, Zero Trust Architecture, as a final document in August 2020, and it remains the conceptual foundation (NIST SP 800-207). Its core assertion is short enough to put on a wall: no implicit trust is granted to assets or accounts based on physical or network location or asset ownership, and protection is oriented around individual resources rather than perimeters. In the document's own words, "authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established."

Read that clause twice, because it is the part vendors skip. Both subject and device. Before a session. Discrete functions. A product that authenticates a user and then hands them a network route has not implemented zero trust; it has implemented a nicer VPN login page.

SP 800-207's logical architecture has three named parts, and naming them in your own environment is more useful than any product evaluation:

The Policy Engine and Policy Administrator together are the Policy Decision Point (PDP). The split matters operationally: a decision made in a place you cannot reach at 03:00 is a decision you cannot change during an incident, and a PEP that keeps honouring a token after the PDP has changed its mind is a control that exists on a slide only.

Draw your own architecture and label every PDP and PEP. Most organizations find the same three things: several PDPs that do not talk to each other, a large population of resources with no PEP at all — anything reachable directly on the LAN — and at least one PEP whose enforcement nobody has ever verified. That is the normal starting position, and it is a better one than a purchase order.

Actionable takeaway: Before you buy anything else, produce a one-page diagram naming every Policy Decision Point and Policy Enforcement Point you operate, and mark in red every resource that has neither. That page is your real baseline, and it costs a whiteboard and an afternoon.

#The CISA maturity model, and scoring yourself in one afternoon

CISA's Zero Trust Maturity Model v2.0, published April 2023, is the scoring instrument to use (CISA ZTMM, ZTMM v2.0 PDF). Free, government-published, and specific enough to argue about — which is what you want in a scoring instrument.

Five pillars:

1. Identity
2. Devices
3. Networks
4. Applications and Workloads
5. Data

Three cross-cutting capabilities, applied across all five pillars: Visibility and Analytics, Automation and Orchestration, Governance.

Four maturity stages:

Two things CISA is explicit about that most summaries drop. Each pillar can progress at its own pace — a mature Identity pillar beside a Traditional Networks pillar is a legitimate state, not a failure. And reaching Optimal requires cross-pillar coordination, so pillar-by-pillar progress eventually stalls without it. Translation for the budget conversation: you can buy five best-of-breed pillar products over three years and still sit at Advanced, because the thing you did not buy is the integration.

If you sell to the defense industrial base, note the parallel instrument. The DoD Zero Trust Strategy (October 2022) uses seven pillars — CISA's five with the two cross-cutting capabilities promoted to full pillars — and sets a Target Level deadline of end of FY2027 (30 September 2027) (DTM 25-003). That date lands on somebody's contract before it lands on yours.

#The afternoon rubric

Score each pillar using the evidence question in the right-hand column. The rule that makes this useful: you may only claim a stage if you can produce the evidence without asking anyone to build a report. If proving it takes a week, you are one stage lower than you think.

Score the three cross-cutting capabilities the same way. They decide whether Advanced ever becomes Optimal.

Actionable takeaway: Book three hours this month with identity, network, endpoint and cloud engineering in one room, score all five pillars and all three cross-cutting capabilities, and write the evidence next to each score. Re-run it every six months and put the scorecards side by side. A maturity model you score once is a poster.

#Every access request verified — what a PDP actually does at 09:00 on a Tuesday

The tenet is easy to say and hard to operationalize: verify every request regardless of network location. A policy decision is a function of signals, and the quality of a zero trust deployment is the quality of the signals its PDP can see. A mid-market organization typically already licenses six: identity and group membership, authentication strength, device compliance from MDM or EDR, identity risk level, named IP location, and its own application tiering. The mistake is treating all six as equally available in an emergency. In Microsoft Entra, Continuous Access Evaluation re-evaluates critical events near real-time and needs no Conditional Access license — it is "available in any tenant" — covering account disable or deletion, password change or reset, MFA enablement, an administrator revoking all refresh tokens, and high user risk. The same document also states that propagation "latency of up to 15 minutes might be observed," that IP locations policy enforcement is instant, that in CAE sessions token lifetime increases to long-lived, up to 28 hours, that CAE does not support guest accounts, and that Conditional Access policy and group-membership changes can take up to one day to reach resource providers — with the documented workaround being explicit session revocation (Continuous access evaluation).

Sit with that for a second: your policy change may take a day to land, but your token may live 28 hours. Those two numbers are the entire reason the containment section of this chapter exists.

The cheap version of a PDP, for an organization with no ZTNA budget: your identity provider is already a policy decision point, and you are probably using about 20% of it. Put every internal web application behind it, add a device-compliance condition on the top five, and require phishing-resistant MFA on privileged roles. Real zero trust progress, zero new spend, two pillars moved.

Two operational rules come straight from Microsoft's own guidance: exclude break-glass and emergency-access accounts from every access policy, including vendor-managed ones, and use report-only mode before you enforce (Conditional Access — block access example, Microsoft-managed policies, Plan your Conditional Access deployment). Break-glass exclusions belong to Chapter 4, but they belong here too: the day you write your first tenant-wide block policy is the day you can lock yourself out of your own PDP, and there is no cable to unplug to fix that.

Actionable takeaway: Pick your five most sensitive internal applications this week and put a device-compliance condition on each — report-only first, then enforced, with a date. Five applications, one condition, existing licences, and a measurable move from Initial to Advanced on two pillars.

#Micro-segmentation, and the visibility purgatory that swallows it

Micro-segmentation decides your blast radius. Equifax is what its absence costs; Volt Typhoon is why nation-state advisories keep naming IT/OT segmentation as a top mitigation, after actors sat in critical infrastructure networks with dwell times of at least five years (CISA AA24-038A).

The sequence is not negotiable, and each step fails differently out of order:

1. Identify crown jewels. Named systems, named business owner, named data. If you segment before you know what matters, you will spend your political capital protecting a print server.
2. Get east-west visibility. Flow logs, host firewall logs, or an agent — you need to know what actually talks to what, because the application documentation is wrong and the people who wrote it have left.
3. Enforce. Deny-by-default around one crown-jewel segment, with a documented allow-list, and a date.

Skip step 1 and you enforce in the wrong place. Skip step 2 and you take production down on a Tuesday afternoon and never get permission to try again. Skip step 3 and you have bought a very expensive network map.

Step 3 is where projects die, and the mechanism deserves naming. Segmentation projects stall at the visibility stage forever, because visibility is comfortable: beautiful dashboards, nothing broken, always one more application to map. Nobody has ever been fired for adding another quarter of discovery. The deny rule is the only step that reduces risk and also the only step that can cause an outage, so it never ships.

The cure is a forcing function written in on day one: each crown-jewel segment gets a fixed observation window, and at the end of it the policy goes into enforcement whether or not the map is complete. Ninety days is generous. When the window closes you enforce with the allow-list you have and break the remaining unknowns in a controlled way with the application team on the call — the fastest documentation-generation technique ever invented.

#A segmentation sequence that finishes

Step 6 is not ceremony. In Kubernetes, a NetworkPolicy object is enforced by the CNI — on EKS it requires the VPC CNI network-policy feature or Calico/Cilium, and a cluster without a policy-enforcing CNI will accept the object and enforce nothing. You will have a green tick in your compliance tool and an open network. Verify from inside the pod. Not from the dashboard.

The cheap version, for organizations with no segmentation product: host firewalls plus cloud-native primitives. Default-deny inbound on workstations with named exceptions removes most workstation-to-workstation lateral movement for the price of a group policy. Security groups, NSGs and NetworkPolicy are already paid for — a database whose security group admits only the application tier's security group is micro-segmentation, and it cost nothing.

Actionable takeaway: Pick one crown-jewel system, open a 90-day observation window with the enforcement date written into the change record on day one, and enforce on that date with the allow-list you have. One segment, finished, beats five segments in permanent discovery.

#ZTNA and the end of the flat VPN

The evidence against network-level remote access is overwhelming, and most of it is not vendor marketing.

Vulnerability exploitation reached 31% of breaches in the 2026 DBIR, overtaking credential abuse (13%) for the first time in that report's 19-year history (SecurityWeek on DBIR 2026). Mandiant records exploits as the top initial infection vector at 32% for the sixth consecutive year, with clusters UNC6201 and UNC5807 specializing in edge and core network devices — VPNs and routers (M-Trends 2026). VulnCheck found 23.43% of KEV-listed vulnerabilities had evidence of exploitation on or before the day the CVE was published, and its new-KEV edge-vendor list for 1H-2026 reads like an inventory of most corporate perimeters: Cisco, Palo Alto, Check Point, F5, Juniper, Fortinet, SonicWall, Ubiquiti, TOTOLINK, Tenda, D-Link, Netgear, Linksys (VulnCheck).

The named campaigns make it concrete. ED 25-03 (25 September 2025) covered Cisco ASA/Firepower CVE-2025-20333 and CVE-2025-20362, which chained give full unauthenticated device control — and Cisco confirmed the actor modified ASA ROM to persist across reboot and upgrade (CISA ED 25-03). Ivanti Connect Secure CVE-2025-0282, Fortinet FortiManager CVE-2024-47575 and Microsoft SharePoint CVE-2025-53770 were jointly responsible for 29 of the NCSC's incidents in its 2024/25 reporting year (NCSC Annual Review 2025). And Salt Typhoon — advisory AA25-239A, agencies in 13 countries — reached 600+ organizations across 80 countries largely through known Cisco vulnerabilities in edge routers, then pivoted through trusted connections into other networks (CISA AA25-239A).

"Pivoted through trusted connections" is the phrase that indicts the flat VPN. A classic VPN authenticates a user and then places a device on the network; everything after that is a routing question. Sophos found that although 97% of ransomware victims had some MFA, coverage was inconsistent across VPNs, firewalls and legacy apps, and 79% of those attacks began with an identity-based approach (Sophos State of Ransomware 2026). The gap is always at the seam.

ZTNA changes the unit of access from network to application: the user authenticates to a broker, the broker evaluates identity and device posture per session, and the connection is stitched to one named application through an outbound-initiated connector — so nothing is listening on the internet and a successful authentication yields one application, not a route.

What that buys, stated without marketing:

Now the honest part, because a chapter that sold ZTNA as a perimeter cure would be the vendor whitepaper this book refuses to be: the broker and its connectors are software too, much of it running on or beside the same appliance families in that KEV list. Replacing a concentrator with a cloud broker changes your exposure profile; it does not delete it. Patch the broker on the clock you would patch a VPN, treat any KEV listing against it as an assume-compromise event with credential rotation, and keep it inside Chapter 10's exposure management and Chapter 14's edge-device playbook.

Start with the highest-value, lowest-friction population: third-party and vendor access. Smallest user group, weakest baseline — only 23% of third-party organizations had fully remediated their MFA issues (Help Net Security on DBIR 2026) — and nobody objects to per-application scoping because they never wanted the full network anyway.

Actionable takeaway: Enumerate every internet-reachable remote-access path you operate — VPN concentrators, RDP gateways, Citrix, jump boxes, vendor portals, that one appliance nobody owns — into a single list with owner, MFA status and last-patched date. Any row with "none" in the MFA column is a Colonial Pipeline row. Fix those first, then move vendor access to per-application brokering.

#Zero Trust as a containment lever

This is the payoff, and most zero trust programs never articulate it to their funders. A mature deployment does not only prevent incidents; it changes what containment is. Isolation stops being a physical act — an engineer walking to a desk, a cable pulled, a switch port shut — and becomes a policy change: central, fast, repeatable, logged.

CISA's federal playbooks list, under both eradication and hardening, "tighten perimeter security (e.g., firewall rulesets, boundary router access control lists) and zero trust access rules" (CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks). One line in a federal playbook; here is the operational version.

#The containment lever table

Each of these is a control you have or can build, and each has a documented time-to-effect that belongs in your playbook. Do not write "revoke access" in a runbook. Write which lever, and how long it takes to bite.

Every limit in that table is the vendor's own documented behavior, not a field estimate; the citations are items 12–14 and 17–22 in this chapter's Sources.

#Immediate credential revocation and re-authentication, in the right order

Chapter 4 owns the identity controls and Chapter 14.3 owns the full account-takeover playbook. What belongs here is the architectural sequencing rule, because the wrong order is the most common containment defect I see.

The ordering rule, stated plainly: revoke sessions and reset the credential in the same action, then apply the block policy. Resetting a password before revoking tokens leaves refresh tokens, app-issued sessions and consented OAuth grants alive while alerting the adversary and locking out the legitimate user — a trade in which you give up surprise and gain nothing. Full sequencing, including the non-human identity branch and the OAuth grant removal that a password reset never touches, is in Chapter 14.3.

And the architectural point that makes any of it possible: you can only revoke centrally what was granted centrally. Every application with its own local account, every VPN with its own user database, every appliance with a shared admin password is a place your containment lever does not reach. That is the real return on consolidating access behind a PDP — not elegance, but ending an adversary's access everywhere in one action.

#Measure the lever

Three numbers. Time-to-useless — containment decision to verified inability of the principal to act, where verified means observed (no new tokens, no new sign-ins, no new API calls) rather than assumed. Levers tested this quarter — each row above, with the date it was last fired on a live system and its measured time-to-effect. And for the board, blast radius: the count of identities and network sources that can reach a given crown jewel. That is the number zero trust spend is supposed to move.

Actionable takeaway: Take the containment lever table, fill in your own tools and your own measured time-to-effect for each row, and exercise every lever against a live system at least once a quarter. A containment control you have never fired is a hypothesis. Today. Not after the next incident.

#The roadmap: year one with no new budget, versus what needs money

Two lists. The first has no line item.

#Year one, existing licences and existing people

That moves you from Traditional toward Initial or Advanced on four of five pillars, and every row costs staff time rather than budget. Do it in that order: the crown-jewel list gates everything below it, because without it you will segment and condition the wrong things.

#What genuinely needs investment

Sequence matters here too. Buying the segmentation platform before the crown-jewel list exists leaves you with a license, a consultant and a network map. Buying automation before the containment levers are written and measured automates an unverified procedure at machine speed.

Actionable takeaway: Fund nothing in the second table until the corresponding row in the first is complete. Every purchase should answer a limit you actually hit, and you should be able to state that limit in one sentence.

#Where Zero Trust does not help

Plainly, because a control described as universal is a control nobody can plan around.

It does not stop an unpatched internet-facing appliance from being exploited. KEV remediation is going backwards — only 26% of KEV vulnerabilities were fully remediated by 13,000 polled organizations, down from 38%, with median patching time up to 43 days (Help Net Security on DBIR 2026). Zero trust changes what an attacker reaches after the appliance falls, not whether it falls. Chapter 10.

It does not protect against an authorized user doing authorized things. An insider exfiltrating data they are entitled to read passes every policy check, because every check says yes. Chapters 8 and 9.

It does not make an application safe. A broker will faithfully deliver an authenticated, compliant, low-risk user to a SQL injection vulnerability. Chapters 6 and 14.13.

It does not survive the destruction of your ability to recover. Mandiant's sharpest 2026 finding is the shift to "recovery denial" — operators deliberately targeting backup infrastructure, identity services, virtualization management planes, AD CS certificate templates and hypervisor datastores (M-Trends 2026). Segmentation puts those planes behind their own boundaries; only tested, immutable, out-of-band recovery saves you. Chapter 12.

It does not reach the vendor's copy of your tokens. Third-party involvement appeared in around 48% of breaches, a roughly 60% year-over-year increase (SecurityWeek on DBIR 2026). When a SaaS provider is breached and the attacker replays OAuth tokens you legitimately issued, your policy engine sees a valid grant behaving normally. Chapter 11.

It does not fix legacy OT protocols with no concept of identity. Segmentation and conduit control are the compensating controls, and Volt Typhoon's five-year dwell times say how well they are currently working. Chapter 14.14.

And one that is not technical: it does not survive an organization that will not accept an outage. Enforcement causes breakage. If the answer to every proposed deny rule is "not this quarter," you do not have a zero trust program; you have a zero trust budget.

Actionable takeaway: Write your own version of this list, name the control that owns each gap, and keep it in the same document as your maturity score. A program that cannot state its own limits gets blamed for every incident it was never designed to prevent, and that is how good programs get defunded.

Zero trust is not a place you arrive; it is the removal of one bad assumption — that being inside means being trusted — applied one resource at a time, with a date on each one. Score the pillars, pick a crown jewel, enforce something this quarter, and make sure that when the pager goes off you can end an adversary's access with a policy change rather than a car journey.

Verify everything, segment something, and never trust a network just because it is yours.

#Chapter checklist

• ZT-01A dated Zero Trust target-state document exists, scored against all five CISA ZTMM pillars and all three cross-cutting capabilities, with a current stage, a target stage, a named owner and a target date per pillar. [IG1] [GV.RM] [GV.RR]
• ZT-02A current architecture document names every Policy Decision Point and Policy Enforcement Point in the environment, and explicitly lists resources protected by neither. [IG1] [ID.AM] [CIS 12]
• ZT-03A single list enumerates every internet-reachable remote-access path (VPN, RDP gateway, Citrix, jump host, vendor portal, ZTNA broker) with owner, authentication method and last-patched date, and no entry lists "none" for MFA. [IG1] [PR.AA] [CIS 12]
• ZT-04No remote-access account or profile exists that is not bound to an active directory identity; dormant profiles are disabled within 30 days of last use. [IG1] [PR.AA] [CIS 5]
• ZT-05A crown-jewel register exists listing system, business owner, data classification and dependencies, reviewed at least annually with owner sign-off. [IG1] [ID.AM] [CIS 1]
• ZT-06Break-glass/emergency-access accounts are excluded from every access policy including vendor-managed ones, are alerted on every use, and are tested at least quarterly. [IG1] [PR.AA]
• ZT-07Every new or changed access policy is deployed in report-only (or equivalent audit) mode for a defined period before enforcement, and the report-only evidence is retained with the change record. [IG1] [PR.AA] [A.8.9]
• ZT-08Host-based firewalls are enabled and default-deny inbound on all managed workstations, with a documented, owned and reviewed exception list. [IG1] [PR.IR] [CIS 4]
• ZT-09Every access-policy exclusion group has a named owner and an expiry date, and its membership count is reported at least quarterly. [IG1] [PR.AA] [GV.OV]
• ZT-10Device compliance is an enforced condition of access to at least the top five crown-jewel applications. [IG2] [PR.AA] [CIS 6]
• ZT-11East-west flow logging is enabled for every crown-jewel segment and retained for at least 90 days. [IG2] [DE.CM] [CIS 8] [CIS 13] [A.8.15]
• ZT-12At least one crown-jewel segment is in deny-by-default enforcement — not log-only — with a documented allow-list and a recorded enforcement date, and the next segment has an enforcement date already booked. [IG2] [PR.IR] [CIS 12]
• ZT-13Enforcement of every segmentation policy has been empirically verified by attempting a connection that should be denied, with the test output retained. [IG2] [PR.IR] [CIS 13]
• ZT-14Third-party and vendor access is brokered per application rather than granted at network level, is time-bounded, and is reviewed at least quarterly. [IG2] [PR.AA] [GV.SC] [CIS 15]
• ZT-15The incident response plan contains a containment lever table naming each available lever, its authority, and its measured time-to-effect, including token-lifetime and policy-propagation limits. [IG2] [RS.MI] [CIS 17]
• ZT-16Identity containment is executed as a single atomic action — session revocation plus credential reset — with the block policy applied afterwards, and this order is written into the runbook with the reason. [IG2] [RS.MI] [PR.AA]
• ZT-17A cloud quarantine mechanism that cannot be removed from within the affected account (for example an SCP applied from the management account) is pre-written and has been tested in a non-production account. [IG2] [RS.MI]
• ZT-18Endpoint isolation has been exercised on a live host within the last quarter, and the documented constraints — auto-lift window, offline retry window, VPN and proxy caveats, per-batch device limits — are recorded in the runbook. [IG2] [RS.MI] [CIS 17]
• ZT-19In every Kubernetes cluster, NetworkPolicy enforcement has been verified against a policy-enforcing CNI rather than assumed from the presence of the policy object. [IG2] [PR.IR]
• ZT-20Backup infrastructure, identity/Tier-0 systems and the virtualization management plane are each in their own enforced segment with distinct, non-shared administrative credentials. [IG3] [PR.IR] [CIS 11] [CIS 12]
• ZT-21Identity risk signals and device posture are consumed by the policy engine automatically, and an elevation in risk terminates or forces reauthentication of existing sessions without manual intervention. [IG3] [PR.AA] [DE.CM]
• ZT-22Blast radius for each crown jewel — the count of identities and network sources able to reach it — is measured, trended, and reported to executive leadership at least twice a year. [IG3] [ID.RA] [GV.OV]
• ZT-23A segmentation or containment exercise is run at least annually that measures actual achieved blast radius and actual time-to-useless, with findings tracked to closure. [IG3] [ID.IM] [CIS 18]

#Sources

1. NIST SP 800-207, Zero Trust Architecture — https://csrc.nist.gov/pubs/sp/800/207/final
2. CISA Zero Trust Maturity Model — https://www.cisa.gov/zero-trust-maturity-model
3. CISA Zero Trust Maturity Model v2.0 (PDF) — https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
4. DTM 25-003, Implementing the DoD Zero Trust Strategy — https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dtm/DTM%2025-003.PDF?ver=i2DzVamcFpNhvo-L7dDeUQ%3D%3D
5. CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks — https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
6. CISA Emergency Directive ED 25-03 (Cisco ASA/Firepower) — https://www.cisa.gov/news-events/directives/ed-25-03-identify-and-mitigate-potential-compromise-cisco-devices
7. CISA Advisory AA25-239A (Salt Typhoon) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a
8. CISA Advisory AA24-038A (Volt Typhoon) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
9. NCSC Annual Review 2025, incident management — https://www.ncsc.gov.uk/collection/ncsc-annual-review-2025/chapter-01-cyber-threat-to-the-uk/incident-management
10. GAO-18-559, Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach — https://www.gao.gov/assets/gao-18-559.pdf
11. Testimony of Joseph Blount, Colonial Pipeline, U.S. Senate Homeland Security and Governmental Affairs Committee — https://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Testimony-Blount-2021-06-08.pdf
12. Microsoft, Continuous access evaluation — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
13. Microsoft, Revoke user access in an emergency in Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
14. Microsoft, Conditional Access: Block access — https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-example
15. Microsoft, Microsoft-managed Conditional Access policies — https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies
16. Microsoft, Plan a Conditional Access deployment — https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access
17. Microsoft, Microsoft Graph PowerShell SDK and Microsoft Entra ID Protection — https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-graph-api
18. Microsoft, Take response actions on a device in Microsoft Defender for Endpoint — https://learn.microsoft.com/en-us/defender-endpoint/respond-machine-alerts
19. AWS, Remediating a potentially compromised Amazon EC2 instance — https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html
20. AWS, Disabling permissions for temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html
21. AWS Organizations CLI, attach-policy — https://docs.aws.amazon.com/cli/latest/reference/organizations/attach-policy.html
22. Google Cloud, Mitigate security incidents in GKE — https://docs.cloud.google.com/kubernetes-engine/docs/how-to/security-mitigations
23. VulnCheck, State of Exploitation 1H-2026 — https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
24. Google Cloud / Mandiant, M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
25. CrowdStrike 2026 Global Threat Report findings — https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
26. SecurityWeek, Verizon DBIR 2026: vulnerability exploitation overtakes credential theft — https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
27. Help Net Security, Verizon 2026 DBIR findings — https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
28. Sophos, State of Ransomware 2026 — https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026

#Chapter 6 — Cloud, Container and Kubernetes Security

How to configure a cloud control plane so it produces evidence, detect the identity and misconfiguration attacks that actually happen there, and contain a compromised account, instance, cluster or workload without destroying the only proof you will ever get.

Who needs this: Cloud platform engineers, SREs, security engineers, detection engineers, incident responders, CISOs signing the log-retention budget | Read time: 27 min | Maps to: CSF 2.0 IDENTIFY, PROTECT, DETECT, RESPOND | CIS Controls 3, 4, 5, 6, 8, 13 | ISO 27001 A.8.9, A.8.15, A.8.16, A.5.28

Welcome back, cyber warriors. Pour the coffee, because this is the chapter where the abstractions stop and the commands start.

In May 2026, Sysdig's threat research team watched an LLM-driven attacker work a cloud environment hands-on-keyboard. It exploited a vulnerability in a marimo notebook, enumerated its own escape options, found an exposed Docker socket, launched a privileged container with the host filesystem bind-mounted at /:/host, read /etc/shadow and the SSH keys, then replayed a projected Kubernetes service-account token against the API server and dumped the cluster's entire Secret store — database credentials, AWS keys, OpenAI API keys. The tell that it was an agent and not a person: it parsed a canary directive hidden inside a JSON error response and acted on it, and it unit-tested its own payload delivery with "hello" before running the escape scripts (Sysdig).

Read that chain again and notice what is missing. No IMDS call. No zero-day in Kubernetes. No malware. A misconfigured socket, a mounted token, and standing permission did the whole job. That is the shape of cloud compromise in 2026: cloud-conscious intrusions are up 37% overall and 266% among state-nexus actors, and 35% of cloud incidents involve valid account abuse (CrowdStrike 2026 Global Threat Report). Meanwhile 82% of CrowdStrike's detections in the period were malware-free. Your EDR has nothing to say about any of this. The evidence lives entirely in the control plane, and the control plane only remembers what you paid it to remember.

That last point is the one that costs organizations their investigations. Nearly every major cloud breach of recent years landed on the customer's side of the shared-responsibility line — misconfiguration, identity, exposed data — not on the provider's. And nearly every failed cloud investigation failed for the same banal reason: the logs that would have answered the question had a default retention of seven days, thirty days, or ninety, and the question got asked on day ninety-one.

This chapter is about closing both gaps before you need them closed, and about what to do in the first hour when you did not.

#1. Shared responsibility, as the providers actually write it

Every vendor slide about shared responsibility shows the same two-color stack, and every one of them is technically correct and operationally useless. The useful version is the one in the providers' own words.

AWS frames it as **security of the cloud versus security in the cloud. AWS protects "the infrastructure that runs all of the services offered in the AWS Cloud." You own "the guest operating system (including updates and security patches), other associated application software," and the configuration of firewalls and security groups. The sentence people skip is the one that matters most: "Customer responsibility will be determined by the AWS Cloud services that a customer selects"** (AWS shared responsibility model). Run EC2 and you carry nearly everything above the hypervisor. Use S3 or DynamoDB and AWS operates deeper into the stack, leaving you managing data, encryption options, classification and IAM. Two services, same account, completely different obligations. Your responsibility is not a property of "the cloud" — it is a property of each service you turned on, and it changes every time an engineer adopts a new one.

Microsoft mirrors the model with explicit IaaS / PaaS / SaaS boundaries, and adds the constant that a lot of teams get wrong: data, endpoints, account and access management are always the customer's, in every service model (Microsoft shared responsibility). There is no tier of service you can buy where identity becomes somebody else's problem.

Google states shared responsibility and then argues past it, framing the relationship as "shared fate" — the position being that a clean boundary leaves customers standing alone on the wrong side of it, so Google pairs it with secure-by-default foundations, blueprints and risk-transfer programs (Google Cloud). Whatever you think of the framing, it points at something real: a boundary is not a control.

#Who owns what

That last row is the whole point. Shared responsibility is a responsibility boundary, not a liability boundary. When a provider has an incident, your regulator does not send the provider a letter. It sends you one. Chapter 15 covers what the clocks look like; Chapter 11 covers the contractual clauses that make a provider tell you in time to meet them.

The practical consequence for this chapter is narrower and more urgent: the boundary determines evidence availability. Your forensic capability stops where the provider's plane begins. You cannot subpoena a hypervisor. Everything you will ever know about an incident in your tenant has to have been logged, routed and retained by decisions you made before the incident started.

Actionable takeaway: Build a one-page responsibility matrix per service, not per provider, and make "who owns the logs, and for how long" a mandatory row. Any service in production without an owner named in that row is an unowned service — assign it this week or turn it off.

#2. The control plane is the crown jewel

Every cloud attack you will investigate ends up as a question about API calls: who called what, from where, with which credential, and what did it return. The control-plane log is the only witness. So the first design decision in cloud security is not a tool — it is a retention policy with a budget attached.

The international logging guidance is blunt about the default: "Default log retention periods are often insufficient." The same document notes 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," and it tells you specifically to log "all control plane operations, including API calls and end user logins… configured to capture read and write activities, administrative changes, and authentication events" (Best Practices for Event Logging and Threat Detection, PDF). Note deliberately what it does not do: it sets no single numeric minimum. Anyone telling you "CISA requires twelve months" is quoting OMB M-21-31, a US federal memo binding on federal civilian agencies, not this guidance.

So you have to pick your own number. Here are the defaults you are picking against.

#What each provider actually retains, by default

Two sentences from that table should end up on a wall somewhere.

The first is Microsoft's, and it is the single most expensive fact in cloud IR: "Log retention changes aren't retroactive. When you upgrade from Free to P1 or P2, only data still within the free retention period (up to seven days) is available. Data that has already expired can't be recovered unless it was previously archived." You cannot buy your way out of this on day one of an incident. Upgrading a license mid-investigation gets you the logs from that moment forward, and nothing before it.

The second is Google's, and it cuts the other way: "Administrators cannot delete log event data or change the length of time that the data is available." In Workspace, that is an evidence-integrity feature — an attacker with admin cannot shorten your window. In AWS and Azure, they very much can, which is why Stealth:IAMUser/CloudTrailLoggingDisabled is a GuardDuty finding type in the first place.

#The 2026 licensing traps that destroy evidence

• Entra and the Unified Audit Log are two different systems. Microsoft says so explicitly: Entra audit and sign-in logs are "separate from the Microsoft 365 Unified Audit Log (UAL). UAL retention is managed through Microsoft Purview Audit and is not affected by Microsoft Entra ID licensing changes." An E5 upgrade does not extend your Entra sign-in retention, and a P2 upgrade does not extend your mailbox audit retention. Budget for both, separately.
• Graph activity logs are licensed but ephemeral. They require P1/P2 and a diagnostic setting routing them to Log Analytics, Sentinel, an Event Hub or Storage. Without the route, the license buys you nothing.
• Two Purview events still require manual activation per mailbox — SearchQueryInitiatedExchange and SearchQueryInitiatedSharePoint, which tell you what an intruder searched for, arguably the highest-signal record of intent you can get. CISA gives the command shape: Set-Mailbox <identity> -<sign-in type> @{Add="SearchQueryInitiated"} (CISA Microsoft Expanded Cloud Logs Implementation Playbook).
• GCP Data Access logs are off. Admin Activity's 400 days lulls teams into believing GCP logging is solved. Data Access — the record of who read what — is opt-in and defaults to 30 days when enabled.
• Azure resource logs are off, one resource at a time. The Activity log tells you somebody opened a Key Vault's access policy; it does not tell you which secrets were read. That is a resource log, it requires a diagnostic setting on that vault, and nobody has ever configured one on every resource by hand. Set it with Azure Policy at the management-group scope so new resources inherit it, or accept that your data-plane evidence is a lottery.
• CloudTrail data events are off. If your question is "which S3 objects did they download," and you have not enabled S3 data events, the honest answer is that you cannot know, and your breach notification has to assume the worst about every object in the bucket.

The cheap version. If you cannot fund a full SIEM ingest of every cloud log, do this instead and you will still be able to investigate. Send the control plane only — CloudTrail management events, Entra sign-in and audit logs, the Azure Activity log, GCP Admin Activity — to cheap object storage with a lifecycle that goes to a cold tier at 30 days and expires at 12 to 18 months, with Object Lock or the platform equivalent turned on. Query it with the provider's own query engine when you need it: CloudTrail Lake takes SELECT-only Trino-dialect SQL with the event data store ID as the FROM value, driven from the CLI with start-query, describe-query, get-query-results, and --delivery-s3-uri to write results to S3 (Lake queries with the CLI). Hot search is a luxury. Having the data at all is not.

Actionable takeaway: This week, run one query per provider — "what is our oldest retained control-plane event?" — and write the answer on the risk register. If the answer is under twelve months, you have an evidence gap, not a logging strategy. Fix the retention before you buy another detection tool, because a detection you cannot investigate is a notification you cannot scope.

#3. The detection stack, provider by provider

You do not need every service on this list. You need to know what each one is actually good at, so you stop paying for overlap and start covering gaps.

Four operational notes that will save you an embarrassing status update.

Security Hub is the normalization layer, and that is worth more than its dashboard. Most teams enable it, look at the compliance score, and never wire it into anything. The IR value is in three places. First, ASFF: Security Hub "processes finding data using the AWS Security Finding Format (ASFF), a standard finding format," which "eliminates the need to manage findings from myriad sources in multiple formats." It receives findings from GuardDuty, Inspector, Macie and the other integrated services, which means your SOAR writes one parser instead of five, and a playbook trigger written against ASFF fields keeps working when you turn on a new detection service. Second, cross-account aggregation is your first scoping question. Security Hub "consolidates your security findings across accounts and provider products" — so "is this confined to one account, or is the same finding type live in six?" is a filter, not an investigation. Ask it before you decide on a per-account or org-level containment. Third, workflow status is your case-tracking hook. Findings carry NEW, NOTIFIED, SUPPRESSED and RESOLVED, settable through aws securityhub batch-update-findings and automation rules (workflow status, Security Hub CSPM). Two traps come with it: Security Hub "only detects and consolidates findings that are generated after you enable" it, so it is worthless for a retrospective question, and marking a finding RESOLVED or SUPPRESSED "doesn't prevent Security Hub CSPM from generating a new finding for the same issue" — suppression is a triage note, not a mute button. Note also that AWS now brands the service Security Hub CSPM; if your runbooks say "Security Hub," check you are pointing at the right product page.

GuardDuty goes quiet on sustained activity. AWS documents it plainly: "If GuardDuty observes continued activity from a remote host, its ML model will identify this as an expected behavior. Therefore, GuardDuty will stop generating this finding" (GuardDuty IAM finding types). Persistent exfiltration eventually stops producing new findings. Never treat finding volume as a proxy for activity volume, and never close an incident because the alerts stopped.

Two GuardDuty families deserve dedicated routing. The UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.* and .../ResourceCredentialExfiltration.* findings mean credentials are demonstrably outside your control — the Resource variants cover Lambda functions and ECS tasks, not just EC2, and on the .InsideAWS variants you pivot on service.action.awsApiCallAction.remoteAccountDetails.accountId and .affiliated. The behavioral families (Persistence:, PrivilegeEscalation:, Exfiltration:IAMUser/AnomalousBehavior) mean escalation or staging is in progress, and Stealth:IAMUser/CloudTrailLoggingDisabled means somebody is turning off the witness. Chapter 14.3 lists the full trigger set for the account-takeover playbook.

Plan around the SCC tiering change. The Security Command Center Enterprise service tier shuts down on 21 May 2027, and organizations on Enterprise move automatically to Premium on or after that date (SCC release notes). If your GCP detection design assumes Enterprise-tier features, put the migration on the roadmap now rather than discovering the gap in a renewal cycle.

Actionable takeaway: For every cloud detection you own, record three separate facts — do we have the telemetry, does the logic exist and is it enabled, and has it fired on a validated test within the last 90 days. Chapter 9 covers the coverage model in full. Anything not green on all three is a named gap with a named owner, not a covered technique.

#4. CSPM and CIEM: the two problems that actually cause the breach

Cloud security spending skews toward threat detection, and cloud breaches skew toward misconfiguration and standing permission. That mismatch is the whole reason these two acronyms exist.

CSPM — Cloud Security Posture Management — answers "is anything configured wrongly." Public buckets, unencrypted volumes, open management ports, disabled logging, unrestricted security groups, missing IMDSv2 enforcement. It is a continuous config audit, mapping to CIS Control 4 and CSF's PR.PS.

CIEM — Cloud Infrastructure Entitlement Management — answers "who could do what if they wanted to." This is the harder and more valuable question, because permission is invisible until it is used. A role with * on s3 looks identical in a console to a role with three scoped actions, right up until the morning it is used to copy a database.

CIEM is the more urgent of the two because non-human identities now dominate cloud estates. CI runners, service accounts, app registrations and workload identities vastly outnumber human accounts and carry standing privilege that no MFA prompt ever guards; Mandiant records the theft of hard-coded keys and personal access tokens as a routine MFA-bypass path (M-Trends 2026), and the Sysdig case above ended in a Secret dump with no human credential involved at any point. Chapter 4 owns machine identity lifecycle; what belongs here is the cloud-specific measurement: for each principal, what could it reach, and when did it last actually use that reach?

The expensive version is a commercial CSPM/CIEM platform with graph-based blast-radius analysis across accounts and providers. On a large multi-cloud estate it earns its keep, mostly by making "who could reach this data" a query instead of a project.

The cheap version works, and you can start it this quarter:

1. Turn on the provider's own posture service. AWS Security Hub standards, GCP Security Command Center, and the equivalent Azure posture capabilities give you a config baseline with no new vendor.
2. Baseline against the CIS Benchmarks. These are consensus-developed prescriptive configuration baselines with AWS, Azure and GCP Foundations profiles plus containers and Kubernetes, each offering Level 1 (safe, broadly applicable) and Level 2 (defense-in-depth, may reduce functionality) profiles (CIS Benchmarks). Start at Level 1 everywhere; go to Level 2 on anything holding regulated data. These are the natural evidence for CIS Control 4 and ISO 27001 A.8.9.
3. Run IAM Access Analyzer's unused-access analyzers and treat the output as a work queue. Unused roles, unused access keys, unused passwords and unused services/actions on active principals are your least-privilege backlog, already sorted by the only thing that matters — nobody is using it, so removing it breaks nothing. Unused-access and internal-access analyzers are not Region-dependent; external access analyzers are, so create one in every Region you operate in.
4. Use policy generation, not guesswork, when you rebuild a role. Access Analyzer can generate a policy from the principal's actual CloudTrail activity. That is how you re-scope a role you just stripped during an incident, without a week of trial-and-error 403s.
5. Pick a framework to organize the work. The CSA Cloud Controls Matrix v4.1 (released 27 January 2026) gives 207 controls across 17 domains with mappings to other standards, and pairs with the CAIQ for assessing your own providers (CCM v4.1). New assessments should start on v4.1 rather than v4.0.x.

One prioritization rule beats any vendor's severity score: fix the misconfigurations that grant identity first. A public S3 bucket is a data-exposure incident. An over-permissive role trust policy is every incident, forever, because it is the machine that manufactures the next compromise.

Actionable takeaway: Stand up an unused-access analyzer in every account this month and delete the top 20 unused privileged grants it finds. It is free, it is reversible, and it is the highest-yield security work available to a team with no budget.

#5. IMDS and SSRF-to-credentials

The instance metadata service exists so a workload can get credentials without an engineer embedding a key. It is a genuinely good design. It is also a credential vending machine reachable at a fixed link-local address from anything running on the host — which means any server-side request forgery in your application is, potentially, a credential theft primitive. Shai-Hulud, the self-replicating npm worm, specifically harvests from cloud metadata endpoints alongside CI pipelines (Unit 42, CISA alert). This is not an edge case any more; it is a standard step in commodity tooling.

#What it looks like in CloudTrail

AWS's own CloudTrail investigation guidance gives you the pivots (Part 1, Part 2). Learn these fields; they are the difference between "we think something happened" and a defensible timeline.

The classic signature is an ASIA credential belonging to an instance role, calling from a source IP that is not in AWS. Add ec2RoleDelivery: "1.0" and you have both the theft and the mechanism in one record.

AWS's investigation checklist from Part 2 is worth following literally: query all Regions for that role's session activity, correlate CloudTrail timestamps against VPC Flow Logs for the actor's source IP, and then hunt IAM write events for persistence — CreateUser, CreateAccessKey.

#Enforcing IMDSv2

IMDSv2 requires a session token obtained via a PUT request, which defeats the naive SSRF pattern. The commands are documented (modify instance metadata options):

# Require IMDSv2 (session token required) on an existing instance.
# --http-endpoint must be set whenever --http-tokens is set.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

# Restrict how many network hops the PUT response may travel.
# A limit of 1 blocks container-to-IMDS in many topologies — that is the point,
# and also the reason it can break things. Test before fleet-wide rollout.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-put-response-hop-limit 3 \
    --http-endpoint enabled

# Turn IMDS off entirely on an instance that does not need it.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-endpoint disabled

Do the pre-flight check or you will cause an outage. AWS documents it: the MetadataNoToken CloudWatch metric tracks IMDSv1 calls, and "when MetadataNoToken records zero IMDSv1 usage for an instance, the instance is then ready to require IMDSv2" (configure IMDS options). Watch the metric until it is flat at zero, then enforce. Reversing that order is how a well-intentioned hardening sprint takes down a payments service.

Precedence matters when you roll this out at scale: launch parameter beats account-level default beats the AMI's ImdsSupport: v2.0 setting. Account-level enforcement is HttpTokensEnforced via ModifyInstanceMetadataDefaults; once it is enabled, a launch specifying HttpTokens=optional fails. That is the control you want in a production account — it makes the insecure configuration unlaunchable rather than merely discouraged. Note also that a hop limit of 1 "can cause issues" in container environments, which is exactly where you most want it; treat container topologies as a per-cluster test, not a fleet-wide flag flip.

Part 2's containment line, for an instance you already believe is compromised, is aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1.

Actionable takeaway: Enable account-level IMDSv2 enforcement (HttpTokensEnforced) in every non-production account today and every production account after MetadataNoToken sits at zero. Enforcement at the account default is worth ten times the same setting applied instance-by-instance, because it survives the next Terraform module somebody copies from a blog post.

#6. Cloud containment: the ordered actions, and what each one destroys

This is the section to bookmark. Everything below is plain, sequenced and boring on purpose — a responder reading it at 03:00 should find no jokes and no ambiguity.

The governing principle: preserve, then scope, then contain in one burst, then verify. The order exists because cloud evidence is short-lived and cloud containment is loud. A containment action taken before preservation can permanently remove the only record of what happened. A containment action taken piecemeal hands the adversary a window between each step.

#The ordered containment table

#The commands, and the traps inside them

Revoking IAM role sessions is not the same as removing permissions. AWS states it directly: "Temporary security credentials are valid until they expire… You can revoke these credentials, but you must also change permissions for the IAM user or role" (disabling permissions for temporary credentials). Session duration ranges from 900 seconds to 129,600 seconds (36 hours), default 43,200 seconds (12 hours) — so a session you fail to kill can outlive your entire first shift.

The console's "Revoke active sessions" attaches an inline policy named AWSRevokeOlderSessions to the role (requiring PutRolePolicy), denying all access to sessions assumed in the past and approximately 30 seconds into the future to absorb propagation delay. "Any user who assumes the role more than approximately 30 seconds after you choose Revoke active sessions is not affected" — which is why step 4's SCP and step 5's permission change both matter. The policy AWS attaches looks like this (revoke IAM role sessions):

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}

Three exceptions that will bite you mid-incident:

• You cannot revoke the session for a service-linked role.
• Roles created from IAM Identity Center permission sets cannot be edited in IAM — you must revoke the active permission-set session in Identity Center instead.
• If a resource-based policy independently allows the principal, revoking the role session is not sufficient. You need an explicit Deny on the resource, keyed on aws:PrincipalArn or aws:SourceIdentity.

For surgical denies that do not nuke a role every other workload depends on, condition on aws:SourceIdentity (immutable once set, and it survives role chaining), aws:PrincipalArn, or aws:userId — AROAXROLE1:* denies every session for a role, AROAXROLE2:<session-name> denies exactly one. The AWS-managed AWSDenyAll policy is the blunt instrument when you want the whole principal dead. And tell your responders to clear their own client caches (rm -r ~/.aws/cli/cache on Linux/macOS, del /s /q %UserProfile%\.aws\cli\cache on Windows) or they will spend twenty minutes debugging a credential that no longer exists.

Quarantine SCPs beat in-account denies during an active incident.

# Attach a quarantine policy to a root, OU, or 12-digit account ID.
aws organizations attach-policy \
  --policy-id p-examplepolicyid111 \
  --target-id ou-examplerootid111-exampleouid111

(attach-policy, SCP concepts) The reason this is the better containment lever is structural: the SCP lives in the management account, outside the compromised account's control, so a principal holding admin in the member account cannot detach it. An inline deny on a role can be removed by the attacker and is subject to IAM eventual consistency. The AWS CIRT playbook documents exactly this pattern — a deny-all conditioned on the offending identitystore:userId or aws:TokenIssueTime, attached at the Root or a target OU (Compromised IAM Credentials playbook).

Three exclusions, and they are the difference between contained and only feeling contained:

• SCPs have no effect on users or roles in the management account. AWS states it twice on the same page: "SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization." An SCP attached at the root still returns success, and the CLI gives you no warning that the principal you are chasing is exempt.
• SCPs cannot restrict any action performed through a service-linked role. "SCPs do not affect any service-linked role."
• SCPs exist only in an organization with all features enabled. They "are available only in an organization that has all features enabled" — an organization on consolidated billing only cannot use this lever at all. Find out which one you have before the incident, not during it.

If the compromised principal lives in the management account, the SCP is not your lever. Nothing you attach at the root will touch it. Contain on the identity side instead: attach an explicit deny to the principal, deactivate its access keys, revoke its role sessions, and — for an Identity Center user — revoke the permission-set session in Identity Center. That is the case where the blunt AWSDenyAll policy and the aws:PrincipalArn conditions above are doing the actual work, and the SCP is doing none.

Key rotation runs backwards during an incident. AWS's no-downtime rotation sequence is create → update applications → verify with get-access-key-last-used → set Inactive → confirm → delete (update access keys). For a compromised key, invert it: deactivate first, then create the replacement. Set it to Inactive rather than deleting it — an inactive key still tells you it existed, who created it and when it was last used; a deleted one tells you nothing.

Instance isolation, and the caveat that breaks naive playbooks. AWS's documented procedure is: create a dedicated Isolation security group with no rule permitting 0.0.0.0/0 (0-65535) in either direction, associate it with the instance, then remove all other security group associations (remediating a compromised EC2 instance).

# Replaces the instance's security groups with the isolation group.
# You must specify at least one security group ID.
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --groups sg-0isolation

Now the caveat, quoted: "The existing tracked connections won't be terminated as a result of changing security groups — only future traffic will be effectively blocked by the new security group." An established C2 channel survives your isolation. For that you need NACLs based on the network IoCs, which AWS's own ransomware response playbook covers in its "Enforce NACLs based on network IoCs" section (Ransom_Response_EC2_Linux). Google documents the identical trap on its side: "Adding firewall rules doesn't close existing connections."

Evidence handling across accounts. Snapshots are Region-scoped, so copy to move Regions. If the snapshot is encrypted, you must also share the customer-managed KMS key that encrypted it, or the forensic account receives an unreadable blob. The forensic role should have read-only access to collected artefacts (forensic investigation environment strategies, SEC10-BP03, capture backups and snapshots).

Federation containment is a demolition tool. There is no disable operation for an OIDC provider — only delete: aws iam delete-open-id-connect-provider --open-id-connect-provider-arn <arn>. It is idempotent, and AWS is explicit about the consequence: "Deleting an OIDC provider does not update roles that reference it. Any attempt to assume such roles will fail" (delete-open-id-connect-provider). That failure is the containment effect, and it is also an outage across every CI pipeline and workload that federated through it. The surgical alternative is remove-client-id-from-open-id-connect-provider, which drops one audience rather than the whole trust.

GCP has its own version of the "revocation is not enough" trap, and it is the most important sentence in a GCP containment playbook: "Disabling a service account key does not revoke short-lived credentials that were issued based on the key." The documented remedy is to disable or delete the service account itself, which immediately stops any workload using it (disable and enable service account keys).

# Disable a suspect key. NOTE: tokens already minted from this key remain valid.
gcloud iam service-accounts keys disable KEY_ID \
    --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --project=PROJECT_ID

Azure has no SCP, and pretending otherwise will cost you an hour. There is no policy object that sits above a subscription and denies arbitrary actions to a compromised principal the way an SCP does. Two things are commonly mistaken for one. Azure deny assignments look exactly right — they attach deny actions to a principal at a scope and beat any role assignment — but Microsoft is blunt: "You can't directly create your own deny assignments. Deny assignments are created and managed by Azure" (deny assignments). They arrive via deployment stacks and managed resources, not via your incident. Azure Policy with the deny effect is assignable by you at management-group scope, and it is the closest analogue — but read what it actually does: it "prevent[s] a resource request that doesn't match defined standards… The request is returned as a 403 (Forbidden)" (deny effect). That blocks resource creation and update. It does not block reads, and it does not block data-plane actions. It will stop an attacker deploying crypto-mining VMs. It will not stop them reading your storage accounts.

So on Azure the containment lever is identity-side, and it is removal rather than denial. Enumerate before you delete — az role assignment delete removes every assignment matching the query:

# ALWAYS run list first. delete removes every assignment matching these arguments.
az role assignment list \
  --assignee 00000000-0000-0000-0000-000000000000 \
  --scope /subscriptions/<subscription-id> \
  --include-inherited

# Remove the compromised principal's assignments at the subscription scope.
az role assignment delete \
  --assignee 00000000-0000-0000-0000-000000000000 \
  --scope /subscriptions/<subscription-id>

# Delete a compromised service-principal secret. Record --key-id in the evidence
# register first: Azure has no "inactive" state, so the credential is simply gone.
az ad sp credential delete \
  --id 00000000-0000-0000-0000-000000000000 \
  --key-id <key-id>

# Isolate a VM by swapping its NIC to a pre-built isolation NSG.
# Build the isolation NSG in advance, in every VNet, like the AWS one in step 9.
az network nic update \
  --resource-group <resource-group> --name <nic-name> \
  --network-security-group <isolation-nsg>

And the Azure trap that mirrors the GCP one: removing a role assignment or deleting a credential does not invalidate an access token the attacker already holds. Entra access tokens stay valid until they expire, and Entra "can't directly revoke a session token issued by an application." Removing the assignment stops the next token; it does not stop the one in flight. This is the same shape as the GCP short-lived-credential trap above and the AWS session trap above it — three providers, three different commands, one identical failure. Pair every removal with session revocation and a Conditional Access block on the identity side (Chapter 14.3), and treat the token lifetime as your real containment clock.

For the identity half of this — Entra session revocation, Conditional Access blocks, OAuth grant removal, Google Workspace signOut and token deletion — see Chapter 14.3, which owns the full account-takeover playbook, and Chapter 4 for the standing controls. The short version you need here: revocation is the control that matters and expiry is not, because in Continuous Access Evaluation sessions token lifetime increases to long-lived, up to 28 hours, and CAE propagation can take up to 15 minutes (continuous access evaluation).

Actionable takeaway: Rehearse this table as a drill in a non-production account, timed, with the snapshot and export steps actually executed. Every step you have never run will take three times as long during an incident, and step 11 — stopping the instance — is the one people run first and regret permanently. Preserve. Then contain. In that order, on every incident, without a debate about it.

#7. Kubernetes and containers

Kubernetes is where all of the above compounds, because a cluster is simultaneously a compute platform, an identity provider and a secret store, and its default settings favor developer velocity over your investigation.

#First: do you even have the audit log?

There is a tuning rule here that most teams miss and every privilege-escalation investigation depends on. Metadata level on all verbs is not enough. You need Request level on Secrets, ServiceAccounts and RBAC objects, because the request body is what shows the escalation — which role, which subject, which secret. Metadata tells you a RoleBinding was created; Request tells you it bound cluster-admin to the attacker's service account. That is the entire finding.

#Finding the blast radius

The EKS best-practices guide gives verbatim one-liners for the three questions you will ask first (EKS incident response and forensics):

# Which node is the suspect pod running on?
kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

# Every pod using a given service account, with its node.
kubectl get pods -o json --namespace <namespace> \
  | jq -r '.items[] | select(.spec.serviceAccount == "<service account name>") | "\(.metadata.name) \(.spec.nodeName)"'

# Every pod running a compromised image, cluster-wide.
IMAGE=<malicious image>
kubectl get pods -o json --all-namespaces \
  | jq -r --arg image "$IMAGE" '.items[] | select(.spec.containers[] | .image == $image) | "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

#The warning that matters more than any command in this chapter

Do not delete the pod.

AWS states it plainly: "Gather forensic evidence before removing the node — an attacker might attempt to destroy evidence through termination." Pods are ephemeral by design. Deleting one destroys the container's writable layer and all in-memory state, and if it is managed by a Deployment, the controller helpfully schedules a replacement — which may re-run the attacker's payload from the same compromised image, restarting the incident with your only evidence already gone.

Capture first, in this order:

1. Memory from the node (LiME or an equivalent acquisition tool; AWS also names its Automated Forensics Orchestrator for Amazon EC2).
2. Network state — netstat for connections and open ports.
3. Container runtime state — docker top, docker logs, docker inspect, docker diff, docker checkpoint; for containerd and CRI-O runtimes, the crictl equivalents.
4. Volume snapshots of the node's persistent storage.

Kubernetes gives you two non-destructive live-triage moves, and they should be your reflex (debug running pods):

# Attach an ephemeral debug container to the RUNNING pod. Does not restart it.
kubectl debug -it POD_NAME --image=busybox --target=CONTAINER_NAME

# Take a copy of the pod to examine, leaving the original running and observable.
kubectl debug POD_NAME --copy-to=POD_NAME-debug --image=DEBUG_IMAGE

Only after capture: kubectl delete pods POD_NAME --grace-period=10, or delete the Deployment so that no replacement is scheduled — which is GKE's documented sequence, and the correct one when the image itself is the problem.

#Quarantine without deletion

Network-policy quarantine. A deny-all policy scoped to the compromised pod's labels:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress

Verify enforcement; do not assume it. NetworkPolicy is enforced by the CNI, not by Kubernetes itself. On EKS it requires the VPC CNI network-policy feature, or Calico or Cilium. A cluster without a policy-enforcing CNI will accept this object, report success, and enforce absolutely nothing. Test this in a drill, on every cluster, before you depend on it in an incident. An object that applies cleanly and does nothing is worse than no control at all, because it produces confident status updates that are false.

Node isolation.

kubectl cordon <node-name>                 # marks unschedulable; does NOT evict anything
kubectl drain --ignore-daemonsets <node>   # evicts, respecting PDBs and grace periods
kubectl uncordon <node-name>               # reverse it

drain "respect[s] the desired graceful termination period, and respect[s] the PodDisruptionBudget you have defined" (safely drain a node) — meaning a PodDisruptionBudget can block your containment drain. Kubernetes recommends the AlwaysAllow unhealthy-pod eviction policy for exactly this reason. Find out which of your PDBs would block a drain before you need to drain.

GKE's documented quarantine pattern is the elegant one: pin the compromised pod in place while moving every healthy workload off the node (mitigate security incidents in GKE):

kubectl cordon NODE_NAME
kubectl label pods POD_NAME quarantine=true
kubectl drain NODE_NAME --pod-selector='!quarantine'

Then cut egress at the VPC layer:

gcloud compute instances add-tags NODE_NAME --zone COMPUTE_ZONE --tags quarantine

gcloud compute firewall-rules create quarantine-egress-deny \
  --network NETWORK_NAME --action deny --direction egress \
  --rules tcp --destination-ranges 0.0.0.0/0 --priority 0 --target-tags quarantine

Remember Google's caveat: adding firewall rules does not close existing connections. On EKS, additionally detach IAM roles from the compromised worker node and remove IAM policies from pod-assigned roles, which is what stops the cluster compromise from becoming a cloud control-plane compromise.

#Service-account tokens — what actually revokes one

This is the part almost every pre-2025 playbook gets wrong. Modern Kubernetes service-account tokens are bound: their validity is tied to an API object — a Pod, a Secret, or a Node (Node binding GA in v1.33) — and private JWT claims carry that object's metadata.name and metadata.uid. "If a referenced object is deleted or doesn't exist (or its metadata.uid doesn't match), authentication with that token fails immediately." For objects pending deletion with finalizers, tokens fail 60 seconds after the deletionTimestamp (managing service accounts).

That gives you a revocation decision tree:

Verify what a captured token is bound to before you decide, using a TokenReview — kubectl create -o yaml -f tokenreview.yaml with an authentication.k8s.io/v1 TokenReview carrying spec.token. The status returns authentication.kubernetes.io/pod-name, pod-uid, node-name and node-uid. And when you mint a replacement, bind it deliberately: kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod".

Strip the RBAC too. Deleting a ServiceAccount without removing its RoleBindings and ClusterRoleBindings leaves the grant sitting there, waiting for a recreated ServiceAccount of the same name to inherit it. That is not eradication; that is a scheduled re-compromise.

#The escalation paths, per platform

• EKS: anything on the node that can reach IMDS can retrieve the node IAM role credentials — the classic vector is a hostNetwork: true pod, or a hop limit of 2 that lets a container reach the metadata service. IRSA exchanges projected service-account tokens for IAM roles, so an over-broad IRSA trust policy, or an sts:AssumeRoleWithWebIdentity condition that does not pin sub to a specific namespace and service account, lets any pod in the cluster assume that role (privilege escalation in EKS via worker node instance roles, Wiz EKS best practices).
• GKE: Workload Identity works primarily through metadata-server emulation, so most applications authenticate automatically with no explicit volume configuration — which is why Google's own incident-mitigation guidance recommends Shielded GKE nodes to prevent metadata server access if a container escape occurs.
• AKS: Workload Identity (federated credentials on a user-assigned managed identity) versus the node's kubelet identity — the same IMDS-reachability problem applies.
• Cross-platform: container-escape CVEs turn a pod compromise into a node compromise, which turns into a cloud-credential compromise. Have these in the playbook: three critical runC vulnerabilities disclosed in November 2025 affecting Docker, Kubernetes, containerd and CRI-O, and CVE-2025-23266 (CVSS 9.0) in the NVIDIA Container Toolkit (Wiz on container escape). Older but still-referenced examples include CVE-2023-3676 (Kubernetes privilege escalation) and CVE-2023-3089 (CRI-O breakout). Chapter 10 owns the prioritization process for all of these.

Actionable takeaway: Audit automountServiceAccountToken across every namespace and set it to false wherever the workload does not call the API server, then enable Request-level audit logging on Secrets, ServiceAccounts and RBAC objects. Those two changes remove the most common escalation primitive and give you the evidence to see the next one. Chapter 14.10 carries the complete Kubernetes compromise playbook.

#8. Serverless and multi-cloud

#Serverless

Serverless shrinks your patching obligation and expands your identity obligation, which is a trade most teams accept without noticing the second half. Three things change materially.

Your invocation record is opt-in. Lambda invocations are CloudTrail data events, and data events are off by default. Without them you have management-plane visibility into who deployed the function and nothing whatsoever about who called it. Enable them for functions handling regulated data or holding privileged roles.

The credential-theft finding is a different one. GuardDuty's UnauthorizedAccess:IAMUser/ResourceCredentialExfiltration.OutsideAWS and .InsideAWS cover Lambda functions and ECS tasks, not just EC2. If your alerting routes only the InstanceCredentialExfiltration variants, you are blind to exactly the compute model you adopted partly for security reasons.

Containment is permission-shaped, not host-shaped. There is no instance to isolate and no security group to swap. The levers are the ones in §6: deny the execution role's permissions, revoke its sessions, remove event-source mappings and triggers, and — if the function itself is the malicious artefact — remove the deployment. Preservation still comes first: capture the function's code, configuration, environment variables and layer versions before you change anything, because a redeploy overwrites the evidence of what was running.

One more, easy to miss: IAM Access Analyzer's external-access analyzers cover Lambda alongside S3, IAM roles, KMS keys, SQS, Secrets Manager, SNS, EBS volume snapshots, RDS snapshots, ECR, EFS and DynamoDB. A snapshot shared to an unknown account is an exfiltration channel that leaves almost no other trace.

#Multi-cloud

Multi-cloud is not three times the work. It is three times the work plus the integration cost of reconciling three incompatible mental models, which is the part nobody budgets for.

The specific failure is that containment semantics differ per provider, in ways that are individually documented and collectively lethal:

A responder who has internalized the AWS model and applies it to GCP will disable the key, watch the API calls continue, and lose twenty minutes deciding whether their tooling is broken. That is a training problem with a documentation answer: write the per-provider revocation semantics into one card and put it in the war room.

Four rules that make multi-cloud tractable:

1. One timeline, one clock. Normalize everything to UTC with ISO 8601 formatting (2024-07-25T20:54:59.649Z), millisecond granularity where available, from a validated time source — exactly what the allied logging guidance calls for. It is the difference between a timeline and a pile of files.
2. One control framework, mapped per provider. Use CSA CCM v4.1 or the CIS Benchmarks as the common spine and map each provider to it, rather than maintaining three independent standards that drift apart.
3. Structured logs, one schema. JSON, consistent field order, automated normalization — the guidance calls normalization "particularly important" for SaaS logs "that can change over time or without notice."
4. Do not buy three of everything. Native detection in each provider plus one aggregation layer beats three partially-deployed third-party platforms. The failure mode of multi-cloud tooling is not insufficient coverage; it is four consoles nobody checks and an alert firing into a channel that was archived last quarter.

Actionable takeaway: Write a one-page per-provider revocation card — for AWS, Azure/Entra and GCP, what kills a session, what kills a credential, and what each one does not reach — and laminate it into the incident war-room kit. The five minutes a responder spends reading it is the cheapest control in this chapter.

Cloud security is not really about the cloud. It is about whether you configured a machine that keeps receipts, whether you know which of your thousands of standing permissions actually get used, and whether the person who gets paged at 03:00 knows to take the snapshot before they kill the pod. None of that requires an enterprise budget. All of it requires deciding, in advance and in writing, what you will do — because the control plane will absolutely do what you told it to, exactly as fast as an attacker can ask.

Log everything that grants power, revoke before you reset, and never, ever delete the pod first.

#Chapter checklist

• CLD-01A responsibility matrix exists per cloud service in production (not per provider), naming the owner of configuration, identity, data and logs for each. [IG1] [GV.RR] [ID.AM]
• CLD-02Control-plane logging is enabled in every account, subscription and project — CloudTrail management events, Entra audit and sign-in logs, the Azure Activity log exported past its 90-day platform window, GCP Admin Activity — with no unlogged region, account, subscription or tenant. [IG1] [DE.CM] [CIS 8] [A.8.15]
• CLD-03Control-plane logs are exported to storage outside the account that generates them, with object-lock or equivalent immutability, and lifecycle rules on those buckets require security sign-off to change. [IG2] [PR.DS] [CIS 8] [A.5.28]
• CLD-04Documented log retention for control-plane events is at least twelve months, with the risk assessment behind the chosen number recorded on the risk register. [IG2] [DE.CM] [CIS 8]
• CLD-05CloudTrail data events are enabled for S3 buckets and Lambda functions that hold or process regulated data. [IG2] [DE.CM] [CIS 8]
• CLD-06GCP Data Access audit logs are enabled for projects holding regulated data, and their retention is configured beyond the 30-day _Default. [IG2] [DE.CM] [CIS 8]
• CLD-07Microsoft Purview Audit retention is configured deliberately, and where a 10-year add-on has been purchased, a matching custom retention policy has been created and targeted. [IG2] [DE.CM]
• CLD-08SearchQueryInitiatedExchange and SearchQueryInitiatedSharePoint are activated for privileged and high-risk mailboxes. [IG3] [DE.CM]
• CLD-09Every cloud detection has a documented data-source precondition check that fails loudly when the source stops reporting or was never populated. [IG2] [DE.AE]
• CLD-10IMDSv2 is enforced at the account level (HttpTokensEnforced) in all production accounts, and the MetadataNoToken metric reads zero for the fleet. [IG2] [PR.PS] [CIS 4] [A.8.9]
• CLD-11A detection exists for CloudTrail events where ec2RoleDelivery is "1.0", and for ASIA instance-role credentials used from a source IP outside AWS. [IG2] [DE.CM]
• CLD-12An unused-access analyzer runs in every account, and its findings are worked as a tracked remediation queue with an owner and a cadence. [IG2] [PR.AA] [CIS 5] [CIS 6]
• CLD-13External-access analyzers exist in every Region in use, not only the primary Region. [IG2] [ID.AM] [PR.AA]
• CLD-14Cloud accounts are baselined against the relevant CIS Benchmark at Level 1 minimum, and at Level 2 for any account holding regulated data, with drift reported. [IG1] [PR.PS] [CIS 4] [A.8.9]
• CLD-15A pre-built quarantine SCP (or equivalent org-level policy) exists in the management account, has been tested in a drill, and its attachment requires Incident Commander approval. The runbook states that it does not restrict management-account principals or service-linked roles, and names the identity-side alternative for those cases. [IG2] [RS.MI] [A.5.26]
• CLD-16A dedicated isolation security group exists in each VPC with no 0.0.0.0/0 (0-65535) rule in either direction, and the runbook documents that changing security groups does not terminate established connections. [IG2] [RS.MI]
• CLD-17A forensics account exists with read-only access to collected artefacts, and the cross-account snapshot procedure — including sharing the customer-managed KMS key for encrypted snapshots — has been executed end-to-end in a drill within the last 12 months. [IG3] [RS.AN] [A.5.28]
• CLD-18A one-page per-provider revocation card (what kills a session, what kills a credential, what each does not reach) is in the incident war-room kit and reviewed annually. [IG1] [RS.MA] [A.5.24]
• CLD-19Kubernetes control-plane audit logging is enabled on every cluster, with Request-level auditing on Secrets, ServiceAccounts and RBAC objects. [IG2] [DE.CM] [CIS 8]
• CLD-20automountServiceAccountToken is set to false for every workload that does not call the API server, verified by policy rather than by convention. [IG2] [PR.AA] [CIS 4]
• CLD-21NetworkPolicy enforcement has been positively verified on every cluster (a deny-all policy demonstrably blocks traffic), not merely assumed from the presence of a CNI. [IG2] [PR.IR] [CIS 13]
• CLD-22The Kubernetes response runbook requires evidence capture — memory, runtime state, volume snapshot — before any pod or node deletion, and the requirement has been exercised in a tabletop or functional drill. [IG2] [RS.AN] [A.5.28]
• CLD-23PodDisruptionBudgets that would block a containment drain have been identified per cluster, with a documented override procedure. [IG3] [RS.MI]
• CLD-24IRSA / Workload Identity trust policies pin the sub claim to a specific namespace and service account, with no cluster-wide assumable roles. [IG3] [PR.AA] [CIS 6]
• CLD-25Cryptomining findings in container environments are triaged as suspected full control-plane compromise, including a mandatory check of whether the cluster Secret store was read. [IG2] [RS.AN]
• CLD-26A diagnostic setting exports the Azure Activity log beyond its 90-day platform window for every subscription, and resource diagnostic logs are enforced by Azure Policy at management-group scope for resources holding regulated data. [IG2] [DE.CM] [CIS 8] [A.8.15]

#Sources

1. AWS Shared Responsibility Model — https://aws.amazon.com/compliance/shared-responsibility-model/
2. Microsoft — Shared responsibility in the cloud — https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
3. Google Cloud — Shared responsibilities and shared fate — https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate
4. AWS CloudTrail concepts (retention, event types) — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html
5. Run and manage CloudTrail Lake queries with the AWS CLI — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/lake-queries-cli.html
6. Microsoft Entra data retention — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
7. Manage audit log retention policies (Microsoft Purview) — https://learn.microsoft.com/en-us/purview/audit-log-retention-policies
8. CISA — Microsoft Expanded Cloud Logs Implementation Playbook (Jan 2025) — https://www.cisa.gov/sites/default/files/2025-01/microsoft-expanded-cloud-logs-implementation-playbook-508c.pdf
9. Google Cloud Logging — retention and buckets — https://cloud.google.com/logging/docs/buckets
10. Google Workspace — Data retention and lag times — https://knowledge.workspace.google.com/admin/reports/data-retention-and-lag-times
11. CISA/ACSC and partners — Best Practices for Event Logging and Threat Detection — https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection (PDF: https://www.ic3.gov/CSA/2024/240822.pdf)
12. Amazon GuardDuty IAM finding types — https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html
13. Amazon Detective finding groups — https://docs.aws.amazon.com/detective/latest/userguide/understanding-groups.html
14. IAM Access Analyzer overview — https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
15. Microsoft Defender XDR — CloudAppEvents table — https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-cloudappevents-table
16. Google Security Command Center — Event Threat Detection overview — https://docs.cloud.google.com/security-command-center/docs/concepts-event-threat-detection-overview
17. Google Security Command Center — threat detection overview — https://docs.cloud.google.com/security-command-center/docs/overview-threats
18. Google Security Command Center release notes (Enterprise tier shutdown) — https://docs.cloud.google.com/security-command-center/docs/release-notes
19. CIS Benchmarks — https://www.cisecurity.org/cis-benchmarks
20. CSA Cloud Controls Matrix v4.1 — https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1
21. AWS Security Blog — Incident response guide for AWS CloudTrail investigations, Part 1 — https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-1/
22. AWS Security Blog — Incident response guide for AWS CloudTrail investigations, Part 2 — https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-2/
23. AWS — Remediating compromised AWS credentials — https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html
24. AWS — Modify instance metadata options for existing instances — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-existing-instances.html
25. AWS — Configure instance metadata options — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html
26. AWS — Revoke IAM role temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html
27. AWS — Disabling permissions for temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html
28. AWS — Update access keys — https://docs.aws.amazon.com/IAM/latest/UserGuide/id-credentials-access-keys-update.html
29. AWS — Remediating a potentially compromised EC2 instance — https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html
30. AWS CLI — ec2 modify-instance-attribute — https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html
31. AWS CLI — organizations attach-policy — https://docs.aws.amazon.com/cli/latest/reference/organizations/attach-policy.html
32. AWS — Service control policies concepts — https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
33. AWS CLI — iam delete-open-id-connect-provider — https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html
34. AWS Security Blog — Forensic investigation environment strategies in the AWS Cloud — https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/
35. AWS Well-Architected — SEC10-BP03 Prepare forensic capabilities — https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html
36. AWS Security IR — Capture backups and snapshots — https://docs.aws.amazon.com/security-ir/latest/userguide/capture-backups-and-snapshots.html
37. aws-samples — Compromised IAM Credentials playbook — https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Compromised_IAM_Credentials.md
38. aws-samples — Ransom Response EC2 Linux playbook — https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md
39. Google Cloud — Disable and enable service account keys — https://docs.cloud.google.com/iam/docs/keys-disable-enable
40. Microsoft — Continuous access evaluation — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
41. Microsoft — Revoke user access in an emergency — https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
42. Amazon EKS — Control plane logging — https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html
43. EKS Best Practices Guide — Incident Response and Forensics — https://aws.github.io/aws-eks-best-practices/security/docs/incidents/
44. Kubernetes — Safely drain a node — https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/
45. Kubernetes — Debug running pods — https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/
46. Kubernetes — Managing service accounts — https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/
47. Google Cloud — Mitigate security incidents in GKE — https://docs.cloud.google.com/kubernetes-engine/docs/how-to/security-mitigations
48. Sysdig — Agentic threat actor hits the orchestration plane — https://webflow.sysdig.com/blog/agentic-threat-actor-hits-the-orchestration-plane-ai-agent-driven-container-escape
49. CrowdStrike 2026 Global Threat Report findings — https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
50. Mandiant M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
51. Unit 42 — npm supply chain attack (Shai-Hulud) — https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
52. CISA alert — Widespread supply chain compromise impacting npm ecosystem — https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
53. Christophe Tafani-Dereeper — Privilege escalation in EKS by compromising the instance role of worker nodes — https://blog.christophetd.fr/privilege-escalation-in-aws-elastic-kubernetes-service-eks-by-compromising-the-instance-role-of-worker-nodes/
54. Wiz — EKS security best practices — https://www.wiz.io/academy/container-security/eks-security-best-practices
55. Wiz — Container escape — https://www.wiz.io/academy/container-security/container-escape
56. Dark Reading — Pernicious permissions: Kubernetes cryptomining and cloud data heist — https://www.darkreading.com/cyber-risk/pernicious-permissions-kubernetes-cryptomining-cloud-data-heist
57. Azure Monitor — Activity log (90-day retention, export) — https://learn.microsoft.com/en-us/azure/azure-monitor/platform/activity-log
58. Azure Monitor — Resource logs (not collected by default) — https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs
59. Microsoft Defender for Cloud — overview (CNAPP, CSPM, CWPP) — https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction
60. Azure RBAC — Deny assignments (cannot be directly created) — https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments
61. Azure Policy — deny effect — https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-deny
62. AWS — Introduction to Security Hub CSPM (ASFF, cross-account aggregation) — https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
63. AWS — Setting the workflow status of findings in Security Hub CSPM — https://docs.aws.amazon.com/securityhub/latest/userguide/finding-workflow-status.html
64. Azure CLI — az role assignment — https://learn.microsoft.com/en-us/cli/azure/role/assignment
65. Azure CLI — az ad sp credential — https://learn.microsoft.com/en-us/cli/azure/ad/sp/credential
66. Azure CLI — az network nic — https://learn.microsoft.com/en-us/cli/azure/network/nic

#Chapter 7 — Using and Securing AI

Inventory every AI system touching your data, govern it against a standard an auditor recognises, use it in the SOC where it is actually good, and build the human process checks that stop an AI-enabled attacker — because the technology ones do not.

Who needs this: CISO · Security Architect · SOC Lead · Detection Engineer · AI/ML Platform Owner · GRC Lead · Head of IT | Read time: 32 min | Maps to: CSF 2.0 GOVERN, IDENTIFY, PROTECT, DETECT · CIS Controls 1, 2, 3, 6, 8, 15, 16, 17 · ISO/IEC 27001 A.5.1, A.5.2, A.5.9–5.11, A.5.19–5.23, A.8.8 · ISO/IEC 42001 · NIST AI RMF (AI 100-1) + GenAI Profile (AI 600-1)

Cyber warriors, let's start with the two incidents that ended the debate about whether any of this is real.

In November 2025 Anthropic disclosed GTG-1002, which it assesses with high confidence to be a Chinese state-sponsored group that ran an agentic intrusion campaign against roughly thirty global targets — large technology companies, financial institutions, chemical manufacturers, government agencies. The AI performed 80–90% of the campaign, with humans stepping in only at decision gates. It did reconnaissance, identified databases, researched vulnerabilities, wrote exploit code, harvested credentials, triaged the stolen data by intelligence value, built backdoors, and then wrote up its own attack documentation. The safeguard bypass was not clever cryptography. The operators role-played as employees of a legitimate security firm doing authorized penetration testing, and they decomposed the work into small tasks that each looked innocuous on their own (Anthropic).

Six months later, Sysdig's threat research team watched the second one happen in a customer's cloud. An LLM-driven actor exploited a vulnerability in a marimo notebook, then autonomously enumerated container-escape primitives, mounted the Docker socket, created a privileged container with /:/host, read /etc/shadow and SSH keys, and replayed a projected Kubernetes service-account token against the API server to dump the entire cluster Secret store — database credentials, AWS keys, and, with a certain poetry, OpenAI API keys. The tell that it was an agent: it parsed and acted on a canary directive hidden inside a JSON error response, and it unit-tested its own payload delivery with "hello" before running the escape scripts (Sysdig). Note the thing that matters most in that chain: the agent never needed an exploit for the escalation. It only needed the access its own runtime already carried.

Now the counterweight, and please put this in your program's stated assumptions before you spend a dollar. Mandiant's conclusion from over 500,000 hours of 2025 incident response is that 2025 was not the year breaches directly resulted from AI; most intrusions still stem from human and systemic failures (M-Trends 2026). AI today is a force multiplier on TTPs you already know, not a new kill chain — with the two agentic exceptions above. Anyone selling you an "AI-native" replacement for identity hygiene, logging and patching is selling you a very expensive hat.

This chapter covers four distinct problems that the industry insists on blending into one slide. Keep them separate, because they have different owners, different budgets and different failure modes: securing the AI you build or buy, governing it, using it in defense, and defending against attackers who use it.

#7.1 Four problems, one spine

NIST gives you the spine. The preliminary draft of **NIST IR 8596, the Cybersecurity Framework Profile for Artificial Intelligence — the "Cyber AI Profile" — was released 16 December 2025 with a comment period that closed 30 January 2026. It aligns to CSF 2.0 and organises the whole domain around three focus areas: Securing AI System Components (Secure), Conducting AI-Enabled Cyber Defense (Defend), and Thwarting AI-Enabled Cyber Attacks (Thwart)** (NIST, NIST IR 8596 iprd). NIST is separately developing SP 800-53 Control Overlays for Securing AI Systems.

I use those three plus a fourth — Govern — because Secure/Defend/Thwart are engineering activities and none of them survive contact with a board, an auditor or a customer questionnaire without a management system behind them.

Because IR 8596 is a preliminary draft, do not write "compliant with NIST IR 8596" on anything. Use it as the structure for your gap analysis and your target profile — that is what a CSF Profile is for.

Actionable takeaway: Split your AI work into Secure / Govern / Defend / Thwart on one page, name a single accountable owner per row, and refuse any AI initiative that cannot say which row it belongs in. Programs that treat "AI security" as one bucket end up funding the exciting quarter of it and none of the boring three.

#7.2 The AI inventory: you cannot govern what you cannot enumerate

Every AI governance framework lands on the same first requirement, and it is the one where most programs fail. The AI system inventory is the AI analogue of CIS Control 1 — asset inventory — and it fails for the identical reason asset inventory always fails: the organization acquires new assets faster than the process that records them.

Shadow AI is not an aberration to be stamped out; it is the default state. Someone in finance is pasting a reconciliation into a consumer chatbot right now, and they are doing it because it works and nobody gave them a sanctioned alternative. If your first move is a ban, your second move is losing visibility entirely, because the traffic moves to personal devices where you have no telemetry at all.

#What an inventory record must contain

#A discovery method that works with logs you already have

You do not need a shadow-AI discovery product to get to 80% coverage. Six passes, roughly a day of work each, all against data you are already paying to store:

1. Egress and DNS. Query your proxy, firewall or DNS logs for the API and web hostnames of every major model provider and AI-tooling vendor, over a 90-day window, grouped by source user and by volume. Volume matters more than presence — one visit is curiosity, four thousand API calls is a production dependency nobody told you about.
2. OAuth grants. Enumerate third-party application consent grants in Entra ID and Google Workspace. AI note-takers, meeting bots, and "AI assistant for X" integrations arrive as OAuth grants, and an OAuth grant is a standing, MFA-immune, password-reset-proof grant of your data to a third party's infrastructure. The Salesloft Drift compromise proved exactly that at scale: attackers stole the OAuth refresh tokens customers had issued to a chat integration and exported records from 700+ organizations over ten days (AppOmni, FINRA). The runbook for enumerating and killing grants lives in Chapter 4; here you are only building the list.
3. Code and CI. Grep your repositories for provider SDK imports and model API base URLs. This finds the AI features your own engineers shipped without a review.
4. Developer agent tooling. Inventory agent CLIs and MCP server configurations on engineering endpoints. This is not paranoia. In the Nx s1ngularity attack of August 2025, malicious package versions detected Claude Code CLI, Google Gemini CLI and Amazon Q CLI on developer machines and invoked them with permission-bypassing flags to enumerate secrets across the filesystem — harvesting 2,349 credentials from 1,079 developer systems, then using the stolen GitHub tokens to flip private repositories public (The Hacker News, GitGuardian).
5. Expense. Pull corporate-card and expense-report lines for AI subscriptions. Finance always knows before security does.
6. Vendor sub-processor pages. For your top-tier vendors, read the sub-processor list and change-notification terms. Your SaaS vendors are adding AI features and AI sub-processors continuously, and most of them notify by updating a web page.

# Pass 3: find AI provider SDKs and API endpoints across every repo you have cloned locally.
# Returns file:line hits. Adapt the pattern list to the providers your egress logs surfaced in pass 1.
grep -rInE 'anthropic|openai|@google/generative-ai|google\.generativeai|bedrock-runtime|azure\.ai\.(inference|openai)|litellm|langchain|llama_index' \
  --include='*.py' --include='*.ts' --include='*.js' --include='*.go' --include='*.java' \
  --include='requirements*.txt' --include='package.json' --include='go.mod' --include='pom.xml' \
  ./repos/ | sort -u

The cheap version: if you have no budget at all, do passes 1, 2 and 5 only, quarterly, into a spreadsheet with the ten fields above. Three queries and a card statement will find the overwhelming majority of your shadow AI, and an approval column with a name in it is worth more to your auditor than a discovery product with nobody reading its output.

Actionable takeaway: Run the six discovery passes this month and publish the inventory with a "last verified" date in the header. Then give the business a sanctioned tool with a real data agreement — because every hour a sanctioned option does not exist is an hour your data spends somewhere you cannot see.

#7.3 The threat model: what to actually map against

Three catalogs, all current, all free. Use them; do not write your own taxonomy.

OWASP Top 10 for LLM Applications 2025 — LLM01 Prompt Injection · LLM02 Sensitive Information Disclosure · LLM03 Supply Chain · LLM04 Data and Model Poisoning · LLM05 Improper Output Handling · LLM06 Excessive Agency · LLM07 System Prompt Leakage · LLM08 Vector and Embedding Weaknesses · LLM09 Misinformation · LLM10 Unbounded Consumption. Prompt injection holds the top slot for the second consecutive edition; System Prompt Leakage, Vector and Embedding Weaknesses, and Unbounded Consumption are the new-for-2025 entries (OWASP GenAI, 2025 PDF). A 2026 LLM edition is published on the same project site (OWASP GenAI LLM Top 10 2026) — pin whichever edition you map against and re-baseline deliberately rather than tracking "latest", the same discipline Chapter 9 applies to ATT&CK versions.

OWASP Top 10 for Agentic Applications 2026, released 9 December 2025 and built by more than 100 contributors, uses ASI01–ASI10 identifiers: ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, ASI07 Insecure Inter-Agent Communication, plus Agentic Supply Chain Compromise, Unexpected Code Execution, Memory and Context Poisoning, Cascading Agent Failures, and Rogue Agents. It maps real incidents to each category and defines an Agentic Development Lifecycle (ADLC) (OWASP GenAI, Agentic Security Initiative).

MITRE ATLAS v5.6.0 (Adversarial Threat Landscape for AI Systems) mirrors ATT&CK's structure deliberately, with 16 tactics including two AI-specific ones — AI Model Access (AML.TA0000) and AI Attack Staging (AML.TA0001) (mitre-atlas/atlas-data). Older references say "ML Model Access" and "ML Attack Staging"; the terminology shifted. Because ATLAS mirrors ATT&CK, it drops straight into an existing threat-informed-defense practice with the tooling you already run.

The useful move is not reciting the lists. It is deciding, per AI system in your inventory, which categories actually apply — most systems face four or five — and writing detections and design constraints for those. A retrieval chatbot over internal documents has an LLM01/LLM02/LLM08 problem and essentially no LLM06 problem. An agent with write access to your ticketing system and your cloud account is the reverse: LLM06 Excessive Agency and ASI02 Tool Misuse are the whole game.

Actionable takeaway: For each system in your AI inventory, record which OWASP LLM and ASI categories are in scope and which are explicitly out of scope, with the reason. A threat model that claims all ten apply to everything is a threat model nobody will use twice.

#7.4 Prompt injection: the honest version

Here is the mechanism, stated plainly, because most vendor material dances around it.

Large language models process instructions and data on the same channel. There is no in-band separator that reliably distinguishes "this is a command from my operator" from "this is content I was asked to read." A model that reads an email, a Jira ticket, a wiki page, a fetched web page, a PDF, or an MCP tool description is reading text that an attacker may have written, and that text is arriving on the same channel as your system prompt. Direct prompt injection is a user typing an attack into the box. Indirect prompt injection is an attacker planting the payload in content the model will later ingest on someone else's behalf — and that is the one that turns into a breach.

EchoLeak (CVE-2025-32711) is the reference case and belongs in your training deck by name. Disclosed in June 2025 by Aim Security, it was a zero-click indirect prompt injection in Microsoft 365 Copilot, rated CVSS 9.3. A single crafted email carried instructions hidden in HTML comments and white text. Copilot ingested it into RAG context. Later, when the user asked Copilot an ordinary question, the hidden instructions caused it to retrieve sensitive tenant data and encode that data into a URL that was then automatically fetched. The chain evaded Microsoft's cross-prompt injection classifier, defeated link redaction using reference-style Markdown, and abused a Teams proxy to complete the exfiltration — a full privilege escalation across LLM trust boundaries with no user interaction at all. Microsoft patched server-side and reported no in-the-wild exploitation (arXiv analysis, HackTheBox writeup).

Read that chain again and notice what it did to the defenses that were present. There was an injection classifier. It was evaded. There was link redaction. It was defeated with a Markdown syntax variant. This is why I will not tell you that any filter prevents prompt injection. Input and output classifiers are speed bumps: they raise the cost of the trivial attack and they will be bypassed by anyone who tries twice. Buy them if they are cheap and already in your stack. Do not architect on them.

What actually reduces risk is architectural, and it comes down to breaking the "lethal trifecta" — private data access, exposure to untrusted content, and the ability to communicate externally, all in one agent (Simon Willison). Remove any one leg and the chain does not complete.

Actionable takeaway: For every AI system that can reach private data, prove on paper that at least one leg of the lethal trifecta is severed, and make that proof a deployment gate. If you cannot sever a leg, the system requires a human confirmation on every action that leaves the boundary — no exceptions for "internal only" tools.

#7.5 Agents, tools and the confused deputy

An agent is a program that holds credentials, reads attacker-influenced text, and takes actions. Put that way, it is the confused-deputy problem with a language model in the middle, and the confused deputy is one of the oldest failure modes we have.

The Model Context Protocol and its peers are where this gets concrete in 2026. The named attack classes in circulation are worth learning as a set:

• Tool poisoning — a malicious tool masquerading as a legitimate one. MCP has no built-in cryptographic verification of tool origin, and names, descriptions and provider claims are trivially spoofable.
• Rug pulls — a tool that silently redefines itself after you approved it.
• Tool shadowing — a malicious server's tool definition influencing how the model uses a legitimate server's tool.
• Cross-server attacks — one connected server's content steering the agent's use of another.
• Confused-deputy and OAuth weaknesses — the protocol does not propagate user context, so the tool acts with the agent's authority rather than the requesting user's.

(Simon Willison, Microsoft — The state of MCP security in 2026)

None of this is theoretical. The Sysdig case from this chapter's opening is the confused deputy in production: the agent inherited a projected Kubernetes service-account token from a mounted volume and replayed it against the API server to dump the cluster Secret store. No exploit was required for the escalation — only the standing access the runtime carried (Sysdig).

#Onboarding an agent or MCP server — and why the order matters

Steps 1 and 2 must precede everything else, and the reason is not tidiness. If the agent's identity is a shared service account, step 2 has no meaningful answer: you cannot revoke it during an incident without breaking every other consumer of that account, so under pressure you will not revoke it at all. That is how a contained incident becomes an uncontained one. Step 7 must precede step 8's production traffic for the reason the Sysdig case demonstrates — logging an escalation you could have made structurally impossible is a poor trade.

The concrete Kubernetes control in step 7 is automountServiceAccountToken: false on any pod that does not need to talk to the API server. Chapter 6 covers the cluster-side work and Chapter 4 covers agent identity, scoping and revocation as an identity discipline; do not build a parallel process here.

Actionable takeaway: Before an agent touches production, run the revocation test and record how long it took. An agent whose credentials you cannot kill in under five minutes is not a productivity tool, it is an unmanaged privileged account with a chat interface.

#7.6 RAG, vector stores, poisoning and model theft

Retrieval leakage is a permissions problem wearing a machine-learning costume. The most common serious defect in enterprise RAG is that the index is built once, with the ingesting service's permissions, and then queried by everyone — so the retrieval layer silently returns the union of what the pipeline could read rather than what the asking user is allowed to read. The fix is not a model fix. Enforce the requesting user's authorization at query time, and test it with a deliberately low-privilege account before launch. OWASP catalogs the broader class as LLM08:2025 Vector and Embedding Weaknesses, which also covers embedding inversion, cross-tenant leakage in multi-tenant vector stores, poisoning at the embedding layer, and unvalidated user-supplied filters flowing into vector-database query strings (OWASP).

Poisoning got much worse than the industry assumed, and this one is verified. Anthropic, the UK AI Safety Institute and the Alan Turing Institute showed that roughly 250 malicious documents suffice to install a backdoor in models from 600M to 13B parameters — a near-constant absolute number, not a percentage of the training corpus. A 13B model trained on twenty times more data was backdoored by the same 250 documents (Anthropic, Alan Turing Institute). The comfortable assumption — that scale dilutes poison — is wrong. Poisoning does not get harder as models get bigger.

For most readers this is not a "we train foundation models" problem; it is a fine-tuning and data-provenance problem. If you fine-tune or continue-train on scraped, user-submitted or vendor-supplied corpora, you need provenance on that data and a review gate on new sources. Maps to LLM04:2025 Data and Model Poisoning and LLM03:2025 Supply Chain.

The AI supply chain is a live attack surface, not a hypothetical. In March 2026, the actor TeamPCP backdoored the aquasecurity/trivy-action GitHub Action; LiteLLM's CI auto-installed the poisoned scanner, which stole LiteLLM's PyPI publishing tokens; malicious litellm releases shipped days later with the payload injected directly into the distributed wheels, running credential harvesting, then lateral movement across Kubernetes clusters, then a persistent systemd backdoor. The campaign spanned GitHub Actions, Docker Hub, npm, PyPI and OpenVSX in five days (Resecurity, LiteLLM first-party update). Read that chain carefully: a security scanner was the delivery vehicle into an AI infrastructure package. The May 2026 "Mini Shai-Hulud" wave then targeted the AI developer supply chain specifically, across 170+ npm packages and 404 malicious versions (CSA Labs, Singapore CSA AD-2026-009).

Practical controls, all of which belong to Chapter 11's supply-chain discipline applied to your AI stack: pin GitHub Actions by commit SHA rather than tag, use short-lived OIDC credentials instead of long-lived publishing tokens, isolate publish jobs, and require an SBOM for AI components — the 2026 CISA minimum elements explicitly extend SBOM scope to AI systems and SaaS (CISA). Note also that SWID tags were removed as an accepted SBOM format in the 2026 revision; SPDX and CycloneDX are the two current formats. For your own model artefacts, apply the same provenance discipline: signed artefacts, a registry with access control, and a record of which training and fine-tuning data produced which version.

Model theft and extraction — high-volume query-based distillation, side-channel signals, and insider access to production artefacts — was LLM10:2023 Model Theft in the prior edition and remains a documented, practically demonstrated attack class (OWASP, Praetorian). If your model is a competitive asset, rate-limit per authenticated principal, monitor for the query patterns that characterize systematic distillation, and treat the production weights as crown-jewel data under Chapter 8's classification scheme.

Actionable takeaway: Before your next RAG system ships, run one test — query it as a user who should see nothing, and confirm they see nothing. If retrieval permissions are not enforced at query time, stop the launch. Everything else in this section is a slower burn; that one is a data breach on day one.

#7.7 Governing AI: the management system and the live clocks

Two standards, and they are complements rather than alternatives. The common real-world pattern is ISO/IEC 42001 as the certifiable management system, with NIST AI RMF as the risk operating model running inside it.

ISO/IEC 42001:2023 is the first international AI management system (AIMS) standard, published December 2023. It uses ISO's Harmonized Structure (Clauses 4–10), so it slots alongside ISO 27001 and 9001 with shared context, leadership, planning, support, operation, evaluation and improvement machinery, and it requires a Statement of Applicability justifying inclusion or exclusion of Annex A controls (AWS, ISMS.online). If you already run a 27001 ISMS, the integration cost is far lower than the sales pitch suggests, because the clause structure is the same one your internal audit program already knows.

NIST AI RMF 1.0 (AI 100-1), released 26 January 2023, has four functions — GOVERN, MAP, MEASURE, MANAGE — with GOVERN at the centre, cross-cutting the other three (NIST). Its Generative AI Profile, NIST AI 600-1 (26 July 2024) enumerates twelve risk categories unique to or exacerbated by generative AI and maps suggested actions onto that core. The twelve: CBRN information or capabilities; confabulation; dangerous, violent or hateful content; data privacy; environmental impacts; harmful bias or homogenization; human-AI configuration; information integrity; information security; intellectual property; obscene, degrading and/or abusive content; and value chain and component integration (NIST AI 600-1). Use those twelve as your impact-assessment scoping checklist and you will not have to invent one.

#What an AI governance program must actually produce

Not what it must say. What it must produce, in artefacts an auditor can pick up:

1. An AI policy with a named accountable owner — a role, not a committee with no charter (42001 Clause 5; AI RMF GOVERN).
2. An AI system inventory (§7.2). This is where most programs fail first.
3. An impact assessment per AI system, covering affected persons and society, scoped with the AI 600-1 categories.
4. Lifecycle controls — data governance and provenance, model development and validation, deployment gates, post-deployment drift monitoring.
5. Measurement — AI RMF MEASURE demands evidence, not assertion: evaluation results, red-team findings, and metrics tied to the risks you identified.
6. Third-party and supply-chain governance covering foundation models, APIs and fine-tuning vendors — AI 600-1's "value chain and component integration", mapping to CSF GV.SC.
7. An AI incident path — how a model failure, a jailbreak, a harmful output or a training-data leak enters your existing IR process. Wire AI incidents into RS.MA rather than inventing a parallel process. This is the seam most programs leave open, and Chapter 14.11 gives you the scenario playbook that closes it.
8. A Statement of Applicability, internal audit and management review, if you intend to certify.

The acceptable-use policy is the part employees will actually read, so keep it to one page and make it specific: which tools are sanctioned, which data classes may go into which tool, that customer and regulated data never enters an unsanctioned service, that AI output touching customers or code is reviewed by a named human, and that AI-assisted code is subject to the same review and provenance rules as any other. Add the two questions people genuinely need answered: where does my data physically go, and is it used for training. Answer both per sanctioned tool, in the policy, in plain language.

#The EU AI Act clocks, as they stand in September 2026

Most published guidance on this is now stale, so read this carefully. The Digital Omnibus on AI, adopted as Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force 27 July 2026 — days before the original 2 August 2026 high-risk deadline.

Two practical consequences. If you ship a GPAI model above the systemic-risk threshold, you have a live serious-incident duty to the AI Office today. If you ship an Annex III high-risk system, the AI Act clock does not start until December 2027 — but GDPR, product liability and, if it is a product with digital elements, the Cyber Resilience Act still bite in the meantime. Chapter 15 owns the full notification matrix; do not build a separate AI notification process beside it.

Data sovereignty and sub-processors deserve their own line in your vendor process rather than a paragraph in a policy nobody opens. For each sanctioned AI tool, record the processing region, whether the provider commits to not training on your data, the sub-processor list, and the notice period for adding a sub-processor. Then re-read that list quarterly, because your SaaS vendors are adding AI sub-processors faster than they are sending you emails about it. Chapter 11 owns the contract clauses.

Actionable takeaway: Produce artefacts 1, 2, 3 and 7 from the list above in the next quarter — policy with an owner, inventory, impact assessments, and the wire from AI incidents into your existing IR process. Those four convert an AI governance slide into an AI governance program, and every remaining artefact is easier once they exist.

#7.8 Using AI in defense: augment, do not abdicate

I use AI every day and it has made me measurably faster. It has also confidently told me things that were not true, in a tone of complete certainty, at exactly the moment I was tired enough to believe it. Both of those sentences have to be true at once for you to deploy this well.

#What automates well

High-volume, evidence-based tasks that are easy to verify after the fact: enrichment (reputation, geo and ASN, asset owner, user context, prior alert history), deduplication and correlation, ticket creation and routing, evidence collection, and closure of known-good alert classes with a documented rationale. Alert triage is the clearest production use case for AI agents today (Panther, Panther on triage agents).

#What automates badly

Anything irreversible, anything whose blast radius scales with a false positive, and anything requiring organizational context the automation does not have. Concretely: auto-isolating a device, auto-containing at scale, auto-attaching a quarantine SCP with org-wide reach, auto-deleting an OIDC provider that every role trusts, auto-draining a node that is holding your evidence.

#The documented failure modes

Two recur in production, and they are the two you must design against: overconfident closure backed by weak proof, and hallucinated detail in investigation narratives. Alongside them: hallucination on ambiguous alerts, blindness to novel attack patterns, and missing organizational context. The sharpest statement of the risk is worth memorizing — the agent acts on a confident hallucination before a human sees it (Panther, UnderDefense, Kaspersky).

The failure mode that scares me most is not the false negative. It is the beautifully written investigation narrative with three invented details that a tired analyst signs off at 04:00 because it reads like every good report they have seen. Fluency is not accuracy, and AI is extremely good at fluency.

#The deployment sequence, and why this order

Teams that succeed report the same phased pattern: enrichment first → summaries → autonomous closure of known-good alert classes, with each phase gated by measured analyst confidence in the previous one, not by a vendor's readiness assessment. Autonomy is then configured per action class — fully autonomous, human-on-the-loop, human-in-the-loop — with every agentic decision logged.

The order is not arbitrary. Enrichment is verifiable at a glance and fails safe. Summaries are where you learn your agent's specific hallucination signature on your data, and you need that knowledge before you grant it any authority. Skipping to autonomous closure means you find out about the hallucination signature from an incident review instead of a metric.

Measure two things and put them on the SOC dashboard: agent-closure rate, and spot-check accuracy from a random sample of agent-closed alerts re-reviewed by a human every week. If spot-check accuracy is not being measured, the closure rate is not a metric, it is a wish. Chapter 9 owns SOC metrics; Chapter 17 owns the automation architecture.

#AI-assisted detection engineering

This is the highest-value defensive use of AI that nobody demos, because it is unglamorous. AI is genuinely good at drafting a Sigma rule from a threat report, at proposing field mappings across log schemas, and at generating the benign-sample edge cases a human would not think to test. It is bad at knowing whether the rule will drown your queue on Monday.

So keep the human structure and let AI fill it. Palantir's Alerting and Detection Strategy (ADS) framework requires nine documented sections per detection: Goal, Categorization (ATT&CK mapping), Strategy Abstract, Technical Context, Blind Spots and Assumptions, False Positives, Validation, Priority, Response (palantir/alerting-detection-strategy-framework). The two sections teams skip are the two in bold, and those are precisely the two an AI will confabulate most convincingly, because they require knowing your environment. Write those two yourself.

Then make the CI pipeline do the arguing. A minimum viable detection-as-code pipeline has four gates: schema and lint on every rule; conversion succeeds for every configured backend; the rule fires against a stored true-positive sample; and the rule does not fire against a stored benign sample. That fourth gate is what catches AI-generated detection slop before it reaches an analyst (SigmaHQ, Splunk on detection-as-code). Chapter 9 owns the pipeline in detail.

Automated timeline generation is the other quiet win — assembling a first-draft chronology from logs during an incident, for a human to correct. Chapter 17 covers it; the rule here is simply that the draft is labeled a draft and the Scribe owns the authoritative timeline.

Actionable takeaway: Deploy AI in the SOC in the order enrichment → summaries → closure, and do not advance a phase until you have four weeks of measured spot-check accuracy on the current one. And keep the analyst's judgment on escalations — augment your people, do not replace the judgment that decides when to wake the executive sponsor.

#7.9 Defending against AI-enabled attackers

Now the other direction. Here is what is actually documented, with the vendor hype stripped out.

#Deepfakes in BEC and help-desk social engineering

Read the last column of the three blocked cases and notice what stopped them. Not a detection product. A human process check — an out-of-band channel anomaly and a shared-secret challenge. That is the mitigation your playbook must encode, because it is the one with a documented record of working.

The structural backdrop: voice phishing was the #2 initial infection vector in 2025, at 11% of all Mandiant investigations (M-Trends 2026), and DBIR 2026 similarly finds voice and text phishing convert better than email (Help Net Security). The FBI's IC3 reported $20.877B in total 2025 losses across 1,008,597 complaints — the first year over one million — with BEC at $3.047B across 24,768 complaints, and introduced "AI-related" as a formal crime descriptor for the first time: 22,000+ complaints and roughly $900M in losses (FBI).

The service desk is the other front door. CISA's advisory on Scattered Spider / UNC3944 / Octo Tempest, last updated 29 July 2025, documents attackers researching employees on business platforms and social media, then calling the IT help desk posing as them to obtain password resets and MFA token transfers to attacker-controlled devices, often splitting the request across separate contacts to evade detection (CISA AA23-320A). Add a convincing voice clone to that call and the last remaining control — the agent's instinct that something sounded off — is gone.

#What to actually do about it

Note what is not in that table: deepfake detection software. If it is already bundled in your stack, fine, use it as a signal. Do not build the control on it, and do not let anyone tell the board it is the mitigation. The three cases that were stopped were stopped by process.

Detection-side, wire these to your SIEM: help-desk-initiated MFA method changes correlated with a sign-in from a new device within a short window; payee bank-detail changes in the ERP correlated with recent inbound contact to that employee; and executive-impersonation domain and display-name lookalikes in mail flow. Chapter 14.9 has the full deepfake and AI-enabled social-engineering playbook; Chapter 14.2 has BEC and payment fraud; Chapter 4 has help-desk verification as an identity control. This section exists to tell you which controls are load-bearing, not to duplicate the response steps.

#AI-generated phishing at scale

Hoxhunt has run a longitudinal experiment since 2023 across more than 70,000 real-world simulations, pitting AI-generated phishing against elite human red-team spear phishing. AI went from **31% less effective in 2023, to 10% less in 2024, to 24% more effective by March 2025 — a 55-point swing in two years (Hoxhunt). Microsoft's MDDR 2025 states AI can make some phishing operations up to 50× more profitable by scaling targeting, and that Microsoft blocked $4B of fraud and scams between April 2024 and April 2025 (Microsoft MDDR 2025). ENISA's ETL 2025 found phishing and its variants — vishing, malspam, malvertising — accounted for roughly 60% of all initial infection vectors** across 4,875 EU incidents (ENISA ETL 2025).

The operational consequence is blunt: the spelling-and-grammar heuristic is dead, and any awareness training still teaching it is actively harmful because it gives people a confidence signal that no longer correlates with anything. Retrain on structure — unexpected urgency, a request to change a payment destination, a channel switch, an authentication prompt you did not initiate — and put the money into phishing-resistant MFA, which blocks over 99% of identity attacks even when the attacker already holds a valid username and password (Microsoft MDDR 2025). Chapter 4 owns that migration.

#AI-assisted exploit development, and the counterweight

This is the fastest-moving item in the chapter and the one most distorted by marketing, so here is the honest picture — a discovery/exploitation gap.

The capability is real. Anthropic's Project Glasswing, announced April 2026 and gated to roughly fifty partner organizations, found more than 10,000 high- or critical-severity vulnerabilities in systemically important software, including a 27-year-old OpenBSD flaw and a 16-year-old FFmpeg bug that automated fuzzing had tested around five million times without finding (Anthropic). Anthropic's own red-team assessment reports that its prior model failed at autonomous exploit development almost entirely, while the newer one reached a 72.4% success rate in the Firefox JS shell (Anthropic red team).

And now the number that should govern your patch queue. VulnCheck found that of 1,061 vulnerabilities attributable to AI-assisted discovery, only 14 — 1.3% — have been confirmed exploited in the wild; for Glasswing specifically, 23,019 findings yielded 126 published CVEs, of which exactly one has been confirmed exploited (VulnCheck). One.

Translation for your vulnerability program: AI-discovered CVEs are inflating your patch queue far faster than they are inflating your actual exploitation risk. Expect vendor advisory volume to rise sharply without a proportional rise in incidents. Prioritize on exploitation evidence — KEV and EPSS — not on CVE count, and do not let a rising open-vulnerability number panic anyone into abandoning risk-based prioritization. Chapter 10 owns that model.

Actionable takeaway: Implement the callback-on-file-number rule and the executive challenge phrase this month; they cost nothing and they are the two controls with a documented record of stopping real deepfake fraud. Then tell your board plainly that AI-assisted vulnerability discovery is raising advisory volume, not exploitation rates, so that your KEV-driven prioritization survives the next scary headline.

#7.10 Where to start with no budget

If you read this chapter and felt the budget anxiety, here is the sequence I would run with nothing but staff time. The order is deliberate: each step makes the next one cheaper.

Chapter 20 sequences this against everything else competing for the same twelve weeks.

Actionable takeaway: Do weeks 1 through 4 even if you do nothing else. Inventory, policy, sanctioned tool, callback rule. That is four items, no procurement, and it moves you from "we have no idea" to "we know and we have a floor."

Securing AI is mostly asset management with better marketing; governing it is mostly writing down what you already decided; defending with it works right up to the moment you stop checking its homework; and defending against it comes down to whether a human being will pick up the phone and dial a number they already trusted. Inventory it, scope it, log it, and keep a person on the escalations — the machines are fast, but they have never once been accountable.

#Chapter checklist

• AI-01A documented AI system inventory exists covering internally built, purchased, and vendor-embedded AI, with a named business owner per system and a "last verified" date no older than 90 days. [IG1] [ID.AM] [CIS 1] [CIS 2] [A.5.9]
• AI-02Shadow-AI discovery runs on a defined schedule across at least egress/DNS logs, third-party OAuth consent grants, and expense records, and its output feeds the inventory. [IG1] [ID.AM] [DE.CM]
• AI-03For every AI system in the inventory, the data classes it can read and the data classes it can write or act upon are recorded separately. [IG1] [ID.AM] [CIS 3]
• AI-04An AI acceptable-use policy is published, is one page or less, names sanctioned tools, and states for each whether customer data is used for training and in which region it is processed. [IG1] [GV.PO] [A.5.1]
• AI-05A single accountable owner for AI governance is named as a role in the policy, with documented decision authority for approving or refusing an AI system. [IG1] [GV.RR] [A.5.2]
• AI-06At least one sanctioned AI tool with a signed data processing agreement is available to every employee who has a business need. [IG1] [GV.SC]
• AI-07AI incidents — jailbreak, harmful output, model failure, training-data or retrieval leakage — are handled through the existing incident response process with a defined entry path, not a parallel process. [IG1] [RS.MA] [CIS 17] [A.5.24]
• AI-08Payment and payee-change requests require callback verification to a number held in the vendor or employee master record, never a number supplied in the request. [IG1] [PR.AT] [CIS 14]
• AI-09Help-desk account recovery and MFA re-enrolment require out-of-band verification against an authoritative source, with no documented exception for caller urgency. [IG1] [PR.AA] [CIS 6]
• AI-10Security awareness training teaches channel and structural indicators rather than spelling and grammar, and explicitly states that a video call or familiar voice is not proof of identity. [IG1] [PR.AT] [CIS 14] [A.6.3]
• AI-11Every AI system that can reach private data has documented evidence that at least one leg of the lethal trifecta — private data access, untrusted content ingestion, external communication — is severed, or has a mandatory human confirmation on every outbound action. [IG2] [PR.DS] [CIS 16]
• AI-12Retrieval-augmented systems enforce the requesting user's authorization at query time, and this is verified before launch with a deliberately low-privilege test account. [IG2] [PR.AA] [CIS 3]
• AI-13Every autonomous agent runs under its own identity — not a shared service account and not a standing human-delegated token — with a documented and time-tested revocation procedure. [IG2] [PR.AA] [CIS 5] [CIS 6]
• AI-14Agent runtimes do not carry ambient credentials they do not need: service-account token automounting is disabled where unnecessary and instance-metadata access is restricted. [IG2] [PR.PS] [CIS 4]
• AI-15Tools and MCP servers available to agents are version-pinned with recorded definition hashes, and any change to a tool definition raises an alert and requires re-approval before it takes effect. [IG2] [GV.SC] [DE.CM]
• AI-16Every tool an agent may invoke is classified as reversible or irreversible, and every irreversible action requires a named human approver. [IG2] [GV.RR] [RS.MI]
• AI-17Prompts, retrieved context, tool calls with parameters, and outputs are logged to the SIEM for every agent with access to production data, with retention matching the organization's incident-investigation window. [IG2] [DE.CM] [CIS 8]
• AI-18Every automated or agent-driven alert closure carries the evidence that justified it, and a weekly random sample of agent-closed alerts is re-reviewed by a human with the resulting accuracy recorded as a metric before any expansion of agent autonomy. [IG2] [DE.AE] [RS.AN]
• AI-19AI-drafted detections pass a four-gate CI pipeline — lint, backend conversion, fires on a stored true-positive sample, does not fire on a stored benign sample — before reaching production, and their Blind Spots and False Positives sections are human-authored. [IG2] [DE.CM] [CIS 8]
• AI-20AI supply-chain controls are applied to the AI stack specifically: CI actions pinned by commit SHA, short-lived OIDC credentials instead of long-lived publishing tokens, isolated publish jobs, and an SBOM covering AI components. [IG2] [GV.SC] [CIS 16] [A.5.19]
• AI-21Each AI system has a documented impact assessment scoped against the NIST AI 600-1 generative-AI risk categories, refreshed on material change. [IG2] [ID.RA] [ISO 42001]
• AI-22Third-party AI risk is managed in the vendor process: processing region, training-use commitment, sub-processor list and sub-processor change-notice period are recorded per sanctioned tool and reviewed quarterly. [IG2] [GV.SC] [CIS 15] [A.5.19]
• AI-23Fine-tuning and continued-training data sources have recorded provenance and a review gate for new sources, on the basis that a near-constant small number of poisoned documents can backdoor a model regardless of corpus size. [IG3] [GV.SC] [ID.RA]
• AI-24If the organization provides a GPAI model above the systemic-risk threshold or places a high-risk AI system on the EU market, the applicable AI Act obligations and their live dates are identified in writing by counsel and reflected in the notification matrix. [IG3] [GV.OC] [RS.CO]
• AI-25Production model artefacts are treated as classified assets: access-controlled registry, signed artefacts, per-principal API rate limiting, and monitoring for query patterns consistent with systematic extraction. [IG3] [PR.DS] [CIS 3]

#Sources

1. Anthropic — Disrupting the first reported AI-orchestrated cyber espionage campaign — https://www.anthropic.com/news/disrupting-AI-espionage
2. Sysdig — Agentic threat actor hits the orchestration plane — https://webflow.sysdig.com/blog/agentic-threat-actor-hits-the-orchestration-plane-ai-agent-driven-container-escape
3. Mandiant / Google Cloud — M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
4. NIST — Draft NIST guidelines rethink cybersecurity in the AI era — https://www.nist.gov/news-events/news/2025/12/draft-nist-guidelines-rethink-cybersecurity-ai-era
5. NIST IR 8596 (preliminary draft) — Cybersecurity Framework Profile for Artificial Intelligence — https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8596.iprd.pdf
6. AppOmni — Salesloft Drift / Salesforce UNC6395 analysis — https://appomni.com/blog/drift-breach-salesforce-unc6395-saas-prevention/
7. FINRA — Salesloft Drift AI supply chain attack — https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack
8. The Hacker News — Malicious Nx packages in "s1ngularity" attack — https://thehackernews.com/2025/08/malicious-nx-packages-in-s1ngularity.html
9. GitGuardian — The Nx s1ngularity attack: inside the credential leak — https://blog.gitguardian.com/the-nx-s1ngularity-attack-inside-the-credential-leak/
10. OWASP GenAI — Top 10 for LLM Applications — https://genai.owasp.org/llm-top-10/
11. OWASP — Top 10 for LLMs v2025 (PDF) — https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
12. OWASP GenAI — LLM Top 10 2026 — https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
13. OWASP GenAI — Top 10 for Agentic Applications 2026 — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
14. OWASP — Agentic Security Initiative — https://genai.owasp.org/initiatives/agentic-security-initiative/
15. MITRE ATLAS — atlas-data repository — https://github.com/mitre-atlas/atlas-data
16. arXiv — analysis of EchoLeak (CVE-2025-32711) — https://arxiv.org/abs/2509.10540
17. HackTheBox — CVE-2025-32711 EchoLeak Copilot vulnerability — https://www.hackthebox.com/blog/cve-2025-32711-echoleak-copilot-vulnerability
18. Simon Willison — MCP prompt injection — https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
19. Microsoft — The state of MCP security in 2026 — https://techcommunity.microsoft.com/blog/microsoft-security-blog/the-state-of-mcp-security-in-2026/4531327
20. Anthropic — Small samples can poison LLMs of any size — https://www.anthropic.com/research/small-samples-poison
21. The Alan Turing Institute — LLMs may be more vulnerable to data poisoning than we thought — https://www.turing.ac.uk/blog/llms-may-be-more-vulnerable-data-poisoning-we-thought
22. Resecurity — The LiteLLM supply chain attack (TeamPCP "SANDCLOCK") — https://www.resecurity.com/blog/article/the-litellm-supply-chain-attack-teampcp-sandclock-cicd-credential-harvesting-campaign-via-a-backdoored-trivy-github-action
23. LiteLLM — Security update, March 2026 — https://docs.litellm.ai/blog/security-update-march-2026
24. Cloud Security Alliance Labs — Shai-Hulud AI supply chain research note — https://labs.cloudsecurityalliance.org/research/csa-research-note-shai-hulud-ai-supply-chain-20260517-csa-st/
25. Singapore CSA — Advisory AD-2026-009 — https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-009/
26. CISA — 2026 Minimum Elements for a Software Bill of Materials — https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
27. OWASP — LLM10:2023 Model Theft — https://genai.owasp.org/llmrisk2023-24/llm10-model-theft/
28. Praetorian — Stealing AI models through the API — https://www.praetorian.com/blog/stealing-ai-models-through-the-api-a-practical-model-extraction-attack/
29. AWS Security Blog — AI lifecycle risk management: ISO/IEC 42001:2023 for AI governance — https://aws.amazon.com/blogs/security/ai-lifecycle-risk-management-iso-iec-420012023-for-ai-governance/
30. ISMS.online — ISO 42001 Annex A controls — https://www.isms.online/iso-42001/annex-a-controls/
31. NIST — AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
32. NIST AI 600-1 — Generative AI Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
33. EU AI Act — Article 73 — https://artificialintelligenceact.eu/article/73/
34. European Commission AI Act Service Desk — Article 73 — https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-73
35. EU AI Act — Article 99 (penalties) — https://artificialintelligenceact.eu/article/99/
36. EU AI Act — Article 55 — https://artificialintelligenceact.eu/article/55/
37. Gibson Dunn — EU AI Act Omnibus: postponed high-risk deadlines — https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
38. Cooley — Digital AI Omnibus delays key deadlines — https://cdp.cooley.com/digital-ai-omnibus-delays-key-deadlines-introduces-new-rules/
39. Panther — Best AI tools for security alert triage — https://panther.com/blog/ai-tools-security-alert-triage
40. Panther — AI agents for incident triage and prioritization — https://panther.com/blog/ai-agents-incident-triage-prioritization
41. Panther — Agentic security orchestration: agents vs. humans — https://panther.com/blog/agentic-security-orchestration
42. UnderDefense — AI SOC automation in 2026 — https://underdefense.com/blog/ai-soc-automation/
43. Kaspersky — Building an autonomous SOC — https://me-en.kaspersky.com/blog/autonomous-soc-2026-challenges-and-solutions/25865/
44. Palantir — Alerting and Detection Strategy framework — https://github.com/palantir/alerting-detection-strategy-framework
45. SigmaHQ — https://sigmahq.io/
46. Splunk — What is detection as code — https://www.splunk.com/en_us/blog/learn/detection-as-code.html
47. CNN — Arup deepfake scam loss, Hong Kong — https://www.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
48. OECD AI Incidents Monitor — WPP CEO deepfake attempt — https://oecd.ai/en/incidents/2024-05-10-e24d
49. AI Incident Database — Ferrari voice-clone attempt — https://incidentdatabase.ai/cite/966/
50. Adaptive Security — deepfake attack examples (LastPass case) — https://www.adaptivesecurity.com/blog/11-deepfake-attack-examples-2026
51. FBI — Cryptocurrency and AI scams bilk Americans of billions (IC3 2025) — https://www.fbi.gov/news/press-releases/cryptocurrency-and-ai-scams-bilk-americans-of-billions
52. CISA — Advisory AA23-320A (Scattered Spider) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
53. Help Net Security — Verizon 2026 DBIR findings — https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
54. Hoxhunt — AI-powered phishing vs. humans — https://hoxhunt.com/blog/ai-powered-phishing-vs-humans
55. Microsoft — Digital Defense Report 2025 — https://www.microsoft.com/en-us/corporate-responsibility/topics/cybersecurity/reports/microsoft-digital-defense-report-2025/
56. ENISA — Threat Landscape 2025 — https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf
57. Anthropic — Project Glasswing — https://www.anthropic.com/glasswing
58. Anthropic Red Team — Mythos Preview — https://red.anthropic.com/2026/mythos-preview/
59. VulnCheck — State of Exploitation 1H-2026 — https://www.vulncheck.com/blog/state-of-exploitation-1h-2026