3. 项目依赖的网络安全环境（TARA）：资产识别、威胁场景分析、影响评级、攻击路径分析

好，咱们进入正题。这一章聊的是TARA，也就是威胁分析与风险评估。说实话，这是ISO 21434落地过程中最核心、也最容易被搞砸的一步。我见过太多项目，TARA做得像走过场，最后评审时被怼得哑口无言。

为什么？因为很多人把TARA当成了一次性的文档工作。其实不然。TARA应该贯穿整个项目生命周期，从概念阶段就开始，一直持续到量产后的运维阶段。你想想看，一辆车要跑十几年，网络安全威胁也在不断变化，怎么可能做一次就完事？

3.1 资产识别：你得知道你要保护什么

资产识别是TARA的第一步，也是最基础的一步。说白了，就是搞清楚你的系统里有哪些东西是值钱的、是可能被攻击的。

资产分类，我个人习惯分成三类：

• 功能资产：比如制动控制、转向控制、动力总成这些直接影响车辆行为的功能
• 数据资产：包括用户隐私数据（位置、身份信息）、车辆配置数据、固件代码等
• 通信资产：CAN总线、以太网、蓝牙、Wi-Fi、蜂窝网络等通信通道

我在一个项目中遇到过这样的情况：团队只识别了ECU本身作为资产，却忽略了ECU之间通信的CAN报文。结果呢？攻击者通过OBD接口注入伪造报文，直接绕过了所有安全机制。嗯，这个教训挺深刻的。

识别资产时，我建议你拉上系统工程师、功能安全工程师一起做。一个人闭门造车，很容易漏掉关键资产。尤其是那些跨系统的交互数据，往往是攻击者最喜欢的目标。

3.2 威胁场景分析：攻击者会怎么搞破坏？

资产识别完了，接下来要思考：谁会攻击这些资产？用什么方式？达到什么目的？这就是威胁场景分析。

常用的方法有STRIDE模型，这个在ISO 21434里也推荐使用。STRIDE是六个威胁类型的首字母缩写：

• Spoofing（欺骗）：冒充合法实体，比如伪造ECU身份
• Tampering（篡改）：修改数据或代码，比如刷写非法固件
• Repudiation（抵赖）：否认做过的事，比如否认发送过某个指令
• Information Disclosure（信息泄露）：敏感数据被窃取
• Denial of Service（拒绝服务）：让系统不可用，比如CAN总线泛洪攻击
• Elevation of Privilege（权限提升）：获取更高权限，比如从普通用户提权到管理员

举个例子。对于制动控制ECU这个资产，我们可以分析出这样的威胁场景：

写威胁场景时，我有个小习惯：尽量用「攻击者通过...方式，利用...漏洞，达到...目的」这样的句式。这样写出来的场景清晰、可追溯，评审时也容易理解。

3.3 影响评级：这事儿有多严重？

威胁场景分析完了，得给每个场景打个分。影响评级主要看四个方面：

影响维度	描述	评级示例
安全（Safety）	对人员生命安全的威胁	严重（S3）：可能导致死亡
财务（Financial）	经济损失	重大（F2）：数万元级损失
隐私（Privacy）	个人数据泄露	严重（P3）：大规模隐私泄露
操作（Operational）	车辆功能受影响	严重（O3）：车辆完全不可用

评级时要注意，不能只看最坏情况。我见过有人把所有场景都评成最高级，结果导致所有风险都不可接受，项目根本没法推进。这其实是在逃避真正的优先级判断。

正确的做法是：结合攻击可行性、资产价值、防护措施等因素综合评估。比如，一个需要物理接触且需要专业设备的攻击，和一個通过远程网络就能发起的攻击，影响评级肯定不一样。

3.4 攻击路径分析：找到那条最脆弱的链路

影响评级完了，接下来要分析攻击路径。说白了，就是攻击者要经过哪些步骤才能达成威胁场景。

攻击路径分析常用的方法是攻击树（Attack Tree）。根节点是攻击目标，子节点是达成目标所需的步骤。每个步骤还可以继续分解，直到不可再分。

举个例子，对于「远程控制制动」这个威胁场景，攻击路径可能是这样的：

攻击目标：远程控制制动
├── 1. 获取车辆远程访问权限
│   ├── 1.1 破解T-Box的蜂窝网络认证
│   │   ├── 1.1.1 利用SIM卡漏洞
│   │   └── 1.1.2 破解T-Box固件
│   └── 1.2 利用OEM云平台漏洞
│       ├── 1.2.1 获取合法用户凭证
│       └── 1.2.2 利用API接口漏洞
├── 2. 从远程网络渗透到CAN网络
│   ├── 2.1 利用网关的防火墙漏洞
│   └── 2.2 通过信息娱乐系统作为跳板
└── 3. 发送伪造制动指令
    ├── 3.1 伪造CAN报文ID
    └── 3.2 绕过制动ECU的报文认证

分析攻击路径时，我建议你重点关注那些「低成本、高回报」的路径。比如，通过云平台漏洞远程攻击，比物理接触攻击更容易被利用，风险也更高。

另外，攻击路径分析不是一次性的。随着系统设计变更、新漏洞披露，攻击路径也会变化。我习惯在每个开发迭代结束时，重新审视一遍攻击路径，看看有没有新增的风险点。

3.5 风险处置决策：接下来怎么办？

TARA的最后一步，是根据影响评级和攻击路径分析结果，决定每个风险怎么处理。ISO 21434给出了四种处置方式：

• 规避（Avoidance）：修改设计，彻底消除风险。比如，去掉不必要的远程控制功能。
• 降低（Reduction）：增加安全措施，降低风险等级。比如，增加报文认证、加密通信。
• 转移（Transfer）：把风险转给第三方。比如，使用经过认证的安全芯片。
• 接受（Acceptance）：风险在可接受范围内，不做额外处理。但需要记录理由。

这里有个常见的误区：很多人觉得「接受」就是不管了。其实不是。接受风险意味着你确认了风险等级在可接受范围内，并且有明确的理由。比如，某个攻击需要攻击者拥有价值100万的专用设备，且攻击成功后只能造成轻微影响，那这个风险就可以接受。

好了，这一章的内容就到这里。TARA做得好不好，直接决定了后续安全开发的成败。我个人建议，第一次做TARA时，多花点时间在资产识别和威胁场景分析上。这两步做扎实了，后面的评级和路径分析就水到渠成。

下一章，我们会聊聊安全目标定义和概念阶段的安全设计。到时候见。