威胁建模为何重要

威胁建模是一种结构化实践，用于在攻击者替您发现问题之前，识别系统中可能出错的地方。您需要分析设计、列举可能的威胁，并决定如何降低这些威胁。

它回答四个核心问题：

• 我们正在构建什么？
• 可能出现什么问题？
• 我们要如何应对？
• 我们做得好吗？

威胁建模体现了左移原则：在开发生命周期的早期处理安全问题，而不是等到部署之后。

修复缺陷的成本会随着发现时间的推迟而大幅增加：

• 设计阶段——修改图表，几乎无需成本
• 开发阶段——重写部分代码
• 生产环境——紧急修补、事件以及可能的数据泄露

在写下第一行代码之前发现设计缺陷，是成本最低的修复方式。

威胁建模会迫使您有意识地转换思维方式：不要再思考系统应该如何工作，而要开始思考系统可能如何被滥用。

防御者自然会关注功能和正常路径。攻击者则会寻找：

• 未经验证的输入
• 可能被破坏的信任假设
• 可以跳过或重放的步骤
• 本应受到保护却没有得到保护的数据

建模可以让这种对抗性思维变得系统化，而不是偶然发生。

三个术语构成每个威胁模型的基础。请将它们明确区分：

• 资产——值得保护的有价值对象（客户数据、凭据、可用性）
• 威胁——潜在的有害事件或行为者（窃取数据的攻击者）
• 漏洞——使威胁得以成功的弱点（缺失的访问检查）

当威胁能够利用漏洞攻击有价值的资产时，就会产生风险。

您无法保护尚未识别的对象。请从列出重要对象开始每一次威胁建模。

常见的资产类别：

威胁建模在特定时刻最有价值，而不是一次性活动：

• 设计新系统或新功能时
• 进行重大架构变更时
• 添加新的信任边界时（例如新的集成或外部接口）
• 发生安全事件后，以寻找相关缺口

成熟的团队会将其视为持续活动，并随着系统演进不断重新审查模型。

威胁建模需要团队协作。由一个人构建的模型会遗漏太多背景信息。

有效的会议应包括：

• 了解系统实际工作方式的开发人员
• 理解设计意图的架构师
• 熟悉攻击模式的安全工程师
• 了解业务影响的产品负责人

多种视角的结合，才能发现任何单一角色都无法看到的威胁。

存在多种结构化方法论；您可以按需组合使用：

• STRIDE — 按类型对威胁进行分类；非常适合技术设计（下一课将介绍）
• PASTA — 以风险为中心，将威胁与业务影响联系起来
• 攻击树 — 对攻击者的目标和路径进行建模
• DREAD — 用于确定风险优先级的评分模型

STRIDE 是最常作为入门内容讲授的方法，因为它系统化且易于理解。

威胁模型只有产生可执行的结果才有用。交付成果通常包括：

• 一张展示系统及其信任边界的图
• 一份经过分类的已识别威胁列表
• 每项威胁的风险评级
• 缓解措施或风险接受决策
• 分配给负责人的行动项

如果威胁模型最终只得到一份无人采取行动的文档，那它就失败了。

威胁建模工作经常以一些可预见的方式失败。请避免以下陷阱：

• 试图面面俱到 — 试图一次性对整个系统建模；应改为严格限定范围
• 分析瘫痪 — 无休止地讨论，却不做任何决定
• 把它当作复选框 — 为满足审计人员要求而编写文档，却从不采取行动
• 缺乏后续落实 — 识别出威胁，却从不跟踪缓解措施

请限定范围、设置时间上限，并将其与实际行动项挂钩。

如果您从未进行过威胁建模，可以从以下轻量流程开始：

• 绘制一张展示系统和数据流的简单图
• 标出数据跨越信任边界的位置
• 针对每个边界，询问攻击者可能采取哪些行动
• 记下主要威胁，并为每项威胁制定一项缓解措施
• 分配负责人，稍后再重新检查

即使是一次 30 分钟的白板讨论，也能发现原本可能进入生产环境的问题。

您已经了解了威胁建模为何重要：

• 威胁建模能够在攻击者发现问题之前，以结构化方式回答可能出现哪些问题
• 它将安全性左移，让修复成本大幅降低
• 请区分资产、威胁和漏洞；风险正是它们的交集
• 在设计阶段和重大变更时进行建模，并组建跨职能团队
• 避免试图面面俱到、缺乏后续落实等误区；始终产生可执行的输出

接下来，您将学习用于对威胁进行分类的 STRIDE 框架。