威胁建模入门：STRIDE模型详解、数据流图（DFD）绘制、威胁识别与分级
威胁建模这件事，说白了就是在攻击者动手之前，你先替他把路走一遍。我见过太多团队上来就写代码、调板子，等到渗透测试时才发现——嗯，这里有个后门，那里能直接读内存。那时候再改，成本就高了去了。
我个人习惯，每个新项目启动的第一周，必须做一次威胁建模。不是走过场，是真的坐下来，把系统拆开看。今天我们就聊聊怎么干这件事。
STRIDE模型：六类威胁，一个框架
STRIDE 是微软提出来的威胁分类法。六个字母，对应六类威胁。你想想看，任何一个安全漏洞，基本都能归到其中一类里。
| 字母 | 威胁类型 | 通俗理解 | 典型例子 |
|---|---|---|---|
| S | Spoofing（假冒） | 你是谁？我凭什么信你？ | 伪造身份、重放攻击 |
| T | Tampering（篡改） | 数据在路上被人动了手脚 | 固件注入、参数篡改 |
| R | Repudiation（抵赖） | 做了不认账 | 缺少审计日志、日志被删 |
| I | Information Disclosure（信息泄露） | 不该看的人看到了 | 侧信道、内存dump |
| D | Denial of Service（拒绝服务） | 系统瘫了，谁也甭用 | 电压毛刺、时钟故障 |
| E | Elevation of Privilege（权限提升） | 普通用户干管理员的事 | 缓冲区溢出、越权调用 |
数据流图（DFD）：把系统画出来，威胁才看得见
光背 STRIDE 没用，你得把它用到自己的系统上。怎么用？先画 DFD。
DFD 有四个基本元素，记住就行：
- 外部实体（矩形）：人、其他系统、云端服务
- 过程（圆形/椭圆）：处理数据的模块，比如加密引擎、认证服务
- 数据存储（双横线）：数据库、文件、寄存器
- 数据流（箭头）：数据怎么走，走什么协议
画 DFD 有个关键原则：只画数据，不画控制流。我刚开始画的时候总想把 if-else 也画进去，结果图乱成一锅粥。记住，DFD 关心的是数据从哪里来、到哪里去、存哪里、谁处理它。
下面这张图，是我做安全评估时常用的 DFD 模板。它展示了一个典型的嵌入式系统数据流：
威胁识别：对着STRIDE，逐个问问题
DFD 画好了，接下来就是拿着 STRIDE 这六把刀，对着每个元素挨个砍一遍。我习惯用表格来记录，这样一目了然。
举个例子，针对上面 DFD 中的「固件更新服务」这个过程：
| STRIDE类别 | 威胁描述 | 影响 |
|---|---|---|
| Spoofing | 攻击者伪装成云端下发假固件 | 设备被植入恶意代码 |
| Tampering | 固件包在传输过程中被篡改 | 固件校验失败或执行恶意逻辑 |
| Repudiation | 固件更新没有日志，出了问题找不到原因 | 无法追溯攻击来源 |
| Information Disclosure | 固件包未加密，泄露内部算法或密钥 | 知识产权被盗 |
| Denial of Service | 攻击者发送大量无效更新请求，耗尽资源 | 设备无法正常更新 |
| Elevation of Privilege | 利用更新服务漏洞获取系统最高权限 | 完全控制设备 |
威胁分级：不是所有威胁都值得修
找到威胁之后，你得排个优先级。资源有限，不可能每个漏洞都修。我常用的方法是 DREAD 模型，给每个威胁打分：
- D - Damage Potential（潜在损害）：如果被利用，损失多大？
- R - Reproducibility（可复现性）：攻击者能稳定复现吗？
- E - Exploitability（可利用性）：攻击难度高不高？
- A - Affected Users（受影响用户）：多少人会遭殃？
- D - Discoverability（可发现性）：攻击者发现这个漏洞的难度？
每个维度打 1-3 分，总分越高，越要优先处理。我一般把 12-15 分的定为「高危」，8-11 分「中危」，5-7 分「低危」。低于 5 分的，先放一放。
小结一下
威胁建模不是一次性的工作。系统变了、攻击手法变了，你的模型也得跟着变。我每半年至少 revisite 一次已有的威胁模型，看看有没有新的攻击面冒出来。
STRIDE 帮你分类，DFD 帮你可视化，DREAD 帮你排优先级。这三样东西配合好，安全设计就有了底。下次我们聊具体怎么用故障注入去验证这些威胁——嗯，那才是真正动手的时候。