威胁建模入门：识别设备资产、识别攻击者、STRIDE威胁模型、绘制数据流图（DFD）
威胁建模，说白了就是在坏人动手之前，先替他们把攻击路径想一遍。我刚开始做嵌入式安全时，总觉得这是安全专家的事，自己只管把功能跑通就行。直到有一次，一个智能门锁项目在渗透测试中被发现——攻击者通过未加密的调试串口直接拿到了固件，然后逆向出了云端通信密钥。嗯，从那以后，我再也不敢跳过威胁建模了。
这一节，我们就把威胁建模的四块核心内容拆开揉碎：识别资产、识别攻击者、STRIDE模型、数据流图（DFD）。你不需要成为安全专家，但得学会用这套框架去审视自己的设备。
1. 识别设备资产：你到底在保护什么？
很多人一上来就画DFD，结果画到一半发现不知道哪些东西需要保护。我个人习惯，先列资产清单。资产分两类：数据资产和功能资产。
| 资产类别 | 举例（以智能锁为例） | 为什么重要 |
|---|---|---|
| 用户凭证 | 指纹模板、密码哈希、蓝牙配对密钥 | 泄露后攻击者可冒充用户开锁 |
| 设备身份 | 设备证书、私钥、序列号 | 被克隆后可以伪造合法设备 |
| 固件/软件 | MCU固件、Bootloader、OTA更新包 | 逆向后可植入后门或提取密钥 |
| 敏感配置 | Wi-Fi SSID/密码、云服务器地址 | 泄露后攻击者可进入内网 |
| 功能资产 | 开锁/关锁指令、门状态传感器 | 被篡改后设备行为失控 |
2. 识别攻击者：谁会对你的设备下手？
你想想看，一个智能灯泡和一个智能门锁，面对的威胁能一样吗？识别攻击者，决定了你要花多少精力做防护。我一般把攻击者分成三个层级：
- 业余爱好者（Script Kiddie）：只会用现成工具，比如用串口助手乱发指令、用网上找的默认密码尝试登录。威胁等级：低。
- 专业攻击者（Hacker）：有逆向能力，会用逻辑分析仪抓I²C/SPI信号，能通过侧信道攻击提取密钥。威胁等级：中到高。
- 国家级/有组织攻击者（APT）：有资金、有团队，能进行芯片级逆向、FIB（聚焦离子束）修改电路。威胁等级：极高。
3. STRIDE威胁模型：六种威胁，逐个击破
STRIDE是微软提出的威胁分类法，每个字母代表一类威胁。我把它当成一个检查清单，每画完一个DFD节点，就对着STRIDE过一遍。
| 字母 | 威胁类型 | 含义 | 嵌入式场景举例 |
|---|---|---|---|
| S | Spoofing（欺骗） | 冒充他人身份 | 攻击者伪造蓝牙MAC地址，冒充合法手机 |
| T | Tampering（篡改） | 修改数据或代码 | 攻击者修改OTA固件包，植入恶意代码 |
| R | Repudiation（抵赖） | 否认做过某操作 | 设备日志被删除，无法追溯谁开了锁 |
| I | Information Disclosure（信息泄露） | 敏感数据被窃取 | 通过侧信道分析，提取AES密钥 |
| D | Denial of Service（拒绝服务） | 系统不可用 | 攻击者发送大量无效MQTT包，耗尽设备内存 |
| E | Elevation of Privilege（权限提升） | 获得更高权限 | 从用户态漏洞提权到内核态，关闭安全机制 |
我的实战经验：STRIDE不是一次性的。每当你增加一个新功能（比如加了个OTA升级），就要重新跑一遍STRIDE。我记得有个项目，产品经理非要加一个“远程开锁”功能，我拿STRIDE一分析——S（冒充手机）、T（篡改指令）、D（拒绝服务）全中。最后我们加了双向认证和指令签名，才敢上线。
4. 绘制数据流图（DFD）：把威胁可视化
DFD是威胁建模的骨架。没有DFD，你就是在盲猜攻击路径。我画DFD遵循四个基本元素：
- 外部实体（External Entity）：矩形，代表与系统交互的人或外部系统（如手机App、云服务器）。
- 过程（Process）：圆形或圆角矩形，代表数据处理单元（如MCU、安全芯片）。
- 数据存储（Data Store）：两条平行线，代表数据存放的地方（如Flash、外部EEPROM）。
- 数据流（Data Flow）：箭头，代表数据移动的方向（如SPI总线、UART、Wi-Fi）。
下面这张图，是我为一个智能锁项目画的简化版DFD。你可以看到数据从手机App出发，经过蓝牙、MCU、安全芯片，最终到达电机驱动。
5. 把STRIDE套到DFD上：实战演练
DFD画完了，接下来就是对着每个数据流和节点，问STRIDE的六个问题。我拿上面那个智能锁DFD举个例子：
- Spoofing：手机App发送“开锁指令”时，MCU如何确认这条指令真的来自合法手机？→ 需要蓝牙配对绑定和指令签名。
- Tampering：MCU通过SPI写入Flash的日志数据，会不会被篡改？→ 需要加CRC校验或数字签名。
- Repudiation：如果有人开了锁，但日志被删了，怎么追溯？→ 日志需要写入只增不减的存储区，并加时间戳。
- Information Disclosure：安全芯片和MCU之间的I²C通信，会不会被逻辑分析仪抓取？→ 需要加密通道或物理隔离。
- Denial of Service：如果攻击者持续发送无效MQTT包，MCU会不会死机？→ 需要看门狗和消息队列限流。
- Elevation of Privilege：如果攻击者通过OTA刷入了恶意固件，能不能获得内核权限？→ 需要签名验证和Secure Boot。
核心思路：威胁建模不是一次性的文档工作。它应该嵌入到你的开发流程里——需求阶段画DFD，设计阶段跑STRIDE，编码阶段实现缓解措施，测试阶段验证。我现在的团队，每个新功能上线前，必须过一遍威胁建模评审，否则不准合代码。
6. 常见误区与避坑
最后，分享几个我踩过的坑：
- DFD画得太粗：只画了“手机→设备→云”三个框，根本看不出攻击面。要细化到具体总线、具体芯片。
- 只关注外部攻击者：忽略了内部威胁——比如生产环节的工人可能通过调试接口提取固件。
- STRIDE只跑一次：产品迭代后，原来的威胁模型可能已经失效。每次改架构，都要重新跑一遍。
- 过度依赖工具：工具（如Microsoft Threat Modeling Tool）只是辅助，核心还是你对系统架构的理解。