# 109 Threat 1e93fae4 > - Skill: `tools-only/109-threat-1e93fae4` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/109-threat-1e93fae4` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/109-threat-1e93fae4/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tools-only/109-threat-1e93fae4 --- # STRIDE Skill Set - Knowledge Architecture v5.2 **Version**: 5.2.1 **Date**: 2026-01-04 **Status**: Production - v2.1.0 Agentic Security Updated --- ## 1. Vision Statement > **"Code-First Automated Application Security Risk Assessment and Threat Modeling Toolkit"** > > An LLM-driven automated system for: > - **Security Design Assessment** > - **Threat Modeling Assessment** > - **Infrastructure Security Assessment** > > With specialized extensions for: > - **Cloud-Native Applications** > - **LLM/AI Applications** --- ## 2. Knowledge System Architecture ### 2.1 Dual-Track Knowledge System The knowledge system consists of two parallel sets that work together: ``` ┌───────────────────────────────────────────────────────────────────────────────────────────────┐ │ Security Knowledge Architecture │ ├───────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌───────────────────────────────────────────┐ │ │ │ Security Principles │ │ │ │ (Foundation - Guides All Phases) │ │ │ │ DID │ LP │ ZT │ FS │ SOD │ SBD │ CM │ EOM │ OD │ IV │ │ └───────────────────────────────────────────┘ │ │ │ │ │ ┌─────────────────────────┴─────────────────────────┐ │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────────────────────────┐ ┌─────────────────────────────────────┐ │ │ │ Security Control Set │ │ Threat Pattern Set │ │ │ │ (What to do & How to do) │ │ (What to know & Validate) │ │ │ ├─────────────────────────────────────┤ ├─────────────────────────────────────┤ │ │ │ │ │ │ │ │ │ Security Domains (16) │ │ CWE Weakness Types (974) │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ │ │ Control Sets (18 files, 107) │ │ CAPEC Attack Patterns (615) │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ │ │ OWASP References (73) │ │ ATT&CK Techniques (835) │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ │ │ Compliance Frameworks (14) │ │ CVE/KEV Vulnerabilities (323K+) │ │ │ │ │ │ │ │ │ └──────────────┬──────────────────────┘ └──────────────┬──────────────────────┘ │ │ │ │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ Verification Set │ │ │ │ │ │ (How to verify & test) │ │ │ │ │ ├─────────────────────────────┤ │ │ │ │ │ │ │ │ │ └─────▶│ WSTG Tests (121) │◀───────┘ │ │ │ │ │ │ │ │ ▼ │ │ │ │ MASTG Tests (206) │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ ASVS Requirements (345) │ │ │ │ │ │ │ └─────────────────────────────┘ │ │ │ │ │ ▼ │ │ Used in: Phase 6 (Validation) / Phase 7 (Mitigation) / Phase 8 (Report)│ │ │ │ Cross-Set Mappings: │ │ ├── STRIDE → Security Domains ←→ CWE Weakness Types │ │ ├── Control Sets ←→ CWE Mitigations │ │ ├── CAPEC → ATT&CK Techniques │ │ ├── Compliance ←→ CWE Compliance Mappings │ │ ├── stride_verification → WSTG/MASTG/ASVS (STRIDE to Verification) │ │ └── cwe_verification → WSTG/MASTG/ASVS (CWE to Verification) │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────┘ ``` ### 2.2 Security Principles (Foundation Layer) Security Principles serve as the foundation that guides all phases of the threat modeling process. | Code | Principle | Definition | Application in Security Control | Application in Threat Analysis | |------|-----------|------------|--------------------------------|-------------------------------| | **DID** | Defense in Depth | 纵深防御 | Multiple independent security controls | Identify single points of failure | | **LP** | Least Privilege | 最小权限 | Permission control design | Detect over-privileged access | | **ZT** | Zero Trust | 零信任 | Continuous verification mechanisms | Identify implicit trust risks | | **FS** | Fail Securely | 安全失败 | Deny/degrade on failure | Detect error handling leaks | | **SOD** | Separation of Duties | 职责分离 | Multi-role collaboration | Identify privilege concentration | | **SBD** | Security by Design | 安全设计 | Built-in security | Identify retrofit vulnerabilities | | **CM** | Continuous Monitoring | 持续监控 | Real-time detection and alerting | Identify detection blind spots | | **EOM** | Economy of Mechanism | 机制简化 | Simple and verifiable | Identify complexity risks | | **OD** | Open Design | 开放设计 | No security by obscurity | Identify obscurity dependencies | | **IV** | Input Validation | 输入验证 | Boundary validation | Identify injection surfaces | ### 2.3 Security Control Set ``` Security Domains ──▶ Control Sets ──▶ OWASP References ──▶ Compliance Frameworks │ │ │ │ │ │ │ │ security- control-set- reference-set- YAML + SQLite design.yaml *.md *.md (compliance tables) ``` **Security Domains (16 total)**: | Seq | Code | Name | STRIDE | Description | |-----|------|------|--------|-------------| | 01 | AUTHN | 认证与会话 | S | Identity verification and session lifecycle | | 02 | AUTHZ | 授权访问控制 | E | Access permission enforcement | | 03 | INPUT | 输入验证 | T | External input validation and sanitization | | 04 | OUTPUT | 输出编码 | T,I | Context-aware output encoding | | 05 | CLIENT | 客户端安全 | S,T,I | Browser and client-side security | | 06 | CRYPTO | 加密与传输安全 | I | Data encryption in transit and at rest | | 07 | LOG | 日志与监控 | R | Security event logging and audit | | 08 | ERROR | 错误处理 | I | Secure error handling and information control | | 09 | API | API与服务安全 | S,T,I,D,E | API endpoint and service communication security | | 10 | DATA | 数据保护 | I | Sensitive data and credential protection | | ext-11 | INFRA | 基础设施安全 | - | Container and orchestration security | | ext-12 | SUPPLY | 供应链安全 | - | Dependency and pipeline security | | ext-13 | AI | AI/LLM安全 | - | LLM-specific threats (OWASP LLM Top 10) | | ext-14 | MOBILE | 移动端安全 | - | Mobile app security | | ext-15 | CLOUD | 云服务安全 | - | Cloud-native security controls | | ext-16 | AGENT | Agent安全 | S,T,R,I,D,E | Agent system and agentic component security (OWASP ASI) | ### 2.4 Threat Pattern Set ``` ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │ Threat Intelligence Chain │ ├─────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ L1: STRIDE L2: 威胁情报知识层 L3/L4: 验证与实时 │ │ ─────────── ──────────────────────────────────── ───────────────── │ │ │ │ ┌─────────┐ ┌───────┐ ┌───────┐ ┌─────────┐ ┌───────────────┐ │ │ │ STRIDE │─────▶│ CWE │─────▶│ CAPEC │─────▶│ ATT&CK │─────▶│ CVE/KEV │ │ │ │ 6类别 │ │ 弱点 │ │ 攻击 │ │ 技术 │ │ 漏洞/已利用 │ │ │ └─────────┘ └───────┘ └───────┘ └─────────┘ └───────────────┘ │ │ │ │ │ │ │ │ │ stride- SQLite:cwe SQLite:capec SQLite:attack_* SQLite:cve + API │ │ library.yaml (974条) (615条) (835条) (323K+) │ │ │ │ 映射表: stride_cwe → capec_cwe → capec_attack → cve_cwe │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────┘ ``` #### L1: STRIDE 威胁分类模型 STRIDE 是威胁情报体系的基础层，定义6大威胁类别： | STRIDE | 英文名 | 中文 | 违反的安全属性 | 存储位置 | |--------|--------|------|----------------|----------| | **S** | Spoofing | 身份伪造 | 认证 (Authentication) | stride-library.yaml | | **T** | Tampering | 数据篡改 | 完整性 (Integrity) | stride-library.yaml | | **R** | Repudiation | 抵赖 | 不可否认性 (Non-repudiation) | stride-library.yaml | | **I** | Information Disclosure | 信息泄露 | 机密性 (Confidentiality) | stride-library.yaml | | **D** | Denial of Service | 拒绝服务 | 可用性 (Availability) | stride-library.yaml | | **E** | Elevation of Privilege | 权限提升 | 授权 (Authorization) | stride-library.yaml | #### L1→L2 映射关系 ``` L1 STRIDE 类别 → L2 威胁情报知识: ───────────────────────────────────────────────────────────────────────────── S(身份伪造) → CWE-287/290/307 → CAPEC-151/194/600 → T1078/T1110 → CVE-* T(数据篡改) → CWE-20/77/89 → CAPEC-66/88/248 → T1190/T1059 → CVE-* R(抵赖) → CWE-117/223/778 → CAPEC-93/268 → T1070/T1562 → CVE-* I(信息泄露) → CWE-200/209/311 → CAPEC-116/157/497 → T1552/T1213 → CVE-* D(拒绝服务) → CWE-400/770/918 → CAPEC-125/227/469 → T1498/T1499 → CVE-* E(权限提升) → CWE-269/284/862 → CAPEC-122/233/17 → T1068/T1548 → CVE-* ``` #### L2: 威胁情报知识层 **STRIDE to CWE Mapping Chain**: | STRIDE | OWASP Top 10 | Primary CWEs | Typical Attack Patterns | |--------|--------------|--------------|------------------------| | S (Spoofing) | A07 Auth Failures | CWE-287, 290, 307 | CAPEC-151, 194, 600 | | T (Tampering) | A03 Injection | CWE-20, 77, 78, 89 | CAPEC-66, 88, 248 | | R (Repudiation) | A09 Logging Failures | CWE-117, 223, 778 | CAPEC-93 | | I (Info Disclosure) | A02 Crypto Failures | CWE-200, 209, 311 | CAPEC-116, 157 | | D (DoS) | A10 SSRF | CWE-400, 770, 918 | CAPEC-125, 227 | | E (Elevation) | A01 Access Control | CWE-269, 284, 862 | CAPEC-122, 233 | ### 2.5 Verification Set (Cross-Cutting) The Verification Set bridges both Security Control Set and Threat Pattern Set, providing test procedures to validate controls and verify threats. ``` ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │ Verification Set Structure │ ├─────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ WSTG (Web Security Testing Guide) - 121 Tests │ │ │ │ Categories: INFO, CONF, IDNT, ATHN, AUTHZ, SESS, INPV, ERRH, CRYP, BUSL, │ │ │ │ CLNT, APIT │ │ │ │ Storage: SQLite (wstg_test table) │ │ │ │ Mappings: stride_verification, cwe_verification │ │ │ └──────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ MASTG (Mobile App Security Testing Guide) - 206 Tests │ │ │ │ Categories: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, │ │ │ │ MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE │ │ │ │ Storage: SQLite (mastg_test table) │ │ │ │ Mappings: stride_verification, cwe_verification │ │ │ └──────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ ASVS (Application Security Verification Standard) - 345 Requirements │ │ │ │ Levels: L1 (Essential), L2 (Standard), L3 (Advanced) │ │ │ │ Chapters: V1-V14 (Architecture to API, Config, Storage, Crypto, etc.) │ │ │ │ Storage: SQLite (asvs_requirement table) │ │ │ │ Mappings: stride_verification, cwe_verification │ │ │ └──────────────────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────┘ ``` **STRIDE to Verification Mapping**: | STRIDE | Verification Categories | Test Count | |--------|------------------------|------------| | S (Spoofing) | WSTG-IDNT, WSTG-ATHN, WSTG-SESS, MASTG-AUTH | 27 | | T (Tampering) | WSTG-INPV, WSTG-CONF, MASTG-PLATFORM | 34 | | R (Repudiation) | WSTG-BUSL, ASVS-V7 (Error/Logging) | 11 | | I (Info Disclosure) | WSTG-INFO, WSTG-ERRH, WSTG-CRYP, MASTG-STORAGE | 31 | | D (DoS) | WSTG-BUSL, WSTG-APIT | 15 | | E (Elevation) | WSTG-AUTHZ, MASTG-AUTH, ASVS-V4 (Access) | 16 | **SQLite Verification Tables**: | Table | Content | Records | Purpose | |-------|---------|---------|---------| | `wstg_test` | Web security test procedures | 121 | Web application testing | | `mastg_test` | Mobile security test procedures | 206 | Mobile app testing | | `asvs_requirement` | Security verification requirements | 345 | Compliance verification | | `stride_verification` | STRIDE → Test mappings | - | Phase 6 validation | | `cwe_verification` | CWE → Test mappings | - | CWE-based testing | | `verification_procedure` | Detailed test procedures | - | POC/Test case generation | **Query Commands**: ```bash # Get verification tests for STRIDE category unified_kb_query.py --stride-tests S # Get verification tests for CWE unified_kb_query.py --cwe-tests CWE-89 # Get ASVS requirements for compliance unified_kb_query.py --asvs-level L2 --chapter V4 # Get WSTG tests for specific category unified_kb_query.py --wstg-category ATHN ``` **Phase Usage**: | Phase | Verification Set Usage | |-------|----------------------| | Phase 6 | `stride_verification` + `cwe_verification` → Generate test cases for each risk | | Phase 7 | `asvs_requirement` → Verify mitigation meets security requirements | | Phase 8 | `asvs_requirement` + Compliance mapping → Report compliance status | --- ## 3. Eight-Phase Workflow with Data Flow ### 3.1 Phase Overview ``` ┌──────────────────────────────────────────────────────────────────────────────────────────────────┐ │ 8-Phase Deep Threat Modeling Workflow │ ├──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ Phase 1 │──▶│ Phase 2 │──▶│ Phase 3 │──▶│ Phase 4 │──▶│ Phase 5 │──▶│ Phase 6 │──▶│ Phase 7 │──▶│ Phase 8 │ │ │ Project │ │ DFD │ │ Trust │ │Security │ │ STRIDE │ │ Risk │ │Mitigate │ │ Report │ │ │ Ctx │ │ Analysis│ │Boundary │ │ Design │ │Analysis │ │Validate │ │ Plan │ │Generate │ │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ │ findings_1 findings_2 findings_3 findings_4 findings_5 validated_ mitigation_ final_ │ [project_ctx] [dfd_issues] [boundary_ [design_gaps] [threat_inv] risks plan report │ issues] │ │ │ ════════════════════════════════════════════════════════════════════════════════════════════════│ │ Execution Mode: Strictly Sequential (Phase N must complete before Phase N+1) │ │ Parallel Support: Phase 5/6/7 can spawn parallel sub-agents for individual risk items │ └──────────────────────────────────────────────────────────────────────────────────────────────────┘ ``` ### 3.2 Phase Data Flow Specification #### Phase 1: Project Understanding | Attribute | Value | |-----------|-------| | **Type** | Exploratory | | **Input** | Project code tree | | **Knowledge** | Security Principles | | **Script** | `list_files.py --detect-type` | | **Output** | `findings_1`: Project context, tech stack, entry points, dependencies | ```yaml findings_1: project_type: web|api|microservice|ai|mobile tech_stack: [framework, language, database, ...] entry_points: [routes, handlers, main, ...] dependencies: [packages, external_services, ...] initial_concerns: [potential_issues, ...] ``` --- #### Phase 2: Call Flow & DFD Analysis | Attribute | Value | |-----------|-------| | **Type** | Constructive | | **Input** | `findings_1` + Source code | | **Knowledge** | Security Principles + `security-design.yaml` (for security-relevant flow identification) | | **Script** | - (Claude native capability) | | **Output** | `findings_2`: DFD elements, data flow issues | ```yaml findings_2: dfd_elements: processes: [{id, name, description, security_aspects}, ...] data_stores: [{id, name, data_types, sensitivity}, ...] data_flows: [{id, source, target, data_type, protocol}, ...] external_entities: [{id, name, trust_level}, ...] dfd_issues: # Issues discovered during DFD analysis - {id: "DFD-001", category: "data_flow", description: "...", severity: "..."} ``` **Knowledge Reference**: `security-design.yaml` provides security domains context for identifying security-relevant data flows (authentication flows, authorization checkpoints, sensitive data paths). --- #### Phase 3: Trust Boundaries | Attribute | Value | |-----------|-------| | **Type** | Evaluative | | **Input** | `findings_1` + `findings_2` + Source code | | **Knowledge** | Security Principles + `security-design.yaml` (for boundary placement criteria) | | **Script** | - (Claude native capability) | | **Output** | `findings_3`: Trust boundaries, boundary crossing issues | ```yaml findings_3: trust_boundaries: - {id: "TB-1", name: "Internet/DMZ", elements: [...], controls_expected: [...]} - {id: "TB-2", name: "DMZ/Internal", elements: [...], controls_expected: [...]} boundary_crossings: - {flow_id, boundary_id, direction, authentication_required, current_state} boundary_issues: # Issues discovered during boundary analysis - {id: "TB-001", category: "trust_boundary", description: "...", severity: "..."} ``` **Knowledge Reference**: `security-design.yaml` core domains (AUTHN, AUTHZ, API) provide expected controls at trust boundaries. --- #### Phase 4: Security Design Assessment | Attribute | Value | |-----------|-------| | **Type** | Evaluative | | **Input** | `findings_1` + `findings_2` + `findings_3` (cumulative context) | | **Knowledge** | `security-design.yaml` + `security-controls/*.md` + `references/*.md` (progressive loading) | | **Script** | `--control {domain}`, `--stride-controls {category}` | | **Output** | `findings_4`: Security design gaps | **Knowledge Loading Strategy**: 1. Load `security-design.yaml` - Get all 16 domains with core requirements 2. For each relevant domain, load corresponding `control-set-*.md` 3. When specific implementation details needed, load `reference-set-*.md` ```yaml findings_4: assessed_domains: - domain: AUTHN status: partial|missing|implemented gaps: [{control_id, description, severity}, ...] evidence: [code_locations, ...] - domain: AUTHZ status: ... design_issues: # Issues discovered during design assessment - {id: "SD-001", domain: "AUTHN", control: "MFA", description: "...", severity: "..."} ``` --- #### Phase 5: STRIDE Analysis | Attribute | Value | |-----------|-------| | **Type** | Enumerative | | **Input** | `findings_2` (DFD elements) + `findings_3` (boundaries) | | **Knowledge** | CWE → CAPEC mapping (Threat Pattern Set) | | **Script** | `unified_kb_query.py --stride`, `--full-chain CWE-XXX`, `--all-llm` | | **Output** | `findings_5`: Threat inventory | **STRIDE per Element Matrix**: | Element Type | Applicable STRIDE | |--------------|-------------------| | Process | S, T, R, I, D, E (all 6) | | Data Store | T, R, I, D | | Data Flow | T, I, D | | External Entity (as source) | S, R | ```yaml findings_5: threat_inventory: - id: "T-S-P001-001" element: {type: process, id: P001, name: "AuthService"} stride_category: S description: "..." cwe_ids: [CWE-287, CWE-290] capec_ids: [CAPEC-151] severity: high|medium|low likelihood: high|medium|low - ... ``` --- #### Phase 6: Risk Validation | Attribute | Value | |-----------|-------| | **Type** | Verification | | **Input** | **ALL previous findings consolidated**: `findings_1` + `findings_2` + `findings_3` + `findings_4` + `findings_5` | | **Knowledge** | Threat Pattern Set (CAPEC → ATT&CK → CVE/KEV) + **Verification Set** (WSTG/MASTG/ASVS) | | **Script** | `--capec`, `--attack-technique`, `--cve-for-cwe`, `--check-kev`, `--stride-tests`, `--cwe-tests` | | **Output** | `validated_risks`: Comprehensive validated risk analysis | **Verification Set Integration**: - Use `stride_verification` to get STRIDE-specific test procedures - Use `cwe_verification` to get CWE-specific test cases - Generate POC/test cases from `verification_procedure` table **Consolidation Process**: 1. Merge all findings from P1-P5 into unified issue list 2. Deduplicate and group related issues 3. Perform detailed validation for each unique risk **Output Structure**: ```yaml validated_risks: # Part 1: Validated Risk List with Assessment Summary risk_summary: total_identified: 45 validated_high: 12 validated_medium: 18 validated_low: 10 dismissed: 5 risk_by_stride: {S: 8, T: 12, R: 3, I: 10, D: 4, E: 8} risk_by_domain: {AUTHN: 10, INPUT: 15, ...} # Part 2: Detailed Risk Analysis per Item risk_details: - risk_id: "VR-001" original_refs: ["T-S-P001-001", "SD-001", "DFD-002"] # Consolidated from multiple phases # 2.1 Issue Location location: files: ["src/auth/login.py:45-67", "src/api/handlers.py:120"] elements: ["P1:AuthService", "DF-3:UserCredentials"] trust_boundary: "TB-1:Internet/DMZ" # 2.2 Detailed Analysis detailed_analysis: vulnerability_type: "CWE-287 Improper Authentication" description: "Authentication bypass possible via..." technical_details: "The login function at line 45..." attack_surface: "External, unauthenticated" affected_data: ["user_credentials", "session_tokens"] impact: "Complete authentication bypass..." # 2.3 Root Cause Analysis root_cause: primary_cause: "Missing authentication check on alternative endpoint" contributing_factors: - "No centralized authentication middleware" - "Inconsistent route protection patterns" design_flaw: true implementation_flaw: true cwe_chain: [CWE-287, CWE-863] # 2.4 Test Cases / POC Analysis validation: test_cases: - name: "TC-001: Direct endpoint access" method: "GET /api/v2/user/profile without token" expected: "401 Unauthorized" actual: "200 OK with user data" result: FAIL - name: "TC-002: Token tampering" method: "Modify JWT payload, skip signature" expected: "401 Unauthorized" actual: "200 OK" result: FAIL poc_available: true poc_complexity: low cvss_score: 9.1 kev_status: false # Part 3: Attack Path Analysis attack_paths: - path_id: "AP-001" name: "Authentication Bypass to Data Exfiltration" risk_refs: ["VR-001", "VR-005", "VR-012"] description: "Attacker chains authentication bypass with..." # 3.1 Attack Path Design attack_chain: entry_point: "External:Internet" target: "DataStore:UserDatabase" trust_boundaries_crossed: ["TB-1", "TB-2"] techniques_used: - capec: CAPEC-151 attack: T1078 description: "Identity Spoofing via authentication bypass" - capec: CAPEC-116 attack: T1552 description: "Credential extraction from memory" # Part 4: Step-by-Step Attack Flow detailed_steps: - step: 1 phase: "Reconnaissance" action: "Enumerate API endpoints via /swagger.json" technique: T1592.002 tools: ["curl", "burpsuite"] commands: | curl -s https://target.com/swagger.json | jq '.paths | keys' expected_result: "List of all API endpoints" - step: 2 phase: "Initial Access" action: "Access unprotected /api/v2/user endpoint" technique: T1190 tools: ["curl"] commands: | curl -s https://target.com/api/v2/user/profile \ -H "X-Forwarded-For: 127.0.0.1" expected_result: "User profile data returned without authentication" - step: 3 phase: "Credential Access" action: "Extract session tokens from response" technique: T1552.001 tools: ["jq", "python"] poc_code: | import requests resp = requests.get("https://target.com/api/v2/user/profile") tokens = resp.json().get("active_sessions", []) print(f"Extracted {len(tokens)} session tokens") expected_result: "Valid session tokens extracted" - step: 4 phase: "Lateral Movement" action: "Use extracted tokens to access other user accounts" technique: T1550.001 commands: | for token in $TOKENS; do curl -s https://target.com/api/v1/admin \ -H "Authorization: Bearer $token" done expected_result: "Access to admin functionality" overall_complexity: medium detection_difficulty: high business_impact: critical ``` --- #### Phase 7: Mitigation Planning | Attribute | Value | |-----------|-------| | **Type** | Prescriptive | | **Input** | `validated_risks` (complete Phase 6 output) | | **Knowledge** | Security Control Set (Control Sets + OWASP References) + CWE Mitigations + **Verification Set** (ASVS) | | **Script** | `--cwe --mitigations`, `--control {domain}`, `--asvs-level`, `--asvs-chapter` | | **Output** | `mitigation_plan`: Risk-by-risk mitigation strategy | **Verification Set Integration**: - Use `asvs_requirement` to ensure mitigations meet ASVS security requirements - Map each mitigation to specific ASVS levels (L1/L2/L3) for compliance tracking - Include ASVS verification method in mitigation verification criteria **Processing**: For each validated risk in `validated_risks.risk_details`, design specific mitigations. ```yaml mitigation_plan: - risk_id: "VR-001" risk_summary: "Authentication bypass via unprotected endpoint" severity: critical immediate_actions: # Quick fixes (hours) - action: "Block unprotected endpoint at WAF/gateway level" implementation: | # nginx configuration location /api/v2/user { auth_request /auth/verify; } effort: 1h risk_reduction: 80% short_term_fixes: # Code changes (days) - action: "Add authentication middleware to all /api/v2 routes" control_ref: "control-set-01-authentication.md#centralized-auth" implementation_guide: "reference-set-01-authentication.md" code_changes: - file: "src/middleware/auth.py" change_type: create content: | from functools import wraps def require_auth(f): @wraps(f) def decorated(*args, **kwargs): token = request.headers.get('Authorization') if not validate_token(token): abort(401) return f(*args, **kwargs) return decorated - file: "src/api/v2/routes.py" change_type: modify diff: | - @app.route('/api/v2/user/profile') + @app.route('/api/v2/user/profile') + @require_auth effort: 2d test_verification: - "Verify all v2 endpoints return 401 without valid token" - "Run TC-001, TC-002 from validation - expect PASS" long_term_improvements: # Architectural (weeks) - action: "Implement centralized API gateway with built-in auth" control_ref: "control-set-09-api-security.md#gateway-pattern" architecture_change: true effort: 2w verification_criteria: - "All test cases from VR-001 validation pass" - "Security scan shows no auth bypass vulnerabilities" - "Penetration test confirms fix effectiveness" ``` --- #### Phase 8: Report Generation | Attribute | Value | |-----------|-------| | **Type** | Comprehensive | | **Input** | **ALL phase outputs**: `findings_1` through `mitigation_plan` | | **Knowledge** | Compliance Frameworks + **Verification Set** (ASVS for compliance verification) | | **Script** | `--compliance {framework}`, `--asvs-level`, `--asvs-chapter` | | **Output** | `final_report`: Complete threat model report | **Verification Set Integration**: - Use `asvs_requirement` to generate ASVS compliance status per chapter - Map validated risks to ASVS requirements for gap analysis - Include ASVS level (L1/L2/L3) compliance matrix in report **Report Structure**: ```yaml final_report: # Executive Summary executive_summary: project: "..." assessment_date: "2026-01-03" risk_posture: critical|high|medium|low key_findings: - "12 critical risks identified, 8 require immediate action" - "Authentication subsystem has fundamental design flaws" recommended_priority: - "VR-001: Authentication bypass (Critical)" - "VR-005: SQL injection in search (Critical)" # Section 1: Project Context (from findings_1) project_context: # ... (Phase 1 output) # Section 2: Architecture Analysis (from findings_2, findings_3) architecture: dfd_diagram: "..." # Mermaid/ASCII diagram trust_boundaries: [...] data_flow_summary: [...] # Section 3: Security Design Gaps (from findings_4) security_design: assessed_domains: [...] gap_summary: [...] # Section 4: Threat Inventory (from findings_5) threats: by_stride: {...} by_severity: {...} full_inventory: [...] # Section 5: Validated Risks - FULL DETAIL (from validated_risks) # CRITICAL: This section must include ALL content from Phase 6 validated_risks: risk_summary: {...} risk_details: [...] # Complete detailed analysis attack_paths: [...] # Complete attack path analysis with POCs # Section 6: Mitigation Plan - FULL DETAIL (from mitigation_plan) # CRITICAL: This section must include ALL mitigations mitigation: prioritized_actions: [...] implementation_roadmap: [...] resource_requirements: {...} # Section 7: Compliance Mapping compliance: frameworks_assessed: ["OWASP ASVS", "NIST 800-53", ...] gap_analysis: [...] recommendations: [...] # Appendices appendices: a_full_threat_list: [...] b_poc_scripts: [...] c_test_cases: [...] d_references: [...] ``` --- ## 4. Phase to Knowledge Mapping ### 4.1 Complete Mapping Table | Phase | Name | Type | Security Control Set | Threat Pattern Set | Verification Set | Script Support | |-------|------|------|----------------------|---------------------|------------------|----------------| | 1 | Project Understanding | Exploratory | - | - | - | `list_files.py` | | 2 | Call Flow & DFD | Constructive | `security-design.yaml` | - | - | - | | 3 | Trust Boundaries | Evaluative | `security-design.yaml` | - | - | - | | 4 | Security Design | Evaluative | `security-design.yaml` → `control-set-*.md` → `reference-set-*.md` | - | - | `--control`, `--stride-controls` | | 5 | STRIDE Analysis | Enumerative | - | CWE → CAPEC | - | `--stride`, `--full-chain`, `--all-llm` | | 6 | Risk Validation | Verification | - | CAPEC → ATT&CK → CVE/KEV | **WSTG + MASTG** (test generation) | `--capec`, `--attack-technique`, `--stride-tests`, `--cwe-tests` | | 7 | Mitigation | Prescriptive | `control-set-*.md` → `reference-set-*.md` | CWE Mitigations | **ASVS** (requirement verification) | `--cwe --mitigations`, `--control`, `--asvs-level` | | 8 | Report | Comprehensive | Compliance Frameworks | - | **ASVS** (compliance status) | `--compliance`, `--asvs-chapter` | ### 4.2 Data Flow Visualization ``` ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Phase Data Flow Architecture │ ├─────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ P1 │─findings1─▶│ P2 │─findings2─▶│ P3 │─findings3─▶│ P4 │─findings4─▶│ P5 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ │ │ │ │ │ security- security- │ │ │ │ │ design.yaml design.yaml │ │ │ │ │ ▼ │ │ │ │ control-set-*.md │ │ │ │ reference-set-*.md │ │ │ │ │ │ │ │ ▼ │ │ │ CWE → CAPEC │ │ │ │ │ │ ▼ ▼ │ │ ┌────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ Phase 6: Risk Validation │ │ │ │ INPUT: findings_1 + findings_2 + findings_3 + findings_4 + findings_5 │ │ │ │ (ALL issues consolidated and deduplicated) │ │ │ │ │ │ │ │ KNOWLEDGE: CAPEC → ATT&CK → CVE/KEV │ │ │ │ │ │ │ │ OUTPUT: validated_risks │ │ │ │ ├── risk_summary (counts, categorization) │ │ │ │ ├── risk_details (per-item: location, analysis, root cause, test cases/POC) │ │ │ │ └── attack_paths (chains, step-by-step flow with commands/POC) │ │ │ └────────────────────────────────────────────────────────────────────────────────────── …(truncated)