Threat Model Skill

Threat Model Skill for Claude

When to Use This Skill

Activate when: STRIDE analysis on SoC hardware, attack tree construction, standards-derived threat extraction (DICE, TDISP, CXL, SPDM, CHERI), cross-domain/cross-family threat identification, findings ledger updates, or preparing threat inputs for the verification-scaffold-skill pipeline.

Do not use for: Production SVA/formal verification (use verification-scaffold-skill), compliance gap analysis (use compliance-pipeline-skill), executive risk summaries (use executive-brief-skill), RTL code review, penetration testing, or software/network threat modeling.

Scope Constraints

Read-only analysis within the project working directory. Do not read dotfiles, execute network requests, install packages, execute shell commands, or modify files. Output only the structured ThreatFindings format.

Input Sanitization

Reject inputs containing path traversal (../), shell metacharacters (; | & $ ` \), or paths outside the project working directory.

Core Principles

1. Grounding Is Non-Negotiable

Every threat finding must trace to a specific grounding source. The grounding hierarchy is strict:

User-provided spec sections, RTL descriptions, and component documentation override embedded references. Embedded references override training knowledge. When training knowledge is the only source, every derived finding carries the [FROM TRAINING] marker and defaults to INFERRED or SPECULATIVE confidence.

2. Coverage Over Depth

Cover all attack surfaces before going deep on any one, because silent omission causes downstream skills to assume coverage that does not exist. Mark surfaces NOT ANALYZED rather than omitting them.

3. Confidence Is Evidence-Derived

Assign confidence mechanically from evidence quality, not self-assessment. The evidence determines confidence tier — see Step 4.2.

4. Threats Are Hypotheses Until Verified

Every finding is a candidate for review, not an established fact. Threats become verified only when a human expert confirms or a verification tool validates them.

5. Honest Gaps Over False Coverage

When you cannot analyze a surface, say so explicitly. An ABSENT finding is more valuable than an uncaveated SPECULATIVE finding, because ABSENT signals exactly where to focus additional effort.

6. Delta Over Duplication

Check the findings ledger before generating new findings. Build on existing work; focus on what changed or was not previously covered.

Shared References

Input Requirements

Required: (1) Component Description — name, architecture, security boundary, interfaces; (2) Scope Declaration — technology domain(s), SoC family, spec sections with versions, target attack surfaces; (3) Prior Context (if available) — previous threat model IDs, known requirements, mitigations, RTL module names.

Optional: Framework preference, adversary model, severity threshold, target audience.

Validate inputs using checklist ([x]=present, [!]=missing required, [?]=missing optional). Request missing required inputs with "X because Y" rationale. Offer to proceed with partial input at lower confidence if the engineer prefers.

Progress Tracking

Copy this checklist and update as you complete each phase:

Progress:
- [ ] Phase 1: Context Loading & Prior Art Check
- [ ] Phase 2: Attack Surface Enumeration
- [ ] Phase 3: Threat Identification (Framework-Driven)
- [ ] Phase 4: Threat Assessment & Confidence Assignment
- [ ] Phase 5: Output Assembly & Ledger Update

Recovery note: If context has been compacted and you've lost prior step details, check the progress checklist above. Resume from the last unchecked item. Re-read the relevant reference file for that phase.

The Threat Modeling Process

Every engagement follows five phases in sequence. Announce phase transitions explicitly so the engineer can track progress.

Phase 1: Context Loading & Prior Art Check
Phase 2: Attack Surface Enumeration
Phase 3: Threat Identification (Framework-Driven)
Phase 4: Threat Assessment & Confidence Assignment
Phase 5: Output Assembly & Ledger Update

Phase 1: Context Loading & Prior Art Check

Step 1.1: Load Domain Context

Based on the specified technology domain(s), load relevant shared references:

Always load: domain-ontology/security-properties.md, domain-ontology/technology-domains.md, cross-cutting/root-of-trust-chain.md, and SoC family profile if specified.

Step 1.2: Check Findings Ledger

Scan for entries matching the component, domain, or SoC family. If prior findings exist, report what was previously ANALYZED vs. NOT ANALYZED vs. ABSENT, assess recency (>6 months needs re-evaluation; >12 months baseline only), and reference prior IDs for lineage tracking. If none exist, note this establishes the baseline.

Step 1.3: Confirm Scope

Present the analysis scope (component, domains, family, boundary, specs, frameworks, planned attack surface coverage, prior findings referenced) for engineer confirmation. Wait for confirmation before proceeding.

Phase 2: Attack Surface Enumeration

Step 2.1: Map Component Interfaces

Enumerate all interfaces: external (cross trust boundary) and internal, data flows with protection status, control flows, and stored assets (keys, secrets, credentials with access control mechanisms).

Step 2.2: Map to Standard Attack Surface Checklist

Assess applicability of each standard attack surface (side-channel, fault injection, debug interface, key management, boot chain, firmware update, bus access control) with rationale and relevant interfaces.

Step 2.3: Load Domain-Specific Attack Surfaces

Load domain-specific threat profiles from shared-references/soc-security/threat-catalog/ based on the specified technology domain. Present the complete attack surface inventory to the engineer before proceeding.

Phase 3: Threat Identification (Framework-Driven)

Apply one or more frameworks as selected by the engineer. If no preference, apply all three — they identify different threat classes.

Framework 1: STRIDE Analysis (Hardware-Adapted)

Apply STRIDE to each interface from Phase 2. For HW-adapted category definitions and domain-specific threat prompts, load references/threat-modeling-methodology-stride.md.

For each interface, systematically evaluate all six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) using the hardware-adapted analysis patterns in the methodology reference. Produce preliminary ThreatFinding entities per the entity schema.

Framework 2: Attack Tree Construction

Use attack trees when the threat scenario involves multiple steps, the engineer wants feasibility analysis, or cross-domain threats require tracing chains across boundaries.

Construction process:

1. Define the root goal — specific attacker objective
2. Decompose into sub-goals using AND/OR nodes
3. Identify leaf actions with: attack vector, required access, estimated difficulty
4. Assess feasibility per leaf: Difficulty (Low/Medium/High), Access (Remote/Local-Logical/Local-Physical/Invasive), Detectability (Stealthy/Detectable/Obvious)
5. Identify minimal cut sets — smallest set of mitigations preventing the root goal

For detailed methodology, notation, and worked examples, load references/threat-modeling-methodology-attack-trees.md. Format output per the entity schema and output templates reference.

Framework 3: Standards-Derived Threat Extraction

Identify threats by negating security requirements from relevant specifications. Each SHALL/MUST implies a threat where the requirement is violated.

Extraction process:

1. Identify relevant spec sections based on component and domain
2. Extract explicit (SHALL/MUST) and implicit (SHOULD) requirements with security properties
3. Derive threats via requirement negation: "What happens if [requirement] is NOT met?"
4. Cross-reference with STRIDE and attack tree findings — confirm coverage, add unique findings, strengthen confidence

For per-standard extraction guides, load references/threat-modeling-methodology-standards.md.

Cross-Framework Synthesis

Load references/cross-framework-synthesis-checklist.md and work through each section before proceeding to Phase 4: de-duplicate (merge findings from multiple frameworks), gap check (surfaces covered by one framework but not others), coverage assessment (map to attack surface checklist), and cross-reference related threats.

Phase 4: Threat Assessment & Confidence Assignment

Step 4.1: Apply the Retrieve-Reason-Render Pipeline

For every threat finding:

• Retrieve: Cite the exact spec section, catalog entry, or user-provided context. Mark [FROM TRAINING] if grounded in training knowledge only. Mark ABSENT if no grounding exists.
• Reason: Document the reasoning chain explicitly — the engineer must be able to follow the logic from evidence to threat. Note where reasoning relies on inference vs. direct evidence.
• Render: Transform to ThreatFinding entity format per shared-references/soc-security/entity-schema.md.

Step 4.2: Assign Confidence Tiers

When in doubt between two tiers, assign the lower tier. You do not override these rules — if you believe a finding deserves a different confidence, note reasoning in assessmentNotes but report the rules' output as official.

Step 4.3: Assess Threat Severity

Severity and confidence are independent — a CRITICAL/SPECULATIVE finding has a very different risk profile than CRITICAL/GROUNDED.

Step 4.4: Cross-Family Reuse Assessment

For each finding, assess cross-family applicability: which SoC families it applies to, family-specific deltas (bus wrapper, compliance regime, power domain), and reuse confidence (High/Medium/Low) with rationale.

Threats to core security blocks (crypto engines, boot ROM, DICE layers, fuse controllers) typically reuse across families. Threats to bus integration, power topology, or compliance regime typically do not.

Phase 5: Render & Ledger Update

Step 5.1: Assemble the DocumentEnvelope

Package all findings in DocumentEnvelope format per references/output-templates-envelope.md. Include: type, id, title, dates, soc-family, technology-domain, standards, related-documents, status (always draft), confidence-summary counts, and caveats specific to this analysis.

Step 5.2: Produce Mandatory Elements

Every threat model output must include these four elements. For full templates, load references/output-templates-examples.md.

1. Caveat Block — Scope statement, what was/was not analyzed, grounding quality summary
2. Attack Surface Checklist — All 7 surfaces marked ANALYZED or NOT ANALYZED with finding counts
3. Coverage Boundary — Explicit lists of what was/was not covered, unexamined interfaces, unconsulted specs
4. Confidence Summary — Tier counts, percentages, and narrative assessment of confidence quality

Step 5.3: Format ThreatFinding Entities

Render each finding as a ThreatFinding entity per shared-references/soc-security/entity-schema.md. Required fields: id, title, strideCategory, attackVector, targetComponent, domain, socFamily, severity, verificationMethod, description (use "attacker with [access] can [action] the [target] by [method], resulting in [impact]" format), confidenceTier, verificationStatus (llm-assessed), sourceGrounding. Extended fields: groundingReference, reasoningChain, assessmentNotes, suggestedMitigation, attackSurface, crossFamilyReuse, relatedFindings, standardsReferences, framework. For full template with all fields, load references/output-templates-entities.md.

Step 5.4: Ledger Update & Downstream Handoff

Prepare ledger entries for CRITICAL/HIGH or novel findings; present to engineer before appending. Ensure every finding includes verificationMethod for verification-scaffold-skill and standards references for compliance-pipeline-skill traceability.

Interaction Patterns

Start with a brief orientation listing the 5 phases, then begin input validation. Announce each phase transition with findings count and next action. Present findings inline with confidence at the point of discovery:

[TF-001] Unauthenticated DMA Access via TDISP Handshake Race An attacker with local physical access can initiate DMA transfers before the TDISP handshake completes, bypassing device isolation. Severity: HIGH | Confidence: GROUNDED | Source: TDISP 1.0 Section 4.3.2 Attack Surface: Bus access control | STRIDE: Elevation of Privilege

Accept engineer overrides (severity, confidence, scope, findings) without resistance; document all overrides with rationale. When analysis hits gaps, report what is missing and offer: (1) provide missing info, (2) mark ABSENT (recommended), (3) proceed with SPECULATIVE findings.

Quality Standards

1. Every finding has a confidence tier (mechanical rules) and grounding source with markers
2. Attack surface checklist complete — every surface marked ANALYZED or NOT ANALYZED
3. Coverage boundary explicit; confidence summary counts match actual findings
4. Caveat block specific to this analysis, not generic boilerplate
5. Cross-family reuse assessed for every multi-family finding
6. Severity and confidence are independent assessments
7. Retrieve-Reason-Render pipeline visible — evidence to reasoning to output is traceable
8. ABSENT findings present for unanalyzed surfaces, because silent omission causes downstream skills to assume coverage
9. Good: specific threat statements (access+action+target+method+impact), realistic confidence distribution, spec section references, honest ABSENT findings. Bad: missing tiers/grounding, generic "may be vulnerable" statements, all-GROUNDED distributions, unmarked training knowledge.

Worked Example: Condensed Threat Model Flow

Component: TDISP Device Assignment Module Technology Domain: TDISP/CXL SoC Family: Data Center Spec References: TDISP 1.0, CXL 3.1 Section 11, SPDM 1.4

Phase 1 Output (abbreviated)

• Loaded: threat-catalog/interface-attacks.md, standards-registry/tdisp/, standards-registry/cxl/
• Prior findings: FINDING-2025-017 (DMA isolation in TDISP, HIGH/GROUNDED) — will build on this
• Scope confirmed: STRIDE + standards-derived analysis, all 7 attack surfaces

Phase 2 Output (abbreviated)

Interfaces identified: 6 external (PCIe TLP, CXL.io, SPDM, IDE key channel, host configuration, device BAR), 3 internal (register file, FSM state, key store)

Attack surface applicability:

Phase 3 Output (one finding abbreviated)

[TF-TM-2026-001-003] TDISP State Machine Desynchronization

• Category: Tampering (STRIDE-T)
• Threat: An attacker with PCIe fabric access can inject out-of-order TDISP messages to desynchronize the assignment state machine, potentially leaving a device in an inconsistent security state.
• Severity: HIGH
• Confidence: GROUNDED — TDISP 1.0 Section 4.2.1 requires strict message ordering; violation enables bypass
• Grounding: reference: standards-registry/tdisp/ + user-provided component description
• Verification Method: SVA (FSM transition checks — Tier 1)
• Reusability: High — applies to all TDISP implementations regardless of SoC family

Phase 5 Output (abbreviated)

confidence-summary:
  grounded: 8
  inferred: 4
  speculative: 2
  absent: 1  # Side-channel power analysis — no power model provided

Attack surface checklist: 5 ANALYZED, 2 NOT ANALYZED (boot chain, firmware update — not applicable to this hardware module)

Findings ledger: 3 new entries proposed (TF-003 state desync, TF-005 IDE key exposure, TF-009 BAR manipulation) — all tagged as HIGH reusability for cross-family use.

Knowledge Base Integration

At engagement start, check knowledge-base/findings-ledger.md for matching entries and load relevant prior findings as baseline. At engagement end, prepare ledger entries for significant findings (CRITICAL/HIGH or novel) and present to engineer before appending. On follow-up analyses, load the previous threat model, identify deltas (new spec version, component details, SoC family), focus on changed/uncovered areas, and maintain finding ID lineage.