3、威胁分析与风险评估（TARA）：基于ISO 21434的TARA方法论
好，咱们进入正题。TARA，全称是Threat Analysis and Risk Assessment。说白了，就是给咱们的汽车系统做一次「体检」，看看哪些地方容易被黑客盯上，以及被盯上后后果有多严重。
ISO 21434里把TARA当作核心流程。我个人习惯，拿到一个新项目，第一件事不是写代码，而是先拉上系统工程师、软件工程师，一起把TARA跑一遍。为什么？因为后面所有的安全需求、安全机制，都得从这里长出来。
3.1 TARA的核心目标
你想想看，做网络安全最怕什么？最怕「我以为」。我以为这个接口没人碰，结果被攻破了。我以为这个数据不重要，结果被篡改了。
TARA要解决三个问题：
- 什么东西需要保护？——识别出关键资产（Asset）
- 谁可能来搞破坏？——分析威胁场景（Threat Scenario）
- 搞破坏的后果有多严重？——评估风险等级（Risk Level）
嗯，这里要注意。TARA不是一次性的工作。我在项目中遇到过，产品迭代到第三版，新增了一个OTA功能，结果原来的TARA完全失效了。所以，TARA要跟着项目走，动态更新。
3.2 TARA的七步法
ISO 21434把TARA拆成了七个步骤。我给大家梳理一下，每一步都有坑，我会把踩过的坑指出来。
| 步骤 | 名称 | 核心产出 |
|---|---|---|
| 1 | 资产识别 | 资产清单（Asset Inventory） |
| 2 | 威胁场景识别 | 威胁场景列表 |
| 3 | 影响评级 | 影响等级（S, S1-S4） |
| 4 | 攻击路径分析 | 攻击可行性等级 |
| 5 | 风险等级确定 | 风险矩阵（Risk Matrix） |
| 6 | 风险处置决策 | 安全目标（Safety Goal） |
| 7 | 文档化 | TARA报告 |
3.3 资产识别——别漏了「隐形资产」
第一步，找出所有需要保护的「东西」。这里的资产不只是硬件，还包括数据、功能、甚至时间。
举个例子：
- 硬件资产：ECU、传感器、执行器
- 软件资产：Bootloader、固件、配置参数
- 数据资产：车辆VIN、用户隐私、诊断日志
- 功能资产：制动功能、转向功能、远程解锁
3.4 威胁场景识别——用STRIDE来帮忙
资产找出来了，接下来要问：这些资产可能被怎么攻击？
我建议用微软的STRIDE模型来引导思考。STRIDE是六个维度的缩写：
- Spoofing（欺骗）：冒充合法实体。比如伪造ECU身份。
- Tampering（篡改）：修改数据或代码。比如篡改固件。
- Repudiation（抵赖）：否认做过的事。比如否认发送过恶意指令。
- Information Disclosure（信息泄露）：敏感数据被偷看。比如窃取密钥。
- Denial of Service（拒绝服务）：让系统不可用。比如CAN总线泛洪攻击。
- Elevation of Privilege（权限提升）：获得不该有的权限。比如从普通用户提权到管理员。
你想想看，每个资产至少过一遍STRIDE，基本不会漏。我在项目中遇到过，团队用STRIDE过了一遍，发现一个「信息泄露」的威胁场景——诊断接口的日志里居然包含了明文密钥。这个要是漏了，后果不堪设想。
3.5 影响评级——别只看技术，要看业务
威胁场景有了，接下来要评估：如果这个威胁真的发生了，会造成什么影响？
ISO 21434把影响分为四个等级：
| 等级 | 描述 | 举例 |
|---|---|---|
| S1 | 轻微影响 | 娱乐系统卡顿，不影响安全 |
| S2 | 中等影响 | 导航失效，驾驶员需要手动操作 |
| S3 | 严重影响 | 制动助力失效，需要更大力度踩刹车 |
| S4 | 灾难性影响 | 制动完全失效，无法减速 |
我个人习惯： 影响评级不能只让安全工程师拍脑袋。一定要拉上功能安全工程师和系统工程师一起讨论。为什么？因为有些影响是「连锁反应」。比如一个娱乐系统的漏洞，可能通过车内网络影响到制动系统。这种跨域的影响，一个人很难想全。
3.6 攻击路径分析与可行性评估
影响评完了，接下来要看：攻击者要达成这个威胁，难度有多大？
攻击可行性评估，我一般看四个维度：
- 攻击时间：需要几分钟？几小时？还是几个月？
- 专业知识：需要普通黑客水平？还是顶级专家？
- 设备成本：需要一台电脑？还是需要价值百万的专用设备？
- 攻击机会：需要物理接触？还是远程就能搞定？
举个例子：
- 远程攻击（比如通过4G/5G）→ 攻击机会高 → 可行性高
- 需要拆开ECU外壳，用JTAG调试器 → 攻击机会低 → 可行性低
嗯，这里要注意。攻击可行性不是一成不变的。我记得有一次，我们评估一个CAN总线攻击的可行性为「低」，因为需要物理接触。结果后来发现，攻击者可以通过OBD接口的蓝牙适配器远程接入。所以，攻击路径分析一定要动态更新。
3.7 风险等级确定——用矩阵说话
影响等级和攻击可行性都出来了，接下来就是「算账」了。ISO 21434推荐用风险矩阵来确定最终的风险等级。
| 影响等级 | 攻击可行性高 | 攻击可行性中 | 攻击可行性低 |
|---|---|---|---|
| S4（灾难性） | 严重风险 | 严重风险 | 中等风险 |
| S3（严重） | 严重风险 | 中等风险 | 低风险 |
| S2（中等） | 中等风险 | 低风险 | 低风险 |
| S1（轻微） | 低风险 | 低风险 | 可忽略 |
避坑指南： 我曾经见过一个团队，把所有风险都评成了「中等」。为什么？因为不敢评「严重」，怕被领导骂；也不敢评「低」，怕被审计说不够严格。结果整个TARA报告失去了区分度。我的建议是：该严重就严重，该低就低。风险等级是用来指导决策的，不是用来讨好谁的。
3.8 风险处置决策——四种选择
风险等级出来了，接下来要决定：怎么处理这个风险？
ISO 21434给出了四种处置方式：
- 规避（Avoid）：直接去掉这个功能或接口。比如，如果远程诊断接口风险太高，干脆砍掉。
- 降低（Reduce）：增加安全机制来降低风险。比如，加加密、加认证、加防火墙。
- 转移（Transfer）：把风险转给第三方。比如，让云服务商负责通信安全。
- 接受（Accept）：风险低到可以接受，或者有业务原因必须保留。但需要记录在案，并得到管理层批准。
我个人习惯，对于「严重风险」，必须降低到「中等」或以下。对于「中等风险」，至少要有缓解措施。对于「低风险」，可以接受，但要定期复查。
3.9 文档化——别让TARA变成「黑盒」
最后一步，把所有的分析过程、决策依据、风险等级都写下来。这不是为了应付审计，而是为了后续的追溯和复用。
一份完整的TARA报告应该包含：
- 资产清单及分类
- 威胁场景及对应的STRIDE维度
- 影响评级及理由
- 攻击路径分析及可行性评估
- 风险矩阵及最终风险等级
- 风险处置决策及对应的安全目标
我曾经踩过的坑： 有一次，我们做完TARA后，没有及时更新文档。三个月后，项目组换了一批人，新来的工程师完全不知道当初为什么做这个决策。结果，他们又把已经规避掉的风险重新引入了。所以，文档不是写给别人看的，是写给未来的自己看的。
3.10 小结
TARA是网络安全设计的「地基」。地基没打好，上面盖的房子再漂亮也没用。我建议大家在项目初期就投入足够的时间做TARA，而不是等到开发快结束了才补。
记住一句话：没有TARA的网络安全，就像没有地图的旅行——你可能走得很远，但大概率会走错方向。
下一章，咱们聊聊如何把TARA的输出转化为具体的安全需求。嗯，那才是真正开始「干活」的时候。