做车辆网络安全的同行应该都逃不过 TARA 这三个字母。TARAThreat Analysis and Risk Assessment威胁分析与风险评估是整车网络安全工作中最核心、也最繁琐的一环。最近我用一个叫 FEV TARA Copilot 的辅助工具完整跑完了一轮真实车型的威胁分析与风险评估体验确实比纯手动靠谱太多。这篇文章把方法论、工具流程、踩过的坑一起记录下来希望能帮到正在做或者准备做 TARA 的团队。这工具名字里的 Copilot 确实容易让人联想到 GitHub Copilot但它的思路是类似的——像副驾一样在你做分析的时候递资料、提醒遗漏、自动算分、生成报告。你不用从零开始动笔车子还是你自己开。对正在导入 ISO/SAE 21434、需要应对 UN R155 审核的团队来说TARA 已经从加分项变成了强制项能辅助团队高质量完成评估的工具价值比想象中要刚需得多。1. 先搞清楚为什么要做 TARA1.1 车辆网络安全不是锦上添花而是硬性门槛如果你是 2022 年以后才开始接触车载网络安全可能很难想象在此之前很多整车项目的安全评审基本停留在防火墙、入侵检测这类单一维度上。但智能化、网联化、软件定义汽车这三板斧砍下来车辆的攻击面已经大得离谱——远程控车、OTA 升级、手机钥匙、云端数据交互每一个功能都是潜在的入口。监管和标准也随之而来。UNECE R155 法规在多个国家和地区已经生效没有过 CSMS网络安全管理系统认证车型连市场准入都拿不到。ISO/SAE 21434 则把网络安全管理贯穿了整个生命周期概念、开发、生产、运维、退役每个阶段都有明确要求。而 TARA 是所有这些要求里最核心的引擎——没有评估就不知道风险在哪里也谈不上缓解措施。换句话说TARA 不是你想不想做的问题而是不做就不让你卖车的问题。这也是我们团队当初下决心把 TARA 流程工具化的直接动力。1.2 TARA 到底在做什么——用大白话说一遍业内聊 TARA 的时候经常满嘴术语什么资产、威胁场景、攻击路径、风险值……但回到本质上TARA 就是在回答四个问题什么东西值得保护资产识别它可能被谁、用什么方式搞坏威胁场景与攻击路径搞坏了后果有多严重影响评级这事发生的可能性有多大攻击可行性评估把这四个问题搞清楚了最后算出一个风险等级再决定是接受、缓解、转移还是规避。整套逻辑有点像你给自家房子做防盗评估先盘点家里有什么值钱的资产想想小偷会从窗户进还是撬锁进门攻击路径一旦丢东西损失多大影响你家所处区域的治安情况怎么样攻击可行性最后决定是装防盗窗还是买保险风险处置。ISO/SAE 21434 对 TARA 的流程做了标准化定义从资产识别开始一直到风险处置决策每一步都有明确的输出要求。实际操作中最耗时间的不是评估思路本身而是把这条链路上所有信息整理出来、量化出来、留下证据。1.3 ISO/SAE 21434 和 UN R155 对 TARA 的具体要求先理清这两个东西的关系。UN R155 是法规它要求企业建立 CSMS并在车型开发中应用相应的网络安全风险管理流程ISO/SAE 21434 是标准它提供了满足法规要求的工程方法和最佳实践。所以很多企业的做法是用 ISO/SAE 21434 搭建网络安全工程体系用产出物去满足 R155 审核。TARA 在 ISO/SAE 21434 里主要在概念阶段Clause 9和开发阶段Clause 10反复出现。概念阶段要求基于 item definition项目定义做 TARA输出网络安全目标和网络安全概念到了开发阶段针对具体组件、具体通信链路还要做更细粒度的 TARA确保需求落实到软硬件层面。这里有个非常多人忽略的坑TARA 不是做一次就完了。设计变了、功能改了、供应链换了都可能改变风险评估结果。法规和标准都强调了 TARA 的持续性和迭代性。用工具管理这些版本变化比用文件夹和命名规则硬扛要省心得多。2. 手动做 TARA 的痛点逼出来了这个 Copilot2.1 一辆智能网联车的资产清单能把你逼疯我第一次真正负责一个车型的 TARA 时以为工作量主要是分析思考后来才发现光是整理资产清单就差点让人崩溃。一台智能网联汽车有几十个 ECU、上百个功能、数不清的传感器和通信总线。每个 ECU 可能承载多个功能资产比如远程解锁、自动紧急刹车、语音助手、车况诊断监控……如果按 ISO/SAE 21434 的粒度资产去定义一个中大型项目资产数量轻松破千。手动做法通常是在 Excel 里拉一张大表资产编号、所属域、安全属性、数据流向、依赖关系、责任人……几百行下来光是维护格式就让人焦头烂额。更麻烦的是资产之间还有关联一个车云通信功能涉及车端 T-Box、云端平台、手机 App、后台账号体系如果资产拆分粒度不一致后面做威胁分析的时候就会漏掉跨组件的攻击路径。我当时最深的体会是TARA 的质量上限在资产清单的质量。资产识别不完整威胁分析做得再漂亮也是白搭——你根本没分析你该保护的东西。这也是工具的价值点之一用结构化数据库管理资产比用 Excel 的无限行靠谱得多。2.2 威胁场景穷举不完整专家经验成了瓶颈资产识别完了下一个头痛的问题是威胁场景怎么列。很多团队的威胁场景来源主要靠两类一是参考行业公开的威胁数据库比如 SAE J3061 时代积累的资料、BEST 或 HEAVENS 项目的威胁场景列表二是靠有经验的网络安全工程师拍脑袋。前者的问题是不够贴合你的具体架构后者的问题是很依赖个人能力而且极易漏项。我见过一个实际案例某团队做的 TARA 报告列了 67 个威胁场景看着不少但外部专家复核时又补了 40 多个涉及 OTA 回滚攻击、远程诊断接口滥用、云端凭证泄露等场景。不是团队不努力而是人脑穷举威胁场景这件事本质上就不靠谱——你只见过你见过的。这也是 Copilot 这类工具特别有价值的地方。它内置了来自大量项目经验沉淀的威胁场景库还能基于 AI 根据你的功能描述、系统架构自动生成候选威胁场景。AI 生成的内容不一定每条都对但它能给你提供一个尽量完整的起点把专家的精力从穷举中解放出来投入到场景筛选和细化上。2.3 文档工作量和审计追溯是隐形负担如果说资产和威胁场景的工作量是显性的那文档报告的工作量就是隐性的但它一点都不轻松。TARA 评估完你得写报告。报告不是随便写写就行——R155 和 21434 审核时审查方会抽查你的评估逻辑是否完整、评分是否有依据、决策是否有记录。换句话说你需要的不只是一份结论而是一条完整的追溯链从资产到威胁场景从威胁场景到攻击路径从攻击路径到风险评估从风险评估到安全需求每一步都要能追溯到为什么这么评。手动整理一条追溯链意味着大量的复制粘贴和交叉引用。尤其是在大型项目里一个资产被多个威胁场景关联一个威胁场景又关联多条攻击路径牵一发而动全身。改了一个资产的描述所有关联的地方都要同步更新纯手工操作基本是在给团队埋定时炸弹。报告格式更是一种隐藏痛苦。不同客户、不同审核机构要求的报告模板都不一样。工具如果能支持报告模板定制和自动生成这背后的效率提升是实打实的尤其是面对多个车企客户时一套工具能给你省出好几周的文档时间。3. FEV TARA Copilot 核心功能拆解3.1 资产管理从 Excel 表格到结构化数据库FEV TARA Copilot 在资产管理上的逻辑和我们手动做的最大的区别是它把资产组织成一棵层级树而不是一张扁平表格。一辆车先划分域底盘域、动力域、座舱域、智驾域/ADAS、车云交互域……域下面是具体组件ECU、传感器、网关、云端服务实例组件下面才是网络安全资产功能性的、数据性的、硬件类型。每个资产都可以定义它的网络安全属性——机密性Confidentiality、完整性Integrity、可用性Availability、真实性Authenticity——以及它在哪些数据流中扮演什么角色。做作用是把之前的项目定义结构化后面做威胁分析时工具能自动关联到所属功能上下文。如果你在设计阶段用了 SysML 或者基于模型的系统工程某些系统架构模型也能通过接口导入。这套资产管理方式带来的直接好处是资产复用同平台车型的项目可以直接复制资产库不用从头再来。影响追溯资产改动时可以迅速看到会影响哪些威胁场景和风险决策。多角色协作架构工程师、功能安全工程师、网络安全工程师在同一套资产定义下工作减少各说各话的沟通成本。3.2 AI 辅助威胁场景识别快速生成候选场景这是 FEV TARA Copilot 最吸引眼球的功能也是我们这次用的核心功能之一。用过 GitHub Copilot 写代码的应该能秒懂这个交互逻辑你给一段功能描述工具会推荐一批可能的威胁场景让你选择。实际的实现路径大致是这样的——输入车辆功能名和功能描述比如远程解锁再勾选涉及的资产类型工具会基于威胁场景库和它对海量 TARA 案例的学习给出候选威胁场景列表。比如针对远程解锁功能它可能会推荐攻击者重放解锁指令实现中间人攻击获取车门控制权攻击者通过网络钓鱼获取用户账号密码远程盗车攻击者利用云端 API 越权漏洞调用解锁接口控制任意车辆攻击者对 OTA 固件包进行逆向篡改部署恶意后门攻击者利用蓝牙低功耗协议漏洞非法配对钥匙每条推荐还附带参考的攻击路径元素、涉及的资产属性和行业标签你可以逐个确认、修改或删除。这个过程不是完全自动的但它把从 0 到 1的写场景过程变成了从 10 到 1的选场景和改场景过程效率差异非常明显。需要强调的是AI 生成只是起点。工具推荐的是行业内常见威胁不一定完全适用于你的特定架构。比如它可能推荐了攻击者物理访问 OBD 端口提取诊断信息但你的车型 OBD 端口在极端情况下有物理访问控制保护那这条场景你就需要调整路径描述并更新防护假设。工具是给你撑腰的副驾不是替你开车的司机最终的专业判断和确认必须由自己完成。3.3 风险计算引擎攻击可行性与影响的量化风险评估是 TARA 的核心输出也是 FEV TARA Copilot 的另一个关键模块。要理解这个模块需要先了解风险评估的两个维度。影响评级Impact RatingISO/SAE 21434 建议关注四个维度维度含义示例Safety对人的安全影响车辆失控、碰撞Financial财务影响盗损、改装损失、公司赔付Operational运营与功能影响车辆不可用、远程功能失效Privacy隐私影响车主个人信息泄露、位置追踪每个维度一般分 04 五级乘以权重后聚合成一个影响分数。比如一个刹车失控的场景Safety 铁定是最高级 4 分而娱乐系统播放异常可能 Operational 也就 2 分Safety 是 0 分。攻击可行性Attack Feasibility行业常见做法参考攻击潜力模型或者 CVSS 思路综合评估攻击时间、攻击者所需专业知识、对系统的了解程度、机会窗口、所需设备等因素。最终输出一个可行性等级从极低到极高。风险值怎么算ISO/SAE 21434 没有强制规定唯一公式常见的做法是风险值 攻击可行性 × 影响等级或者做成 4×5 的矩阵表落在不同格子里对应不同风险等级。Copilot 的做法是在你完成影响和可行性评分后自动计算风险值并映射到高、中、低、可忽略等风险等级。这里有一个非常实用的功能——评分依据留痕。工具会让你针对每个评级填写依据说明比如影响评级选了 Safety4依据是该攻击可导致任意位置制动功能丧失。这对应前面说的审计追溯需求审核组问起来你能明确说出每个分值的理由而不只是拿结论糊弄。3.4 自动报告与审计追溯工具内置了基于 ISO/SAE 21434 标准的报告模板应该说是把文档工程师的活给接了一大半。关键的输出物包括资产清单表威胁场景清单及来源攻击路径图影响评级汇总攻击可行性评估明细风险矩阵与风险等级汇总处置决策及安全需求追踪每一份报告都带着数据血缘关系——这条威胁场景是基于哪组资产定义推出来的风险值用的是哪些维度的评分安全需求关联的是哪条处置决策在报表里都能层层点击溯源。我们在实际审核预演时评审专家会随机抽查一个风险项要求完整走通从资产到需求的追溯链。手动方案下往往要翻好几个文件才能凑齐用工具之后可以在几分钟内完整展示全链路逻辑这对通过 R155 审核的信心提升是很实在的。4. 实操过程用 FEV TARA Copilot 走完一次完整评估4.1 环境准备与项目初始化工具使用前需要确认运行环境和数据输入。根据团队实际条件通常会涉及以下准备系统环境支持 Windows 10/11 或常见 Linux 发行版本建议 16GB 以上内存因为处理大型资产库和模型时会比较吃资源。输入数据系统架构定义如果有 SysML 或架构工具导出文件、功能列表、接口表、现有安全方案描述。编译技巧工具支持在 Web 界面中导入或复制功能描述也可以通过 Excel 批量导入资产清单首次使用建议从 Excel 导入快速建立初始资产库。初始化项目时需要设置 TARA 上下文包括项目名称、适用车型、评估范围架构层、组件层、评估依据比如遵循 ISO/SAE 21434 还是客户定制方法。这里建议把上下文定义得足够清晰范围不明确是后期反复返工的头号原因。4.2 资产识别与系统边界定义资产识别是最关键的一步也是我在使用中花时间最多的地方。实际操作中我建议按以下顺序来先从整车/系统层面拆功能清单把功能域划分出来。比如智能座舱域、智能驾驶域、动力与底盘域、车身控制域、远程服务域。针对每个功能域识别承载该功能的组件记下 ECU、传感器、执行器、CIoud服务等。再为每个组件定义资产。这里的关键是区分资产和组件的关系组件是物理逻辑载体资产是需要保护的对象。举个例子网关Gateway是一个组件但它承载的资产可能包括诊断相关内部通信数据的完整性安全启动密钥及证书的机密性网关路由功能的可用性每个资产生成时要定义资产属性CIA/ authenticity这决定了后面威胁场景生成时会偏向哪些攻击手法。比如远程诊断数据机密性要求高系统在生成威胁时就更容易推荐与信息泄露相关的场景如果某个安全关键控制命令完整性高则更容易推荐与消息篡改和重放相关的场景。这部分的输出需要团队评审确认。我建议至少包括两类人熟悉系统架构的工程师和熟悉网络安全攻防的工程师。两者视角互补能有效避免资产定义只有组件没有安全属性或者只有属性但不贴合架构的问题。4.3 威胁场景分析与攻击路径建模资产和功能定义好之后就可以开始威胁场景识别了。我在实操时最喜欢的方式是逐个功能过一遍。以远程控制功能为例输入的资产集合可能是手机 App Token、车端接收模块、云端指令处理服务、T-Box 通信接口。在 FEV TARA Copilot 中输入这些信息后工具给出了一组大约 2030 条候选威胁场景覆盖了外部攻击、内部异常等不同角度。我从中挑选确认后对每条场景进行了细化补充攻击路径。这里有一个要点攻击路径不是画一张什么都能打的流程图而是要把每一步的具体手段都落到真实的通信链路和接口上。举个实际例子一条攻击者通过伪造手机 App 身份发送远程解锁指令的攻击路径可以拆解为攻击者通过恶意软件/钓鱼获取用户账号凭据。攻击者使用凭据调用云端主动解锁 API。云端未识别异常登录行为处理指令并下发至 T-Box。T-Box 验证指令合法性因为无异常——凭据有效所以验证通过——需注意若存在多重验证仍然有效时。车门控制器接收到解锁指令执行解锁动作。细化之后你可以针对每一环节标注已有防护措施比如调用频率异常检测、设备指纹绑定、短信验证码二次校验、车辆端证书鉴权等。护措施描述越完整后面评攻击可行性时就越有依据报告也更有说服力。这里还要提醒一句威胁场景的粒度要统一。同一个功能下建议按照一个攻击目标 一类攻击方法 一个入口的方式拆分场景避免出现远程控制功能可能被黑客攻击这种一句话包打天下的描述。4.4 影响评级与攻击可行性评估威胁场景确认之后就进入打分环节。影响评级的操作界面里每个场景需要对 S/F/O/P 四个维度分别打分和填写理由。工具会给出每个维度的等级定义说明比如 Safety 维度等级描述示例S0无影响无人员受伤风险S1轻度影响车辆功能异常但对驾驶影响轻微S2中度影响车辆功能部分失效可能导致轻伤S3严重影响车辆主要安全功能失效可能导致重伤S4极端影响可能造成多人伤亡攻击者通过伪造 App 身份远程解锁并盗车这个场景Safety 方面如果没有人在车内通常是 S0/S1但 Financial 方面因为车辆被盗至少是 F3/F4Privacy 方面车辆位置信息被掌握可能有 P2/P3。这个多维评分比传统单一高/中/低要科学得多——既能反映某个具体维度的风险又不至于因为一个维度高就掩盖其他问题。攻击可行性评估我通常先参考工具生成的初始值工具会根据攻击路径涉及的接触程度、所需专业知识自动给一个初始建议再由评审人员复核。这个初始建议的作用是防止人为偏见——比如你明知道某个远程接口很容易被攻击但因为这个功能是你们团队的成果会下意识降低可行性分数。工具的客观参考值能帮你把评分拉回现实。不过说实话初始建议只是参考实际评审时经常需要调整。你看攻击潜力模型里的那些因子——攻击时间、专业知识、对系统的了解、机会窗口——每一项在不同车型上差异都非常大。比如一个仅在中国市场售卖但未做本地化安全加固的云端服务和部署了 WAF、IDaaS 和异常流量检测的云端服务同样的攻击路径可行性评分可以差出两个等级。4.5风险值计算与处置决策完成影响评级和攻击可行性评估后工具自动计算风险值并生成风险矩阵。我们以 4×5 矩阵为例攻击可行性 \ 影响低影响中影响高影响极高影响极低可忽略可忽略低中低可忽略低中高中低中高高高低中高极高落在不同风险等级的场景处置方式也不同可忽略不需要额外处理记录在案。低风险可选做加固或者平衡进度决定是否处理。中风险原则上需要制定安全需求来处理如果某个场景没法完全消除风险要明确接受理由。高风险/极高风险必须制定缓解措施通常涉及网络安全需求定义、架构调整或运营端检测响应能力建设。处置决策不是工具的活而是团队的决策。但工具提供了极好的辅助——每一项决策都可以关联到具体的安全需求或已采取的缓解措施。这形成了一个完整的处置闭环我们做的每一个接受风险决策都有数据支撑和责任人这对后续的审核追溯起到了关键作用。4.6 报告生成与团队评审评估完成后我直接使用工具的报告生成功能导出评审材料。报告内容包括所有场景的评估明细并自动按风险等级排序、分类汇总。输出报告后的流程和传统 TARA 没有本质区别——组织评审会议邀请网络安全负责人、系统架构负责人、功能安全工程师、项目质量工程师参会逐条审阅高风险项和中风险项确认处置决策。但相比手动方式工具导出的报告格式统一、关联清晰评审节奏明显加快团队可以把时间花在评审业务决策上而不是看Excel对格式上。5. 常见问题与排查技巧实录5.1 威胁和风险总被混着说报告一塌糊涂这是新手团队最常见的坑。威胁Threat是可能发生什么不好的事风险Risk是这件事发生的可能性和后果有多大。很多团队的 TARA 报告把攻击者入侵网关这种信息直接当作风险结果展示完全没有量化的过程审核组一眼就能看穿。用工具能帮助缓解这个问题因为工具强制要求你走完威胁场景 → 影响评级 → 可行性评价 → 风险值计算的全流程。但前提是你也要理解每一步的意义威胁是定性的描述风险是定量的综合评估。写报告时一定要区分清楚该列为威胁场景的不要出现在风险结论里。5.2 评分主观性太重团队内部都吵起来了影响评级和攻击可行性评分都包含主观判断这是 TARA 方法论本身的特点无法完全消除。但可以通过流程设计把主观性降到最低。我的做法有三个第一评分前先做一次预打分校准。拿两三个典型案例比如远程解锁、OTA 更新让大家分别打分再开会对齐差异让团队在什么情况算 S3这类问题上形成共识。第二强制填写评分依据不允许只给分数不给理由。这个要求能让评分者逼自己去思考。第三利用工具的客观参考值做锚定。攻击可行性建议值是工具基于攻击路径计算出的参考值即使不直接采用也能帮你削弱主观偏差的影响。5.3 架构文档不齐资产识别卡壳怎么办现实项目中系统架构不清晰是常态尤其是在新平台开发初期。碰到这种情况我从实践中总结出一套后退一步再前进的办法先从功能清单出发定义逻辑资产功能级的比如远程解锁的授权校验逻辑把逻辑资产列清楚。即便没有完整的通信链路图也能分析大部分与流程相关的威胁。物理架构细节等文档补充后再细化资产和攻击路径再进行第二轮的威胁场景复核。关键是明确当前这一轮 TARA 覆盖到什么级别、后期何时再刷新。工具同样可以应对这个场景它的资产模型本身是分层的先建逻辑/功能层资产后面再补充组件层和接口层不会因为粒度变化而推翻重来。5.4 工具与现有开发流程的对接问题再好的工具如果不能跟团队的现有流程结合起来也会变成摆设。这方面我有几个建议团队里要有人承担工具管理员角色负责资产库的维护、流程模板的定制和权限管理否则工具用半年就会变成信息孤岛。与需求管理系统比如 Polarion、DOORS、Jama做好对接把 TARA 输出的安全需求、处置决策同步到需求管理平台。每次评估迭代要与设计变更同步触发避免出现设计改了、风险还是老版本的尴尬。定期做 TARA 复用性复盘。同一个平台的多个车型初始评估结果大多数可以复用但一定要评估这个改动是否影响之前的安全结论工具的项目复制功能可以帮你快速生成新项目的基线。5.5 AI 生成结果看起来合理实则有偏的问题这是我在使用生成式辅助功能时最警惕的一点。AI 给出的威胁场景数量多、形式规范但内容可能偏向行业通用场景对你们车型特有的技术路线覆盖不足。比如一个团队用了自研的隐私计算方案AI 大概率不会自动推荐攻击者利用隐私计算节点密钥管理漏洞提取用户数据这种高度定制化的场景。所以在实际使用时AI 提示只作为基础候选列表真正可用的威胁场景清单最终还是要靠有经验的工程师结合自己的系统特性人工补充和调整。提醒使用 AI 输出时千万不要盲信工具的全和准它提供的是经验不是针对你车型的定制结论。TARA 的最终责任一定在评估团队。6. 我的一些实在体会工具用了之后最大的感触不是省了多少时间而是质量下限被抬起来了。过去手动评估时一场重要的 TARA 评审会开下来大家常会发现某个关键功能被漏掉、某个攻击路径完全没考虑到这种遗漏的感觉实在糟糕。有了 FEV TARA Copilot 这种辅助工具虽然依然需要网络安全的专业判断、评审会依然要开、高风险项依然要打磨但起码团队不用再在基础工作上消耗大量精力——资产清单不再是几张互相矛盾的 Excel 表威胁场景不靠几个人闭门想风险计算不会算错维度报告也不会在最后一天熬到半夜拼凑。这种踏实感我觉得是这类工具带来的最大价值。以后遇到做车辆网络安全的朋友问要不要上 TARA 工具我的答案已经变成有条件就上吧不是因为它能取代你的判断是因为它能在你没注意到的地方帮你兜底。TARA 这件事本身就是个系统工程与其把精力浪费在穷举、排序和排版上不如留给那些真正需要人来思考的问题。