Threat Modeling
此技能使代理能够为软件应用程序、API 和基础设施执行结构化的威胁建模。代理分析系统架构、数据流和信任边界，使用 STRIDE、DREAD、PASTA 和攻击树等已建立的方法论系统地识别潜在的安全威胁。输出是一个优先级排序的威胁登记册，其中包含具体且可操作的缓解策略，开发团队可以将其整合到他们的待办事项中。
Workflow
-
分解系统架构 — 分析架构图、代码库、基础设施即代码文件和部署配置，以识别所有组件、数据存储、外部服务和通信渠道。映射网络、服务和用户权限级别之间的信任边界。生成一个显示数据如何在系统中流动的数据流图（DFD）。
-
选择威胁建模方法论 — 根据项目需求选择合适的方法论。使用 STRIDE 对每个组件进行威胁类别的系统性枚举。使用 DREAD 对已知威胁进行评分和优先排序。使用 PASTA（攻击模拟与威胁分析流程）进行以风险为中心、与业务目标一致的分析。使用攻击树对特定高价值目标（如认证或支付系统）进行深入分析。
-
枚举威胁 — 将所选方法论应用于 DFD 中的每个组件和数据流。对于 STRIDE，评估每个元素在所有六种威胁类别中的表现：欺骗、篡改、否认、信息泄露、拒绝服务和权限提升。为每个威胁记录唯一标识符、描述、受影响的组件以及它跨越的信任边界。
-
评估风险并排序 — 使用 DREAD（损害、可重现性、可利用性、受影响用户、可发现性）或类似的定量框架对每个威胁进行评分。结合业务背景进行评分 — 支付服务的威胁优先级高于内部管理仪表盘中的相同威胁。生成一个排序后的威胁登记册。
-
定义缓解措施和安全控制 — 对于每个高、中优先级威胁，明确具体的缓解策略：架构变更、代码级别修复、配置加固或操作控制。在适用的情况下将缓解措施映射到安全框架（如 NIST 800-53、CIS Controls）。估算每项缓解措施的实施工作量。
-
记录并维护威胁模型 — 生成一个活文档，包含 DFD、威胁登记册、风险评分和缓解状态。每当架构发生变化、添加新功能或出现新的攻击技术时更新威胁模型。将威胁模型审查整合到冲刺规划和设计评审流程中。
支持的技术
- 方法论: STRIDE, DREAD, PASTA, 攻击树, VAST（Visual Agile Simple Threat modeling）
- 绘图工具: 数据流图（DFD）、Mermaid、draw.io、Microsoft 威胁建模工具
- 架构类型: 单体应用、微服务、无服务器、事件驱动、移动后端、物联网系统
- 基础设施: AWS、GCP、Azure、Kubernetes、本地混合环境
- 标准映射: OWASP Top 10、MITRE ATT&CK、NIST 800-53、CIS Controls
Usage
向代理提供对架构文档、源代码、基础设施即代码文件或系统描述的访问权限。指定所需的方法论和任何合规标准以进行映射。代理将生成一个完整的威胁模型，包括优先级排序的威胁登记册和缓解计划。
提示示例:
Perform a STRIDE threat model on our microservices architecture. The services are defined in /infra/docker-compose.yml and the source code is in /services/. Focus on the API gateway, authentication service, and payment service. Map findings to OWASP Top 10.
Examples
示例 1：微服务电子商务平台的 STRIDE 分析
系统组件: API 网关、认证服务、产品服务、支付服务、PostgreSQL 数据库、Redis 缓存、RabbitMQ 消息代理。
STRIDE 威胁表:
| ID | Component | STRIDE Category | Threat Description | Risk | OWASP | Mitigation |
|---|---|---|---|---|---|---|
| T-01 | API Gateway | Spoofing | Attacker forges JWT tokens to impersonate users | High | A07:2021 | Validate JWT signatures using RS256 with key rotation; reject HS256 tokens |
| T-02 | API Gateway | Denial of Service | Volumetric attack overwhelms the gateway, blocking legitimate traffic | High | — | Implement rate limiting per client IP and API key; deploy behind a CDN with DDoS protection |
| T-03 | Auth Service | Spoofing | Credential stuffing using leaked username/password databases | High | A07:2021 | Enforce MFA, implement rate limiting on /login, integrate breach-detection APIs (HaveIBeenPwned) |
| T-04 | Auth Service | Repudiation | User denies performing a sensitive action (e.g., changing email) | Medium | A09:2021 | Log all authentication events and account changes to an immutable audit log with timestamps and source IP |
| T-05 | Payment Service | Tampering | Attacker modifies order total in transit between Product Service and Payment Service | Critical | A04:2021 | Sign inter-service messages with HMAC; Payment Service re-fetches price from database instead of trusting the request payload |
| T-06 | Payment Service | Information Disclosure | Credit card numbers logged in plaintext to application logs | Critical | A02:2021 | Mask PAN data in all logs; use a PCI-compliant tokenization service; restrict log access |
| T-07 | PostgreSQL | Tampering | SQL injection via Product Service search endpoint alters database records | High | A03:2021 | Use parameterized queries exclusively; apply least-privilege database roles per service |
| T-08 | RabbitMQ | Information Disclosure | Messages in transit between services are readable by network attackers | Medium | A02:2021 | Enable TLS for all RabbitMQ connections; encrypt sensitive message payloads at the application layer |
| T-09 | Redis Cache | Elevation of Privilege | Unauthenticated Redis instance allows any service to read/write session data | High | A01:2021 | Enable Redis AUTH with a strong password; bind to private network interface only; use ACLs to restrict key access per service |
示例 2：认证系统的攻击树
根目标: 获得对用户账户的未授权访问。
Gain Unauthorized Access to User Account
├── 1. Steal Valid Credentials
│ ├── 1.1 Phishing attack targeting user email [Likelihood: High]
│ ├── 1.2 Credential stuffing from breached databases [Likelihood: High]
│ └── 1.3 Keylogger malware on user device [Likelihood: Medium]
├── 2. Bypass Authentication
│ ├── 2.1 Exploit password reset flow
│ │ ├── 2.1.1 Predictable reset token (insufficient entropy) [Likelihood: Medium]
│ │ └── 2.1.2 Reset link does not expire [Likelihood: Low]
│ ├── 2.2 Session hijacking
│ │ ├── 2.2.1 Steal session cookie via XSS [Likelihood: Medium]
│ │ └── 2.2.2 Session fixation attack [Likelihood: Low]
│ └── 2.3 Forge or tamper with JWT
│ ├── 2.3.1 Algorithm confusion attack (HS256 vs RS256) [Likelihood: Medium]
│ └── 2.3.2 Weak signing secret (brute-forceable) [Likelihood: Medium]
├── 3. Exploit Authorization Flaws
│ ├── 3.1 IDOR — access another user's resources by changing user ID in URL [Likelihood: High]
│ └── 3.2 Privilege escalation — modify role claim in JWT payload [Likelihood: Medium]
└── 4. Compromise the Auth Service Directly
├── 4.1 SQL injection in login endpoint [Likelihood: Medium]
└── 4.2 Exploit unpatched dependency in auth service [Likelihood: Medium]
从攻击树中得出的缓解措施:
| Attack Path | Mitigation | Priority |
|---|---|---|
| 1.2 Credential stuffing | Rate limit login to 5 attempts per minute per IP; integrate HaveIBeenPwned API; require MFA | Critical |
| 2.1.1 Predictable reset token | Generate tokens with 256-bit cryptographic randomness; expire after 15 minutes | High |
| 2.3.1 Algorithm confusion | Explicitly set algorithms: ["RS256"] in JWT verification; reject tokens with alg: none or HS256 |
High |
| 3.1 IDOR | Enforce server-side ownership checks on every resource access; never rely on client-supplied user IDs | High |
| 4.1 SQL injection | Use parameterized queries; deploy a WAF rule for SQL injection patterns on the login endpoint | High |
最佳实践
- 在设计阶段早期进行威胁建模 — 在编写代码之前识别威胁比在生产环境中发现它们要便宜得多。将威胁建模作为设计评审过程中的一个关卡。
- 保持模型为活文档 — 一次创建且从未更新的威胁模型比无用更糟，因为它会带来虚假的安全感。每次重大架构变更或新增功能时都应审查和更新它。
- 涉及跨职能利益相关者 — 开发人员了解代码，运维了解部署，产品了解业务影响。有效的威胁建模需要来自这三个视角的输入。
- 关注信任边界 — 最容易被利用的漏洞发生在数据跨越信任边界的地方：用户与应用程序之间、服务之间、应用程序与数据库之间。优先处理这些交汇点的威胁。
- 使用威胁建模驱动待办事项 — 每个识别出的缓解措施应成为可追踪的工作项，有负责人和截止日期。无法产生可操作待办事项的威胁模型是失败的。
- 通过测试验证威胁 — 在识别出一个威胁后，编写相应的安全测试（渗透测试、集成测试或 DAST 规则），以验证缓解措施是否有效。
Edge Cases
- 共享数据库的微服务 — 当多个服务读写同一个数据库时，信任边界变得模糊。一个服务中的漏洞可能危及“属于”另一个服务的数据。将每个服务对数据库的访问建模为独立的信任边界，并实施模式级隔离。
- 第三方 API 集成 — 外部 API（支付处理器、身份提供商、分析工具）引入了超出控制范围的威胁。将集成建模为不受信任的数据源，验证所有响应，并计划应对 API 停机或数据完整性失败的情况。
- 事件驱动架构 — 在具有消息队列和事件总线的系统中，威胁包括消息注入、重放攻击和乱序处理。将消息代理建模为具有自己信任边界的组件，并确保消息认证和幂等处理。
- 多租户 SaaS 平台 — 多租户特有的威胁包括跨租户数据泄露、噪声邻居拒绝服务和租户冒充。分别在网络层、应用层和数据层建模租户隔离。
- 频繁部署的快速演进系统 — 如果架构每周都会变化，季度威胁模型审查是不够的。将轻量级威胁评估整合到 PR 审查流程中，针对修改信任边界、添加新数据流或引入新的外部集成的更改进行评估。
