« All Roles

Security Engineer - 24-Month Engineering and Research Curriculum

Target roles:

• Senior Security Engineer / Security Consultant
• Product and Application Security Engineer
• Cloud and Kubernetes Security Engineer
• Android Platform or Mobile Application Security Engineer
• Vulnerability Researcher / Security Research Engineer
• Detection Engineer / Incident Responder
• AI and Agent Security Engineer

Reference role: the senior, client-facing security profile in jd.md
Duration: 104 weeks (24 months), 15-20 focused hours per week
Starting point: a strong software engineer who can already build and debug production software
Operating boundary: owned systems, purpose-built labs, CTFs, explicitly authorized programs, and coordinated open-source disclosure only

1. Executive Summary

This is not a collection of hacking tutorials. It is a two-year engineering apprenticeship built around four abilities that elite security teams repeatedly hire for:

1. Understand the system deeply enough to identify where trust is misplaced.
2. Prove the risk safely with reproducible evidence inside an authorized environment.
3. Engineer the control and verify that the fix survives regression, scale, and operational use.
4. Communicate the decision to developers, responders, executives, auditors, and customers.

The curriculum moves from systems and protocol foundations through product security, mobile, cross-platform internals, isolation, cloud, vulnerability research, incident response, OT, and AI security. Every phase produces code, tests, diagrams, evidence, and two reports: one technical and one executive-facing.

The breadth is deliberate, but "broad" does not mean shallow. Four specialization lanes run through the second year: cloud provider security, Android vulnerability research, sandboxing and isolation, and AI/agent security. ICS/OT is offered as a fifth lane for infrastructure roles. Choose one primary lane and one secondary lane by Month 12.

The proof-of-work rule

Reading does not complete a phase. A phase is complete only when:

• its flagship build runs from a clean checkout;
• security properties have automated tests or repeatable verification steps;
• failures and limitations are documented;
• a peer can reproduce the result from the README;
• findings distinguish observation, inference, exploitability, impact, and remediation;
• the portfolio artifact contains no secrets, personal data, proprietary material, or unsafe weaponization.

2. Target Role Mapping

Reference JD alignment

Certifications are checkpoints, not substitutes for evidence. For this JD, prioritize one foundational credential only if needed, then a role-aligned advanced credential after the matching labs. Never postpone practical work to collect badges.

3. Skill Matrix

Score each capability quarterly: 0 unfamiliar, 1 explain, 2 perform with guidance, 3 perform independently, 4 design/review/teach.

* depends on the chosen specialization.

4. The 24-Month Roadmap

Quarterly gates

5. Curriculum Structure

Every phase guide contains objectives, theory, programming work, exact labs, capstone, tools, readings, evaluation, mistakes, interview questions, portfolio artifacts, and stretch goals. Runnable labs follow LAB-STANDARD.md: learner TODOs, complete references, adversarial tests, attack evidence, mitigation, regression, teardown, and communication outputs. See LAB-CATALOG.md for requirements traceability and platform extension work.

6. Weekly Study Structure

Use a repeatable 15-20 hour week:

The four-week phase rhythm

1. Model: learn the system and draw trust boundaries.
2. Break safely: reproduce a known weakness in an owned lab.
3. Fix and detect: implement controls and negative tests.
4. Operate and explain: inject failure, collect evidence, write reports, present decisions.

Longer phases repeat this rhythm with increasingly realistic systems.

7. Lab Environment

Reference architecture

                         Management network
                   Git, artifact store, documentation
                                |
                    [router/firewall + deny-by-default]
                      /          |             \
             attack range    victim range     telemetry range
             Kali/Ubuntu     Win/Linux/macOS   Wazuh/OpenSearch
             test tools      Android emulator  Zeek/Suricata
                    \             |             /
                     \------ isolated switch --/
                                |
                       optional OT simulation

            Separate accounts/projects: AWS | Azure | Google Cloud
            Separate local cluster: kind/k3d + private container registry

Hard rules

• No bridging a malware-analysis or vulnerable-target network to home, corporate, or public networks.
• No real credentials or personal data in fixtures, screenshots, packets, commits, or reports.
• Default cloud budgets, quotas, alerts, and teardown automation before the first deployment.
• Snapshot before risky work; destroy and rebuild after it.
• Hash evidence at collection; record source, time, collector, timezone, and transformation.
• Treat model weights, containers, APKs, binaries, and packet captures as untrusted inputs.
• Never test a target because it is internet-accessible. Test only when ownership and authorization are documented.

Baseline equipment

• Host with 32 GB RAM preferred, 16 GB workable; 200+ GB free SSD
• Virtualization: UTM/VMware/VirtualBox/Hyper-V as appropriate
• Ubuntu engineering VM, isolated security-testing VM, Windows evaluation VM
• Android Studio emulator; physical test device only if dedicated and resettable
• macOS host or authorized macOS VM for Apple labs; iOS simulator for non-jailbreak fundamentals
• Docker/Podman, kind or k3d, Terraform/OpenTofu, Git, task runner
• Wazuh or OpenSearch stack, Zeek, Suricata, osquery, Sysmon, auditd

See templates/lab-acceptance-checklist.md before running any offensive or malware-adjacent exercise.

8. Programming Languages and Why

Quality bar: typed interfaces where supported, linting, tests, dependency locking, threat model, structured logs, no embedded secrets, and a documented least-privilege execution model.

9. Core Books, Papers, and Primary Sources

Read current vendor documentation alongside these durable foundations. Prefer original standards, project documentation, and peer-reviewed or conference work over tool-list blogs.

Systems and vulnerability research

• Computer Systems: A Programmer's Perspective - Bryant and O'Hallaron
• Operating Systems: Three Easy Pieces - Arpaci-Dusseau and Arpaci-Dusseau
• The Art of Software Security Assessment - Dowd, McDonald, and Schuh
• Practical Binary Analysis - Andriesse
• The Fuzzing Book - Zeller et al.
• ELF, PE/COFF, Mach-O, DWARF, x86-64, and Arm architecture specifications

Application, identity, and crypto

• Security Engineering - Ross Anderson
• Real-World Cryptography - David Wong
• OWASP ASVS, MASVS, MSTG, API Security Top 10, SAMM, and threat-modeling resources
• RFCs for HTTP, TLS 1.3, OAuth 2.0, PKCE, OIDC, JWT/JWS/JWE, SCIM, DNS, and WebAuthn
• NIST SSDF and Secure Software Development Framework materials

Platform, cloud, and response

• Android Security documentation and Android Open Source Project source/docs
• Apple Platform Security; Microsoft Windows security and Sysinternals documentation
• Linux kernel, seccomp, namespaces, cgroups, LSM, eBPF, OCI, runc, gVisor, and Firecracker docs
• Kubernetes security documentation and NSA/CISA Kubernetes hardening guidance
• Cloud-provider architecture, IAM, KMS, logging, and incident-response documentation
• NIST SP 800-61, 800-86, 800-207; MITRE ATT&CK; Sigma specification

OT and AI security

• NIST SP 800-82 and CISA ICS guidance
• ISA/IEC 62443 concepts and vendor protocol documentation
• OWASP Top 10 for LLM Applications and Agentic Application Security materials
• MITRE ATLAS, NIST AI RMF, Google SAIF, and model/provider system cards
• Foundational papers on indirect prompt injection, tool-use risks, RAG poisoning, and agent evals

Each phase guide narrows this list to the exact chapters and documentation needed.

10. Tooling Map

Tools never define the method. Every assessment must still state scope, assumptions, evidence, false-positive handling, impact, remediation, and retest result.

11. Capstone Portfolio

The 13 phase capstones form one coherent fictional company, Aegis Transit Cloud: a multi-tenant SaaS and mobile operations platform with cloud services, Android field clients, isolated job execution, OT telemetry, and an AI operations assistant. Reusing one system forces you to manage changing assumptions and cross-domain risk.

Runnable lab portfolio

Every phase includes three learner implementations, reference solutions, adversarial pytest suites, and detailed lab READMEs: 47 runnable labs across the track, including compiled C/C++, Rust, Go, Java/JVM, Kotlin/JNI, and provider-specific AWS, Google Cloud, and Azure work.

1. Engagement scope/evidence guard
2. Bounded binary parser and fuzz smoke target
3. Tenant-aware authorization engine
4. Security release gate
5. Android manifest exposure analyzer
6. Cross-platform service hardening evaluator
7. Sandbox policy compiler for container/gVisor/Firecracker modes
8. Cloud IAM attack-path analyzer
9. Crash triage, minimization, and parser patch
10. Cross-source detection correlation engine
11. Passive OT asset inventory
12. Least-privilege AI agent tool gateway
13. Security portfolio evidence linter

Each numbered item above is the first lab in its phase. Labs 02 and 03 add the adjacent attack, hardening, operations, or evidence layer so no phase is represented by a single exercise.

12. Portfolio Plan

Use this structure:

security-portfolio/
├── README.md
├── 00-operating-rules/
├── 01-tools/
├── 02-threat-models/
├── 03-design-reviews/
├── 04-mobile/
├── 05-cloud-and-isolation/
├── 06-vulnerability-research/
├── 07-detection-and-response/
├── 08-ot/
├── 09-ai-security/
├── 10-talks-and-writing/
└── evidence-private/          # never publish raw sensitive evidence

Every public project needs:

• one-sentence problem and explicit authorization boundary;
• architecture and threat model;
• reproducible setup and teardown;
• tests and expected output;
• known limitations and non-goals;
• secure implementation or remediation;
• sanitized evidence;
• 3-minute demo script;
• one truthful resume bullet with numbers you can defend.

Publish fewer, stronger artifacts. The final portfolio should contain 6-8 flagship projects, not 100 unfinished tool screenshots.

13. Interview Preparation

Interview work starts in Month 2, not Month 24:

• weekly: explain one concept without notes in five minutes;
• biweekly: code or debug a security-relevant component;
• monthly: threat-model a new architecture in 45 minutes;
• quarterly: run a mock incident or design review with an executive summary;
• final quarter: two full loops per specialization.

Use interview-prep/README.md for question banks, system-design prompts, incident scenarios, and behavioral evidence.

The answer standard is: define assets and trust boundaries, state assumptions, prioritize abuse cases, choose controls with tradeoffs, describe validation and telemetry, and communicate residual risk. Tool names alone are not an answer.

14. VRP and Responsible Disclosure

VRP work is optional and begins only after Phase 08 readiness.

1. Select programs with clear scope, safe-harbor language, testing rules, and reporting channels.
2. Build a target matrix from the written policy; ambiguous assets are out of scope.
3. Set request-rate, data-access, account, and cost limits below program maxima.
4. Stop at minimum proof. Do not access unrelated data, establish persistence, evade controls, pivot, degrade service, or test other users.
5. Encrypt notes, redact personal data, preserve timestamps, and report promptly.
6. Follow disclosure timelines and do not publish without authorization.
7. Track duplicates and invalid findings as methodology feedback, not as permission to test harder.

Use templates/rules-of-engagement.md and templates/responsible-disclosure-report.md.

15. AI/LLM Security Specialization

Choose this lane if targeting AI platform, product security, or agent-infrastructure teams.

• Deepen Phases 02, 03, 06, 07, 09, and 11.
• Build a typed tool gateway that separates model intent from authorization.
• Maintain injection, exfiltration, confused-deputy, excessive-agency, and RAG-poisoning eval sets.
• Evaluate capability and safety separately; a refusal rate is not a security metric by itself.
• Treat prompts and filters as defense in depth, never as the authorization boundary.
• Final research question: how does the system contain a compromised model or retrieved document?

Flagship proof: an agent platform where untrusted content cannot directly cause privileged tool execution, with policy tests, approval gates, tamper-evident audit events, and red-team evals.

16. Cloud-Provider Security Specialization

Choose this lane for cloud security, infrastructure security, or security consulting.

• Deepen Phases 02, 03, 05, 06, 07, and 09.
• Implement the same workload in AWS, Azure, and Google Cloud at architecture level; deploy one provider fully to control cost.
• Build IAM graph analysis, organization guardrails, workload identity, private networking, centralized logs, break-glass controls, and incident playbooks.
• Map controls to one regulated baseline in depth; map the others at a comparison level.
• Final research question: how do identity, tenant, and control-plane failures propagate?

Flagship proof: a tested landing zone and Kubernetes platform with policy-as-code, attack-path analysis, detections, recovery exercise, and executive remediation roadmap.

17. Android Vulnerability Research Specialization

Choose this lane for Android platform, mobile product security, or mobile VRP work.

• Deepen C/C++, ARM64, JNI, Binder, SELinux, ART, APK signing, WebView, Keystore, and fuzzing.
• Study AOSP source paths and monthly Android Security Bulletins; reproduce only public issues in compatible local builds or purpose-built apps.
• Maintain vulnerable and fixed app variants with instrumentation and regression tests.
• Final research question: which trust transition crosses Java/Kotlin, Binder, native code, kernel, hardware-backed services, or cloud APIs?

Flagship proof: an original lab-app finding or authorized open-source finding with minimized proof, root cause, patch, regression test, variant analysis, and conference-quality writeup.

18. Sandboxing and Isolation Specialization

Choose this lane for platform security, cloud workload isolation, or systems research.

• Deepen Linux internals, Rust/C/Go, namespaces, cgroups v2, seccomp-BPF, capabilities, LSMs, OCI/runc, KVM, virtio, gVisor, and Firecracker.
• Benchmark security and performance without claiming equivalence to production runtimes.
• Model malicious workloads, control-plane compromise, filesystem/device exposure, noisy-neighbor risks, side channels, and observability gaps.
• Final research question: what remains shared, and what happens when that shared component fails?

Flagship proof: a policy-driven workload runner with layered isolation, negative tests, telemetry, resource controls, and an honest limitations analysis.

19. ICS/OT Specialization

Choose this lane for critical infrastructure, industrial cloud, or public-sector security.

• Deepen Phase 10 plus network, Windows, cloud, IR, and executive communication.
• Use only simulation and vendor-provided training systems.
• Prioritize safety, availability, deterministic operations, passive discovery, and recovery.
• Never transpose IT playbooks blindly into OT; containment can create physical consequences.
• Final research question: which cyber control can alter process safety, and who authorizes it?

Flagship proof: a safety-reviewed architecture and incident exercise connecting an OT simulation to a cloud analytics platform without active probing of real industrial equipment.

20. Assessment Rubrics

Score every capstone from 0-4 in each category. A phase passes at 24/32, with no zero and no score below 2 in safety or reproducibility.

Staff-level distinction

A staff-level submission explains why the organization should choose a control, how it will be adopted, what it costs, how it fails, who owns it, and how success will be measured. Technical cleverness without organizational viability does not score a 4.

21. Final Job-Readiness Checklist

You are ready to apply when you can provide evidence for all of the following:

• I can define authorization, stop conditions, evidence handling, and disclosure workflow.
• I can review C/C++, Rust, Go, Python, Java/Kotlin, and shell code at security boundaries.
• I can explain a request from DNS through TLS, identity, authorization, service, and storage.
• I have led at least six threat models and three full secure design reviews.
• I can test web, API, Android, cloud, container, and endpoint controls in owned labs.
• I can explain Linux, Windows, macOS/iOS, and Android security architecture and limits.
• I built and threat-modeled a sandbox, not merely ran a container.
• I can design IAM, network, key, logging, Kubernetes, CI/CD, and policy controls.
• I can fuzz, minimize, triage, patch, retest, and report a vulnerability.
• I can preserve evidence, build a timeline, lead containment, and write a post-incident review.
• I can explain OT safety constraints and avoid unsafe IT assumptions.
• I can secure an LLM agent with real authorization, isolation, approvals, audit, and evals.
• I have six to eight polished artifacts and can defend every metric on my resume.
• I can brief the same risk to engineers, executives, customers, and auditors.
• I have eight STAR stories showing judgment, conflict handling, incident leadership, mentoring, ambiguity, customer trust, failed decisions, and measurable improvement.
• I can produce a credible 30/60/90-day plan for the target team.

Completing the calendar is not the finish line. Passing this evidence checklist is.

Minimum qualifications: Bachelor's degree in Computer Science, Information Systems, Cybersecurity a related technical field or equivalent practical experience. Certification in one or more of the following: CompTIA Security+; CompTIA Network+; ISC2 (CISSP); SANS-GIAC certification (GSEC, GCIH, GCED, GCFA, GCIA, GNFA, GPEN, GWAPT); CISCO (CCNA); EC-Council (CEH, LPT). 8 years of experience assessing and developing cybersecurity solutions across multiple security domains. Experience leading incident response activities and communicating investigation status to executive stakeholders

Preferred qualifications: Experience developing executive stakeholder client relationships to achieve project/long-term objectives. Understanding of security controls for common platforms and devices, including Windows, Linux and network equipment. Ability to communicate in Arabic fluently as this is a client facing role. Excellent written and verbal communication skills.

Security Lab Engineering Standard

Every lab in this track is a security engineering exercise, not a command transcript.

Required Files

Platform-specific labs may add docker-compose.yml, Terraform, Rego, Kotlin, C/C++, Rust, Go, Java/JVM, packet captures, manifests, or scripts, but they still need an offline-testable core.

Deep Guide Standard

Every phase has two complementary guides. They must not repeat a shallow tool tutorial.

WARMUP.md: explain the system

The warm-up must answer:

1. What problem does the subsystem solve, and why does it exist?
2. Which state, identities, objects, and authority does it maintain?
3. Which components execute in user space, kernel, hypervisor, control plane, or external service?
4. What exact data/control path occurs under the hood?
5. Where is policy evaluated and which component enforces it?
6. Which invariants define correct and secure behavior?
7. How do bugs compose into an attack chain?
8. What do mitigations prevent, and what do they explicitly not prevent?
9. Which evidence distinguishes observation from inferred impact?
10. How do patching, rotation, recovery, and residual risk work?

Use mechanism diagrams, state transitions, trust/authority tables, and small code/configuration fragments where they clarify causality. Define acronyms and connect abstractions to the runnable labs.

HITCHHIKERS-GUIDE.md: operate the system

The operator guide must provide:

• a purpose-built authorized range architecture;
• build and inspection workflow;
• safe attack/failure fixtures with expected observations;
• hardening steps tied to the mechanism they change;
• negative, boundary, compatibility, and failure-injection tests;
• runtime verification that proves effective state rather than intended configuration;
• telemetry, detection, triage, containment, and recovery;
• cleanup/teardown and cost/resource controls;
• evidence packet and completion criteria;
• common false claims and control limitations.

Commands without expected state, explanation, and verification do not meet this standard.

Required Learning Loop

1. Authorize: define owner, scope, permitted methods, data, time, rates, and stop conditions.
2. Model: draw assets, identities, flows, trust boundaries, and security invariants.
3. Attack safely: run a seeded case only against the owned fixture.
4. Observe: collect the log, packet, trace, crash, policy decision, or evidence manifest.
5. Explain: distinguish precondition, root cause, demonstrated impact, and plausible impact.
6. Mitigate: change design/code/configuration, not only the triggering input.
7. Regress: prove the attack fails and legitimate behavior still works.
8. Operate: add telemetry, response, rollback, cleanup, and ownership.
9. Communicate: write developer remediation and executive decision summaries.

Test Taxonomy

Every flagship lab must include:

• happy-path tests;
• malformed and oversized input;
• deny-by-default behavior;
• cross-tenant, cross-scope, or privilege-negative cases where relevant;
• race/replay/duplicate/idempotency cases where relevant;
• log redaction and secret canaries;
• regression tests for every seeded weakness;
• failure cleanup and fail-closed behavior.

Safety Rules

• Use only included fixtures, owned local services, CTFs, or explicitly authorized programs.
• Do not target public hosts, neighboring networks, real users, or third-party infrastructure.
• Do not add persistence, stealth, credential theft, destructive payloads, or defense evasion.
• Stop at minimum proof and preserve only the data required to explain and remediate the issue.
• Any lab involving vulnerable services, mobile instrumentation, malware-like samples, cloud accounts, or OT protocols must pass templates/lab-acceptance-checklist.md.

Definition of Done

A lab is complete only when the reference suite passes, the learner implementation passes after the TODOs are completed, the setup works from a clean checkout, and the report states limitations.

Security Lab Catalog and Requirements Traceability

The track contains 58 runnable core labs (including five advanced, intensive labs: HTTP request smuggling, the seccomp-BPF compiler, the coverage-guided fuzzer, the lethal-trifecta agent guard, and the Windows token-escalation analyzer). Labs use Python, C, C++, Rust, Go, Java, Kotlin/JNI, IaC, policy, and configuration where each is appropriate. Every core has learner work, a reference, adversarial verification through pytest or the native toolchain, and a platform extension. Larger phase exercises compose these cores rather than duplicating policy logic in throwaway scripts.

Phase 00 - Safety and Lab Operations

Covers isolated range, endpoint inventory inputs, telemetry paths, cloud sandbox policy, ROE, disclosure, evidence handling, and research notebook discipline.

Phase 01 - Systems

Covers vulnerable/fixed C, parsers, fuzzing, ELF/binary analysis, syscall tracing, debugger inputs, secure systems tooling, HTTP-service boundaries, and secret-manager prerequisites.

Phase 02 - Network, Web, Identity, and Crypto

Phase extensions add packet captures, vulnerable/fixed web routes, SAML, SCIM, mTLS, TLS inspection, password recovery, JWT policy, and secrets rotation using the same negative-test model.

Phase 03 - Application Security and SDLC

Covers threat modeling, design review, checklists, SAST/DAST/SCA/secrets/container/IaC gates, vulnerability workflow, developer training, executive memo, and release approval.

Phase 04 - Android

Phase extensions use JADX/apktool/adb/Frida on the owned app, Binder/AIDL caller validation, WebView fixtures, local proxying/pinning rotation, JNI parser sanitizers, and native fuzzing.

Phase 05 - OS Security

Covers Linux LSM/seccomp/eBPF/systemd, Windows ETW/Sysmon/PowerShell/AD/Kerberos, and macOS signing, TCC, Keychain, entitlements, and endpoint telemetry.

Phase 06 - Isolation

Covers minimal runtime, namespaces, cgroups, seccomp, capabilities, rootless operation, syscall interception, gVisor comparison, microVM isolation, monitoring, and escape-prevention controls.

Phase 07 - Cloud and Kubernetes

Phase extensions deploy landing zone, segmentation, workload identity, KMS/secrets, registry signing, logging/detection, cloud IR, Terraform security, and backup/restore.

Phase 08 - Vulnerability Research

Covers parser/image/protocol fuzzing, sanitizers, crash/root cause analysis, reverse engineering, patch diffing, variant review, CTF-style binaries, and responsible disclosure.

The CVE Casebook adds primary-source studies of Heartbleed, Log4Shell, runc isolation failures, and ingress-nginx CVE-2025-1974, each mapped to a safe lab, patch invariant, variant search, fleet response, and detection plan.

Phase 09 - Incident Response and Detection

Covers Windows/Linux/cloud/Kubernetes telemetry, memory/disk/network forensics, benign malware triage, dashboards, timeline, MITRE mapping, incident simulation, executive report, and PIR.

Phase 10 - OT

Covers simulated ICS network, protocol analysis, passive discovery, segmentation, cloud-connected threat model, vulnerability plan, detections, and safety-aware incident response.

Phase 11 - AI and Agent Security

Covers code review, vulnerability triage, remediation, cloud posture, logs, threat models, compliance mapping, disclosure drafting, injection defense, least privilege, audit, and evals.

Phase 12 - Staff Practice

Covers executive and engineering presentations, VRP readiness, public writing, talk proposal, specialization mock interviews, STAR stories, portfolio curation, and joining plan.

Phase 13 - Hardware, Firmware, and Device Security (Elite/Principal)

Covers hardware root of trust, verified vs measured boot, TPM/PCRs, remote attestation, TEEs and confidential computing, firmware/SMM/ME security, secure OTA + anti-rollback, key provisioning/DICE, and the physical/side-channel threat model.

Phase 14 - Software Supply Chain Security (Elite/Principal)

Covers the source-to-consumer threat model, in-toto provenance + materials reconciliation, SLSA levels, hermetic/reproducible builds, keyless signing + Merkle transparency logs, binary authorization, dependency confusion/typosquat/hijack defenses, and SBOM/VEX.

Phase 15 - Compliance and Authorization Engineering (Elite/Principal)

Covers NIST 800-53 families/baselines, the FedRAMP ATO process, the authorization boundary and control inheritance, OSCAL/compliance-as-code, continuous monitoring + POA&M SLAs, FIPS 140-3 validated crypto, and the PCI/HIPAA/SOC 2/ISO/CMMC crosswalk.

Security Glossary — Acronyms and Terms Across the Track

A one-line definition for every acronym and term used across the curriculum, with the phase/module where it's covered in depth. Use it as a quick reference; follow the pointer for the full from-zero treatment. Organized alphabetically. (Pnn = phase; module names link to the mastery modules.)

A

• ABAC — Attribute-Based Access Control: authorize by attributes of subject/resource/action/context. P02, P07.
• ABI — Application Binary Interface: the machine-level calling convention/layout contract. P01.
• AEAD — Authenticated Encryption with Associated Data (AES-GCM, ChaCha20-Poly1305): confidentiality + integrity in one. P02.
• AD — Active Directory: Microsoft's enterprise directory/auth backbone. P05.
• ADP — Authorized Data Publisher: a party that enriches a CVE record (e.g. CISA Vulnrichment). P08.
• AMSI — Antimalware Scan Interface: lets defenders inspect de-obfuscated script content in memory. P05, P09.
• APK / AAB — Android Package / App Bundle: the app artifact / Play upload format. P04.
• ASLR — Address Space Layout Randomization: randomizes memory layout; defeated by an info leak. P01, P08.
• ASM — Attack-Surface Management: continuously discovering your own exposed assets. Offensive module.
• ASVS — OWASP Application Security Verification Standard: the verifiable-requirements catalog (L1–L3). Standards module, P03.
• ATT&CK — MITRE's tactic→technique matrix of adversary behavior. P09, Standards & Offensive modules.
• AT (CVSS v4) — Attack Requirements, a new v4 base metric. Standards module Lab 05.
• ATO — Authorization to Operate: a system's formal authorization (FedRAMP/RMF). P15.
• ATS — App Transport Security: iOS policy forcing good TLS by default. iOS module.
• ATT (App Tracking Transparency) — iOS opt-in prompt for cross-app tracking. iOS module.

B

• BCP 38 — RFC 2827 ingress filtering (source-address validation) to stop spoofed packets. Availability module.
• BEC — Business Email Compromise: fraudulent-instruction email attack. P02, Offensive module.
• BLE — Bluetooth Low Energy. Wireless module.
• BMC — Baseboard Management Controller: out-of-band, network-reachable server management processor. P13.
• BOLA / IDOR — Broken Object-Level Authorization / Insecure Direct Object Reference: the flagship authz bug. P02.
• BOPLA — Broken Object Property-Level Authorization (mass assignment). P02.

C

• C2 — Command-and-Control: the channel a compromised host uses for instructions/exfil. P09, Offensive module.
• CA — Certificate Authority: signs certs binding a key to a name. P02, P02 Lab 10.
• CAPEC — Common Attack Pattern Enumeration and Classification (MITRE). Standards module.
• CCM — Cloud Controls Matrix (CSA): cloud control catalog with crosswalks. P07, Standards module.
• CDN — Content Delivery Network: distributed edge caches. P02, Availability module.
• CIS — Center for Internet Security: Controls + Benchmarks (hardening guides). Standards module, P05–P07.
• CISA — US Cybersecurity and Infrastructure Security Agency: KEV, advisories, Secure by Design. P08, Standards module.
• CNA — CVE Numbering Authority: an org authorized to assign CVE IDs. P08.
• CNAPP / CSPM — Cloud-Native Application Protection Platform / Cloud Security Posture Management. P07.
• CNI — Container Network Interface: the k8s pluggable networking component that enforces NetworkPolicy. P07.
• CORS — Cross-Origin Resource Sharing: a relaxation of the Same-Origin Policy for reading responses (not an access control). P02.
• CSP — Content Security Policy: a response header constraining resource sources (XSS defense-in-depth, frame-ancestors for clickjacking). P02.
• CSPRNG — Cryptographically Secure Pseudo-Random Number Generator. P02.
• CSRF — Cross-Site Request Forgery: abuse of ambient cookie authority. P02.
• CVE — Common Vulnerabilities and Exposures: a unique public name for one vulnerability. P08.
• CVSS — Common Vulnerability Scoring System (FIRST): 0–10 severity from a vector. P08, Standards module.
• CWE — Common Weakness Enumeration (MITRE): the class of bug (e.g. CWE-89 SQLi). P08, Standards module.
• chain of custody — the recorded, unbroken provenance of evidence. P00, P09.
• confused deputy — a privileged component tricked into misusing its authority for an attacker. P02, P04.

D

• DAC / MAC — Discretionary / Mandatory Access Control. P05.
• DAST — Dynamic Application Security Testing: probe the running app. P03.
• DEK / KEK — Data / Key Encryption Key (envelope encryption). P02, P07.
• DEP / NX — Data Execution Prevention / No-eXecute: non-executable data pages; pushed attackers to ROP. P01, P08.
• DICE — Device Identifier Composition Engine: layered device identity from a hardware secret. P13.
• Diamond Model — adversary/capability/infrastructure/victim intrusion-analysis lens. Offensive & Standards modules.
• differential privacy (DP) — calibrated-noise query privacy with a bounded ε guarantee. Privacy module.
• DKIM — DomainKeys Identified Mail: signs email; survives forwarding. P02.
• DMARC — Domain-based Message Authentication, Reporting & Conformance: ties SPF/DKIM to the visible From: via alignment + policy. P02.
• DMZ — Demilitarized Zone: a buffer network between trust levels (the iDMZ in OT). P10.
• DPIA — Data Protection Impact Assessment: GDPR's high-risk-processing risk assessment. Privacy module.
• DSAR — Data Subject Access Request (and the right to erasure). Privacy module.
• DoS / DDoS — (Distributed) Denial of Service. Availability module.

E

• EAP / EAP-TLS — Extensible Authentication Protocol; certificate-based variant for 802.1X. Wireless module.
• EC — Embedded Controller: small chip managing power/keyboard/thermals. P13.
• ECB — Electronic CodeBook: a broken cipher mode that leaks structure. P02.
• EDR / MDM — Endpoint Detection & Response / Mobile Device Management. P05, P09.
• eBPF — in-kernel programmable observability/enforcement. P05.
• ELF / PE / Mach-O — executable formats (Linux / Windows / Apple). P01.
• EPSS — Exploit Prediction Scoring System (FIRST): probability of exploitation in 30 days. P08, Standards module.
• evil twin — a rogue AP cloning a legitimate SSID with a stronger signal. Wireless module.
• exploit primitive — a reliable read/write/control-flow capability a bug grants. P08.

F

• FedRAMP — US government cloud authorization program (NIST 800-53 + continuous monitoring). P15.
• FIDO2 / WebAuthn — phishing-resistant, origin-bound authentication (passkeys). P02 Lab 12.
• FIPS — Federal Information Processing Standards (e.g. 140-3 validated crypto modules; 199 categorization). P15, Standards module.
• FIRST — Forum of Incident Response and Security Teams: stewards CVSS, EPSS, TLP. Standards module.
• Frida — dynamic instrumentation toolkit (hooks/rewrites functions at runtime). P04, iOS module.
• fuzzing — feeding many inputs to find crashes; coverage-guided = evolutionary search. P08, P01.

G–H

• GHSA — GitHub Advisory Database / Security Advisory. P08.
• GOT — Global Offset Table: resolved-import address table; RELRO makes it read-only. P01.
• HIBP — Have I Been Pwned: breach corpus queried via k-anonymity range. P02 Lab 11.
• HMAC — keyed-hash MAC immune to length extension. P02.
• HSTS — HTTP Strict Transport Security. P02.
• HSM / KMS — Hardware Security Module / Key Management Service: key material in a hardened boundary. P02, P07.

I

• IAM — Identity and Access Management (cloud). P07.
• IaC — Infrastructure as Code (Terraform, etc.). P07.
• IAST — Interactive Application Security Testing. P03.
• iDMZ — Industrial DMZ: the brokered buffer between IT and OT. P10.
• IDS / IPS — Intrusion Detection / Prevention System. P09.
• IETF — Internet Engineering Task Force: publishes RFCs (TLS, OAuth, HTTP, JWT). Standards module.
• IOC — Indicator of Compromise (hash/IP/domain) — low on the pyramid of pain. P09.
• ISO/IEC 27001 — certifiable Information Security Management System; 27002 = controls; 29147/30111 = disclosure/handling. Standards module, P15.

J–K

• JNI — Java Native Interface: the Java↔C/C++ boundary where memory bugs re-enter. P04.
• JWT / JWS / JWE — JSON Web Token / Signature / Encryption; validation is a protocol, not decode(). P02.
• k-anonymity — every record indistinguishable from k−1 others on quasi-identifiers. Privacy module.
• KDF — Key Derivation Function; for passwords use slow/salted/memory-hard (Argon2id/bcrypt/scrypt/PBKDF2). P02.
• Kerberos / Kerberoasting — ticket-based auth; offline-cracking service-account tickets. P05.
• KEV — CISA Known Exploited Vulnerabilities catalog (confirmed in-the-wild). P08, Standards module.
• Kill Chain — Lockheed Martin's linear intrusion-phase model. Offensive & Standards modules.

L–M

• LAPS — Local Administrator Password Solution: unique per-host admin passwords (breaks credential-reuse). Offensive module.
• l-diversity — each k-anonymous class has ≥ l distinct sensitive values (fixes homogeneity). Privacy module.
• LOLBins — Living-off-the-Land Binaries: abusing trusted signed tools. P09, Offensive module.
• LSM — Linux Security Module (SELinux/AppArmor): mandatory access control. P05, P06.
• MAC (crypto) — Message Authentication Code; compare in constant time. P02.
• MASVS / MASTG — OWASP Mobile App Security Verification Standard / Testing Guide. P04, iOS module.
• MFA — Multi-Factor Authentication (phishing-resistant = WebAuthn/passkeys). P02.
• MITRE — nonprofit owning CVE, CWE, CAPEC, ATT&CK, D3FEND. Standards module.
• mTLS — mutual TLS: both peers authenticate. P02, P07.

N–O

• NAT — Network Address Translation. P00.
• NIST — US standards engine: SP 800 series, FIPS, CSF, RMF, NVD. Standards module, P15.
• NVD — National Vulnerability Database (NIST enrichment of CVE). P08.
• OAuth2 / OIDC — delegated authorization / identity layer on top. P02.
• OCSP / CRL — Online Certificate Status Protocol / Certificate Revocation List. P02.
• OSCAL — Open Security Controls Assessment Language (compliance as code). P15.
• OSINT — Open-Source Intelligence (reconnaissance). Offensive module.
• OTA — Over-the-Air (firmware update); must be signed + anti-rollback. P13.
• OWASP — Open Worldwide Application Security Project: Top 10, ASVS, Cheat Sheets, ZAP. Standards module, P02/P03.

P

• PAC — Pointer Authentication (ARM64): signs pointers to detect tampering. P01.
• padding oracle — leaks CBC plaintext byte-by-byte via padding-validity feedback. P02.
• PCI DSS — Payment Card Industry Data Security Standard (contractual). P15, Standards module.
• PKCE — Proof Key for Code Exchange: binds the OAuth code to the initiating client. P02.
• PKI — Public Key Infrastructure: CAs, chains, validation. P02.
• PLC / RTU / HMI / SCADA / SIS — industrial control equipment / supervisory systems / safety system. P10.
• PMKID — a WPA2 field enabling client-free offline handshake cracking. Wireless module.
• prototype pollution — polluting JavaScript's shared Object.prototype. P02.
• provenance / SLSA — verifiable build metadata / build-integrity levels. P14, P03.
• pseudonymization vs anonymization — reversible tokenization (still personal data) vs irreversible. Privacy module.
• Pyramid of Pain — indicators (cheap to change) vs TTPs (expensive). P09, Offensive module.

Q–R

• RBAC / ReBAC — Role- / Relationship-Based Access Control (Zanzibar). P02, P07.
• RCE — Remote Code Execution. P08.
• ReDoS — Regular-expression Denial of Service (catastrophic backtracking). Availability module.
• RELRO — RELocation Read-Only: makes the GOT read-only. P01.
• RFID / NFC — radio-frequency / near-field identification; static-ID tags are clonable. Wireless module.
• RMF — NIST Risk Management Framework (the ATO lifecycle). P15.
• ROP — Return-Oriented Programming: chaining existing code gadgets to defeat NX/DEP. P01, P08.
• rate limiting — token bucket / leaky bucket / fixed & sliding window (per-key). Availability module.

S

• SAML / SCIM — XML SSO assertions / cross-domain provisioning. P02.
• SAST — Static Application Security Testing (taint analysis). P03 Lab 04.
• SBOM / VEX — Software Bill of Materials / Vulnerability Exploitability eXchange. P14, P03.
• SAE — Simultaneous Authentication of Equals: WPA3's offline-cracking-resistant handshake. Wireless module.
• SDLC — Software Development Life Cycle (secure = SSDF, shift-left). P03.
• seccomp — syscall-filtering sandbox mechanism. P05, P06.
• Secure Enclave / TEE / TrustZone / SGX / SEV-SNP / TDX — hardware-isolated execution. P05, P13.
• SIEM — Security Information and Event Management (log platform). P09.
• Sigstore / Cosign / Fulcio / Rekor — keyless signing + transparency log. P14.
• SLSA — Supply-chain Levels for Software Artifacts (OpenSSF). P14.
• SMM (ring -2) — System Management Mode: firmware more privileged than the kernel. P13.
• SOC 2 — trust-services audit of operating controls. P15, Standards module.
• SOP — Same-Origin Policy (the browser rule CORS relaxes). P02.
• SPF — Sender Policy Framework: authorizes sending IPs for a domain (envelope, not visible From). P02.
• SPIFFE / SPIRE — workload identity standard / runtime. P07.
• SQLi / XSS / SSRF / SSTI / XXE — injection / cross-site scripting / server-side request forgery / template injection / XML external entity. P02.
• SSDF — NIST Secure Software Development Framework (SP 800-218). P03.
• SSVC — Stakeholder-Specific Vulnerability Categorization: decision tree (Track/Track*/Attend/Act). P08, Standards module Lab 05.
• STIX / TAXII / MISP — structured threat-intel format / transport / sharing platform. Standards module Lab 04.
• STRIDE — Spoofing/Tampering/Repudiation/Info-disclosure/DoS/Elevation threat taxonomy. P03.
• subdomain takeover — claiming a dangling DNS record pointing at a deprovisioned resource. Offensive module.

T–U

• TCC — Transparency, Consent, and Control: Apple's privacy-permission system. P05, iOS module.
• TLP — Traffic Light Protocol: intel-sharing handling labels. FIRST; Standards module.
• TLS — Transport Layer Security (1.3 = RFC 8446). P02, P02 Lab 10.
• TOCTOU — Time-Of-Check to Time-Of-Use race (incl. web race conditions). P01, P02, P06.
• TPM / PCR — Trusted Platform Module / Platform Configuration Register (extend-only). P13.
• TTP — Tactics, Techniques, and Procedures (the behavior level of intel). P09.
• token bucket — rate-limiting algorithm: sustained rate + controlled bursts. Availability module.
• UAF — Use-After-Free. P01, P08.
• UAC — User Account Control (explicitly not a security boundary). P05.
• UBSan / ASan / MSan / TSan — Clang sanitizers (UB / address / memory / thread). P01, P08.

V–Z

• variant analysis — finding all instances of a bug class, not just the one found. P08.
• VEX — see SBOM/VEX. P14.
• VRP — Vulnerability Reward Program (bug bounty) + coordinated disclosure. P00, P08.
• WAF — Web Application Firewall (edge request filtering). P02, P03.
• WebAuthn — see FIDO2. P02 Lab 12.
• WPA2 / WPA3 / 802.1X — Wi-Fi security (PSK handshake / SAE / Enterprise). Wireless module.
• XSW — XML Signature Wrapping (a SAML parser-differential attack). P02.
• YARA — pattern-matching rules over files/memory for malware classification. P09 Lab 04.
• Zanzibar — Google's ReBAC authorization system. P02, P07.
• Zero Trust — authorize every request by identity/context, not network location (NIST 800-207). P07.

This glossary indexes the deep treatments; for any term, open the linked phase/module WARMUP for the full from-zero explanation, mechanism, attack/defense, and misconception.

Standards and Frameworks Mastery — A Cross-Cutting Module

What this is. A phase-equivalent, cross-cutting module on the security standards bodies and frameworks that every other phase relies on: OWASP, NIST, MITRE, FIRST, CIS, ISO/IEC, the IETF, and the cloud/supply-chain bodies (CSA, OpenSSF, CISA, PCI SSC) plus the cloud-provider frameworks. The phases use these constantly; this module is where you learn them from first principles and, more importantly, build the engines that operationalize them.

Why it's its own module, not a references appendix. Reading "OWASP Top 10" or "NIST 800-53" in a references list teaches nothing. A staff/principal security engineer can do four things with any framework: sort it into a kind (catalog / taxonomy / scoring / process), map it to a real system, implement and evidence a control, and crosswalk one control across many frameworks. Those are engineering skills, so this module is built like every other: a deep guide plus runnable labs with adversarial tests.

Prerequisites. Comfortable Python; ideally Phases 02, 03, 08, and 15 (the labs reuse the CVSS, crosswalk, and CWE/ATT&CK ideas those phases introduce). Everything here is offline and authorized-lab-only — the labs reason over metadata (vectors, control records, finding labels), never live systems.

Learning Objectives

By the end you can, without notes:

1. Explain each standards body — who they are, why they exist, what they publish — and sort every framework into one of the four kinds: catalog of controls, taxonomy of weaknesses/attacks, scoring system, or process/lifecycle.
2. Tie each framework to real code and infrastructure — OWASP injection to parameterized queries in Rails/Django/JDBC, NIST FIPS to OpenSSL/JVM FIPS mode, MITRE CWE to language-agnostic bug classes, IETF RFCs to your TLS/OAuth/JWT stack, CIS Benchmarks to your container/k8s/cloud config.
3. Prioritize a vulnerability backlog with CVSS × EPSS × KEV × reachability (not raw CVSS).
4. Crosswalk one engineered control across NIST/OWASP/ISO/PCI/CIS so one implementation satisfies many audits.
5. Normalize scanner findings to weakness classes (CWE) and map them to attack patterns and adversary behavior (CAPEC/ATT&CK) for coverage analysis.

The Mental Model (read the WARMUP first)

KIND                 ANSWERS                EXAMPLES                          THIS MODULE'S LAB
catalog of controls  "what should I do?"    NIST 800-53, OWASP ASVS, CIS      Lab 02 (crosswalk)
taxonomy             "what goes wrong?"     MITRE CWE/CAPEC/ATT&CK, Top 10    Lab 03 (taxonomy map)
scoring system       "how bad / how likely?" FIRST CVSS/EPSS, CISA KEV        Lab 01 (triage)
process / lifecycle  "how do I run it?"     NIST RMF/SSDF, ISO 27001, SAMM    Lab 02 (evidence/crosswalk)

See WARMUP.md for the full from-zero treatment of every body and framework, with the coding/network/cloud tie-ins and a phase-mapping table.

Labs

Each lab follows the track standard (LAB-STANDARD.md): a lab.py with focused TODOs, a complete solution.py, an adversarial test_lab.py, and a README.md. Run:

cd lab-01-vuln-triage-engine
LAB_MODULE=solution pytest -q   # reference passes
pytest -q                        # your implementation after the TODOs

Deliverables

• A working triage engine that computes correct CVSS v3.1 base scores (validated against the canonical vectors) and produces a defensible, ordered patch queue from CVSS+EPSS+KEV+reachability.
• A working crosswalk engine that validates a control library against multiple framework requirement sets, flags gaps/dangling/unsubstantiated mappings, and reports per-framework coverage and the highest-leverage controls.
• A working taxonomy mapper that deduplicates findings by CWE class, enriches them with CAPEC/ATT&CK/OWASP/Top-25 context, and reports ATT&CK detection-coverage gaps.
• The ability to answer the WARMUP's interview questions and explain, for any framework you encounter on the job, which kind it is and how you'd operationalize it.

Safety

Authorized-lab-only and entirely offline. The labs reason over metadata — CVSS vectors, control records, and finding labels in the included fixtures. No live scanning, no network, no real systems. This module is about engineering judgment over framework data, which is exactly the staff-level skill it certifies.

Warmup Guide — Security Standards Bodies and Frameworks from First Principles

The deep guide for the Standards and Frameworks Mastery module. Every phase cites OWASP, NIST, MITRE, FIRST, CIS, ISO, the IETF, and the cloud bodies as authorities — this guide explains, from first principles, who they are, what they publish, why it exists, and — crucially — how each framework lands in real code and infrastructure (Java/JVM, Python, Ruby on Rails, Node, cloud, Kubernetes). Read it once; the phases link back here rather than re-explaining. The goal is to stop you treating these as magic acronyms in a references section and start reading them the way a staff engineer does: as requirement specs, taxonomies, scoring systems, and processes you implement and verify. Three runnable labs turn that fluency into code — a CVSS/EPSS/KEV triage engine, a multi-framework control-crosswalk engine, and a CWE/CAPEC/ATT&CK weakness-taxonomy mapper.

Table of Contents

• Chapter 1: Why Standards Bodies Exist — and the Four Kinds of Framework
• Chapter 2: OWASP — Application Security for People Who Ship Code
• Chapter 3: NIST — The Standards Engine Behind US Government Security
• Chapter 4: MITRE — CVE, CWE, CAPEC, and ATT&CK
• Chapter 5: FIRST — Scoring and Sharing Vulnerabilities
• Chapter 6: CIS — Hardening Benchmarks and Controls
• Chapter 7: ISO/IEC — International Management Standards
• Chapter 8: Cloud and Supply-Chain Bodies — CSA, OpenSSF, CISA, PCI
• Chapter 9: IETF — The Network and Protocol Standards (RFCs)
• Chapter 10: Cloud-Provider Security Frameworks
• Chapter 11: Putting It Together — Crosswalks, Not Cargo-Culting
• Chapter 12: Threat-Intelligence Frameworks — Kill Chain, Diamond, and the Intel Lifecycle
• How This Maps to the Phases
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Why Standards Bodies Exist — and the Four Kinds of Framework

Zero background. A standards body is an organization that publishes agreed-upon documents so that thousands of independent teams can build, assess, and talk about security the same way. Without them, every company would invent its own definition of "critical," its own list of "the bugs that matter," its own hardening checklist — and nobody could compare, audit, or interoperate. They exist for the same reason the metric system or TCP/IP exists: a shared reference is worth more than any single party's private one. Some bodies are government (NIST, CISA — US), some are nonprofit communities (OWASP, MITRE, OpenSSF), some are industry consortia (PCI SSC, FIRST, CSA, CIS), and some are international treaty-style organizations (ISO/IEC, IETF).

The single most useful mental model: there are only four kinds of framework. Once you can sort any document into one of these buckets, you know how to use it instead of being intimidated by it:

Why this matters for an engineer specifically. A catalog (ASVS, 800-53) becomes tests in CI. A taxonomy (CWE, ATT&CK) becomes what your scanners and detections target. A scoring system (CVSS, EPSS) becomes your patch queue's sort order. A process (RMF, SSDF) becomes the gates in your pipeline. The frameworks are not paperwork — they are the externally-validated specification of the work you do in every phase of this track.

The reading discipline (don't cargo-cult). A framework is a prompt to think, not a form to complete. The recurring failure across this curriculum — checklist-only threat modeling, "we ran the scanner so we're secure," CVSS-as-risk — is treating the artifact as the goal. You map the framework to your system, implement real controls, and evidence that they operate (Chapter 11).

Misconception to kill now. "Standards are bureaucracy that slows engineers down." The opposite: they save you from re-deriving the entire field. A staff engineer uses them as leverage — one ASVS requirement, one CWE pattern, one CIS benchmark line — to make a decision defensible in minutes instead of arguing it from scratch.

Chapter 2: OWASP — Application Security for People Who Ship Code

What it is. OWASP (the Open Worldwide Application Security Project) is a nonprofit, open community that produces free, vendor-neutral application-security knowledge: documents, standards, and tools, all written by and for developers. If NIST is the government's voice and MITRE is the research community's, OWASP is the builder's voice — it speaks in terms of code and web requests, not compliance language. This is the body whose output you touch most as a working engineer.

Why it exists. Web applications became the dominant attack surface, and most developers had no accessible, practical guidance on how they get hacked. OWASP filled that gap with material any engineer can read and apply the same afternoon.

The deliverables you must know (and where each lands in code):

• OWASP Top 10 — the flagship: a data-driven (built from real-world vulnerability data across hundreds of thousands of applications) list of the ten most critical web-app risk categories. The 2021 edition leads with Broken Access Control (A01) and includes Injection (A03), Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, and more. It is a taxonomy, not a checklist — A03 Injection is one root cause realized a hundred ways. In code: Injection is fixed by separating code from data — ActiveRecord parameter binding (where("email = ?", input), never string interpolation) in Rails, the Django ORM or cursor.execute(sql, params) in Python, PreparedStatement/JPA in Java, parameterized drivers in Node. Broken Access Control (A01) is the IDOR/BOLA work from Phase 02 — a Rails controller scoping current_user.invoices.find(params[:id]) instead of Invoice.find(params[:id]).
• OWASP API Security Top 10 — the same idea specialized for APIs, where Broken Object-Level Authorization (BOLA) and Broken Function-Level Authorization dominate (Phase 02).
• OWASP ASVS (Application Security Verification Standard) — a catalog of controls organized as verifiable requirements at three levels (L1 opportunistic, L2 standard, L3 high-assurance). This is the one you turn into tests: "V2: verify the session token is rotated on privilege change," "V5: verify output encoding is contextual." ASVS is how you make "is this app secure?" a checklist of pass/fail assertions in CI rather than a vibe.
• OWASP MASVS / MASTG (Mobile) — the verification standard and testing guide for mobile apps; the backbone of Phase 04 (Android). MASVS is the what to verify; MASTG is the how to test it.
• OWASP Top 10 for LLM Applications — the AI-era list (prompt injection, insecure output handling, excessive agency); the spine of Phase 11.
• OWASP Cheat Sheet Series — short, concrete, implementation-level guides (the Authentication, CSRF, SSRF, Deserialization, Password Storage cheat sheets). When you need "how do I do X correctly in practice," this is the first stop.
• OWASP SAMM (Software Assurance Maturity Model) — a process framework for measuring and improving an org's security program maturity (Phase 03).
• Tools: ZAP (the Zed Attack Proxy — a DAST scanner, Phase 03), Dependency-Check and Dependency-Track (SCA — flagging known-vulnerable dependencies, Phase 03/14).

Where it bites in real stacks. The JVM deserialization lab (Phase 02) is OWASP's "Insecure Deserialization" made concrete: Java ObjectInputStream, Ruby Marshal/YAML.load, Python pickle all rebuild arbitrary object graphs and are gadget-chained to RCE (ysoserial). OWASP's guidance — never deserialize untrusted native objects; use schema-validated JSON — is the fix. XSS lands in your templating layer (Rails ERB auto-escaping, Django autoescape, React's JSX escaping) and OWASP's context-aware-encoding rule tells you when auto-escaping is not enough (inside a <script>, a URL, or an HTML attribute).

Misconception to kill now. "We follow the OWASP Top 10, so we're covered." The Top 10 is an awareness taxonomy of the most common categories — it is explicitly not a complete checklist. The verification standard for "are we actually secure" is ASVS; the Top 10 is where you start, not where you stop.

Chapter 3: NIST — The Standards Engine Behind US Government Security

What it is. NIST (the National Institute of Standards and Technology) is a US federal agency that publishes the technical standards the US government — and, by gravitational pull, much of the private sector and the world — runs on. Its security output has two main lines: the SP 800 series (Special Publications: detailed guidance) and FIPS (Federal Information Processing Standards: mandatory standards for federal systems, especially cryptography).

Why it exists. The US government needed a consistent, defensible way to secure and authorize thousands of systems across hundreds of agencies. Because federal procurement is enormous, NIST's choices become de facto global standards (vendors implement them to sell to the government, and everyone else inherits them).

The SP 800 documents you'll meet across this track:

• SP 800-53 — the master catalog of controls (access control, audit, crypto, incident response, …), grouped into ~20 families (AC, AU, IA, SC, …). This is the backbone of FedRAMP and Phase 15 — each control becomes an implementation statement you evidence.
• SP 800-37 (RMF, Risk Management Framework) — the process for categorizing, selecting, implementing, assessing, authorizing, and monitoring controls. The lifecycle behind an ATO.
• SP 800-63 (Digital Identity Guidelines) — authentication and identity assurance (password rules, MFA, federation). In code: this is what shapes Devise/bcrypt in Rails, Django's auth and password hashers, and your MFA/session policy (Phase 02).
• SP 800-61 (Incident Handling) and SP 800-86 (Forensic Techniques) — the IR lifecycle and order-of-volatility behind Phase 09.
• SP 800-190 (Container Security) and SP 800-207 (Zero Trust Architecture) — the cloud/k8s and identity-is-the-perimeter models of Phase 06/07.
• SP 800-218 (SSDF, Secure Software Development Framework) — the process for building security into the SDLC (Phase 03); referenced by US Executive Order 14028 on supply-chain security.
• SP 800-161 (Supply-Chain Risk Management) — the supply-chain spine of Phase 14.

FIPS — the mandatory ones, mostly cryptographic:

• FIPS 199 — how you categorize a system's impact (Low/Moderate/High) — the input that selects a 800-53 baseline (Phase 15).
• FIPS 140-3 — validated cryptographic modules: crypto must run in an independently-tested, certified module (a CMVP certificate), not just "correct AES." In code: this is FIPS mode in OpenSSL, the JVM's BouncyCastle FIPS provider or a validated JCE, and Python's cryptography/ hashlib when backed by a FIPS OpenSSL — using AES-256 from a non-validated path does not satisfy it (Phase 15 Chapter 7).
• FIPS 197 (AES), FIPS 186 (digital signatures), FIPS 180/202 (SHA-2/SHA-3), and the new FIPS 203/204/205 (post-quantum: ML-KEM, ML-DSA, SLH-DSA) — the algorithm standards your crypto libraries implement.

The cross-cutting frameworks:

• NIST CSF (Cybersecurity Framework) — a high-level process/governance model organized into six functions: Govern, Identify, Protect, Detect, Respond, Recover. It's the org-level structure executives and roadmaps use (Phase 12) — a common language above the technical controls.
• NIST AI RMF — risk management for AI systems (Phase 11).
• NVD (National Vulnerability Database) — NIST's enrichment of the CVE list with CVSS/CWE/CPE (Phase 08 Chapter 13).

Misconception to kill now. "NIST is just government compliance paperwork." NIST docs are some of the most rigorous engineering references in the field — 800-63 is the definitive word on authentication, 800-207 defines zero trust, and FIPS 140-3 is why your kms.Encrypt() call is trustworthy. Treat them as specifications, not bureaucracy.

Chapter 4: MITRE — CVE, CWE, CAPEC, and ATT&CK

What it is. MITRE is a US nonprofit that operates federally funded research and development centers; in security it is the naming authority for the field's shared vocabularies. Where OWASP teaches builders and NIST writes controls, MITRE builds the taxonomies everyone references — the dictionaries of what goes wrong and how attackers operate. Almost every tool you use speaks MITRE's identifiers under the hood.

The four taxonomies, from instance to behavior:

• CVE (Common Vulnerabilities and Exposures) — a unique public name for one specific vulnerability instance (CVE-2021-44228 = Log4Shell). It's the join key of the whole vulnerability-management industry. Covered in depth in Phase 08 Chapter 13.
• CWE (Common Weakness Enumeration) — the class of mistake, independent of any one product or language: CWE-89 SQL Injection, CWE-79 XSS, CWE-502 Deserialization of Untrusted Data, CWE-416 Use After Free, CWE-22 Path Traversal, CWE-787 Out-of-bounds Write. This is the most coding-relevant MITRE taxonomy — a CWE is the bug pattern you variant-hunt for (Phase 08 Chapter 10) and the same CWE-89 describes an unsafe string-built query whether it's in a Rails find_by_sql, a Python f-string passed to cursor.execute, a Java Statement, or a Node template literal. The annual CWE Top 25 ranks the classes that actually dominate real CVEs.
• CAPEC (Common Attack Pattern Enumeration and Classification) — the attack patterns that exploit those weaknesses (e.g. "SQL injection," "session fixation") — a bridge between a CWE and how it's attacked.
• ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) — a structured matrix of real-world adversary tactics (the why: Initial Access, Persistence, Privilege Escalation, Exfiltration) and techniques (the how: "Valid Accounts," "Phishing"). It is the coverage map for detection engineering (Phase 09): you map your detections to ATT&CK techniques to see where you're blind. There are specialized matrices — ATT&CK for ICS (Phase 10) and ATLAS (adversarial threats to AI systems, Phase 11).

Also from MITRE: D3FEND (a taxonomy of defensive techniques, the mirror of ATT&CK) and MITRE acts as the CVE Program secretariat and a Top-Level Root CNA (Phase 08 Chapter 13).

Where it bites in real stacks. When a scanner flags your JVM app, it reports a CVE (the instance) mapped to a CWE (the class). When your SIEM correlates a Python-based C2 implant's behavior, it tags ATT&CK techniques. Reasoning at the CWE/ATT&CK level (the class and the behavior) instead of the CVE/IOC level (the instance and the indicator) is exactly the "pyramid of pain" lesson — it's what makes your fixes and detections survive the attacker changing one byte.

Misconception to kill now. "CVE, CWE, and ATT&CK are kind of the same thing." They sit at different altitudes: CWE is the weakness class (in your code), CVE is one instance of it (in a specific product), CAPEC/ATT&CK are how attackers exploit and operate. Mixing them up is mixing up "the bug," "the bug here," and "the attack."

Chapter 5: FIRST — Scoring and Sharing Vulnerabilities

What it is. FIRST (the Forum of Incident Response and Security Teams) is the global association of incident-response and security teams. Its lasting contribution is the scoring systems the industry uses to prioritize — turning "is this bad?" into comparable numbers.

The deliverables:

• CVSS (Common Vulnerability Scoring System) — a 0.0–10.0 severity score derived from a vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8). It measures worst-case severity if exploited, not risk to you. Read the vector, re-derive the Environmental score for your deployment. Depth in Phase 08 Chapter 13.
• EPSS (Exploit Prediction Scoring System) — a daily probability (0–1) that a CVE will be exploited in the wild in the next 30 days. The likelihood axis CVSS lacks.
• TLP (Traffic Light Protocol) — a simple labeling scheme (RED/AMBER/GREEN/CLEAR) for how widely shared information may be redistributed. You'll see TLP markings on threat intel and advisories — it governs sharing, not severity.

Where it bites. CVSS/EPSS are what sort your dependency-upgrade queue when an SCA tool (OWASP Dependency-Check, Trivy, bundler-audit for Rails, pip-audit for Python, npm audit for Node) dumps 10,000 findings on you. The staff move (Phase 03/08): rank by CVSS × EPSS × KEV × reachability-in-your-code, not by raw CVSS.

Misconception to kill now. "CVSS tells me what to patch first." Severity is one input; FIRST also publishes EPSS precisely because severity ≠ likelihood. Pair them with CISA KEV (confirmed exploitation) and your own reachability analysis.

Chapter 6: CIS — Hardening Benchmarks and Controls

What it is. The Center for Internet Security (CIS) is a nonprofit that publishes two famous things: the CIS Controls (a prioritized catalog of ~18 safeguards — "what an org should do," a leaner alternative to 800-53) and, more relevant to engineers, the CIS Benchmarks — consensus, configuration-level hardening guides for specific technologies.

Why the Benchmarks matter to you. A CIS Benchmark is a long, specific checklist of settings for one platform — "disable root SSH login," "set kernel.randomize_va_space=2," "ensure the API server --anonymous-auth=false." There are Benchmarks for Ubuntu/RHEL, Docker, Kubernetes, AWS/GCP/Azure, PostgreSQL/MySQL, nginx, and the JVM, among many others. They are the concrete, testable definition of "hardened" that Phase 05/06/07 reference.

Where it bites in real stacks. The CIS Docker Benchmark tells you to run as non-root, drop capabilities, and use a read-only root filesystem — exactly the Phase 06 sandbox composition; the CIS Kubernetes Benchmark drives Pod Security and admission policy (Phase 07); the CIS AWS Benchmark flags public S3 buckets and over-broad IAM. Tools like kube-bench, Docker Bench, and cloud CSPM scanners automate "does this system match the Benchmark." A hardened distroless or minimal base image is the CIS Benchmark applied to your container.

The critical caveat (a Phase 05 flagged mistake). Apply Benchmarks with workload context — a blanket CIS setting can break a legitimate service. The skill is hardening and proving the service still works (rollback + availability tests), not pasting the whole Benchmark.

Misconception to kill now. "Apply the CIS Benchmark and we're hardened." A Benchmark is a strong default, not a context-free law — some settings will break your workload, and a green benchmark score still says nothing about your application logic or authorization. Harden deliberately, test, and keep the exceptions documented.

Chapter 7: ISO/IEC — International Management Standards

What it is. ISO (the International Organization for Standardization), jointly with IEC for electrotechnical topics, publishes globally-recognized standards across every industry. In security the headline is the ISO/IEC 27000 family, centered on building and certifying an information security management system.

The deliverables:

• ISO/IEC 27001 — the certifiable standard for an ISMS (Information Security Management System): a process framework for governing security risk (scope, risk assessment, controls, continual improvement). An accredited auditor certifies you against it — the international enterprise-trust bar, comparable to SOC 2 in the US market (Phase 07/15).
• ISO/IEC 27002 — the companion catalog of controls (the implementation guidance for 27001's Annex A).
• ISO/IEC 27017 / 27018 — cloud-security and cloud-privacy (PII) control sets.
• ISO/IEC 29147 (Vulnerability Disclosure) and 30111 (Vulnerability Handling) — the process standards behind coordinated disclosure (Phase 00/08): how an organization should receive and handle externally-reported vulnerabilities.

Where it bites. ISO is less about a line of code and more about the program around your code — but 29147/30111 directly shape how you run a security.txt / VRP intake, and 27001 certification is often the contractual gate that determines whether your Rails/Java/cloud SaaS can sell to a large enterprise at all.

Misconception to kill now. "ISO 27001 means the product is secure." 27001 certifies that a management system for handling risk exists and operates — it's about process maturity, not a guarantee that any given service is bug-free. It's necessary trust infrastructure, not a security proof.

Chapter 8: Cloud and Supply-Chain Bodies — CSA, OpenSSF, CISA, PCI

A cluster of bodies own the cloud and supply-chain surfaces that dominate modern risk:

• CSA (Cloud Security Alliance) — a nonprofit focused on cloud. Its Cloud Controls Matrix (CCM) is a cloud-specific catalog of controls with a crosswalk mapping each control to ISO/NIST/PCI; the CAIQ is the questionnaire vendors fill out; STAR is its assurance registry. Use the CCM when you need "the cloud control set, already mapped to every other regime" (Phase 07).
• OpenSSF (Open Source Security Foundation) — a Linux Foundation body securing the open-source supply chain. It stewards SLSA (Supply-chain Levels for Software Artifacts — build-integrity levels), Sigstore (keyless signing: Fulcio + Rekor), and the Scorecard (automated checks of a repo's security posture). This is the spine of Phase 14. In code: cosign verify on your container, a SLSA provenance attestation from your GitHub Actions build, Scorecard scanning your Python/Node/Java repo's branch protection and pinned dependencies.
• CISA (Cybersecurity and Infrastructure Security Agency) — the US operational cyber-defense agency (distinct from NIST, which writes standards; CISA acts). It runs the KEV (Known Exploited Vulnerabilities) catalog (confirmed in-the-wild exploitation — your strongest "patch now" signal, Phase 08), the Vulnrichment ADP filling NVD's gaps, ICS advisories (Phase 10), and the Secure by Design initiative pushing vendors to ship safe defaults.
• PCI SSC (Payment Card Industry Security Standards Council) — the card-brand consortium behind PCI DSS, the prescriptive control set for any system touching cardholder data. Unlike most others it is contractually mandatory (not law) if you process cards, and scope minimization (shrinking the cardholder-data environment) is the central engineering game (Phase 15).

Misconception to kill now. "These overlap, so I only need one." They own different surfaces — CSA the cloud config, OpenSSF the build/dependency chain, CISA the live-exploitation signal, PCI the payment boundary. A real program draws on all four, and CSA's CCM crosswalk is how you avoid doing the overlapping parts N times (Chapter 11).

Chapter 9: IETF — The Network and Protocol Standards (RFCs)

What it is. The IETF (Internet Engineering Task Force) is the open body that standardizes the protocols of the internet itself, published as RFCs (Requests for Comments) — numbered documents that are the authoritative definition of how a protocol works. This is the network layer the user asked about: every secure connection your code makes is governed by an RFC, and security bugs are often a disagreement with what the RFC actually says.

The security-critical RFCs you'll meet (Phase 02):

• TLS 1.3 — RFC 8446. The protocol securing your connections (HTTPS, database TLS, service mesh). In code: this is what your nginx/Puma (Rails) terminator negotiates, what Java's JSSE and Python's ssl module implement, what an https.Agent in Node speaks.
• X.509 PKI — RFC 5280. Certificate structure and chain validation (the CA/SNI/revocation logic of Phase 02 Chapter 4).
• HTTP — RFC 9110/9112 (1.1), 9113 (HTTP/2), 9114 (HTTP/3), and QUIC RFC 9000. The request/ response semantics and framing where request smuggling lives (a disagreement between two hops about message boundaries — Phase 02 lab-06).
• OAuth 2.0 — RFC 6749, PKCE — RFC 7636, Security BCP — RFC 9700; OpenID Connect (an OIDF spec layered on OAuth). The delegated-authorization flows of Phase 02 Chapter 7. In code: OmniAuth/ Doorkeeper in Rails, Spring Security OAuth in Java, authlib/requests-oauthlib in Python.
• JWT — RFC 7519, with JWS/JWA — RFC 7515/7518. The signed-token format whose validation as a protocol (pin the alg, check iss/aud/exp) is Phase 02 Chapter 8. In code: the jwt gem (Rails), PyJWT (Python), jjwt/Nimbus (Java), jsonwebtoken (Node) — and the classic bug (alg: none, RS256→HMAC confusion) is a failure to follow the RFC's verification requirements.
• Cookies — RFC 6265bis. Secure/HttpOnly/SameSite semantics (the CSRF/ambient-authority discussion of Phase 02 Chapter 6).

Why this is the network tie-in. Many web vulnerabilities are precisely a parser differential — your front-end proxy and your Rails/Java backend interpreting the same bytes against the RFC differently (Phase 01 Chapter 6, Phase 02 Chapter 3). Reading the RFC is how you settle "what should this actually do," which is the whole game in protocol security.

Misconception to kill now. "RFCs are for protocol implementers, not app developers." If your code issues an HTTP request, validates a TLS cert, or parses a JWT, you are relying on an RFC — and the bug is usually where your library (or your usage of it) diverges from what the RFC requires.

Chapter 10: Cloud-Provider Security Frameworks

Beyond the neutral bodies, each major cloud publishes its own opinionated security framework for its platform — prescriptive, product-specific, and directly actionable (Phase 07/12):

• AWS Well-Architected Framework — Security Pillar. AWS's design principles and review questions (identity foundation, traceability, least privilege, data protection). The AWS-native expression of identity-is-the-perimeter.
• Google SAIF (Secure AI Framework) and BeyondCorp (the original zero-trust architecture — access by device/identity attestation, not network location; Phase 13 attestation underpins it).
• Microsoft Cloud Adoption Framework / Azure security baselines and Microsoft STRIDE (the threat-modeling taxonomy of Phase 03 — Spoofing/Tampering/Repudiation/Information disclosure/Denial of service/Elevation of privilege).
• Google Cloud security foundations / Architecture Framework — GCP's equivalent landing-zone guidance.

Where it bites. These tell you the right way to wire identity, network, and data in a specific provider — the AWS Security Pillar is what a "secure landing zone" lab (Phase 07) implements: org-level guardrails (SCPs), federated identity, no long-lived keys, centralized logging. They're the bridge between the neutral standards above and the actual buttons in your cloud console / Terraform.

Misconception to kill now. "Provider frameworks replace the neutral standards." They're the provider-specific implementation of the same principles — you still map them back to NIST/CIS/ISO for cross-provider portability and audits (Chapter 11). A multi-cloud shop standardizes on the neutral control set and uses each provider's framework to realize it.

Chapter 11: Putting It Together — Crosswalks, Not Cargo-Culting

The single most important skill: one control, many frameworks. The frameworks overlap enormously on purpose. "Encrypt data in transit, enforced and tested" simultaneously satisfies a NIST 800-53 SC-8, an OWASP ASVS communications requirement, a PCI DSS requirement, an ISO 27002 control, a SOC 2 criterion, and an IETF TLS 1.3 implementation. A mature program implements the control once and keeps a crosswalk — a mapping of "which control satisfies which requirement in which framework" — so one engineered, tested, evidenced control serves every audit at once (Phase 15 Chapter 8). CSA's CCM and NIST's own mappings publish these crosswalks; you extend them for your stack.

The engineering pipeline, framework by framework. Across this track the frameworks compose into a single flow:

THREAT MODEL          → STRIDE (Microsoft) + MITRE CWE/CAPEC + abuse cases   [Phase 03]
BUILD SECURELY        → OWASP ASVS as tests + NIST SSDF process in CI         [Phase 03]
KNOW THE WEAKNESSES   → MITRE CWE/ATT&CK as scanner & detection targets       [Phase 08/09]
HARDEN THE PLATFORM   → CIS Benchmarks + NIST 800-190/207                     [Phase 05/06/07]
SECURE THE PROTOCOLS  → IETF RFCs (TLS/OAuth/JWT/HTTP)                        [Phase 02]
SCORE & PRIORITIZE    → FIRST CVSS/EPSS + CISA KEV + reachability             [Phase 08]
SECURE THE SUPPLY CHAIN → OpenSSF SLSA/Sigstore/Scorecard                     [Phase 14]
AUTHORIZE & CERTIFY   → NIST RMF/800-53 (FedRAMP), ISO 27001, PCI, SOC 2      [Phase 15]
DISCLOSE              → ISO 29147/30111 + a VRP                               [Phase 00/08]

The reading discipline, restated. Sort any new document into the four kinds (Chapter 1), map it to your system, implement a real control, and evidence that it operates with fresh data. The failure in every phase is the same: treating the framework as the deliverable instead of the prompt — a green CIS score, a filled-in STRIDE table, a high CVSS, an SBOM nobody queries. Frameworks are leverage; the work is still yours.

Misconception to kill now. "More frameworks = more security." A pile of overlapping checklists applied without judgment produces noise, friction, and false confidence. The staff skill is one well-engineered control library with a crosswalk — the minimum set of real controls that satisfies the maximum set of requirements, each tested and evidenced.

Chapter 12: Threat-Intelligence Frameworks — Kill Chain, Diamond, and the Intel Lifecycle

ATT&CK (Chapter 4) is the famous threat model, but it is one of three that a detection engineer, threat hunter, or incident responder uses together — and there's a whole machinery for sharing intelligence. This chapter completes the picture; the Offensive Methodology Mastery module builds the runnable engines for it.

The three threat models (they compose; they don't compete).

• Cyber Kill Chain (Lockheed Martin) — the linear campaign lens: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control → Actions on Objectives. Its value is earliness — detect and break the chain as far left as possible, where defense is cheapest. It answers "how far along is this intrusion?"
• Diamond Model (Caltagirone et al.) — the relational lens: every event has four vertices — Adversary, Capability, Infrastructure, Victim — and you pivot from a known vertex (a C2 domain, a malware sample) to discover related events. It answers "what else is connected — same actor, same campaign?" and is the analytic core of attribution.
• MITRE ATT&CK — the behavioral taxonomy lens (Chapter 4): tactic → technique, the shared vocabulary and detection-coverage map. It answers "what behavior is this, and can we detect it?"

Use the Kill Chain to phase an intrusion, ATT&CK to label and detect its techniques, and the Diamond Model to scope and attribute the campaign.

The intelligence lifecycle (the process, a fourth "kind" of framework). Producing usable threat intel is a cycle: Direction (what do we need to know?) → Collection (feeds, telemetry, OSINT) → Processing (normalize, deduplicate) → Analysis (the three models above; the Pyramid of Pain — prioritize TTP-level intel over trivially-changed hashes/IPs) → Dissemination (to detection, IR, leadership) → Feedback. Intel that doesn't change a detection or a decision is trivia, the same "artifact ≠ outcome" lesson as the rest of this module.

The sharing standards (how intel moves between organizations).

• STIX (Structured Threat Information eXpression) — a JSON schema for representing threat intel as objects (indicators, malware, threat-actors, attack-patterns, campaigns) and relationships — a machine-readable Diamond/ATT&CK graph.
• TAXII — the transport protocol for exchanging STIX (publish/subscribe to threat feeds).
• MISP — the widely used open-source threat-intel sharing platform (communities, feeds, correlation).
• TLP (Traffic Light Protocol) — the handling/sharing labels (Chapter 5) that govern how widely a piece of intel may be redistributed.

Misconception to kill now. "ATT&CK is the threat model." ATT&CK is the technique taxonomy; the Kill Chain is the campaign sequence and the Diamond Model is the relationship graph. Real analysis moves fluidly among all three, and the intel lifecycle plus STIX/TAXII/MISP are how that analysis is produced and shared.

How This Maps to the Phases

Lab Walkthrough Guidance

Five labs turn the four kinds of framework into runnable engines — the point is to implement the standards, not memorize them. Build order:

1. Lab 01 — Vulnerability Triage Engine (CVSS / EPSS / KEV). Implement the actual CVSS v3.1 base-score formula (parse the vector, compute the Impact/Exploitability sub-scores, apply the Scope rule and the official Roundup), then combine severity with EPSS probability, CISA KEV membership, and reachability into a defensible, ordered patch queue. This is the scoring kind (Chapters 4–5, 8). The lesson in code: severity ≠ risk — a KEV-listed, reachable, internet-facing Medium must outrank an unreachable 9.8.
2. Lab 02 — Control Crosswalk & Coverage Engine. Model one engineered control that satisfies many framework requirements (NIST 800-53, OWASP ASVS, ISO 27002, PCI DSS, CIS), validate the crosswalk (requirements with no control = gaps; controls claiming unknown requirements = dangling; mapped-but-unimplemented/stale = unsubstantiated), and compute per-framework coverage plus the highest-leverage controls. This is the catalog/process kind (Chapters 2, 3, 6, 7, 11). The lesson: implement once, satisfy many — the crosswalk is the staff skill.
3. Lab 03 — Weakness Taxonomy Mapper (CWE / CAPEC / ATT&CK). Normalize a pile of raw scanner findings to CWE classes (dedup by class, not instance), enrich each with CAPEC patterns, ATT&CK techniques, the OWASP category, and CWE-Top-25 membership, then compute ATT&CK detection coverage gaps. This is the taxonomy kind (Chapter 4). The lesson: report weakness classes and behaviors, not raw findings — the same altitude shift as the pyramid of pain.
4. Lab 04 — STIX Threat-Intel Bundle. Represent intel as typed STIX objects + relationships, validate the bundle (dangling refs, duplicate ids, type-prefix), and pivot a campaign graph (indicator → malware → campaign → threat-actor) — the sharing layer (Chapter 12).
5. Lab 05 — SSVC + CVSS v4. Implement the SSVC decision tree (Exploitation/Automatable/Technical- Impact/Mission → Track/Track*/Attend/Act) with a monotonicity guarantee, plus a CVSS v4.0 vector parser — the modern, context-first replacement for prioritizing by a raw CVSS number (Chapters 5, 12).

Run each lab against your implementation and the reference:

LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation, after completing the TODOs

Success Criteria

You have internalized this module when you can, without notes:

1. Sort any security framework into one of the four kinds (catalog / taxonomy / scoring / process) and say how you'd use it.
2. Explain what OWASP, NIST, MITRE, FIRST, CIS, ISO, the IETF, CSA/OpenSSF/CISA/PCI, and the cloud-provider frameworks each are and own.
3. Trace one concrete control (e.g. "encrypt data in transit") from an IETF RFC up through OWASP ASVS, NIST 800-53 SC-8, PCI DSS, ISO 27002, and a SOC 2 criterion — one implementation, many requirements.
4. Compute a CVSS base score from its vector and explain why CVSS × EPSS × KEV × reachability beats raw CVSS for prioritization.
5. Map a finding CVE → CWE → CAPEC → ATT&CK and say what each altitude is for.
6. Name the framework(s) that power each phase of this track (the mapping table above).
7. Read a new framework as a prompt to implement and evidence real controls — not a checklist to cargo-cult.

Common Mistakes

• Treating a framework as the deliverable (a green CIS score, a filled-in STRIDE table, an unqueried SBOM) instead of as a prompt to build and evidence real controls.
• Confusing the four altitudes — CVE (one instance) vs CWE (the weakness class) vs CAPEC/ATT&CK (the attack pattern / adversary behavior).
• Prioritizing by CVSS base score alone — severity is not risk; pair it with EPSS, KEV, and reachability-in-your-code.
• Re-implementing the same control N times for N frameworks instead of building it once and keeping a crosswalk.
• Citing the OWASP Top 10 as a completeness checklist — it is an awareness taxonomy; ASVS is the verification standard.
• Applying a CIS Benchmark without workload context and silently breaking the service.
• Assuming an ISO 27001 / SOC 2 certificate, or a provider's "FedRAMP-authorized" status, proves your system is secure (it proves a process exists / proves the provider's layer).

Interview Q&A

Q: What's the difference between OWASP, NIST, and MITRE? A: OWASP is the builder's community — practical, free app-sec for developers (Top 10, ASVS, Cheat Sheets, ZAP). NIST is the US government's standards engine — control catalogs (800-53), mandatory crypto (FIPS 140-3), and process frameworks (CSF, RMF, SSDF). MITRE owns the field's taxonomies — CVE (instances), CWE (weakness classes), CAPEC (attack patterns), ATT&CK (adversary behavior). Builder guidance vs. control standards vs. shared vocabularies — different layers, used together.

Q: Explain "one control, many frameworks." A: Frameworks overlap by design. A single engineered control — "TLS 1.2+ enforced and tested on every endpoint" — satisfies a NIST 800-53 SC-8, an OWASP ASVS communications requirement, a PCI DSS requirement, an ISO 27002 control, and a SOC 2 criterion at once. You implement and evidence it once and keep a crosswalk mapping it to each framework's requirement id, so one piece of work serves every audit. That's the difference between a 9-month FedRAMP and a 3-year scramble — and it's exactly what Lab 02 builds.

Q: A scanner dumps 10,000 findings. How do the frameworks help you prioritize? A: Not by CVSS alone. CVSS (FIRST) gives severity if exploited; I add EPSS (FIRST — probability of exploitation) and CISA KEV (confirmed in-the-wild) for likelihood/reality, and reachability in my own code (is the vulnerable function even called, across a trust boundary?). I rank by CVSS × EPSS × KEV × reachability and fix the reachable-and-actively-exploited few first — a KEV-listed, reachable Medium beats an unreachable 9.8. That ranking engine is Lab 01.

Q: CVE vs CWE vs ATT&CK — when do you use each? A: CVE names one vulnerability instance in a specific product (CVE-2021-44228). CWE names the weakness class in code (CWE-502 deserialization) — what I variant-hunt for and what's language-agnostic across Rails/Java/Python. ATT&CK names adversary behavior (techniques like "Valid Accounts") — what I build detections against. I reason at the CWE/ATT&CK altitude (class and behavior) rather than CVE/IOC (instance and indicator) so my fixes and detections survive the attacker changing one byte. Lab 03 does this translation.

Q: Is the OWASP Top 10 a security checklist? A: No — it's a data-driven awareness taxonomy of the most common web-app risk categories, meant to focus attention. The actual verification standard, the one you turn into pass/fail tests, is OWASP ASVS (with levels L1–L3). Treating the Top 10 as "complete the list and we're secure" is the classic misuse — it's where you start, not where you stop.

References

Application security (builders)

• OWASP: the Top 10, API Security Top 10, ASVS, MASVS/MASTG, Top 10 for LLM Applications, the Cheat Sheet Series, SAMM; tools ZAP, Dependency-Check/Track.

Government standards and process

• NIST: SP 800-53 (controls), 800-37 (RMF), 800-63 (digital identity), 800-61/86 (IR/forensics), 800-190/207 (containers/zero trust), 800-218 (SSDF), 800-161 (supply chain); FIPS 199, 140-3, 197/186/180/202, 203–205 (post-quantum); the Cybersecurity Framework (CSF) and AI RMF; the NVD.
• ISO/IEC 27001/27002 (ISMS + controls), 27017/27018 (cloud), 29147/30111 (vuln disclosure/handling).

Taxonomies, scoring, and intelligence

• MITRE: CVE, CWE (+ CWE Top 25), CAPEC, ATT&CK (+ ICS, ATLAS), D3FEND.
• FIRST: CVSS v3.1/v4.0, EPSS, the Traffic Light Protocol.
• CISA: KEV catalog, Vulnrichment, Secure by Design, ICS advisories.

Hardening, cloud, and supply chain

• CIS: Controls v8 and the Benchmarks (OS, Docker, Kubernetes, cloud, databases); kube-bench.
• CSA: Cloud Controls Matrix (CCM), CAIQ, STAR.
• OpenSSF: SLSA, Sigstore (Fulcio/Rekor), Scorecard; PCI SSC: PCI DSS v4.0.
• Cloud-provider: AWS Well-Architected Security Pillar; Google SAIF/BeyondCorp; Microsoft CAF/STRIDE.

Protocols (the network layer)

• IETF RFCs: 8446 (TLS 1.3), 5280 (X.509), 9110/9112/9113/9114 + 9000 (HTTP/QUIC), 6749/7636/9700 (OAuth/PKCE/BCP), 7519/7515/7518 (JWT/JWS/JWA), 6265bis (cookies); OpenID Connect Core (OIDF).

Lab 01 — Vulnerability Triage Engine (CVSS / EPSS / KEV)

Frameworks: FIRST CVSS v3.1, FIRST EPSS, CISA KEV, SSVC-style decision. Kind: scoring system. Builds toward: Phase 08 Chapter 13.

The problem (and the threat model)

A scanner produces thousands of findings; the dangerous move is to sort them by CVSS base score and "patch criticals first." CVSS base score measures worst-case severity if exploited — it knows nothing about whether anyone is exploiting the bug, or whether the vulnerable code is even reachable in your deployment. The "attacker" in this lab is misprioritization: the team burns its remediation budget on a 9.8 nobody exploits and that you don't expose, while a KEV-listed, internet-facing, reachable Medium — the one actually being used against your peers — sits in the backlog. The control is a triage engine that scores risk on four axes, not one.

finding ─► CVSS base score (severity)  ─┐
        ─► EPSS probability (likelihood) ─┤
        ─► CISA KEV (confirmed exploited)─┼─► deterministic decision ─► ordered queue
        ─► reachability + exposure (you)  ─┘     act-now / scheduled / track / defer

What you build (lab.py)

• parse_cvss_vector(vector) — parse and validate a CVSS v3.0/3.1 base vector (reject wrong prefix, missing metric, invalid value).
• roundup(value) — the official CVSS v3.1 Roundup (a float-safe one-decimal ceiling — 5.43 → 5.5).
• cvss_base_score(vector) — the real formula: ISS → Impact (with the Scope rule) → Exploitability → Base. Validated against the canonical vectors (…C:H/I:H/A:H = 9.8; Scope-Changed = 10.0).
• severity_band(score) — None / Low / Medium / High / Critical.
• triage(findings) — combine severity with EPSS, KEV, and reachability into a deterministic, highest-risk-first ordered queue, each with an action and a rationale.

The decision policy (deterministic, defensible)

This is a small SSVC (Stakeholder-Specific Vulnerability Categorization) tree: the framework's point is to make the contextual questions explicit instead of hiding behind a single number.

Attack / failure cases the tests cover

• Severity ≠ risk: a KEV-listed reachable Medium outranks an unreachable Critical 9.8.
• Unreachable always defers even at EPSS 0.99 + KEV (you can't be exploited through code you don't run).
• CVSS formula correctness against canonical FIRST vectors, including the Scope-Changed branch and the Roundup ceiling.
• Vector validation: wrong prefix, missing metric, invalid value → ValueError.
• Determinism: identical input yields identical order across runs (stable tiebreak by CVE).

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Hardening / extensions

• Add CVSS v4.0 (new metric groups: Attack Requirements, the Threat and Supplemental groups).
• Replace the threshold policy with the full SSVC decision tree (Exploitation / Automatable / Technical Impact / Mission & Well-being) and emit the Act/Attend/Track/Track* decision.
• Pull EPSS and KEV from their published feeds (offline snapshot) and add freshness checks.
• Add reachability evidence (an SCA call-graph result) as a first-class input rather than a bool.

Interview / resume

"Built a vulnerability triage engine implementing the FIRST CVSS v3.1 base-score algorithm and an SSVC-style decision that prioritizes by CVSS × EPSS × KEV × reachability — demonstrating that severity is not risk and that an unreachable 9.8 must wait behind a KEV-listed, reachable Medium."

Limitations: base-metric CVSS only (no Temporal/Environmental re-scoring beyond the reachability gate); EPSS/KEV/reachability are supplied as inputs; the policy thresholds are a defensible default, not an organization-specific risk appetite.

Lab 02 — Control Crosswalk & Coverage Engine

Frameworks: NIST 800-53, OWASP ASVS, ISO 27002, PCI DSS, SOC 2. Kind: catalog of controls + process. Builds toward: Phase 15, Phase 07.

The problem (and the threat model)

The naive compliance program runs N separate efforts for N frameworks — re-documenting "we encrypt data in transit" five times, five ways, for five auditors. That is how a company spends three years on what should take nine months. The "threat" here is wasted, un-leveraged effort and un-evidenced claims: a control marked "done" in a spreadsheet with no fresh evidence behind it, or a requirement everyone assumed some other control covered. The control is a crosswalk engine: engineer each control once, map it to the requirement it satisfies in every framework, and prove — mechanically — that every required item has a substantiated control behind it.

one control ("TLS 1.2+ enforced & tested")
   ├─ NIST:SC-8        (FedRAMP)
   ├─ PCI:4.2.1        (PCI DSS)
   ├─ ISO:8.24         (ISO 27002)
   ├─ ASVS:9.1.1       (OWASP ASVS)
   └─ SOC2:CC6.7       (SOC 2)        → implement once, satisfy five

A control only counts when it is implemented, has evidence, and that evidence is fresh (an implemented control with stale or missing evidence is an assertion, not a control — the ConMon lesson from Phase 07/15).

What you build (lab.py)

• is_substantiated(control) — implemented and evidenced and fresh.
• validate_crosswalk(controls) — sorted findings of three kinds:
  • gap:{framework}:{req} — a required item no control even maps to;
  • unsubstantiated:{framework}:{req} — mapped, but no substantiated control behind it;
  • dangling-claim:{control}:{req} — a control claims a requirement no framework demands (a typo / stale mapping).
• coverage(controls) — per framework: {required, satisfied, gaps}.
• leverage(controls) — rank substantiated controls by how many real requirements each satisfies (the "one control, many frameworks" metric — where to invest).
• is_ready(framework, controls) — zero gaps for that framework.

Attack / failure cases the tests cover

• One control, many frameworks: a clean five-control library fully covers all five frameworks; the three highest-leverage controls each satisfy 5 requirements.
• Gap: a requirement with no mapped control fails coverage and readiness.
• Unsubstantiated: a mapped control with no evidence or stale evidence (> 365 days) does not satisfy its requirements — it becomes a coverage gap, not a free pass.
• Dangling claim: a control claiming a requirement no framework demands is flagged.
• Determinism: findings are sorted and stable.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Import a real OSCAL catalog/profile and emit OSCAL assessment-results (Phase 15).
• Add partial satisfaction (a requirement needing two controls) and weighted coverage.
• Pull the crosswalk from CSA's Cloud Controls Matrix mappings instead of a hand-built table.
• Add an exception path (owner + expiry) so a gap can be accepted with a tracked POA&M (Phase 15).

Interview / resume

"Built a multi-framework control-crosswalk engine that maps one engineered, evidenced control to its requirement in NIST 800-53, PCI DSS, ISO 27002, OWASP ASVS, and SOC 2 — computing coverage, flagging unsubstantiated and dangling mappings, and ranking controls by cross-framework leverage. The point: implement once, satisfy many; an un-evidenced control is a gap, not a checkbox."

Limitations: a representative requirement slice, not the full catalogs; one-to-one control→requirement satisfaction (no partial/composite controls); freshness is a single global window.

Lab 03 — Weakness Taxonomy Mapper (CWE / CAPEC / ATT&CK)

Frameworks: MITRE CWE, CAPEC, ATT&CK, CWE Top 25, OWASP categories. Kind: taxonomy. Builds toward: Phase 08 (variants), Phase 09 (ATT&CK coverage).

The problem (and the threat model)

A scanner hands you thousands of instances with tool-specific labels ("SQLi in /login (sqlmap)," "tainted query in OrdersController"). Reasoning at that altitude is hopeless and brittle — it's the "searching only for known indicators" failure. The "threat" is drowning in instances and missing the class: ten findings that are all one CWE-89 SQL-injection class, and a whole ATT&CK technique you have no detection for. The control is a taxonomy mapper: normalize raw findings to MITRE CWE classes, enrich each with its CAPEC attack pattern, ATT&CK technique, OWASP category, and CWE Top 25 rank, then diff the implicated ATT&CK techniques against your detections to find coverage gaps.

raw finding ─► CWE class (the weakness, language-agnostic)
                 ├─ CAPEC  (the attack pattern)
                 ├─ ATT&CK (the adversary technique → what a detection targets)
                 ├─ OWASP  (the web risk category)
                 └─ Top 25 (how dangerous the class is)

The same CWE-89 describes a Rails find_by_sql, a Python f-string in cursor.execute, a Java Statement, and a Node template literal — which is exactly why the class is the useful unit.

What you build (lab.py)

• normalize(findings) — collapse raw findings to {cwe: instance_count} (dedup by class).
• enrich(cwe) — the CAPEC / ATT&CK / OWASP / Top-25 context for a class, with an in_top25 flag (UNKNOWN for unmapped CWEs).
• class_priority(findings) — rank classes by prevalence, then Top-25 danger, then id.
• attack_coverage(findings, detections) — {implicated, covered, gaps} ATT&CK techniques: the detection-engineering view (Phase 09's pyramid of pain — invest at the technique level).

Attack / failure cases the tests cover

• Dedup by class: three SQLi instances collapse to one CWE-89 with count 3.
• Enrichment: known class → CAPEC/ATT&CK/OWASP/Top-25; unknown CWE → UNKNOWN, in_top25=False.
• Prioritization: ranked by instance count, then Top-25 rank (a count-1 CWE-787 rank-1 outranks a count-1 CWE-502 rank-16), unranked classes last.
• Coverage gap: an implicated ATT&CK technique with no detection is reported as a gap.
• Unmapped CWE implicates no technique (no phantom coverage).
• Determinism: stable, sorted outputs.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Load the real CWE→ATT&CK mappings from MITRE / the Center for Threat-Informed Defense (CTID), rather than the small teaching table here.
• Add CWE abstraction relationships (Pillar → Class → Base → Variant) so a Variant rolls up to its Base class for variant analysis (Phase 08 Chapter 10).
• Join with Lab 01: enrich each finding with its CVE/CVSS/EPSS/KEV and produce a single class-and-risk-ranked remediation plan.
• Emit an ATT&CK Navigator layer JSON for the coverage gaps (Phase 09).

Interview / resume

"Built a weakness-taxonomy mapper that normalizes noisy scanner output to MITRE CWE classes and maps each to its CAPEC pattern, ATT&CK technique, OWASP category, and CWE Top 25 rank — then computes ATT&CK detection-coverage gaps. The point: reason about weakness classes and adversary behaviors, not instances and indicators, so fixes and detections survive the attacker changing one byte."

Limitations: a representative taxonomy slice with defensible (not authoritative) CWE→ATT&CK assignments; single-technique-per-class; no CWE abstraction hierarchy.

Standards Lab 04 — STIX-style Threat-Intel Bundle

Frameworks: STIX / TAXII (Standards WARMUP Chapter 12). Kind: taxonomy / sharing.

The idea

Threat intelligence is shared as a machine-readable graph: typed STIX objects (indicator, malware, threat-actor, attack-pattern, campaign, infrastructure) joined by relationships (indicates, uses, attributed-to, communicates-with), exchanged over TAXII. It's the Diamond Model (Lab in the Offensive module) and ATT&CK made interoperable. This lab validates a bundle and performs the analyst's core move — pivoting from one object to related ones and tracing a path from an indicator up to a threat actor.

What you build (lab.py)

• validate_bundle(bundle) — dangling relationship refs, duplicate ids, STIX <type>-- prefix mismatches.
• find_by_type(bundle, type) — objects of a type.
• related(bundle, id) — directly connected objects (the pivot).
• pivot_path(bundle, source, target) — shortest relationship path (e.g. indicator → malware → campaign → threat-actor).

Cases the tests cover

• A well-formed bundle validates clean; a dangling ref, duplicate id, and type-prefix mismatch are caught; find_by_type and related return the right neighbors; pivot_path traces the indicator-to-actor chain; same-node and unconnected cases handled.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Parse real STIX 2.1 JSON bundles and emit grouping/relationship objects.
• Add a TAXII-style publish/subscribe feed model with collection filtering.
• Weight pivots by confidence and add time windows (infrastructure reuse only within active periods).

Interview / resume

"Built a STIX-style intel bundle engine — typed objects + relationships — with validation and graph pivoting (indicator→malware→campaign→threat-actor), the machine-readable form of the Diamond Model shared over TAXII."

Limitations: a representative object/relationship subset (not full STIX 2.1); undirected pivot traversal; no confidence/time weighting.

Standards Lab 05 — SSVC Decision Engine + CVSS v4 Vector Parser

Frameworks: SSVC (CISA/CMU SEI), CVSS v4.0 (FIRST). Kind: scoring / process. Extends: Lab 01.

The idea

CVSS gives severity; SSVC (Stakeholder-Specific Vulnerability Categorization) gives a decision by walking a tree over Exploitation / Automatable / Technical Impact / Mission & Well-being to Track / Track* / Attend / Act — the defensible replacement for "patch everything above CVSS 7." This lab implements that decision tree and parses/validates a CVSS v4.0 vector (its new metric groups — Attack Requirements, vulnerable vs subsequent system impacts).

What you build (lab.py)

• ssvc_decision(exploitation, automatable, technical_impact, mission_wellbeing) → outcome; input validation; a monotone tree (raising any axis never lowers urgency).
• outcome_rank(outcome) → 0..3 urgency.
• parse_cvss4_vector(vector) → validated {metric: value} for the 11 v4 base metrics.
• severity_band(score) → None/Low/Medium/High/Critical.

Cases the tests cover

• SSVC anchors (all-minimal → Track, all-maximal → Act); active exploitation escalates; invalid input raises; monotonicity across the entire input space (raising any axis never decreases urgency).
• CVSS v4 vector parsing: valid vector, wrong prefix, missing metric (SA), invalid value; severity banding.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Encode the exact published CISA SSVC deployer/coordinator lookup tree (36 leaves) instead of the monotone scoring used here.
• Implement full CVSS v4.0 MacroVector scoring (the official table-based computation).
• Add CVSS v4 Threat (Exploit Maturity) and Environmental modifiers, and wire SSVC's Exploitation input from KEV/EPSS (Lab 01).

Interview / resume

"Built an SSVC decision engine (Exploitation/Automatable/Technical-Impact/Mission → Track/Track*/ Attend/Act) with a monotonicity guarantee, plus a CVSS v4.0 vector parser — the modern, context-first replacement for prioritizing by a raw CVSS number."

Limitations: SSVC is encoded as a documented monotone tree (not the exact CISA lookup table); CVSS v4 scoring (MacroVector) is out of scope — the lab parses/validates the vector and bands a score.

Offensive Methodology Mastery — The Adversary Playbook, for Defenders and Authorized Testers

What this is. A phase-equivalent, cross-cutting module on how attackers actually operate end to end — the unified lifecycle (reconnaissance → initial access → execution → persistence → privilege escalation → lateral movement → collection → command-and-control → exfiltration → impact) and the three frameworks that structure it (the Cyber Kill Chain, the Diamond Model, and MITRE ATT&CK). The rest of the track teaches you to build and defend systems; this module teaches you to think in attacks across the whole campaign, which is what a penetration tester, red-teamer, threat hunter, detection engineer, or incident responder does every day.

Why it exists (the gap it closes). The other phases cover attacker techniques locally — a memory bug here, an SSRF there, an over-permissioned IAM role elsewhere. What was missing was the connective tissue: how an attacker chains those into a campaign, and the mental models a defender uses to detect the chain early and break it. You cannot defend, hunt, or emulate an adversary you can't model end to end.

The ethical frame (read this first — it is not optional). This module is the attacker's playbook taught for defense and authorized testing, fully consistent with Phase 00:

• Everything is authorized-lab-only and reasons over synthetic metadata (event logs, network graphs, intel records) in the labs — there is no exploitation, no live targets, no payloads.
• Knowing the lifecycle is what lets you detect and disrupt it (every offensive concept here ends in a defensive break-the-chain lesson) and lets an authorized pentester/red-teamer emulate threats safely and report them.
• The difference between an attacker and a defender is authorization and intent, not knowledge — the same lesson as Phase 08's adversary chapter. This module gives you the knowledge under that boundary.

Prerequisites. The whole track, especially Phases 02 (web/identity), 05 (OS/AD), 07 (cloud/IAM), and 09 (IR/detection). The labs are pure Python (stdlib + pytest), offline.

Learning Objectives

By the end you can, without notes:

1. Walk the attacker lifecycle end to end and name, for each stage, the goal, common techniques, the telemetry it produces, and the control that breaks the chain there.
2. Use the three lenses correctly and know when each helps: Cyber Kill Chain (the linear campaign phases), Diamond Model (adversary / capability / infrastructure / victim, and pivoting between events), and MITRE ATT&CK (the technique matrix).
3. Reconstruct a campaign from scattered events, map each to its phase/technique, and identify the earliest disruption point.
4. Reason about lateral movement and pivoting as reachability over a host/credential graph, and find the choke points a defender should cut.
5. Correlate events with the Diamond Model to pivot from one indicator to related infrastructure and capability — the core of threat-intelligence analysis.
6. Design a safe, authorized adversary-emulation plan (scope, ATT&CK technique selection, stop conditions) and explain how purple-teaming closes detection gaps.

The three lenses (read the WARMUP for depth)

CYBER KILL CHAIN   linear campaign phases       "how far along is this intrusion?"   → break early
DIAMOND MODEL      adversary/capability/         "what else is connected to this?"    → pivot & attribute
                   infrastructure/victim
MITRE ATT&CK       tactic → technique matrix     "what behavior, and can we detect it?" → coverage

See WARMUP.md for the full from-zero treatment of the lifecycle, the three frameworks, each stage's techniques and defensive counters, and adversary emulation / purple teaming.

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), complete solution.py, adversarial test_lab.py, README.md, requirements.txt.

cd lab-01-killchain-attack-mapper
LAB_MODULE=solution pytest -q   # reference passes
pytest -q                        # your implementation after the TODOs

Deliverables

• A campaign reconstructor that orders scattered events into kill-chain phases, maps each to an ATT&CK tactic, and reports the earliest stage a control could have broken the chain.
• A pivot planner that computes which hosts an attacker reaches from a foothold given credential and network edges, and identifies the choke-point hosts/credentials a defender should cut.
• A Diamond-Model correlator that links events sharing infrastructure or capability and clusters them into campaigns — the analytic move behind threat attribution.
• The ability to explain the lifecycle and the three frameworks fluently in an interview, and to scope a safe adversary-emulation engagement.

Safety

Authorized-lab-only and entirely offline; the labs reason over synthetic event/graph/intel metadata. No exploitation, no live targets, no payloads, no persistence/stealth tooling. This module builds judgment about attacker campaigns — the staff-level skill that makes the offensive knowledge a defensive asset.

Warmup Guide — The Attacker Lifecycle from First Principles (for Defenders)

Zero-to-expert primer for the Offensive Methodology module. It builds the whole attack, end to end, the way a penetration tester, red-teamer, threat hunter, or incident responder must understand it — the lifecycle (reconnaissance → initial access → execution → persistence → privilege escalation → lateral movement → collection → command-and-control → exfiltration → impact) and the three lenses that structure it (Cyber Kill Chain, Diamond Model, MITRE ATT&CK). Every offensive concept here ends in what telemetry it produces and how a defender breaks the chain. It is taught for defense and authorized testing: authorized-lab-only, no live targets, no payloads (Phase 00). The difference between an attacker and a defender is authorization and intent — not knowledge.

Table of Contents

• Chapter 1: Why a Defender Learns the Whole Attack
• Chapter 2: The Three Lenses — Kill Chain, Diamond Model, ATT&CK
• Chapter 3: Reconnaissance and Attack-Surface Mapping
• Chapter 4: Initial Access
• Chapter 5: Execution, Persistence, and Defense Evasion
• Chapter 6: Privilege Escalation
• Chapter 7: Lateral Movement and Pivoting
• Chapter 8: Collection, Command-and-Control, and Exfiltration
• Chapter 9: Impact — Ransomware, Destruction, and Fraud
• Chapter 10: Adversary Emulation and Purple Teaming
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Why a Defender Learns the Whole Attack

Zero background. The other phases teach attacker techniques in isolation — a memory bug (P01), an SSRF (P02), an over-permissioned IAM role (P07). A real intrusion is a campaign: an attacker chains many small steps, over hours to months, from "I know nothing about this company" to "I have their data / their money / their operations." If you only understand the steps locally, you cannot answer the questions that matter on the job: how far along is this intrusion? what comes next? where is the cheapest place to stop it? what else is the same actor doing?

Why "the whole attack" is the unit of defense. Defense that fixes one technique is whack-a-mole; the attacker just picks another. Defense that understands the chain finds choke points — the few stages every campaign must pass through (initial access, privilege escalation, lateral movement, exfiltration) where one good control breaks many attack paths at once. The entire value of the frameworks in Chapter 2 is turning a pile of alerts into a campaign you can reason about and disrupt.

The professional roles this serves. A penetration tester / red-teamer executes this lifecycle (authorized, scoped) to prove risk. A threat hunter looks for it in telemetry before an alert fires. A detection engineer writes detections for its stages (P09). An incident responder reconstructs it after the fact (P09). A security architect designs controls at its choke points. All four think in the same lifecycle; this module is that shared model.

Misconception to kill now. "Learning attacks is for offensive roles only." You cannot detect, hunt, scope, or architect against a campaign you can't model end to end. Every defensive discipline runs on an internalized attacker lifecycle — that's why blue teams study ATT&CK and run purple-team exercises.

Chapter 2: The Three Lenses — Kill Chain, Diamond Model, ATT&CK

Three complementary models structure attacker behavior. They are not competitors; a mature analyst uses all three, each for what it's good at.

The Cyber Kill Chain (Lockheed Martin) — the linear campaign lens. Seven phases an intrusion-style attack passes through in order: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control → Actions on Objectives. Its value is earliness: the further left you detect and break the chain, the cheaper the defense and the less damage. It answers "how far along is this intrusion, and where do we cut it?" Its limit: it's linear and intrusion-centric — real attacks loop (re-recon after a foothold) and some (insider, supply chain) don't fit neatly.

The Diamond Model — the relational / intelligence lens. Every malicious event has four vertices: Adversary (who), Capability (the tool/technique/malware), Infrastructure (the IPs/domains/C2 they use), and Victim (the target). The power is pivoting: knowing one vertex lets you discover others — a C2 domain (infrastructure) leads to other victims contacting it, a malware sample (capability) leads to other infrastructure it talks to. It answers "what else is connected to this — same actor, same campaign?" and is the analytic core of threat intelligence and attribution. (Lab 03 builds exactly this pivot.)

MITRE ATT&CK — the behavioral catalog lens. A matrix of tactics (the adversary's goal at a stage — Initial Access, Persistence, Privilege Escalation, Lateral Movement, Exfiltration, …) and the techniques that achieve each (e.g. T1566 Phishing, T1078 Valid Accounts, T1021 Remote Services). It answers "what specific behavior is this, and do we have a detection for it?" ATT&CK is the shared vocabulary that ties the other two lenses to concrete, detectable actions (P09's coverage map).

How they compose (the mental model): the Kill Chain tells you where in the campaign you are; ATT&CK tells you what technique you're looking at within that phase; the Diamond Model tells you what else is related so you can scope the whole campaign. Lab 01 maps events onto Kill Chain + ATT&CK; Lab 03 pivots them with the Diamond Model.

Misconception to kill now. "ATT&CK replaced the Kill Chain." They operate at different altitudes — the Kill Chain is the sequence/strategy, ATT&CK is the technique taxonomy, the Diamond Model is the relationship graph. Strong analysts switch between all three.

Chapter 3: Reconnaissance and Attack-Surface Mapping

Zero background. Before touching a target, attackers learn it. Reconnaissance (ATT&CK tactic TA0043) splits into passive (no packets to the target — public sources) and active (probing the target, which generates logs and risk). The defender's mirror discipline is Attack-Surface Management (ASM): continuously discovering your own exposed assets before the attacker does.

Passive recon / OSINT (Open-Source Intelligence). Public data assembled into a target map: DNS and certificate transparency logs (every TLS cert is public — they leak subdomains and internal naming), WHOIS, search engines and code search (leaked secrets, internal hostnames in GitHub), job postings (revealing the tech stack), breach-data and credential dumps, social media (employee names → email format → phishing targets), and cloud-bucket/asset enumeration. None of it touches the target, so none of it is logged by them.

Active recon. Port/service scanning (nmap), service/version fingerprinting, web crawling, subdomain brute-forcing, and vulnerability scanning — all of which do hit the target and produce telemetry.

The defensive counter (break the chain at the earliest phase). You cannot stop OSINT, but you can shrink and monitor the surface it reveals: run your own ASM (subdomain/cert-transparency monitoring, external scanners, leaked-secret scanning of your repos — P03/P14), find and kill subdomain takeovers (a dangling DNS record pointing at a deprovisioned cloud resource an attacker can claim), minimize what job posts and error pages disclose, and rotate any secret that appears in a public source. Active recon is detectable — scan-pattern detections and honeypots (P09) catch it.

Misconception to kill now. "We're not interesting enough to be targeted." Recon is cheap and automated; mass scanners hit every IP on the internet continuously. Attack-surface discovery is a defensive must — the attacker is already enumerating you.

Chapter 4: Initial Access

Zero background. Initial Access (TA0001) is the attacker's first foothold inside the trust boundary. The dominant vectors, in rough order of real-world prevalence:

• Phishing (T1566). A crafted email/message lures a user into running a payload, entering credentials on a fake page, or approving an MFA prompt. Business Email Compromise (BEC) is the high-value variant — no malware, just a convincing fraudulent instruction (often after From: spoofing — P02 Chapter 14). Phishing is the single most common initial-access vector.
• Valid accounts (T1078). Logging in with real stolen/leaked/purchased credentials — the quietest entry, because it looks like a normal login. Credential stuffing, password spraying, and buying access from initial-access brokers all land here.
• Exploit public-facing application (T1190). A vulnerable internet-exposed service — the web classes of P02, an unpatched VPN/appliance, a 1-day after a patch (P08 patch diffing).
• Supply-chain compromise (T1195). Poison a dependency or the build so the victim ships the attacker's code (P14 — SolarWinds, xz).
• External remote services / trusted relationship — abusing a VPN, RDP, or a third-party integration's access.

The defensive counter. This is a choke point — almost every campaign passes through it. Phishing-resistant MFA (FIDO2/WebAuthn passkeys, which can't be phished or MFA-fatigued) defeats the credential vectors; email authentication (SPF/DKIM/DMARC) and user reporting cut phishing; patch velocity and external attack-surface reduction cut T1190; SLSA/signing cut supply chain (P14). Detect impossible-travel logins, new-device/MFA anomalies, and first-seen processes after a document open.

Misconception to kill now. "We have MFA, so credentials are handled." Push/SMS MFA is phishable and fatigue-able (spam the user with prompts until they approve). Only phishing-resistant (WebAuthn/passkey) MFA closes the channel.

Chapter 5: Execution, Persistence, and Defense Evasion

Execution (TA0002). Running attacker code on the foothold. The modern hallmark is Living-off-the-Land (LOLBins) — abusing legitimate, signed system tools (PowerShell, wmic, certutil, rundll32, mshta, bash, python) so there's no malicious binary to flag. This is why P05/P09 emphasize command-line and script-block logging: the binary is trusted; the arguments betray the abuse.

Persistence (TA0003). Surviving reboots and credential changes so the foothold is durable: scheduled tasks/cron, new or modified accounts, services, run keys, startup items, SSH authorized_keys, cloud IAM users/keys, OAuth-app grants, and — most dangerous — identity persistence (a rogue federation trust, a golden/silver Kerberos ticket, a long-lived cloud access key). Identity persistence outlives any host rebuild.

Defense Evasion (TA0005). Hiding: disabling or blinding security tooling (AMSI bypass, ETW patching — P05), clearing/tampering logs, timestomping, obfuscation, and process injection (P08 — running in a trusted process's memory). The point for a defender is that mature attackers expect your tools and try to turn them off; tamper-evident, centralized, off-host logging (P00/P09) is what survives.

The defensive counter. Application allowlisting and constrained language modes raise the cost of execution; EDR behavioral detection catches LOLBin patterns (the parent-child process tree, the command line) even when each binary is trusted; persistence is caught by baselining (a new scheduled task, a new admin, a new OAuth grant is an event to alert on); and you monitor the monitors (a source that goes silent, AMSI disabled — P09 health alerts).

Misconception to kill now. "No malware was found, so there was no compromise." Living-off-the-land intrusions ship no malware — they abuse trusted tools and stolen credentials. Behavior, not binaries, is the signal.

Chapter 6: Privilege Escalation

Zero background. A foothold rarely lands with the privilege the attacker wants. Privilege Escalation (TA0004) is climbing from the access you have to the access you need, on three terrains:

• Local (host). A setuid/sudo misconfiguration or a writable service binary on Linux (P05); an unquoted service path, token impersonation (SeImpersonate/"Potato" techniques), or a vulnerable driver on Windows; a kernel exploit (P01/P08) where memory-safety meets privilege.
• Active Directory (enterprise). The richest terrain: Kerberoasting and AS-REP roasting (crack service-account passwords offline — P05 Chapter 7), unconstrained/constrained delegation abuse, ACL abuse, and DCSync (impersonate a domain controller to pull every password hash). AD privilege escalation is usually graph navigation (BloodHound maps it).
• Cloud. Permission/trust chaining — iam:PassRole + a compute service to run as a higher role, CreatePolicyVersion to grant yourself anything, or reaching the metadata endpoint for a more privileged role's tokens (P07 Chapter 4 — the IAM attack graph).

The defensive counter. Least privilege everywhere (P05/P07); strong, rotated service-account secrets and managed/group-managed accounts (defeating Kerberoasting); tiered administration so a workstation admin can't reach a domain admin; and attack-path analysis of your own AD/IAM graph (BloodHound, the P07 analyzer) to find and cut the escalation edges before an attacker walks them.

Misconception to kill now. "Each account is least-privilege, so we're safe." Escalation is about composition — a chain of innocuous-looking permissions/edges reaches admin. You must analyze the graph (P07), not the nodes.

Chapter 7: Lateral Movement and Pivoting

Zero background. One foothold is rarely the goal. Lateral Movement (TA0008) is spreading from the compromised host to others to reach the real target (the database, the domain controller, the backup server). The mechanics:

• Credential reuse / pass-the-hash / pass-the-ticket (T1550). Reuse harvested credentials or Kerberos tickets to authenticate elsewhere without cracking the password (P05 Chapter 7) — the reason a single compromised admin password is catastrophic across a flat network.
• Remote services (T1021). RDP, SSH, SMB, WinRM, WMI — moving with valid (stolen) credentials over legitimate admin protocols, which looks like normal administration.
• Pivoting / tunneling. Using the compromised host as a router into networks the attacker can't reach directly (SOCKS proxies, SSH tunnels, port forwarding) — turning one foothold into reach across segments.

The graph view (the key insight, and Lab 02). Lateral movement is reachability over a graph whose nodes are hosts/identities and whose edges are "can authenticate to" / "shares a credential with" / "can reach over the network." An attacker runs a breadth-first search from the foothold to the crown jewels; a defender runs the same search to find the choke points — the host or credential that, if cut, disconnects the foothold from the target. That equivalence is why BloodHound (attack) and attack-path analysis (defense) are the same algorithm.

The defensive counter. Network segmentation (P06/P07/P10) shrinks the graph's edges; least-privilege and unique local-admin passwords (Windows LAPS) break credential-reuse edges; phishing-resistant MFA on internal services and just-in-time admin cut the authentication edges; and detection looks for anomalous east-west movement (a workstation suddenly using WMI/SMB to many hosts — P09).

Misconception to kill now. "The attacker only had one machine." On a flat network with reused admin credentials, one machine is the whole network — lateral movement is fast and quiet. Segmentation and unique credentials are what make the second hop hard.

Chapter 8: Collection, Command-and-Control, and Exfiltration

Collection (TA0009). Gathering the target data — files, databases, email, screenshots, keystrokes — and staging it (compressing/encrypting an archive in a scratch location) before it leaves. Staging is a detection opportunity: large unusual archive creation, mass file reads.

Command-and-Control (TA0011). The channel the foothold uses to receive instructions and return data. Modern C2 (frameworks like Cobalt Strike, Sliver, Mythic — dual-use tools also used by red teams) blends into normal traffic: HTTPS to a legitimate-looking domain, domain fronting, DNS tunneling (P02), or abusing a SaaS API (Slack/Telegram/cloud storage as C2). The defining behavior is beaconing — periodic, regular callbacks — which stands out statistically even when the content is encrypted (P09 — Zeek/network analytics on connection regularity, not payload).

Exfiltration (TA0010). Moving the staged data out — over the C2 channel, to cloud storage, via DNS, or to a physical medium. The signal is volume and destination: a large outbound transfer to a new external endpoint.

The defensive counter. Egress control is the choke point (P06/P07): default-deny outbound, allowlist destinations, and route through a proxy that logs and inspects — this breaks both C2 and exfiltration regardless of the technique. DLP (Data Loss Prevention) and data classification catch sensitive-data movement; network analytics catch beaconing by regularity; and blocking the cloud metadata endpoint (P02/P06) cuts a common credential-theft-to-exfil path.

Misconception to kill now. "The C2 traffic was encrypted, so we couldn't have seen it." You detect C2 by behavior — beacon regularity, rare destinations, JA3/TLS fingerprints, DNS volume — not by reading the payload. Encryption hides content, not pattern.

Chapter 9: Impact — Ransomware, Destruction, and Fraud

Zero background. Impact (TA0040) is the attacker's objective realized. The dominant forms:

• Ransomware. Modern ransomware is double/triple extortion: the actor exfiltrates data first (Chapter 8), then encrypts (T1486), then threatens to publish — so "we have backups" no longer means "we're fine," because the leak threat remains. Crucially, ransomware is the last step of a long campaign (initial access → escalation → lateral movement → exfil → encrypt); every earlier chapter is an opportunity to have stopped it.
• Destruction / wipers. Irreversible damage (disk wiping, sabotage) — often nation-state or hacktivist, and the OT analog (P10) is physical impact.
• Financial fraud / BEC payout. The objective is money moved, not data — a fraudulent wire after a BEC, or cryptocurrency theft.

The defensive counter (and the whole-chain lesson). At the impact stage your options are damage control: immutable, offline, tested backups (so encryption isn't fatal — but they don't solve the leak), segmentation to limit blast radius, rapid isolation (P09), and a tested IR/ransomware playbook with legal/comms. The real lesson: because impact is the end of the chain, defense is cheapest upstream — phishing-resistant MFA (Ch4), least privilege (Ch6), segmentation (Ch7), and egress control (Ch8) prevent the ransomware long before the encryption starts.

Misconception to kill now. "Backups solve ransomware." Backups address the encryption leg, not the data-theft/leak leg of double extortion — and many incidents find the backups were reachable and encrypted too. Prevention upstream and offline, tested backups together are the answer.

Chapter 10: Adversary Emulation and Purple Teaming

Zero background. Knowing the lifecycle lets you test defenses against it, safely and with authorization. The spectrum:

• Penetration test — find and prove exploitable vulnerabilities in a scoped target.
• Red team — emulate a specific adversary's TTPs end to end against the live environment to test detection and response, not just "can we get in." Goal-driven and stealthy.
• Adversary emulation — red-teaming driven by real threat intelligence: pick an actor relevant to your sector, take their documented ATT&CK techniques, and reproduce those (MITRE's emulation plans, Caldera, Atomic Red Team for atomic per-technique tests).
• Purple team — red and blue working together in a feedback loop: run a technique, check whether detection fired, fix the gap, repeat. This is the fastest way to close coverage gaps (P09).

Scoping and safety (the professional discipline — Phase 00). Every engagement is bounded by authorization: rules of engagement, scope, permitted techniques, stop conditions, deconfliction (so the blue team's real-incident response isn't triggered destructively), and no real destruction, data theft, or persistence left behind. An emulation plan maps each step to an ATT&CK technique and the safe synthetic procedure that exercises it.

The output that matters. Not "we got domain admin" but a per-technique detection-coverage report: for each ATT&CK technique exercised, did prevention block it, did telemetry record it, did a detection alert, and did response act — feeding P09's coverage map and the controls at each choke point. That closing of the loop is the point of running the attack at all.

Misconception to kill now. "Red teaming is about getting in." Getting in is assumed; the value is measuring how fast you're detected and stopped. A red team that breaches silently and a blue team that never noticed both failed — the purpose is to surface and fix that gap.

Lab Walkthrough Guidance

Four labs turn the lifecycle and the three lenses into runnable engines (all synthetic, offline):

1. Lab 01 — Kill-Chain & ATT&CK Event Mapper. Reconstruct a campaign from scattered events: map each to its kill-chain phase and ATT&CK tactic, order them, and report the earliest stage a control could have broken the chain (Chapters 2, 3–9). The lesson: defend left.
2. Lab 02 — Network Attack-Path / Pivot Planner. Model hosts/identities and "can-reach"/ "shares-credential" edges as a graph; compute which targets an attacker reaches from a foothold (BFS), and the choke points a defender cuts to disconnect the crown jewels (Chapters 6–7). The lesson: lateral movement is graph reachability.
3. Lab 03 — Diamond Model Event Correlator. Correlate events that share infrastructure or capability into campaigns, and pivot from one indicator to related events (Chapter 2). The lesson: how threat-intel attribution actually works.
4. Lab 04 — Weighted Attack-Path Solver. Weight host-graph edges by attacker effort; find the cheapest (least-resistance) path with Dijkstra and the formal dominators — nodes on every path to a target, the true choke points (Chapter 7). The lesson: attackers take the path of least resistance, not fewest hops.

LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

1. Walk the attacker lifecycle end to end, naming each stage's goal, common ATT&CK techniques, the telemetry it produces, and the control that breaks the chain there.
2. Explain the Cyber Kill Chain, Diamond Model, and ATT&CK — what each is for and when to reach for it — and that they compose rather than compete.
3. Reconstruct a campaign from events and identify the earliest, cheapest disruption point.
4. Explain lateral movement as graph reachability and find the choke-point host/credential to cut.
5. Pivot one indicator into a campaign with the Diamond Model.
6. Distinguish a pen test, red team, adversary emulation, and purple team, and scope a safe, authorized engagement with stop conditions.
7. Articulate why prevention is cheapest upstream (phishing-resistant MFA, least privilege, segmentation, egress control) and why "no malware found" or "backups exist" are false comforts.

Common Mistakes

• Defending techniques in isolation instead of finding the campaign's choke points.
• Treating the three lenses as competitors, or thinking ATT&CK replaced the Kill Chain.
• Assuming push/SMS MFA is phishing-resistant (it isn't — only WebAuthn/passkeys are).
• "No malware found = no compromise" (living-off-the-land and valid-accounts intrusions ship none).
• Believing encrypted C2 is undetectable (beaconing regularity and rare destinations betray it).
• "Backups solve ransomware" (ignores double-extortion data theft and reachable/encrypted backups).
• Red-teaming for "did we get in" instead of measuring time-to-detect and time-to-respond.
• Running any of this outside written authorization, scope, and stop conditions (Phase 00).

Interview Q&A

Q: Walk me through a ransomware intrusion and where you'd break the chain. A: Initial access (phishing or a stolen VPN credential) → execution (a LOLBin loader) → privilege escalation (Kerberoasting or a local-admin reuse) → lateral movement (pass-the-hash over SMB to the file and backup servers) → collection and exfiltration (stage an archive, beacon out over HTTPS) → impact (encrypt + leak threat). I break it upstream and at choke points: phishing-resistant MFA and patching kill most initial access; least privilege and unique local-admin passwords (LAPS) break escalation and the lateral-movement credential edges; segmentation shrinks the graph; egress control stops the C2/exfil; offline tested backups limit the encryption damage. The cheapest defense is furthest left.

Q: Compare the Cyber Kill Chain, Diamond Model, and ATT&CK. A: Different altitudes that compose. The Kill Chain is the linear campaign sequence — it answers "how far along is this and where do we cut it," and its value is detecting left. ATT&CK is the tactic→technique catalog — "what specific behavior is this, and can we detect it" — the shared vocabulary and coverage map. The Diamond Model is the relationship graph (adversary/capability/ infrastructure/victim) — "what else is connected," the basis of pivoting and attribution. I use the Kill Chain to phase an intrusion, ATT&CK to label and detect the techniques, and the Diamond Model to scope the campaign.

Q: How is lateral movement a graph problem, and how does that help the defender? A: Nodes are hosts/identities; edges are "can authenticate to," "shares a credential with," and "can reach over the network." The attacker BFS's from a foothold to the crown jewels; the defender runs the same search to find choke points — the host or credential that, if removed, disconnects the foothold from the target. It's why BloodHound (offense) and attack-path analysis (defense) are one algorithm, and why segmentation, unique local-admin passwords, and tiered admin are the highest-leverage controls.

Q: A red team breached us silently and got domain admin. Did the engagement succeed or fail? A: The test succeeded — it revealed that our detection and response failed. Red-teaming assumes breach; its purpose is to measure time-to-detect and time-to-respond and to surface the coverage gaps. The right next step is a purple-team loop: replay each technique, find why no detection fired, fix it, and re-test — turning the breach into closed detection gaps mapped to ATT&CK.

Q: Why isn't push MFA enough, and what is "phishing-resistant"? A: Push/SMS/TOTP MFA can be phished (a proxy phishing kit relays the code) or fatigued (spam approvals until the user taps "yes"). Phishing-resistant MFA — FIDO2/WebAuthn passkeys — binds the credential to the origin and uses a hardware-held key, so a fake site can't relay it and there's no code to approve. It closes the dominant initial-access channel (stolen/phished credentials).

References

Frameworks and models

• Lockheed Martin Cyber Kill Chain; Caltagirone, Pendergast & Betz, The Diamond Model of Intrusion Analysis; MITRE ATT&CK (Enterprise/Cloud/ICS) and the ATT&CK Navigator.
• MITRE D3FEND (defensive techniques) and the Center for Threat-Informed Defense mappings.
• The Pyramid of Pain (David Bianco) — indicators vs. TTPs (P09).

Adversary emulation and testing

• MITRE Adversary Emulation Library and Caldera; Red Canary Atomic Red Team.
• The Unified Kill Chain (Pols) — a longer, looped model unifying Kill Chain + ATT&CK.
• PTES (Penetration Testing Execution Standard); NIST SP 800-115 (testing); OSSTMM.

Tradecraft references (study defensively; authorized-lab only)

• BloodHound / attack-path analysis for AD and Azure (the graph view of Chapters 6–7).
• CISA/FBI joint advisories and DFIR reporting (real campaign walkthroughs mapped to ATT&CK).
• Phase cross-references: P02 (web/identity/email), P05 (OS/AD escalation), P06/P07 (segmentation, cloud IAM graph, egress), P08 (exploitation/evasion), P09 (detection, IR, pyramid of pain).

Offensive Lab 01 — Kill-Chain & ATT&CK Event Mapper

Lenses: Cyber Kill Chain + MITRE ATT&CK. WARMUP: Chapters 2–9.

The problem

An intrusion arrives as scattered, out-of-order events — an alert here, a log line there. To respond you must turn them into a campaign: which ATT&CK technique is each, where in the lifecycle does it sit, how far did the attacker get, and — most important — where was the earliest, cheapest place to break the chain? "Defend left": the lower the tactic in the lifecycle, the more downstream damage a control there prevents.

What you build (lab.py)

• classify(technique_id) — {technique, name, tactic, order, break_control} (the break-the-chain control for each technique).
• reconstruct(events) — order scattered events along the lifecycle (tactic order → timestamp → id).
• tactics_reached(events) / furthest_tactic(events) — "how far along is this intrusion?"
• earliest_break(events) — the lowest-order event and the control that would have broken the chain there.

Attack cases the tests cover

• A ransomware campaign (phishing → execution → lateral movement → exfiltration → impact) observed out of order is reconstructed into lifecycle order.
• furthest_tactic reports the deepest stage reached.
• earliest_break returns the lowest-order tactic (and prefers reconnaissance when present) with its defensive control.
• Unknown techniques and empty inputs are handled; output is deterministic.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Load the real ATT&CK STIX bundle (full technique→tactic mapping, sub-techniques).
• Map each technique to its detection data sources and join with a coverage map (P09).
• Score the campaign's dwell time (first-to-last event) and flag the longest undetected gap.
• Emit an ATT&CK Navigator layer of the observed techniques.

Interview / resume

"Built a campaign reconstructor that maps scattered events to ATT&CK techniques/tactics, orders them along the attacker lifecycle, reports how far an intrusion progressed, and identifies the earliest break point — encoding the 'defend left' principle."

Limitations: a representative technique slice (not the full ATT&CK matrix); single-tactic per technique; lifecycle order approximated by ATT&CK enterprise tactic order.

Offensive Lab 02 — Network Attack-Path / Pivot Planner

Lens: Lateral movement as graph reachability. WARMUP: Chapters 6–7.

The problem

One foothold is rarely the goal. Lateral movement spreads from the compromised host to the crown jewels (the domain controller, the database, the backup server) over a graph whose nodes are hosts/identities and whose edges are "can move from A to B" (network reachability, a shared credential, an admin session, a trust). The attacker runs a breadth-first search from the foothold; the defender runs the same search to find the choke point — the node that, if cut, disconnects the foothold from a target. (BloodHound for offense and attack-path analysis for defense are the same algorithm.)

What you build (lab.py)

• reachable(edges, start, exclude=None) — BFS reachable set, optionally removing a node.
• reaches / reachable_targets — what crown jewels the attacker reaches from a foothold.
• shortest_path(edges, start, target) — deterministic BFS attack path.
• choke_points(edges, start, targets) — the nodes whose removal disconnects the foothold from a currently-reachable target: the highest-leverage defensive cuts.

Attack cases the tests cover

• From a workstation foothold, the attacker reaches the file server, jump host, DC, and backup (but not a disconnected island).
• The DC has two paths (via the file server and the jump host) → no single choke; the backup is reachable only via the jump host → jumphost is the choke point.
• Removing the jump host cuts the backup but leaves the DC reachable (second path).
• A linear a→b→c chain makes b the choke point.
• Deterministic shortest paths; excluding the start yields an empty reachable set.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Weight edges by attacker cost (a cracked Kerberos ticket vs. a clear-text admin session) and find the cheapest path, not just the shortest.
• Model credential nodes explicitly so a shared local-admin password becomes a visible choke point (the argument for Windows LAPS).
• Compute true dominators (every path passes through) and rank choke points by how many targets they cut.
• Import a real BloodHound/Azure graph export (authorized environments only).

Interview / resume

"Built an attack-path planner that models lateral movement as reachability over a host/credential graph — computing reachable crown jewels from a foothold and the choke points a defender cuts — demonstrating that BloodHound (offense) and attack-path analysis (defense) are one algorithm, and why segmentation and unique local-admin passwords are the highest-leverage controls."

Limitations: unweighted directed graph; choke points found by node-removal (not full dominator analysis); synthetic graph only.

Offensive Lab 03 — Diamond Model Event Correlator

Lens: The Diamond Model (adversary / capability / infrastructure / victim). WARMUP: Chapter 2.

The problem

A single malicious event tells you little; the power of intelligence analysis is pivoting — using one observed vertex to discover related events. Two events that share infrastructure (the same C2 IP/domain) or capability (the same malware/tool) are likely the same campaign, even when the adversary is unknown. This engine pivots from one event to its relatives, clusters events into campaigns, and infers attribution by association — while honestly flagging when that inference conflicts (the danger of over-attributing on shared infrastructure).

What you build (lab.py)

• pivot(events, event_id) — events sharing capability or infrastructure with a given one (the core analyst move).
• correlate(events) — connected components over shared infra/capability = campaigns.
• infer_adversary(events, cluster) — the single known adversary across a cluster, or conflicting, or None (attribution by association, with its failure mode).
• campaign_summary(events) — per-cluster rollup of adversary, victims, infrastructure, capabilities.

Attack cases the tests cover

• Pivoting from ev2 finds ev1 (shared capability) and ev3 (shared infrastructure).
• Three events chain into one campaign cluster; a separate pair forms another; an event with no observables stays isolated.
• Attribution by association: an unattributed event in a known actor's cluster inherits the attribution — and a second actor in the same cluster is flagged conflicting (don't over-attribute).
• Deterministic clustering and campaign summaries.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Weight pivots by confidence (a unique C2 domain is stronger evidence than a shared commodity tool).
• Add time so infrastructure reuse is only a pivot within an overlapping active window.
• Ingest STIX bundles and export clusters as STIX grouping/relationship objects.
• Add the other Diamond meta-features (timestamp, phase, result, direction, methodology, resources).

Interview / resume

"Built a Diamond Model correlator that pivots events on shared infrastructure/capability, clusters them into campaigns, and performs attribution by association while flagging conflicting attribution — the analytic core of threat intelligence, including its over-attribution failure mode."

Limitations: pivots on capability/infrastructure equality only (no fuzzy/confidence matching, no time window); attribution is single-actor-or-conflict; synthetic intel records.

Offensive Lab 04 — Weighted Attack-Path Solver

Lens: Lateral movement, weighted. WARMUP: Chapter 7. Extends: Lab 02.

The problem

Lab 02 found reachability and choke points over an unweighted graph. Real attackers take the path of least resistance, not fewest hops — a reused clear-text admin session is cheaper than cracking a Kerberos ticket. This lab weights each edge by attacker effort and finds the cheapest path (Dijkstra), and computes formal dominators — nodes on every path from the foothold to a target, i.e. the true choke points a defender must cut.

What you build (lab.py)

• cheapest_path(edges, start, target) → (path, cost) via Dijkstra; (None, inf) if unreachable.
• path_cost(...) → the total attacker effort.
• dominators(edges, start, target) → nodes whose removal disconnects the target (true choke points).

Cases the tests cover

• The cheapest path takes the low-effort route even when it's longer in hops; a cheaper long path beats an expensive direct edge; unreachable targets return (None, inf).
• Dominators: a target with two paths has no single dominator; a target reachable only via one node has that node as a dominator; a linear chain's interior nodes are all dominators.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Derive edge cost from real signals (auth type, MFA, patch level, exploit availability/EPSS).
• Compute a minimum-cost cut (cheapest set of edges to disconnect the crown jewels), not just dominator nodes.
• Import a BloodHound/Azure graph (authorized environments) and rank remediations by cost-to-cut.

Interview / resume

"Built a weighted attack-path solver (Dijkstra cheapest path + formal dominators) showing that attackers follow least-resistance, not shortest, paths — and that dominator nodes are the highest-leverage cuts for a defender."

Limitations: static weights on a directed graph; dominators via node-removal (not the linear-time dominator-tree algorithm); no min-cut.

Wireless, RF, and IoT Security — A Cross-Cutting Module

What this is. A phase-equivalent module on the security of the radio attack surface — Wi-Fi (802.11), Bluetooth/BLE, NFC/RFID, and the broader IoT/RF world — the layer most curricula skip because it lives off the wire. Attackers don't need a network port when they can reach you over the air from the parking lot; defenders (and authorized wireless assessors) must understand how these links authenticate, encrypt, and fail.

Why it's its own module. The rest of the track assumes IP-and-above. Wireless changes the medium: anyone in range can listen and transmit, identity is tied to radios you don't control, and "physical access" shrinks to "within ~100 m." That reframes the threat model — rogue access points, evil twins, handshake capture, BLE pairing weaknesses, and RFID cloning have no exact wired analog.

Prerequisites. Phases 02 (TLS/identity), 05 (OS), 13 (hardware). Everything here is authorized-lab-only and offline — the labs reason over captured scan/advertisement metadata, never live transmission. Transmitting on licensed/occupied spectrum or attacking networks you don't own is illegal (Phase 00); this module builds analysis and defense judgment.

Learning Objectives

By the end you can, without notes:

1. Explain the Wi-Fi security evolution (WEP → WPA/WPA2-PSK → WPA3-SAE → Enterprise/802.1X) and what each fixed and left open.
2. Explain the 4-way handshake, why it's capturable, and what makes a WPA2-PSK network crackable (offline dictionary attack, PMKID) versus WPA3-SAE's resistance.
3. Detect rogue APs and evil twins and explain why "it has the right SSID" proves nothing.
4. Reason about Bluetooth/BLE pairing (Just Works vs Passkey vs Numeric Comparison) and why Just Works has no MITM protection.
5. Explain NFC/RFID cloning and relay attacks and the defenses (cryptographic challenge-response, distance bounding).
6. Give the defensive playbook: WPA3/802.1X, management-frame protection (802.11w), wireless IDS, network segmentation for IoT, and "no security by obscurity of frequency."

The radio threat model (read the WARMUP)

WIRED:    attacker needs a port / a route          identity ~ cable + switchport
WIRELESS: attacker needs to be in range            identity ~ a radio anyone can imitate
          → passive capture is free and invisible
          → transmitting a stronger/identical signal hijacks the link (evil twin, rogue AP)

See WARMUP.md for the full from-zero treatment of 802.11, the handshakes, BLE, NFC/RFID, and the defenses.

Labs

Each lab is pure Python (stdlib + pytest) with lab.py/solution.py/test_lab.py/README.md.

cd lab-01-wireless-survey-analyzer
LAB_MODULE=solution pytest -q
pytest -q

Safety

Authorized-lab-only and offline; the labs analyze captured/synthetic metadata. No transmission, no attacking networks/devices you don't own, no spectrum you aren't licensed for (Phase 00).

Warmup Guide — Wireless, RF, and IoT Security from First Principles

Zero-to-expert primer for the Wireless/RF/IoT module. It builds the radio attack surface from the ground up: why wireless changes the threat model, the 802.11 security evolution, the 4-way handshake and how WPA2 is cracked, WPA3/SAE and Enterprise/802.1X, rogue APs and evil twins, Bluetooth/BLE pairing, NFC/RFID cloning and relay, and the defensive playbook. Everything is authorized-lab-only and offline — analysis over captured metadata, never live transmission (Phase 00). By the end you can read a wireless survey, judge what's crackable, spot an evil twin, and reason about BLE/NFC.

Table of Contents

• Chapter 1: Why Radio Changes the Threat Model
• Chapter 2: 802.11 and the Wi-Fi Security Evolution
• Chapter 3: The 4-Way Handshake and How WPA2 Is Cracked
• Chapter 4: WPA3, SAE, and Enterprise 802.1X
• Chapter 5: Rogue APs, Evil Twins, and Deauthentication
• Chapter 6: Bluetooth and BLE
• Chapter 7: NFC, RFID, and Relay Attacks
• Chapter 8: IoT and the Broader RF Surface
• Chapter 9: The Wireless Defensive Playbook
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Why Radio Changes the Threat Model

Zero background. Every other phase assumes a wire: to attack you, someone needs a network port, a route, or a foothold. Radio removes that assumption. A wireless signal is broadcast into shared space, so anyone within range can receive it passively (invisibly — no packets sent, nothing logged) and anyone can transmit on the same frequency. The "perimeter" is now a sphere of radio range — a parking lot, the floor above, a drone overhead.

The two consequences that reshape everything:

• Passive capture is free and undetectable. An attacker can record all your Wi-Fi traffic (encrypted or not) without touching your network. This is why wireless encryption and forward secrecy matter so much: captured ciphertext today must stay safe tomorrow.
• Identity is tied to a radio you don't control. A device identifies an access point by its name (SSID) and MAC (BSSID) — both trivially forged. An attacker who transmits the same SSID with a stronger signal becomes "the network" to nearby clients (the evil twin, Chapter 5). There's no cable to trust.

Why a defender (or authorized assessor) must learn this. You cannot secure or assess what you can't model. Wireless is a first-class enterprise attack surface — guest networks, IoT devices, badge readers, Bluetooth peripherals — and "it's just Wi-Fi" has cost real breaches.

Misconception to kill now. "Our Wi-Fi is hidden / uses an obscure frequency, so it's safe." Hiding the SSID stops nothing (clients still probe for it, revealing it), and security through frequency obscurity fails to anyone with a $30 software-defined radio. Wireless security comes from cryptography and authentication, not from being hard to find.

Chapter 2: 802.11 and the Wi-Fi Security Evolution

What 802.11 is. The IEEE family of Wi-Fi standards. For security you care about how a client (STA) associates with an access point (AP) and how the link is authenticated and encrypted. Frames come in three types: management (beacons, association, deauthentication — historically unauthenticated), control, and data.

The evolution — each step fixed the previous disaster:

• WEP (Wired Equivalent Privacy). The original — broken beyond repair. A tiny 24-bit IV reused constantly and an RC4 flaw let the key be recovered from captured traffic in minutes. If you ever see WEP, it is effectively open.
• WPA / WPA2 (with TKIP or CCMP/AES). WPA2-CCMP (AES) is the long-time baseline. Two modes: Personal (PSK) — everyone shares one passphrase — and Enterprise (802.1X) — each user authenticates individually (Chapter 4). WPA2-PSK's weakness is the offline-crackable handshake (Chapter 3). TKIP is legacy and weak; CCMP/AES is the floor.
• WPA3. The current standard. Replaces the PSK handshake with SAE (Simultaneous Authentication of Equals — a password-authenticated key exchange) that resists offline cracking and adds forward secrecy, and mandates management-frame protection (802.11w) to stop deauth attacks (Chapter 5).

Misconception to kill now. "WPA2 is fine." WPA2-CCMP is still widely acceptable, but WPA2-PSK with a weak passphrase is offline-crackable from a single captured handshake, and WPA2 lacks mandatory management-frame protection. WPA3/SAE is the answer; WEP and TKIP are non-negotiable removals.

Chapter 3: The 4-Way Handshake and How WPA2 Is Cracked

The mechanism. In WPA2-PSK, the AP and client both already know the passphrase; the 4-way handshake is how they prove it and derive fresh per-session keys without sending the passphrase. From the passphrase (and SSID) both sides compute the PMK (Pairwise Master Key); the handshake exchanges nonces and derives the PTK (Pairwise Transient Key) for the session, and a MIC (message integrity code) proves each side holds the PMK.

Why it's crackable (the key insight). An eavesdropper who captures the handshake has everything needed to verify a guess offline: they take a candidate passphrase, derive the PMK, derive the PTK with the captured nonces, compute the MIC, and check it against the captured MIC. No interaction with the network is needed — it's a pure offline dictionary/brute-force attack, GPU-accelerated. So WPA2-PSK security = passphrase strength. A weak or common passphrase falls in seconds; a long random one is infeasible.

• Getting the handshake. Wait for a client to join, or send a forged deauthentication frame (WPA2 management frames are unauthenticated) to kick a client off so it reconnects and you capture the handshake (Chapter 5).
• PMKID attack. Some APs leak a PMKID in the first handshake message, letting an attacker derive the same offline-crackable material from the AP alone — no client needed.

The defense. A long, high-entropy passphrase makes offline cracking infeasible; better, move to WPA3-SAE, whose handshake is not offline-crackable (each guess requires a fresh online interaction the AP can rate-limit), or Enterprise 802.1X (no shared passphrase at all).

Misconception to kill now. "They'd have to break AES." They don't — they capture the handshake and brute-force the passphrase offline. The cipher is fine; the shared human-chosen secret is the weak link.

Chapter 4: WPA3, SAE, and Enterprise 802.1X

WPA3-SAE (Personal). SAE is a password-authenticated key exchange (a "dragonfly" handshake): both sides prove knowledge of the passphrase through an interactive exchange that yields no offline- crackable artifact and provides forward secrecy (a later passphrase compromise doesn't decrypt past captures). An attacker must guess online, against an AP that can throttle — turning an offline GPU attack into an infeasible online one. (The early "Dragonblood" side-channel/downgrade bugs were patched; transition modes that allow WPA2 fallback reintroduce risk.)

Enterprise / 802.1X (the right answer for organizations). Instead of a shared passphrase, each user/device authenticates individually to a RADIUS server via EAP (Extensible Authentication Protocol). The robust variant is EAP-TLS — mutual certificate authentication, no password to phish or crack. The components: the supplicant (client), the authenticator (AP/ switch), and the authentication server (RADIUS). Benefits: per-user keys and revocation, no shared secret, and integration with your identity provider (Phase 02/05).

The classic Enterprise pitfall. If clients don't validate the RADIUS server's certificate, an attacker stands up a rogue AP + rogue RADIUS (an "evil twin" for Enterprise) and harvests the EAP credentials (e.g., MSCHAPv2 hashes to crack). The defense is server-certificate validation pinned to your CA on every client — the wireless echo of Phase 02's "validate the cert, not just the name."

Misconception to kill now. "Enterprise Wi-Fi is automatically secure." Only if clients validate the server certificate; a misconfigured supplicant trusts any RADIUS server and leaks credentials to a rogue one. Configuration, not the protocol name, is the control.

Chapter 5: Rogue APs, Evil Twins, and Deauthentication

Rogue AP. Any unauthorized access point on (or impersonating) your network — a malicious one an attacker plants, or a careless employee's personal router bridged to the corporate LAN (a backdoor around all your wired controls).

Evil twin. An attacker AP that clones a legitimate network's SSID (and often BSSID) and broadcasts a stronger signal, so nearby clients — which auto-connect to the "best" known network — associate with the attacker. Now the attacker is the client's gateway: they can capture traffic, run a captive-portal phishing page, or (for Enterprise) harvest EAP credentials. The defining lesson: a matching SSID proves nothing — SSID/BSSID are forgeable, so "the right name and a strong signal" is exactly what an attacker presents.

Deauthentication attack. Because WPA2 management frames are unauthenticated, an attacker can spoof a deauth frame to disconnect a client — to cause a denial of service, or to force a reconnect so they can (a) capture the 4-way handshake (Chapter 3) or (b) push the client onto their evil twin. 802.11w (management-frame protection), mandatory in WPA3, cryptographically protects these frames and shuts the attack down.

Detection (the defender's job, and Lab 01). A Wireless IDS spots evil twins and rogue APs by the contradictions: the same SSID on an unexpected BSSID/vendor, a known SSID suddenly on a different channel or with a much stronger RSSI, a BSSID not in your approved inventory, or an open clone of a secured network. You build exactly this classifier in Lab 01.

Misconception to kill now. "My phone connected to our network name, so it's our network." Your phone connected to the strongest radio claiming that name. Without server-certificate validation (Enterprise) or WPA3, that can be an evil twin.

Chapter 6: Bluetooth and BLE

What it is. Bluetooth Classic (BR/EDR) and Bluetooth Low Energy (BLE) are short-range radio for peripherals and IoT. BLE dominates modern devices (wearables, locks, medical, beacons). Two security questions matter: how devices pair (establish keys) and how they're identified.

Pairing methods — the security hinges here:

• Just Works — pairing with no user verification. It encrypts the link but provides no MITM protection: an attacker present during pairing can interpose. Ubiquitous in cheap IoT because it needs no display/keypad — and a frequent finding.
• Passkey Entry — a 6-digit code shown on one device, entered on the other: MITM resistance if the passkey is random and not reused.
• Numeric Comparison (Secure Connections / LE Secure Connections) — both devices show a number the user confirms; the strongest, using ECDH so a passive eavesdropper can't derive the key.

Other BLE issues. Static or predictable MAC addresses enable tracking (mitigated by MAC randomization); legacy pairing's weak key derivation; sniffing during pairing; and the perennial default credentials / no authentication on the application layer (a BLE lock that opens for any phone that speaks its protocol). Bluetooth has also had implementation-bug families (e.g., BlueBorne, KNOB key-negotiation downgrade) — patch currency matters.

Misconception to kill now. "It's paired, so it's secure." Just Works pairing encrypts but does not authenticate — an attacker can MITM the pairing — and many devices add no application-layer auth on top, so "paired" can mean "anyone nearby can drive it."

Chapter 7: NFC, RFID, and Relay Attacks

What they are. RFID (radio-frequency identification) and NFC (near-field communication, a short-range RFID subset) power badges, transit cards, payment, and tags. Security depends entirely on whether the tag does cryptographic challenge-response or just presents a static identifier.

The attacks:

• Cloning. A tag that emits a fixed ID (older 125 kHz badges, MIFARE Classic with its broken Crypto1 cipher) can be read and copied to a blank — an attacker brushes past your badge with a pocket reader and walks in. Secure tags (DESFire, modern e-passports, EMV cards) use a secret key in challenge-response that never leaves the chip, so the response can't be replayed.
• Relay attack. Even a cryptographically sound contactless system can be defeated by relaying the radio exchange in real time: one attacker's device near the victim's card, another near the reader, tunneling the challenge/response over the internet so the reader thinks the card is present. The defense is distance bounding (measuring round-trip time so a far-away card is rejected) and requiring user intent (tap-to-confirm, on-device biometric).

Misconception to kill now. "Our badges are RFID, so they're secure." A static-ID badge is a password you broadcast to anyone with a reader. Security requires challenge-response with a key the tag never reveals — and even then, relay attacks need distance bounding.

Chapter 8: IoT and the Broader RF Surface

Why IoT concentrates wireless risk. IoT devices are cheap, long-lived, rarely patched, and often ship with default credentials, no secure update (OTA) mechanism, unauthenticated local protocols, and hardcoded keys (Phase 13). They speak Wi-Fi, BLE, Zigbee/Z-Wave (mesh home/ building automation), LoRa (long-range), and proprietary sub-GHz RF (garage doors, sensors, car key fobs). Many sub-GHz remotes use static codes or weak rolling codes that are replayable or roll-jam-able with a software-defined radio.

The IoT security checklist (what an assessor looks for): unique per-device credentials (no shared defaults), authenticated + signed OTA updates with anti-rollback (Phase 13), encrypted + authenticated radio links (not Just Works / static codes), no hardcoded secrets, a documented patch lifecycle, and — critically at the architecture level — network segmentation so a compromised camera can't reach the rest of the network (Phase 06/07).

Misconception to kill now. "It's just a sensor / a lightbulb." A foothold device with weak RF and no segmentation is a pivot into the whole network (Chapter 7 of the Offensive module) and a botnet recruit (Mirai). The cheapest device sets your wireless security floor.

Chapter 9: The Wireless Defensive Playbook

Pulling it together — the controls, mapped to the mechanisms they fix:

• Use WPA3-SAE (or strong WPA2-CCMP with a long random passphrase as a floor); never WEP or TKIP. For organizations, Enterprise 802.1X with EAP-TLS and enforced server-certificate validation on every client.
• Mandate 802.11w (management-frame protection) to kill deauth/evil-twin forcing.
• Run a Wireless IDS/IPS to detect rogue APs and evil twins against an approved BSSID inventory (Lab 01), and physically locate them.
• Segment guest, corporate, and IoT onto separate VLANs/networks with least-privilege routing (Phase 06/07); a guest or IoT device must not reach corporate systems.
• BLE/NFC: require Secure Connections (Numeric Comparison) pairing, application-layer authentication, challenge-response (not static-ID) tags, and distance bounding for high-value contactless.
• IoT: unique credentials, signed OTA + anti-rollback (Phase 13), and an inventory + patch lifecycle.

Misconception to kill now. "We set a Wi-Fi password, so wireless is handled." A passphrase is one control on one link type. The wireless surface is APs (rogue/evil-twin), management frames, Bluetooth, NFC badges, and dozens of unpatched IoT radios — each needs its own control, and segmentation is what limits the blast radius when one fails.

Lab Walkthrough Guidance

Two labs turn the radio surface into runnable analysis (all synthetic/offline):

1. Lab 01 — Wireless Survey Analyzer. From a scan (SSID/BSSID/vendor/security/channel/RSSI), classify each AP's posture (open/WEP/WPA2-PSK/WPA3/Enterprise), rate handshake crackability, and detect rogue/evil-twin APs against an approved inventory (Chapters 2–5).
2. Lab 02 — BLE/IoT Posture Evaluator. From device metadata (BLE pairing method, app-layer auth, default creds, OTA support, tag type), flag the weaknesses — Just Works, static-ID tags, default credentials, no signed OTA — with severity (Chapters 6–8).

LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

1. Explain why radio removes the wired perimeter and makes passive capture free.
2. Explain the 4-way handshake and why WPA2-PSK is offline-crackable (and PMKID), versus WPA3-SAE.
3. Explain Enterprise 802.1X/EAP-TLS and the server-certificate-validation pitfall.
4. Detect an evil twin and explain why a matching SSID proves nothing.
5. Compare BLE Just Works / Passkey / Numeric Comparison and the MITM implications.
6. Explain RFID/NFC cloning vs. relay attacks and their defenses.
7. Give the wireless defensive playbook and why IoT segmentation is the blast-radius control.

Common Mistakes

• Treating a hidden SSID or an obscure frequency as a security control.
• Running WEP/TKIP, or WPA2-PSK with a weak passphrase (offline-crackable from one handshake).
• Deploying Enterprise Wi-Fi without enforcing RADIUS server-certificate validation on clients.
• Trusting a network by SSID match (evil twin) or a badge by static RFID ID (cloning).
• Accepting BLE "Just Works" pairing for anything sensitive; assuming "paired" means "authenticated."
• Putting IoT on the flat corporate network with default credentials and no signed OTA.

Interview Q&A

Q: How is WPA2-PSK cracked, and how does WPA3 change it? A: An eavesdropper captures the 4-way handshake (waiting for a join or forcing one with a spoofed deauth), then brute-forces offline: for each candidate passphrase, derive the PMK→PTK with the captured nonces, compute the MIC, and compare to the captured MIC — no network interaction, GPU- accelerated, so security equals passphrase entropy (PMKID makes it client-free). WPA3-SAE replaces this with a password-authenticated key exchange that yields no offline-crackable artifact and adds forward secrecy, so guessing must happen online against a rate-limiting AP.

Q: What's an evil twin and how do you detect it? A: A rogue AP cloning a legitimate SSID (often BSSID) with a stronger signal so clients auto-associate to the attacker, who then captures traffic, phishes via captive portal, or harvests Enterprise EAP credentials. A matching SSID proves nothing — names and MACs are forgeable. Detection is contradiction- spotting against an approved inventory: the same SSID on an unexpected BSSID/vendor/channel, an open clone of a secured network, or an anomalous signal — a wireless IDS, plus enforced server-cert validation (Enterprise) and WPA3/802.11w to prevent the forcing.

Q: A client wants BLE locks — what do you check? A: The pairing method (reject Just Works — it encrypts but gives no MITM protection; require LE Secure Connections / Numeric Comparison), application-layer authentication (the lock must authenticate the phone, not just be "paired"), no default/shared keys, MAC randomization to prevent tracking, signed OTA updates, and resistance to relay (proximity/intent confirmation). "Paired" is not "authenticated."

Q: Why isn't an RFID badge secure by default? A: A static-ID tag broadcasts a fixed identifier any reader can capture and clone to a blank — it's a password you transmit on demand. Security needs challenge-response with a key the tag never reveals (DESFire, EMV), and even those need distance bounding to defeat real-time relay attacks.

References

• IEEE 802.11 (incl. 802.11i security, 802.11w management-frame protection); Wi-Fi Alliance WPA3 / SAE.
• "Dragonblood" (Vanhoef & Ronen) — WPA3 SAE analysis; KRACK (Vanhoef) — WPA2 handshake reinstallation.
• Bluetooth Core Spec (LE Secure Connections, pairing); BlueBorne and KNOB attack research.
• MIFARE Classic / Crypto1 break (Nohl et al.); EMV and NFC relay-attack and distance-bounding research.
• IoT: OWASP IoT Top 10; the Mirai botnet retrospective; Phase 13 (firmware, OTA, anti-rollback).
• Phase cross-references: P02 (TLS/identity), P06/P07 (segmentation), P13 (hardware/firmware).

Wireless Lab 01 — Wireless Survey Analyzer

WARMUP: Chapters 2–5 (802.11, handshake, WPA3/802.1X, evil twins).

Threat model

From the parking lot, an attacker passively captures your Wi-Fi and stands up an evil twin (your SSID, a stronger signal) to harvest traffic or credentials. The "attacker" this lab analyzes is a weak or impersonated wireless link: an open/WEP network, a WPA2-PSK with a crackable passphrase, or a rogue AP cloning a managed SSID. The engine turns a scan into posture ratings, crackability verdicts, and rogue/evil-twin findings against an approved BSSID inventory.

What you build (lab.py)

• classify_posture(ap) → (rating, issues): open-network, wep-broken, weak-passphrase, pmkid-exposed, no-mfp; rating critical/weak/acceptable/strong.
• crackability(ap) → trivial / offline-feasible / offline-hard / online-only / n/a-enterprise — encoding that WPA2-PSK = passphrase entropy and WPA3-SAE resists offline cracking.
• detect_rogues(scan, approved) → evil-twin/rogue findings (known SSID on an unapproved BSSID; open clone of a managed SSID = critical).

Attack cases the tests cover

• Open/WEP = critical + trivial; WPA2-PSK weak/PMKID = offline-feasible; WPA2-PSK strong = offline-hard; WPA3-SAE = strong + online-only; Enterprise = n/a.
• Missing 802.11w flagged; an evil twin (SSID match, unapproved BSSID) detected; an open clone rated critical; an unknown SSID is not flagged; findings sorted by severity.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add channel/RSSI anomaly scoring (a known SSID suddenly louder or on a new channel).
• Flag WPA3 transition mode (downgrade-to-WPA2) and Enterprise without server-cert validation.
• Ingest a real airodump/Kismet CSV and locate rogues by signal triangulation.

Interview / resume

"Built a Wi-Fi survey analyzer that rates AP posture, judges handshake crackability (WPA2-PSK offline vs WPA3-SAE online), and detects evil-twin/rogue APs against an approved inventory — encoding that a matching SSID proves nothing."

Limitations: analyzes scan metadata (no live capture); crackability is a category, not a time estimate; rogue detection keys on the approved-BSSID inventory.

Wireless Lab 02 — BLE / IoT Posture Evaluator

WARMUP: Chapters 6–8 (Bluetooth/BLE, NFC/RFID, IoT).

Threat model

Cheap, long-lived, rarely-patched IoT devices set your wireless security floor. The weaknesses are predictable: BLE Just Works pairing (encrypted but no MITM protection), no application-layer auth ("paired" ≠ "authenticated" — anyone nearby drives the device), default credentials, unsigned or absent OTA (can't patch / attacker pushes firmware), static-ID RFID/NFC tags (clonable), hardcoded keys, and trackable MACs. This engine turns device metadata into a severity-ranked findings list.

What you build (lab.py)

• evaluate(device) — ble-no-pairing (critical), ble-just-works (high), no-app-layer-auth, default-credentials (critical), hardcoded-keys, no-ota/unsigned-ota/ota-no-antirollback, clonable-static-id, trackable-mac — severity-sorted.
• is_secure(device) — nothing medium-or-above.

Attack cases the tests cover

• A device with Numeric-Comparison pairing, app auth, and signed+anti-rollback OTA is clean.
• Just Works = high; no pairing = critical; default creds = critical (first); each OTA tier flagged correctly; static-ID tag clonable while crypto-challenge is clean; BLE checks skipped for non-BLE devices; severity-sorted output.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add a segmentation check (is the device on an isolated VLAN?) — the blast-radius control.
• Model known CVE/protocol-downgrade exposure (KNOB, BleedingTooth) by firmware version.
• Evaluate sub-GHz remotes for static/rolling-code replay/roll-jam exposure.

Interview / resume

"Built a BLE/IoT posture evaluator flagging Just Works pairing, missing app-layer auth, default credentials, unsigned OTA, and clonable static-ID tags — encoding that 'paired' is not 'authenticated' and that the cheapest device sets the wireless security floor."

Limitations: metadata analysis only; no live BLE/NFC interrogation; rule set is the common high-value weaknesses, not exhaustive.

iOS and Apple Platform App Security — A Module

What this is. The mobile-app counterpart to Phase 04 (Android), for Apple platforms. Phase 05 covers Apple OS internals (XNU, code signing, sandbox, TCC, Secure Enclave); this module covers what an app security engineer reviews in an iOS application: App Transport Security, entitlements and the Info.plist, the Data Protection classes and Keychain accessibility, URL-scheme/universal-link handling, the pasteboard, privacy manifests and required-reason APIs, and why jailbreak detection and pinning are not authorization boundaries.

Why it's its own module. Phase 04 is Android-specific (Binder, intents, the manifest, JADX). iOS is a different platform with different primitives — Info.plist instead of AndroidManifest.xml, entitlements instead of permissions, Data Protection classes instead of file modes, App Groups and Keychain access groups instead of sharedUserId. The principles are shared (least privilege, server-side authorization, protect the whole data lifecycle); the mechanisms are not.

Prerequisites. Phase 04 (mobile threat model), Phase 05 (Apple OS internals — sandbox, TCC, Secure Enclave), Phase 02 (TLS/identity). Everything here is authorized-lab-only and offline — the labs analyze app configuration metadata (Info.plist, entitlements, data-protection settings), not live devices.

Learning Objectives

By the end you can, without notes:

1. Read an iOS app's Info.plist and entitlements and flag the dangerous ones (ATS exceptions, over-broad entitlements, hijackable URL schemes, missing data protection).
2. Explain App Transport Security (ATS) and why NSAllowsArbitraryLoads is a finding.
3. Choose the right Data Protection class and Keychain accessibility for a datum, and explain the tradeoffs (CompleteUntilFirstUserAuthentication vs Complete vs Always).
4. Explain URL-scheme hijacking and why Universal Links (verified apple-app-site-association) are the secure alternative — the iOS mirror of Android App Links.
5. Reason about pasteboard, screenshots, backups, and logs as data-lifecycle leaks.
6. Explain privacy manifests / required-reason APIs and App Tracking Transparency.
7. State why jailbreak detection and certificate pinning are not authorization boundaries (the server is) — the iOS echo of Phase 04 Chapter 10.

The iOS review surface (read the WARMUP)

Info.plist + entitlements  ->  what the app is allowed to do / reach
ATS                        ->  is network traffic forced over good TLS?
Data Protection + Keychain ->  is data encrypted at rest, and unlocked when?
URL schemes / Universal Links -> who can invoke the app, with what params?
pasteboard/screenshots/backups/logs -> the lifecycle leaks around the secure store

See WARMUP.md for the full from-zero treatment.

Labs

Pure Python (stdlib + pytest), lab.py/solution.py/test_lab.py/README.md each.

cd lab-01-ats-entitlements-analyzer
LAB_MODULE=solution pytest -q
pytest -q

Safety

Authorized-lab-only and offline; the labs reason over app configuration metadata. No device instrumentation, no App Store interaction, no targeting apps you don't own (Phase 00).

Warmup Guide — iOS and Apple Platform App Security from First Principles

Zero-to-expert primer for the iOS module. It builds what an app security engineer reviews in an iOS app, from the ground up: the app sandbox and Info.plist/entitlements, App Transport Security, the Data Protection classes and Keychain accessibility, URL schemes vs Universal Links, the data-lifecycle leaks (pasteboard/screenshots/backups/logs), privacy manifests and required-reason APIs, and why client-side checks (jailbreak detection, pinning) are not authorization. Builds on Phase 04 (mobile threat model) and Phase 05 (Apple OS internals). Authorized-lab-only, offline — analysis over app configuration metadata.

Table of Contents

• Chapter 1: The iOS App Threat Model
• Chapter 2: The Sandbox, Info.plist, and Entitlements
• Chapter 3: App Transport Security
• Chapter 4: Data Protection and the Keychain
• Chapter 5: URL Schemes, Universal Links, and IPC
• Chapter 6: The Data-Lifecycle Leaks
• Chapter 7: Privacy — Manifests, Required-Reason APIs, ATT
• Chapter 8: Why Jailbreak Detection and Pinning Are Not Authorization
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: The iOS App Threat Model

Zero background. iOS is a hardened platform (Phase 05): mandatory code signing (only signed code runs), a per-app sandbox, a hardware Secure Enclave, and TCC privacy consent. That raises the floor — but it does not secure your app's design. The app-security questions are the same as Phase 04, asked in Apple's terms:

• What can the app reach? — its entitlements and Info.plist declarations.
• How does it talk to the network? — App Transport Security (Chapter 3).
• How is data protected at rest, and when is it readable? — Data Protection classes + Keychain accessibility (Chapter 4).
• Who can invoke it, with what input? — URL schemes / Universal Links (Chapter 5).
• Where does data leak around the secure store? — pasteboard, screenshots, backups, logs (Ch 6).

The threats you assess (the parties). The app developer (your review target), Apple (the platform), the backend the app calls, and the user — and an attacker who may physically hold the device (lost/stolen phone) or run a jailbroken device they control (Chapter 8). A finding names the responsible party.

Misconception to kill now. "iOS is secure, so the app is secure." iOS secures the platform; an app can still ship secrets in plaintext, disable TLS, store data with weak protection, expose a hijackable URL handler, or trust the client for authorization. The platform is the floor, not the app.

Chapter 2: The Sandbox, Info.plist, and Entitlements

The sandbox. Each app runs in its own container with a private filesystem; it cannot read another app's data (Phase 05). Sharing is explicit, via App Groups (a shared container) and Keychain access groups — both gated by entitlements. The sandbox gives you isolation for free; everything the app reaches beyond it is a review item.

Info.plist — the app's declaration. The property list bundled with the app declares its configuration: supported URL schemes, the ATS policy (Chapter 3), required device capabilities, usage-description strings (NSCameraUsageDescription, etc. — required to even request a TCC permission), background modes, and more. It is the iOS analog of Android's manifest and your primary review artifact.

Entitlements — capabilities baked into the signature. An entitlement is a signed key/value granting a specific capability: Keychain access groups, App Groups, push, associated domains (for Universal Links), HealthKit, network extensions, and powerful debug ones. Because entitlements are part of the code signature, they can't be altered without breaking it. The review rule (Phase 05): every entitlement must map to a justified feature — minimize them. Dangerous ones to flag: get-task-allow (allows debugging — must be false in release), com.apple.security.cs.disable-library-validation (loads unsigned libraries), wildcard or over-broad associated domains, and broad Keychain access groups that share secrets too widely. A powerful entitlement is a finding only if unjustified or abusable (not automatically) — the same nuance as Phase 04's exported-components.

Misconception to kill now. "macOS/iOS apps can't be tampered with because they're signed." Signing binds the bundle to a developer and fixes the entitlements — but it says nothing about whether those entitlements are appropriate, whether the app disables TLS, or whether it stores secrets safely. Review the configuration, not just the signature.

Chapter 3: App Transport Security

What ATS is. App Transport Security is the iOS policy (declared in Info.plist) that forces network connections to use good TLS by default — HTTPS, TLS 1.2+, forward-secret ciphers, and valid certificates. It exists because apps historically shipped cleartext or weak-TLS connections, leaking data on hostile networks (Chapter 1's lost-phone / coffee-shop attacker).

The findings — ATS exceptions weaken it:

• NSAllowsArbitraryLoads = true — the big one: disables ATS globally, permitting cleartext HTTP and weak TLS app-wide. A serious finding unless tightly justified and scoped.
• Per-domain exceptions (NSExceptionDomains with NSExceptionAllowsInsecureHTTPLoads, NSExceptionMinimumTLSVersion lowered, NSExceptionRequiresForwardSecrecy = false) — narrower, but each is a hole; review the domain and the justification.
• NSAllowsLocalNetworking / NSAllowsArbitraryLoadsForMedia — scoped relaxations that still need review.

The right posture: ATS on, no global disable, exceptions only for specific justified domains, and Apple now requires a justification for NSAllowsArbitraryLoads at App Store review — but reviewers see apps ship it anyway.

Misconception to kill now. "We set NSAllowsArbitraryLoads to make development easier." That ships a production app that accepts cleartext and weak TLS everywhere. ATS exceptions must be specific, justified, and removed when not needed — like any security exception (Phase 03).

Chapter 4: Data Protection and the Keychain

Data Protection — file encryption tied to the lock state. iOS encrypts files with keys derived from the device key and the user passcode, and each file has a protection class controlling when its key is available:

• NSFileProtectionComplete — decryptable only while the device is unlocked; the key is evicted shortly after lock. Strongest; use for the most sensitive data.
• NSFileProtectionCompleteUntilFirstUserAuthentication (the default) — available after the first unlock following boot, until shutdown. A pragmatic default (background apps work after first unlock).
• NSFileProtectionCompleteUnlessOpen — can be created/written while locked (for files written by background tasks).
• NSFileProtectionNone — encrypted only with the device key, available even when locked (i.e., readable by anyone who extracts the device storage with the device locked). Sensitive data at None is a finding.

The Keychain — the place for secrets. Credentials, tokens, and keys belong in the Keychain (hardware-backed, per-item access control), not in UserDefaults, plist files, or app files. Each item has an accessibility attribute mirroring the protection classes:

• kSecAttrAccessibleWhenUnlocked — only while unlocked (strong).
• ...AfterFirstUnlock — after first unlock (common for background access).
• ...Always — deprecated and dangerous (readable while locked).
• the ...ThisDeviceOnly variants — not synced to iCloud / restored to a new device (use for device-bound secrets).
• plus access control flags binding an item to biometric/passcode (SecAccessControl with .userPresence / .biometryCurrentSet) and to the Secure Enclave (Phase 05).

Misconception to kill now. "We encrypted the token, so it's safe." If it's stored in UserDefaults/a plist, or in the Keychain with Always accessibility, or in a file at NSFileProtectionNone, it's exposed on a locked or backed-up device. Put secrets in the Keychain with WhenUnlocked (or biometric-gated) accessibility, and pick Complete protection for sensitive files.

Chapter 5: URL Schemes, Universal Links, and IPC

Custom URL schemes — the hijackable entry point. An app can register a scheme (myapp://pay?to=...) so other apps/web pages can launch it. The problem: any app can claim any custom scheme — there is no ownership proof — so a malicious app can register myapp:// and intercept links (or impersonate yours). And a URL handler is untrusted input from outside the app (Phase 04's deep-link lesson): its parameters must be validated, and it must never perform a sensitive action (a payment, a token exchange) without in-app confirmation and server-side authorization.

Universal Links — the secure alternative. A Universal Link is a regular https:// URL that opens your app if the app proves it owns the domain, via an apple-app-site-association (AASA) file served over HTTPS on that domain and the associated-domains entitlement. Because ownership is cryptographically/HTTPS-verified, another app cannot claim it — the iOS mirror of Android App Links. Prefer Universal Links for anything sensitive; treat custom schemes as untrusted and unowned.

Other IPC surfaces. App Groups (shared container — validate what you read from it), pasteboard (Chapter 6), document providers, share extensions, and the keyboard. Each is a boundary where data crosses between apps.

Misconception to kill now. "Our custom URL scheme is private to our app." Custom schemes have no ownership enforcement — any app can register the same scheme and intercept or spoof it. Use Universal Links (verified domain ownership) and validate every parameter as untrusted.

Chapter 6: The Data-Lifecycle Leaks

Even with perfect Data Protection and Keychain use, data leaks around the secure store — the same lifecycle lesson as Phase 04 Chapter 9:

• Pasteboard. The general UIPasteboard is system-wide and readable by other apps (and, pre-mitigation, synced across devices via Universal Clipboard). Copying a password/OTP/token to it leaks it. Use a named, non-persistent pasteboard for sensitive copies, set expirationDate, and mark items localOnly.
• Screenshots / app switcher. iOS snapshots your UI for the app switcher; a sensitive screen is captured to disk. Blur/obscure sensitive screens on willResignActive.
• Backups (iTunes/iCloud). App files and Keychain items may be backed up; secrets that shouldn't leave the device need the ...ThisDeviceOnly Keychain accessibility (not backed up/restored) and appropriate file-protection exclusion.
• Logs / crash reports / analytics. Logging tokens, PII, or full requests sends secrets to logs, crash services, and third-party SDKs. Never log sensitive data (Phase 00 minimization).
• Third-party SDKs. Ad/analytics SDKs can exfiltrate pasteboard, IDFA, and PII — a supply-chain and privacy risk (Chapter 7, Phase 14).

Misconception to kill now. "The secret is in the Keychain, so we're done." If the same secret is copied to the system pasteboard, captured in an app-switcher snapshot, included in a crash log, or backed up to iCloud via a synced Keychain item, the Keychain protection is moot. Secure the whole lifecycle.

Chapter 7: Privacy — Manifests, Required-Reason APIs, ATT

Apple has turned privacy into enforced configuration that an app-security/privacy reviewer checks:

• Usage-description strings. To request a TCC-gated resource (camera, location, contacts, photos, mic, tracking), the Info.plist must contain a purpose string (NS...UsageDescription). Missing string = the request crashes; vague/misleading string = a review and trust problem.
• Privacy manifests (PrivacyInfo.xcprivacy). A declaration of the data the app (and each bundled SDK) collects, the purposes, and the use of required-reason APIs — APIs (like accessing the file timestamp, UserDefaults, system boot time) historically abused for fingerprinting, which now require a declared approved reason. Undeclared use is rejected at App Store review.
• App Tracking Transparency (ATT). Cross-app/cross-site tracking (using the IDFA) requires explicit user opt-in via the ATT prompt; tracking without it violates policy.
• Privacy "nutrition labels." The App Store data-collection disclosure must match what the app actually does.

For a reviewer: confirm the declared collection matches reality, that bundled SDKs' manifests are present and honest, and that required-reason APIs are justified — privacy is now a compliance-tested property (Phase 15), not a promise.

Misconception to kill now. "Privacy is legal's problem." On iOS, privacy is enforced configuration: missing usage strings crash, undeclared required-reason APIs and SDK manifests fail review, and tracking without ATT violates policy. It's an engineering review item.

Chapter 8: Why Jailbreak Detection and Pinning Are Not Authorization

The iOS echo of Phase 04 Chapter 10. Jailbreak detection and certificate pinning run on the device the attacker controls:

• Jailbreak detection raises analysis cost (a speed bump) but is bypassable on a jailbroken device with hooking frameworks (Frida, objection, Liberty) that stub out the checks. It must never be the control standing between an attacker and your data.
• Certificate pinning hardcodes the expected server cert/key so the app rejects a mis-issued or intercepted cert — good defense-in-depth against TLS interception, but it protects the network link, not authorization, and can be removed on a controlled device. It also needs a rotation plan (backup pins) or it bricks the app on key rotation (Phase 04).

The load-bearing point: the security decisions that matter are server-side. The server must authorize every request and never trust client-side attestation alone (Apple's App Attest / DeviceCheck provides server-verifiable device integrity signals — stronger than client-side jailbreak detection, but still an input to a server decision, not a boundary by itself).

Misconception to kill now. "We detect jailbreak and pin certs, so the API is protected." Both run on the client and are bypassable; the API is protected only by server-side authorization that doesn't trust the client — the same conclusion as web (P02) and Android (P04).

Lab Walkthrough Guidance

Two labs turn the iOS review surface into runnable analysis (synthetic config metadata):

1. Lab 01 — ATS & Entitlements Analyzer. From Info.plist/entitlements metadata, flag NSAllowsArbitraryLoads and weak per-domain ATS exceptions, dangerous entitlements (get-task-allow, disable-library-validation, wildcard associated domains), and sensitive actions on custom URL schemes (Chapters 2–3, 5).
2. Lab 02 — Data-Protection & Privacy Evaluator. For each stored datum, check the Data Protection class / Keychain accessibility against its sensitivity, and flag pasteboard/backup/log leaks and undeclared required-reason APIs (Chapters 4, 6, 7).

LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

1. Review an Info.plist/entitlements set and flag the dangerous entries with justification.
2. Explain ATS and why NSAllowsArbitraryLoads is a finding.
3. Choose the right Data Protection class and Keychain accessibility for a datum and justify it.
4. Explain URL-scheme hijacking and why Universal Links are the secure alternative.
5. Enumerate the data-lifecycle leaks (pasteboard, screenshots, backups, logs, SDKs) and the fixes.
6. Explain privacy manifests, required-reason APIs, and ATT as enforced configuration.
7. Explain why jailbreak detection and pinning are not authorization, and where App Attest fits.

Common Mistakes

• Shipping NSAllowsArbitraryLoads (global ATS disable) from development into production.
• Storing secrets in UserDefaults/plist, or Keychain with Always accessibility, or files at NSFileProtectionNone.
• Using custom URL schemes (no ownership) for sensitive actions instead of Universal Links.
• Copying secrets/OTPs to the system pasteboard; not obscuring sensitive screens in the app switcher.
• Backing up device-bound secrets (not using ThisDeviceOnly); logging tokens/PII.
• Undeclared required-reason APIs or dishonest SDK privacy manifests; tracking without ATT.
• Treating jailbreak detection / pinning as the authorization boundary.

Interview Q&A

Q: Where should an iOS app store an auth token, and why not UserDefaults? A: In the Keychain, with kSecAttrAccessibleWhenUnlocked (or biometric-gated via SecAccessControl, Secure-Enclave-backed for keys), and ThisDeviceOnly if it must not sync/restore. UserDefaults is an unencrypted plist readable from a backup or a jailbroken device; the Keychain is hardware-backed with per-item access control tied to the lock state.

Q: What is ATS and what would you flag? A: App Transport Security forces HTTPS/TLS 1.2+/forward secrecy/valid certs by default. I'd flag a global NSAllowsArbitraryLoads = true (cleartext/weak TLS app-wide) first, then per-domain exceptions that allow insecure HTTP, lower the minimum TLS version, or disable forward secrecy — each needs a specific justification or removal.

Q: Custom URL scheme vs Universal Link? A: A custom scheme (myapp://) has no ownership enforcement — any app can register it and intercept or spoof your links — so it's untrusted input and unsafe for sensitive actions. A Universal Link is an https:// URL that opens your app only after domain ownership is proven via the apple-app-site-association file plus the associated-domains entitlement, so it can't be hijacked. Prefer Universal Links and validate every parameter regardless.

Q: Are jailbreak detection and pinning security controls? A: They're defense-in-depth, not boundaries — both run on a device the attacker controls and are bypassable (Frida/objection for jailbreak checks; pin removal on a controlled device). The real control is server-side authorization that never trusts the client; Apple's App Attest/DeviceCheck give a server-verifiable integrity signal, but it's an input to the server's decision, not a boundary itself.

References

• Apple: App Transport Security, Data Protection, Keychain Services, SecAccessControl, Universal Links / apple-app-site-association, Privacy Manifests / required-reason APIs, App Tracking Transparency, App Attest / DeviceCheck; the Apple Platform Security Guide.
• OWASP MASVS / MASTG (the iOS testing chapters); OWASP Mobile Top 10.
• Phase cross-references: P04 (mobile threat model, deep links, pinning), P05 (XNU, sandbox, TCC, Secure Enclave), P02 (TLS/identity), P14/P07 (SDK supply chain, privacy compliance).

iOS Lab 01 — ATS & Entitlements Analyzer

WARMUP: Chapters 2–3, 5 (sandbox/entitlements, ATS, URL schemes).

Threat model

An iOS app's Info.plist and entitlements declare what it can reach and how it talks to the network — and they're where reviewable misconfigurations hide: a global NSAllowsArbitraryLoads (cleartext/ weak TLS app-wide), a debuggable release (get-task-allow), library-validation disabled (loads unsigned code), a wildcard associated domain or broad Keychain group, and a sensitive action on a hijackable custom URL scheme. This engine turns that metadata into severity-ranked findings and a release gate.

What you build (lab.py)

• analyze(config) — ATS findings (global + per-domain insecure-HTTP / weak-TLS / no-FS), dangerous entitlements, wildcard associated domain, broad Keychain group, sensitive-action-on-custom-scheme; severity-sorted.
• is_release_safe(config) — no high-or-above (a release gate).

Attack cases the tests cover

• Clean config is release-safe; NSAllowsArbitraryLoads = high; a fully-weak per-domain exception yields insecure-http/weak-tls/no-fs; a TLS-1.3 exception is clean; get-task-allow and disable-library-validation = high; wildcard domain & broad Keychain = medium; sensitive-action on a custom scheme = high (but only when a scheme exists); severity-sorted.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Parse a real Info.plist/.entitlements (plist XML) instead of the dataclass.
• Add more entitlement checks (network extensions, keychain-access-groups breadth, push in dev).
• Flag App Store review blockers (missing usage-description strings for requested TCC resources).

Interview / resume

"Built an iOS configuration analyzer that flags ATS exceptions, debug/unsafe entitlements, wildcard associated domains, and sensitive actions on hijackable custom URL schemes — with a release gate on high-severity findings."

Limitations: analyzes config metadata (not a parsed binary/plist); rule set is the common high-value items, not exhaustive.

iOS Lab 02 — Data-Protection & Privacy Evaluator

WARMUP: Chapters 4, 6, 7 (Data Protection/Keychain, lifecycle leaks, privacy).

Threat model

A lost or stolen phone, a backup, or a curious other app. Even apps that "encrypt" data leak it by storing secrets in UserDefaults (plaintext plist), in the Keychain with Always accessibility (readable while locked), in files at NSFileProtectionNone, on the system pasteboard, in logs, or by syncing device-bound secrets to iCloud. Plus privacy obligations: undeclared required-reason APIs and tracking without ATT. This engine checks each stored datum against its sensitivity and checks the privacy posture.

What you build (lab.py)

• evaluate_item / evaluate_items — per-datum findings: plaintext-userdefaults (critical), on-system-pasteboard, keychain-always, file-protection-none, logged-secret (critical), synced-secret; non-sensitive data is ignored.
• privacy_check — undeclared required-reason APIs (medium) and tracking-without-ATT (high).
• is_safe — no item finding medium-or-above.

Attack cases the tests cover

• A token in the Keychain when-unlocked, device-only, is clean; the same secret in UserDefaults is critical, on the pasteboard / Always / NSFileProtectionNone is high, logged is critical, synced is medium.
• Non-sensitive data isn't flagged; an undeclared required-reason API and tracking without ATT are flagged (declared API / ATT-requested are clean); severity-sorted.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add SecAccessControl checks (biometric/Secure-Enclave-gated items) and per-class file-protection recommendations by data type.
• Detect screenshot/app-switcher exposure for sensitive screens.
• Parse a real PrivacyInfo.xcprivacy and bundled-SDK manifests; cross-check the App Store data labels.

Interview / resume

"Built an iOS data-protection evaluator that checks each datum's storage/protection/Keychain accessibility and sync against its sensitivity, flags pasteboard/log leaks, and checks privacy obligations (required-reason APIs, ATT) — encoding 'secure the whole data lifecycle, not just the store.'"

Limitations: metadata model (not a parsed app); the rule set is the common high-value protections; sensitivity classification is an input.

Privacy Engineering — A Module

What this is. Privacy as an engineering discipline, not a legal afterthought: data classification and inventory, data-flow mapping and minimization, lawful basis and purpose limitation, retention and deletion (DSARs / right-to-erasure), cross-border transfer, de-identification (anonymization vs pseudonymization, k-anonymity, differential privacy), and Privacy by Design. It turns GDPR/CCPA-style requirements into tested controls over data flows — the same "compliance as engineering" stance as Phase 15, applied to personal data.

Why it's its own module. Security protects data from unauthorized access; privacy governs authorized collection and use — should we hold this, for what purpose, how long, and can it be re-identified? Those are distinct questions with their own failure modes (over-collection, purpose creep, weak anonymization, illegal transfer) that the security phases don't cover.

Prerequisites. Phase 00 (data minimization, redaction), Phase 02 (crypto), Phase 15 (compliance as engineering). Everything is offline and reasons over data-flow and dataset metadata — no real personal data.

Learning Objectives

By the end you can, without notes:

1. Distinguish security vs privacy, and PII / sensitive PII / PHI / PCI and the obligations each triggers.
2. Map a data flow (collection → processing → storage → sharing → deletion) and apply data minimization and purpose limitation.
3. Explain lawful basis, retention limits, and DSAR / right-to-erasure, and detect violations (over-collection, over-retention, no lawful basis).
4. Reason about cross-border transfer restrictions (adequacy / safeguards).
5. Distinguish anonymization vs pseudonymization and measure re-identification risk with k-anonymity (and the ideas of l-diversity and differential privacy).
6. Apply Privacy by Design and DPIA thinking to a feature before it ships.

The privacy lens (read the WARMUP)

SECURITY asks: can an UNAUTHORIZED party access this data?
PRIVACY  asks: should we hold it at all? for what purpose? how long? can it be re-identified?
            collect minimum -> bind to a purpose -> retain briefly -> delete on request -> de-identify well

See WARMUP.md for the full from-zero treatment.

Labs

Pure Python (stdlib + pytest), lab.py/solution.py/test_lab.py/README.md each.

cd lab-02-k-anonymity-evaluator
LAB_MODULE=solution pytest -q
pytest -q

Safety

Offline; the labs reason over synthetic data-flow records and a synthetic dataset's quasi-identifiers. No real personal data, and the de-identification lab demonstrates measuring re-identification risk to prevent it (Phase 00 minimization).

Warmup Guide — Privacy Engineering from First Principles

Zero-to-expert primer for the Privacy Engineering module. It builds privacy as an engineering discipline: security vs privacy, the data taxonomy (PII/PHI/PCI), data-flow mapping and minimization, lawful basis and purpose limitation, retention and deletion (DSAR/erasure), cross-border transfer, de-identification (anonymization vs pseudonymization, k-anonymity, differential privacy), and Privacy by Design / DPIA. Builds on Phase 00 (minimization) and Phase 15 (compliance as engineering). Offline, over data-flow and dataset metadata — no real personal data.

Table of Contents

• Chapter 1: Security vs Privacy
• Chapter 2: The Data Taxonomy — PII, Sensitive PII, PHI, PCI
• Chapter 3: Data-Flow Mapping and Minimization
• Chapter 4: Lawful Basis, Purpose Limitation, and Retention
• Chapter 5: Subject Rights — DSAR and the Right to Erasure
• Chapter 6: Cross-Border Transfer
• Chapter 7: De-identification — Anonymization vs Pseudonymization
• Chapter 8: k-Anonymity, l-Diversity, and Differential Privacy
• Chapter 9: Privacy by Design and the DPIA
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Security vs Privacy

Zero background. They overlap but ask different questions. Security asks: can an unauthorized party access this data? (confidentiality, integrity, availability). Privacy asks: should we have this data at all, for what purpose, for how long, who do we share it with, and can the individual control it? You can be perfectly secure and badly violate privacy — e.g., an airtight database that collects far more than needed, keeps it forever, and sells it. Privacy engineering is the discipline of building systems that handle personal data appropriately, by design.

Why an engineer owns this. Privacy obligations (GDPR, CCPA/CPRA, HIPAA, and dozens of national laws) are requirement specifications that become tested controls over data flows — exactly the "compliance as engineering" stance of Phase 15, but the subject is personal data. The engineer maps the flows, enforces minimization and retention in code, builds the deletion pipeline, and proves it.

The relationship to security. Privacy needs security (you can't keep a deletion promise if an attacker copied the data), and security needs privacy (the less you collect and keep, the smaller the breach — data you don't have can't leak; Phase 00). They reinforce each other; neither replaces the other.

Misconception to kill now. "We encrypt it and restrict access, so privacy is handled." That's security. Privacy is also: did we have a lawful basis to collect it, is it the minimum needed for a stated purpose, are we keeping it only as long as necessary, can the person get it deleted, and is it truly de-identified if we claim so? An encrypted over-collection is still a privacy violation.

Chapter 2: The Data Taxonomy — PII, Sensitive PII, PHI, PCI

You can't govern what you haven't classified. The categories and what each triggers:

• PII (Personally Identifiable Information) — data that identifies a person directly (name, email, phone, government ID, account ID) or indirectly in combination (the quasi-identifiers of Chapter 8). GDPR's broader term is personal data: any information relating to an identifiable person (including IP address, device ID, cookies, location).
• Sensitive / special-category data — a higher-protection subset: health, biometrics, genetics, race/ethnicity, religion, sexual orientation, political views, precise geolocation, children's data. Processing it usually requires stronger lawful basis and controls.
• PHI (Protected Health Information) — health data under HIPAA (US) with specific safeguards.
• PCI (cardholder data) — payment card data under PCI DSS (Phase 15): a contractual regime where scope minimization (don't store the PAN; tokenize) is the central move.

Why classification drives everything. The category sets the lawful basis, retention, transfer rules, breach-notification thresholds, and de-identification bar. A data inventory ("data map") tagging every field with its category and purpose is the foundation control — and the input to Lab 01.

Misconception to kill now. "It's not PII, it's just an IP/device ID/cookie." Under GDPR those are personal data (identifiers that single out a person), and combinations of non-identifying fields (ZIP + birthdate + sex) re-identify individuals (Chapter 8). "Not PII" is a claim you must prove, not assume.

Chapter 3: Data-Flow Mapping and Minimization

Map the flow. For each piece of personal data, trace its lifecycle: collection (where it enters, with what consent) → processing (who/what uses it, for what) → storage (where, encrypted, how long) → sharing (processors, third parties, regions) → deletion (when, how, verified). You cannot govern, secure, or honor a deletion request for data whose flow you haven't mapped. This is the privacy analog of the Phase 03 data-flow diagram.

Data minimization — the core principle (and the highest-leverage control). Collect and keep the least data needed for the stated purpose, and no more. Minimization shrinks every downstream obligation and the breach blast radius simultaneously — data you don't have can't be breached, subpoenaed, or misused (Phase 00). Concretely: don't collect fields "just in case," don't log full request bodies with PII, don't copy production PII into analytics/dev, and drop data the moment its purpose is served.

Misconception to kill now. "Collect everything now; we might need it later." Speculative collection is a liability, not an asset: it expands consent, retention, transfer, and breach obligations and the attack surface, for data you may never use. Minimization is the cheapest privacy and security control.

Chapter 4: Lawful Basis, Purpose Limitation, and Retention

Lawful basis. Under GDPR, every processing of personal data needs a lawful basis — consent, contract, legal obligation, vital interests, public task, or legitimate interests. No basis = unlawful processing. (Consent must be freely given, specific, informed, and revocable — pre-ticked boxes don't count.)

Purpose limitation. Data collected for one stated purpose may not be silently repurposed. Collecting an email "to send your receipt" and then using it for marketing or selling it to a partner is purpose creep — a violation even though you "had" the data. Each new purpose needs its own basis.

Retention limitation. Keep personal data only as long as necessary for its purpose, then delete or anonymize it. "Keep forever" violates the storage-limitation principle. A retention schedule per data category, enforced by an automated deletion pipeline, is the control — and over-retention is a classic finding (Lab 01).

Misconception to kill now. "We have the data, so we can use it for X." Having data lawfully for one purpose doesn't authorize a new purpose, and it doesn't authorize keeping it past need. Lawful basis and purpose are per use, and retention is time-bounded.

Chapter 5: Subject Rights — DSAR and the Right to Erasure

Data Subject Rights. Privacy laws give individuals rights over their data: access (a DSAR — Data Subject Access Request: "give me everything you hold on me"), rectification, erasure ("right to be forgotten"), portability, restriction, and objection. These are engineering requirements: you must be able to find all of a person's data across every system (back to the data map, Chapter 3) and return or delete it within a legal deadline (e.g. ~30 days under GDPR).

Why erasure is hard (the engineering reality). "Delete the user" must reach every copy: primary DB, replicas, caches, search indexes, analytics warehouses, logs, backups, and third-party processors — and prove it. Data scattered without a map makes erasure impossible to honor, which is itself a violation. Backups are the classic snag (you can't always surgically delete from an immutable backup — the accepted practice is documented suppression on restore).

Misconception to kill now. "We deleted the row." Erasure means all copies — replicas, caches, indexes, analytics, logs, backups, and processors — verifiably, within the deadline. A row delete that leaves the data in five other stores is not erasure.

Chapter 6: Cross-Border Transfer

The restriction. Many regimes restrict moving personal data across borders. GDPR permits transfer out of the EEA only with a safeguard: an adequacy decision (the destination country is deemed to protect data adequately), Standard Contractual Clauses (SCCs), Binding Corporate Rules, or specific derogations. Transferring EU personal data to a non-adequate country with no safeguard is unlawful (the Schrems II ruling tightened this and invalidated Privacy Shield).

Why an engineer cares. Data residency and transfer are architecture decisions: where your databases, replicas, CDNs, analytics, and SaaS processors physically run determines whether a transfer is occurring. "Our analytics processor stores EU users' data in a non-adequate region without SCCs" is a real finding (Lab 01) — and data localization requirements (some countries mandate in-country storage) constrain your deployment topology.

Misconception to kill now. "Data in the cloud has no location." It always has a physical region, and routing EU personal data to a non-adequate region without a safeguard is an unlawful transfer. Region and processor choice is a privacy control.

Chapter 7: De-identification — Anonymization vs Pseudonymization

The crucial distinction. Both reduce identifiability, but the legal and technical line is sharp:

• Pseudonymization replaces identifiers with a token/key (e.g., a user_id instead of a name) but the mapping still exists somewhere, so the data can be re-linked. It is a strong security measure and reduces risk — but pseudonymized data is still personal data under GDPR (the obligations remain). Most "anonymized" datasets are really pseudonymized.
• Anonymization irreversibly removes the ability to identify anyone, such that re-identification is not reasonably possible — then the data falls outside personal-data law. True anonymization is hard, because removing the obvious identifiers is not enough: quasi-identifiers remain.

The re-identification trap (why "we removed names" fails). Latanya Sweeney showed that ~87% of Americans are uniquely identified by just {ZIP code, birth date, sex} — none of which is a "name." She re-identified the Massachusetts governor's medical record from a "de-identified" release by joining it with voter rolls. Netflix and AOL "anonymized" datasets were re-identified the same way. So anonymization must address the combination of quasi-identifiers (Chapter 8), not just direct identifiers.

Misconception to kill now. "We removed the names, so it's anonymous." Removing direct identifiers leaves quasi-identifiers (ZIP, birthdate, sex, job title, timestamps) that uniquely fingerprint people when combined or joined with another dataset. "Anonymized" is a measured property (Chapter 8), not "we deleted the name column."

Chapter 8: k-Anonymity, l-Diversity, and Differential Privacy

k-anonymity — measuring re-identification risk. A dataset is k-anonymous (with respect to its quasi-identifiers) if every record is indistinguishable from at least k−1 others on those quasi-identifiers — i.e., the smallest equivalence class (group of records sharing the same quasi-identifier values) has size ≥ k. k = 1 means at least one person is unique and trivially re-identifiable; higher k means each person hides in a crowd of k. You achieve it by generalization (ZIP 02138 → 021**, age 37 → 30–40) and suppression (dropping outlier records). Computing the minimum equivalence-class size = the achieved k is exactly Lab 02.

l-diversity — k-anonymity's blind spot. k-anonymity hides who you are but not necessarily your sensitive value: if all k records in your group share the same diagnosis, an attacker who locates your group learns your diagnosis anyway (a homogeneity attack). l-diversity requires each equivalence class to contain at least l distinct sensitive values. (t-closeness refines this further.)

Differential privacy — the modern, rigorous answer. Instead of transforming a dataset, DP adds calibrated noise to query results / aggregates so that the output is provably almost the same whether or not any single individual is in the data (the privacy loss is bounded by a parameter ε — smaller ε = more privacy, more noise). It gives a mathematical guarantee that k-anonymity can't, and underlies modern releases (US Census 2020, Apple/Google telemetry). The tradeoff is the privacy/accuracy budget.

Misconception to kill now. "k-anonymity makes it safe." k-anonymity bounds identity disclosure but not attribute disclosure (homogeneity → use l-diversity) and degrades as more quasi-identifiers or auxiliary datasets are added; for strong guarantees over queries, differential privacy is the rigorous tool.

Chapter 9: Privacy by Design and the DPIA

Privacy by Design (PbD). Build privacy in from the start, not bolted on: minimize collection by default, default to the most private setting, be transparent, give users control, and secure the lifecycle. It's the privacy sibling of "shift left" (Phase 03) — the cheapest place to fix a privacy problem is the design review, before any personal data is collected.

The DPIA (Data Protection Impact Assessment). For high-risk processing (large-scale sensitive data, profiling, monitoring), GDPR requires a DPIA: describe the processing and purpose, assess necessity and proportionality, identify risks to individuals, and define mitigations — the privacy analog of the Phase 03 threat model, producing decisions and a residual-risk record (not a checkbox).

Misconception to kill now. "We'll do a privacy review before launch." Bolting privacy on at the end means re-architecting (you already collected too much, in the wrong region, with no deletion path). PbD and the DPIA move the decision to design time, where it's cheap.

Lab Walkthrough Guidance

Four labs turn privacy into runnable analysis (synthetic metadata):

1. Lab 01 — PII Data-Flow Analyzer. Over data-flow records (field, category, purpose, lawful basis, retention, region, logged), flag over-collection (no purpose), no lawful basis, over-retention, PII in logs, and unsafe cross-border transfer (Chapters 2–6).
2. Lab 02 — k-Anonymity / Re-identification Evaluator. Over a dataset's quasi-identifier rows, compute the achieved k (smallest equivalence class), rate re-identification risk, check an l-diversity condition on a sensitive attribute, and distinguish anonymization from pseudonymization (Chapters 7–8).
3. Lab 03 — Differential Privacy. Implement the Laplace mechanism with count/bounded-sum sensitivity and clipping, an ε-budget with sequential composition, and randomized response — DP's per-query, auxiliary-data-proof guarantee (Chapter 8).
4. Lab 04 — k-Anonymity Generalization. Achieve a target k by raising quasi-identifier generalization levels and suppressing residual small classes — the privacy/utility tradeoff in code (Chapters 7–8).

LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

1. Explain security vs privacy and why an encrypted over-collection is still a violation.
2. Classify data (PII/sensitive/PHI/PCI) and say what each triggers.
3. Map a data flow and apply minimization and purpose limitation.
4. Explain lawful basis, retention limits, and the DSAR/erasure engineering challenge.
5. Explain cross-border transfer restrictions and why region/processor choice is a control.
6. Distinguish anonymization from pseudonymization and explain the quasi-identifier re-identification trap.
7. Compute k-anonymity, explain l-diversity's fix for homogeneity, and what differential privacy adds.

Common Mistakes

• Equating "secure" with "private" (encrypted over-collection is still a privacy violation).
• Collecting/retaining "just in case"; logging full PII; copying production PII to analytics/dev.
• Repurposing data beyond its collected purpose; no lawful basis; no retention schedule.
• "Deleting the row" but leaving copies in replicas/caches/indexes/analytics/backups/processors.
• Transferring personal data to a non-adequate region without SCCs/adequacy.
• Calling pseudonymized data "anonymous"; "we removed names" while quasi-identifiers re-identify people.
• Trusting k-anonymity against attribute disclosure (homogeneity) or strong query privacy (use l-diversity / DP).

Interview Q&A

Q: What's the difference between security and privacy? A: Security keeps unauthorized parties out (CIA). Privacy governs authorized collection and use — should we hold this, for what purpose, how long, shared with whom, and can the person control it? You can be secure and still violate privacy by over-collecting, repurposing, over-retaining, or transferring data — so privacy adds minimization, purpose limitation, retention, subject rights, and de-identification on top of security.

Q: Anonymization vs pseudonymization — why does it matter? A: Pseudonymization swaps identifiers for tokens but the re-linking mapping still exists, so the data is still personal data (obligations remain) — a security measure, not an exit from the law. Anonymization irreversibly prevents re-identification, so the data leaves personal-data scope — but it's hard, because removing names leaves quasi-identifiers (ZIP+birthdate+sex uniquely identify ~87% of Americans) that re-identify by joining with other datasets. Most "anonymized" data is really pseudonymized.

Q: What is k-anonymity and its limitation? A: A dataset is k-anonymous on its quasi-identifiers if every record shares those values with at least k−1 others — the smallest equivalence class has size ≥ k, so each person hides among k. You achieve it by generalizing and suppressing. Its limit is attribute disclosure: if everyone in your group shares the sensitive value (homogeneity), the attacker learns it anyway — that's what l-diversity fixes, and differential privacy gives a rigorous bounded guarantee over query results.

Q: A user invokes their right to erasure. What does "delete me" actually require? A: Finding all of their data across every system — primary DB, replicas, caches, search indexes, analytics/warehouse, logs, backups, and third-party processors — and deleting (or documented-suppressing for immutable backups) within the legal deadline, with proof. It's only feasible if you have a data map (every field, where it lives, why) — which is why minimization and inventory are prerequisites, not afterthoughts.

References

• GDPR (esp. Arts. 5, 6, 9, 17, 25, 35, Ch. V transfers); CCPA/CPRA; HIPAA; PCI DSS (Phase 15).
• Sweeney, "k-Anonymity" and the Massachusetts re-identification; Machanavajjhala et al., "l-Diversity"; Dwork, "Differential Privacy"; the Netflix Prize and AOL re-identification cases.
• NIST SP 800-122 (PII), NIST Privacy Framework; ENISA pseudonymization guidance; ISO/IEC 27701.
• Phase cross-references: P00 (minimization/redaction), P02 (crypto), P15 (compliance as engineering).

Privacy Lab 01 — PII Data-Flow Analyzer

WARMUP: Chapters 2–6 (taxonomy, data flows, lawful basis/retention, transfer).

Threat model

The "attacker" here is the organization's own data practices: collecting personal data with no purpose, no lawful basis, keeping it past need, writing it to logs, or shipping it to a non-adequate region without a safeguard. Each is a privacy violation independent of any breach. This engine turns a data-flow inventory into severity-ranked findings and a compliance gate.

What you build (lab.py)

• analyze_flow(flow) — for personal-category flows: over-collection (no purpose), no-lawful-basis, over-retention (per-category cap), pii-in-logs (critical for sensitive/PHI), unsafe-transfer.
• analyze(flows) — all findings, severity-sorted.
• is_compliant(flows) — no high-or-above.

Attack cases the tests cover

• A clean PII flow (purpose, lawful basis, short retention, EU, not logged) is compliant.
• Each violation is flagged at the right severity; sensitive/PHI in logs = critical; over-retention honors tighter per-category caps; a cross-border transfer is unsafe without a safeguard but fine with SCCs or to an adequate region; non-personal data is never flagged; severity-sorted.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add purpose-creep detection (a field used by more purposes than it was collected for).
• Generate a DSAR/erasure reachability report (every store holding a given subject's data).
• Model consent state and flag processing without active consent where consent is the basis.

Interview / resume

"Built a PII data-flow analyzer that flags over-collection, missing lawful basis, over-retention, PII in logs, and unsafe cross-border transfers from a data inventory — turning GDPR principles into a tested compliance gate."

Limitations: rule-based over a data-flow inventory; retention caps and adequate-region list are configurable inputs, not legal advice.

Privacy Lab 02 — k-Anonymity / Re-identification Evaluator

WARMUP: Chapters 7–8 (de-identification, k-anonymity, l-diversity, DP).

Threat model

"We removed the names, so it's anonymous" is the most common — and most wrong — privacy claim. Quasi-identifiers (ZIP + birthdate + sex uniquely identify ~87% of Americans) re-identify people by joining a "de-identified" dataset with another. The "attacker" is re-identification by linkage. This engine measures anonymity: it groups records into equivalence classes on their quasi-identifiers, computes the achieved k (smallest class), rates re-identification risk, and checks l-diversity (k-anonymity's homogeneity blind spot).

What you build (lab.py)

• equivalence_classes / k_anonymity / is_k_anonymous / num_unique — the core k-anonymity computation (achieved k = smallest equivalence class; uniques = trivially re-identifiable).
• reidentification_risk — high (k≤1) / medium (k<5) / low (k≥5).
• l_diversity / is_l_diverse — distinct sensitive values per class (catches homogeneity).
• describe_deidentification(has_mapping) — pseudonymized vs anonymization-candidate.

Attack cases the tests cover

• A dataset with unique quasi-identifier rows has k = 1 (high risk, uniques counted); a dataset where all rows share quasi-identifiers has k = N (lower risk).
• l-diversity catches the homogeneity attack: a k-anonymous group where everyone has the same sensitive value (e.g. all "HIV") has l = 1 — identity is hidden but the diagnosis is not.
• Pseudonymized (mapping exists) vs anonymization-candidate; empty-dataset edge case.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Implement generalization/suppression to achieve a target k (the Mondrian algorithm) and report the information loss.
• Add t-closeness (sensitive-value distribution close to the global one).
• Add a differential-privacy count query (Laplace noise for a chosen ε) and compare guarantees.
• Simulate a linkage attack against an auxiliary dataset to demonstrate re-identification.

Interview / resume

"Built a k-anonymity / re-identification evaluator that computes achieved k and l-diversity over a dataset's quasi-identifiers — demonstrating that 'removing names' isn't anonymization and that k-anonymity hides identity but not (without l-diversity) the sensitive attribute."

Limitations: measures k/l on given quasi-identifiers (doesn't choose them or generalize to reach a target); no differential privacy / linkage simulation in the core (left as extensions).

Privacy Lab 03 — Differential Privacy

WARMUP: Chapter 8 (k-anonymity, l-diversity, differential privacy).

The idea

k-anonymity (Lab 02) transforms a dataset and degrades as auxiliary data grows. Differential privacy (DP) instead adds calibrated noise to query results so the output is provably almost identical whether or not any single individual is in the data — a mathematical guarantee bounded by ε (smaller ε = more privacy, more noise). It underlies the US Census 2020 and Apple/Google telemetry. This lab implements the Laplace mechanism, sensitivity for counts and bounded sums (with clipping), sequential composition of an ε budget, and randomized response (local DP).

What you build (lab.py)

• laplace_scale(sensitivity, epsilon) = sensitivity/epsilon.
• laplace_mechanism(true_value, sensitivity, epsilon, noise_fn) — noise injectable for deterministic tests; smaller ε ⇒ larger noise.
• clamp, private_count (sensitivity 1), private_bounded_sum (clip to [lower,upper], sensitivity upper-lower).
• PrivacyBudget — sequential composition: ε's add, can't exceed the total.
• randomized_response(true_bit, first_coin, second_coin) — plausible-deniability local DP.

Cases the tests cover

• Scale math and rejection of bad ε/sensitivity; injected-noise mechanism; smaller ε ⇒ more noise; count sensitivity = 1; bounded-sum clipping and range sensitivity; budget composition and a budget-exceeded error; randomized response's truthful/coin-flip branches.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add the Gaussian mechanism and (ε, δ)-DP; add advanced composition.
• Add the exponential mechanism for non-numeric outputs.
• Build a small DP query API with per-analyst budgets and report the accuracy/privacy tradeoff.

Interview / resume

"Implemented the Laplace mechanism with count/bounded-sum sensitivity and clipping, an ε-budget with sequential composition, and randomized response — demonstrating DP's per-query, auxiliary-data-proof guarantee versus k-anonymity's dataset transformation."

Limitations: pure ε-DP with the Laplace mechanism (no Gaussian/(ε,δ), no advanced composition); noise is injectable for testing, so production use needs a vetted CSPRNG-backed sampler.

Privacy Lab 04 — k-Anonymity Generalization

WARMUP: Chapters 7–8 (de-identification, k-anonymity).

The idea

Lab 02 measured k-anonymity; this lab achieves a target k. Each quasi-identifier has a generalization hierarchy (level 0 = exact 02138; coarser levels 0213* → 021** → *). You raise the global generalization level until every equivalence class has ≥ k records, optionally suppressing records still stuck in too-small classes — the classic generalization/suppression tradeoff between privacy (higher k) and utility (less detail).

What you build (lab.py)

• equivalence_classes / k_anonymity — the grouping and achieved-k (self-contained).
• generalize_record / generalize — apply each QI's hierarchy at a level (capped per QI).
• max_level — the highest meaningful global level.
• generalize_to_k(records, hierarchies, k) — the smallest level reaching k (best-effort if k is unreachable).
• suppress_small_classes(records, qi, k) — drop records in classes < k; return (kept, suppressed).

Cases the tests cover

• Level 0 is all-unique (k=1); level-1 generalization produces the expected coarse values (non-QI fields untouched, order preserved); generalize_to_k finds the minimum level for k=2, fully collapses for k=4, and returns a best-effort max level when k is unreachable; suppression removes exactly the small-class records.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Implement Mondrian (multidimensional, per-partition generalization) instead of a uniform global level, and report information loss.
• Add a suppression budget (suppress up to X% rather than all small classes).
• Combine with Lab 02's l-diversity so generalization also guarantees sensitive-value diversity.

Interview / resume

"Built a generalization/suppression engine that achieves a target k-anonymity by raising quasi-identifier generalization levels and suppressing residual small classes — making the privacy/utility tradeoff explicit."

Limitations: uniform global generalization level (not per-partition Mondrian); no information-loss metric; hierarchies are supplied as callables.

Availability and Denial-of-Service Engineering — A Module

What this is. The "A" in CIA, treated as a first-class security discipline: the DoS/DDoS taxonomy (volumetric, protocol, application-layer), amplification/reflection, the mitigation stack (rate limiting, SYN cookies, anycast + scrubbing, CDN/WAF, autoscaling, load shedding), and the algorithms that bound load (token bucket, leaky bucket, sliding window). Availability failures are security failures — an attacker who can't read your data but can take you offline has still won.

Why it's its own module. Other phases mention "DoS" as a STRIDE letter or a rate-limit bullet, but never build the engineering of staying up under hostile load: how the attack classes differ, why each needs a different mitigation layer, and how a rate limiter actually works. This is core for any platform/SRE-adjacent security role.

Prerequisites. Phase 02 (network/HTTP), Phase 06/07 (isolation, cloud, egress). Everything is offline — the labs reason over attack-traffic descriptors and simulate a rate limiter deterministically. No traffic is generated; DoS testing against systems you don't own is illegal (Phase 00).

Learning Objectives

By the end you can, without notes:

1. Classify a DoS attack by layer (volumetric / protocol / application) and vector (SYN flood, UDP/DNS/NTP amplification, HTTP flood, Slowloris) and explain why each is cheap for the attacker.
2. Explain amplification/reflection and the amplification factor that makes small attackers huge.
3. Map each attack class to the right mitigation layer (you can't rate-limit your way out of a 400 Gbps volumetric flood; you can't anycast your way out of an app-layer logic bomb).
4. Implement and reason about rate-limiting algorithms — token bucket, leaky bucket, sliding window — including burst behavior and per-key isolation.
5. Explain load shedding, autoscaling-as-a-DoS-amplifier (denial of wallet), backpressure, and graceful degradation.
6. Distinguish DoS the security event from capacity/availability engineering and where they meet.

The availability lens (read the WARMUP)

VOLUMETRIC (L3/4)   overwhelm bandwidth/PPS        -> upstream: anycast + scrubbing + CDN
PROTOCOL  (L3/4)    exhaust connection state        -> SYN cookies, conn limits, stateless edges
APPLICATION (L7)    exhaust CPU/DB/threads cheaply   -> rate limiting, WAF, caching, load shedding
                    (Slowloris, expensive queries, denial of wallet)

See WARMUP.md for the full from-zero treatment.

Labs

Pure Python (stdlib + pytest), lab.py/solution.py/test_lab.py/README.md each.

cd lab-02-rate-limiter-simulator
LAB_MODULE=solution pytest -q
pytest -q

Safety

Offline; the labs classify attack descriptors and simulate a rate limiter over a synthetic request log. No traffic generation, no testing against systems you don't own (Phase 00).

Warmup Guide — Availability and Denial-of-Service Engineering from First Principles

Zero-to-expert primer for the Availability/DoS module. It builds the "A" in CIA as a discipline: why availability is security, the DoS/DDoS taxonomy (volumetric, protocol, application), amplification/ reflection, the layered mitigation stack, the rate-limiting algorithms (token bucket, leaky bucket, sliding window), and graceful degradation / denial of wallet. Builds on Phase 02 (network) and Phase 06/07 (isolation, cloud). Offline — analysis over attack descriptors and a simulated limiter; no traffic generation (Phase 00).

Table of Contents

• Chapter 1: Availability Is Security
• Chapter 2: The DoS / DDoS Taxonomy
• Chapter 3: Amplification and Reflection
• Chapter 4: Application-Layer DoS and Asymmetric Work
• Chapter 5: The Mitigation Stack — Match the Layer
• Chapter 6: Rate-Limiting Algorithms
• Chapter 7: Graceful Degradation, Load Shedding, and Denial of Wallet
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Availability Is Security

Zero background. The classic security triad is C-I-A — Confidentiality, Integrity, Availability. A Denial of Service (DoS) attack targets the third: it doesn't steal or alter data, it makes the system unavailable to legitimate users. An attacker who can't read your database but can keep your service offline during a product launch, an election, or a trading window has inflicted real damage — sometimes more than a data leak. Distributed DoS (DDoS) is the same attack from many sources (a botnet — often compromised IoT devices, Chapter 8 of the Wireless module — or a booter/stresser service rented for dollars), which makes it both more powerful and harder to filter by source.

Why it's an engineering discipline, not just "buy DDoS protection." Different attacks exhaust different resources (bandwidth, connection state, CPU, database, money), and each requires a different mitigation at a different layer (Chapter 5). Throwing a CDN at an application-logic DoS, or rate-limiting a 400 Gbps volumetric flood, fails. The skill is diagnosing which resource is being exhausted and applying the matching control.

The asymmetry that defines DoS. The attacker wins when their cost to send is far less than your cost to process. Amplification (Chapter 3) and asymmetric work (Chapter 4) are both ways of widening that gap. Good availability engineering narrows it — make rejecting bad traffic cheap and make expensive work require proven legitimacy.

Misconception to kill now. "DoS isn't a real security issue — nothing gets stolen." Availability is one third of the security model; a successful DoS can cause more business harm than a breach, and DoS is frequently used as a smokescreen to distract responders during a real intrusion. It is squarely a security concern.

Chapter 2: The DoS / DDoS Taxonomy

Three classes by which resource they exhaust — memorize this, because it dictates the mitigation:

• Volumetric (L3/L4). Saturate bandwidth or packets-per-second with sheer volume — UDP floods, ICMP floods, amplified reflection (Chapter 3). Measured in Gbps/Mpps; the largest hit terabits per second. Your link/edge is full before traffic even reaches your app. Only upstream capacity (a scrubbing provider, anycast, a CDN) can absorb it — you cannot fix it on your origin server.
• Protocol / state-exhaustion (L3/L4). Exhaust a finite state table rather than bandwidth. The classic is the SYN flood: the attacker sends TCP SYNs but never completes the handshake, filling the server's half-open-connection table so legitimate handshakes are refused. Also: ACK floods, connection-table and load-balancer exhaustion. Cheap in bandwidth, deadly to state.
• Application-layer (L7). Make the application do expensive work with few, valid-looking requests — an HTTP flood of real requests, Slowloris (hold many connections open by sending headers one byte at a time), or hitting an expensive endpoint (a heavy search, an unbounded export, a costly regex — ReDoS). These blend with legitimate traffic, so volume-based filtering misses them; you need application awareness (Chapter 4).

Misconception to kill now. "DDoS means a huge traffic flood." Only the volumetric class is about volume. A Slowloris or an expensive-query L7 attack can take down a server with trivial bandwidth from a single host — low and slow, not big and loud.

Chapter 3: Amplification and Reflection

The mechanism. Reflection spoofs the victim's IP as the source of requests to third-party servers, so the responses flood the victim (who never sent anything). Amplification picks protocols where the response is much larger than the request, multiplying the attacker's bandwidth.

The amplification factor is response-size ÷ request-size. The notorious reflectors:

• DNS (~28–54×), NTP monlist (~556×), memcached (up to ~51,000× — the 1.3 Tbps GitHub 2018 attack), SSDP, CLDAP, SNMP. A small attacker with a spoofable upstream becomes a terabit cannon.

Why it works (the root cause). Two enablers: UDP (connectionless, so the source IP is trivially spoofed — no handshake to prove you are who you claim) and open, abusable services that answer unauthenticated queries with large responses. The defenses are systemic: BCP 38 / source-address validation (ingress filtering) by ISPs to stop spoofed packets leaving a network, and closing/ securing the reflector services (don't expose monlist, memcached, open resolvers to the internet). For the victim, only upstream scrubbing/anycast (Chapter 5) absorbs the resulting flood.

Misconception to kill now. "We just need to block the attacking IPs." In a reflection attack the source IPs are innocent third-party servers (and spoofed), not the attacker — blocking them blocks legitimate services and never reaches the real attacker. The fix is upstream absorption plus the internet-wide hygiene of anti-spoofing and closed reflectors.

Chapter 4: Application-Layer DoS and Asymmetric Work

The core idea: asymmetric work. L7 DoS exploits any place where a cheap request triggers expensive processing — the attacker spends a little, you spend a lot:

• Slowloris / slow-read. Open many connections and trickle data so each ties up a worker thread indefinitely; a few thousand connections exhaust a thread-per-connection server with almost no bandwidth. Fix: connection timeouts, limits per IP, and async/event-driven servers.
• Expensive endpoints. A search with no result cap, an export of the whole table, an unindexed query, a zip-bomb upload, image resizing, or crypto operations — one request burns seconds of CPU or a DB connection. Fix: pagination/limits, query budgets, caching, and authentication before expensive work.
• ReDoS (regular-expression DoS). A "catastrophic backtracking" regex on attacker input takes exponential time ((a+)+$ against aaaa...!). Fix: linear-time regex engines (RE2), input length caps, timeouts.
• Algorithmic complexity attacks. Inputs crafted to hit a data structure's worst case (hash collisions → O(n²); the reason languages randomize hash seeds).
• Amplification within your app: one API call that fans out to many backend calls, or a cache-busting pattern that forces origin work (the cousin of web cache poisoning, P02).

The defining property: L7 attacks use valid-looking, low-volume requests, so source/volume filtering misses them. You need application awareness — rate-limit by user/endpoint, bound the work per request, require auth before the expensive path, and shed load (Chapter 7).

Misconception to kill now. "Our autoscaler will handle the load." Autoscaling against an L7 attack just scales your bill (denial of wallet, Chapter 7) and your database connections while the attacker spends pennies. Bound the expensive work and require legitimacy; don't buy your way through asymmetry.

Chapter 5: The Mitigation Stack — Match the Layer

The one rule: the mitigation must match the attack's layer. A control for one class does nothing for another.

Cross-cutting controls: anycast (the same IP announced from many locations so an attack is diluted and absorbed near its source), always-on vs on-demand DDoS protection, generous upstream capacity headroom, and an incident runbook (who declares, who engages the scrubbing provider, how you communicate). Architecturally, statelessness at the edge and isolation/segmentation (P06/P07) limit how far an attack propagates.

Misconception to kill now. "We have a WAF/CDN, so we're protected from DDoS." A CDN/WAF helps with L7 and cacheable volumetric, but a non-cacheable volumetric flood needs scrubbing/anycast capacity, and a protocol flood needs SYN cookies/state limits. There is no single box; you defend per layer.

Chapter 6: Rate-Limiting Algorithms

Rate limiting is the workhorse L7 control: cap how many requests a client (key) may make per unit time, rejecting or queuing the excess. The algorithms (and their tradeoffs):

• Fixed window. Count requests per key per fixed interval (e.g. per minute); reset at the boundary. Simple, but allows a 2× burst at the boundary (max requests at the end of one window + the start of the next).
• Sliding window. Smooths the boundary burst by weighting the previous window or tracking timestamps over a rolling interval. More accurate, slightly more state.
• Token bucket (the most common). A bucket holds up to capacity tokens and refills at rate tokens/sec; each request consumes a token; if the bucket is empty, the request is limited. This allows controlled bursts (up to capacity) while bounding the sustained rate to rate — the behavior most APIs want. (Lab 02 implements this.)
• Leaky bucket. Requests enter a queue that drains at a fixed rate; it smooths output to a constant rate (no bursts) — good for protecting a downstream that needs steady input.

The engineering details that matter: rate-limit per key (per user / API key / IP — and beware that IP is shared/spoofable and NAT groups many users), isolate keys so one abuser doesn't starve others, make the limiter distributed (a shared store) so it holds across many servers, and return 429 Too Many Requests with a Retry-After. Rate limiting is also a security control beyond DoS: it throttles credential stuffing, brute force, scraping, and enumeration.

Misconception to kill now. "A fixed per-minute counter is good enough." Fixed windows permit a near- 2× burst across the boundary, and a single global counter lets one client starve everyone. Token bucket (controlled bursts, sustained-rate bound) with per-key isolation is the usual right answer.

Chapter 7: Graceful Degradation, Load Shedding, and Denial of Wallet

Load shedding. When overloaded, deliberately drop or reject low-priority work to keep the core serving — return 503 fast for non-critical endpoints, prioritize authenticated/paying users, and fail fast rather than letting every request pile up and time out (which collapses everything). Shedding load is choosing who to disappoint instead of failing for everyone.

Backpressure and graceful degradation. Propagate "I'm full" upstream (bounded queues, timeouts, circuit breakers — P01/P11 bounded-concurrency lesson) so callers slow down instead of overwhelming a struggling dependency. Degrade gracefully: serve stale cache, disable expensive features, show a lightweight page — partial service beats total outage.

Denial of Wallet (the cloud-era DoS). In autoscaling/serverless, an attacker can't take you down (you scale) — instead they run up an enormous bill, or exhaust a quota, or drain a third-party API budget (the AI-agent "denial of wallet" of P11). The defenses are budgets and caps: max autoscale limits, per-tenant quotas, spend alerts, and — again — rate limiting and auth-before-expense.

The whole-picture lesson. Availability under attack is a system property: upstream capacity for volumetric, stateless edges for protocol, rate limits + work budgets + auth for L7, and load shedding + backpressure + budgets so that when you are overwhelmed you degrade predictably instead of collapsing — and you don't bankrupt yourself scaling against an attacker who spends nothing.

Misconception to kill now. "Scale up until the attack stops." Against asymmetric L7 or a volumetric flood, scaling converts a downtime problem into a bankruptcy problem (denial of wallet) and often just moves the bottleneck to the database. Caps, shedding, and matched-layer mitigation — not unlimited scaling — are the answer.

Lab Walkthrough Guidance

Three labs turn availability into runnable engineering (offline):

1. Lab 01 — DDoS Classification & Mitigation Planner. From an attack descriptor (layer, vector, rate, amplification, spoofed, cacheable), classify it and recommend the correct mitigation layer — and reject mismatched ones (you can't rate-limit a volumetric flood). Chapters 2–5.
2. Lab 02 — Rate-Limiter Simulator. Implement a deterministic token-bucket limiter (capacity + refill rate) with per-key isolation and a sliding-window variant; verify it bounds the sustained rate, allows bursts up to capacity, and isolates keys. Chapter 6.
3. Lab 03 — Rate-Limiter Variants. Add the fixed-window and leaky-bucket algorithms and demonstrate the fixed-window boundary burst (≈2× the nominal rate) that a naive counter allows — the algorithm tradeoffs in code (Chapter 6).

LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

1. Classify a DoS attack by layer and vector and explain the attacker's asymmetric advantage.
2. Explain amplification/reflection, the amplification factor, and why blocking source IPs fails.
3. Explain L7 / asymmetric-work attacks (Slowloris, expensive endpoints, ReDoS) and why volume filtering misses them.
4. Match each attack class to the mitigation layer that actually works (and why a CDN ≠ full DDoS protection).
5. Implement and compare token-bucket, leaky-bucket, fixed- and sliding-window rate limiting, with per-key isolation.
6. Explain load shedding, backpressure, graceful degradation, and denial of wallet.

Common Mistakes

• Treating DoS as "not real security," or ignoring that it's used as a smokescreen for intrusion.
• Trying to fix a volumetric flood on the origin (it needs upstream scrubbing/anycast).
• Blocking the source IPs of a reflection attack (they're innocent/spoofed third parties).
• Assuming a CDN/WAF covers all DDoS (it doesn't cover non-cacheable volumetric or protocol floods).
• Fixed-window rate limits (boundary burst) and a single global counter (one client starves all).
• Autoscaling against an attack (denial of wallet) instead of caps, shedding, and matched mitigation.
• No load shedding / backpressure, so overload collapses everything instead of degrading.

Interview Q&A

Q: Classify DDoS attacks and match each to a mitigation. A: Volumetric (L3/4 — saturate bandwidth/PPS, often amplified): only upstream anycast/scrubbing/CDN absorbs it — you can't fix it on the origin. Protocol (L3/4 — exhaust state, e.g. SYN flood): SYN cookies, connection limits, stateless edges. Application (L7 — asymmetric work, e.g. Slowloris, expensive queries): rate limiting, WAF, caching, work budgets, auth-before-expense, load shedding. The rule is match the mitigation to the layer; a CDN doesn't stop a protocol flood and SYN cookies don't stop an expensive-query L7 attack.

Q: How does amplification work and why can't you just block the attacking IPs? A: The attacker spoofs the victim's IP as the source of small queries to open UDP services (DNS, NTP monlist, memcached at ~51,000×), and the large responses flood the victim. The "sources" are innocent third-party reflectors (and spoofed), so blocking them blocks legitimate services and never reaches the attacker. Real fixes are systemic — BCP 38 source-address validation by ISPs and closing open reflectors — plus upstream scrubbing for the victim.

Q: Implement a token-bucket rate limiter and explain its advantage. A: A bucket holds up to capacity tokens, refilling at rate/sec; each request takes a token, and an empty bucket means limited. It bounds the sustained rate to rate while allowing controlled bursts up to capacity — what most APIs want — unlike a fixed window (which permits a ~2× boundary burst) or a leaky bucket (which forbids bursts entirely). I'd key it per user/API key, isolate keys, back it with a shared store for distributed enforcement, and return 429 with Retry-After.

Q: An autoscaling service is under an L7 attack — what do you do? A: Don't just scale (that's denial of wallet — you pay, the attacker doesn't, and the DB becomes the bottleneck). Rate-limit per key, require auth before expensive paths, cap autoscale and per-tenant quotas, shed low-priority load (503 fast), cache what's cacheable, put a WAF/bot filter in front, and engage scrubbing if there's a volumetric component. Bound the asymmetric work; don't buy through it.

References

• Cloudflare/Akamai/AWS DDoS taxonomy and "Learning Center" articles; the GitHub 2018 memcached 1.3 Tbps and Dyn 2016 (Mirai) incidents.
• BCP 38 / RFC 2827 (ingress filtering / source-address validation); SYN cookies (Bernstein).
• Rate-limiting: token bucket / leaky bucket; the "sliding window" approaches; RE2 (linear-time regex).
• Google SRE Book (load shedding, graceful degradation, cascading failures); Phase cross-refs: P02 (network/HTTP), P06/P07 (isolation, cloud, egress), P11 (denial of wallet).

DoS Lab 01 — DDoS Classification & Mitigation Planner

WARMUP: Chapters 2–5 (taxonomy, amplification, mitigation stack).

Threat model

A DoS takes you offline; the failure mode this lab targets is applying the wrong mitigation — trying to rate-limit a 400 Gbps volumetric flood, blocking the (innocent, spoofed) source IPs of a reflection attack, or assuming a CDN covers a protocol flood. This engine classifies an attack by vector → layer, recommends the matching mitigation, evaluates a proposed plan, and answers whether blocking source IPs would even help.

What you build (lab.py)

• classify(attack) → {layer, recommended} (protocol / volumetric / application).
• recommend(attack) → the matching mitigations.
• evaluate_plan(attack, chosen) → {effective, ineffective, missing} — catches mismatched controls.
• would_blocking_sources_help(attack) → False for spoofed/amplified reflection.

Attack cases the tests cover

• Layers classified per vector; rate-limiting is ineffective against a volumetric amplification attack (and the correct anycast/scrubbing shows as missing); a correct SYN-flood plan is effective; partial plans report what's missing; blocking source IPs is useless for spoofed/amplified reflection but can help for an L7 flood from real clients.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Recommend by combined signal (rate + cacheable + spoofed), not just vector.
• Add a cost/SLA model (when to engage always-on vs on-demand scrubbing).
• Produce an incident runbook step list per classification.

Interview / resume

"Built a DDoS classification and mitigation planner that maps each attack class to the mitigation layer that actually works and flags mismatches — encoding that you can't rate-limit a volumetric flood or block the spoofed sources of a reflection attack."

Limitations: rule-based over attack descriptors; the vector→mitigation table is representative, not exhaustive.

DoS Lab 02 — Rate-Limiter Simulator

WARMUP: Chapter 6 (rate-limiting algorithms).

The problem

Rate limiting is the workhorse application-layer availability control — and a defense against credential stuffing, brute force, scraping, and enumeration. The failure modes are subtle: a fixed-window counter permits a ~2× boundary burst, and a single global counter lets one client starve everyone. This lab implements the algorithm most APIs actually want — a token bucket (bounds the sustained rate while allowing controlled bursts) — plus a sliding-window limiter, both with per-key isolation. Time is supplied, so behavior is deterministic and testable.

What you build (lab.py)

• TokenBucketLimiter(capacity, refill_rate) — allow(key, now) and tokens(key, now): refill to now, consume a token if available, cap at capacity.
• SlidingWindowLimiter(limit, window) — allow(key, now): at most limit requests in any trailing window seconds.
• simulate(limiter, events) — run (key, time) events and return the allow/deny decisions.

Attack cases the tests cover

• Token bucket: a full bucket allows a burst of capacity, then denies; tokens refill over time; they cap at capacity (not unbounded after idle); the sustained rate is bounded to refill_rate; one key's exhaustion doesn't affect another (per-key isolation).
• Sliding window: limits within the window and frees requests once they age out; per-key.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add fixed-window and leaky-bucket variants and compare boundary-burst behavior.
• Make it distributed (a shared store) and discuss atomicity (the P02 web-race lesson).
• Return 429 + Retry-After semantics and a per-tenant quota tier.
• Add cost-weighted requests (an expensive endpoint consumes more tokens).

Interview / resume

"Implemented token-bucket and sliding-window rate limiters with per-key isolation — bounding the sustained rate while allowing controlled bursts — the core L7 availability and anti-abuse control, and explained why fixed-window/global counters fail."

Limitations: in-memory single-process simulation with supplied time (not a distributed, wall-clock implementation); the leaky-bucket/fixed-window variants are left as extensions.

DoS Lab 03 — Rate-Limiter Variants

WARMUP: Chapter 6 (rate-limiting algorithms). Extends: Lab 02 (token bucket).

The idea

Lab 02 built a token bucket. This implements the other classic algorithms and demonstrates the failure mode each one fixes or exhibits: a fixed window is simple but permits a ~2× burst across the window boundary; a leaky bucket smooths output to a constant drain rate (no bursts at all). Knowing the tradeoffs — and that a naive fixed-window counter lets a client send double the nominal rate around the boundary — is the point.

What you build (lab.py)

• FixedWindowLimiter(limit, window) — per-key count per fixed bucket; resets at the boundary.
• LeakyBucketLimiter(capacity, leak_rate) — leak-then-admit; smooths to a constant rate.
• boundary_burst_demo(limit, window) — returns the allowed count (≈ 2*limit) when sending limit at the end of one window and limit at the start of the next — the fixed-window flaw, made visible.

Cases the tests cover

• Fixed window limits within a window and resets at the next; boundary burst = 2×limit; per-key.
• Leaky bucket caps at capacity, leaks over time, and smooths to the leak rate (one/sec sustainable, two within an instant not); per-key.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q
pytest -q

Hardening / extensions

• Add a sliding-window-counter (weighted previous window) that fixes the boundary burst cheaply.
• Compare all four algorithms (token/leaky/fixed/sliding) on the same request trace and report the effective admitted rate.
• Make them distributed (shared store) and discuss atomicity (the P02 web-race lesson).

Interview / resume

"Implemented fixed-window and leaky-bucket rate limiters and demonstrated the fixed-window 2× boundary burst — completing the token-bucket picture and explaining when to use each algorithm."

Limitations: in-memory, single-process, supplied-time simulation; sliding-window-counter left as an extension.

Phase 00 - Safety, Ethics, Legal Boundaries, and Lab Operations

Duration: 4 weeks (Month 1)
Objective: become a trustworthy operator before acquiring offensive capability.

Exit Standard

You can reject an unsafe request, prove authorization, isolate an exercise, preserve evidence, handle private data, escalate a critical finding, and explain responsible disclosure. Your lab must pass the acceptance test in ../templates/lab-acceptance-checklist.md.

Learning Path

Beginner

• White, black, gray, red, blue, green, and purple team terminology; why labels never replace authorization.
• Computer misuse, contract, privacy, export, workplace, and sector-specific constraints at a conceptual level. Obtain qualified legal advice for real engagements.
• Scope, rules of engagement, safe harbor, data minimization, need-to-know, and conflicts of interest.

Intermediate

• Vulnerability disclosure and VRP lifecycle; duplicates, severity disputes, embargoes, and publication permission.
• Evidence provenance, UTC timelines, hashing, chain of custody, redaction, retention, and secure destruction.
• Safe malware handling: inert fixtures first, isolated networks, snapshots, no shared folders, no clipboard, no host credentials, and controlled sample transfer.

Advanced

• Design a research environment whose failure modes are contained.
• Lead go/no-go review, critical-finding escalation, incident conversion, and executive status.
• Resolve ambiguous scope by stopping and obtaining written clarification.

Required Theory

• Read the policies of three major VRPs and compare scope, prohibited testing, data handling, automation, and disclosure terms.
• Read NIST SP 800-61 incident-handling preparation sections and NIST SP 800-86 evidence concepts.
• Study local organizational policies and the laws applicable to the learner's jurisdiction.

Labs

Runnable lab portfolio

1. Engagement Guard and Evidence Verifier: scope drift, prohibited techniques, ceilings, stop conditions, and evidence tampering.
2. Range Containment Verifier: required telemetry paths and forbidden LAN, internet, OT, and management reachability.
3. Evidence Redaction Pipeline: sanitized reporting with deterministic transformation counts.

Read WARMUP.md before implementing it and use HITCHHIKERS-GUIDE.md to build and harden the range.

Capstone - Security Research Operating Manual

Deliver:

• legal/ethical operating rules and refusal policy;
• lab architecture and data-flow diagram;
• installation and version inventory;
• authorization, evidence, triage, disclosure, and incident-conversion procedures;
• backup, snapshot, reset, teardown, and cloud-cost controls;
• a 10-minute go/no-go briefing.

Tools

Git, age or GPG for encrypted artifacts, SHA-256 tooling, virtualization platform, host firewall, Docker/Podman, kind/k3d, Android Studio, Wazuh/OpenSearch or equivalent, Wireshark, Sysmon, auditd.

Evaluation Checklist

• Every segment has a documented purpose and default-deny boundary.
• A test from each lab host proves prohibited routes fail.
• No real secret or personal data exists in the repository.
• Evidence survives transfer with matching hashes.
• ROE names allowed methods, exclusions, rates, time, contacts, and stop conditions.
• The learner stops and escalates during an injected scope ambiguity.

Common Mistakes

• Treating public reachability as authorization.
• Using a VPN, disclaimer, or VM as a substitute for scope.
• Allowing vulnerable images to retain internet or LAN access.
• Capturing excessive data and calling it "evidence."
• Publishing before the owner authorizes disclosure.

Interview Questions

1. What would make you stop an assessment immediately?
2. How do you preserve evidence while minimizing personal data?
3. A client verbally asks you to test an asset absent from the signed scope. What do you do?
4. When does a security assessment become an incident response engagement?
5. Explain responsible disclosure to an executive who wants immediate publication.

Portfolio and Stretch

Publish sanitized templates and the architecture, never raw evidence. Stretch work: add infrastructure-as-code for the local range, automatic egress tests, encrypted evidence indexing, and a tabletop involving accidental third-party data.

Warmup Guide — Authorization, Containment, and Evidence from First Principles

Zero-to-expert primer for Phase 00. Read this before the labs. It builds every concept the phase depends on — authorization as data, scope as machine-checkable policy, network isolation, evidence provenance, responsible disclosure, and the legal frame — from the ground up, assuming only basic programming. By the end you should be able to refuse an unsafe request and name the exact reason, prove a lab is contained, and preserve evidence that survives scrutiny. Security capability without this discipline is not a junior version of the job; it is a liability.

Table of Contents

• Chapter 1: Why a Safety Phase Comes First
• Chapter 2: The Legal Ground — What the Law Actually Prohibits
• Chapter 3: Authorization Is Data, Not a Vibe
• Chapter 4: Scope as a Machine-Checkable Policy
• Chapter 5: Stop Conditions and Incident Conversion
• Chapter 6: Network Isolation from First Principles
• Chapter 7: Evidence, Hashing, and Provenance
• Chapter 8: Privacy, Data Minimization, and Redaction
• Chapter 9: Safe Handling of Malware and Dangerous Fixtures
• Chapter 10: Responsible Disclosure and the VRP Lifecycle
• Chapter 11: The Hat Taxonomy and Why Labels Never Grant Permission
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Why a Safety Phase Comes First

Zero background. A security engineer's daily work overlaps mechanically with the work of an attacker: you send unexpected input, you probe authorization, you read memory you were not meant to read, you handle malicious files. The single difference between a professional and a criminal is not skill — it is authorization, containment, and discipline. Those three are the load-bearing walls of the entire role. A vulnerability researcher who cannot prove they were authorized, who contaminates the host they were testing from, or who leaks a victim's personal data while writing a report has done net harm regardless of how clever the finding was.

Why it exists. Every later phase in this curriculum hands you a sharper tool: fuzzers (Phase 08), container-escape primitives (Phase 06), Android instrumentation (Phase 04), cloud IAM attack-path analysis (Phase 07), AI agents that can take actions (Phase 11). Each of those is dual-use. Phase 00 installs the reflexes that make the rest safe to learn. You build the muscles that fire automatically: Am I authorized? Is this contained? Is my evidence sound? Should I stop? When those questions are automatic, the offensive tooling that follows is an engineering instrument rather than a hazard.

How it connects to production. At a top-tier security team, you will not be trusted with production access, red-team scope, or a VRP queue until you demonstrate exactly the behaviors this phase teaches. The "operating manual" capstone is not busywork — a real engagement begins with a rules-of-engagement document, a contained environment, an evidence plan, and a stop-condition list. Interviewers probe this directly: the fastest way to fail a security interview is to answer "the client asked me to test an asset not in scope" with anything other than "I stop and get it in writing."

Misconception to kill now. "Safety is the boring part before the real hacking." Inverted. The real differentiator at the staff/principal level is judgment under ambiguity — and judgment is exactly what this phase trains. Anyone can run a scanner. Few can be trusted to run one against a system that matters.

Chapter 2: The Legal Ground — What the Law Actually Prohibits

Zero background. You do not need to be a lawyer, but you must understand the shape of the laws that govern this work, because the boundary they draw is the boundary of your career. The recurring theme across jurisdictions is authorization: accessing a computer system without authorization (or exceeding authorized access) is the criminal act, independent of harm.

The major statutes (conceptually).

• United States — Computer Fraud and Abuse Act (CFAA). Criminalizes accessing a "protected computer" without authorization or in excess of authorization. "Protected computer" is broad — effectively anything internet-connected. The 2021 Van Buren v. United States Supreme Court decision narrowed "exceeds authorized access" to mean accessing areas of a system you are not permitted to enter, rather than merely using permitted access for a forbidden purpose — but this is a thin shield, not a license. The 2022 DOJ policy declined to prosecute good-faith security research, but DOJ policy is not law and protects no one in a civil suit.
• United Kingdom — Computer Misuse Act 1990. Unauthorized access (s.1), unauthorized access with intent to commit further offenses (s.2), and unauthorized acts impairing operation (s.3).
• European Union — Directive 2013/40/EU on attacks against information systems, transposed into member-state law.
• Sector and data law. GDPR (EU), HIPAA (US health), PCI DSS (cards — contractual, not statutory, but binding), and export-control regimes (EAR/Wassenaar) that can restrict sharing certain intrusion tooling across borders.

Why "the system was reachable" is never a defense. None of these statutes contain a "but the port was open" exception. An unlocked door is still trespass. This is the single most important legal intuition in the field: reachability is not permission.

How it connects to production. Real engagements are governed by a contract (statement of work, master services agreement) plus a rules-of-engagement (ROE) document, and frequently a safe harbor clause in a VRP that promises the organization will not pursue legal action for good-faith testing within stated scope. Your protection is the intersection of statute, contract, and written authorization — never any one alone.

Misconception to kill now. "Bug bounty pages mean everything is fair game." A VRP scope page is a narrow grant with explicit exclusions (no DoS, no social engineering, no testing of third-party-hosted assets, no automated scanning above a rate). Acting outside it forfeits safe harbor and re-exposes you to the statutes above.

This curriculum is authorized-lab-only. Everything you build and break, you own or have explicit written permission to test. When in doubt, obtain qualified legal advice for your jurisdiction — this chapter is orientation, not legal counsel.

Chapter 3: Authorization Is Data, Not a Vibe

The problem. A human agreement ("you may test our staging API next week") is prose. Your tools operate on concrete facts: IP addresses, hostnames, cloud resource IDs, account identifiers, timestamps, technique names, request rates, data volumes. The gap between the prose and the facts is where accidents live. An IP can be reassigned to a different tenant after the agreement is signed. A wildcard domain *.example.com can silently include a vendor-hosted subdomain you have no right to touch.

The fix: convert authorization into runtime state. Treat authorization as a versioned policy object evaluated before every consequential action. The decision is a function of:

engagement + operator + target + resolved asset identity + technique
           + time window + rate/data budget + safety state + policy version

Every one of those is a fact a program can check. The first lab (Engagement Guard) makes you build exactly this evaluator. The discipline you learn — resolve identity, then reject ambiguity, then fail closed — is the same discipline that reappears as cloud IAM (Phase 07), Kubernetes admission control (Phase 07), Android component-export checks (Phase 04), sandbox policy (Phase 06), and AI-agent tool gating (Phase 11). Deny-by-default authorization is the spine of the whole curriculum; here is where you first build it.

Fail closed, defined. When the system cannot establish that an action is permitted — because ownership is unclear, the policy is stale, an identifier won't resolve, or a predicate is missing — the answer is deny with a reason, never allow because probably fine. "Fail open" (allow on uncertainty) is how good intentions become incidents.

Misconception to kill now. "I'll just keep the scope in my head." Human memory is not an auditable control. If a teammate, an auditor, or a court asks "what authorized this packet?", the answer must be a record, not a recollection.

Chapter 4: Scope as a Machine-Checkable Policy

Build the model. An engagement is a small data structure:

Engagement
  approved assets        # exact identifiers, no wildcards you haven't resolved
  approved techniques    # e.g. {web-app-test} — NOT {load-test, social, physical}
  UTC start / end        # the window
  request ceiling        # max rate / total requests
  data ceiling           # max bytes / records of proof
  stop conditions        # state that overrides everything (Chapter 5)

The decision predicate. An action is allowed only if every clause is true:

asset ∈ approved_assets
  AND technique ∈ approved_techniques
  AND start ≤ now ≤ end
  AND observed_rate ≤ request_ceiling
  AND requested_data ≤ data_ceiling
  AND no stop_condition is active

This is a conjunction, which means any single false clause denies the action. That asymmetry is the whole point: it is hard to accidentally allow something and easy to deny it.

The five classic scope-drift failures — memorize these; each is a real-world incident pattern:

• Adjacent-host drift. A redirect, DNS alias, load balancer, or freshly discovered hostname is assumed in scope. It is not. Discovery does not extend authorization.
• Technique drift. "Web testing" silently becomes load testing, denial-of-service, social engineering, or physical entry. Each technique class needs its own explicit grant.
• Account/tenant drift. Access to one test tenant is treated as permission to read another tenant's data. Multi-tenancy boundaries are scope boundaries.
• Time drift. A scan launched inside the window keeps running after it closes. The window governs traffic, not just button presses.
• Data drift. "Minimum proof of the vulnerability" balloons into a bulk export of real records. Prove the bug with one record, not the database.

Why UTC, strictly. Timestamps without a timezone are ambiguous, and ambiguity in a time window means an action might be inside or outside scope depending on interpretation. The lab forces strict UTC parsing because an unparseable or naive timestamp must fail closed — you cannot prove you acted inside the window if you cannot pin the window to an absolute instant.

Misconception to kill now. "Canonicalizing the asset means resolving DNS and following redirects to see what's really there." No — resolving to discover new assets is itself drift. You canonicalize to compare against the approved list, not to expand it.

Chapter 5: Stop Conditions and Incident Conversion

Zero background. A stop condition is a precommitted rule that says: if state X becomes true, all permissions are revoked and active work halts immediately. It is a circuit breaker. The value of precommitting is that the decision to stop is made calmly in advance, not under the pressure of a live engagement where momentum and sunk cost push you to continue.

The canonical stop conditions:

• unexpected third-party or personal data appears;
• the target shows instability, degradation, or safety impact;
• scope becomes ambiguous;
• cloud cost runs away;
• evidence integrity fails (a hash mismatch you cannot explain);
• you see signs of a real intrusion unrelated to your testing;
• the owner or an incident commander says stop.

Stop conditions override permissions. This is the key structural property. In the decision predicate of Chapter 4, the stop-condition clause is ANDed last and dominates: even a perfectly in-scope, in-window, in-budget action is denied if a stop condition is active. The lab models this as state that short-circuits the allow decision.

Incident conversion. Sometimes during a test you encounter activity that may not be yours — a shell you didn't drop, beaconing you didn't start, data already exfiltrated. The assessment may have just walked into a real incident. The correct sequence:

1. Freeze automated activity (stop generating new events).
2. Preserve telemetry and your own action log.
3. Separate tester-generated events from unknown events — this is why you keep a precise log of everything you did, with timestamps and request IDs.
4. Escalate via the incident-command path; do not investigate beyond the authority the incident lead grants you.

Why your action log matters. Incident responders' first hard problem is "which of these events were the authorized tester and which were the adversary?" If your activity is logged precisely, you hand them a clean subtraction. If it isn't, you have made the incident harder to investigate.

Misconception to kill now. "Stopping is failure." Stopping correctly is the success metric of this phase. A tester who recognizes a stop condition and halts has performed flawless risk control.

Chapter 6: Network Isolation from First Principles

Zero background — what a network boundary actually is. When a machine wants to talk to another machine, the operating system consults its routing table to pick an outbound interface and a next hop. A firewall sits in that path and applies rules: allow or drop a packet based on source, destination, port, and protocol. "Isolation" means the only paths that exist are the ones you intend, and you have proven the others are absent. A virtual machine is not isolation — it is a container for an operating system that, by default, often has full LAN and internet access through the host.

Defense in depth — layers, each independently enforcing deny-by-default:

host firewall                         # the host won't route lab subnets to your home LAN
  → isolated virtual switch           # guests share a switch with no uplink to the real network
    → lab router (default-deny)       # explicit allow rules only for declared zone pairs
      → workload egress policy        # per-VM/container outbound restrictions
        → DNS/HTTP proxy allowlist    # only when an exercise truly needs outbound access

The reason for layers is that any single control can be misconfigured. If the virtual switch is accidentally bridged, the host firewall still blocks the LAN. Independent layers turn one mistake into a near-miss instead of a breach.

Test the negative path — the core discipline. A diagram claims isolation; packets prove it. From every vulnerable or analysis host, you must demonstrate that prohibited routes fail:

• your home/corporate LAN is unreachable;
• cloud metadata service addresses (169.254.169.254 and the link-local IPv6 equivalents) are unreachable — these endpoints hand out credentials and are a top cloud-pivot target;
• public egress is denied unless the exercise explicitly routes through a controlled proxy;
• management services accept only the management identity over the management path.

Canary technique. Place a synthetic secret (a "canary") in a forbidden location and confirm the vulnerable host cannot reach it. If denial is observed, you've proven the policy works — not merely that the target happened to be absent. This distinction (policy-proven vs. coincidentally absent) is what separates a tested control from an assumed one.

Management plane vs. experiment plane. The experiment (the vulnerable systems, the attacker workstation) must never be able to administer or impersonate the management plane (source control, the evidence vault, orchestration, telemetry). If a compromised victim VM could reach your evidence store, your evidence is no longer trustworthy. Separate the planes and prove the experiment plane cannot touch the management plane.

Misconception to kill now. "I'm behind NAT / on a VPN, so I'm isolated." NAT (Network Address Translation — rewriting private addresses to a shared public one so many hosts share one IP) and VPNs change addressing and confidentiality, not authorization or containment. A NATed host can still reach the internet; a VPN just moves where it egresses. Neither stops a victim VM from reaching your LAN or the internet.

Chapter 7: Evidence, Hashing, and Provenance

Zero background — what a cryptographic hash proves. A hash function (SHA-256) maps any input to a fixed 256-bit fingerprint such that (a) the same input always yields the same output, and (b) it is computationally infeasible to find two inputs with the same output (collision resistance) or to reverse it. Therefore, if you record \( \text{SHA-256}(\text{file}) = h \) at collection time and later recompute it and get the same \( h \), the bytes have not changed since collection.

What hashing does not prove — and this is the crux. A matching hash proves integrity since the recorded moment. It says nothing about:

• who collected the bytes,
• when (was the clock correct? synced to what source?),
• whether the source was trustworthy (a hash of a planted file is still a valid hash),
• what context was omitted during collection.

Integrity is necessary but not sufficient. The missing piece is provenance.

Provenance as a graph. Real evidence is a chain from origin to claim:

source → collector (tool + version) → collection time (UTC + clock source)
       → raw hash → transformation (decompress / filter / redact / convert)
       → derived hash → analyst claim → linked artifact

Every transformation creates a new artifact with a new hash and a recorded reason. You analyze copies and keep the original read-only, so the original's hash stays valid forever. This is the engineering meaning of chain of custody: an unbroken, recorded sequence from acquisition to conclusion, where every hop is attributable and every transformation is logged.

Minimum fields of an evidence record:

• stable evidence ID;
• source and collector (with tool version);
• collection time in UTC and the clock source;
• SHA-256 digest of the raw artifact;
• storage location and access controls;
• every transformation applied, each with its own derived hash.

The tamper demonstration (Lab 03 / evidence drill). Hash a fixture; flip one byte; show the manifest rejects it; restore the original; show it passes. The operational lesson: analysis tooling must fail loudly on integrity mismatch. Silent acceptance of altered evidence is how a report gets destroyed in review.

Why screenshots are weak evidence. A screenshot omits source state, collection method, searchable structure, and transformation history. It is a presentation artifact, not primary evidence. Collect the underlying log, pcap, or file; derive the screenshot from it.

Misconception to kill now. "Hashing makes evidence trustworthy." Hashing makes evidence tamper-evident from a point in time. Trustworthiness comes from the full provenance graph plus access controls plus a trustworthy collection process.

Chapter 8: Privacy, Data Minimization, and Redaction

Zero background. During testing you will brush against real personal data — names, emails, tokens, health or financial records. The governing principle is data minimization: collect the least data that proves the finding, and remove sensitive content from anything you share.

Proof, not plunder. To prove broken object-level authorization, you need one record you shouldn't be able to read — not the table. The size of your evidence is a liability, not a trophy. A report that includes a bulk export has converted a vulnerability finding into a data breach you caused.

Redaction as a deterministic transformation. The evidence-redaction lab models redaction as a pipeline that replaces sensitive tokens with stable placeholders and counts the transformations, so the report can state "17 email addresses redacted" auditably. Two properties matter:

• Determinism: the same input always redacts to the same output, so the same entity gets the same placeholder and analysts can correlate without seeing the raw value.
• Counting: the number of redactions is itself evidence of thoroughness and a check against leaks.

Redaction is irreversible by design. A good redaction cannot be undone from the published artifact. Beware "redactions" that merely overlay (black box over still-present text, metadata that retains the original, reversible hashing of low-entropy values like phone numbers). Redact the bytes, not the appearance.

Misconception to kill now. "I'll redact before publishing." Redact before storing in any shared location. The published report is not the only leak surface — chat messages, ticket attachments, and screenshots leak just as effectively.

Chapter 9: Safe Handling of Malware and Dangerous Fixtures

Zero background. Later phases triage malicious files (Phase 09) and run fuzzers that produce crashing inputs (Phase 08). A malicious sample is live ordnance: opening it in the wrong place executes attacker code with your privileges and network position.

The handling rules, and why each exists:

• Inert fixtures first. Prefer a benign file that exhibits the behavior you're studying (e.g. the EICAR test string for AV pipelines) over a real sample. You learn the workflow without the hazard.
• Isolated network, snapshots. Detonate only in a guest with no path to your LAN, internet, or management plane (Chapter 6), and snapshot before so you can roll back to a clean state.
• No shared folders, no clipboard, no host credentials. Each of these is a bridge the malware can cross from guest to host. Disable them for any malware-adjacent VM.
• Controlled transfer. Move samples as encrypted, password-protected archives so they don't auto-execute or get scanned/quarantined in transit, and so they can't accidentally detonate on an intermediary.

Why this lives in Phase 00. You set up these handling reflexes before you ever touch a real sample, so that when Phase 09 hands you one, the containment is already instinct.

Misconception to kill now. "It's just a sample in a VM." A VM with clipboard sharing, a shared folder, and internet access is a launch pad, not a sandbox. Containment is a property you prove (Chapter 6), not a checkbox you assume.

Chapter 10: Responsible Disclosure and the VRP Lifecycle

Zero background. When you find a real vulnerability in someone else's system (within authorized scope), responsible disclosure (a.k.a. coordinated disclosure) is the process of reporting it privately to the owner, giving them time to fix it, and only then — with permission — publishing. The goal is to get the bug fixed without arming attackers in the interim.

The VRP lifecycle (Vulnerability Reward Program / bug bounty):

discover → validate (reproduce, minimize proof) → report (clear writeup, repro steps, impact)
        → triage (vendor confirms / deduplicates / scores severity) → remediation (vendor fixes)
        → verification (you confirm the fix) → disclosure (coordinated, with permission)
        → optional reward

The friction points you must understand:

• Duplicates. Someone may have reported the same bug first; VRPs reward the first valid report.
• Severity disputes. You and the vendor may disagree on impact; argue with a clear exploitation scenario and a CVSS-style rationale, not indignation.
• Embargoes. A period during which neither party publishes, so a coordinated fix can ship — often aligned with a CVE assignment and patch release.
• Publication permission. You do not unilaterally publish. Even after a fix, you coordinate timing. Publishing a working exploit before users can patch is harmful disclosure.

Severity, briefly (CVSS intuition). A finding's severity combines exploitability (how easy to trigger: attack vector, complexity, privileges/interaction required) and impact (confidentiality, integrity, availability). A pre-auth remote bug that leaks all tenant data is critical; a self-XSS requiring the victim to paste an attacker's payload into their own console is low. You will justify severity in every report you write.

Explaining disclosure to an executive who wants to publish immediately. Frame it as risk to users: until a fix ships and is adopted, a public writeup is a roadmap for attackers against your own customers. Coordinated timing maximizes the number of users protected at publication.

Misconception to kill now. "Finding it gives me the right to publish it." Authorization to test is not authorization to disclose. They are separate grants with separate timing.

Chapter 11: The Hat Taxonomy and Why Labels Never Grant Permission

The community uses color labels; know them so you can speak the language, but internalize that none of them is a legal or ethical status — only authorization is.

• White hat — authorized, ethical testing to improve security.
• Black hat — unauthorized, malicious.
• Gray hat — acts without clear authorization, often disclosing afterward; legally exposed regardless of intent.
• Red team — authorized adversary emulation, broad scope, tests detection and response.
• Blue team — defenders: detection, response, hardening.
• Purple team — red and blue working together to close detection gaps in a feedback loop.
• Green/blue-hat — informal terms (newcomers; external invited testers, e.g. pre-release programs) with no consistent industry meaning.

The load-bearing point: calling yourself a "white hat" does not make an action authorized. The label describes intent; authorization (Chapters 3–4) describes permission. Only the latter keeps you on the right side of Chapter 2. A "gray hat" who finds a real bug in a stranger's system and discloses it is still legally exposed — good intent is not a defense to unauthorized access.

Lab Walkthrough Guidance

The three runnable labs operationalize this guide. Build them in this order:

Lab 01 — Engagement Guard and Evidence Verifier. This is the flagship. Implement in sub-steps:

1. Parse strict UTC timestamps; a naive or unparseable timestamp must fail closed (Chapter 4).
2. Canonicalize asset identifiers for comparison only — do not resolve or discover adjacent assets (Chapter 4 misconception).
3. Validate the engagement policy object (assets, techniques, window, ceilings).
4. Implement the allow decision as the conjunction from Chapter 4.
5. Make stop conditions override all permissions (Chapter 5) — verify an in-scope action is denied when a stop condition is active.
6. Hash and verify evidence files; reject a tampered fixture (Chapter 7).
7. Emit structured decision records that name the failed predicate and contain no secrets.

Lab 02 — Range Containment Verifier. Encode the zone reachability matrix (Chapter 6): only declared zone pairs may communicate; LAN, internet, OT, metadata, and management reachability from vulnerable zones must be proven absent.

Lab 03 — Evidence Redaction Pipeline. Deterministic redaction with transformation counts (Chapter 8); the same secret always maps to the same placeholder; the count is reported.

Run each lab against both your implementation and the reference solution:

pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v

Success Criteria

You are ready for Phase 01 when you can, without notes:

1. Refuse an out-of-scope target and name the exact failed predicate (asset / technique / window / rate / data / stop).
2. Stop an otherwise-permitted action because a stop condition is active, and explain the override semantics.
3. Detect modified evidence and explain why integrity ≠ provenance.
4. Prove a forbidden network path is absent using packets, not a diagram, including the metadata endpoint and your home LAN.
5. Explain why a VM, VPN, disclaimer, or public bug-bounty page is not sufficient authorization.
6. Convert a test into an incident workflow without contaminating evidence or losing the tester/adversary distinction.
7. Disclose responsibly — describe the VRP lifecycle, embargoes, and why publication needs coordination.

Common Mistakes

• Treating public reachability as authorization (Chapter 2 — the defining error).
• Using a VPN, disclaimer, or VM as a substitute for written scope.
• Letting vulnerable images keep internet or LAN access; never testing the negative path.
• Capturing excessive data and calling it "evidence" (Chapter 8).
• Hashing evidence but never recording provenance, then being unable to defend it.
• Treating "stop" as failure rather than as the primary success behavior.
• Publishing a finding before the owner authorizes disclosure.

Interview Q&A

Q: What would make you stop an assessment immediately? A: Any active stop condition — unexpected third-party/personal data, target instability or safety impact, scope ambiguity, runaway cloud cost, an unexplained evidence-integrity failure, signs of a real intrusion, or an owner/IC stop request. Stop conditions override all other permissions, so I halt even mid-action, preserve state and my action log, record the reason and time, notify the owner, and require explicit re-authorization before resuming.

Q: A redirect points from an approved hostname to an unlisted hostname. Do you continue? A: No. Redirects, aliases, and discovered hosts do not extend scope — that's adjacent-host drift. I stop that path, preserve the response as evidence, and obtain written clarification from the asset owner before touching the new host.

Q: The client verbally asks you to test a new asset during a call. What do you do? A: Record the request, but do not test until the authorized scope is updated in writing by the right owner. A verbal request from someone on a call is not proof of authorization, and I can't later show what authorized the traffic.

Q: How do you preserve evidence while minimizing personal data? A: Collect the minimum that proves the finding — one record, not the table. Preserve the raw artifact read-only with a recorded hash and full provenance (collector, tool/version, UTC time, clock source). Analyze copies. Redact secrets and personal data deterministically before the artifact enters any shared location, and report the redaction counts.

Q: Why hash evidence more than once? A: I hash at acquisition to anchor integrity, and again after each transformation boundary (transfer, normalization, redaction). Matching hashes prove the bytes are unchanged since each point; the chain of derived hashes plus recorded reasons preserves provenance. A single hash proves integrity from one instant; the chain proves the whole custody path.

Q: When does a security assessment become an incident response engagement? A: When I encounter activity that may not be mine — a foothold I didn't create, beaconing, evidence of prior exfiltration. I freeze my automated activity, preserve telemetry and my action log, mark every event I generated so responders can subtract my activity, and escalate through incident command without investigating beyond the authority the IC grants.

Q: Explain responsible disclosure to an executive who wants to publish immediately. A: Until a fix ships and customers adopt it, a public writeup is an attacker roadmap against our own users. Coordinated disclosure — private report, remediation window, optional embargo aligned with the patch — maximizes the number of users protected when we publish. We lose nothing by sequencing it; we expose users by rushing it.

References

Standards and government guidance

• NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide (preparation, IR lifecycle).
• NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response (evidence concepts, order of volatility, chain of custody).
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (scoping, rules of engagement, methodology).
• ISO/IEC 29147 — Vulnerability disclosure; ISO/IEC 30111 — Vulnerability handling processes.
• FIRST CVSS v3.1 / v4.0 specification — severity scoring (exploitability vs. impact).

Law and policy

• Computer Fraud and Abuse Act, 18 U.S.C. § 1030; Van Buren v. United States, 593 U.S. (2021).
• UK Computer Misuse Act 1990; EU Directive 2013/40/EU on attacks against information systems.
• U.S. DOJ, "Policy Regarding Charging Under the CFAA" (2022) — good-faith research declination (policy, not law).
• EFF, Coders' Rights Project — vulnerability reporting and reverse-engineering FAQs.

Disclosure and program practice

• disclose.io — open-source safe-harbor and disclosure policy templates.
• Major VRP policy pages (Google, Apple Security Research, Microsoft MSRC) — compare scope, prohibited testing, data handling, and disclosure terms (Phase 00 required reading).
• CERT/CC Guide to Coordinated Vulnerability Disclosure.

Books

• Jon Erickson, Hacking: The Art of Exploitation (lab-only mindset, foundations).
• Dafydd Stuttard & Marcus Pinto, The Web Application Hacker's Handbook (methodology discipline).
• Bruce Schneier, Secrets and Lies (security as a risk-management process, not a product).

Hitchhiker's Guide — Building a Security Research Range That Fails Closed

The operational companion to the Phase 00 WARMUP. The WARMUP explains why authorization, containment, and evidence are executable properties; this guide is the how — the concrete topology, firewall rules, commands, drills, and acceptance packet that turn a pile of VMs into a range where a mistake is contained, observable, reversible, and attributable. "I used a VM" is not a design.

Table of Contents

• The Operator's Goal
• Reference Zones and Topology
• The Default-Deny Policy
• Build Checklist
• Proving Containment — Concrete Commands
• Telemetry: Prove Every Source
• Attack Simulation Rules
• Operator and Tool Identity
• The Evidence Pipeline Exercise
• Failure Scenarios and Drills
• Teardown
• Failure Injection and the Readiness Packet
• References

The Operator's Goal

Build a range with four properties, each testable:

• Contained — a compromised guest cannot reach your LAN, the internet, the cloud metadata endpoint, the hypervisor, or the management plane.
• Observable — every zone ships telemetry you have verified with a real event.
• Reversible — snapshots and teardown return the range to a known-clean state.
• Attributable — every action ties to an operator, a tool/version, and a policy decision.

If you cannot demonstrate all four with commands and packet evidence, the range is not ready.

Reference Zones and Topology

                    ┌────────────── management (10.10.0.0/24) ──────────────┐
                    │ Git · package mirror · evidence vault · orchestration │
                    └───────────────┬───────────────────────────────────────┘
                                    │ (admin only, one direction)
   ┌──────────────┬────────────────┼────────────────┬───────────────┐
   │ attacker     │ victim         │ mobile         │ kubernetes    │  → all zones ship logs →
   │ 10.10.1.0/24 │ 10.10.2.0/24   │ 10.10.3.0/24   │ 10.10.4.0/24  │     telemetry 10.10.9.0/24
   └──────────────┴────────────────┴────────────────┴───────────────┘
   cloud: dedicated sandbox accounts/projects (federated, no stored keys)
   ot-sim: synthetic protocols + process simulator only (10.10.5.0/24)

Use host-only / isolated virtual switches with no uplink to your real NIC; a dedicated lab router VM (e.g. OPNsense/VyOS) enforces inter-zone policy. The host firewall is the backstop if the switch is ever misconfigured.

The Default-Deny Policy

• management may administer lab zones; lab zones may not administer management;
• every lab zone ships logs to telemetry (one direction);
• attacker reaches only the declared victim service ports;
• victim/mobile/OT cannot initiate arbitrary internet or LAN connections;
• no vulnerable zone reaches host credentials, hypervisor sockets, shared clipboard, or home directories;
• cloud and package access goes through dedicated identities in explicit setup windows only.

Build Checklist

Host

• full-disk encryption; patched hypervisor;
• a dedicated lab directory with no production credentials;
• a separate browser profile and SSH config (~/.ssh/config Host lab-* block, distinct keys);
• password-manager entries scoped to lab accounts only;
• host firewall denies lab subnets → local LAN (example, Linux nftables):

# Drop anything from lab subnets headed to the home/corp LAN and metadata
nft add rule inet filter forward ip saddr 10.10.0.0/16 ip daddr 192.168.0.0/16 drop
nft add rule inet filter forward ip saddr 10.10.0.0/16 ip daddr 169.254.169.254 drop

Virtualization

• host-only / isolated switches; verify no guest has a bridged/NAT adapter it shouldn't;
• disable drag-and-drop, clipboard sharing, and shared folders for vulnerable/malware-adjacent guests (virsh/VirtualBox/VMware settings — confirm in the running guest, not just config);
• snapshot clean states and label versions (virsh snapshot-create-as victim clean-v1);
• never expose hypervisor control sockets (/var/run/libvirt/..., the Docker socket) to guests.

Cloud

• separate organization/account/project; MFA; no root/owner for daily use;
• budgets, quotas, region restrictions, teardown tags;
• short-lived federation (OIDC) instead of stored long-lived keys;
• organization-level audit logs stored outside workload-admin control.

Proving Containment — Concrete Commands

A diagram claims isolation; packets prove it. From every vulnerable/analysis host, run the negative-path tests and confirm each fails:

# From a victim/attacker guest — every one of these MUST fail (timeout/refused):
curl -m 3 http://192.168.1.1/            # home LAN gateway      → must fail
curl -m 3 http://169.254.169.254/        # cloud metadata        → must fail
curl -m 3 https://example.com/           # public egress         → must fail (unless proxied)
nc -vz 10.10.0.10 22                      # management SSH        → must fail
# And the one ALLOWED path MUST succeed:
nc -vz 10.10.2.20 8080                    # declared victim port  → must succeed

Canary technique: place a synthetic secret on an unreachable host and confirm the vulnerable guest cannot fetch it — denial then proves policy, not mere target absence. Capture with tcpdump -i any -w proof.pcap running on the router so you have packet evidence the connection was dropped, not just unanswered.

Re-run these after every reboot and snapshot restore — restored state can silently re-enable a NAT adapter.

Telemetry: Prove Every Source

Never assume a log source works; generate a benign event and query it back:

A source that doesn't produce a queryable record is a blind spot — fix it before you rely on it.

Attack Simulation Rules

• prefer seeded fixtures over general offensive tooling;
• use synthetic identities and canary secrets only;
• cap requests, concurrency, bytes, runtime, and cost;
• start packet/log capture before the exercise;
• maintain a tester action log (timestamp, operator, tool/version, target, request IDs) so responders can subtract your activity from an incident;
• stop the moment the security property is demonstrated (minimum proof, Phase 00 WARMUP).

Operator and Tool Identity

Give human operators named identities and automation narrowly scoped service identities. Never reuse personal cloud credentials inside the range. Require short-lived credentials, strong admin authentication, and a separate identity for evidence-store access (the experiment plane must not be able to write the evidence vault). For every consequential action record: operator · tool/version · policy decision · target · result.

The Evidence Pipeline Exercise

Run this once per range build to prove your evidence handling (Phase 00 WARMUP, Chapter 7):

# 1. create a source artifact with known time/identity
# 2. collect with the documented tool
sha256sum capture.pcap > capture.pcap.sha256          # 3. hash + register the RAW artifact
cp capture.pcap derived_utc.pcap                      # 4. normalize time into a DERIVED copy
./redact --canary > presentation.txt                  # 5. redact a canary into a presentation copy
sha256sum -c capture.pcap.sha256                       # 6. verify — must PASS
printf '\x00' | dd of=capture.pcap bs=1 seek=10 conv=notrunc 2>/dev/null
sha256sum -c capture.pcap.sha256                       # 7. after edit — must FAIL (tamper-evident)

Record every transformation with its own derived hash and reason. Screenshots alone are weak evidence — they omit source state, collection method, searchable structure, and transformation history; derive them from primary evidence.

Failure Scenarios and Drills

Unexpected personal/third-party data. Stop collection, isolate the artifact, restrict access, notify the authorized owner/privacy contact, record what was seen without copying more than necessary, and follow deletion/retention direction.

Service degradation. Stop traffic, capture time and request IDs, inform the owner, preserve tester logs, assist recovery, and do not resume until explicitly re-authorized.

Real suspicious activity during testing. Freeze automated tests, preserve telemetry and your action log, invoke incident command, and mark every known tester event so responders can separate you from the adversary. Do not investigate beyond the authority the incident lead grants.

Teardown

□ terminate cloud and local workloads
□ revoke temporary identities, certs, tokens, secrets
□ remove routes, TAP devices, namespaces, mounts, cgroups
□ export and hash required evidence; store in the vault
□ destroy unnecessary captures/snapshots per retention policy
□ run a final discovery FROM management and confirm only baseline assets remain

Teardown that "looks done" but leaves an orphaned cloud resource (cost + exposure) or a lingering TAP device (a path back) is a failed teardown — verify, don't assume.

Failure Injection and the Readiness Packet

Before you trust the range, inject each failure and confirm the range/operator responds correctly: expired authorization, adjacent target, DNS reassignment, prohibited technique, rate-budget exhaustion, telemetry loss, unexpected sensitive data, service degradation, and emergency stop.

The readiness packet (the go/no-go artifact) contains: authorization/scope, ownership evidence, topology, permitted/denied reachability proofs, identities and budgets, evidence controls, stop contacts and drill results, snapshot/rebuild procedure, teardown verification, and cost checks.

References

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (lab setup, rules of engagement).
• NIST SP 800-61r2 / 800-86 — incident handling and forensic/evidence concepts.
• CIS Benchmarks — host/hypervisor hardening baselines.
• nftables / iptables and libvirt networking documentation (isolated networks, host-only switches).
• Zeek and Suricata documentation; Sysmon (Sysinternals) and Linux auditd documentation.
• disclose.io — safe-harbor and rules-of-engagement templates (paired with Phase 00 WARMUP).

Lab 01 — Engagement Guard and Evidence Verifier

Difficulty: 3/5 | Time: 4–6 hours | Runs locally: yes, standard library only

Pairs with the Phase 00 WARMUP (Chapters 3–7) and HITCHHIKERS-GUIDE. Build a deny-by-default control that decides whether a proposed security test is authorized, and a verifier that proves the evidence you collected has not been altered.

Why This Lab Exists (Purpose & Goal)

Every catastrophic security-engineering mistake in the news began the same way: someone took an action they believed was authorized but could not prove was authorized, against a target that turned out to be out of scope. The line between a professional security engineer and a criminal is not skill — it is provable authorization, containment, and evidence discipline. This is Lab 01 because it is the reflex that makes every sharper tool in the curriculum (fuzzers, container escapes, cloud IAM analysis, AI agents) safe to wield.

The goal is to make authorization a machine-checkable property rather than a feeling. You will build the small program a real engagement runs before every consequential action: it converts a signed rules-of-engagement document into a policy object and answers, deterministically, "is this exact action, against this exact asset, with this technique, at this time, within these limits, allowed right now?" — and refuses, with a named reason, when any predicate fails.

The Concept, In the Weeds

A human agreement ("you may test our staging API next week") is prose; your tools operate on concrete facts — IP addresses, hostnames, technique names, timestamps, request rates, byte counts. The gap between the prose and the facts is where accidents live: an IP reassigned to a different tenant after sign-off, a wildcard domain that silently includes vendor infrastructure, a scan that keeps running after the window closed.

The fix is to evaluate authorization as a conjunction of predicates — every clause must be true, so any single false clause denies the action. That asymmetry (hard to accidentally allow, easy to deny) is the entire point of deny-by-default:

asset ∈ approved_assets
  AND technique ∈ approved_techniques
  AND start ≤ now ≤ end           (timezone-aware UTC)
  AND observed_rate ≤ rate_ceiling
  AND requested_data ≤ data_ceiling
  AND no stop_condition is active   ← dominates everything else

Two subtleties this lab forces you to confront:

• Stop conditions are circuit breakers, not prose. A perfectly in-scope, in-window, in-budget action is still denied the instant a stop condition is active. You precommit them so the decision to halt is made calmly in advance, not under the momentum of a live test.
• Integrity ≠ provenance. A SHA-256 digest proves bytes are unchanged since you recorded the digest — nothing more. It does not prove who collected them, when, or from where. The verifier uses a constant-time comparison (hmac.compare_digest) so an attacker cannot learn the expected digest byte-by-byte through timing.

Why This Matters for Protecting the Company

When you join a security team, you are not trusted with production access, red-team scope, or a vulnerability-reward-program queue until you demonstrate exactly this behavior. A tester who cannot prove authorization exposes the company to legal liability (the CFAA and its global equivalents criminalize unauthorized access regardless of intent); a tester who contaminates evidence destroys the company's ability to act on a finding or defend itself; a tester who ignores a stop condition can turn an assessment into an outage or a breach. This control is the difference between a security program that reduces risk and one that creates it.

What You're Building

ProposedAction (operator, asset, technique, time, rate, data)
        │
        ▼
authorize_action(policy, action) ──▶ Decision(allowed, reason, failed_control)
        │                                  └─ logged with NO secrets, names the failed control
NetworkPolicy.allows(src, dst, port) ──▶ only declared zone pairs reachable
sha256_file / verify_evidence ──▶ tamper-evident, constant-time

How This Is Used on the Job

This is not a toy — it is the shape of real tooling. A pentest orchestrator gates every scanner launch through an authorization function like this. A bug-bounty automation pipeline refuses to send traffic to a host absent from the program scope. An incident-response evidence vault verifies every artifact's hash on ingest and rejects a mismatch loudly. The exact same deny-by-default policy shape reappears later as cloud IAM (Phase 07), Kubernetes admission control (Phase 07), Android component-export checks (Phase 04), sandbox policy (Phase 06), and AI-agent tool gating (Phase 11). You are building the spine of the whole discipline here.

Attack / Failure Cases You Must Handle

1. An operator supplies an adjacent but unapproved hostname (asset-scope drift).
2. A permitted target is tested with a prohibited technique (technique drift).
3. A request starts outside the approved UTC window (time drift).
4. The requested rate or data volume exceeds the engagement ceiling (data/rate drift).
5. A safety stop is active but the target/technique are otherwise valid (stop dominates).
6. An evidence file changes after collection (tamper detection).
7. A lab network flow crosses an undeclared zone boundary (containment).

Build Order

1. EngagementPolicy.validate — reject a malformed policy (fail closed).
2. authorize_action — the conjunction above, returning a named failed control.
3. sha256_file and verify_evidence — hashing + constant-time verification.
4. NetworkPolicy.allows — only declared (source, destination, port) flows.
5. Decision.to_json — a decision record with no secrets and the failed control.

Run

python -m pip install -r requirements.txt
pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v

Security Properties (Invariants)

• a malformed policy fails closed;
• exact asset matching — no suffix/wildcard guessing;
• any active stop condition denies all actions;
• timestamps are timezone-aware;
• evidence comparison is constant-time;
• network paths absent from policy are denied;
• decision logs omit secrets and include the failed control.

Validation — What You Should Be Able to Do Now

After this lab you can, without notes:

• Refuse an out-of-scope action and name the exact failed predicate, rather than waving at "it felt wrong." This is the answer interviewers want when they ask "the client verbally asks you to test a new asset — what do you do?"
• Explain why a VM, a VPN, a disclaimer, or a public bug-bounty page is not sufficient authorization — because none of them is a record a court, an auditor, or a teammate can check.
• Distinguish integrity from provenance and explain why a matching hash is necessary but not sufficient evidence.
• State the stop-condition override semantics and why "stopping correctly" is a success, not a failure.

The Broader Perspective

You just built, in miniature, a policy decision point (PDP) — the architectural pattern that governs access in every serious system you will ever secure. The mental move you practiced — convert a human agreement into versioned, evaluated-before-every-action policy data, and fail closed on ambiguity — is the single most transferable idea in security engineering. When you later look at an over-permissive IAM role, a lenient admission controller, or an agent that runs whatever the model proposes, you will recognize them all as the same failure: authority that wasn't evaluated deny-by-default against an explicit policy. Carry this forward; it is the lens for the entire track.

Interview Angle

• "What would make you stop an assessment immediately?" — Any active stop condition (unexpected third-party data, instability, scope ambiguity, runaway cost, evidence-integrity failure, signs of a real intrusion, owner stop). Stop conditions override all permissions.
• "Why hash evidence, and why isn't a hash enough?" — A hash makes the artifact tamper-evident from a point in time; trustworthiness also needs provenance (collector, tool, UTC time, clock source) and access controls.

Extension (Stretch)

Sign the policy file; add CIDR support with ipaddress; connect the decision function to a local scanner wrapper that refuses to launch unless authorization succeeds.

References

• NIST SP 800-115 (testing methodology, rules of engagement); NIST SP 800-86 (evidence concepts).
• disclose.io safe-harbor templates; CFAA / Computer Misuse Act overview (Phase 00 WARMUP, Ch. 2).
• Phase 00 WARMUP Chapters 3–7.

Lab 02 — Range Containment Verifier

Difficulty: 2/5 | Runs locally: yes, standard library only

Pairs with the Phase 00 WARMUP Chapter 6 (network isolation) and the HITCHHIKERS-GUIDE ("Proving Containment").

Why This Lab Exists (Purpose & Goal)

"I used a VM" is not a containment design. A virtual machine is just an operating system that, by default, often has full LAN and internet access through the host — so a vulnerable or malware-laden guest can reach your home network, your employer's network, the cloud metadata endpoint that hands out credentials, or your own management tooling. The purpose of this lab is to make containment a property you can prove with code, not a checkbox you assume. You build the verifier that takes a lab's declared network policy and reports two kinds of failure: a required telemetry flow that is missing (you'd be blind), and a forbidden path that is reachable (you'd be exposed).

The Concept, In the Weeds

Isolation means the only paths that exist are the ones you intend, and you have proven the others are absent. That last clause is the hard part: a diagram claims isolation; only an explicit check proves it. The model has zones — management, attacker, victim, telemetry, mobile, Kubernetes, cloud-proxy, and an OT simulation — and an allow-list of (source, destination, port) flows. The verifier asserts two opposite things at once:

• Positive obligations — every zone must be able to ship logs to telemetry. A missing flow here is a silent blind spot an attacker exploits (you can't investigate what you never recorded).
• Negative obligations — the victim must not reach the LAN or the internet; the attacker must not reach the management plane; the OT simulation must not reach the internet. A reachable forbidden path is a containment breach.

The deep idea is defense in depth across independent layers (host firewall → isolated virtual switch → lab router → per-workload egress policy). Any single layer can be misconfigured; independent layers turn one mistake into a near-miss instead of a breach. The verifier is the test that catches the mistake before a live exercise does.

Why This Matters for Protecting the Company

A contained range is the difference between "we safely studied a malware sample" and "we detonated ransomware on the corporate network." The same reasoning protects production: the experiment plane (vulnerable systems, attacker workstation) must never be able to administer or impersonate the management plane (source control, the evidence vault, orchestration, telemetry). If a compromised victim could reach your evidence store, your evidence is no longer trustworthy and your incident is no longer investigable. Proving the absence of paths is exactly how you protect the crown jewels — in a lab, in a cloud account (Phase 07 metadata/SSRF egress controls), and in an OT plant (Phase 10 zones and conduits).

How This Is Used on the Job

This is the kernel of network segmentation review — one of the most common and highest-leverage activities a security engineer performs. Cloud security reviews ask exactly this ("can a workload in the public subnet reach the database subnet?"). Container and Kubernetes reviews ask it (NetworkPolicy + a CNI that actually enforces it). OT assessments ask it (the zone-and-conduit matrix). You are learning to reason about reachability as a bidirectional property: prove the good flows exist and prove the bad flows don't.

Build It

Implement audit_policy(allowed): given the set of allowed (source, destination, port) flows, return a sorted, de-duplicated tuple of findings — one for every missing required telemetry flow and one for every forbidden reachable path (victim→LAN, victim→internet, attacker→management, OT→internet).

LAB_MODULE=solution pytest -q

Validation — What You Should Be Able to Do Now

• Test the negative path by reflex: from any vulnerable host, prove the home LAN, the metadata endpoint (169.254.169.254), public egress, and the management plane are all unreachable — with a packet or a policy assertion, not a diagram.
• Explain the canary technique: place a synthetic secret in a forbidden location and confirm the vulnerable host cannot reach it, so denial proves the policy rather than the target merely being absent.
• Articulate why NAT and VPNs are not containment — they change addressing and confidentiality, not authorization or reachability.

The Broader Perspective

You practiced the most underrated discipline in security: proving a negative. Most engineers can list what a system should do; few rigorously prove what it must never do. That habit — encode the forbidden paths and continuously verify their absence — is what later lets you trust a cloud landing zone, a sandbox, or a segmented OT network. Reachability is policy; verify it, don't assume it.

Interview Angle

• "How do you prove a lab/VM is actually isolated?" — Enumerate interfaces, routes, DNS, proxies, shared folders, host services, the metadata endpoint, and the management path; test intended and forbidden flows; keep packet/firewall evidence; re-test after reboot and snapshot restore.

Extension (Stretch)

Implement the equivalent rules in real nftables/iptables and a host-only virtual switch, and prove containment with tcpdump captures (Phase 00 HITCHHIKERS, "Proving Containment").

References

• Phase 00 WARMUP Chapter 6; HITCHHIKERS-GUIDE.
• NIST SP 800-115 (lab setup); CIS Benchmarks (host/hypervisor hardening).

Lab 03 — Evidence Redaction Pipeline

Difficulty: 2/5 | Runs locally: yes, standard library only

Pairs with the Phase 00 WARMUP Chapter 8 (privacy, data minimization, redaction).

Why This Lab Exists (Purpose & Goal)

During real testing you will brush against real secrets and real personal data — bearer tokens, emails, IP addresses, API keys. The moment any of it lands in a report, a ticket, a chat message, or a screenshot, you have potentially turned a vulnerability finding into a data breach that you caused. The purpose of this lab is to make redaction a deterministic, auditable transformation rather than a manual, error-prone afterthought. You build the pipeline that strips sensitive tokens from a report while producing a stable count of exactly what was removed.

The Concept, In the Weeds

Two principles govern handling sensitive evidence:

• Data minimization — proof, not plunder. To prove broken object-level authorization you need one record you shouldn't be able to read, not the whole table. The size of your evidence is a liability, not a trophy.
• Redaction is an irreversible transformation, by design. A good redaction cannot be undone from the published artifact. Beware fake redactions — a black box drawn over still-present text, metadata that retains the original, or reversibly "hashing" a low-entropy value like a phone number that can be brute-forced back. You must redact the bytes, not the appearance.

This lab's pipeline has two properties that matter:

• Determinism — the same input always redacts to the same output, so the same entity maps to the same placeholder and analysts can correlate occurrences without ever seeing the raw value.
• Counting — the number of redactions ("17 email addresses redacted") is itself evidence of thoroughness and a check against leaks: if the count is zero where you expected secrets, your patterns are wrong.

Why This Matters for Protecting the Company

A leaked report is a new incident, on top of the one you were investigating, and it is one you are personally responsible for. Regulators (GDPR, HIPAA, PCI) treat the unnecessary collection or exposure of personal data as a violation regardless of intent. A redaction pipeline with a verifiable count is how a mature security team demonstrates — to its own privacy/legal function and to a customer — that findings were communicated without ever spreading the sensitive data they concerned. This is also why you redact before storing in any shared location, not just before publishing: the published report is rarely the only leak surface.

Build It

Implement redact(text): replace synthetic bearer tokens, email addresses, IPv4 addresses, and API-key assignments with stable placeholders, returning (redacted_text, counts_by_category). Raw evidence stays unchanged and access-controlled; only sanitized report copies pass through this tool.

LAB_MODULE=solution pytest -q

Secure Implementation Patterns

The anti-pattern. A "redaction" that overlays text it doesn't remove, or that can't report what it did:

report = report.replace(secret, "████")    # if you miss one secret, you don't know; no count, no audit

The secure pattern — deterministic, counted, byte-level redaction (mirrors solution.py):

PATTERNS = (
    ("bearer",  re.compile(r"(?i)\bBearer\s+[A-Za-z0-9._~-]+")),
    ("email",   re.compile(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b")),
    ("ipv4",    re.compile(r"\b(?:\d{1,3}\.){3}\d{1,3}\b")),
    ("api_key", re.compile(r"(?i)\bapi[_-]?key\s*[:=]\s*\S+")),
)

def redact(text: str) -> tuple[str, dict[str, int]]:
    counts, output = {}, text
    for name, pattern in PATTERNS:
        output, count = pattern.subn(f"[REDACTED:{name}]", output)   # replace the BYTES, not the display
        counts[name] = count                                          # COUNT each category (evidence + leak check)
    return output, counts

The counts are the security feature: "17 emails redacted" is auditable proof of thoroughness, and a count of zero on a report you know contained secrets means your patterns are broken — not that the report is clean.

Production practices to carry forward:

• Redact the bytes, not the appearance — never a black box over still-present text, and strip document metadata that retains the original.
• Determinism enables correlation — the same entity maps to the same placeholder, so analysts can correlate occurrences without seeing the raw value.
• Redact before any shared location (report, ticket, chat, screenshot), not just before publishing.
• Data minimization first — collect one record that proves the finding, not the table; a smaller artifact is a smaller liability.
• Beware reversible "redaction" of low-entropy values (a phone number "hashed" is brute-forceable).

Validation — What You Should Be Able to Do Now

• Explain why a matching redaction count is evidence, and why a count of zero on a report you know contained secrets means your detection (not the report) is broken.
• Recognize fake redactions (overlay, retained metadata, reversible low-entropy hashing) and why they leak.
• State the minimization rule: collect and retain the least data that proves the finding, and redact before the artifact enters any shared location.

The Broader Perspective

This lab teaches a habit that distinguishes a trusted senior engineer: treat every artifact you produce as a potential leak surface, and make safety mechanical. The same instinct later drives your decision logging (never log a bearer token), your detection telemetry (Phase 09 redaction of PII in alerts), and your AI-agent design (Phase 11 redaction before the provider boundary). Handling other people's data carefully, by default, is not bureaucracy — it is the foundation of being trusted with access to systems that matter.

Interview Angle

• "How do you preserve evidence while minimizing personal data?" — Collect the minimum that proves the finding; preserve the raw artifact read-only with a recorded hash and provenance; analyze copies; redact deterministically before the artifact enters any shared location, and report the redaction counts.

Extension (Stretch)

Add policy-selected pseudonyms (stable per-entity aliases) and emit a transformation entry for the evidence manifest, so the redaction itself is part of the chain of custody.

References

• Phase 00 WARMUP Chapter 8; NIST SP 800-86 (evidence handling).
• GDPR data-minimization principle; PCI DSS / HIPAA handling of sensitive data.

Phase 01 - Systems Programming and Computer Science Foundations

Duration: 12 weeks (Months 2-4)
Objective: understand software below framework level and build security tools without unsafe parsing, memory, concurrency, or privilege assumptions.

Deep guides: WARMUP.md derives the memory/parser/binary boundary; HITCHHIKERS-GUIDE.md covers compiler hardening, attack corpora, fuzzing, triage, and production containment.

Objectives and Theory

• C memory model: object lifetime, stack/heap, pointers, bounds, integer conversion, UAF, double-free, and undefined behavior.
• C++ object model: RAII, ownership, vtables, exceptions, templates, and unsafe interoperability.
• Rust ownership, borrowing, lifetimes, traits, unsafe, FFI, and parser design.
• Go goroutines, channels, cancellation, interfaces, memory model, races, and network I/O.
• Python typing, binary parsing, async/subprocess safety, packaging, and secure automation.
• Java/Kotlin bytecode/runtime basics needed for Android.
• x86-64 and ARM64 registers, calling conventions, stack frames, control flow, and syscalls.
• Processes, threads, virtual memory, file descriptors, signals, scheduling, IPC, filesystems, and user/kernel transitions.
• ELF, PE, Mach-O, linking, relocation, symbols, debug information, disassembly, and decompilation.

Programming Standard

Every program needs malformed-input tests, explicit resource limits, structured errors, dependency locking, and a short threat model. Run compiler warnings, linters, sanitizers, race detectors, and fuzzers where applicable.

12-Week Build Sequence

Runnable lab portfolio

1. Bounded Binary Parser and Fuzz Target
2. Binary Hardening Report Analyzer
3. Syscall Policy Synthesizer
4. C Memory Corruption: Break, Diagnose, Fix, Defend
5. Rust Capability Token and Replay Defense

Together they cover parser attack surfaces, hardening metadata, syscall observation, forbidden kernel interfaces, policy regression, native memory corruption under sanitizers, and memory-safe capability authorization with tenant, expiry, action, and replay invariants.

Do not build exploit chains. Vulnerable examples exist only to teach root cause, compiler/runtime diagnostics, secure replacement patterns, and regression prevention.

Capstone - Security Engineer Systems Toolkit

Integrate the ELF inspector, tracer, fuzz harness, Rust parser, packet decoder, configuration auditor, SARIF normalizer, and secure coding corpus behind one documented workspace.

Required capstone experiments:

1. Feed 10,000 generated malformed inputs to each parser.
2. Demonstrate sanitizer or fuzzer discovery of at least three seeded defects.
3. Fix each defect and add a regression test.
4. Benchmark safe limits and identify denial-of-service thresholds.
5. Compare C and Rust failure modes without claiming Rust eliminates logic bugs.

Recommended Sources

• Computer Systems: A Programmer's Perspective
• Operating Systems: Three Easy Pieces
• Effective C and the SEI CERT C/C++ guidance
• The Rustonomicon, Rust unsafe-code guidelines, Go memory model and race detector docs
• System V AMD64 ABI, Arm ABI, ELF and DWARF specifications
• The Fuzzing Book and LLVM libFuzzer/sanitizer documentation

Measurable Outcomes

• 80%+ meaningful branch coverage on owned parser logic.
• Zero sanitizer findings and zero race-detector findings after fixes.
• Fuzz smoke test runs in CI with saved regression corpus.
• All tools reject oversized/truncated input without crash or unbounded allocation.
• A new engineer can run the toolkit from a clean environment in under 15 minutes.

Evaluation Checklist

• Explain stack vs heap, virtual vs physical memory, and syscall transitions from a trace.
• Identify endianness, alignment, lifetime, and integer-width hazards during review.
• Read a small x86-64 and ARM64 function and reconstruct control flow.
• Explain ELF/PE/Mach-O similarities and security-relevant differences.
• Minimize a crash, identify root cause, patch it, and prove regression coverage.
• State what each tool cannot safely conclude.

Common Mistakes and Interview Prompts

Mistakes: parsing before validating lengths, trusting file offsets, unbounded concurrency, subprocess command construction, swallowing errors, confusing crashes with exploitability, and reporting sanitizer output without root-cause analysis.

Interview prompts:

1. Design a safe parser for an untrusted length-prefixed format.
2. What makes use-after-free possible, and how do ownership systems change the risk?
3. Walk from a function call to a syscall and back.
4. How would you fuzz a stateful protocol parser?
5. Why can a memory-safe service still be security-critical?

Portfolio and Stretch

Publish the toolkit with architecture, tests, sample sanitized outputs, benchmarks, and a research note on one root cause. Stretch: PE/Mach-O support, eBPF-based tracing, grammar-aware fuzzing, differential parser tests, and a small verified parser state machine.

Warmup Guide — Memory, Parsers, Binaries, and the Kernel Boundary

Zero-to-expert primer for Phase 01. It builds, from first principles, the systems knowledge a security engineer needs below framework level: the C abstract machine and undefined behavior, the memory-defect families, integer arithmetic as the source of length bugs, parser state machines and differentials, executable formats (ELF/PE/Mach-O), the loader and the syscall boundary, and what Rust and Go actually remove. Assumes only basic programming. By the end you should be able to write a parser that cannot be tricked, read a crash and reason about its root cause, and explain why a memory-safe service can still be security-critical.

Table of Contents

• Chapter 1: Where Security Bugs Live — The One-Line Model
• Chapter 2: The C Abstract Machine and Undefined Behavior
• Chapter 3: Stack, Heap, and the Memory-Defect Families
• Chapter 4: Integer Arithmetic Before Memory Arithmetic
• Chapter 5: Parsers — Parse, Don't Guess
• Chapter 6: Parser Differentials as Vulnerabilities
• Chapter 7: Executable Formats and the Loader
• Chapter 8: The Syscall Boundary and File Descriptors as Capabilities
• Chapter 9: CPU Architecture — Registers, Calling Conventions, Control Flow
• Chapter 10: Compiler and Runtime Hardening
• Chapter 11: What Rust and Go Remove — and What Remains
• Chapter 12: Fuzzing, Sanitizers, and Crash Triage
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes
• Interview Q&A
• References

Chapter 1: Where Security Bugs Live — The One-Line Model

Zero background. A memory-safety vulnerability is not magic; it is a place where the program's assumptions about bytes diverge from the actual bytes an attacker supplied. Almost every low-level security bug fits one mental model:

untrusted bytes → length/offset arithmetic → allocation → object lifetime → privileged action

Each arrow is a place an assumption can break: bytes get interpreted as a structure that doesn't match; arithmetic on a length wraps or underflows; an allocation is the wrong size; an object is used after its lifetime ends; a privileged operation trusts a value it shouldn't. The entire phase is about making each arrow provably correct.

Why this matters for a security engineer specifically. You are not just trying to write correct code — you are trying to write code whose correctness survives an adversary choosing the worst possible input. A function that works for every "reasonable" input and corrupts memory on one crafted input is, to an attacker, a feature. Your job is to think in terms of what input maximizes damage, then prove that input is rejected.

Misconception to kill now. "Memory bugs are a solved problem; just use a safe language." Safe languages remove whole classes of bugs (Chapter 11), but (a) the world runs on enormous C/C++ codebases you will audit, (b) safe languages still have logic bugs, resource-exhaustion bugs, and unsafe/FFI escape hatches, and (c) understanding why the bugs exist is what lets you design the safe replacement. You cannot defend a boundary you don't understand.

Chapter 2: The C Abstract Machine and Undefined Behavior

The key idea. C is not "portable assembly." The C standard defines an abstract machine with rules, and the compiler is only obligated to make your program behave correctly if you obey the rules. Break a rule and you hit undefined behavior (UB): the standard imposes no requirements at all. The program may crash, may produce wrong output, or may appear to work — and crucially, the optimizer is allowed to assume UB never happens and delete the code that would have handled it.

Pointer provenance. A C pointer is valid only for a specific object, with a specific lifetime, alignment, and set of permitted operations. An address that merely happens to be mapped in the process is not automatically a valid C pointer. Indexing past the end of an array, dereferencing a freed pointer, or reading uninitialized memory are all UB even if the underlying memory page is readable.

Why UB is a security problem, not just a correctness problem. Consider:

char buf[8];
if (idx < 0) return ERR;          // signed check
buf[idx] = x;                      // attacker controls idx

If the optimizer can prove that an out-of-range idx would be UB, it may assume idx is in range and remove a redundant-looking bounds check elsewhere. UB doesn't just let the bad thing happen; it can erase the very checks you wrote to prevent it. This is why "it compiled and ran on my machine" proves nothing about safety.

Production significance. Auditors read C for UB constantly: signed-overflow assumptions, strict-aliasing violations, out-of-bounds, use-after-free, and memcpy with a tainted length. Tools that find UB (UBSan, ASan — Chapter 12) are how you turn "looks fine" into "proven on this input."

Misconception to kill now. "If it doesn't crash, it's fine." UB that doesn't crash is the more dangerous case — it's a latent corruption an attacker can steer.

Chapter 3: Stack, Heap, and the Memory-Defect Families

Stack vs heap — what they actually are. The stack is a region the CPU grows and shrinks automatically as functions call and return; each call pushes a stack frame holding local variables, saved registers, and the return address (where to resume after the function returns). The heap is memory you request explicitly (malloc/new) and must release (free/delete); an allocator tracks free and used chunks, often with metadata stored inline between chunks. Stack and heap are allocation strategies, not security levels — both can be corrupted.

Why a stack overflow is dangerous. A write past the end of a local array can overwrite the saved return address or adjacent locals. Historically this enabled redirecting execution; today, mitigations (Chapter 10) make it harder but the corruption is still a bug and often still exploitable.

The memory-defect families — the vocabulary you must own:

• Out-of-bounds read/write (OOB). An index, pointer, or length escapes the object's bounds. Reads leak adjacent data; writes corrupt it.
• Use-after-free (UAF) / double-free. A pointer is used after the object's lifetime ended. Dangerous because the allocator may have handed those bytes to a new owner — now two pieces of code disagree about what lives there.
• Integer overflow / truncation. The validated number differs from the number actually used to allocate or copy (Chapter 4).
• Uninitialized read. Stale memory contents influence output or control flow — can leak secrets or create nondeterministic logic.
• Race / TOCTOU (time-of-check-to-time-of-use). The object checked is not the object used, because another thread or process changed it in between.
• Type confusion. Memory is interpreted as the wrong type (common in C++ with bad casts), so a field meant to be data is treated as a pointer or vtable. (A vtable is the hidden table of function pointers C++ uses to dispatch virtual methods; if an attacker controls what an object's vtable pointer points at, they choose which function the next virtual call invokes.)

Production significance. When you triage a crash (Phase 08), the first job is to classify it into one of these families, because the family determines exploitability reasoning and the right fix.

Misconception to kill now. "A read OOB is harmless." Information-disclosure OOB reads (Heartbleed being the canonical example) leak keys and tokens and are frequently critical.

Chapter 4: Integer Arithmetic Before Memory Arithmetic

The insight that prevents most length bugs. Memory corruption usually starts in integer math, before any memcpy. The classic mistake:

size_t bytes = count * element_size;     // can overflow / wrap
if (bytes > remaining) return ERROR;     // validates the WRAPPED value
memcpy(dst, src, bytes);

If count * element_size overflows size_t, it wraps to a small number; the check passes; but the intended size was huge. The fix checks the operands before multiplying:

if (element_size != 0 && count > SIZE_MAX / element_size) return ERROR;  // no overflow possible
size_t bytes = count * element_size;
if (bytes > remaining || bytes > configured_limit) return ERROR;          // bounded

The other integer traps:

• Signed→unsigned conversion. Converting a negative int to size_t yields a gigantic value. A check like if (len > max) passes the wrong way if len was negative and got widened.
• Truncation. Storing a 64-bit length in a 32-bit field silently drops the high bits.
• Underflow. remaining - field_len underflows to a huge number if you didn't first prove field_len <= remaining.
• Implicit promotion. C promotes small types to int in arithmetic; the resulting type and signedness can surprise you. Know the exact types in the expression.

Production significance. "Validate lengths before you trust them, and check operands before the operation" is the single highest-leverage habit in C/C++ auditing. A large fraction of CVEs in parsers reduce to one missing operand check.

Misconception to kill now. "I checked the result is within bounds." Checking the result of an overflowing operation validates the wrapped value, not the intended one. Check the inputs.

Chapter 5: Parsers — Parse, Don't Guess

Why parsers are the front line. A parser is where untrusted bytes first become structured data. Every byte that later flows into a length, an offset, an identity, or a privileged action came through a parser. A parser that "guesses" — accepts ambiguous input and does its best — hands that ambiguity to everything downstream.

The eight rules of a secure parser (the flagship TLV — Tag-Length-Value — lab enforces these):

1. Bound the total input before parsing anything.
2. Verify a complete fixed header exists before indexing into it.
3. For each field, check its length against both a per-field limit and the remaining bytes (length <= max AND length <= remaining).
4. Reject duplicate singleton / security fields (e.g. two "tenant identity" fields).
5. Reject unknown critical fields (fields the spec says must be understood).
6. Decode text strictly (reject invalid UTF-8 rather than substituting).
7. Consume exactly one message — no trailing bytes left unexplained.
8. Return structured errors that say what failed without echoing the raw input back.

Why rule 3 needs both clauses. length <= max alone allows a field that claims a legal size but extends past the buffer — an OOB read. length <= remaining alone allows a field within the buffer but larger than the protocol permits — a resource or logic abuse. You need both.

Why rules 4 and 7 are about security, not tidiness. A duplicate identity field lets two components pick different identities (Chapter 6). Trailing bytes let one component stop after message 1 while another reads a hidden message 2. Both are parser differentials — the most underappreciated bug class in protocol security.

Production significance. Length-prefixed and TLV formats are everywhere: TLS records, protobuf, ASN.1/X.509 certificates, image and font files, network protocols. The discipline here is exactly what you'll apply auditing any of them.

Chapter 6: Parser Differentials as Vulnerabilities

Zero background. A parser differential occurs when two components that process the same bytes disagree about what those bytes mean. Security breaks at the disagreement.

Anatomy. A parser has a cursor (position), remaining length, grammar state, a resource budget, and semantic context. Four levels of validation:

• Syntactic: the bytes form a structurally valid message.
• Semantic: the message is meaningful in this transaction (right type, right identity).
• Canonicalization: there is one chosen representation (no two encodings of the same thing).
• Exact consumption: no second interpretation hides after the first.

The classic exploits this prevents:

• HTTP request smuggling: a front-end proxy and a back-end server disagree about where one request ends (e.g. Content-Length vs Transfer-Encoding), so the attacker smuggles a second request past the proxy's authorization.
• Certificate/identity confusion: a signature verifier and an application disagree about which field is the subject identity, so a signed-but-attacker-chosen name is trusted.
• Cache poisoning: a cache keys on one interpretation of the request while the origin serves another.

The defense, stated once: define a single policy for duplicate fields, whitespace, encodings, integer forms, unknown-critical fields, and trailing data — and make every component on the path enforce the same policy. When the flagship lab makes you fuzz a C and a Rust implementation of the same TLV format and compare accept/reject results, any disagreement is a finding — that's a parser differential in miniature.

Misconception to kill now. "It's just strictness for its own sake." No — leniency in a parser is the attack surface. "Be liberal in what you accept" is a robustness maxim that has cost the industry a thousand CVEs.

Chapter 7: Executable Formats and the Loader

Why a security engineer reads binary formats. You will analyze programs you don't have source for, verify hardening flags, and understand what the loader trusts. The three formats:

• ELF (Linux/Unix) — Executable and Linkable Format.
• PE (Windows) — Portable Executable.
• Mach-O (macOS/iOS) — Mach object format.

All three describe the same things in different layouts: segments/sections (code, data), symbols (named functions/variables), imports (external functions to resolve), relocations (addresses to fix up at load time), permissions (read/write/execute per region), and an entry point.

What the loader actually does. When you run a program, the loader: maps the executable's segments into memory, assigns each the right permissions, applies relocations, loads shared libraries it depends on, sets up runtime state, and jumps to the entry point. Each of these is a trust decision — e.g. where it finds libraries (search path) is a classic hijack surface.

The hardening questions you ask of any binary (the binary-hardening lab makes you extract these without shelling out):

• Is any writable memory also executable (W^X violation)? Writable+executable pages are an attacker's dream.
• Is the binary position-independent (PIE) so ASLR can randomize it?
• Are stack canaries, RELRO (read-only relocations), and CFI present?
• Which libraries and symbols does it import — i.e., how big is the attack surface?

Production significance. "Is this build hardened?" is a real question in supply-chain review (Phase 03) and incident response (Phase 09). Reading the format yourself, rather than trusting a tool's summary, is how you answer it precisely.

Chapter 8: The Syscall Boundary and File Descriptors as Capabilities

Zero background — the user/kernel boundary. Application code runs in user mode with limited privilege. To touch files, processes, memory, devices, or the network, it must ask the kernel via a system call (syscall) — a controlled transition into privileged mode. The syscall interface is the security boundary of an OS: everything dangerous a process can do, it does through a syscall.

Why this matters for sandboxing (foreshadowing Phase 06). If you can restrict which syscalls a process may make (seccomp), you shrink what a compromised process can do — even if its code is fully controlled by an attacker. The syscall tracer and syscall-policy labs make you observe the actual syscalls a program needs, so you can write a least-privilege allowlist.

File descriptors are capabilities — the crucial idea. A file descriptor (an integer handle to an open file, socket, directory, or device) is an unforgeable token of access. A process that inherits an already-open descriptor to a secret file or a socket can use it without ever calling open — so an allowlist that blocks open but ignores inherited descriptors is incomplete. This is why you review:

• execve and what descriptors survive it (CLOEXEC flag closes them on exec — its absence leaks capabilities to child processes),
• the environment and current working directory (both influence what a child trusts),
• signal handlers and child cleanup.

Production significance. "What can this process actually do?" is answered by enumerating its syscalls and its inherited descriptors, environment, and namespaces — not just its source code.

Misconception to kill now. "Dropping privileges means dropping the user ID." Privilege is the union of UID, capabilities, namespaces, open descriptors, and syscall access. Lower the UID but leave a root-owned socket open and you've dropped nothing that matters.

Chapter 9: CPU Architecture — Registers, Calling Conventions, Control Flow

Why a defender reads assembly. To triage a crash, understand a patch diff, or reverse a binary (Phase 08), you must read a little machine code. You don't need to write assembly; you need to reconstruct what a function does from it.

Registers. Small, fast CPU storage. On x86-64, general-purpose registers include rax, rdi, rsi, rdx, etc.; rsp is the stack pointer, rip the instruction pointer. On ARM64 (AArch64), x0–x30 are general-purpose, sp the stack pointer, lr (x30) the link register holding the return address.

Calling conventions (ABIs). The agreed rules for how functions pass arguments and return values. On the System V AMD64 ABI (Linux/macOS), the first integer arguments go in rdi, rsi, rdx, rcx, r8, r9, return value in rax. On AArch64, arguments go in x0–x7, return in x0. Knowing this lets you read "what was passed to this function" straight from a crash dump.

Stack frames and control flow. A call pushes the return address; the function may set up a frame; ret pops the return address into the instruction pointer. The return address living on the stack is exactly why stack buffer overflows historically hijacked control — and why stack canaries and shadow stacks exist (Chapter 10). Reconstructing control flow means following the conditional branches (jne, b.eq) to rebuild the if/else and loop structure.

Production significance. The toy-debugger and syscall-tracer labs make this concrete: you set breakpoints, read registers, and watch arguments flow into syscalls. That is the same skill applied at scale in a decompiler.

Chapter 10: Compiler and Runtime Hardening

These mitigations don't make bugs correct; they make them harder to exploit. Know what each does and what it does not cover:

• ASLR (Address Space Layout Randomization) — randomizes where code/stack/heap land, so an attacker can't hardcode addresses. Defeated by an information leak that reveals a real address.
• NX / DEP / W^X — writable pages are non-executable, so injected data can't run as code. Pushed attackers toward reuse of existing code (ROP — return-oriented programming).
• Stack canaries — a random value placed before the return address; corrupted by an overflow and checked on return. Detects contiguous stack overwrites, not targeted writes.
• RELRO (RELocation Read-Only) — makes the relocation and GOT tables read-only after startup. (The Global Offset Table is the per-process table of resolved addresses for imported library functions; while it's writable, an attacker who can write memory overwrites one entry to redirect a library call to code of their choosing — RELRO closes that classic function-pointer overwrite.)
• CFI (Control-Flow Integrity) — constrains indirect branches to valid targets, blunting ROP and vtable hijacks.
• Pointer Authentication (PAC) on ARM64 — signs selected pointers (e.g. return addresses) so tampering is detected.