4、威胁分析与风险评估（TARA）
各位工程师，咱们今天聊TARA。说实话，这玩意儿在座舱合规里，是真正决定你安全投入方向的“总开关”。
我见过不少团队，一上来就堆加密、堆防火墙，结果关键路径反而漏了。为什么？因为没做系统性的威胁分析。TARA不是走过场，它是帮你回答三个问题：什么东西会被攻击？怎么攻击？后果多严重？
4.1 TARA方法论：从ISO 21434说起
目前行业里最主流的TARA方法，基本都跟着ISO 21434走。我个人习惯把它拆成五个步骤，像流水线一样：
- 资产识别 —— 找出需要保护的东西
- 威胁场景建模 —— 设想攻击者会怎么下手
- 影响评级 —— 评估安全、财产、隐私、运营四个维度的伤害
- 攻击可行性分析 —— 判断攻击门槛高不高
- 风险等级判定 —— 综合得出最终风险值
嗯，这里要注意：ISO 21434并没有规定你必须用哪种具体算法。你可以用HEAVENS，也可以用EVITA，甚至自己搭一套。但核心逻辑不变——风险 = 影响 × 攻击可行性。
核心原则： TARA不是一次性工作。每次架构变更、新增功能、甚至第三方库版本升级，都要重新审视。我在项目中遇到过，因为OTA升级包签名算法从SHA-256换成SHA-384，导致原有威胁场景的攻击路径完全失效——这种“被动安全提升”其实很常见。
4.2 资产识别：你到底在保护什么？
资产识别是TARA的第一步，也是最容易翻车的一步。很多团队只盯着“数据”，却忽略了“功能”和“硬件”。
我建议把座舱软件资产分成三类：
| 资产类型 | 典型例子 | 保护目标 |
|---|---|---|
| 数据资产 | 用户生物特征、车辆位置、蓝牙配对密钥 | 机密性、完整性 |
| 功能资产 | 语音助手、导航路径规划、空调控制 | 可用性、正确性 |
| 硬件/平台资产 | SoC安全域、TEE、CAN控制器 | 防篡改、防旁路 |
你想想看，如果只列数据资产，那“语音助手被恶意唤醒导致导航误导”这种威胁就漏了。功能资产的安全属性，往往比数据更致命。
实操技巧： 资产识别阶段，拉上系统架构师、功能安全工程师一起过一遍架构图。我曾经在评审会上，架构师随口说了一句“这个DDR区域是共享的”，结果发现两个不同安全等级的进程居然能通过DMA互相访问——这就是典型的资产边界模糊问题。
4.3 威胁场景建模：攻击者会怎么干？
资产识别完了，接下来就是“坏人视角”。我个人习惯用STRIDE模型来引导思考：
- Spoofing（欺骗） —— 冒充合法实体，比如伪造TSP服务器
- Tampering（篡改） —— 修改数据或代码，比如刷写非官方固件
- Repudiation（抵赖） —— 否认操作，比如日志被清空后无法追溯
- Information Disclosure（信息泄露） —— 敏感数据被窃取，比如蓝牙配对密钥被dump
- Denial of Service（拒绝服务） —— 让功能不可用，比如CAN总线被泛洪攻击
- Elevation of Privilege（权限提升） —— 从普通用户拿到root权限
- Spoofing： 攻击者通过蓝牙播放伪造的语音指令
- Tampering： 修改语音识别模型文件，让“打开车窗”变成“打开天窗”
- DoS： 持续发送无效音频流，导致语音服务崩溃
- 影响等级（Impact Rating）：安全（S）、财产（F）、隐私（P）、运营（O），每个维度分4级
- 攻击可行性（Attack Feasibility）：基于攻击时间、专业知识、资产知识、设备访问、样本访问五个参数
- 误区一：资产识别只做一次。 座舱软件迭代快，每次新增一个第三方SDK，都可能引入新的攻击面。我建议每个Sprint结束时，花半小时快速过一遍资产清单。
- 误区二：威胁场景写得像小说。 比如“黑客通过远程攻击获取车辆控制权”——太笼统。要写清楚是通过哪个接口、利用哪个漏洞、达到什么效果。
- 误区三：风险等级判定全靠拍脑袋。 攻击可行性评估有五个参数：攻击时间、专业知识、资产知识、设备访问、样本访问。每个参数都有对应的量化标准，别凭感觉打分。
- 误区四：TARA文档写完就锁柜子里。 安全需求要落到开发任务里，测试用例要覆盖威胁场景。我曾经在一个项目里，TARA报告写了200页，结果开发团队根本不知道哪些代码需要加固——这就是典型的“文档与开发脱节”。
每个资产，至少过一遍这六类。举个例子，对于“车载语音助手”这个功能资产：
嗯，这里有个坑：不要只写“攻击者可能篡改数据”这种空话。威胁场景必须具体到“谁、通过什么路径、对哪个资产、做了什么”。我见过最离谱的威胁描述是“攻击者可能攻击系统”——这等于没写。
避坑指南： 我曾经在一个项目里，团队把“攻击者通过Wi-Fi入侵座舱”写成了威胁场景。但实际架构里，Wi-Fi模块运行在独立的安全域，与座舱主域之间只有单向消息通道。这个威胁场景根本不可行。所以，威胁建模一定要结合实际的网络拓扑和隔离策略，别凭空想象。
4.4 风险等级判定：算清楚这笔账
风险等级判定，说白了就是给每个威胁场景打分。ISO 21434推荐从两个维度评估：
我习惯用下面这个矩阵来定级：
| 影响等级 | 攻击可行性低 | 攻击可行性中 | 攻击可行性高 |
|---|---|---|---|
| 严重（S4/F4/P4/O4） | 中等风险 | 高风险 | 极高风险 |
| 主要（S3/F3/P3/O3） | 低风险 | 中等风险 | 高风险 |
| 轻微（S2/F2/P2/O2） | 可忽略 | 低风险 | 中等风险 |
| 无影响（S1/F1/P1/O1） | 可忽略 | 可忽略 | 低风险 |
举个例子：如果某个威胁场景会导致“车辆在高速行驶时刹车失灵”，那安全影响肯定是S4。但如果攻击者需要物理接触车辆、拆开中控台、用JTAG调试器才能触发——攻击可行性就是低。最终风险等级是“中等风险”。
你可能会问：中等风险要不要处理？我的建议是：所有中等及以上风险，都必须有缓解措施。可忽略和低风险可以记录在案，但要有书面理由。
关键提醒： 风险等级判定不是终点，而是安全需求生成的起点。每个高风险项，都要对应一条安全需求。比如“高风险：OTA升级包被篡改” → 安全需求：“OTA升级包必须使用ECDSA签名，且公钥存储在HSM中”。没有这个映射，TARA就白做了。
4.5 TARA全流程知识图谱
下面这张图，是我自己总结的TARA核心流程。你可以把它贴在工位上，每次做TARA时对照着走一遍。
4.6 实战中的几个常见误区
最后，分享几个我在实际项目里踩过的坑：
我的习惯： 每次TARA评审会，我都要求安全工程师、开发负责人、测试负责人三方签字。不是为了追责，而是确保信息真正传递到了执行层。你想想看，如果做TARA的人不跟写代码的人对齐，那风险分析再漂亮也没用。