威胁建模与风险评估：STRIDE模型、DREAD模型、攻击树分析、风险矩阵
好，咱们进入第二章。这一章我把它叫做「动手前的沙盘推演」。你想想看，一个物联网系统少说几十个组件，多则成百上千。如果一上来就埋头写代码、搭架构，等上线了才发现安全漏洞，那代价可就大了去了。
我个人习惯，在画第一张架构图的同时，就开始做威胁建模。说白了，就是站在攻击者的角度，提前想好「谁会打我？怎么打我？打中了会怎样？」。今天咱们就聊透四个最实用的工具：STRIDE、DREAD、攻击树和风险矩阵。
STRIDE模型：六类威胁，一个不漏
STRIDE 是微软提出来的，名字取自六种威胁类型的首字母。我在项目中用过不下几十次，确实好用。它帮我们把模糊的「不安全」拆解成了六个具体问题。
| 威胁类型 | 英文 | 核心问题 | 物联网场景举例 |
|---|---|---|---|
| S - 身份欺骗 | Spoofing | 攻击者能否冒充他人？ | 伪造设备ID接入云端 |
| T - 篡改 | Tampering | 数据是否会被非法修改？ | 固件OTA包被中间人篡改 |
| R - 抵赖 | Repudiation | 操作能否被追溯？ | 设备执行了危险指令却无日志 |
| I - 信息泄露 | Information Disclosure | 敏感数据是否暴露？ | 蓝牙广播包泄露设备密钥 |
| D - 拒绝服务 | Denial of Service | 系统能否被耗尽资源？ | 大量虚假MQTT连接打垮Broker |
| E - 权限提升 | Elevation of Privilege | 能否获得更高权限？ | 从普通用户提权到root |
怎么用？我建议你画一张数据流图（DFD），然后对着每个数据流、每个存储、每个进程，挨个问这六个问题。嗯，这里要注意：不要只盯着外部实体看，内部模块之间的交互往往更容易出问题。
实战小技巧： 我在做智能门锁项目时，用STRIDE一查，发现「身份欺骗」和「篡改」两个威胁等级特别高。后来专门针对这两个点做了双向证书认证和签名校验。如果当时没做这个建模，后果不堪设想。
DREAD模型：给威胁打个分
STRIDE 帮我们找到了威胁，但哪个威胁最要命？这时候就需要 DREAD 出场了。DREAD 是一个风险评估模型，每个维度打分 1-10，最后算平均值。
| 维度 | 英文 | 评分标准（1-10） |
|---|---|---|
| D - 潜在损害 | Damage | 1=轻微影响，10=系统完全瘫痪 |
| R - 可重现性 | Reproducibility | 1=极难复现，10=每次必现 |
| E - 可利用性 | Exploitability | 1=需要极高技能，10=脚本小子也能搞 |
| A - 受影响用户 | Affected Users | 1=个别人，10=所有用户 |
| D - 可发现性 | Discoverability | 1=极难发现，10=公开漏洞 |
举个例子。你发现设备固件升级时没有校验签名。我们来打个分：损害8分（可远程控制设备），可重现性10分（每次升级都触发），可利用性7分（需要中间人攻击能力），受影响用户9分（所有设备），可发现性6分（需要逆向分析）。总分 (8+10+7+9+6)/5 = 8分。嗯，这属于高危，必须马上修。
我的经验： DREAD 打分不用太纠结精确性。我一般拉上开发、测试、产品一起打分，取平均值。重点不是分数本身，而是通过讨论让大家对风险达成共识。
攻击树分析：把攻击路径画出来
攻击树是布鲁斯·施奈尔提出的。说白了，就是把攻击者的目标作为根节点，然后不断往下拆解「要达成这个目标，需要先做什么？」。我个人觉得，这是最直观的威胁分析工具。
举个例子，攻击目标是「远程控制智能灯泡」：
远程控制智能灯泡（根节点）
├── 1.0 获取WiFi密码
│ ├── 1.1 暴力破解路由器
│ ├── 1.2 从手机APP提取密码
│ └── 1.3 监听配网过程
├── 2.0 绕过设备认证
│ ├── 2.1 利用固件后门
│ ├── 2.2 重放配网令牌
│ └── 2.3 破解本地API密钥
└── 3.0 发送恶意指令
├── 3.1 伪造MQTT消息
├── 3.2 利用CoAP协议漏洞
└── 3.3 注入恶意固件你看，这么一画，攻击路径就清清楚楚了。每个叶子节点就是一个具体的攻击向量。我曾经在一个车联网项目里用攻击树分析T-Box的远程攻击面，画了整整三页纸。最后发现，最容易被攻破的路径不是云端，而是蓝牙配网那个环节。
避坑指南： 我曾经犯过一个错误——只画了外部攻击者的树。后来发现内部人员（比如工厂产线工人）的攻击树完全不同。建议至少画两棵：外部攻击树和内部攻击树。
风险矩阵：决策的最终依据
好了，现在我们有了一堆威胁，也打了分，还画了攻击树。接下来怎么办？总不可能所有威胁都修复吧？资源有限啊。这时候就需要风险矩阵来帮忙做决策。
风险矩阵的横轴是「可能性」，纵轴是「影响程度」。两个维度都分低、中、高三档。交叉点就是风险等级。
| 影响 \ 可能性 | 低 | 中 | 高 |
|---|---|---|---|
| 高 | 中风险 | 高风险 | 极高风险 |
| 中 | 低风险 | 中风险 | 高风险 |
| 低 | 低风险 | 低风险 | 中风险 |
怎么用？举个例子。你发现「设备本地调试接口未关闭」这个威胁。可能性高（很多产线都忘了关），影响高（可以直接拿到root shell）。矩阵一查，极高风险。那没得商量，必须修复，而且要在上线前修完。
反过来，如果某个威胁是「通过物理拆解芯片读取Flash」。可能性低（需要专业设备），影响高（密钥泄露）。矩阵显示中风险。那你可以选择接受，或者加个简单的防拆检测就行，不用投入太多资源。
核心原则： 风险矩阵不是数学公式，它是沟通工具。我每次做安全评审，最后都会把风险矩阵贴在墙上。大家一看就明白：哪些是红线不能碰，哪些可以缓一缓。说白了，安全不是零和游戏，而是风险管理。
四个工具怎么配合？
最后说说我的工作流。你照着这个顺序来，基本不会漏：
- 先用STRIDE 全面扫描，找出所有潜在威胁。别漏，宁可多也不要少。
- 再用DREAD 给每个威胁打分。注意，这里要拉上团队一起评，别自己闷头打分。
- 对高分威胁画攻击树，把攻击路径拆到叶子节点。这一步能帮你找到真正的防御点。
- 最后用风险矩阵 做决策。哪些必须修？哪些可以缓？哪些接受？一目了然。
我记得有一次，一个智能家居项目时间特别紧。我用这套流程只花了两天，就把整个系统的威胁模型做完了。最后上线后，安全团队做渗透测试，只发现了一个低危问题。嗯，那一刻我觉得，这活没白干。
下一章咱们聊聊「物联网安全架构设计原则」。到时候我会分享一些具体的架构模式，比如如何做安全分区、如何设计信任链。咱们到时候见。