第三章：威胁建模方法论
威胁建模，说白了就是「先想好敌人怎么打，再设计自己的盾牌」。
我在车载安全这行干了快十年，见过太多「先上车后补票」的项目——功能都开发完了，才想起来做安全分析。结果呢？要么大改架构，要么留一堆漏洞上线。所以，我建议每个项目在需求阶段就把威胁建模做起来。
3.1 STRIDE模型：微软的经典六步法
STRIDE 是微软提出的威胁分类模型。名字来自六种威胁类型的首字母：
| 字母 | 威胁类型 | 通俗解释 | 车载场景举例 |
|---|---|---|---|
| S | Spoofing（欺骗） | 冒充别人身份 | 伪造ECU的CAN ID发送虚假报文 |
| T | Tampering（篡改） | 修改数据或代码 | 刷写非法的固件到T-Box |
| R | Repudiation（抵赖） | 做了事不认账 | 攻击后删除日志，无法溯源 |
| I | Information Disclosure（信息泄露） | 不该看的被看到了 | 通过OBD接口窃取车辆VIN和位置 |
| D | Denial of Service（拒绝服务） | 让系统没法用 | 向CAN总线发送大量垃圾帧，导致网关瘫痪 |
| E | Elevation of Privilege（权限提升） | 从小权限变成大权限 | 从IVI的普通应用提权到系统级root |
我的经验：STRIDE 最适合用在「数据流图」上。你画好系统架构图，然后对着每个数据流、每个存储、每个进程，挨个问「这里能不能S？能不能T？能不能R？」。我习惯用Excel表格列出来，一行一个威胁，效率很高。
小技巧：车载项目里，Spoofing 和 Tampering 是最常见的。尤其是 CAN 总线上的欺骗攻击，几乎每个项目都会遇到。所以，优先关注这两个。
3.2 攻击树分析：把攻击路径画成一棵树
攻击树是 Bruce Schneier 提出的方法。根节点是攻击者的最终目标，子节点是达成目标需要的步骤。
举个例子，攻击者的目标是「远程控制车辆刹车」：
根目标：远程控制刹车
├── 1. 进入车载网络
│ ├── 1.1 通过T-Box远程入侵
│ │ ├── 1.1.1 利用T-Box固件漏洞
│ │ └── 1.1.2 暴力破解T-Box登录密码
│ └── 1.2 通过蓝牙近距离入侵
│ └── 1.2.1 破解蓝牙配对密钥
├── 2. 发送刹车指令
│ ├── 2.1 伪造CAN刹车报文
│ └── 2.2 篡改合法ECU的刹车逻辑
└── 3. 绕过安全监控
└── 3.1 禁用网关的防火墙规则为什么要画攻击树？因为你可以直观地看到：哪些路径最容易走通？哪些节点是「必由之路」？
避坑指南：我曾经犯过一个错误——攻击树画得太细，每个叶子节点都列了十几步。结果分析起来累死人，而且很多分支根本不可能实现。后来我学乖了：攻击树只画到「攻击方法」这一层，具体的技术细节留给后面的渗透测试去验证。
3.3 攻击路径图：从攻击者视角看全局
攻击路径图跟攻击树有点像，但更强调「顺序」和「依赖关系」。它像一张地铁线路图，告诉你从起点（攻击入口）到终点（攻击目标）需要经过哪些站。
我常用的画法是这样的：
- 入口节点：攻击者从哪里进来？比如Wi-Fi、蓝牙、OBD接口、4G/5G网络。
- 中间节点：攻击者需要攻破哪些组件？比如T-Box、网关、域控制器。
- 目标节点：攻击者最终想控制什么？比如刹车系统、转向系统、车门锁。
- 边：节点之间的攻击方法，比如「利用协议漏洞」、「暴力破解」、「提权」。
举个例子，一个典型的攻击路径：
[攻击者] → [Wi-Fi热点] → [IVI娱乐系统] → [网关] → [CAN总线] → [刹车ECU]这条路径上，每个箭头都代表一个攻击步骤。你想想看，如果网关能拦住非法CAN报文，那攻击者就卡在网关这一站了。所以，网关就是「高价值防御点」。
我的建议：攻击路径图最好跟系统架构师一起画。因为他们最清楚数据怎么流、组件怎么连。我每次做威胁建模，都会拉上架构师开个1小时的会，在白板上画路径图。画完之后，安全方案也就清晰了。
3.4 威胁建模工具介绍
光靠脑子想和手画，容易漏。所以，我推荐用工具来辅助。下面是我用过的几款：
| 工具名称 | 类型 | 优点 | 缺点 |
|---|---|---|---|
| Microsoft Threat Modeling Tool | 桌面软件 | 免费、自带STRIDE模板、自动生成威胁列表 | 只支持Windows、模板偏IT，车载场景需要自定义 |
| OWASP Threat Dragon | Web/桌面 | 开源、跨平台、支持多人协作 | 功能相对简单，没有自动威胁分析 |
| IriusRisk | 商业软件 | 支持完整的安全开发生命周期、集成度高 | 收费、学习曲线陡 |
| draw.io + 自定义模板 | 在线/桌面 | 灵活、免费、可以自己画攻击树和路径图 | 没有自动分析功能，全靠人工 |
我的选择：小团队或者项目初期，我推荐用 draw.io 自己画。因为车载系统的组件跟IT系统差别很大——你很难在微软的工具里找到「T-Box」或「网关」的图标。等架构稳定了，再用 IriusRisk 做正式的威胁库管理。
3.5 实战：把方法论用起来
光说不练假把式。我拿一个真实的项目举例：
某款新能源车的T-Box，支持远程OTA升级。我们做威胁建模时，用了STRIDE+攻击树组合：
- 画数据流图：T-Box从云端下载固件 → 校验签名 → 写入Flash → 重启生效。
- 套STRIDE：
- Spoofing：攻击者能不能伪造云端服务器？能，如果证书验证不严。
- Tampering：攻击者能不能篡改固件包？能，如果签名算法有漏洞。
- Denial of Service：攻击者能不能让T-Box一直下载失败？能，如果网络协议有缺陷。
- 画攻击树：根目标是「刷入恶意固件」。子节点包括「绕过签名校验」、「利用缓冲区溢出」、「降级攻击」等。
- 找防御点：签名校验是必由之路，所以重点加固。我们用了硬件安全模块（HSM）来存储签名公钥，防止被篡改。
结果：这个项目后来通过了第三方安全测试，没有发现高危漏洞。说实话，威胁建模帮了大忙——它让我们在开发阶段就堵住了好几个坑。
3.6 总结：别让方法论变成形式主义
威胁建模不是「做完文档就完事」的。我见过一些团队，花了两周画了精美的攻击树，然后扔到文件夹里吃灰。这完全失去了意义。
我的习惯是：威胁建模的输出要跟开发任务挂钩。比如，每个威胁对应一个JIRA ticket，分配给对应的开发人员去修复。修复完了，还要回归测试，确认漏洞真的堵上了。
嗯，这一章就讲到这里。下一章，我们会聊攻击面识别——说白了，就是「你的车到底哪里能被打」。到时候我会分享一些我在实车测试中发现的「惊喜」。