尧图网站建设 
简介《ISO/SAE 21434:2021 道路车辆——网络安全工程》中文版是一份面向汽车电子电气系统研发团队、功能安全与网络安全工程师、自动驾驶与车联网安全从业者的完整标准译文。相比英文原版中文版消除了语言障碍便于在国内研发、审核与合规评估中直接引用适合作为整车厂与零部件供应商实施车辆网络安全管理体系的基础参考文件。压缩包共 1 个 PDF 文件整体约 1.46MB轻量便于下载与分发。文件完整收录标准正文涵盖组织网络安全管理、项目依赖的网络安全管理、分布式网络安全活动、持续的网络安全活动、概念阶段、产品开发、网络安全验证、生产、操作与维护、网络安全支持和退役以及威胁分析和风险评估方法TARA等第 4~15 条核心内容并保留条款与工作产品的唯一标识符方便对照检索。目前已有 3125 人次学习下载。对需要建立车辆网络安全流程、完成供应商安全对接或落实 WP.29 R155 合规要求的从业者这份中文版能直接提供完整的标准依据与工程要求清单。1. 为什么 ISO SAE 21434 中文版成了智能网联汽车团队的必读材料智能网联汽车的项目评审会上这两年几乎每次都会有人问这条按 21434 怎么过。ISO SAE 21434-2021 是道路车辆网络安全工程的第一份国际标准它把过去靠个人经验输出的安全工作变成了一套从组织管理到产品退役的工程流程。对整车厂、Tier 1 和做域控制器、T-Box、网关的团队来说这份中文版 PDF 解决三件事给研发流程补一套可审计的网络安全骨架给客户交付一份合规证据给法规强制备案一张底牌。它适合谁读网络安全工程师拿它定流程嵌入式与测试拿它找输出物项目经理拿它排计划供应商质量拿它写合同。拿到手别从头翻先抓条款编号和附录清单——这份标准的查法比读法重要。2. 先读骨架把条款 514 拆成五张地图中文版从哪里开始查拿到中文版 PDF最常见的姿势是从第一页开始翻翻到 TARA 那章就卡住。这个标准不是按阅读顺序写的它是按审计顺序写的。我建议先看目录把条款 5 到 14 按职能画成五块组织级管理、项目级管理、分布式活动、持续活动、产品生命周期工程。这五块正好对应外界评审时五个方向也是建体系时五个责任区。这样拆完你会立刻发现21434 和 ISO 26262 的框架同源都讲究组织有方针、项目有计划、过程有输出、证据可追溯。但 21434 多出两条 26262 不太强调的线一条是供应链上下游的网络安全责任传递一条是车型上市后的持续监控与漏洞管理。这两条恰恰是国内团队最容易忽略、也最容易被外审抓住短板的区域。2.1 条款 57组织级、项目级与分布式活动CSMS 是地基条款 5 是组织级网络安全管理核心是 CSMS也就是网络安全管理体系。它要求的不是某一个项目的产出而是公司层面要有网络安全方针、角色与责任、人员能力、意识培训、过程改进和信息共享机制。翻译成落地动作你要有明确的安全负责人和一张责任矩阵要有培训记录要有工具链管理办法还要有持续改进的证据。这部分在国内企业里最容易被跳过因为它不直接对应产品功能老板看不到功能点。但外部审核第一次看的就是条款 5组织层面要是空的后面项目文档再全审核员也可以直接判定体系不成立。我见过一家 Tier 1 项目材料做得很漂亮却拿不出公司层级的网络安全方针和年度培训计划最终审核结论直接降级。所以别把条款 5 当成放文件夹的公共部分它是整个体系能不能站住的底座。条款 6 是项目级网络安全管理讲的是每个项目怎么做计划。包括网络安全活动在项目计划里的排布、工作产物清单、里程碑、角色分配以及标准里 cybersecurity case网络安全案例的逐步积累。条款 7 是分布式网络安全活动通俗讲就是供应链接口外包给供应商的软硬件、云服务、工具链网络安全责任怎么划分、需求怎么传递、验收怎么闭环。对 Tier 1 来说这一条决定了你从整车厂拿到的规格书里会附带多少条安全需求也决定你转包给二级供应商时必须传递哪些约束。实操建议是先按条款 5 的条目做一次差距分析把不满足的项列一张表再按条款 6 挑一个正在进行的量产项目做项目网络安全计划。不用贪多一个试点项目完整跑通比十个项目各写三张纸有用得多。2.2 条款 813概念、开发、验证、生产、运维的工程主线条款 8 到 13 是标准的工程主干对应产品从立项到退役的完整生命周期。建议按六个阶段读每个阶段抓活动 输出物两件事阶段条款关键活动主要输出持续活动8网络安全监控、漏洞分析、漏洞管理监控计划、漏洞评估记录、处置决策概念阶段9项目定义、TARA、网络安全目标、网络安全概念TARA 报告、目标清单、概念文档产品开发10需求拆解、架构设计、软硬件实现、集成验证安全需求规格、设计文档、验证记录网络安全验证11在整车/系统层面确认风险被有效消减验证报告、网络安全案例生产12产线安全控制、一致性检查、追溯生产控制计划、产线审计记录运维与退役13运行监控、OTA 安全更新、退役数据擦除运维计划、事件响应记录这里要特别提醒两个词的区别条款 10 里的 verification 是需求实现了没有条款 11 的 cybersecurity validation 是实现之后风险降低了没有。很多团队在这两个词上栽过跟头把单元测试报告当验证报告交了外审问起来才发现少了整车层面的风险确认证据。另外一个容易被忽略的是条款 12 生产环节。产线上的密钥烧录、软件签名、配置数据防篡改都要有控制点和追溯记录。传统车厂里生产部门默认这是研发的事研发又以为产线自己会管最后两边都没有证据。这部分在审核里属于必查项因为攻击者往往比研发更容易接触产线。2.3 条款 14 与附录 A/BTARA 方法和工作产物中文版怎么查最快条款 14 定义了 TARA 方法本身的输入、输出和迭代步骤附录 A 给了 TARA 方法的实例附录 B 是各条款对应的工作产物清单。这份标准查法有点特殊它不像 ISO 26262 那样按 ASIL 给你一张该做什么活动的裁剪表而是把做到多深的责任交给企业自己标准只给约束和产出要求。所以实战中中文版 PDF 最常用的两处就是附录 B 和条款 14。审厂和客户审计时审核员基本都拿着这两处展开要证据。用中文版的时候建议和英文原版对照着查条款编号一致遇到翻译分歧时能快速确认原意。比如英文术语中文版常见译法备注item项目 / 条目 / 对象物指被研究的整车、系统或组件别和 project 混淆cybersecurity goal网络安全目标TARA 的直接输出TARA威胁分析与风险评估条款 14 的方法学attack feasibility攻击可行性评估攻击难度CAL网络安全保证等级 / 保障等级四个级别详见第 3 章work product工作产物附录 B 清单CSMS网络安全管理体系条款 5 的核心概念提示中文翻译里最容易造成误解的是 item。有的版本译成项目读的时候会跟项目管理混在一起。建议团队内部统一叫被评估对象并在文档里保留英文原文。3. 落地最小流程集从 TARA 到工作产物的可抄作业模板读完了条款地图接下来就是把它变成每周能执行的动作。我经过两个完整项目后沉淀下来一套最小流程集一次 TARA、一张 CAL 分档表、一套按阶段交的产物清单。这套东西不大但能覆盖外审 80% 的检查点。3.1 用 TARA 把风险讲清楚资产识别、攻击路径与风险值的打分规则TARA 是 21434 里唯一给了详细方法定义的工程活动也是外审必查的第一个技术文档。一份能通过评审的 TARA 记录表至少包含下面这些字段字段含义容易写歪的地方资产要保护的对象数据、功能、属性写成CAN 总线而不是制动指令的完整性威胁场景攻击者通过某路径造成损害的描述写得太抽象不可验证攻击路径从入口到资产的完整链路漏掉物理接触类入口影响对人身安全、财务、运营、隐私的影响只写严重没有分级依据攻击可行性攻击需要的时间、技能、知识、设备、机会窗口凭感觉打分没有统一尺度风险值影响 × 攻击可行性的综合评定高低判据不一致网络安全目标针对风险值提出的消减目标直接写成具体方案缓解措施达成目标的手段放网络安全概念里在 TARA 里写太细过早设计实操步骤我一般这么走第一步圈定对象item 可以是整车、域控制器、网关也可以是一个软件组件第二步列资产并给每个资产标安全属性常见的是机密性、完整性、真实性、可用性第三步枚举威胁场景这里不要从攻击树反推要从这个部件被拿到攻击者手里最可能的入口在哪出发。打分时我会建一张评分细则表影响和攻击可行性各按 1 到 4 分打分然后组合成风险矩阵。附录 A 给了 EVITA、HEAVENS 等方法的思路常见做法是自建一套简化版关键是所有条目用同一把尺子。审核员最在意的不是你的分数准不准而是评分标准的一致性以及这条为什么接受、那条为什么不接受的可追溯逻辑。风险值的输出是排序不是绝对真理这一点想通了TARA 就不难。3.2 从风险值到网络安全目标CAL 分档与需求推导链TARA 输出了风险值和网络安全目标之后下一步是给目标分配 CAL。CAL 有四个级别中文版通常叫网络安全保证等级或保障等级。它描述的是为了达成这个目标需要多强的保证活动而不是目标本身有多重要。这一点经常被搞反有人把 CAL 当风险等级标在需求上其实它是用来决定评审深度和验证强度的。CAL适用场景典型保证活动CAL 1低风险、不涉及核心资产常规设计评审、自测CAL 2中低风险、攻击面有限增加架构评审、对抗措施分析CAL 3高风险、涉及安全或核心数据独立评审、系统化验证证据CAL 4极高风险、攻击后果严重更严格的证据链、必要时形式化方法完整的推导链路是威胁场景 → 风险值 → 网络安全目标 → CAL → 网络安全需求 → 设计实现 → 验证确认。每个目标都要能在这条链路上找到自己的位置。我习惯在需求管理工具里给每条安全需求挂两个属性来源目标编号和 CAL 等级这样审核时输入目标编号能一键拉出全部相关需求。这里有个高频误区把 CAL 当 ASIL 用试图建立两者之间的固定映射。21434 明确没有这种对应关系CAL 从风险值来ASIL 从危害分析来。实践中两个体系各评各的只在文档里互相引用。比如一个远程控制功能功能安全上可能是 ASIL B但网络安全上因为攻击面大、可达性高CAL 可能定到 3两者不必相等也不能互相替代。3.3 四类必交工作产物概念、开发、验证、运维各交什么附录 B 的工作产物清单很长全做完会把人吓退。我按外审重点收敛成四类每个阶段交什么、里面有什么提前定死阶段必交产物核心内容概念TARA 报告、网络安全目标、网络安全概念风险分析结论、目标清单、初步架构级措施开发安全需求规格、设计说明、验证记录需求到设计的追溯、测试用例与结果验证网络安全验证报告整车/系统层面的风险消减确认、残余风险说明运维监控与响应计划、漏洞管理记录情报来源、SLA、事件升级链路、漏洞处置台账这四类产物是项目级的最小集合也是外审看证据时的主入口。注意每一类都要有版本和签审记录没有受控的文档在审核里等于不存在。另外产物之间要能互相追溯从网络安全目标能查到对应需求从需求能查到验证用例从验证用例能追回目标。断一环整条证据链就不成立。提示项目开始时就把这几类产物的模板定下来哪怕内容是空的。后期补文档是最痛苦的因为细节早就忘了补出来的东西审核员一眼就能看出来是补的。4. 实施 21434 的避坑指南六个翻车现场与血泪拆解下面六条是我在项目里真实踩过、也看同行反复踩的坑。每条按现象、原因、解决三段写留着排查问题用。4.1 TARA 做成了安全测试用例列表现象TARA 报告里全是通信要加密要做模糊测试这类对抗措施描述翻完整份文档看不到威胁场景和攻击路径。原因团队把 TARA 和安全方案混在一起跳过了风险分析直接写对策觉得反正都要做。解决TARA 记录表先只写威胁场景、影响、攻击可行性、风险值任何解决方案都不许写进去对抗措施放进网络安全概念文档。评审时先要求删掉方案再评逼着把风险分析补上。4.2 把 CAL 当 ASIL 用直接套映射表现象项目计划里写CAL 3 等同 ASIL C活动裁剪完全照搬功能安全那套。原因团队刚从 ISO 26262 项目转过来顺手把经验平移了。解决CAL 从风险值推导ASIL 从危害推导两边独立评定但互相引用。给每个 CAL 等级写一份活动定义表说清楚这一级要做哪些评审、哪些验证别用 ASIL 的裁剪逻辑替代。4.3 供应商合同里的网络安全接口留空现象和供应商签的技术协议里只有功能、质量和交期没提安全需求开发中安全需求变更只能在邮件里流转最后验收对不上。原因采购阶段没有网络安全工程师参与合同模板里也没有对应条款。解决在采购合同或技术协议里增加网络安全章节至少包含需求来源、交付物清单、审核权、变更流程和验收标准另外加一条供应商漏洞响应的承诺时限。4.4 文档版本失控审核时对不上现象TARA 更新了两版网络安全目标文档还是旧版审核现场到处找哪个是最新版。原因文档没有走配置管理项目计划里的版本基线没有跟着变更走。解决把网络安全工作产物纳入现有配置管理库和受控软件用同一套规则任何版本变更必须带变更记录并在项目网络安全计划里登记。4.5 漏洞管理只管开发、不管上市后现象车型上市后漏洞没人牵头管安全事件发生两三天才有人响应客户投诉了才复盘。原因条款 8 和条款 13 被忽略团队只做了开发期的活动上线即散场。解决建立监控 → 分析 → 决策 → 修复 → 验证的闭环明确漏洞评估时效比如可利用性高的漏洞一周内出结论、一个月内出修复计划并把这条写进运维 SLA。4.6 生产环节没有任何网络安全控制点现象密钥烧录、软件刷写的产线操作没有审计日志关键参数变更没有审批记录。原因条款 12 被当成制造部门的事研发和网络安全团队从没去过产线。解决把产线网络安全控制点写进控制计划每个控制点要有检验标准、责任人、操作记录并安排季度产线审计。审核员很吃这一套因为大部分公司做不到。5. 对接法规与客户把 21434 建成合规矩阵21434 本身是自愿性标准但它的条款几乎都对应着强制法规的落地要求。把标准条款和法规条目做成一张合规矩阵是应付外部审核和客户问询最省力的方式。5.1 UN R155 七类攻击场景与 21434 的映射表UN R155 是法规层面的强制要求整车厂要有 CSMS 证书并且能证明车型的网络安全能力过关才能获得型式认证。欧盟从 2022 年 7 月起对新车型实施、随后逐步扩展到全部在产车型。R155 附件里列了七类攻击场景做合规矩阵时可以直接拿它们当覆盖面检查表R155 攻击场景主要对应条款落地动作后端服务器相关5 / 8 / 10云平台安全基线、接口认证与监控通信通道相关9 / 10车载与外部通信的加密、双向认证软件更新相关9 / 10 / 13OTA 全链路签名校验、回滚机制人员误操作相关5 / 6访问控制、职责分离、操作审计外部连接相关9 / 10诊断口、USB、蓝牙等接口的攻击面收敛数据与代码相关恶意代码10 / 11代码签名、可信启动、完整性校验数据被篡改或丢失10 / 13完整性保护、备份恢复、异常检测这张映射表的用法是查覆盖率每一类攻击场景至少要对应一条 TARA 记录、一个网络安全目标和一份验证证据。整车厂做自评估时沿着这七行往下核对比逐条读标准效率高得多。Tier 1 也可以拿它对照自己负责的组件确认客户问到的攻击场景都落在自己的风险分析范围内。5.2 GB 44495-2024 的对接点强标拆成测试项再反查 TARA国内这边GB 44495-2024《汽车整车信息安全技术要求》是走向强制性监管的标志。它在总体框架上和 UN R155 对齐要求整车具备防入侵、防篡改、数据保护、安全启动、远程升级安全等能力。对一线团队来说21434 解决怎么做强标解决做成什么样两者不是二选一是一条链路的两端。我建议把强标的条款逐条拆成可验证的测试项做成一张测试项清单然后反查 TARA 和安全需求文档这个测试项对应的威胁场景在哪条 TARA 里对应的网络安全目标有没有落到需求上对应验证报告有没有结论这套反查做下来你会发现强标覆盖面和 TARA 覆盖面之间有缺口通常是诊断、蓝牙、USB 这类历史遗留接口这些恰恰是审核和黑客都爱光顾的地方。5.3 采购合同里的网络安全接口需求、交付物、审核权、SLA 四条供应链上的网络安全责任条款 7 和 R155 都要求传递并验证。落到合同上我一般会加四条缺一不可第一需求来源。写明供应商需要遵守的安全基线来自哪份文件比如遵循 ISO/SAE 21434并满足附件 A 中 20 条安全需求。第二交付物清单。明确供应商必须交付的网络安全工作产物通常包括 TARA 摘要、安全设计说明、验证报告和已知漏洞清单。第三审核权。约定客户有权在项目节点和量产前进行网络安全审核供应商要开放相关文档和产线检查。第四SLA。约定漏洞响应时限例如严重漏洞 72 小时内出初步结论、两周内给出修复计划。这四条写进合同之后供应商的行为会明显不一样。没有合同约束时安全需求经常被当成建议有了条款和验收挂钩供应商才会把安全排进真正的计划里。这也是很多整车厂审核员第一个追问供应商的问题你的上游合同里有没有安全条款6. 验证体系是不是真落地从纸面合规到扛得住外审的三条自查路径纸面合规和真落地的差别外审一次就能验出来。我常用的自查方法有三条每季度做一次每次半天到一天。第一条差距分析打分。拿附录 B 的工作产物清单当基准给每个产物按 0、1、2 打分0 是没有1 是有但证据不完整2 是完整且可追溯。打完分按条款分组统计低于 80% 的条款就是下个季度的整改重点。这个打分表也是外审前的自评估底稿审核员问起来可以直接展示。第二条反向追溯抽查。随机挑三个网络安全目标从目标出发往下追对应需求有没有设计里有没有对应措施测试用例有没有覆盖验证结论是什么再往上追这个目标对应的威胁场景风险值是多少为什么定这个 CAL一条链走下来任何一环断了都能立刻暴露体系里的真实空洞。我习惯每季度抽一次每次都能发现一两处断链大部分是需求变更后没有同步更新追溯关系。第三条模拟外审提问。把审核员最喜欢问的问题列成清单自己当被审方回答一遍。最典型的三问是你的 TARA 里 CAL 3 的目标证据链在哪上市后的漏洞响应 SLA 执行得怎么样供应商的网络安全要求怎么验收的这三个问题能答得上来体系基本就立住了答不上来的地方就是下次整改的入口。我的习惯是每次自查后写一份一页纸的差距清单发给项目负责人而不是只发给安全团队因为大多数断链要研发、测试、生产配合才能补。这个习惯帮我保住了不止一次外部审核也让安全团队从一个挑刺的部门变成了项目愿意配合的伙伴。验证体系这件事做得越频繁外审越轻松——希望帮到你。本文还有配套的精品资源点击获取 ISO SAE 21434中文版落地指南：从TARA到工作产物的实施要点
简介《ISO/SAE 21434:2021 道路车辆——网络安全工程》中文版是一份面向汽车电子电气系统研发团队、功能安全与网络安全工程师、自动驾驶与车联网安全从业者的完整标准译文。相比英文原版中文版消除了语言障碍便于在国内研发、审核与合规评估中直接引用适合作为整车厂与零部件供应商实施车辆网络安全管理体系的基础参考文件。压缩包共 1 个 PDF 文件整体约 1.46MB轻量便于下载与分发。文件完整收录标准正文涵盖组织网络安全管理、项目依赖的网络安全管理、分布式网络安全活动、持续的网络安全活动、概念阶段、产品开发、网络安全验证、生产、操作与维护、网络安全支持和退役以及威胁分析和风险评估方法TARA等第 4~15 条核心内容并保留条款与工作产品的唯一标识符方便对照检索。目前已有 3125 人次学习下载。对需要建立车辆网络安全流程、完成供应商安全对接或落实 WP.29 R155 合规要求的从业者这份中文版能直接提供完整的标准依据与工程要求清单。1. 为什么 ISO SAE 21434 中文版成了智能网联汽车团队的必读材料智能网联汽车的项目评审会上这两年几乎每次都会有人问这条按 21434 怎么过。ISO SAE 21434-2021 是道路车辆网络安全工程的第一份国际标准它把过去靠个人经验输出的安全工作变成了一套从组织管理到产品退役的工程流程。对整车厂、Tier 1 和做域控制器、T-Box、网关的团队来说这份中文版 PDF 解决三件事给研发流程补一套可审计的网络安全骨架给客户交付一份合规证据给法规强制备案一张底牌。它适合谁读网络安全工程师拿它定流程嵌入式与测试拿它找输出物项目经理拿它排计划供应商质量拿它写合同。拿到手别从头翻先抓条款编号和附录清单——这份标准的查法比读法重要。2. 先读骨架把条款 514 拆成五张地图中文版从哪里开始查拿到中文版 PDF最常见的姿势是从第一页开始翻翻到 TARA 那章就卡住。这个标准不是按阅读顺序写的它是按审计顺序写的。我建议先看目录把条款 5 到 14 按职能画成五块组织级管理、项目级管理、分布式活动、持续活动、产品生命周期工程。这五块正好对应外界评审时五个方向也是建体系时五个责任区。这样拆完你会立刻发现21434 和 ISO 26262 的框架同源都讲究组织有方针、项目有计划、过程有输出、证据可追溯。但 21434 多出两条 26262 不太强调的线一条是供应链上下游的网络安全责任传递一条是车型上市后的持续监控与漏洞管理。这两条恰恰是国内团队最容易忽略、也最容易被外审抓住短板的区域。2.1 条款 57组织级、项目级与分布式活动CSMS 是地基条款 5 是组织级网络安全管理核心是 CSMS也就是网络安全管理体系。它要求的不是某一个项目的产出而是公司层面要有网络安全方针、角色与责任、人员能力、意识培训、过程改进和信息共享机制。翻译成落地动作你要有明确的安全负责人和一张责任矩阵要有培训记录要有工具链管理办法还要有持续改进的证据。这部分在国内企业里最容易被跳过因为它不直接对应产品功能老板看不到功能点。但外部审核第一次看的就是条款 5组织层面要是空的后面项目文档再全审核员也可以直接判定体系不成立。我见过一家 Tier 1 项目材料做得很漂亮却拿不出公司层级的网络安全方针和年度培训计划最终审核结论直接降级。所以别把条款 5 当成放文件夹的公共部分它是整个体系能不能站住的底座。条款 6 是项目级网络安全管理讲的是每个项目怎么做计划。包括网络安全活动在项目计划里的排布、工作产物清单、里程碑、角色分配以及标准里 cybersecurity case网络安全案例的逐步积累。条款 7 是分布式网络安全活动通俗讲就是供应链接口外包给供应商的软硬件、云服务、工具链网络安全责任怎么划分、需求怎么传递、验收怎么闭环。对 Tier 1 来说这一条决定了你从整车厂拿到的规格书里会附带多少条安全需求也决定你转包给二级供应商时必须传递哪些约束。实操建议是先按条款 5 的条目做一次差距分析把不满足的项列一张表再按条款 6 挑一个正在进行的量产项目做项目网络安全计划。不用贪多一个试点项目完整跑通比十个项目各写三张纸有用得多。2.2 条款 813概念、开发、验证、生产、运维的工程主线条款 8 到 13 是标准的工程主干对应产品从立项到退役的完整生命周期。建议按六个阶段读每个阶段抓活动 输出物两件事阶段条款关键活动主要输出持续活动8网络安全监控、漏洞分析、漏洞管理监控计划、漏洞评估记录、处置决策概念阶段9项目定义、TARA、网络安全目标、网络安全概念TARA 报告、目标清单、概念文档产品开发10需求拆解、架构设计、软硬件实现、集成验证安全需求规格、设计文档、验证记录网络安全验证11在整车/系统层面确认风险被有效消减验证报告、网络安全案例生产12产线安全控制、一致性检查、追溯生产控制计划、产线审计记录运维与退役13运行监控、OTA 安全更新、退役数据擦除运维计划、事件响应记录这里要特别提醒两个词的区别条款 10 里的 verification 是需求实现了没有条款 11 的 cybersecurity validation 是实现之后风险降低了没有。很多团队在这两个词上栽过跟头把单元测试报告当验证报告交了外审问起来才发现少了整车层面的风险确认证据。另外一个容易被忽略的是条款 12 生产环节。产线上的密钥烧录、软件签名、配置数据防篡改都要有控制点和追溯记录。传统车厂里生产部门默认这是研发的事研发又以为产线自己会管最后两边都没有证据。这部分在审核里属于必查项因为攻击者往往比研发更容易接触产线。2.3 条款 14 与附录 A/BTARA 方法和工作产物中文版怎么查最快条款 14 定义了 TARA 方法本身的输入、输出和迭代步骤附录 A 给了 TARA 方法的实例附录 B 是各条款对应的工作产物清单。这份标准查法有点特殊它不像 ISO 26262 那样按 ASIL 给你一张该做什么活动的裁剪表而是把做到多深的责任交给企业自己标准只给约束和产出要求。所以实战中中文版 PDF 最常用的两处就是附录 B 和条款 14。审厂和客户审计时审核员基本都拿着这两处展开要证据。用中文版的时候建议和英文原版对照着查条款编号一致遇到翻译分歧时能快速确认原意。比如英文术语中文版常见译法备注item项目 / 条目 / 对象物指被研究的整车、系统或组件别和 project 混淆cybersecurity goal网络安全目标TARA 的直接输出TARA威胁分析与风险评估条款 14 的方法学attack feasibility攻击可行性评估攻击难度CAL网络安全保证等级 / 保障等级四个级别详见第 3 章work product工作产物附录 B 清单CSMS网络安全管理体系条款 5 的核心概念提示中文翻译里最容易造成误解的是 item。有的版本译成项目读的时候会跟项目管理混在一起。建议团队内部统一叫被评估对象并在文档里保留英文原文。3. 落地最小流程集从 TARA 到工作产物的可抄作业模板读完了条款地图接下来就是把它变成每周能执行的动作。我经过两个完整项目后沉淀下来一套最小流程集一次 TARA、一张 CAL 分档表、一套按阶段交的产物清单。这套东西不大但能覆盖外审 80% 的检查点。3.1 用 TARA 把风险讲清楚资产识别、攻击路径与风险值的打分规则TARA 是 21434 里唯一给了详细方法定义的工程活动也是外审必查的第一个技术文档。一份能通过评审的 TARA 记录表至少包含下面这些字段字段含义容易写歪的地方资产要保护的对象数据、功能、属性写成CAN 总线而不是制动指令的完整性威胁场景攻击者通过某路径造成损害的描述写得太抽象不可验证攻击路径从入口到资产的完整链路漏掉物理接触类入口影响对人身安全、财务、运营、隐私的影响只写严重没有分级依据攻击可行性攻击需要的时间、技能、知识、设备、机会窗口凭感觉打分没有统一尺度风险值影响 × 攻击可行性的综合评定高低判据不一致网络安全目标针对风险值提出的消减目标直接写成具体方案缓解措施达成目标的手段放网络安全概念里在 TARA 里写太细过早设计实操步骤我一般这么走第一步圈定对象item 可以是整车、域控制器、网关也可以是一个软件组件第二步列资产并给每个资产标安全属性常见的是机密性、完整性、真实性、可用性第三步枚举威胁场景这里不要从攻击树反推要从这个部件被拿到攻击者手里最可能的入口在哪出发。打分时我会建一张评分细则表影响和攻击可行性各按 1 到 4 分打分然后组合成风险矩阵。附录 A 给了 EVITA、HEAVENS 等方法的思路常见做法是自建一套简化版关键是所有条目用同一把尺子。审核员最在意的不是你的分数准不准而是评分标准的一致性以及这条为什么接受、那条为什么不接受的可追溯逻辑。风险值的输出是排序不是绝对真理这一点想通了TARA 就不难。3.2 从风险值到网络安全目标CAL 分档与需求推导链TARA 输出了风险值和网络安全目标之后下一步是给目标分配 CAL。CAL 有四个级别中文版通常叫网络安全保证等级或保障等级。它描述的是为了达成这个目标需要多强的保证活动而不是目标本身有多重要。这一点经常被搞反有人把 CAL 当风险等级标在需求上其实它是用来决定评审深度和验证强度的。CAL适用场景典型保证活动CAL 1低风险、不涉及核心资产常规设计评审、自测CAL 2中低风险、攻击面有限增加架构评审、对抗措施分析CAL 3高风险、涉及安全或核心数据独立评审、系统化验证证据CAL 4极高风险、攻击后果严重更严格的证据链、必要时形式化方法完整的推导链路是威胁场景 → 风险值 → 网络安全目标 → CAL → 网络安全需求 → 设计实现 → 验证确认。每个目标都要能在这条链路上找到自己的位置。我习惯在需求管理工具里给每条安全需求挂两个属性来源目标编号和 CAL 等级这样审核时输入目标编号能一键拉出全部相关需求。这里有个高频误区把 CAL 当 ASIL 用试图建立两者之间的固定映射。21434 明确没有这种对应关系CAL 从风险值来ASIL 从危害分析来。实践中两个体系各评各的只在文档里互相引用。比如一个远程控制功能功能安全上可能是 ASIL B但网络安全上因为攻击面大、可达性高CAL 可能定到 3两者不必相等也不能互相替代。3.3 四类必交工作产物概念、开发、验证、运维各交什么附录 B 的工作产物清单很长全做完会把人吓退。我按外审重点收敛成四类每个阶段交什么、里面有什么提前定死阶段必交产物核心内容概念TARA 报告、网络安全目标、网络安全概念风险分析结论、目标清单、初步架构级措施开发安全需求规格、设计说明、验证记录需求到设计的追溯、测试用例与结果验证网络安全验证报告整车/系统层面的风险消减确认、残余风险说明运维监控与响应计划、漏洞管理记录情报来源、SLA、事件升级链路、漏洞处置台账这四类产物是项目级的最小集合也是外审看证据时的主入口。注意每一类都要有版本和签审记录没有受控的文档在审核里等于不存在。另外产物之间要能互相追溯从网络安全目标能查到对应需求从需求能查到验证用例从验证用例能追回目标。断一环整条证据链就不成立。提示项目开始时就把这几类产物的模板定下来哪怕内容是空的。后期补文档是最痛苦的因为细节早就忘了补出来的东西审核员一眼就能看出来是补的。4. 实施 21434 的避坑指南六个翻车现场与血泪拆解下面六条是我在项目里真实踩过、也看同行反复踩的坑。每条按现象、原因、解决三段写留着排查问题用。4.1 TARA 做成了安全测试用例列表现象TARA 报告里全是通信要加密要做模糊测试这类对抗措施描述翻完整份文档看不到威胁场景和攻击路径。原因团队把 TARA 和安全方案混在一起跳过了风险分析直接写对策觉得反正都要做。解决TARA 记录表先只写威胁场景、影响、攻击可行性、风险值任何解决方案都不许写进去对抗措施放进网络安全概念文档。评审时先要求删掉方案再评逼着把风险分析补上。4.2 把 CAL 当 ASIL 用直接套映射表现象项目计划里写CAL 3 等同 ASIL C活动裁剪完全照搬功能安全那套。原因团队刚从 ISO 26262 项目转过来顺手把经验平移了。解决CAL 从风险值推导ASIL 从危害推导两边独立评定但互相引用。给每个 CAL 等级写一份活动定义表说清楚这一级要做哪些评审、哪些验证别用 ASIL 的裁剪逻辑替代。4.3 供应商合同里的网络安全接口留空现象和供应商签的技术协议里只有功能、质量和交期没提安全需求开发中安全需求变更只能在邮件里流转最后验收对不上。原因采购阶段没有网络安全工程师参与合同模板里也没有对应条款。解决在采购合同或技术协议里增加网络安全章节至少包含需求来源、交付物清单、审核权、变更流程和验收标准另外加一条供应商漏洞响应的承诺时限。4.4 文档版本失控审核时对不上现象TARA 更新了两版网络安全目标文档还是旧版审核现场到处找哪个是最新版。原因文档没有走配置管理项目计划里的版本基线没有跟着变更走。解决把网络安全工作产物纳入现有配置管理库和受控软件用同一套规则任何版本变更必须带变更记录并在项目网络安全计划里登记。4.5 漏洞管理只管开发、不管上市后现象车型上市后漏洞没人牵头管安全事件发生两三天才有人响应客户投诉了才复盘。原因条款 8 和条款 13 被忽略团队只做了开发期的活动上线即散场。解决建立监控 → 分析 → 决策 → 修复 → 验证的闭环明确漏洞评估时效比如可利用性高的漏洞一周内出结论、一个月内出修复计划并把这条写进运维 SLA。4.6 生产环节没有任何网络安全控制点现象密钥烧录、软件刷写的产线操作没有审计日志关键参数变更没有审批记录。原因条款 12 被当成制造部门的事研发和网络安全团队从没去过产线。解决把产线网络安全控制点写进控制计划每个控制点要有检验标准、责任人、操作记录并安排季度产线审计。审核员很吃这一套因为大部分公司做不到。5. 对接法规与客户把 21434 建成合规矩阵21434 本身是自愿性标准但它的条款几乎都对应着强制法规的落地要求。把标准条款和法规条目做成一张合规矩阵是应付外部审核和客户问询最省力的方式。5.1 UN R155 七类攻击场景与 21434 的映射表UN R155 是法规层面的强制要求整车厂要有 CSMS 证书并且能证明车型的网络安全能力过关才能获得型式认证。欧盟从 2022 年 7 月起对新车型实施、随后逐步扩展到全部在产车型。R155 附件里列了七类攻击场景做合规矩阵时可以直接拿它们当覆盖面检查表R155 攻击场景主要对应条款落地动作后端服务器相关5 / 8 / 10云平台安全基线、接口认证与监控通信通道相关9 / 10车载与外部通信的加密、双向认证软件更新相关9 / 10 / 13OTA 全链路签名校验、回滚机制人员误操作相关5 / 6访问控制、职责分离、操作审计外部连接相关9 / 10诊断口、USB、蓝牙等接口的攻击面收敛数据与代码相关恶意代码10 / 11代码签名、可信启动、完整性校验数据被篡改或丢失10 / 13完整性保护、备份恢复、异常检测这张映射表的用法是查覆盖率每一类攻击场景至少要对应一条 TARA 记录、一个网络安全目标和一份验证证据。整车厂做自评估时沿着这七行往下核对比逐条读标准效率高得多。Tier 1 也可以拿它对照自己负责的组件确认客户问到的攻击场景都落在自己的风险分析范围内。5.2 GB 44495-2024 的对接点强标拆成测试项再反查 TARA国内这边GB 44495-2024《汽车整车信息安全技术要求》是走向强制性监管的标志。它在总体框架上和 UN R155 对齐要求整车具备防入侵、防篡改、数据保护、安全启动、远程升级安全等能力。对一线团队来说21434 解决怎么做强标解决做成什么样两者不是二选一是一条链路的两端。我建议把强标的条款逐条拆成可验证的测试项做成一张测试项清单然后反查 TARA 和安全需求文档这个测试项对应的威胁场景在哪条 TARA 里对应的网络安全目标有没有落到需求上对应验证报告有没有结论这套反查做下来你会发现强标覆盖面和 TARA 覆盖面之间有缺口通常是诊断、蓝牙、USB 这类历史遗留接口这些恰恰是审核和黑客都爱光顾的地方。5.3 采购合同里的网络安全接口需求、交付物、审核权、SLA 四条供应链上的网络安全责任条款 7 和 R155 都要求传递并验证。落到合同上我一般会加四条缺一不可第一需求来源。写明供应商需要遵守的安全基线来自哪份文件比如遵循 ISO/SAE 21434并满足附件 A 中 20 条安全需求。第二交付物清单。明确供应商必须交付的网络安全工作产物通常包括 TARA 摘要、安全设计说明、验证报告和已知漏洞清单。第三审核权。约定客户有权在项目节点和量产前进行网络安全审核供应商要开放相关文档和产线检查。第四SLA。约定漏洞响应时限例如严重漏洞 72 小时内出初步结论、两周内给出修复计划。这四条写进合同之后供应商的行为会明显不一样。没有合同约束时安全需求经常被当成建议有了条款和验收挂钩供应商才会把安全排进真正的计划里。这也是很多整车厂审核员第一个追问供应商的问题你的上游合同里有没有安全条款6. 验证体系是不是真落地从纸面合规到扛得住外审的三条自查路径纸面合规和真落地的差别外审一次就能验出来。我常用的自查方法有三条每季度做一次每次半天到一天。第一条差距分析打分。拿附录 B 的工作产物清单当基准给每个产物按 0、1、2 打分0 是没有1 是有但证据不完整2 是完整且可追溯。打完分按条款分组统计低于 80% 的条款就是下个季度的整改重点。这个打分表也是外审前的自评估底稿审核员问起来可以直接展示。第二条反向追溯抽查。随机挑三个网络安全目标从目标出发往下追对应需求有没有设计里有没有对应措施测试用例有没有覆盖验证结论是什么再往上追这个目标对应的威胁场景风险值是多少为什么定这个 CAL一条链走下来任何一环断了都能立刻暴露体系里的真实空洞。我习惯每季度抽一次每次都能发现一两处断链大部分是需求变更后没有同步更新追溯关系。第三条模拟外审提问。把审核员最喜欢问的问题列成清单自己当被审方回答一遍。最典型的三问是你的 TARA 里 CAL 3 的目标证据链在哪上市后的漏洞响应 SLA 执行得怎么样供应商的网络安全要求怎么验收的这三个问题能答得上来体系基本就立住了答不上来的地方就是下次整改的入口。我的习惯是每次自查后写一份一页纸的差距清单发给项目负责人而不是只发给安全团队因为大多数断链要研发、测试、生产配合才能补。这个习惯帮我保住了不止一次外部审核也让安全团队从一个挑刺的部门变成了项目愿意配合的伙伴。验证体系这件事做得越频繁外审越轻松——希望帮到你。本文还有配套的精品资源点击获取