2、威胁建模与风险评估：TARA方法论、攻击树分析、风险等级判定
好，咱们进入第二章。说实话，威胁建模这块，是很多工程师觉得「虚」的地方。总觉得画几张图、列几个表，能解决啥实际问题？
我刚开始做车载安全那会儿，也这么想。直到有一次，我们一个T-Box项目在渗透测试中被攻破了远程解锁接口。复盘时才发现，这个攻击路径在威胁建模阶段其实已经被识别出来了，但当时觉得「概率太低」就给忽略了。嗯，从那以后，我再也不敢轻视TARA了。
2.1 TARA方法论：从资产到风险的完整链路
TARA，全称是Threat Analysis and Risk Assessment。说白了，就是一套系统化的「找茬」流程。它帮你回答三个问题：什么东西值得保护？谁会来攻击？后果有多严重？
我个人习惯把TARA分成五个步骤：
- 资产识别 – 找出需要保护的东西
- 威胁场景分析 – 设想可能的攻击方式
- 影响评级 – 评估出事后的损失
- 攻击可行性分析 – 判断攻击难度
- 风险等级判定 – 综合得出最终结论
你想想看，这其实跟医生看病很像。先问哪里不舒服（资产），再推测可能是什么病（威胁），最后判断严重程度（风险）。
核心要点：TARA不是一次性工作。我建议在每个架构迭代中都跑一遍。因为新功能引入，往往意味着新攻击面。
2.2 攻击树分析：把攻击路径可视化
攻击树，是我个人非常喜欢的一个工具。它把一次攻击拆解成多个子目标，形成一棵倒着长的树。
举个例子。假设我们要分析「攻击者通过OTA升级植入恶意固件」这个场景。攻击树可能是这样的：
根节点：成功植入恶意固件
├── OR 获取签名私钥
│ ├── 从服务器窃取
│ ├── 从开发环境泄露
│ └── 暴力破解
├── AND 绕过签名验证
│ ├── 利用缓冲区溢出
│ └── 篡改验证逻辑
└── AND 物理访问ECU
├── 打开车辆外壳
└── 连接调试接口
这里要注意「AND」和「OR」节点。AND表示所有子条件必须同时满足，OR表示只要满足一个就行。这直接影响风险评估的结论。
我的经验：画攻击树时，别贪多。我一般控制在3-4层深度。太深了反而看不清重点。曾经有个项目，团队画了一棵7层的攻击树，最后发现90%的叶子节点根本不可能实现，白白浪费了时间。
2.3 风险等级判定：量化你的焦虑
风险等级判定，说白了就是把「感觉」变成「数字」。ISO 21434里推荐了一个经典矩阵：
| 攻击可行性 | 影响：严重 | 影响：主要 | 影响：轻微 |
|---|---|---|---|
| 高 | 严重 | 高 | 中 |
| 中 | 高 | 中 | 低 |
| 低 | 中 | 低 | 可忽略 |
影响评级我一般看四个方面：
- 安全 – 会不会导致人员伤亡？
- 财产 – 车辆损坏还是数据泄露？
- 隐私 – 用户信息被窃取？
- 合规 – 违反法规要求？
攻击可行性则考虑：
- 攻击者需要什么设备？
- 需要多少专业知识？
- 攻击窗口期多长？
- 有没有现成的攻击工具？
避坑指南：我曾经犯过一个错误——把「攻击可行性」和「攻击者动机」混为一谈。一个攻击虽然技术上可行，但如果攻击者没有收益，实际风险其实很低。记住，我们评估的是「可能性」，不是「能力」。
2.4 实战中的常见误区
做了这么多年安全评估，我总结出几个常见坑：
- 过度乐观 – 「这个攻击太复杂了，没人会做」——结果呢？总有比你想象中更执着的人。
- 忽略供应链 – 只关注自己的ECU，却忘了第三方库、云服务、甚至芯片本身都可能成为攻击入口。
- 静态思维 – 威胁建模不是交作业。车辆上路后，新的攻击手法会不断出现。我建议每半年重新评估一次。
- 只画图不行动 – 攻击树画得再漂亮，如果不转化为安全需求，就是一张废纸。
嗯，这里要注意一点。风险评估的最终输出，不是一张表格，而是一份「行动清单」。哪些风险需要立即修复？哪些可以接受？哪些需要持续监控？这些才是真正有价值的东西。
好了，第二章就到这里。下一章我们会聊聊「安全架构设计原则」，看看怎么把这些风险评估结果落地成具体的防护方案。