UN R155认证视角下的TARA实践

白帽100安全攻防实验室 · 2025-12-29 19:08 · 3 阅读

原创 novy 2025-12-29 19:08 浙江

在本文中我将重点探讨TARA的方法论与实施思路，以期为相关团队提供参考

在方法论开始之前，请先允许我介绍一下TARA和TARA的作用

TARA是什么

目前（截至编写文章时间-2025年底）R155法规已被包括欧盟所有成员国、日本、韩国、英国、澳大利亚、南非等在内等超过60多个国家采纳，对OEM而言，自2022年7月起，欧盟成员国内对所有现有架构新车型进行强制实施R155，所有适用的新车型出口欧洲均需通过Vehicle Type Approval（车辆型式认证，简称VTA），自2024年7月开始所有架构所有车型都需通过认证

OEM要有效执行UN R155的合规要求，首先需要建立全面的网络安全管理体系，即Cybersecurity Management System (CSMS)，以确保汽车全生命周期中都有对应的流程措施用以控制相关风险，在这诸多要求中，威胁分析与风险评估（Threat Analysis and Risk Assessment，简称TARA）是贯穿始终的核心方法，要求从攻击者视角系统识别威胁场景、评估风险水平，并制定针对性的缓解措施，基于多年参与VTA认证项目的实践经验，在本文中我将重点探讨TARA的方法论与实施思路，以期为相关团队提供参考

TARA在UN R155中的定位和要求

UN R155法规的核心目标是要求OEM建立并运行有效的网络安全管理体系（CSMS），以确保车辆在全生命周期内抵御网络攻击风险，作为CSMS的关键组成部分，威胁分析与风险评估（TARA）被视为实现这一目标的最基础工具，虽然法规正文没有直接使用“TARA”这个术语，但其对风险识别、评估和管理的要求（第7条及Annex 5）本质上指向了TARA方法，TARA在UN R155中的定位和要求主要体现在以下几个方面：

风险识别和评估的核心手段

法规7.3.3至7.3.6要求OEM系统识别车辆网络安全风险、评估风险水平并确定、验证缓解措施，TARA正是满足这些要求的具体方法，其要求OEM从攻击者视角分析潜在威胁，并覆盖车辆所有相关组件（包括供应链零部件），Annex 5提供的67个典型威胁场景作为参考基准，OEM需要证明已评估这些场景（如果不适用，说明不适用理由）

贯穿车辆全生命周期

TARA并非一次性活动，而是贯穿CSMS全过程的要求：在概念阶段进行初步风险评估、在开发阶段细化并迭代、在生产和运营阶段持续监控新出现的威胁并复审、在车辆退役阶段评估残余风险，法规明确要求OEM在CSMS中建立持续监控和残余风险管理过程（详见GRVA的解释文档7.2.2.2 (f)(g)，这个文档对UN R155 CSMS审核的目的、依据和细节做了很详细的说明），确保风险评估结果保持最新，当出现新漏洞、新攻击技术或车辆配置变更等情况时，需重新评估残余风险的可接受性，并采取必要措施

VTA的关键证据

在车辆型式认证阶段，认证机构会重点审查OEM提交的风险评估结果及其衍生材料（包括威胁列表、风险值、安全目标等等），TARA报告是CSMS审计和VTA的核心证据之一，如果风险评估不完整或缺乏可追溯性，将直接导致认证失败

与UN R156的关联

软件更新过程是高风险攻击面（Annex 5中有多条相关威胁场景），TARA需特别评估OTA更新风险（如更新包篡改、伪造服务器、传输劫持），其结果直接输入SUMS设计，确保更新过程的安全性和可追溯性

供应链延伸要求

UN R155明确规定车辆网络安全的最终责任由OEM承担，即使风险来源于供应商提供的零部件，认证机构追究责任的时候也是首先找的OEM，也就是说OEM在进行整车级TARA的时候必须要将供应商零部件的风险评估结果纳入其中，确保整车风险分析的完整性，为了实现这一要求，在进行整车TARA分析前期阶段，供应商要向OEM提供必要的TARA相关工作输入

总的来说，TARA在UN R155中不仅是技术方法，更是合规证据链的核心环节，其输出直接决定后续网络安全需求的完整性和有效性，实践经验表明，认证审核中最常见的驳回原因往往源于TARA的深度不足（比如损害场景没有跟功能安全关联、威胁场景覆盖不全、攻击可行性评估过于乐观、风险处理决策缺乏依据等等）

TARA方法论

在开展工作前，OEM必须准备好以下材料：

EE架构图，需体现ECU之间的通信链路设计方案（通信方式、通信协议、外部接口），架构图需要通过网络安全评审
整车功能清单，内容包括：功能定义、功能详细描述、每一个功能关联到的ECU 、功能的数据流
零部件清单及详细信息，包括简称和全称，零部件的配置详情（外部接口、是否包含诊断、诊断服务信息、是否包含刷写、刷写方式信息、PCB主板正反面图等）、零部件供应商名称、负责人及联系方式、功能简述、详述、架构等等
…

TARA开展

法规未强制指定风险评估的具体方法，但要求过程必须系统、可追溯，并覆盖所有潜在威胁，在认证实践中，ISO/SAE 21434标准定义的TARA方法已成为行业事实标准，该标准将TARA分解为资产识别、威胁场景识别、影响评级、攻击路径分析、攻击可行性评级、风险确定、风险处理决策七个步骤，形成一个闭环、可迭代的风险管理流程，在本文中，我也主要以21434中的方法介绍

一、资产识别（Asset identification）

根据判定结果，明确Item中可能被利用造成网络安全风险、需要保护的资产，包括物理组件、数据、功能等，并标注其安全属性（保密性、完整性、可用性、授权、不可抵赖性、真实性 - 21434里的3.1.20，除了有必不可少的属性，同时还对应后面说到的STRIDE模型）

为了完整识别资产，避免遗漏，我们可采用以下单一方法或结合使用（RQ-15-02 NOTE 2）：

分析Item定义
从已确定的Item边界、功能描述、初步架构和假设出发，直接提取资产
进行影响评级
通过损害场景反向推导需要保护的资产
从威胁场景中提取资产
基于已识别的威胁场景，追溯涉及的关键资产
使用预定义目录
使用预设资产分类模板（比如外部实体/硬件、功能单元、数据流、数据存储），按类别逐一列出

整车级TARA需识别整车层面资产（包括集成交互），零部件级TARA只关注组件内部及暴露接口资产

示例：

推荐预定义资产类型的方式，更快更方便，识别更完整：

整车TARA：除了架构图上的网络安全相关组件外，还有车辆对外暴露的USB接口（外部接口）、WIFI（功能单元）、无线射频（功能单元）、OTA（功能单元）等，还有在OTA更新功能中，资产可能包括：固件镜像文件（数据存储）、车机日志（数据存储）、OTA通道（数据流）、零部件间的通信（数据流）、IVI里的系统（功能单元）等
零部件TARA：调试接口（外部实体）、芯片（外部实体）、芯片间的通信（数据流）、芯片里的数据（数据存储）、芯片里的功能模组（功能单元）等

识别后的资产清单输出物示例：

TARA输出示例：

二、威胁场景识别（Threat scenario identification）

威胁场景识别是TARA的核心步骤之一，在实践中，一般使用STRIDE模型辅助分类（Spoofing欺骗、Tampering篡改、Repudiation不可否认、Information Disclosure信息泄露、Denial of Service拒绝服务、Elevation of Privilege权限提升），从分类中分析威胁场景

分析威胁场景目的是识别可能导致资产网络安全属性被违反（受到损害）的具体攻击方式，每个威胁场景必须包括以下核心要素（RQ-15-03）：

目标资产：
被攻击的资产
资产的网络安全属性受损：
哪个属性（保密性、完整性、可用性）被破坏
网络安全属性受损的原因：
攻击者是怎么做到的

示例：

针对特定资产，使用STRIDE模型识别，注意要包含上面提到的核心要素：

Tampering
攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性遭到破坏
Spoofing
攻击者伪造【ECU1】与服务器的身份验证，导致【ECU1】通信身份验证机制的真实性遭到破坏
Denial of Service
攻击者干扰【ECU1】的CAN通信，导致【ECU1】通信通道的可用性被破坏

注意：UN R155 附录5列出了67个参考威胁场景作为法规基准，OEM必须逐一评估这些场景的适用性（适用就分析，不适用需要提供技术理由）

零部件级TARA主要识别组件内部威胁场景（包括内部数据流、存储、功能及暴露接口的威胁），可以考虑外部接口（如CAN、Ethernet等）被直接攻击的风险，但不需要负责这些接口在整车集成后与其他组件交互产生的新威胁（这些属于整车级责任）

整车级TARA需额外考虑集成引入的新场景，例如：

从娱乐域（IVI）穿越到动力域的攻击
网关路由规则漏洞导致的域隔离失效
多个ECU协同形成的攻击链（单个ECU看来正常，组合后产生高风险）

这样能确保风险覆盖完整，而且还符合OEM对整车网络安全的最终责任要求，TARA输出示例：

三、影响评级（Impact rating）

影响评级用于评估威胁场景实现后可能造成的潜在损害，即通过损害场景分析量化后果严重程度，该步骤的核心输出是每个威胁场景在Safety（安全）、Financial（财务）、Operational（操作）、Privacy（隐私）四个维度上的独立评级（RQ-15-04 SFOP框架，SFOP是对同一损害场景从不同视角进行的严重度评估，而非产生多个独立损害场景），评级等级通常为Negligible（可忽略不计）、Moderate（中等）、Major（主要）、Severe（严重）

损害场景是指威胁场景成功后，对车辆、用户或相关方造成的技术层面直接不良后果（例如“刹车系统失效”“车辆关键功能瘫痪”），21434建议损害场景包含以下要素（RQ-15-01 NOTE 1）：

Item功能与不良后果之间的关系
对道路使用者的伤害描述
相关资产

示例：威胁场景“攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性遭到破坏”，该威胁场景的损害场景是：“篡改后的更新包被【ECU1】刷写，造成【ECU1】执行恶意或错误逻辑，导致刹车控制功能失效，车辆在行驶中无法正常制动，对道路使用者构成重伤或死亡风险”，对应的SFOP评级（对该损害场景的多维度评估）：

Safety = Severe
（可能造成人员重伤或死亡）
Financial = Major
（医疗费用、维修或替代交通成本显著增加）
Operational = Major
（车辆关键功能瘫痪）
Privacy = Negligible
（无直接隐私数据泄露）

如果损害场景对某个维度的影响足够严重，则可优先聚焦该维度，其他维度作为辅助参考，比如上面的例子，综合影响评级为“Severe”，也就是取最高值（PM-15-07）

注意：整车级影响往往高于零部件级：同一威胁在零部件级可能仅影响局部功能（Operational=Moderate），但在整车集成后可能放大为安全风险（Safety=Severe），所以评级时需要有依据需提供评级准则（CFG，参考21434附录F）和会议纪要（功能安全评估，功能或零部件受到损害时，会不会影响车辆行驶）作为证据

通过详细的损害场景分析和多维度评级，能为后续风险确定提供客观基础，确保高严重度风险得到优先缓解，而且在实践中，可以采用两种分析方向（从损害场景倒推威胁场景、从威胁场景正向扩展损害场景）结合的迭代方式，既能快速聚焦高风险，又能确保覆盖全面，避免单纯依赖经验导致遗漏其他场景

示例：

正向分析（从威胁场景扩展损害场景）

从已知的威胁场景出发，正向推导其成功后可能造成的损害后果：

威胁场景
攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性遭到破坏。
扩展损害场景
篡改后的更新包被【ECU1】刷写，造成【ECU1】执行恶意或错误逻辑，导致刹车控制功能失效，车辆在行驶中无法正常制动，对道路使用者构成重伤或死亡风险

倒推分析（从损害场景倒推威胁场景）

从损害场景出发，倒推可能导致该损害的威胁场景：

损害场景：
篡改后的更新包被【ECU1】刷写，造成【ECU1】执行恶意或错误逻辑，导致刹车控制功能失效，车辆在行驶中无法正常制动，对道路使用者构成重伤或死亡风险
o 威胁场景1：攻击者篡改车辆接收到的【ECU1】更新包，导致【ECU1】更新包的完整性被破坏
o 威胁场景2：攻击者伪造合法更新服务器身份，使【ECU1】接受来源不可信的更新包，导致【ECU1】的真实性被破坏
o …

需要说明的是，每项资产可能有多个网络安全属性，每个属性可能对应一个或多个损害场景，每个损害场景可能对应多个威胁场景，每个威胁场景也可能导致多个损害场景（RQ-15-03 NOTE 3）

TARA输出示例：

四、攻击路径分析（Attack path analysis）

攻击路径分析的目的是详细描述威胁场景如何被实现，包括攻击入口、具体步骤、所需条件以及现有缓解措施，该步骤帮助评估攻击的可行性，并为后续风险确定和安全需求制定提供依据，在实践中，该步骤在21434中给出了2个建议（RQ-15-08 NOTE 1），可根据产品阶段进行单独或结合使用（RQ-15-09 NOTE 3）：

自顶向下方法（top-down），从威胁场景作为起点“顶”，层层分解可能的攻击路径，直到基本攻击步骤，比如，对于威胁场景“篡改OTA更新包”，我们可以从这个顶点出发分解：

要实现这个威胁，攻击者必须做到拦截通信（MITM）或者供应链注入
拦截通信时可能需要伪造证书或劫持DNS
每一步再继续向下，直到不可再分的叶节点，这种方式常用攻击树来表达：根节点是威胁场景，子节点是子目标，使用AND/OR逻辑连接（AND表示所有子路径必须成功，OR表示任一即可）

由此得知当前树中有1条完整攻击路径（为方便解释，在不考虑continue的情况下）：

路径01
MITM拦截并替换包 + 绕过签名验证（利用签名算法漏洞）

o 下载篡改包方式：MITM（连接车辆网络 → 执行流量劫持 → 替换下载包内容）

o 接受刷写方式：利用签名算法漏洞（已到叶节点）

最终攻击路径描述：攻击者通过连接车辆网络、执行流量劫持并替换下载包内容，让车辆下载篡改后的更新包，同时利用签名算法漏洞绕过验证，使车辆接受并刷写篡改固件

在分析过程中，如果某个路径中的关键环节无法实现（比如需要物理访问但车辆环境受控），或者该环节对整体威胁场景没有实质影响，就可以终止对这一分支的后续分析（RQ-15-08 NOTE 2），避免没必要的深度分析，这种剪枝（pruning）是各类基于树模型分析的常见优化技巧

另外，一个威胁场景通常对应多个攻击路径，比如“篡改OTA更新包”可能有：

路径1：远程MITM拦截通信
路径2：供应链攻击预装恶意固件
路径3：物理访问刷写

自底向上方法（bottom-up），从已知漏洞、弱点或基本攻击步骤出发，向上追溯它可能导致哪些威胁场景，最终评估潜在损害和风险，这种方法特别适合团队已通过渗透测试、代码审计或漏洞扫描获得具体弱点时，这里的“底”是已知的具体漏洞或弱点（而不是抽象的威胁场景），例如：

ECU固件存在缓冲区溢出漏洞
诊断服务未实现安全访问机制
OTA通信未启用TLS加密
网关规则配置错误

例如：假设通过代码审计发现“某个ECU的诊断服务存在缓冲区溢出漏洞”自底向上拆解：

这个漏洞能被利用来做什么？ → 注入任意代码或消息（基本攻击步骤）
注入任意代码能导致什么威胁场景？ → 伪造诊断消息刷写固件（Spoofing + Tampering）
这些威胁场景成功后造成什么损害？ → 刹车系统失效（Safety = Severe）

攻击树表现形式：树是倒着长的，叶节点在底（已知漏洞），向上汇聚到根节点（损害场景）

此处示例图特意采用纯线性描述（不用AND/OR逻辑），以更直观展示其局限性，也就是虽然简单直接，但少了很多可能性（无法表达必须同时满足的条件），可能会导致分析深度不足、覆盖不全

五、攻击可行性评级（Attack feasibility rating）

攻击可行性评级用于量化威胁场景实现的难度，为后续风险值的确定提供客观输入，在21434里定义了四个可行性等级（RQ-15-10，直译，可另行解读）：

High
攻击路径可以通过低努力来实现
Medium
攻击路径可通过中等努力实现
Low
攻击路径可通过高努力实现
Very Low
攻击路径可通过很高努力实现

另外还推荐了三种方法确定可行性评级（RC-15-11），可以根据生命周期阶段和可用信息选择（RC-15-11 NOTE 1）：

1、基于攻击潜力方法

通过核心因素打分计算潜力值，再映射到可行性等级（RC-15-12、Annex G），核心因素包括：

经过的时间（攻击需要多长时间）：

≤1 day
≤1 week
≤1 month
≤6 months

专业知识（执行这个攻击需要什么样的熟练度）

业余：与专家或熟练人员相比无知识，没有特定专长
熟练：熟悉产品或系统类型的安全行为
专家：熟悉底层算法、协议、硬件、结构、安全行为、安全运用原理和概念、新攻击定义技术及工具、密码学、产品类型的经典攻击、攻击方法等
多领域多位专家：攻击的不同步骤需要不同领域的专家级专长

信息公开性（原文说的是“对物品或组件的了解”，我觉得这里可以理解为“物品或组件的公开度”）

公开：关于物品或组件的信息能从互联网得到
受限：在开发者组织内部控制并在非披露协议下与其他组织共享的知识
机密：在开发者组织内不同团队之间共享，访问仅限于指定团队成员
严格机密：仅少数人知道，访问受到严格“需知原则”和个人承诺的严格控制

机会窗口（执行这个攻击困不困难）

无限制：通过公共/不受信任的网络实现高可用性，没有任何时间限制（即资产始终可访问），无物理存在或时间限制的远程访问，以及对物品或组件的无限制物理访问
简单：高可用性和有限的访问时间，无需物理存在即可远程访问物品或组件
中等：低可用性，有限的物理或逻辑访问，在不使用特殊工具下对车辆内外部进行物理访问
困难：非常低的可用性，访问程度不实际，无法实施攻击

所需设备（执行这个攻击需要特定设备吗）

普通：攻击者可以随时获得利用所需的设备，该设备可以是产品本身的一部分（例如操作系统中的调试器），也可以是一些开源工具
专业：攻击者不容易获得设备，但可以通过购买或花费时间去开发获得
定制：设备是专门生产的（例如非常复杂的软件），公众不容易获得（例如黑市），或者设备非常专业，以至于其分销受到控制，甚至可能受到限制，或者设备非常昂贵
多种定制：不同步骤需要不同类型的定制设备

评估攻击潜力后，Annex G还提供了Table G.6 — Example aggregation of attack potential作为示例聚合表，用于将五个核心因素的打分汇总成总攻击潜力值

然后将得到的总分映射到可行性等级：

示例：

假设威胁场景“OTA包被篡改”，对其中一条攻击路径（通过车辆WiFi热点执行中间人攻击）使用攻击潜力方法打分：

经过的时间：≤1 day，对应分值0
专业知识：专家，对应分值6
信息公开性：受限，对应分值3
机会窗口：中等，对应分值4
所需设备：普通，对应分值0

总分加起来是13分，属于10-13的范围，所以攻击可行性等级为Medium

攻击可行性评级结果将与影响评级结合，计算最终风险值，风险值是风险处理决策的重要依据

2、基于CVSS方法

基于CVSS基础指标组的可利用性指标分数计算，包括攻击向量、攻击复杂度、所需权限、用户交互（详见G.3 Guidelines for the CVSS-based approach）

3、基于攻击向量方法

基于攻击向量方法仅基于路径的主要攻击向量评估可行性，其核心思路是攻击者路径越远（逻辑和物理上）可行性评级越高，因为使用互联网的潜在攻击者数量远大于需要物理访问车辆或零部件的攻击者（详见G.4 Guidelines for the attack vector-based approach）

在实际项目中，我主要用的是基于攻击向量方法，所以本文主要介绍基于攻击向量的方法，如果读者希望了解基于攻击潜力或基于CVSS的详细计算方式，可参考G.3 Guidelines for the CVSS-based approach和G.4 Guidelines for the attack vector-based approach

TARA输出示例：

六、风险值确定（Risk value determination）

对于每个威胁场景，必须根据其关联的损害场景的影响等级和关联攻击路径的攻击可行性等级来计算最终的风险值，也就是说，要将影响评级和攻击可行性评级结合来计算威胁场景最终风险值的步骤（RQ-15-15），这一步的核心是使用风险矩阵将两个维度映射到风险等级（根据表8示例，等级从1到5，1表示风险最小），帮助优先排序高风险威胁并决定缓解策略

示例（威胁场景“篡改OTA更新包”）：

影响评级：Severe
可行性评级：High
风险值：按照矩阵，当影响等级是Severe且可行性是High时，风险值为5

风险值的计算并不强制要求用表8矩阵，但方法要一致（必须根据其关联的损害场景的影响等级和关联攻击路径的攻击可行性等级来计算最终的风险值）且要有依据

七、风险处理决策（Risk treatment decision）

风险处理决策是TARA的最后一步，根据威胁场景的风险值，选择合适的处理方式（RQ-15-17），并输出相应的网络安全目标或声明，该步骤的选项包括：

消除风险
移除风险源或放弃引发风险的功能/活动（比如取消或者移除某个引发高风险的功能）
降低风险
通过技术或组织措施降低风险至可接受水平
转移风险
通过合同或保险将风险转移给第三方
保留风险
在风险可接受范围内保留残余风险，但需记录理由作为网络安全声明，并纳入持续监控和漏洞管理

注意：通常风险值为3/4/5的场景不可以选择接受残余风险，必须选择“消除”或“降低”

通过风险处理决策，能将TARA分析结果转化为可执行的安全目标或声明，确保高风险威胁得到有效处置

TARA输出示例：

网络安全概念

网络安全概念阶段（9 Concept）是车辆网络安全工程中的关键环节，其核心任务是将TARA输出的网络安全目标和声明转化为一个针对Item的、整体的、抽象级别的安全设计方案，为后续需求细化、系统实现和验证测试提供指导框架，TARA通过风险处理决策直接输出：

网络安全目标
用于降低不可接受风险的高层要求，是网络安全需求的最高层来源
网络安全声明
对接受或转移风险的理由说明

网络安全概念以此为基础，完成以下工作：

描述安全控制措施（RQ-09-08）：
描述用什么技术或运营手段实现目标
定义网络安全需求（RQ-09-09）：
从安全目标派生安全需求
需求分配（RQ-09-10）：
将需求分配到Item

总的来说，网络安全概念将TARA的“风险是什么、怎么处理”转化为“怎么在架构中防”，确保所有TARA识别的风险得到覆盖，并将分析结果落地到设计中

为了使网络安全活动全链条逻辑清晰、可追溯性强，我非常建议在TARA的风险处理决策后直接衔接网络安全概念部分，通过这种结构，整个风险链条（威胁场景 ->风险值 -> 处理决策 -> 网络安全目标 -> 安全控制措施 -> 网络安全需求）一目了然，这种一体化呈现方式能很大程度上减少文档分散带来的查找成本，提高工作效率，输出示例：

Re-TARA

Re-TARA是指在初始TARA完成后，系统实现、并通过验证测试后，对残余风险进行的重新威胁分析与风险评估，其本质上是TARA方法的迭代应用，目的是确认已实施的安全措施是否有效降低了风险，并评估当前残余风险是否仍可接受，注意，此处的残余风险有两个意思：

经过整改后，还是无法解决这个风险
经过整改后，已经验证了安全措施有效，但网络安全不是静态的，安全措施只是当前有效不代表以后没有新漏洞、新攻击技术利用，所以此处的验证有效只代表当前状态，所以此时结果是降低风险到可接受，而不是代表“已安全”（无法永远安全），所以此时这一项就成了残余风险，需要后续管理
怎么做Re-TARA
输入材料：
初始TARA报告、已实现的网络安全需求、验证测试结果、变更记录、新漏洞情报
过程：
1.重新审视威胁场景和攻击路径，评估措施实施后攻击可行性是否降低
2.重新计算风险值
3.对残余风险决定“接受”（记录网络安全声明）或进一步措施
输出材料：
1.残余风险列表及网络安全声明（接受理由）
2.监控计划

结语

TARA作为ISO/SAE 21434定义的核心风险评估方法，其在UN R155法规框架下不仅是技术工具，更是车辆型式认证和CSMS运行的合规基石，通过系统识别资产、威胁、损害、可行性，并最终转化为网络安全目标和需求，TARA确保了风险从识别到缓解的全链条闭环，在实际项目中，TARA需结合法规基准（附录5参考场景）和供应链协作（供应商组件级结果整合），尤其整车级要重点关注集成引入的新风险，持续迭代和监控是保持车辆生命周期网络安全的关健

说明

输出的TARA示例图每个都是单独例子，请不要串联
TARA真的是一个复杂的工作，光粗略的写都能有近万字，其中的过程其实还有很多种方法这里没有提及，请谅解，如果你有我的联系方式，我们可以交流一下
重申：TARA有很多方法，如果我讲的跟你想的不一致请不要喷，不好的评论我会删
ReTARA网络安全不是静态这个概念是之前在某个认证现场跟老外讨论并且后面本人已经做过了的，我觉得是真可以
TARA需要尽早开展，避免后期大返工（最好是车型立项开始选供应商阶段，OEM提供初步安全需求作为选型标准，签订合同后开始完成TARA，这个过程大概有7-12个月或以上，贯穿整个车型周期）