ISO21434 信息安全风险分析 Roadmap and Method for Implementing ISO/SAE 21434 Cybersecurity Risk Analysis in Automotive Cybersecurity Risk Analysis and Management for ISO 21434 Compliant Automotive

说到汽车，你脑海里的画面是什么？是引擎的轰鸣，是弯道中的操控感，还是那种机械带来的安全信赖？现在的车早就变了。它们变成了跑在马路上的超级计算机，拥有几百个电子控制单元（ECU），几百兆行代码，还有4G/5G联网功能。听起来很酷对吧？但这也意味着，以前的“偷车”是撬门锁，现在的“偷车”可能是通过蓝牙、Wi-Fi，甚至是你车机系统的一个漏洞，远程黑进你的刹车或转向系统。

这就是为什么ISO/SAE 21434这个标准变得如此重要。它不只是给车企看的合规文档，它是现代智能汽车的安全基石。今天，我们就来把这个听起来高大上的“网络安全风险分析”掰开揉碎，像给聪明的小朋友讲故事一样，把它讲清楚。如果你正是一名正在为项目头疼的汽车工程师，或者是对汽车安全感兴趣的技术爱好者，这篇指南就是为你准备的。

为什么要给汽车穿上“数字防弹衣”？

在深入技术细节之前，我们先来聊聊背景。2015年，两位研究员Charlie Miller和Chris Valasek远程入侵了一辆 Jeep Cherokee。他们在高速公路上远程控制方向盘、刹车，甚至切断了引擎动力。那辆车当时有100多个ECU，负责从引擎管理到娱乐系统的一切。这件事震惊了整个汽车行业，也直接催生了ISO/SAE 21434标准的诞生。

以前，汽车网络安全是个“黑盒”，大家凭经验做，没有统一标准。现在，ISO/SAE 21434规定了从概念阶段到报废阶段，整个汽车生命周期都要怎么做网络安全。而其中的核心环节，就是网络安全风险分析（Cybersecurity Risk Analysis）。

你可以把汽车想象成一栋智能大楼。以前这栋楼只有物理锁（机械钥匙），现在它有指纹锁、APP远程开门、监控摄像头、电梯系统、电力控制系统……如果只防贼撬门，不管电梯系统有没有被黑客劫持，那这栋楼还是很危险。ISO 21434就是教你如何系统地检查这栋楼里的每一个系统，找出哪里可能被攻击，后果有多严重，然后怎么修补。

核心概念：TARA——风险分析的代名词

在ISO 21434的语境里，你听到的最高频的词一定是TARA，全称是威胁分析与风险评估（Threat Analysis and Risk Assessment）。它是整个标准的技术核心，也是工程师们花费精力最多的地方。

TARA不是一次会议，而是一套严谨的方法论。它回答三个核心问题：

谁会攻击我？为什么？怎么攻击？（威胁源与攻击向量）
如果攻击成功，后果有多严重？（影响评估）
我们能承受这个风险吗？如果不能，怎么办？（风险评价与处置）

很多初学者会把TARA当成一个孤立的文档工作，这是最大的误区。TARA应该贯穿整车开发的始终，随着软件版本的迭代而更新。它不是一次性的“交作业”，而是动态的安全守护。

第一步：识别与定义——找出你的“数字资产”

分析风险之前，你得先知道有哪些东西值得被保护。在ISO 21434中，这叫做资产识别（Asset Identification）。

1.1 什么是“资产”？

在汽车里，资产不仅仅是数据，还包括：

功能资产：比如“防抱死刹车系统（ABS）正常工作”、“车辆保持车道”。
数据资产：比如“用户个人身份PII”、“车辆GPS位置”、“加密密钥”、“车辆配置数据”。
通信资产：比如“CAN总线上的关键控制指令”。

1.2 如何识别资产？

通常会使用功能树（Function Tree）或系统架构图来辅助。想象你在画一张地图，把车辆的各个子系统列出来：

动力域：发动机、变速箱、电池管理（BEV/HV）。
底盘域：制动、转向、悬挂。
车身域：车门锁、车窗、座椅、空调。
智驾域：ADAS、自动驾驶感知与决策。
网联域：T-Box、车载信息娱乐系统（IVI）、OTA升级模块。

实战案例： 假设你正在分析一辆具备L2级辅助驾驶功能的电动车。

功能资产：ACC自适应巡航、AEB自动紧急制动。
数据资产：高精地图数据、驾驶员生物特征（用于生物识别登录）、OTA签名密钥。
关联资产：V2X通信模块接收的路侧单元数据。

只有把资产列清楚，你才能知道“敌人”想偷什么、破坏什么。

第二步：威胁场景构建——想象最坏的情况

知道了有什么资产，接下来就要扮演“黑客”，思考威胁场景（Threat Scenarios）。这不是让你去真的攻击自己的车，而是通过逻辑推理，构建出可能的攻击路径。

ISO 21434提供了两种主要的方法来构建威胁场景：

参考攻击向量（Attack Vector）枚举：参考标准附录中的常见攻击路径。
基于场景的思维链（Chaining）：结合车辆的具体架构，串联起攻击步骤。

2.1 常见的攻击向量

黑客通常从哪里下手？

车内网络：通过OBD-II接口（维修接口）直接连接CAN总线。这是最古老但依然有效的手段，就像有人拿着万能钥匙插进你的点烟器孔。
无线接口：蓝牙（Keyless Entry）、Wi-Fi、蜂窝网络（4G/5G）。比如，黑客可以模拟一个恶意热点，诱导车辆连接，然后进行中间人攻击。
供应链/开发环境：通过攻击Tier 1供应商的软件开发环境，注入恶意代码，再通过OTA升级进入车辆。这是近年来最高级的威胁。
物理访问：拆开后盖，直接访问ECU的调试接口（JTAG/SWD）。

2.2 构建威胁场景的例子

让我们以“远程解锁并盗窃车辆”这个常见威胁为例，构建一个具体的场景：

威胁场景 TS-01：通过手机App漏洞远程解锁车辆

威胁源：远程攻击者（具备移动网络接入能力）。
攻击路径：
- 攻击者发现了车企手机App后端API的一个逻辑漏洞（如缺乏速率限制或令牌重放漏洞）。
- 攻击者批量尝试获取合法用户的会话令牌。
- 攻击者利用令牌向T-Box发送“解锁车门”和“启动引擎”的指令。
- T-Box验证指令后，通过CAN总线向车身控制模块（BCM）发送解锁指令。
潜在后果：车辆被远程盗走，用户隐私泄露。

你看，这样一个简单的场景，就涉及了云端、手机App、T-Box、CAN总线、BCM等多个环节。这就是为什么风险分析必须跨域进行。

第三步：影响评估——后果有多严重？

不是所有的风险都一样严重。ISO 21434引入了影响类别（Impact Categories）来量化后果。这比单纯说“很严重”要科学得多。

3.1 四大影响类别

物理影响（Safety Impact, SF）：
- 这是最重要的。攻击是否会导致人身伤害或死亡？
- 例如：黑客篡改刹车信号，导致AEB失效，引发碰撞。这属于高安全影响。
资产影响（Asset Impact, AF）：
- 攻击是否导致数据泄露、丢失或损坏？
- 例如：黑客窃取了用户的通讯录和照片。这属于高资产影响，但可能不涉及直接的人身伤害。
业务影响（Business Impact, BF）：
- 攻击是否导致车企品牌声誉受损、诉讼成本增加、业务中断？
- 例如：大规模车辆被勒索病毒锁死，车企需要支付巨额赎金并面临召回。
合规影响（Compliance Impact, CF）：
- 攻击是否导致违反法律法规（如GDPR、中国数据安全法）？
- 例如：未经授权将用户位置数据上传至境外服务器。

3.2 如何评估影响等级？

通常分为高（High）、中（Medium）、低（Low）三个等级。评估时需要考虑：

受影响的用户数量：是单个用户，还是百万级车队？
严重程度：是轻微不便，还是致命伤害？
持续时间：是瞬时干扰，还是永久损坏？

实战案例： 回到上面的“远程解锁盗窃”场景：

SF（安全影响）：低。因为只是偷车，没有直接导致碰撞或人员伤害（假设驾驶员在车内时未被攻击）。
AF（资产影响）：高。用户隐私泄露，车辆资产丢失。
BF（业务影响）：高。品牌声誉严重受损，面临巨额召回和诉讼。
CF（合规影响）：中。涉及用户数据违规处理。

综合来看，虽然安全影响低，但资产和业务影响极高，这个威胁场景的风险等级依然很高。

第四步：风险评价——决定能不能接受

有了影响评估，接下来要判断风险等级（Risk Level）。这通常通过一个风险矩阵来完成。

4.1 鲁棒性等级（Robustness Level, RL）

ISO 21434引入了一个概念叫所需鲁棒性等级（Required Robustness Level, RRL）。这取决于两个因素：

影响等级（SF, AF, BF, CF）。
攻击可行性（Attack Feasibility, AF）：黑客攻破这个系统的难易程度。

攻击可行性考量因素：

专业知识要求：需要顶级黑客专家，还是普通脚本小子？
访问权限：需要物理接触，还是远程互联网即可？
成本与设备：需要昂贵的专业设备，还是一台普通笔记本电脑？
开发时间：是一天能搞定，还是需要数月研究？

鲁棒性等级表（简化版）：

影响等级	高攻击可行性	中攻击可行性	低攻击可行性
高	RL 3 (最高防护)	RL 2	RL 1
中	RL 2	RL 1	RL 1 (可接受)
低	RL 1	RL 1	RL 1 (可接受)

注：RL 3要求最高级别的工程措施，RL 1要求基本的安全工程实践。

4.2 风险接受准则

不可接受风险：必须通过风险处置来降低。
可容忍风险：需要在成本与收益平衡后，由项目经理决策是否接受，并记录在案。
可接受风险：无需额外措施，维持当前安全工程实践即可。

实战案例： 继续分析“远程解锁盗窃”：

假设评估为：高资产影响、高业务影响。
攻击可行性：中等（需要发现App漏洞，但不需要物理接触）。
查表可得：所需鲁棒性等级 RL 2。
结论：该威胁场景的风险处于“可容忍”或“不可接受”边缘，必须采取相应的安全措施将其降至合理水平。

第五步：风险处置——如何“治病救人”

识别出高风险后，你不能不管它。ISO 21434规定了四种风险处置策略：

风险规避（Avoid）：
- 改变设计，彻底消除威胁。
- 例子：移除不必要的远程解锁功能，或者禁止T-Box直接访问动力总成的CAN总线。
风险降低（Reduce/Mitigate）：
- 这是最常用的方法。通过安全措施降低攻击可行性或影响。
- 例子：增加多因素认证（MFA）、启用通信加密（TLS/IPsec）、实施入侵检测系统（IDS）、定期安全更新。
风险转移（Transfer）：
- 通过保险、合同条款等方式将风险转移给第三方。
- 例子：与供应商签订合同，要求其保证软件安全性，若出现漏洞由供应商承担责任。
风险接受（Accept）：
- 明知有风险，但成本过高或技术不可行，经决策后接受。
- 例子：对于一台完全离线、无联网功能的旧款仪表显示单元，鉴于其攻击面极小，决定不投入过多资源进行加固，仅记录为可接受风险。

关键点： 风险处置不是一次性的。对于RL 2和RL 3的威胁，你必须设计具体的网络安全措施（Cybersecurity Controls），并验证其有效性。

第六步：工具与方法论——工程师的武器库

好的风险分析需要好的工具。以下是行业内常用的方法和工具：

6.1 建模工具

SysML/UML：用于绘制系统架构图、序列图，清晰展示数据流和控制流。
Attack Trees（攻击树）：从目标（如“车辆被盗”）出发，逆向推导所有可能的攻击路径。这是一种非常直观的威胁建模方法。
STRIDE模型：微软提出的经典威胁分类法，适用于软件组件层面的分析：
- Spoofing（伪造）：冒充他人身份。
- Tampering（篡改）：修改数据。
- Repudiation（抵赖）：否认操作行为。
- Information Disclosure（信息泄露）：泄露敏感信息。
- Denial of Service（拒绝服务）：使系统不可用。
- Elevation of Privilege（权限提升）：获取更高权限。

6.2 自动化扫描工具

SAST（静态应用安全测试）：扫描源代码中的安全漏洞（如缓冲区溢出）。常用工具：Checkmarx, Fortify。
DAST（动态应用安全测试）：对运行中的应用进行黑盒测试。
Fuzzing（模糊测试）：向系统输入随机数据，寻找崩溃点或异常。对于汽车嵌入式软件，模糊测试是发现漏洞的神器。

6.3 威胁建模软件

Microsoft Threat Modeling Tool：免费且易用，适合入门。
IOActive’s TMS：专为汽车行业标准设计，输出直接符合ISO 21434格式。
Plextrus, Secura：商业化的汽车网络安全平台，集成化管理整个生命周期。

代码示例：一个简单的CAN报文伪造检测逻辑 虽然TARA是方法论，但实现需要代码。以下是一个伪代码示例，展示如何在ECU中实现基本的异常检测（作为风险降低措施的一部分）：

// 假设这是一个简单的CAN总线监控模块
#define CAN_ID_ACC_PEDAL 0x123
#define MAX_ACC_VALUE 100.0 // 最大加速度阈值
#define MIN_ACC_VALUE -10.0 // 最小减速度阈值

float last_acc_value = 0.0;
float rate_of_change_limit = 50.0; // 加速度变化率限制

bool detect_anomaly(uint32_t can_id, float acc_value) {
    if (can_id != CAN_ID_ACC_PEDAL) {
        return false; // 非目标CAN ID，忽略
    }
    
    // 检查值域是否合法
    if (acc_value > MAX_ACC_VALUE || acc_value < MIN_ACC_VALUE) {
        log_event("ANOMALY: Out of range ACC value: " + acc_value);
        return true;
    }
    
    // 检查变化率是否异常（防止快速篡改）
    float delta = abs(acc_value - last_acc_value);
    if (delta > rate_of_change_limit) {
        log_event("ANOMALY: Abrupt ACC change detected: " + delta);
        return true;
    }
    
    last_acc_value = acc_value;
    return false;
}

这段代码虽然简单，但它体现了ISO 21434中“检测与响应”层面的安全措施。通过这种嵌入式监控，可以显著降低攻击成功的可能性。

常见陷阱：为什么你的TARA会失败？

即使掌握了方法，很多团队在做ISO 21434合规时还是踩坑。以下是几个最常见的陷阱：

陷阱1：TARA是“文档工作”而非“工程活动”

现象：工程师花几周时间写了一本厚厚的TARA报告，然后扔进文件夹，设计阶段完全不参考。后果：报告与实际设计脱节，审核时无法证明措施已实施。对策：将TARA输出直接转化为需求规格说明书（Cybersecurity Requirements Specification, CSRS）。每条威胁场景都必须有对应的安全需求，并在设计评审中检查这些需求是否被实现。

陷阱2：忽视供应链风险

现象：只分析自己编写的软件，忽略了购买的第三方中间件、开源库（如Linux内核、Qt、OpenSSL）。后果：漏洞发生在第三方组件，车企却背锅。对策：严格执行SBOM（软件物料清单）管理。要求供应商提供其组件的安全分析报告和CVE（通用漏洞披露）历史。对于关键开源库，要建立漏洞监控机制。

陷阱3：静态风险分析

现象：只在项目初期做一次TARA，之后不再更新。后果：随着新功能加入（如新增OTA功能），新的威胁出现，但风险档案没有更新。对策：建立变更管理流程。任何架构或功能的变更，都必须触发TARA的增量更新。TARA应该是“活文档”。

陷阱4：混淆“风险”与“漏洞”

现象：把发现一个漏洞当成风险消除。后果：修了一个漏洞，但另一个更严重的漏洞被忽略。对策：TARA关注的是场景和后果，而不仅仅是技术漏洞。一个漏洞可能导致高风险场景，也可能只是低风险场景。要从场景出发，全面评估。

正文

ISO21434 信息安全风险分析 Roadmap and Method for Implementing ISO/SAE 21434 Cybersecurity Risk Analysis in Automotive Cybersecurity Risk Analysis and Management for ISO 21434 Compliant Automotive

为什么要给汽车穿上“数字防弹衣”？

核心概念：TARA——风险分析的代名词

第一步：识别与定义——找出你的“数字资产”

1.1 什么是“资产”？

1.2 如何识别资产？

第二步：威胁场景构建——想象最坏的情况

2.1 常见的攻击向量

2.2 构建威胁场景的例子

第三步：影响评估——后果有多严重？

3.1 四大影响类别

3.2 如何评估影响等级？

第四步：风险评价——决定能不能接受

4.1 鲁棒性等级（Robustness Level, RL）

4.2 风险接受准则

第五步：风险处置——如何“治病救人”

第六步：工具与方法论——工程师的武器库

6.1 建模工具

6.2 自动化扫描工具

6.3 威胁建模软件

常见陷阱：为什么你的TARA会失败？

陷阱1：TARA是“文档工作”而非“工程活动”

陷阱2：忽视供应链风险

陷阱3：静态风险分析

陷阱4：混淆“风险”与“漏洞”

相关阅读

揭秘ISO21434：汽车行业信息安全标准解析与应用

揭秘ISO21434标准，深度解析汽车行业如何确保IT安全与合规

汽车安全新规ISO21434详解：如何影响汽车制造与驾驶安全

汽车行业新规ISO21434：揭秘汽车网络安全升级背后的秘密与挑战

掌握ISO21434标准，成为食品行业安全守护者：培训讲师必备技能解析

汽车软件漏洞频发ISO21434风险分析让功能安全与信息安全不再扯皮

揭秘ISO21434：如何为汽车行业打造信息安全风险防护盾牌

揭秘ISO21434：汽车行业系统安全设计的黄金法则，如何确保驾驶安全？

揭秘ISO21434：如何为汽车行业搭建坚固信息安全防护堡垒

儿童玩具安全标准ISO21434：揭秘如何保障孩子网络信息安全