Appendix A — Advanced glossary

Terms introduced in this guide, not repeated from G1's Appendix A. Assume you know CIA, TLS, OAuth basics, STRIDE, and the OWASP Top 10 already.

ABAC          Attribute-Based Access Control. Policy over attributes of
             principal/action/resource/context. (Ch 25)
Actor token   In OAuth token exchange (RFC 8693), the identity token proving
             which SERVICE is making the call on a user's behalf. (Ch 24)
ADS           Alerting and Detection Strategy. Palantir's per-detection
             documentation template: hypothesis, ATT&CK mapping, data
             source, false positives, priority, response. (Ch 51)
ASVS          OWASP Application Security Verification Standard. Three
             levels (baseline/sensitive-data/critical) used as a design-
             review target. (Ch 58)
Attack path   A chain of individually-permitted steps from an attacker's
             position to a goal; severity is a property of the whole
             chain, not its worst edge. (Ch 1)
BOLA/IDOR     Broken Object-Level Authorization -- see G1 Appendix A;
             solved structurally here via ReBAC (Ch 25) and RLS (Ch 27).
Break-glass   A documented, heavily-logged emergency access path used
             outside normal approval flow. (Ch 49, 63)
Chokepoint    An edge appearing in many high-value attack paths; the
             highest-ROI place to cut. (Ch 1)
CIEM          Cloud Infrastructure Entitlement Management -- tooling for
             the IAM-sprawl problem across a cloud estate. (Ch 6)
CISA KEV      Known Exploited Vulnerabilities catalog -- CVEs with
             CONFIRMED active exploitation. The strongest patch-priority
             signal available. (Ch 59)
Crypto-shredding  Destroying the key that wraps a dataset, rendering it
             permanently unrecoverable everywhere it's stored -- the
             mechanism behind practical erasure across backups. (Ch 44, 46)
CSA CCM       Cloud Security Alliance Cloud Controls Matrix -- a free,
             cross-framework compliance control mapping. (Ch 61)
DAM           Database Activity Monitoring -- detects anomalous QUERY
             PATTERNS from otherwise-authorized accounts. (Ch 48)
DAST / IAST   Dynamic / Interactive Application Security Testing -- runtime
             analysis, complementing SAST's static analysis. (Ch 58)
Deny policy   In cloud IAM, an explicit Deny that overrides every Allow
             from any source (identity policy, resource policy, SCP). The
             fastest containment lever in cloud IR. (Ch 6, 55)
Differential privacy  A formal guarantee (parameterised by epsilon) that a
             query's output is nearly indistinguishable whether or not any
             one individual's data was included. (Ch 45)
DPF           EU-US Data Privacy Framework -- the current mechanism for
             EU-to-US personal data transfer, successor to Privacy
             Shield/Safe Harbor. (Ch 47)
DSAR          Data Subject Access Request -- a request under GDPR/CCPA to
             access or delete one's personal data. (Ch 46)
EPSS          Exploit Prediction Scoring System -- a daily-updated 0-1
             probability that a CVE will be exploited in the wild in the
             next 30 days. Complements CVSS's severity score with a
             likelihood score. (Ch 59)
FAIR          Factor Analysis of Information Risk -- quantifies risk in
             dollar terms as Loss Event Frequency x Loss Magnitude. (Ch 62)
FPE           Format-Preserving Encryption (NIST SP 800-38G) -- encrypts a
             value while preserving its format (a 16-digit card number
             stays 16 digits). (Ch 43)
gVisor / Kata Sandboxed container runtimes: a user-space kernel (gVisor)
             or a lightweight per-pod VM (Kata) for stronger tenant
             isolation than a shared-kernel container. (Ch 21)
IRSA          IAM Roles for Service Accounts -- AWS EKS's mechanism giving
             a Kubernetes pod short-lived, scoped AWS credentials via OIDC
             federation. (Ch 20)
JIT access    Just-in-time access -- granted on request, time-boxed,
             auto-revoked, replacing standing permanent grants. (Ch 49)
KEV           see CISA KEV.
KMS key hierarchy  Root/master key -> per-environment or per-tenant CMK ->
             ephemeral per-record DEK. Splitting the hierarchy makes
             rotation cheap at the top and blast radius small at the
             bottom. (Ch 44, Part 2 Ch 9)
KubeHound / PMapper / CloudFox  Attack-path graphing tools for Kubernetes
             and AWS respectively -- the offensive/defensive analogue of
             BloodHound for cloud and cluster identity. (Ch 1, 6, 17)
Pyramid of Pain  David Bianco's model: detections on hashes/IPs are cheap
             for an attacker to evade; detections on TTPs are expensive to
             evade. Spend effort near the top. (Ch 51)
ReBAC / Zanzibar  Relationship-Based Access Control -- authorization
             expressed as a graph of tuples (object#relation@user),
             answering "can X access Y" and "what can X access" natively.
             Google's Zanzibar paper is the origin; OpenFGA and SpiceDB
             are open implementations. (Ch 25)
Reachability analysis  Determining whether a vulnerable code path in a
             dependency is actually called by your application --
             dramatically cuts a noisy SCA backlog. (Ch 59)
RLS           Row-Level Security -- a database engine feature (PostgreSQL)
             that makes tenant scoping mandatory and implicit on every
             query, closing the "forgot the WHERE clause" leak class.
             (Ch 27)
RoPA          Record of Processing Activities -- GDPR Art. 30's required
             inventory of what personal data you process, why, and for
             how long. (Ch 41)
Schrems I/II  CJEU rulings invalidating Safe Harbor (2015) and Privacy
             Shield (2020) as EU-US transfer mechanisms over US
             surveillance-law concerns. (Ch 47)
SCP           Service Control Policy -- an AWS Organizations guardrail
             that CAPS (never grants) the permissions available to member
             accounts. (Ch 7)
SIEM/SOAR     Security Information and Event Management (correlates and
             alerts on telemetry) / Security Orchestration, Automation and
             Response (automates the response playbook). (Ch 52, 55)
Sigma         A portable, YAML-based detection-rule format compiled to
             many SIEM query languages -- write once, deploy anywhere.
             (Ch 51)
SLSA          Supply-chain Levels for Software Artifacts -- a build-
             integrity maturity model (L1-L3) for provenance and build
             isolation. (Part 3 Ch 13)
SOC 2 / ISO 27001  SOC 2 is an AUDIT against Trust Services Criteria; ISO
             27001 is a CERTIFICATION of a whole management system
             (an ISMS), not just a control list. (Ch 61)
SPIFFE / SPIRE  A standard (SPIFFE) and implementation (SPIRE) for
             automatic, short-lived, attested workload identity -- the
             foundation for zero-trust service-to-service mTLS. (Ch 23)
SSDF          NIST Secure Software Development Framework (SP 800-218) --
             baseline SSDLC practices. (Ch 58)
SVID          SPIFFE Verifiable Identity Document -- the actual credential
             (an X.509 cert or a JWT) carrying a workload's SPIFFE ID.
             (Ch 23)
Tenant isolation  Structural guarantees (RLS, per-tenant keys, per-store
             scoping) that one customer's data is unreachable to another,
             independent of any single query remembering a filter. (Ch 27)
Token exchange  RFC 8693 -- a service exchanges an incoming token plus its
             own identity for a NEW, audience-scoped, short-lived token for
             a specific downstream call, preventing cross-service replay.
             (Ch 24)
Tokenization  Replacing a sensitive value with a non-reversible (outside a
             vault) placeholder -- unlike encryption, removes entire
             systems from compliance scope (e.g. PCI). (Ch 43)
XSW           XML Signature Wrapping -- a SAML attack where signature
             VALIDATION checks one XML element but business logic CONSUMES
             a different, injected, unsigned one. (Ch 39)

Appendix B — Cloud attack-path reference (AWS / GCP / Azure)

Consolidated from Part 2. Use as a checklist when auditing an account, or as attack primitives to test for in your own sandbox (Chapter 0.6 applies).

Privilege-escalation primitives

Metadata endpoints and their gate

Defence baseline (all three): IMDSv2/header-only metadata + hop-limit 1; workload identity (IRSA/Workload Identity/Managed Identity) scoped per-service with a trust condition pinned to the exact namespace/service account; no egress from application pods to the metadata IP at the network layer as a backstop (Part 2 Ch 8, Part 4 Ch 19).

Guardrail checklist (Part 2 Ch 7)

[ ] Management/root account runs nothing; SCPs/Org Policy don't apply there --
    treat it as break-glass only.
[ ] Deny: disabling CloudTrail/Config/GuardDuty, writing to log-archive,
    leaving the org, non-approved regions, root actions, iam:CreateUser/
    CreateAccessKey outside break-glass, making resources public, disabling
    default encryption, RunInstances without IMDSv2.
[ ] Delegate GuardDuty/Security Hub/Config admin to a dedicated security
    account.
[ ] Continuous scanning: PMapper/cloudsplaining/Access Analyzer (AWS),
    equivalent GCP/Azure posture tools, in CI.

Appendix C — Kubernetes security checklist

Consolidated from Part 4. Run this against any cluster you operate.

Build-time (image and manifest)

[ ] Image pinned by DIGEST, from an approved registry, SIGNED (cosign
    keyless) with SBOM + SLSA provenance attestations.
[ ] Dockerfile: non-root user, minimal/distroless base, no package
    manager in the final layer.
[ ] Manifest: runAsNonRoot, allowPrivilegeEscalation:false,
    capabilities.drop:["ALL"], seccompProfile RuntimeDefault,
    readOnlyRootFilesystem:true, no hostPath/hostPID/hostNetwork/hostIPC,
    automountServiceAccountToken:false unless the workload calls the API,
    resource requests/limits set, hostUsers:false where supported.

Cluster-level

[ ] kube-apiserver: --anonymous-auth=false; RBAC (+ Node authorizer)
    only; no client cert with O=system:masters outside a documented root.
[ ] etcd: mTLS, encrypted at rest (KMS/aesgcm provider), isolated network,
    encrypted + access-controlled backups.
[ ] kubelet: --anonymous-auth=false, --authorization-mode=Webhook;
    unreachable from workload pods (NetworkPolicy).
[ ] CNI supports and enforces NetworkPolicy (Calico/Cilium/Antrea --
    NOT flannel alone).
[ ] Pod Security Admission: restricted enforced on every non-system
    namespace (rolled out via warn/audit first); system-namespace
    exemptions are named explicitly, not blanket.
[ ] Admission policy (Kyverno/Gatekeeper/VAP) enforcing: signed images by
    digest, no unapproved serviceAccountName on pod create, default-deny
    NetworkPolicy generated per namespace, no hostPath outside a named
    system-DaemonSet allowlist.

RBAC

[ ] No workload SA has: cross-namespace `secrets` read, pods/exec on
    others' pods, create on clusterrolebindings/rolebindings, escalate/
    bind/impersonate, control of webhook configurations.
[ ] Bound, projected SA tokens (1.24+) -- no legacy long-lived Secret-type
    tokens outstanding (audit for them).
[ ] Humans authenticate via OIDC/SSO mapped to least-privilege Roles, not
    a static admin kubeconfig.
[ ] RBAC graphed continuously (KubeHound/rbac-police/KubiScan) in CI,
    zero escalation edges to cluster-admin from a workload SA.

Network

[ ] Default-deny NetworkPolicy (ingress+egress) in every namespace, with
    explicit DNS + service-to-service + ingress-controller allows.
[ ] 169.254.169.254/32 egress denied at the NetworkPolicy layer as
    defence in depth (Appendix B's IMDS gate is the primary control).
[ ] Mesh mTLS (SPIFFE identities) + AuthorizationPolicy scoping east-west
    calls to their real, intended callers.
[ ] FQDN egress allowlisting (Cilium/Calico CRDs) for third-party API
    destinations instead of a blanket outbound allow.

Runtime

[ ] Falco or Tetragon deployed (eBPF), tuned (baseline + allowlist known-
    good, page only on high-fidelity rules).
[ ] At minimum: shell-in-container, container-escape-syscall-pattern,
    unexpected-outbound, and API-server-contact-from-unexpected-pod rules
    live and validated against a real technique run.
[ ] Multi-tenancy model matches trust level: namespace-per-tenant only for
    TRUSTED workloads; gVisor/Kata + node isolation, or cluster-per-tenant,
    for untrusted/arbitrary code.

Appendix D — Distributed authorization patterns reference

Consolidated from Part 5.

IDENTITY LAYER (Ch 23)
  every service gets a SPIFFE ID (spiffe://trust-domain/ns/x/sa/y) and a
  short-lived SVID from SPIRE, obtained via the Workload API with no
  bootstrap secret. Mesh mTLS uses this for channel authentication.

PROPAGATION LAYER (Ch 24)
  the end-user's identity travels as an AUDIENCE-SCOPED, SHORT-LIVED
  token, re-minted at every hop via RFC 8693 token exchange:
    subject_token (incoming) + actor_token (this service's identity)
    + audience (the exact next hop) -> a new token with aud=next-hop,
    sub=end-user, act={delegation chain}, exp~60s.
  EVERY service validates aud == itself. This single check kills
  cross-service replay.

DECISION LAYER (Ch 25)
  RBAC (roles) for coarse, stable structure.
  ABAC (Cedar, OPA/Rego) for conditional/contextual rules.
  ReBAC/Zanzibar (OpenFGA, SpiceDB) for ownership, sharing, hierarchy,
    and group membership -- and the ONLY one of the three with a native
    answer for "what can this user see" (ListObjects) without N+1 checks.
  PEP (in every service) -> PDP (embedded-cached or central) -> PIP
    (the tuple/attribute store) -> PAP (where policy/tuples are authored).
  Handle the "new enemy" problem with the engine's consistency tokens
  (zedtokens/zookies) on security-sensitive reads.

DATA LAYER (Ch 27)
  RLS + FORCE (non-owner, non-BYPASSRLS app role) makes tenant scoping
  MANDATORY per query, not a WHERE clause you remember.
  Per-tenant KMS-wrapped DEKs back this up even against a full RLS
  bypass (ciphertext without the tenant's key).
  Every OTHER store (search, cache, object storage, events) needs its
  OWN tenant scoping -- index-per-tenant, key-prefix, bucket-prefix +
  IAM condition, topic/ACL-per-tenant.
  Test "as tenant B" on every read path; canary tenants with sentinel
  records.

RESILIENCE LAYER (Ch 28)
  timeouts everywhere -> bounded jittered retries with a retry BUDGET ->
  circuit breakers per dependency -> bulkheads (separate pools per
  dependency/tenant) -> rate limits + per-tenant quotas -> load shedding
  under overload. Availability is a security property; treat DoS/
  denial-of-wallet as an incident class.

Appendix E — Data-protection decision tables

Consolidated from Part 7.

What to encrypt, and how

The erasure decision, per store

De-identification technique, by use case

Transfer mechanism, by destination

Appendix F — Detection coverage map (ATT&CK technique → data source → rule idea)

A starter map, seeded from this guide's own labs (Part 8 Ch 54's method). Extend it with your own attack-path findings — this is a template, not a complete list.

Appendix G — Answers to "Check yourself"

Brief answers, in chapter order. If your answer matches in substance, you're fine — page back to the chapter for anything that doesn't click.

Chapter 1 — Attack paths

1. A chain of individually-permitted steps from an attacker's position to a goal; severity is a property of the whole walk because a chain of "medium" edges can reach a critical goal with no detection, which is worse than any single edge's rating suggests.
2. An edge appearing in many high-value paths — cutting it removes the most risk for the least effort, often with no application change (e.g. IMDSv2).
3. Reachability of the start × feasibility of each edge × value of the goal ÷ probability of detection in time.
4. PMapper/Cartography (cloud), BloodHound/AzureHound (AD/Entra), KubeHound (Kubernetes).
5. Permissions, routes, and deployments change constantly; a graph computed once is stale within days.

Chapter 2 — Adversary emulation

1. Pentest: find as many vulns as possible, time-boxed, a findings report. Red team: achieve a specific objective stealthily, testing detection/ response. Purple team: run techniques openly with defenders present, building detection coverage collaboratively.
2. Prevented (best), Detected, Logged (evidence exists but no rule fired), Missed (worst).
3. Coverage of irrelevant TTPs is vanity; prioritise from your actual threat model and assets.
4. Atomic Red Team (endpoint); Stratus Red Team (cloud/containers).
5. A visual (technique × prevent/detect/gap) map of honest security posture, reportable to leadership.

Chapter 3 — Assume breach

1. Orient (minimise discoverable info) → Escalate (remove privesc edges, permission boundaries) → Move (segmentation + identity on every hop) → Persist (short-lived creds, immutable infra) → Collect (data-access limits, canaries) → Exfil (egress default-deny, DLP).
2. A written statement of exactly what's exposed if a component is fully compromised; it's a finding when the answer is "everything."
3. They're the attacker's foothold for surviving beyond the initial compromise — a stolen long-lived credential keeps working indefinitely.
4. Contain = impossible; Detect = loud but not prevented. Want both: contain what you can, detect what you can't.
5. Everything inside trusts everything inside (no internal segmentation or identity checks); dangerous because one foothold reaches all of it.

Chapter 4 — Threat modeling at scale

1. Tier 0 (every change, a 3-prompt note) → Tier 1 (new service, full STRIDE + DFD) → Tier 2 (crown jewels, attack trees/emulation plan) → Tier 3 (pre-launch/regulatory, full PASTA or red team).
2. Attack trees when decomposing one attacker goal into sub-goals; attack paths when the system is graph-shaped (cloud/k8s/microservices) and often more useful than STRIDE there.
3. It lives in the repo, is reviewed in PRs, has tracked issues with owners, and is re-run after incidents and architecture changes.
4. Privacy-specific harms: linkability, identifiability, non-repudiation-as- harm, detectability, disclosure, unawareness, non-compliance.
5. RLS + FORCE, context-from-claim-only (never body), and the "as tenant B" test suite — three independent layers.

Chapter 5 — The cloud security model

1. IaaS: you patch the OS. PaaS: provider patches the engine, you configure access/network/encryption. FaaS: provider runs everything, you own code + its role + its triggers.
2. Human (federated via SSO), workload (EC2 instance profile/IRSA/GCP SA/ Azure managed identity), external (cross-account role assumption).
3. An explicit Deny always wins; an action is allowed only if some Allow applies and no Deny applies and every ceiling (SCP/boundary/session) also allows.
4. Management events show API calls; data events show object-level reads/ writes — the actual exfiltration.
5. Both the IAM identity policy AND the KMS key policy must allow it.

Chapter 6 — Cloud IAM privesc

1. Implicit deny → explicit Deny anywhere always wins → SCP must allow → resource policy can grant (same-account) → identity policy must allow → permission boundary must also allow → session policy must also allow.
2. Grant-yourself: CreatePolicyVersion+SetAsDefault, AttachUserPolicy, PutUserPolicy. PassRole+service: PassRole+RunInstances, PassRole+CreateFunction+invoke.
3. A Resource scoped to specific role ARNs, plus an iam:PassedToService condition.
4. It caps the maximum permissions an identity policy can grant, so even a successful privesc primitive can't exceed the boundary.
5. iam.serviceAccounts.actAs — dangerous because the default Compute Engine service account is often granted project Editor.
6. The management/root account — SCPs don't restrict it, so it should run nothing and be break-glass only.

Chapter 7 — Org guardrails

1. Account boundaries are the cheapest strong isolation the cloud gives you — separate blast radius without new technology.
2. It caps maximum available permissions (never grants); it doesn't apply to the management account.
3. Deny disabling logging/GuardDuty, deny writing to log-archive, deny leaving the org, deny non-approved regions, deny making resources public.
4. A pre-packaged bundle of account factory + baseline guardrails + central logging as IaC, rather than hand-rolling the same thing.
5. So findings aggregate centrally and workload accounts can't disable their own monitoring.
6. A tested, alarmed break-glass access path excluded from the restrictive SCP.

Chapter 8 — Cloud network security

1. SG: stateful, instance-level, primary tool. NACL: stateless, subnet-level, coarse backstop.
2. A private path to a cloud service without traversing the internet; a policy on it restricts which resources/accounts it can reach.
3. It's the exfiltration control — layers: SG egress rules, an egress proxy/firewall with an FQDN allowlist, DNS Firewall, and VPC endpoint policies.
4. Databases don't need the internet; a NAT route there is an exfil lane with no legitimate purpose.
5. Network reachability + identity-based refusal (mTLS/SPIFFE authz) — matters because assume-breach means a reachable service must still refuse unauthenticated/wrong-identity calls.
6. It restricts the bucket to requests coming through that specific VPC endpoint, so even valid IAM creds can't reach it over the internet.

Chapter 9 — KMS and envelope encryption

1. The raw key material — you get a hardware-backed root of trust and centrally-enforced, audited access decisions.
2. GenerateDataKey → get plaintext DEK + encrypted DEK → AEAD-encrypt with the plaintext DEK → store encrypted DEK + ciphertext → zero the plaintext DEK; decrypt reverses via KMS Decrypt.
3. Extra authenticated data bound to a ciphertext (e.g. tenant/purpose) — enables fine-grained key-policy conditions and CloudTrail filtering.
4. Both IAM and the key policy; the KEY POLICY is the real tenant-isolation control.
5. Destroying the wrapping key, rendering everything it wrapped permanently unrecoverable — requires the key boundary (per-tenant/per-subject) to have been designed in and no plaintext copies elsewhere.
6. RDS storage encryption is set at creation; retrofitting needs a snapshot, copy-with-encryption, and restore.

Chapter 11 — IaC security

1. Computed values, module outputs, and variable-driven config are invisible in source but visible in the plan's actual resource attributes.
2. Every resource attribute in plaintext, including generated secrets; it should live in an encrypted, access-restricted remote backend.
3. A committed provider lockfile with checksums; module sources pinned to a version or commit SHA, never a mutable branch ref.
4. Reality diverging from code; scheduled terraform plan and cloud-native config/posture scanning (Config, Prowler, ScoutSuite).
5. It runs arbitrary commands on the CI runner with whatever privileges that run has.
6. No public admin ports; mandatory customer-CMK encryption; no iam:PassRole with Resource:"*".

Chapter 12 — CI/CD as attack surface

1. Direct: modifying the CI config file itself in a PR. Indirect: modifying a file (Makefile, build script) the fixed CI config runs, without touching the workflow file.
2. It checks out and runs untrusted PR code while carrying the base repo's secrets and a write token.
3. Exchanging a CI-provider OIDC token for a short-lived cloud role session instead of static keys; the misconfig is a trust sub scoped too broadly (whole org/any branch) instead of pinned to the exact repo+ref/environment.
4. Fork PRs run attacker code on your infra; job N can poison the cache/ environment for job N+1; non-ephemeral runners persist compromise.
5. Attacker-controlled event fields (PR title, branch name) interpolated directly into a run: shell block execute as commands; fix by passing them via env: and referencing the variable, not ${{ }} inline.
6. Insufficient flow control (no review gates), inadequate IAM, dependency chain abuse, poisoned pipeline execution, insufficient credential hygiene — each with the corresponding control from the chapter.

Chapter 13 — Provenance and admission

1. L1: provenance exists. L2: signed, from a hosted build platform. L3: the build platform itself is hardened and provenance is non-falsifiable.
2. Builder identity, exact source commit, build config, and inputs — not just "someone with a key signed this."
3. Fulcio issues short-lived certs bound to an OIDC identity (no long-lived signing key to steal); Rekor is a public transparency log of the signatures/attestations.
4. Signature validity, the signing identity matches the expected pipeline, required attestations present (SBOM, provenance, scan), image referenced by digest from an approved registry.
5. No network access and pinned/content-addressed inputs, so a poisoned dependency or mirror can't sneak in during the build.
6. It makes the secure path the easy/default one, so teams that skip it are the ones flagged (unsigned images fail admission), aligning incentives.

Chapter 15 — Container internals

1. pid (process tree), net (interfaces/routes), mnt (filesystem), uts (hostname), user (uid/gid mapping — the "strong" one, often NOT on by default), ipc, cgroup.
2. Near-root: mount, pivot_root, many syscalls; CAP_SYS_MODULE lets you load an arbitrary kernel module — total host compromise.
3. privileged:true, hostPath (esp. /, runtime sockets), hostPID, hostNetwork, dangerous capabilities without privileged (CAP_SYS_ADMIN/CAP_SYS_PTRACE).
4. Together: no writable filesystem, no privilege gain, minimal syscalls available, and not running as root — closes most of the practical escape classes at once.
5. It IS the container runtime from inside; you can create a new, privileged container mounting the host filesystem.
6. Kernel/runtime CVEs (runc, cgroups, Dirty Pipe/COW) bypass a perfect pod spec entirely.

Chapter 16 — Kubernetes architecture

1. kube-apiserver (all traffic and authz decisions), etcd (all state including Secrets), kubelet (node credentials + on-node Secret access).
2. system:node:<name>; the Node authorizer lets it read Secrets/ConfigMaps/ tokens of every pod scheduled on its node.
3. Secrets are only base64 unless encryption-at-rest is configured — raw access is every Secret in the cluster in plaintext.
4. It must actually enforce NetworkPolicy objects — flannel does not.
5. pod→node (an escape class), node→cluster (kubelet credentials + Node authorizer), any→etcd (direct cluster-admin equivalent).
6. It sees or can rewrite every matching API request cluster-wide, or wedge the whole control plane if failurePolicy: Fail.

Chapter 17 — Kubernetes RBAC

1. Bound tokens are audience-scoped, time-limited (~1h), auto-rotated, and invalid once the pod is gone; legacy Secret tokens are long-lived and non-expiring.
2. It lets you schedule a pod naming a more-privileged serviceAccountName, or a hostPath/privileged pod that escapes to the node.
3. escalate: create a role with more permissions than you hold. bind: bind a role you don't fully possess. impersonate: act as another user/ group/SA (e.g. system:masters).
4. It's a hardcoded, RBAC-bypassing cluster-admin group — a permanent backdoor if ever issued.
5. Cross-namespace secrets read, pods/exec on others' pods, create on role/clusterrole bindings.
6. KubeHound, rbac-police, KubiScan.

Chapter 18 — Admission control

1. Mutating webhooks (can change the object) → schema validation → validating webhooks (accept/reject) → validating admission policies (CEL, no webhook).
2. privileged/baseline/restricted; enforce/audit/warn. Roll out warn+audit first, fix violations, then flip to enforce.
3. For simple, critical allow/deny rules where you want zero webhook-outage risk (no extra pod in the request path).
4. It can block ALL matching API writes cluster-wide if the webhook becomes unavailable; mitigate with tight selectors, failurePolicy: Ignore for non-critical rules, HA webhooks, or prefer VAP.
5. Approved-registry+digest images, default-deny NetworkPolicy generation, a serviceAccountName allowlist, required labels, no unapproved LoadBalancer Services.
6. Attackers use whichever field a policy doesn't cover — initContainers, ephemeralContainers, and every workload-kind template need the same rule.

Chapter 19 — Kubernetes network security

1. Default-allow to everything; a pod becomes default-deny for a direction the moment ANY policy selects it for that direction.
2. Support and actively enforce NetworkPolicy objects; flannel alone does not.
3. L7 rules (HTTP method/path), FQDN-based egress, DNS-aware/cluster-wide policies.
4. NetworkPolicy: coarse reachability. Mesh AuthorizationPolicy: identity- based, who-is-calling authz. Use both for defense in depth.
5. It's the highest-value pod-reachable target (cloud credentials); IMDSv2 + hop-limit 1 backs it up at the node level.
6. Allowing DNS egress (kube-dns:53) — a default-deny egress policy without it breaks everything.

Chapter 20 — Runtime security

1. Shell spawned in a container, reads of sensitive files, unexpected outbound connections, container drift (a binary not in the image runs); distroless/read-only removes the attacker's tools and makes any exec anomalous.
2. Falco observes and alerts; Tetragon can additionally ENFORCE (kill the process/block the syscall) in-kernel via eBPF.
3. A webhook injects a projected token (audience sts.amazonaws.com); the SDK calls AssumeRoleWithWebIdentity; the role trust condition must pin the exact namespace:serviceaccount (and audience).
4. Because they'd otherwise borrow the NODE's (usually broader) instance role via IMDS, bypassing their own scoped workload identity entirely.
5. Minimal permissions only (CNI, image pull, logs) — never app-level data permissions, since every pod on the node can potentially reach it.
6. Because a detection with no automated/human-ready response is a slow incident; wiring includes cordon/isolate, snapshot, revoke sessions, and open an incident.

Chapter 21 — Multi-tenancy

1. The control plane, etcd, the kernel, and cluster-scoped resources are shared — a control-plane or kernel bug crosses tenants.
2. Soft (namespaces) is fine for trusted/internal workloads; hard isolation (sandboxed runtime, node isolation, or cluster-per-tenant) is needed for untrusted/arbitrary code.
3. gVisor: a user-space kernel intercepts syscalls (lighter, some compat gaps). Kata: a full lightweight VM per pod (stronger, more overhead).
4. Its own API server/control plane, isolating cluster-scoped resources from the host and other tenants, while still sharing host nodes/kernel.
5. RBAC scoped per tenant namespace, default-deny NetworkPolicy, ResourceQuota /LimitRange, PSA restricted enforced, separate SAs, no shared PVs.
6. Compute isolation alone doesn't stop a service-layer bug from leaking data across tenants — the data layer (RLS, per-tenant keys/indices) is an independent decision.

Chapter 23 — SPIFFE and SPIRE

1. SPIFFE ID is the identifier (a URI, not secret); the SVID is the actual signed credential. The Workload API needs no secret because process/kernel- level attestation IS the authentication.
2. Node attestation (agent proves what node it's on, e.g. via k8s_psat) then workload attestation (agent inspects the calling process, e.g. via k8s namespace/SA selectors) to hand out the right SVID.
3. Selector-set → SPIFFE ID mappings; too-loose selectors (namespace only) mean any SA in that namespace gets the identity.
4. A leaked SVID expires quickly; practical because rotation is automatic via the Workload API, not manual.
5. As the CA for mTLS between sidecars, keying AuthorizationPolicy off the SPIFFE principal.
6. An authorization model/policy engine (Ch 25).

Chapter 24 — Token exchange

1. It's replayable to any service accepting that token; it may carry scopes far beyond what the call needs; it loses per-hop attribution.
2. subject_token: the incoming token to exchange. actor_token: the calling service's own identity. audience: the intended downstream. act: the resulting delegation chain in the new token.
3. The aud check — every service must validate the token's audience equals itself.
4. The gateway holds real tokens (via introspection) and forwards them only internally, so an opaque reference token is all the public client ever sees.
5. mTLS/SPIFFE authenticates the connection/service; the token carries the end-user identity and delegation chain for per-user authz and audit.
6. They only need to survive one hop; shorter life means less replay window if leaked.

Chapter 25 — Distributed authorization

1. Ownership, sharing, hierarchy, groups (RBAC struggles — role explosion). ABAC adds conditional/contextual policy; ReBAC adds relationship graphs that model ownership/sharing/hierarchy natively.
2. A tuple object#relation@subject (a userset can itself be a group); Check answers "is this user related to this object via this relation."
3. PEP enforces in the service; PDP decides; PIP supplies the data; PAP is where policy is authored. Embedded PDP: low latency, distribution burden. Central PDP: one source of truth, adds a network hop.
4. A stale cache after revocation still granting access; solved with consistency tokens (zedtokens/zookies) that bind a check to a fresh-enough revision.
5. It becomes "fetch all, check each" — N+1 and slow; use the engine's native list-objects/reverse-index operation.
6. At the edge/gateway (coarse, fast fail) AND in each service (authoritative) AND at the data layer (RLS/keys) as a backstop.

Chapter 26 — East-west security

1. Assume-breach means the internal network is hostile too; "internal" is a network fact, not an authentication decision.
2. Channel creds authenticate the connection (mTLS); call creds authenticate the request (a token in metadata). Authz logic belongs in interceptors, centrally.
3. Disabling reflection (hides the API surface), message-size limits (memory DoS), and deadline/timeout enforcement (prevents cascading hangs).
4. Per-topic/group/transactional-id read/write/describe permissions; topic- per-tenant is stronger isolation, a shared topic with a tenant_id field is cheaper but relies on consumer-side filtering discipline.
5. When authenticity must survive replication, mirroring, tiered storage, or a potentially-compromised broker — transport auth alone isn't enough.
6. It accumulates PII and error data, is often more widely readable, and retained longer than the main topic.

Chapter 27 — Multi-tenant data isolation

1. Pool: cheapest, one migration, relies on discipline; silo: strongest, costliest; bridge: middle. Pool suits many small tenants.
2. ENABLE turns RLS on; FORCE applies it even to the table owner; USING gates reads, WITH CHECK gates writes. The app role must not be superuser, the table owner (without FORCE), or have BYPASSRLS.
3. Pooled connections carry session state, so a bare SET (not SET LOCAL) leaks tenant context to the next request; fix by using SET LOCAL inside an explicit transaction.
4. It backs up RLS against a full bypass (ciphertext without the tenant's key) and makes offboarding a single key-destruction operation (crypto-shredding).
5. Search index, cache, object storage, event streams, logs/traces, backups.
6. Automated "as tenant B" tests run against every read path in CI.

Chapter 28 — Resilience as security

1. Availability is one leg of the CIA triad; a DoS or denial-of-wallet directly attacks it.
2. Per-IP, per-user, per-tenant, per-endpoint; per-IP alone fails against distributed abuse and shared NATs.
3. A cap on total retries as a fraction of traffic, preventing a downstream blip from becoming a self-inflicted retry storm.
4. Circuit breaker: stops calling a failing dependency. Bulkhead: isolates resource pools so one dependency/tenant can't starve others.
5. ReDoS (linear-time regex/timeouts), decompression bombs (size/ratio limits), deeply nested payloads (depth/size limits), expensive-by-input queries (mandatory bounds/async processing).
6. The service stays up while the cloud bill explodes from abuse; bounded by per-tenant quotas and autoscaling caps with cost alerts.

Chapter 30 — Request smuggling

1. Front-end uses Content-Length, back-end uses Transfer-Encoding (or vice versa); leftover bytes are prepended to the NEXT request on the reused connection.
2. HTTP/2 has an explicit, unambiguous length; a downgrade to HTTP/1.1 at the back-end reintroduces the CL/TE ambiguity (or CRLF-injection variants).
3. The victim's own browser is the smuggling vector via a crafted fetch(); no intermediary proxy is needed.
4. Bypass front-end auth/WAF controls, capture other users' requests (credentials/CSRF tokens), poison the response queue/cache.
5. HTTP/2 end-to-end; reject requests with both CL and TE or malformed TE; don't reuse back-end connections across clients; re-authenticate on the back-end regardless of the front-end's decision.

Chapter 31 — Cache poisoning/deception

1. An input (often a header) that affects the response but isn't part of the cache key — a poisoned response then serves to everyone sharing that key.
2. X-Forwarded-Host, X-Forwarded-Scheme, a "fat GET" body, an obscure query parameter.
3. Poisoning injects malicious content into a shared cache entry; deception tricks the cache into storing someone else's PRIVATE response where the attacker can then read it.
4. A dynamic, personalised path (/account/x.css) can be miscategorised as static and cached, exposing private data.
5. Don't cache on unkeyed input (or key it, or strip it); no-store/private on personalised responses; cache only explicit static assets, ideally on a separate cookieless origin; normalise paths identically at cache and origin.

Chapter 32 — XXE

1. <!DOCTYPE r [<!ENTITY x SYSTEM "file:///etc/passwd">]><r>&x;</r>.
2. Parameter entities load an external DTD you host, which defines an entity that reads a local file and sends it out via an HTTP request to your server — no reflection in the original response needed.
3. SAML, DOCX/XLSX/PPTX, SVG, SOAP/XML-RPC, RSS/Atom.
4. Blind/OOB attacks specifically use parameter entities; disabling only general entities leaves this path open.
5. No outbound network from the parsing process (kills OOB exfil) and least file-system privilege for that process.

Chapter 33 — SSRF mastery

1. IMDSv2 requires a PUT+header the naive <img src> case can't do; but full-request-control SSRF, an HTTP-proxy SSRF, or hop-limit>1 still reach it.
2. Craft raw protocol bytes to Redis (e.g. SET/module load/RDB write) via gopher://, achieving code execution on the Redis host.
3. DNS returns an allowed IP for validation and a private/metadata IP for the actual connection (different lookups, TTL 0); fails because validation and connection resolve separately.
4. Resolve the hostname once, validate every resulting IP against deny ranges, then connect to that pinned IP directly (with Host header set) — prevents rebinding and denylist bypass.
5. Egress default-deny with an FQDN allowlist, blocking the metadata IP at the network layer, and a scoped/no cloud role on the fetcher's identity.
6. A URL saved now and fetched later by a different, often more privileged, backend job/context.

Chapter 34 — Prototype pollution etc.

1. Object.prototype, inherited by every object — code that never touched the attacker's input still reads the polluted property off a fresh {}.
2. Pollute child_process spawn options (e.g. shell) so a later, unrelated spawn({}) call executes via a shell.
3. Using injected HTML with id/name to shadow a global/property; useful when script tags are filtered but HTML attributes survive sanitisation.
4. The browser's parser "fixes up" sanitiser-approved markup on insertion/re-serialisation into something executable the sanitiser never saw; a passing sanitiser check doesn't guarantee safe final DOM.
5. __proto__, constructor, prototype.
6. Because the danger is in the browser re-parsing the sanitised output a second time (an innerHTML round-trip), not in the sanitiser's first pass.

Chapter 35 — Web race conditions

1. Read-check (is this unused?) then write-mark (mark used) as two separate steps; firing many parallel requests lets all of them pass the check before any commits (e.g. redeeming one gift card 20 times).
2. It packs the final frames of many requests into a single TCP packet, eliminating network jitter that made HTTP/1.1 timing unreliable.
3. Limit overrun, multi-endpoint, single-endpoint, partial construction/ hidden state (also time-sensitive token reuse).
4. A conditional UPDATE checked by rows-affected, a UNIQUE constraint on the redemption row, or SELECT ... FOR UPDATE row locking.
5. It reduces attempt volume but the single-packet attack often fits within the limit; it doesn't fix the underlying non-atomic operation.
6. Represent the pre-verification state as a distinct token/session that grants access to nothing except the verification step itself.

Chapter 36 — SSTI/EL injection

1. XSS injects into rendered OUTPUT; SSTI injects into the template SOURCE itself, which the engine then evaluates as code.
2. Try engine-specific math syntax ({{7*7}}, ${7*7}, <%= 7*7 %>) and see which evaluates; different engines respond to different syntax.
3. {{ cycler.__init__.__globals__.os.popen('id').read() }} (or the config/self equivalents).
4. Evaluating user input as an expression language (SpEL, OGNL); Struts2 (OGNL) and Spring (SpEL) both have real RCE CVE history from this.
5. A strict sandboxed environment, process isolation (no network/secrets, resource limits), and an explicit allowlist of exposed variables/filters.
6. Sandboxes (Jinja2, Twig) have had documented escapes; isolation and allowlisting are needed as additional, independent layers.

Chapter 37 — Deserialization

1. The serializer constructs real objects and invokes their lifecycle methods (readObject, reduce, __wakeup) — attacker-controlled object graphs chain those methods into command execution.
2. A sequence of classes already on the classpath/dependency tree whose normal methods, wired together by the crafted input, reach exec; the gadgets come from your own dependencies.
3. Java: AC ED 00 05 / base64 rO0. Python: class X: def __reduce__(self): return (os.system, ('id',)).
4. The phar:// stream wrapper triggers deserialization of a crafted phar's metadata on ordinary filesystem calls (file_exists, etc.), no explicit unserialize() needed.
5. A JEP 290 ObjectInputFilter — an allowlist of expected classes plus depth/ref limits, rejecting everything else before it's instantiated.
6. It defeats gadget chains that trigger remote class loading (JNDI/LDAP) even without a local exec gadget present.

Chapter 38 — File upload

1. Execution (the file itself runs), parser exploitation (a library processing it is vulnerable), and path/filename traversal.
2. Decoding and re-encoding destroys embedded polyglot payloads and most metadata-based exploit payloads, producing a clean, canonical file.
3. ImageTragick (ImageMagick delegates → RCE/SSRF), the GitLab ExifTool CVE-2021-22204 (DjVu → Perl injection → RCE), ffmpeg HLS playlist tricks (arbitrary file read).
4. Archive entry names containing ../ writing outside the extraction directory; prevent by canonicalising and containing every entry path.
5. So even an uploaded HTML/SVG/script file can't execute in the app's trusted origin or read its cookies.
6. A CSV cell starting with =/+/-/@ is interpreted as a formula by the victim's spreadsheet application when they open the export — code runs on the downloader's machine.

Chapter 39 — Federated identity attacks

1. Signature VALIDATION checks one XML element while business logic CONSUMES a different, injected, unsigned element.
2. Stealing the IdP's token-signing private key; then arbitrary valid assertions can be forged offline, for any user/SP, indefinitely — no further IdP interaction or logging occurs.
3. Audience, Recipient, Destination, timestamps (NotBefore/NotOnOrAfter), InResponseTo, and one-time Assertion ID enforcement.
4. A malicious/compromised IdP tricks a multi-IdP client into sending a code/ token to the wrong IdP; mitigated by the iss response parameter (RFC 9207).
5. Linking a federated identity to a local account by email without verifying control, letting an attacker pre-register the victim's email; fix with verified-email + re-auth before linking.
6. Because the mismatch between "what was verified" and "what was consumed" is the root cause — consuming only the exact verified subtree eliminates it structurally.

Chapter 40A — API payload security

1. Positive validation defines exactly what's allowed and rejects everything else (finite, fails closed); negative validation tries to enumerate what's bad (infinite, always incomplete) — positive is preferred at the boundary.
2. It rejects any field not explicitly declared in the schema, directly closing the mass-assignment/overposting class demonstrated in the 2012 GitHub Rails incident.
3. Different parsers can pick different values for duplicate keys — the same "two components disagree about what a message means" root cause as HTTP request smuggling (Ch 30).
4. Max body size, max array length, max string length, max nesting depth (also: max distinct key count).
5. Rendering or trusting a field from a third-party API response without the same output encoding as user input — e.g. displaying an unescaped city name from a geolocation API leads to stored XSS.

Chapter 40B — API rate limiting

1. Token bucket allows a controlled burst up to its capacity while capping the sustained rate; leaky bucket smooths bursts into a steady, fixed-rate outflow instead of allowing them.
2. It gives equivalent behaviour to token bucket while storing only a single value per key, making it cheap to keep consistent across a distributed cache at scale.
3. Per API key/client, per user/account, per endpoint+method, per plan tier — per-IP alone is trivially defeated by rotation, proxies, and shared NATs for any authenticated API.
4. Firing many parallel requests so they all read the counter before any of them commits its increment, letting more through than the limit allows; fix with an atomic check-and-increment (a single Lua script or a conditional UPDATE with a rows-affected check).
5. The limiter resets on a fake IP the attacker supplies itself; fix by only trusting the forwarded-IP header value your own edge appended, never a client-supplied one.
6. Total daily/session lookup volume and the enumeration pattern itself (a systematic sequence of targets from one caller) — a per-minute or per-IP limit alone doesn't catch a slow, distributed, or patient harvest.

Chapter 40C — WAF

1. A rule written to block exploitation of a specific, disclosed vulnerability while the real fix is developed; it should always be tied to a vulnerability-management SLA (Ch 59) as a stopgap, not a permanent fix.
2. Negative (signature/blocklist) has broad out-of-the-box coverage but perpetually chases novel bypasses; positive (allowlist/schema) is far more effective but requires defining exactly what's valid per endpoint.
3. The WAF only ever inspects the outer, visible request; the smuggled second request reaches the backend without ever being seen or filtered by the WAF at all.
4. The WAF itself had an SSRF vulnerability, and it ran with an over-permissive IAM role granting broad S3 access; the over-permissioned identity was arguably the more consequential failure, since it's what turned an SSRF bug into a 100-million-record breach.
5. Encoding/parser-confusion (payload doesn't match the signature but the backend still executes it), HTTP parameter pollution (WAF and backend pick different duplicate values), and content-type mismatch (WAF doesn't parse the format the payload was actually sent in).

Chapter 40D — WAAP

1. Credential stuffing (valid-looking requests with stolen credentials, no bad pattern to match), scraping (individually legitimate-rate requests, no malformed syntax), and shadow/zombie API abuse (the WAF has no rules for an endpoint it doesn't know exists).
2. It fingerprints the underlying TLS/client stack making the connection, independent of the User-Agent header, which is trivial for a script to fake.
3. It passively observes real traffic and catalogues every endpoint/method actually being called, including undocumented ones — directly addressing OWASP API9:2023, Improper Inventory Management.
4. L7 DDoS is a flood of individually valid-looking application requests overwhelming capacity; L3/L4 is raw packet/connection volume. L7 needs behavioural/bot-management signals to distinguish from a real traffic spike; L3/L4 is handled by network-layer scrubbing.
5. A mandatory policy that every endpoint discovered receiving live traffic must be reviewed, classified, and either brought into the security baseline or decommissioned — with an owner and a deadline, not left as a documentation backlog item.

Chapter 40E — OWASP API Security Top 10

1. API1 BOLA (ownership checks, Part 5 Ch 25/27), API2 Broken Authentication (G1 Ch 46), API3 Broken Object Property Authorization (Ch 40A's schema + response DTOs), API4 Unrestricted Resource Consumption (Ch 40B, Part 5 Ch 28), API5 BFLA (G1 Ch 45, Part 5 Ch 25), API6 Unrestricted Business Flows (Ch 40B's business-flow limits + Ch 40D's bot management), API7 SSRF (Part 6 Ch 33), API8 Security Misconfiguration (Part 3's gates, Ch 58), API9 Improper Inventory Management (Ch 40D, Part 7 Ch 41), API10 Unsafe Consumption of APIs (output-encode and schema-validate third-party responses, verify webhook signatures).
2. API1 checks whether the caller owns/may access THIS SPECIFIC OBJECT; API5 checks whether the caller's ROLE permits the action AT ALL, independent of any particular object.
3. It's a business/fraud problem as much as a technical one (bot-driven ticket scalping, sneaker-bot purchasing) — often needs product-level decisions (queues, purchase limits) as much as a technical control, and frequently falls between security and fraud teams.
4. Rendering an unescaped field from a third-party API response (e.g. a city name from a geolocation service) directly in a page without output encoding.
5. SSRF (API7, from fetching a user-supplied URL) and business-flow abuse (API6, from potential bot-driven mass submission) were the standouts; API10 (trusting the third-party price API's response) is the one a typical review skips, because it inverts the usual "validate what comes IN" framing to "validate what you receive FROM other systems too."

Chapter 41 — Data classification

1. Purpose, data-subject categories, data categories, recipients, transfers, retention period, security measures.
2. IP addresses, device IDs, cookie IDs, precise location — all personal data under GDPR even though they don't feel sensitive.
3. New features constantly add new flows; a one-time inventory rots within a quarter without continuous scanning.
4. Encryption policy, the erasure orchestrator, and access-review tooling.
5. A quarterly scan-vs-map reconciliation (Macie/DLP) caught an unmapped export flow before it became an incident.

Chapter 42 — Encryption at rest

1. Stolen disks, snapshots, and improperly-shared backups; it does not protect against a compromised app, a malicious DBA, or SQL injection, since the engine decrypts transparently for any authenticated query.
2. When the threat model includes the database/DBA/analyst itself — field encryption keeps data as ciphertext even from broad DB-level access.
3. An HMAC of the normalised plaintext stored alongside non-deterministic ciphertext, enabling equality lookup while leaking less than deterministic encryption (though still leaking equality).
4. In the service that legitimately needs the plaintext, or a dedicated crypto service other services call; never transparently at a shared DB proxy for everyone.
5. Storage encryption stopped an accidentally-shared snapshot; it did nothing against a phished account with legitimate broad SELECT access, which only field encryption stopped.

Chapter 43 — Tokenization

1. Encryption is reversible with the key; a vault-based token has no mathematical relationship to the original at all, so systems handling only tokens can be removed from compliance scope entirely.
2. Vault-based: provably non-reversible outside the vault, but the vault is a single high-value point of failure. FPE: no vault dependency and fits legacy schemas, but is deterministic encryption reversible by anyone holding the key.
3. Risk concentrates into the vault/gateway; that's the goal — one small, heavily-hardened system instead of many loosely-protected ones.
4. Client-side tokenization where the card number never touches your servers at all — stronger than server-side tokenization because your infrastructure never handles cardholder data even transiently.
5. Because unrestricted detokenization recreates the original exposure with extra steps — it needs the same authorization rigor as the sensitive data itself.

Chapter 44 — Key management lifecycle

1. Backing-key rotation creates a new key VERSION (cheap, usually automatic, old ciphertext still decryptable); data re-encryption actually rewrites ciphertext under the new key (expensive, needed if old key material itself is compromised).
2. Rotating the top layer is cheap (re-wrap DEKs) without touching bulk data; the root changes rarely under heavy control.
3. A formal, witnessed procedure to generate/recover a root key with no single person able to reconstruct it alone; M-of-N split knowledge requires a quorum of custodians.
4. So one compromised admin account can't both access the data and grant itself the key to decrypt it.
5. Meaningful encryption context on every Decrypt call let the response scope exactly which tenant/records were actually accessed.
6. BYOK: you generate the key, the provider holds/operates it. HYOK: the key never enters the provider at all, via an external key store — maximum control but a hard dependency (your outage blocks the provider's own support access too).

Chapter 45 — De-identification

1. Pseudonymized data is still personal data (re-identifiable with separately-held info); only true anonymization is outside GDPR's scope entirely.
2. Sweeney's 1997 case (ZIP+DOB+sex re-identified a governor's records), the 2006 AOL log release (content alone identified a user), the 2008 Netflix Prize (cross-referencing public IMDb data re-identified subscribers).
3. L-diversity fixes the homogeneity attack (all K records sharing one sensitive value); t-closeness fixes skewness/similarity attacks from an unrepresentative sensitive-value distribution.
4. Epsilon is the privacy budget/loss — smaller means more noise, more privacy; it's consumed across queries, so cumulative spend must be tracked or repeated "safe" queries add up to an unsafe total.
5. Global DP: a trusted curator adds noise to query results (higher accuracy, e.g. US Census). Local DP: each device adds noise before sending anything (stronger trust model, e.g. Google RAPPOR/Apple telemetry).
6. K-anonymity/l-diversity for a one-off, static dataset release; differential privacy for an ongoing, repeatedly-queried live system.

Chapter 46 — Right to erasure

1. Becoming aware of the request; roughly one month, extendable for complex cases with notice.
2. Legal-obligation retention (e.g. tax records) and legal-claim defence — document the specific ground per record class retained.
3. Backups are often immutable by design; crypto-shredding a per-subject key (if designed in) or a short, disclosed retention-bound exception both work.
4. Destroying the wrapping key renders every copy — including immutable backups — unrecoverable without touching the backup files themselves.
5. Intake → verify identity → discover scope (from the data-flow map) → check exemptions → execute per system → verify → respond → audit trail.
6. A delete call can silently fail (timeout, permission error); re-querying confirms the data is actually gone rather than trusting a 200 response.

Chapter 47 — Data residency

1. Adequacy decisions, Standard Contractual Clauses, and the EU-US Data Privacy Framework; its predecessors (Safe Harbor, Privacy Shield) were both invalidated by the CJEU (Schrems I and II).
2. A Transfer Impact Assessment of the destination country's surveillance laws, plus supplementary measures (e.g. encryption the importer can't decrypt) where risk is found.
3. China's PIPL/Cybersecurity Law and Russia's data-localization law both require certain data to physically stay within the country, independent of any transfer-out restriction.
4. It gives operational/legal guarantees that even support/operational access stays within the jurisdiction, addressing the surveillance-law concern Schrems II raised more directly than region selection alone.
5. A quarterly data-flow reconciliation found a SaaS tool's US-region default ingesting PII; redacting the data before it ever reaches the tool would have prevented the transfer regardless of region configuration.
6. Each sub-processor's identity, its transfer mechanism, and its data region — most privacy laws require disclosing this to your own customers.

Chapter 48 — Database security

1. Masking hides values at query time via engine-enforced role rules with no underlying data change; it doesn't stop an account with masking-bypass privilege, which field encryption still would.
2. A legitimately-authorized account behaving anomalously at volume (a bulk export pattern) — every individual query was "authorized."
3. It replaces static, leakable passwords with short-lived, IAM-derived tokens; revoking the underlying IAM identity immediately breaks DB access.
4. One account per service, no superuser/BYPASSRLS app roles, parameterised stored procedures, and an audited list of installed extensions.
5. Pre-2.6 MongoDB shipping with no authentication by default; the fix is authentication always on, regardless of network placement.
6. Neither caught the volume/pattern anomaly of non-field-encrypted metadata being exfiltrated slowly; Database Activity Monitoring's baseline comparison caught it.

Chapter 49 — Access governance

1. Into "who DID access, when, and why" — a small, self-documenting log instead of a large, rarely-reviewed standing-permission list.
2. It's heavily logged, immediately alerts a separate party, and requires post-hoc justification within a defined window.
3. It catches carelessness and opportunism via pattern matching, not determined exfiltration (encoding, screenshots) — it's one layer, not a guarantee.
4. Stale-but-valid access that no behaviour would ever flag as anomalous (rarely used, but still technically valid); recertification re-asks the authorization question on a schedule regardless of activity.
5. Masked/read-replica query tools as the default; JIT access with session recording for genuine exceptions; mandatory query auditing tied to a ticket reference.
6. Contractor/service-account offboarding often lacks the same trigger as employee offboarding (no HR termination event fires it), so access silently outlives the engagement.

Chapter 51 — Detection lifecycle

1. A model ranking indicators by how expensive they are for an attacker to change; TTPs (top) survive tool/infra changes, hashes (bottom) don't survive a recompile — spend effort near the top.
2. Identify → design hypothesis → develop → test → deploy → tune → measure → maintain.
3. Unit tests (fixtures, catch regressions) and live validation (actual technique execution against real telemetry, proves it works in practice).
4. It compiles to many SIEM backends, survives a tool migration, and is reviewable/shareable as code.
5. Detections built for YOUR specific attack-path chokepoints, not just consuming published community content.
6. A schema change, refactor, or new service can make it stop matching silently; only periodic re-emulation reveals this, since "hasn't fired" looks identical to "broken."

Chapter 52 — Telemetry architecture

1. Endpoint, container/k8s, network, cloud control plane, application, identity, DNS, email, SaaS — identity and SaaS logs are most commonly missing.
2. Detection rules and hunting queries work identically across sources and survive a tool swap.
3. Avoids being cost-locked into one vendor's per-GB pricing and lets multiple tools query the same authoritative data.
4. A year with 3 months immediately available (PCI-DSS); real dwell time regularly exceeds 90 days, so hot storage alone often misses the investigation window.
5. High-value/lower-volume sources (identity, control plane) get hot, real-time indexing; high-volume/lower-value sources route to cheap object-storage tiers queried on demand.
6. A 30-day hot-only retention aged out the primary evidence for a 65-day-old intrusion; routing high-volume sources to cold storage funded a longer retention on high-value sources at the same total cost.

Chapter 53 — Threat hunting

1. A hunt starts from a hypothesis with no triggering alert; investigating an alert is incident response, not hunting.
2. Strategic (leadership/trends), operational (hunters/campaign TTPs), tactical (IOCs for automated matching).
3. Direction → collection → processing → analysis → dissemination → feedback.
4. A thorough negative result increases confidence a specific gap is currently unexploited — a documented, real outcome, not wasted effort.
5. A repeatable pattern found manually should become an automated, scheduled detection so future occurrences don't need the same manual effort again.
6. Peer organisations' real, current, sector-specific incident data — often the highest-signal source available, since you're likely a similar target.

Chapter 54 — Detecting attack paths

1. For every edge on a critical attack path, ask what it would look like in your telemetry and whether a detection exists — building the backlog from demonstrated risk, not a generic checklist.
2. Session credentials used from outside known VPC/NAT ranges; and CreatePolicyVersion+SetDefaultPolicyVersion in a short window by a non-admin.
3. The audit log records the API-level RBAC decision itself (who created what with what SA); Falco's runtime telemetry is a separate signal for what actually ran inside the resulting pod.
4. By the same path-risk formula (reachability × feasibility × value ÷ detection), now weighted by the inverse of current coverage.
5. It records what's already adequately handled, preventing the same "gap" from being re-litigated repeatedly and focusing effort on real shortfalls.

Chapter 55 — Cloud/container IR

1. Termination destroys evidence and doesn't stop the credential's blast radius; isolation for a pod means cordon+quarantine NetworkPolicy without deleting it, for an instance means detach+snapshot without stopping it.
2. There's no direct "kill this session" API for an active cloud session; attach an explicit Deny policy immediately, which wins over all Allows for every subsequent call regardless of session TTL.
3. Exactly which records/tenants were actually decrypted during the compromise window, enabling precise breach scoping instead of worst-case notification.
4. Only for high-confidence detections where a false positive's disruption cost is acceptable; ambiguous findings should automate investigation but keep a human in the containment decision.
5. You cannot be confident every persistence mechanism was found by inspection; rebuilding from known-good IaC/images removes that doubt.
6. Cross-account/cross-cluster investigations and centralised, tamper- resistant logs live in the dedicated security account.

Chapter 56 — Ransomware

1. Initial access → execution/discovery/lateral movement → privilege escalation → disable defenses/backups → stage and exfiltrate → encrypt at scale.
2. It's distinctively abnormal (shadow-copy deletion, backup-service stops) with near-zero legitimate frequency, giving a high-confidence signal BEFORE mass encryption completes.
3. An immutable or offline/air-gapped copy the attacker's network-based reach or delete permissions cannot touch — Object Lock/WORM storage, or a genuinely offline copy.
4. Backups that are never actually restored are a hope, not a proven recovery path; only a real, scheduled test proves they work.
5. Legality/sanctions (OFAC advisories), no guarantee of a working decryptor or that exfiltrated data won't leak anyway, and law-enforcement engagement; legal, insurance, and executives must be involved, not engineering alone.
6. Attackers often retain a second foothold and re-encrypt an organisation that restores without confirming the initial-access vector is actually closed.

Chapter 58 — SSDLC program

1. Pre-commit: secret scanning. PR: SAST, SCA, IaC policy. Pre-deploy: DAST, container/signature verification. Post-deploy: runtime detection.
2. It scales scarce central-security expertise across every team via an engineer who already has the team's context and trust — losing that context is what a fully separate role would sacrifice.
3. A concrete, level-based checklist (baseline/sensitive/critical) to verify against, replacing a vague, unanswerable "is this secure enough."
4. Shift left catches issues early and cheaply; shift right (production detection) catches what every static/dynamic tool inevitably misses — they're complementary, not alternatives.
5. It trains engineers to suppress rather than fix findings; roll out in audit-only mode first, tune to a small high-confidence rule set, then enable blocking team by team.
6. So they're triaged, prioritised, and tracked to closure with the same visibility and discipline as any other defect, rather than being silently deprioritised in a separate system.

Chapter 59 — Vulnerability management

1. CVSS measures severity IF exploited; EPSS adds the probability it WILL be exploited in the wild in the next 30 days.
2. It represents CONFIRMED, observed exploitation rather than a prediction — the strongest available signal, overriding the rest of the formula.
3. Determining whether the vulnerable code path is actually called by your application; it eliminates unreachable findings that carry no real operational risk.
4. KEV or (internet-facing+reachable+high EPSS) → 24-48h; high CVSS+ reachable+internet-facing → 7 days; high CVSS but unreachable/internal → next patch cycle; low everything → track, batch-review.
5. An owner, a documented reason, and an expiry/review date, visible to someone accountable.
6. It rises simply as scanning coverage improves and says nothing about actual risk trend; track SLA-compliance percentage and KEV/high-EPSS item age instead.

Chapter 60 — Offensive program

1. A published policy with a safe-harbor clause protecting good-faith researchers from legal action; every organisation should have one because it's nearly free and provides a real reporting channel.
2. Private/invite-only first to prove triage capacity at smaller volume, then public once response times and quality are demonstrated.
3. A pentest finds as many vulnerabilities as possible in a scope/timebox; a red team tests whether a specific objective can be reached WITHOUT being detected, testing response as much as prevention.
4. Running it against near-zero detection capability mostly just re-confirms "no visibility" at high cost, which a cheaper conversation would establish just as well.
5. It must enter the same vulnerability-management pipeline as every other finding, with the same prioritisation and tracked SLA — never live only in a report.
6. Scope, timing/blackout windows and an emergency stop-work contact, and explicit legal authorisation.

Chapter 61 — Compliance

1. Type I assesses control DESIGN at a point in time; Type II assesses OPERATING EFFECTIVENESS over a period (6-12 months) — customers prefer Type II because it shows sustained practice.
2. An entire management SYSTEM (an ISMS with risk assessment, management review, continuous improvement) around the controls, not just the control list itself.
3. Doing the minimum documented activity to satisfy a control's wording without addressing the underlying risk; the tell is evidence generated only because an audit is approaching, rather than as a byproduct of a continuously-operating control.
4. Map already-operating artifacts (access reviews, detection coverage, vulnerability backlogs) onto the framework's language, so genuine practice generates evidence continuously instead of building parallel processes per framework.
5. They automate evidence COLLECTION from connected systems; they don't replace the requirement that the underlying control genuinely exists and operates.
6. A quarterly access review satisfies SOC 2, ISO 27001, and PCI-DSS language simultaneously; the CSA Cloud Controls Matrix and Secure Controls Framework publish cross-framework mappings.

Chapter 62 — Risk and metrics

1. FAIR expresses risk as a probabilistic dollar range (comparable to every other business risk a board weighs); the cost is that it's harder to do well and unskilled use produces false precision.
2. Description, likelihood, impact, owner, treatment (mitigate/accept/ transfer/avoid), residual risk, review date.
3. Matters: MTTD/MTTR, % KEV/high-EPSS remediated within SLA, ATT&CK coverage %. Vanity: raw finding count (rises with scanning coverage, not risk), tool count, training completion % alone (doesn't prove behaviour change).
4. A small number of trended KPIs, peer/industry benchmarking, explicit ties to business objectives, and asks framed as resource-allocation decisions.
5. It's demonstrated rather than hypothetical — a concrete, walked path with real evidence is far more persuasive than an abstract risk claim.
6. Each audience needs different detail and framing for its actual decision: tactical/technical now, strategic/business-trend for the board, transparent/measured for customers.

Chapter 63 — Enterprise identity

1. Every federated application inherits the IdP's compromise; phishing- resistant MFA on admin accounts and a tested offline break-glass path both follow directly.
2. Tier 0 (identity infra/DCs), Tier 1 (servers), Tier 2 (workstations); a lower-tier credential must never be usable to escalate to a higher tier.
3. Kerberoasting: request a service ticket and crack its offline hash — mitigated by long/random or managed (gMSA) service-account passwords. Golden Ticket: forge unrestricted tickets with a stolen krbtgt hash — mitigated by protecting and rotating krbtgt plus the tiered model.
4. Internal role/team changes have no natural offboarding trigger, so old access silently persists; automating provisioning/deprovisioning from HR via SCIM, including an explicit "mover" event, fixes it structurally.
5. The same underlying principle (least standing privilege, time-boxed access, session accountability) applied to a different layer — infrastructure/directory access here versus data access in Part 7.
6. Conditional access is preventive (tries to stop the anomalous sign-in before it succeeds); UEBA is detective (catches the pattern if it gets through anyway) — you need both.

End of guide. You started able to secure one system and finished able to model attack paths across an entire estate, build distributed authorization that provably isolates tenants, exploit and remediate the web's hardest classes, protect data through its full lifecycle including deletion on request, run a detection program from first principles, and operate the organisational machinery that makes all of it durable. Keep the lab running. Keep the artifacts current. Teach what you learn.