3、威胁建模与风险评估：STRIDE、DREAD、攻击树等威胁建模方法，针对车载网关的资产识别与风险分析
好，咱们进入第三章。这一章聊的是威胁建模与风险评估。说实话，这是整个安全设计里最「虚」也最「实」的一环。虚在它看不见摸不着，实在它决定了你后面所有防护措施的投入方向。
我个人的习惯是，拿到一个车载网关项目，第一件事不是看原理图，而是拉上系统、软件、测试的兄弟，关起门来先做一轮威胁建模。为什么？因为只有把「敌人可能从哪里来」想清楚了，你才知道钱该花在哪儿。
3.1 资产识别：你得先知道家里有什么值钱的东西
威胁建模的第一步，永远是资产识别。说白了，就是盘点一下你的车载网关里，哪些东西是黑客眼里的「肥肉」。
车载网关的资产，我一般分成这么几类：
- 通信资产：CAN/CAN-FD 总线、车载以太网、LIN、FlexRay，还有无线接口（比如 4G/5G、Wi-Fi、蓝牙）。这些是数据进出的通道。
- 数据资产：诊断数据（UDS）、OTA 升级包、车辆配置信息、用户隐私数据（比如手机连接后的联系人）。
- 功能资产：路由表、防火墙规则、密钥存储区、安全启动的信任根。
- 硬件资产：主控芯片（MCU/MPU）、HSM（硬件安全模块）、外部存储器（Flash/SRAM）。
我记得有一次做项目，团队只关注了 CAN 报文的安全，完全忽略了 OTA 升级包的完整性校验。结果呢？后来做渗透测试时，测试人员伪造了一个升级包，直接刷进了网关。嗯，那次之后，我们的资产清单里就多了一条：「OTA 升级包存储区」。
3.2 STRIDE：微软的六顶思考帽
STRIDE 是微软提出来的威胁分类模型。它把威胁分成六类：
| 缩写 | 含义 | 车载网关场景举例 |
|---|---|---|
| S | Spoofing（欺骗） | 伪造一个合法的 ECU 向网关发送诊断请求 |
| T | Tampering（篡改） | 修改网关的防火墙规则表 |
| R | Repudiation（抵赖） | 攻击者发送了恶意报文，但日志里查不到是谁发的 |
| I | Information Disclosure（信息泄露） | 通过调试接口读取网关内部的密钥 |
| D | Denial of Service（拒绝服务） | 向 CAN 总线发送大量高优先级报文，导致网关无法处理正常消息 |
| E | Elevation of Privilege（权限提升） | 从普通诊断会话切换到编程会话，获取刷写权限 |
你想想看，这六类威胁几乎覆盖了所有攻击路径。我习惯的做法是，针对每个资产，逐一问自己：「这个资产会不会被欺骗？会不会被篡改？……」
举个例子。对于「CAN 报文路由表」这个资产：
- Spoofing：攻击者能不能伪造一个合法的源节点 ID？能。因为 CAN 总线本身没有源认证。
- Tampering：能不能修改路由表？如果路由表存储在可写的 Flash 里，且没有完整性校验，那就能。
- Denial of Service：能不能通过大量报文让路由表查询超时？能，如果网关的 CPU 性能不够。
这样一轮下来，威胁清单就出来了。
3.3 DREAD：给威胁打个分
STRIDE 帮你找到了威胁，但没告诉你哪个威胁最要命。这时候 DREAD 就派上用场了。
DREAD 是一个风险评估模型，每个字母代表一个维度：
- D - Damage Potential（潜在损害）：如果这个威胁被利用，会造成多大损失？
- R - Reproducibility（可复现性）：攻击者能稳定复现这个攻击吗？
- E - Exploitability（可利用性）：发起这个攻击需要什么条件？需要物理接触吗？需要专业知识吗？
- A - Affected Users（受影响用户）：有多少车辆会受影响？
- D - Discoverability（可发现性）：攻击者发现这个漏洞的难度有多大？
每个维度打分，1 到 10 分。最后算总分或平均分。分数越高，风险越大。
我举个例子。针对「OTA 升级包被篡改」这个威胁：
| 维度 | 评分 | 理由 |
|---|---|---|
| Damage Potential | 9 | 可以刷入恶意固件，完全控制网关 |
| Reproducibility | 8 | 只要知道 OTA 流程，每次都能复现 |
| Exploitability | 6 | 需要中间人攻击能力，但不算太难 |
| Affected Users | 10 | 所有支持 OTA 的车辆 |
| Discoverability | 7 | 如果 OTA 协议没有加密，很容易被逆向 |
总分 40，平均 8 分。这属于高风险，必须优先处理。
3.4 攻击树：画一张黑客的作战地图
攻击树是一种树形结构，根节点是攻击者的最终目标，子节点是达成目标需要执行的步骤。
举个例子。攻击者的目标是「远程控制车辆的刹车系统」。攻击树可能是这样的：
远程控制刹车系统
├── 1. 进入车载网络
│ ├── 1.1 通过 OTA 漏洞进入
│ │ ├── 1.1.1 伪造 OTA 服务器证书
│ │ └── 1.1.2 利用 OTA 客户端缓冲区溢出
│ ├── 1.2 通过蓝牙漏洞进入
│ │ └── 1.2.1 破解蓝牙配对密钥
│ └── 1.3 通过物理接口进入
│ └── 1.3.1 连接 OBD-II 端口
├── 2. 横向移动到制动控制单元
│ ├── 2.1 通过 CAN 总线发送伪造报文
│ └── 2.2 利用网关路由漏洞转发恶意消息
└── 3. 发送制动指令
├── 3.1 发送 CAN ID 0x123 的制动报文
└── 3.2 绕过网关的防火墙规则
画攻击树的好处是什么？我跟你讲，它能帮你找到「最薄弱的环节」。你看上面这棵树，如果 OTA 的证书校验做得很好，但蓝牙配对密钥是硬编码的，那攻击者大概率会走蓝牙这条路。
我个人习惯是，把攻击树画在白板上，然后问团队：「哪个叶子节点最容易实现？」那个节点就是我们要优先加固的地方。
3.5 实战：车载网关的威胁建模流程
好了，理论讲完了。咱们来点实际的。我一般按这个流程走：
- 定义系统边界：网关的输入输出是什么？哪些是可信域，哪些是非可信域？
- 识别资产：按 3.1 节的方法，列出所有资产。
- 应用 STRIDE：对每个资产，逐一分析六类威胁。
- 构建攻击树：对高风险的威胁，画出攻击路径。
- DREAD 评分：给每个威胁打分，确定优先级。
- 制定缓解措施：针对高优先级威胁，设计安全控制。
举个例子。我在一个项目中，发现「诊断会话权限提升」这个威胁的 DREAD 分数很高。为什么呢？因为很多网关的诊断实现里，从默认会话切换到编程会话只需要发送一条特定的诊断请求，没有任何认证。攻击者只要连上 OBD-II 端口，就能刷写固件。
我们的缓解措施是：在切换会话时，要求发送一个基于密钥的挑战-响应认证。嗯，这个措施后来被证明非常有效，渗透测试团队花了三天都没绕过。
3.6 避坑指南
最后，分享几个我踩过的坑：
- 别只做 STRIDE 不做 DREAD：STRIDE 告诉你有什么威胁，但没告诉你哪个最危险。没有优先级，你会在低风险问题上浪费大量时间。
- 攻击树别画得太细：画到第三层就够了。再往下，细节会淹没重点。我曾经画过一个 7 层的攻击树，最后发现根本没法用。
- 别忘了物理攻击：很多人只关注网络攻击，忽略了物理接口。车载网关的 OBD-II 端口、调试串口、JTAG 接口，都是实实在在的攻击面。
- 威胁建模文档要活：别写完就扔进共享文件夹吃灰。我建议把威胁建模的结果直接关联到安全需求里，每个威胁对应一个安全需求，每个安全需求对应一个测试用例。
好了，这一章就到这里。下一章咱们聊聊防火墙的规则设计——怎么在性能和安全性之间找到平衡点。到时候见。