ISO 21434 车辆网络安全 TARA 风险分析全流程实操

ISO/SAE 21434 车辆网络安全 TARA 风险分析全流程实操体系解析

引言

     随着智能网联汽车、自动驾驶、车载域控制器、车载 OTA、车云交互技术大规模落地，车辆数据泄露、远程劫持、固件篡改、车载 ECU 入侵等网络安全攻击面持续扩大。传统电气安全、功能安全风险评估手段无法覆盖车辆数字化带来的网络安全威胁，为此 ISO/SAE 21434《道路车辆 网络安全工程》标准统一规定TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估） 作为整车及零部件网络安全风险管控核心工具。TARA 贯穿整车概念开发、设计、试制、量产、售后全生命周期，是主机厂、一级供应商满足法规、TISAX、ISO26262 一体化审核的强制技术活动。

     本文系统拆解 TARA 完整闭环流程，覆盖资产识别、威胁识别、漏洞分析、风险估值、风险处置、验证迭代全环节，厘清各阶段输入输出、判定准则、落地实施要点，为车载软硬件开发团队提供标准化实施框架。全文围绕 ISO/SAE 21434:2023 标准条款要求，形成可直接用于项目开发、体系审核、第三方评估的标准化 TARA 实施逻辑。

一、TARA 基础定义与标准定位

1.1 TARA 核心概念

TARA 全称威胁分析与风险评估，是针对车载电子电气系统、软件、数据、通信接口开展的系统性风险分析方法。

其核心逻辑：识别资产→挖掘潜在威胁→分析系统脆弱点→结合攻击场景判定风险等级→制定风险处置措施→持续监控更新风险台账。

区别于 ISO26262 功能安全 HARA（危害分析与风险评估）聚焦人身伤害，TARA 聚焦网络安全层面损害，包含数据泄露、车辆操控篡改、系统停机、品牌声誉损失、合规处罚、用户隐私泄露六大类损害后果。

1.2 ISO/SAE 21434 对 TARA 的强制性要求

   标准第 8 章节 “网络安全风险评估” 明确规定：所有车载电子零部件、整车项目必须开展 TARA；TARA 需在概念阶段启动，随设计变更、软硬件迭代、攻击手段更新持续迭代；

高风险组件（车载网关、T-BOX、自动驾驶域、车载娱乐系统、电池管理系统）需单独开展专项 TARA；

TARA 形成完整文档作为认证、客户审厂、TISAX AL3 评估核心技术证据。

同时标准要求 TARA 需形成可追溯台账，包含资产清单、威胁场景、脆弱点、风险值、处置措施、验证记录，文档留存周期覆盖车辆全生命周期加 15 年。

1.3 TARA 与 HARA、FMEA 的协同关系

1. 与 HARA 协同：网络安全攻击可诱发功能安全危害（如远程劫持刹车系统），TARA 识别的高风险场景需同步传递至 HARA 补充危害场景；

2. 与 DFMEA/PFMEA 协同：硬件接口漏洞、软件逻辑缺陷、产线烧录漏洞同时纳入 TARA 脆弱点分析，实现安全一体化管控；

3. 与 TISAX 协同：TARA 输出的风险管控措施、数据分级、访问控制方案直接支撑 TISAX 原型保护、信息安全风险评估模块评审。

二、TARA 完整实施全流程（五大核心阶段）

标准规定 TARA 标准化闭环流程分为：

资产识别→威胁分析→脆弱点分析→风险评价定级→风险处置与持续迭代五大阶段，各阶段存在严格输入输出逻辑，不可颠倒、省略。

阶段一：资产识别（TARA 基础输入，8.2 条款）

资产识别是整个 TARA 工作的起点，核心目标是完整梳理系统内所有具备网络安全价值、遭受攻击后会产生损失的全部资产，杜绝资产遗漏导致风险盲区。ISO/SAE 21434 将车载资产划分为四大类别，需逐项建立《资产清单》。

1. 硬件资产：T-BOX、中央网关、车载 MCU、域控制器、摄像头、雷达、蓝牙 / 4G/5G 通信模块、存储芯片、诊断接口 OBD、加密芯片 HSM 等；

2. 软件资产：车载操作系统、固件、APP 应用、OTA 升级包、诊断软件、加密算法程序、云端交互接口程序；

3. 数据资产（核心管控对象）：车辆行驶数据、定位信息、用户人脸 / 声纹隐私数据、整车控制指令、加密密钥、维修诊断数据、整车原型图纸、软件源代码；

4. 通信与接口资产：车内 CAN/LIN/Ethernet 总线、车云通信、蓝牙、WiFi、USB 外设、远程诊断接口、产线烧录接口。

资产识别实施步骤

**步：划定 TARA 分析边界，明确分析对象（单零部件 / 整车 / 域控制器），区分内部组件、外部云端、第三方合作系统；第二步：依托系统架构图、硬件 BOM、软件架构、通信矩阵逐条梳理全部资产；第三步：对资产进行价值分级，划分高、中、低价值资产，高价值资产（密钥、整车控制程序、用户隐私数据）作为 TARA 重点分析对象；第四步：输出受控文件《资产识别清单》，标注资产存储位置、传输路径、使用主体、保护需求。

常见实施缺陷：仅梳理硬件忽略软件与数据资产、遗漏产线 / 售后诊断接口资产，造成后门攻击风险未识别，是 CNAS、TÜV 审核高频不符合项。

阶段二：威胁识别与场景构建（TARA 核心分析环节，8.3 条款）

威胁指外部攻击者、内部人员通过各类手段对资产发起的恶意行为，威胁识别需结合车载真实攻击链路，构建完整攻击场景，避免单一、片面的威胁描述。

2.1 威胁来源分类

1. 外部恶意攻击者：黑客、网络黑产、第三方恶意服务商，通过车云网络、无线通信远程攻击；

2. 内部风险人员：研发工程师、产线操作工、售后维修人员、外包服务商，存在误操作、数据窃取、固件篡改风险；

3. 供应链风险：芯片供应商、软件外包商、代工厂植入后门、泄露加密密钥；

4. 环境间接威胁：无线信号劫持、中间人攻击、OTA 升级包劫持篡改。

2.2 车载典型威胁类型（ISO/SAE 21434 推荐威胁库）

• 窃取：窃取用户隐私、整车数据、加密密钥、源代码、原型资料；

• 篡改：篡改控制指令、OTA 固件、标定参数、定位数据；

• 拒绝服务 DoS：总线泛洪、通信阻塞，导致车辆动力、制动、转向失效；

• 伪造：伪造诊断报文、云端指令、身份凭证；

• 重放攻击：截取合法报文重复发送，控制车辆执行危险动作；

• 泄露：未加密传输、无权限访问导致数据外泄；

• 抵赖：操作行为无日志审计，无法追溯攻击源头。

2.3 威胁场景标准化构建方法

采用 “攻击者 + 攻击路径 + 目标资产 + 攻击行为” 四段式构建场景，示例：外部黑客通过 5G 车云接口（攻击路径），伪造云端指令（攻击行为）篡改自动驾驶域控制器控制程序（目标资产）。所有场景统一录入《威胁场景清单》，每个资产至少匹配 2 条以上潜在威胁场景，高价值资产需覆盖全部 8 类典型威胁。

阶段三：脆弱点分析（漏洞挖掘，风险发生前提）

脆弱点（漏洞）是系统自身存在的缺陷，是攻击者能够实施威胁的必要条件。若无脆弱点，威胁无法落地形成实际风险。本阶段结合硬件设计、软件代码、通信协议、管理制度、人员权限全维度排查漏洞。

3.1 脆弱点四大分类

1. 技术脆弱点：软件代码漏洞、未加密总线传输、无身份认证接口、弱加密算法、密钥明文存储、无日志审计；

2. 硬件脆弱点：调试接口未锁死、芯片无安全启动、存储芯片可直接读取、无硬件加密模块；

3. 流程脆弱点：OTA 升级无校验、产线密钥统一固化、售后诊断无权限分级、外包代码无安全审查；

4. 管理脆弱点：人员权限未定期回收、原型图纸无保密管控、供应商无网络安全约束、无信息安全培训。

3.2 脆弱点分析实施手段

1. 静态分析：软件代码审计、硬件原理图安全审查、通信矩阵漏洞排查；

2. 动态测试：渗透测试、总线模拟攻击、OTA 劫持测试、接口漏洞扫描；

3. 管理文件评审：供应商协议、权限管理制度、保密制度评审；

4. 对标行业漏洞库：车联网漏洞库、CVE 车载漏洞、主机厂历史安全事故复盘。

输出《脆弱点分析台账》，将每一条脆弱点与对应威胁场景一一关联，建立追溯关系。

阶段四：风险评价与等级定级（量化判定，8.4 条款）

风险 = 攻击发生可能性 × 网络安全损害严重程度，ISO/SAE 21434 要求采用二维矩阵法完成风险量化定级，统一划分为高、中、低三级风险，部分企业增加 “极高风险” 专项管控等级。

4.1 两大评价维度判定准则

1. 发生可能性（L）：分为高、中、低三档高：攻击手段公开、攻击成本低、接口暴露在外网，极易被利用；中：需专业设备与技术，存在有限攻击渠道；低：攻击条件苛刻，物理接触车辆内部硬件才可实施。

2. 损害严重度（S）：基于网络安全损失判定，不直接等同于功能安全伤害极高：车辆失控引发重大人身伤亡、大规模用户隐私批量泄露、企业巨额合规罚款；高：单台车辆操控异常、核心加密密钥泄露、整车源代码外泄；中：非核心数据泄露、车载娱乐系统瘫痪、局部功能失效；低：少量无关数据展示异常，无实质性损失。

4.2 风险矩阵判定规则

• 高可能性 + 极高 / 高严重度 = 极高 / 高风险；

• 中可能性 + 高严重度 / 高可能性 + 中严重度 = 中风险；

• 低可能性 + 低 / 中严重度 = 低风险。

4.3 风险评价输出文件

《TARA 风险评价汇总表》，每条记录包含：资产编号、威胁场景、脆弱点、可能性、严重度、综合风险等级，所有高 / 极高风险项标记红色预警，作为项目优先整改项。标准明确要求：高风险不可直接接受，必须落实专项管控措施降低风险。

阶段五：风险处置、验证与持续迭代（闭环管控，8.5/8.6 条款）

TARA 不是一次性静态活动，风险处置、有效性验证、全生命周期迭代是实现风险闭环管控的关键，也是审核重点核查内容。

5.1 四种标准化风险处置策略（ISO/SAE 21434 规定）

1. 风险消除：从设计层面彻底移除脆弱点或攻击面，**处置方案。例：取消外部可访问的调试接口、删除存在漏洞的冗余通信协议；

2. 风险降低：通过安全措施削减可能性或严重程度，车载项目最常用手段。包含加密传输、身份认证、安全启动、访问权限分级、日志审计、防火墙、数据脱敏、原型保护区物理隔离；

3. 风险转移：通过合同、保险、供应商责任划分转移风险。例：在零部件供应商协议中约定网络安全赔偿条款、购买车辆网络安全责任险；

4. 风险接受：仅适用于低风险项，需**管理者书面审批，留存风险接受说明，明确无需额外管控的理由。中、高风险严禁直接风险接受。

针对每一条高、中风险项，制定《风险处置方案》，明确整改措施、责任部门、完成期限、验证方法。

5.2 处置措施有效性验证

整改完成后必须开展验证，确认脆弱点已被消除或风险显著下降，验证方式包含：

1. 复测：渗透测试、总线攻击复测、代码二次审计；

2. 文件评审：核对安全制度、软硬件设计变更文档；

3. 场景模拟：复现原有攻击场景，确认攻击无法达成；验证记录附入 TARA 档案，无验证记录视为 TARA 工作未闭环。

5.3 全生命周期持续迭代更新

标准强制要求触发 TARA 复评的变更条件：

1. 软硬件架构重大变更、接口新增 / 删减；

2. OTA 版本迭代、固件升级；

3. 新增无线通信、云端交互功能；

4. 行业出现新型车载攻击手段、重大车辆网络安全事故；

5. 客户（主机厂）提出新的网络安全要求、TISAX 标准更新；

6. 年度整车网络安全管理评审。复评后更新全套 TARA 台账，形成版本变更记录，保证风险管控与产品同步更新。

三、TARA 文档体系与审核落地要点

一套完整合规的 TARA 技术档案包含 6 份受控文件，全部可作为 ISO/SAE 21434、客户二方审核证据：

1. TARA 实施计划（明确分析范围、人员、周期、工具）；

2. 资产识别清单；

3. 威胁场景分析清单；

4. 脆弱点漏洞台账；

5. 风险评价矩阵与分级汇总表；

6. 风险处置方案、验证报告、风险接受审批单、版本迭代变更记录。

审核高频缺陷总结：资产识别不全、威胁场景单一、无量化风险矩阵、高风险直接接受、无整改验证记录、产品变更后未复评 TARA，企业落地时需重点规避。

四、TARA 与车载行业合规价值总结

1. 标准合规：满足 ISO/SAE 21434 强制开发流程，顺利通过第三方网络安全认证；

2. 客户准入：德系、欧美主机厂强制要求供应商提供完整 TARA 报告，是供货准入门槛；

3. ISO24134 取证支撑：TARA 输出的风险管控、数据分级、访问控制方案是 ISO24134 评估核心技术材料；

4. 风险前置防控：在研发阶段识别网络安全漏洞，避免量产后期整改带来巨额改造成本；

5. 事故责任界定：完整 TARA 档案可证明企业已履行网络安全设计管控义务，降低安全事故后的处罚与赔偿风险。

结语

        TARA 作为 ISO/SAE 21434 车载网络安全的核心风险分析工具，形成 “资产识别 — 威胁挖掘 — 漏洞分析 — 风险定级 — 处置验证 — 持续迭代” 完整闭环流程，贯穿智能网联汽车全生命周期。企业在落地过程中需杜绝简化流程、仅做纸面文件的形式化工作，结合渗透测试、代码审计、整车攻击模拟实现真实风险挖掘，同步联动功能安全 HARA、质量 FMEA、TISAX 信息安全体系，实现整车多维度安全一体化管控。随着车载网络安全法规日趋严格，标准化、可追溯、动态更新的 TARA 体系将成为车载零部件企业核心竞争力与合规底线。