SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场threat-modelling

threat-modelling

安全与审计

查看项目

更新于 10-15 14:05

技能介绍

用途

威胁建模（Threat Modelling）是 Microsoft 安全开发生命周期（SDL）中的一项结构化实践，用于在设计的早期阶段——代码编写之前——识别、沟通并缓解威胁，并在设计发生实质性变更时重新应用。

适用场景：设计新系统、对现有系统进行重大变更、评估架构安全性，或开展正式的安全设计评审。

不适用场景：

  • 组织级安全架构或路线图（应使用 security-architecture）
  • 运行时检测或事件响应（应使用 sentinel / defender-xdr）
  • 代码级漏洞扫描（应使用 SAST/DAST 工具）

STRIDE 六大类别

字母 威胁 破坏的安全属性 典型缓解措施
S 仿冒（Spoofing） 身份验证 MFA、双向 TLS、签名令牌
T 篡改（Tampering） 完整性 签名、哈希、写保护存储
R 抵赖（Repudiation） 不可否认性 审计日志、签名交易
I 信息泄露（Information disclosure） 机密性 加密（静态+传输）、授权
D 拒绝服务（Denial of service） 可用性 速率限制、配额、自动扩缩容、WAF
E 权限提升（Elevation of privilege） 授权 最小权限、输入验证、沙箱

经验法则：将数据流图中的每个元素逐一对照全部六个 STRIDE 类别进行排查。以“此处不适用”为由跳过某些类别，是遗漏真实威胁最常见的方式。

方法

  1. 定义范围与假设——说明哪些在范围内、哪些在范围外、信任模型（你信任谁做什么）以及受保护的资产。没有范围的威胁模型只是一种观点。验证：一页范围说明列出资产、参与者、范围内组件和明确的排除项。

  2. 构建数据流图（DFD）——绘制外部实体、进程、数据存储、数据流和信任边界。信任边界是权限/数据在不同主体之间跨越的地方——大多数威胁就存在于此。验证：每条跨越信任边界的数据流都被高亮标注；没有遗漏任何跨边界流。

  3. 按元素用 STRIDE 枚举威胁——对每个元素/流，逐一走查全部六个 STRIDE 类别。对每个适用的威胁写一行描述。验证：每个元素都已对照全部六个字母评估；能够展示覆盖矩阵。

  4. 按风险对威胁排序——使用 DREAD 或基于可能性与影响的简单高/中/低分级。进行分诊，让团队优先处理最高层级。验证：前 10 威胁列表按风险排序，而非按发现顺序。

  5. 将每个威胁映射到具体缓解措施——缓解措施 = 具体控制（MFA、输入验证、签名、加密、速率限制、最小权限）加上负责人和目标日期。抽象的“我们应该保护那里”不是缓解措施。验证：每个最高层级威胁都有具名缓解措施、负责人和实施目标。

  6. 验证缓解措施已实施——在构建期间，确认每项缓解措施落实到代码、配置或流程中。在评审期间，测试缓解措施是否真正阻止了威胁（负向测试）。验证：测试套件或安全评审清单中存在缓解措施测试。

  7. 实质性变更时重新建模——将威胁建模视为迭代过程。每个新的信任边界、新的外部集成、新的数据分类或重大重构，都是对受影响部分重新建模的触发条件。验证：团队有书面触发清单，且模型在最近一次触发事件后已更新。

  8. 在有用时使用工具——Microsoft Threat Modeling Tool 会按 DFD 元素自动生成 STRIDE 威胁。威胁建模卡片/模板适合没有工具的研讨会。

护栏

  • 威胁建模是迭代的——在每次重大设计变更时重新审视，而不是只在项目开始时做一次。设计时冻结的模型与已交付系统毫无关系。
  • 明确记录假设和范围外事项——未记录的假设就是明年的安全事件。
  • 将威胁与可执行的缓解措施挂钩，包含负责人和日期，而非抽象风险。
  • 对每个元素走查全部六个 STRIDE 字母——跳过类别是最常见的缺口。
  • 威胁建模不能替代代码评审、依赖扫描或渗透测试。它通过塑造测试内容来补充它们。
  • 产出是共享理解，而不是文档。如果开发团队无法口头解释最高威胁，模型就没有落地。

常见反模式

  • “我们在项目启动时做过威胁模型”——然后再也没更新过。被建模的系统已不复存在。
  • 一份 200 个威胁的电子表格，没有排序。什么都修不了，因为一切看起来都一样。分诊才是交付物。
  • 因为“不适用”而跳过 STRIDE 字母。强制走查；记录某类别确实不适用的原因，而不是默默跳过。
  • 缓解措施 = “使用 TLS”。这不是缓解措施。缓解措施 = 在网关上强制 TLS 1.2+ 并指定密码套件 X，由测试 Y 验证，由 Z 负责。
  • 威胁模型成为安全团队的产物，工程团队从不阅读。开发团队必须拥有模型；安全团队负责促进。

示例提示

  • 运行一次带数据流图和信任边界的 STRIDE 威胁建模。
  • 使用 Microsoft Threat Modeling Tool 进行设计评审。
  • 如何为新系统识别威胁并映射缓解措施？
  • 开展一次 SDL 威胁建模会议。
  • STRIDE 中的 E 涵盖什么，如何缓解？

参考链接

  • Microsoft Threat Modeling Tool：https://learn.microsoft.com/azure/security/develop/threat-modeling-tool
  • Threat Modeling Tool 威胁参考：https://learn.microsoft.com/azure/security/develop/threat-modeling-tool-threats
  • Threat Modeling Tool 缓解措施：https://learn.microsoft.com/azure/security/develop/threat-modeling-tool-mitigations
  • Microsoft SDL：https://www.microsoft.com/securityengineering/sdl
  • SDL 实践：https://www.microsoft.com/securityengineering/sdl/practices