threat-modeling

威胁建模

此技能使 Agent 能够对软件应用、API 和基础设施执行结构化威胁建模。Agent 会分析系统架构、数据流和信任边界，并使用 STRIDE、DREAD、PASTA 和攻击树等成熟方法，系统地识别潜在安全威胁。输出内容包括一份按优先级排序的威胁登记表，其中列出具体且可执行的缓解策略，供开发团队纳入待办事项。

工作流

1. 分解系统架构 — 分析架构图、代码仓库、基础设施即代码文件和部署配置，识别所有组件、数据存储、外部服务和通信通道。绘制网络、服务和用户权限级别之间的信任边界。生成数据流图（DFD），展示数据在系统中的流动方式。

2. 选择威胁建模方法 — 根据项目需求选择合适的方法。使用 STRIDE 系统地枚举各组件的威胁类别。使用 DREAD 对已知威胁进行评分和排序。使用 PASTA（攻击模拟与威胁分析流程）开展以风险为中心、与业务目标相结合的分析。使用攻击树深入分析身份验证或支付系统等特定高价值目标。

3. 枚举威胁 — 将选定的方法应用于 DFD 中的每个组件和数据流。对于 STRIDE，按照六类威胁逐一评估每个元素：欺骗、篡改、抵赖、信息泄露、拒绝服务和权限提升。为每项威胁记录唯一标识符、描述、受影响组件以及其跨越的信任边界。

4. 评估风险并确定优先级 — 使用 DREAD（损害程度、可复现性、可利用性、受影响用户数、可发现性）或类似的量化框架为每项威胁评分。将评分与业务背景结合起来——针对支付服务的威胁，其优先级高于针对内部管理仪表板的同类威胁。生成按优先级排序的威胁登记表。

5. 制定缓解措施和安全控制 — 针对每项高优先级和中优先级威胁，制定具体的缓解策略：架构变更、代码级修复、配置加固或运营控制。在适用情况下，将缓解措施映射到安全框架（NIST 800-53、CIS Controls）。估算每项缓解措施的实施工作量。

6. 记录并维护威胁模型 — 生成一份持续更新的文档，记录 DFD、威胁登记表、风险评分和缓解状态。每当架构变更、添加新功能或出现新的攻击技术时，都更新威胁模型。将威胁模型评审纳入 Sprint 规划和设计评审流程。

支持的技术

• 方法：STRIDE、DREAD、PASTA、攻击树、VAST（可视化敏捷简单威胁建模）
• 绘图：数据流图（DFD）、Mermaid、draw.io、Microsoft Threat Modeling Tool
• 架构类型：单体架构、微服务、无服务器、事件驱动、移动后端、IoT 系统
• 基础设施：AWS、GCP、Azure、Kubernetes、本地部署的混合环境
• 标准映射：OWASP Top 10、MITRE ATT&CK、NIST 800-53、CIS Controls

用法

向 Agent 提供架构文档、源代码、基础设施即代码文件，或系统描述的访问权限。指定所需的方法以及要映射的合规标准。Agent 将生成完整的威胁模型，其中包括按优先级排序的威胁登记表和缓解计划。

提示词示例：

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.

示例

示例 1：微服务电商平台的 STRIDE 分析

系统组件：API 网关、认证服务、商品服务、支付服务、PostgreSQL 数据库、Redis 缓存、RabbitMQ 消息代理。

STRIDE 威胁表：

ID	组件	STRIDE 类别	威胁描述	风险	OWASP	缓解措施
T-01	API 网关	欺骗	攻击者伪造 JWT 令牌来冒充用户	高	A07:2021	使用 RS256 和密钥轮换验证 JWT 签名；拒绝 HS256 令牌
T-02	API 网关	拒绝服务	流量攻击压垮网关，阻断合法流量	高	—	按客户端 IP 和 API 密钥实施速率限制；在 CDN 后部署并启用 DDoS 防护
T-03	认证服务	欺骗	利用泄露的用户名/密码数据库进行凭证填充攻击	高	A07:2021	强制启用 MFA；对 /login 实施速率限制；集成泄露检测 API（HaveIBeenPwned）
T-04	认证服务	抵赖	用户否认执行过敏感操作（例如更改电子邮件）	中	A09:2021	将所有身份验证事件和账户更改记录到不可篡改的审计日志中，并记录时间戳和源 IP
T-05	支付服务	篡改	攻击者修改商品服务与支付服务之间传输的订单总额	严重	A04:2021	使用 HMAC 对服务间消息签名；支付服务从数据库重新获取价格，而不是信任请求负载
T-06	支付服务	信息泄露	信用卡号以明文形式记录在应用程序日志中	严重	A02:2021	在所有日志中屏蔽 PAN 数据；使用符合 PCI 标准的令牌化服务；限制日志访问权限
T-07	PostgreSQL	篡改	攻击者通过商品服务搜索端点进行 SQL 注入，修改数据库记录	高	A03:2021	仅使用参数化查询；为每项服务应用最小权限数据库角色
T-08	RabbitMQ	信息泄露	网络攻击者可以读取服务间传输的消息	中	A02:2021	为所有 RabbitMQ 连接启用 TLS；在应用层加密敏感消息负载
T-09	Redis 缓存	权限提升	未经身份验证的 Redis 实例允许任何服务读写会话数据	高	A01:2021	启用 Redis AUTH 并设置强密码；仅绑定到专用网络接口；使用 ACL 限制各服务的键访问权限

示例 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]

根据攻击树推导出的缓解措施：

攻击路径	缓解措施	优先级
1.2 凭证填充攻击	将登录速率限制为每个 IP 每分钟 5 次尝试；集成 HaveIBeenPwned API；要求启用 MFA	严重
2.1.1 可预测的重置令牌	使用 256 位密码学随机数生成令牌；15 分钟后令牌过期	高
2.3.1 算法混淆	在 JWT 验证中显式设置 algorithms: ["RS256"]；拒绝 alg: none 或 HS256 令牌	高
3.1 IDOR	每次访问资源时都执行服务端所有权检查；绝不依赖客户端提供的用户 ID	高
4.1 SQL 注入	使用参数化查询；在登录端点部署针对 SQL 注入模式的 WAF 规则	高

最佳实践

• 在设计阶段尽早进行威胁建模 — 在编写代码之前识别威胁，成本远低于在生产环境中发现问题。将威胁建模纳入设计评审流程，作为一道审核关卡。
• 让模型保持动态更新 — 创建后从不更新的威胁模型毫无用处，甚至更糟，因为它会带来虚假的安全感。每次发生重大架构变更或推出新功能时，都应评审并更新模型。
• 让跨职能相关方参与 — 开发人员了解代码，运维人员了解部署，产品人员了解业务影响。有效的威胁建模需要这三方面的意见。
• 聚焦信任边界 — 最容易被利用的漏洞出现在数据跨越信任边界之处：用户与应用之间、服务之间，以及应用与数据库之间。应优先处理这些交界处的威胁。
• 通过威胁建模推动待办事项 — 每项已识别的缓解措施都应成为可跟踪的工作项，并明确负责人和截止日期。无法产生可执行待办事项的威胁模型就是失败的。
• 通过测试验证威胁 — 识别威胁后，编写相应的安全测试（渗透测试、集成测试或 DAST 规则），验证缓解措施是否有效。

安全边界

• 仅对用户拥有或明确授权评估的系统开展工作，并在测试前记录获批范围。
• 从被动检查或只读检查开始。在进行主动扫描、利用漏洞、生成负载或采取可能造成干扰的修复措施之前，先取得明确批准。
• 绝不泄露机密信息、提取无关数据、削弱生产环境的控制措施，或超出获批目标范围。
• 保留证据、尽量减少影响、在系统不稳定时停止操作，并为每项重大变更提供回滚或遏制步骤。

边缘情况

• 使用共享数据库的微服务 — 多个服务同时读写同一数据库时，信任边界会变得模糊。一个服务中的漏洞可能危及“属于”另一服务的数据。应将每个服务的数据库访问分别建模为独立的信任边界，并在架构层面实施隔离。
• 第三方 API 集成 — 外部 API（支付处理商、身份提供商、分析服务）会带来你无法控制的威胁。应将此类集成建模为不可信数据源，验证所有响应，并制定应对 API 中断或数据完整性失效的计划。
• 事件驱动架构 — 在采用消息队列和事件总线的系统中，威胁包括消息注入、重放攻击和乱序处理。应将消息代理建模为具有自身信任边界的组件，并确保消息经过身份验证且处理具有幂等性。
• 多租户 SaaS 平台 — 多租户特有的威胁包括租户间数据泄露、邻居干扰导致的拒绝服务以及租户冒充。应分别在网络层、应用层和数据层对租户隔离进行建模。
• 频繁部署、快速演进的系统 — 如果架构每周都在变化，每季度一次的威胁模型评审就不够了。对于会改变信任边界、新增数据流或引入外部集成的变更，应在 PR 评审流程中纳入轻量级威胁评估。