威胁建模与风险评估：STRIDE模型、DREAD模型、风险矩阵与优先级划分
做安全这么多年，我见过太多团队一上来就撸代码，等上线了才发现到处都是窟窿。说实话，安全不是靠堆工具堆出来的，你得先想清楚——你的系统到底怕什么？
威胁建模，就是帮你回答这个问题的。它不是什么高深理论，说白了就是一套结构化的思考方式。今天咱们就聊聊我最常用的两个模型：STRIDE 和 DREAD，再加上风险矩阵怎么用。
STRIDE 模型：六类威胁，一个不漏
STRIDE 是微软提出来的，名字来自六种威胁类型的首字母。我个人习惯在做任何系统设计时，先拿 STRIDE 过一遍，就像安全检查清单一样。
| 威胁类型 | 英文 | 核心问题 | 举个栗子 |
|---|---|---|---|
| S - 身份欺骗 | Spoofing | 攻击者能不能假装成别人？ | 伪造 JWT Token 冒充管理员 |
| T - 数据篡改 | Tampering | 数据在传输或存储中能被改吗？ | 中间人篡改固件更新包 |
| R - 抵赖 | Repudiation | 用户做了操作能赖账吗？ | 没有审计日志，用户说"我没删数据" |
| I - 信息泄露 | Information Disclosure | 敏感数据会不会被不该看到的人看到？ | 数据库备份文件未加密被拖库 |
| D - 拒绝服务 | Denial of Service | 系统能不能被搞瘫痪？ | 刷更新请求把 OTA 服务器打挂 |
| E - 权限提升 | Elevation of Privilege | 普通用户能不能干管理员的事？ | 通过 API 参数注入获取 root 权限 |
我的小习惯：每次画系统架构图时，我会在每条数据流旁边标上它可能对应的 STRIDE 威胁类型。这样一眼就能看出哪里风险最集中。
DREAD 模型：给威胁打个分
STRIDE 帮你找到了威胁，但哪个最要命？这时候 DREAD 就派上用场了。它是个评分模型，每个维度 1-10 分，最后算平均值。
| 维度 | 含义 | 低分（1-3） | 高分（8-10） |
|---|---|---|---|
| D - 潜在损失 | 如果被利用，损失多大？ | 影响个别用户 | 全系统瘫痪，数据全丢 |
| R - 可重现性 | 攻击能不能稳定复现？ | 需要特殊条件 | 随便点两下就触发 |
| E - 可利用性 | 攻击门槛高不高？ | 需要内网+高级技巧 | 网上有现成工具 |
| A - 受影响用户 | 多少人会遭殃？ | 个位数 | 所有用户 |
| D - 可发现性 | 漏洞容易被发现吗？ | 藏在深层代码里 | 公开接口，一测就现 |
算分公式很简单：(D + R + E + A + D) / 5。我个人一般把 7 分以上的定为高危，4-7 分中危，4 分以下低危。
注意：DREAD 的评分主观性挺强的。同一个威胁，开发觉得 3 分，安全觉得 8 分。我建议团队一起评，取平均值，别一个人拍脑袋。
风险矩阵：把威胁排个队
有了 DREAD 分数，下一步就是排优先级。风险矩阵是我最常用的工具——横轴是可能性，纵轴是影响程度，交叉点就是风险等级。
你看，落在红色区域的威胁，必须优先处理。绿色区域的可以暂时接受，但得持续监控。
优先级划分：到底先修哪个洞？
我遇到过不少团队，漏洞列表拉出来几十条，结果开发不知道从哪下手。我的做法分三步：
- 先看风险矩阵：紧急风险 > 高风险 > 中风险 > 低风险
- 再看修复成本：同样高风险，改一行配置就能修的先搞
- 最后看业务影响：核心链路的风险优先级高于边缘功能
实战经验：有一次做车联网 OTA 系统的威胁建模，STRIDE 跑下来发现"固件包篡改"和"更新服务器 DoS"都是高风险。但修复成本差很多——加签名验证花了两天，做弹性扩容花了两周。所以我们先修了篡改问题，再慢慢搞 DoS 防护。优先级不是死板的，得结合实际情况。
完整流程：从建模到落地
把上面这些串起来，一个完整的威胁建模流程大概是这样的：
- 画数据流图：搞清楚系统里数据怎么流动的
- 套 STRIDE：对每个数据流节点，问自己六类威胁
- 用 DREAD 打分：给每个威胁评个分
- 落风险矩阵：把分数映射到矩阵里
- 定优先级：按矩阵结果 + 修复成本排顺序
- 出缓解方案：每个高风险威胁至少有一个应对措施
避坑指南：我曾经在一个项目里只做了 STRIDE 没做 DREAD，结果列出来 30 多个威胁，团队直接懵了。后来加了评分和矩阵，才把真正要命的 5 个问题拎出来。记住，威胁建模的目的是聚焦，不是列清单。
好了，这一套组合拳打下来，你的系统安全底子基本就稳了。下次做设计评审的时候，不妨试试拿 STRIDE 过一遍，你会发现很多之前没想到的问题。