前言
随着汽车智能化、网联化的深度发展，车辆电子电气架构从分布式向域控化、中央计算架构演进，车辆对外连接接口（5G、WiFi、蓝牙等）持续增多，网络攻击面呈指数级扩大。网络安全已从车辆的增值功能，转变为关乎人身安全、合规准入、品牌口碑的核心底线。
在汽车网络安全工程体系中，TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估） 是整个体系的核心基石，是 ISO/SAE 2143要求的核心方法论，也是车企实现网络安全主动防御、满足合规准入的必备工作。
本文将从零开始拆解 TARA 分析的全流程，用通俗的语言、可落地的步骤，让新手也能完整掌握 TARA 分析的核心逻辑与实操方法，同时规避行业常见误区。
一、TARA 分析到底是什么？
核心定义
TARA 分析是汽车行业通用的、标准化的网络安全方法论，核心是通过系统化的流程，识别车辆面临的网络安全风险，拆解攻击路径，量化评估风险等级，最终输出可落地的风险处置措施，实现网络安全风险的全生命周期可控。
简单类比：TARA 分析就像给车辆做一次全面的 “网络安全防盗体检”—— 先找到车里要保护的、资产，再找到所有可能被小偷突破的门窗、下水道（攻击面），评估小偷作案得手后的危害（损害场景），然后推演小偷可能的入室路径和作案手段（威胁场景与攻击路径），最终给门窗装锁、加监控、设报警（风险处置）。
二、为什么必须做 TARA 分析？
全球合规强制准入要求
这是车企开展 TARA 分析的核心刚性约束。
•国际合规要求： UNECE R155 法规：作为全球首个车辆网络安全强制法规，其要求车企建立 CSMS 网络安全管理体系、完成车辆网络安全型式认证。法规条文未直接指定 TARA 术语，但强制要求开展威胁识别、风险评估与风险处置；在全球整车准入审核中，依据 ISO/SAE 21434 标准开展的 TARA 分析，是监管及认证机构统一认可的合规手段，也是产品进入欧盟及相关协定市场的关键技术材料。
•国内合规要求：GB 44495-2024《道路车辆 网络安全工程》强制性要求车辆全生命周期开展网络安全威胁识别、风险分析与风险处置活动。TARA 作为标准规定的标准化风险分析方法，是落实国标安全管控条款、完成车型准入审查、通过合规审核的必要技术文件与核心佐证材料。
车辆安全的本质需求
智能网联汽车的核心行驶功能（制动、转向、动力）已与网联系统深度打通，一旦被黑客攻击，将直接导致车辆失控、人员伤亡。TARA 分析是从产品设计源头识别风险，而非事后补救，是避免车辆出现恶性网络安全事件的核心手段。
研发与运营的成本控制
行业实践表明：在产品前期阶段提前识别并整改网络安全风险，成本远低于量产后期补救。TARA 分析可实现风险前置管控，有效规避量产召回、高额处罚、品牌口碑受损等重大损失，是车企优化成本、降本控险的关键手段。
供应链安全的责任划分
当前汽车供应链高度复杂，一辆车的 ECU、软件模块来自数十家甚至上百家供应商。TARA 分析可以明确整车级、系统级、组件级的安全需求，清晰划分车企与供应商的网络安全责任边界，避免出现安全事件后责任推诿的问题。
三、TARA 分析在网络安全项目中的执行节点
TARA 分析不是一次性的纸面工作，而是贯穿车辆全生命周期的持续性工作，对应 ISO/SAE 21434 的全生命周期阶段，核心执行节点如下：
概念阶段：首次核心开展
概念阶段是网络安全风险管控的关键前置节点。需依托整车及电子电气架构方案，针对智能驾驶、车联网、动力底盘等关键域，开展整车级首轮 TARA 威胁风险分析，同步制定网络安全目标与顶层安全需求，为后续架构设计、方案选型划定安全基线。若前期缺失该环节，易导致设计方案存在原生安全短板，后期整改难度大、成本激增。
产品开发阶段：迭代细化
在系统、硬件、软件开发阶段，针对具体的域控制器、ECU、软件模块、通信接口，开展组件级、细化版的 TARA 分析，将整车级安全需求分解到每一个硬件、软件组件，验证设计方案是否满足安全需求，同步优化防护措施。
生产与运维阶段：持续更新
生产阶段：针对生产过程中的调试接口、烧录流程、密钥管理等场景，开展专项 TARA 分析，避免生产环节引入安全风险；
运维阶段：车辆量产后，每一次 OTA 功能升级、新增对外接口、行业出现新的漏洞 / 攻击手段、野外发现安全事件，都必须重新开展 TARA 分析，更新风险处置措施，确保车辆全生命周期的风险可控。
变更阶段：变更触发
任何涉及车辆 E/E 架构、通信接口、软件功能、对外连接、数据处理的变更，都必须开展变更影响性 TARA 分析，评估变更是否引入新的攻击面和风险，只有风险可控的变更才可落地。
四、TARA 分析的完整实操步骤（行业通用标准流程）
TARA 分析的核心逻辑可总结为 8 个标准化步骤，完全符合 ISO/SAE 21434 标准要求。
步骤 1：定义分析对象、边界与相关项定义
这是 TARA 分析的基础，核心是明确分析范围与基线，避免分析盲区或范围失控。
- 明确分析对象
可根据项目需求选择整车、智能驾驶域、车联网域、动力底盘域、域控制器、单个 ECU、软件模块、OTA、数字钥匙、远程控制等相关项。
- 明确相关项边界
界定功能范围、对外通信接口、车内交互关系、数据流向、协议类型、云端交互、车联网 APP 交互、维修诊断链路及供应链责任边界。
- 明确操作环境与假设条件
包括车内网络架构、外部依赖环境、交互系统假设及合规适用范围。
步骤 2：资产识别与损害场景识别
资产是网络安全防护的核心保护对象，是开展 TARA 分析的前置基础。需完成数据流图绘制、资产识别、网络安全属性判定、损害场景推导四位一体分析。
- 绘制数据流图
基于系统架构、功能逻辑、通信链路与数据流转过程，完整描述相关项的数据输入、处理、传输、存储与外部交互，覆盖所有组件、接口、协议与依赖环境。 - 资产识别
全面梳理整车 / 系统 / 组件级关键资产，程序 / 应用、数据流、存储数据、软件组件等。
- 信息安全属性判定
明确每类资产的核心保护属性：机密性、完整性、可用性、真实性、可授权性、不可抵赖性、时效性。
- 损害场景识别
分析资产安全属性被破坏后，可能对道路使用者、车辆、驾乘人员、企业造成的负面后果，包括人身伤害、功能失效、隐私泄露、经济损失等。
步骤 3：影响等级评估（S/F/O/P 四维评估）
这一步核心是回答攻击成功后危害有多大，从四大维度开展影响评估：
- 安全影响（S） ：是否造成人身伤亡、车辆失控、道路安全风险；
- 财务影响（F） ：经济损失、召回成本、维修成本、企业财产损失；
- 操作影响（O） ：车辆核心 / 重要功能丧失、异常、降级、不可用；
- 隐私影响（P） ：个人信息泄露、滥用、未经授权访问与追踪。
影响等级划分为：严重、中的、中等、可忽略。
步骤 4：攻击面梳理与威胁场景识别
这一步核心是回答攻击者从哪里进入、以何种方式实施攻击，实现威胁识别全覆盖、无遗漏。
攻击面全覆盖梳理
- 远程无接触攻击面：5G/4G 通信接口、OTA 云端接口、车联网 APP、WiFi、蓝牙、NFC、V2X、云端服务接口；
- 本地物理攻击面：OBD 诊断接口、USB/SD 接口、硬件调试口、JTAG、维修刷写接口；
- 车内内部攻击面：CAN/CAN-FD/LIN 总线、车载以太网、域间通信链路、ECU 内部交互接口。
- 威胁场景识别（STRIDE 模型，行业通用）
采用 STRIDE 威胁模型开展标准化威胁识别，覆盖汽车网络安全绝大多数威胁类型：
| 缩写 | 威胁类型 | 中文释义 | 汽车行业典型示例 |
|---|---|---|---|
| S | Spoofing | 仿冒 | 伪造合法 ECU 接入总线、仿冒用户登录车联网 APP、伪造 OTA 升级包 |
| T | Tampering | 篡改 | 篡改底盘控制信号、篡改固件 / 配置、篡改行车数据 / 日志 |
| R | Repudiation | 抵赖 | 删除攻击日志、销毁审计痕迹、导致安全事件无法追溯 |
| I | Information Disclosure | 信息泄露 | 泄露行车轨迹、人脸 / 指纹信息、车辆密钥、固件源码、诊断数据 |
| D | Denial of Service | 拒绝服务 | 总线拥塞、功能宕机、ECU 重启、车辆失去控制能力 |
| E | Elevation of Privilege | 权限提升 | 从娱乐系统突破获取底盘控制权、普通权限提升管理员权限 |
步骤 5：攻击路径识别与分析
针对每一个威胁场景，完整拆解攻击者从入口到目标资产的整条攻击链，要求无断点、无跳跃、可复现、可验证。
可采用自上而下（攻击树 / 攻击图）或自下而上（由漏洞反推）的方法开展分析。
步骤 6：攻击可行性评级（基于攻击潜力）
攻击潜力由 5 项核心要素 综合判定：
- 操作时间：识别漏洞、开发攻击代码、成功实施攻击所需时长；
- 专业知识：攻击者所需技术水平（外行 / 熟练人员 / 专家 / 多领域专家）；
- 对相关项 / 组件的了解程度（公开信息 / 受限信息 / 机密信息 / 严格保密信息）；
- 机会窗口：攻击可达性与访问条件（远程无限制 / 邻近 / 本地 / 物理接触）；
- 设备 / 工具：所需工具类型（标准设备 / 专业设备 / 定制设备 / 多套定制设备）。
各项评分累加后，映射为攻击可行性等级：高 / 中 / 低 / 非常低。
步骤 7：风险等级判定与优先级排序
将攻击可行性与影响等级带入风险矩阵，量化计算最终风险值与风险等级，是行业通用、合规可审的判定方法。
风险优先级：极高风险 (5) ＞ 高风险 (4) ＞ 中风险 (3) ＞ 低风险 (2) ＞ 可接受 (1)
步骤 8：风险处置措施制定与验证
这是 TARA 分析的最终落脚点，核心是把风险变成可落地的安全措施。标准允许 4 种法定风险处置策略：
风险规避
从根源消除风险，移除风险源或关闭攻击面。
示例：禁用非必要远程控制功能。
风险降低（行业最常用）
通过安全控制降低攻击可行性或影响程度。
示例：OTA 加密验签、CAN 总线身份认证、安全启动、防火墙、入侵检测 IDS、数据加密。
风险分担
将风险责任与损失转移给第三方。
示例：网络安全保险、供应商安全责任合同、第三方安全运营。
风险保留
仅适用于低风险；必须书面审批、定期复审；极高 / 高风险严禁直接保留。
示例：极低影响、极难实施、处置成本远高于风险损失。
强制性要求：所有措施必须转化为可测试、可验证、可量化的安全需求，禁止模糊表述。
步骤 9：文档记录与全生命周期迭代
TARA 不是一次性活动，而是贯穿车辆全生命周期的持续迭代活动。
完整文档归档
输出《TARA 分析报告》 ，作为准入认证、型式批准、CSMS 体系审核的核心交付物，必须包含：分析范围、资产、攻击面、威胁场景、攻击路径、可行性、影响、风险矩阵、处置措施、审批记录。
持续更新触发条件
架构变更、功能新增、组件复用、新漏洞发布、新威胁情报、法规更新、量产运维阶段均需重新迭代。
全生命周期覆盖
概念阶段 → 产品开发 → 生产制造 → 运营维护 → 报废停用。
五、TARA 分析常见问题与解答（FAQ）
1.TARA 分析必须车企自己做吗？供应商做的可以用吗？
整车级 TARA 分析必须由车企作为主体负责，因为车企是车辆产品的最终合规与安全责任方。供应商必须提供其供货组件（ECU、域控、软件）的组件级 TARA 分析报告，车企需将其整合到整车级 TARA 中，验证其是否满足整车安全需求，不可直接照搬使用。车企对整车网络安全负最终责任，供应商对其供货组件的安全负责。
2.TARA 分析的粒度越细越好吗？
不是。TARA 分析的粒度需与分析对象的层级匹配，核心原则是既不分析不足，也不过度分析：
整车级 TARA：粒度到系统 / 域级即可，无需细化到 ECU 寄存器；
域控 / ECU 级 TARA：粒度到硬件模块、软件组件级即可；
软件模块级 TARA：可细化到具体接口、代码逻辑。
若在整车级过度细化到代码层面，会导致工作量爆炸，完全无法落地；若在 ECU 级仅分析到系统层面，会导致风险识别不全。
3. 车辆已经量产了，之前没做过 TARA，现在补做还有用吗？
有用。车辆量产运维阶段，仍需满足 ISO/SAE 21434 与 R155 法规的持续风险评估要求。补做时，需先完成整车级 TARA 分析，识别现有车辆的核心高风险，优先通过 OTA 升级、线下整改等方式处置高风险问题；后续所有车辆功能变更、OTA 升级，都必须提前开展 TARA 分析，避免事后补做。
4. 攻击可行性和影响等级打分，我和同事的结果不一样怎么办？
ISO/SAE 21434 标准仅规定了评估维度，未制定统一的打分阈值，因此车企必须提前制定企业内部统一的《TARA 分析规范》 ，明确每个维度的打分标准、等级定义、风险矩阵判定规则，所有分析人员必须严格按照规范执行，保证评估一致性。若出现分歧，以规范定义为准，或由企业网络安全负责人最终裁定。
5. TARA 分析识别的风险，必须全部消除吗？
不是。网络安全没有绝对的安全，只有相对的风险可控。
极高 / 高风险：严禁直接接受，必须采取处置措施，将风险降低到企业可接受等级；
中低风险：可根据处置成本、风险收益，选择风险降低、转移或接受；
风险接受：必须经过严格的书面审批流程，留存完整记录，且每半年至一年重新评估，确认风险仍处于可接受范围。
七、总结
TARA 分析不是车企为了应付合规审核的纸面工作，而是汽车网络安全从被动补救到主动防御的核心基石。随着汽车智能化程度的持续提升，车辆的网络攻击面将持续扩大，TARA 分析的价值也将愈发凸显。
对于车企而言，只有建立完善的 TARA 分析流程，培养专业的分析团队，将 TARA 分析真正落地到车辆全生命周期的每一个环节，而非停留在文档层面，才能真正守住车辆网络安全的底线，保障用户的人身与财产安全，同时满足全球市场的合规准入要求。
以上为本次技术分享，后续相关专题文章将持续更新，欢迎关注交流。
