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).