简介：ISO/SAE 21434（道路车辆—网络安全工程）国际标准草案，由国际标准化组织与美国汽车工程师学会联合制定，面向汽车制造商、供应链参与者和网络安全研究人员，为车辆全生命周期的信息安全风险管理提供统一框架。资源为1个PDF文件，大小3.19MB，内容为官方草案原文，包含范围、规范性引用、术语定义等核心章节，可辅助理解汽车网络安全风险管理、威胁分析、安全需求定义及供应链安全等要点，并涵盖组织级治理、项目开发中的网络安全活动以及生产运营阶段的持续监控。该草案曾于2020年2月至5月征询意见，最终版可能有所调整，阅读时需注意其草案属性，正文中个别文字可能因OCR识别存在误差。目前已有391人学习下载，适合作为汽车信息安全领域的研究参考资料。
1. ISO/SAE 21434不是一份设计手册：它逼你把安全做成流程
两年前我给某公司的网关项目做技术支持，安全链路设计花了三个月，评审会上对方信息安全负责人只问了一句：“这条通信链路的TARA记录在哪？”那一刻我才意识到，单纯把密码学方案做扎实，并不等于满足ISO/SAE 21434。ISO/SAE 21434（Road vehicles — Cybersecurity engineering）是汽车行业网络安全工程的一项国际标准，它不规定你必须用哪家的HSM、要不要上防火墙，而是要求你从概念阶段到退役，把威胁分析、风险评估、处置决策和验证证据组织成一套能追溯的流程。它的作用对象不是某一颗芯片，而是整个组织。电子电气工程师、TARA分析员、架构师、网络安全经理，以及给主机厂供货的供应商团队，都能在这条流程里找到自己被考核的位置。这篇笔记从落地角度讲：三个地基概念、一套TARA模板、三组必调参数，以及五类常见翻车现场。
2. 先分清CSMS、TARA、CIA：ISO/SAE 21434落地的三块地基
第一次翻开标准的正文，很容易被抽象名词劝退。CSMS、TARA、CAL、攻击潜力、网络安全属性、损害场景、威胁场景——看起来是一堆黑话，实际只围绕三个地基：组织层面要有什么管理体系，项目层面要做什么分析，分析里到底拿什么属性当尺子。这三块地基搞混，后面所有文档都会变形。
2.1 一个误区：把CSMS当成了安全产品开发计划
CSMS全称是Cybersecurity Management System，直译是网络安全管理体系。我见过不少团队的做法，是把它理解成“我们的安全网关产品开发计划”，写上几页安全功能规划，加一张流程图，就当CSMS交付了。这是最典型的走偏。
CSMS对标的是组织层面，不是产品层面。它回答的问题不是“这个ECU怎么做安全启动”，而是“这家公司有没有一套持续的机制，保证每个项目都能按同样的尺度做威胁分析、分配风险等级、留出验证证据”。说得直白一点，类似于功能安全里的质量管理体系，但聚焦在网络安全。
至少需要覆盖十个方面：网络安全治理与策略、角色与职责、人员能力、TARA方法论、风险评估准则、开发流程集成、验证活动要求、事件响应流程、供应链网络安全要求、持续改进机制。实际操作中，我建议先做一个自查清单，按“有文件模板 / 有执行记录 / 有评审签字”三档打勾，而不是一上来就写几百页手册。
提示：CSMS写得再漂亮，只要没有一份带签字的评审记录，审计师不会认。流程证据的口径永远优先于文档厚度。
2.2 TARA在哪里发生：生命周期中的位置与输入输出
TARA全称Threat Analysis and Risk Assessment，威胁分析与风险评估。它是ISO/SAE 21434里最核心的分析活动，位置在概念阶段和产品开发早期，但并不是做一次就结束。我在实际项目里，一般会放在系统需求冻结前后各跑一轮，后续每次设计变更、新增外部接口、引入新通信协议，都要回到TARA做增量更新。
TARA的输入和输出可以整理成一张表：
| 活动阶段 | 主要输入 | 主要输出 |
|---|---|---|
| 概念阶段 | 系统边界、资产清单、已知对手能力、业务场景 | 网络安全属性、损害场景、风险等级排序 |
| 产品开发 | TARA结果、架构设计、通信矩阵、漏洞情报 | 网络安全目标、网络安全概念、CAL等级 |
| 验证阶段 | 安全需求、测试计划、渗透测试发现 | 风险复评结论、残余风险清单、验证证据 |
从这张表能看出，TARA不是一份“安全报告”，而是一个持续更新的决策引擎。它把风险信息转成两条下游链条：一条是网络安全目标和CAL等级，驱动正向安全开发；另一条是残余风险和复评记录，驱动审计证据链。
2.3 CIA之外：网络安全属性为什么不是三选一
很多工程师习惯了信息安全里的CIA三要素：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）。但在ISO/SAE 21434语境下，网络安全属性不只有这三个，还可能包括真实性、授权、不可否认性和可更新性。到底选哪些，不是凭个人偏好拍脑袋，而是看损害场景怎么定义。
汽车场景里，完整性往往比机密性优先级更高。我可以给出一个常用判断角度：篡改一条转向控制报文可能直接造成人身伤害，而窃听一条位置信息通常只会带来隐私风险。所以在做商用车车队管理系统时，我把完整性、真实性和授权列为必须分析的属性，机密性只在涉及用户个人数据或高价值密钥时排进前列。
选错了属性会让整个TARA白做。比如某个远程诊断功能，把所有精力放在防窃听上，结果真正出事的是诊断指令被伪造重放，那安全目标连靶心都没对准。建议在属性清单里加一列“该属性失效后造成的最坏后果”，拿后果去校验属性选择是否完整。
3. 从差距分析到TARA模板：把21434条款变成每天要做的事
标准的正文条款划分很细，直接照着条款逐条做容易把人劝退。更务实的路线是先做一次差距分析，圈出现在的能力缺口，再搭一套最小的日常动作：谁在什么阶段做什么分析，用什么模板记录，输出交给谁。把这个顺序倒过来，大概率会陷入“文档很多、证据链仍然断着”的窘境。
3.1 第一步永远是差距分析：用自查表摸清家底
差距分析的目的是回答一个问题：如果明天审计上门，我们哪些东西能当场拿出证据，哪些只有口头承诺？我习惯把自查范围分成五个域：组织治理、项目流程、TARA方法、验证活动、供应链管理。
| 自查域 | 常见缺口表现 | 建议处置 |
|---|---|---|
| 组织治理 | 没有网络安全策略、没有指定网络安全经理 | 先定负责人和年度目标 |
| 项目流程 | V模型各阶段没有安全活动入口 | 在阶段评审里增加安全条件 |
| TARA方法 | 没人能说清怎么评估风险等级 | 定义简化评级表并试点跑通 |
| 验证活动 | 安全需求没有对应测试项 | 给每条安全目标绑定测试用例 |
| 供应链管理 | 供应商只收到需求清单 | 补充问卷、证据评审和准入条件 |
做完自查表，我建议不要一次性铺开全部项目。选一个规模中等、带有外部通信接口、团队里有人懂安全的项目当试点。试点目标只有一个：把TARA到安全目标到测试验证这条主链条跑通。跑通之后，其他项目照葫芦画瓢，比拿着条款硬套快得多。
3.2 谁来写：角色、职责与能力矩阵的常见落法
很多中小型团队卡在责任分配上：标准要求有人负责网络安全治理，有人做TARA，有人做验证，但公司总共只有三五个工程师。我的经验是，不追求一人一岗，但必须保证每个关键活动有明确Owner，且Owner的能力边界被写清楚。
典型角色可以这样分配：
- 网络安全经理：管CSMS、定风险接受权限、审核CAL分配。
- TARA分析员：做威胁场景识别、攻击路径分析、风险评级。
- 项目安全工程师：把网络安全目标转成系统需求，跟踪实现。
- 验证工程师：设计安全测试用例，执行渗透测试和模糊测试。
- 事件响应协调员：处理售后和路试中发现的安全事件，反向更新TARA。
在一个人同时承担多个角色的情况下，容易出的问题是“既是运动员又是裁判员”。我一般建议TARA分析的评审由不直接参与该项目的人来做，哪怕这个人是临时借调的。哪怕只有一个人能审核，也比没人审核强，因为审计师看的不是人数，是制衡关系有没有被定义。
RACI简表也可以在这一步顺手建出来。对于“TARA产出”这项活动，TARA分析员是R和A，项目安全工程师是C，网络安全经理是I；对于“CAL等级批准”，网络安全经理是A，TARA分析员是C。表建好后贴在项目看板上，比写进几十页流程文件实用得多。
3.3 一个最小TARA实践模板：从损害场景到网络安全目标
TARA没有官方强制表格，各家公司做法差别不小。下面这套字段是我多次调整后沉淀下来的最小可用模板，适合第一次落地时使用。核心思路是让每一行都能回答一个问题：这个资产，如果被攻击，会造成什么损害，风险有多大，我们打算怎么做，做到什么程度算完。
模板字段如下：
| 字段 | 填写说明 | 是否必填 |
|---|---|---|
| 资产ID | 资产唯一编号，关联系统架构图 | 必填 |
| 资产描述 | 这个资产是ECU、报文、服务还是密钥 | 必填 |
| 网络安全属性 | 完整性、真实性、授权、可用性等 | 必填 |
| 损害场景 | 攻击成功会造成什么车辆、人员、商业后果 | 必填 |
| 威胁场景 | 谁在什么条件下发起什么动作 | 必填 |
| 攻击路径 | 从攻击入口到资产的调用链 | 必填 |
| 攻击潜力评级 | 低、中、高或具体数值 | 建议 |
| 影响评级 | 按安全、隐私、金融、运营四个维度打分 | 必填 |
| 风险值 | 可能性乘影响得到的排序值 | 必填 |
| 处置决定 | 降低、避免、转移、接受 | 必填 |
| 网络安全目标ID | 对应的一条或多条安全目标 | 必填 |
| CAL等级 | 目标对应的保证等级 | 建议 |
| 验证证据链接 | 测试用例编号、报告路径 | 必填 |
有一个细节值得多说一句：证据链接字段不能空。哪怕写的是“待补充”，也要有一个可以被追踪的下文。我见过太多TARA表里写得密密麻麻，唯独证据链接空着，看起来完整，审计一抽就断了。
4. CAL、攻击潜力与风险接受准则：落地必须设对的三组参数
TARA模板搭起来之后，真正的分水岭在参数设定。CAL怎么定、攻击潜力怎么量化、什么样的残余风险可以被接受，这三组参数直接决定后续开发成本和安全投入的边界。设得太松，审计不认；设得太紧，团队会被验证工作量拖垮。这个平衡，是ISO/SAE 21434落地中最需要经验的地方。
4.1 CAL和风险评估如何互相推导
CAL全称Cybersecurity Assurance Level，网络安全保证等级。它的作用和功能安全里的ASIL类似，用来表达“这个安全目标需要做多少保证活动”。区别在于，ASIL主要从危害的严重性、暴露率和可控性推导，CAL则更贴近威胁分析和风险处置结论。
在标准语境里，CAL1到CAL4四个等级并不直接等于风险数值，但常见做法是先算出风险等级，再映射到某个CAL。下面给一个简化示例矩阵，它代表一种常见的映射方式，但每个组织都应该在CSMS里定义自己的版本，并经过评审后固化下来：
| 可能性 \ 影响 | 低影响 | 中影响 | 高影响 |
|---|---|---|---|
| 低可能性 | CAL1 | CAL2 | CAL2 |
| 中可能性 | CAL2 | CAL3 | CAL3 |
| 高可能性 | CAL3 | CAL4 | CAL4 |
这里有个很容易踩的误区：CAL4是不是一定对应最高风险？不一定。风险值高意味着需要更强的处置，但“处置”可能是架构上彻底去掉攻击面，也可能是通过降级设计把风险压到可接受区间。CAL本身回答的是“保证活动的强度”，不是“风险大小”。如果架构设计把攻击面消除了，可能不需要很高的CAL，这就是为什么很多安全设计采用“隔离加白名单”而不是“加密加证书”的原因——前者能从根上降低风险。
4.2 攻击潜力（attack potential）数值表：量化“破解难度”的争议
攻击潜力是一个源于安全评估领域的量化概念，用来衡量攻击者需要具备多少资源才能成功利用某个漏洞或攻击路径。ISO/SAE 21434中把它作为可能性评级的一种方法。实际使用中，这是最容易陷入“玄学”争论的地方。
常见的攻击潜力评估因素包括：攻击经过的时间、攻击者的专业知识水平、攻击者对目标的了解程度、接触目标的机会窗口、所需的软硬件设备等级、样本数量等。为了便于落地，我一般会做一张简化评分表，每个因素分为低、中、高三档给予权重：
| 因素 | 低 | 中 | 高 |
|---|---|---|---|
| 经过时间 | 小于一周 | 一周到一个月 | 超过一个月 |
| 专业知识 | 门外汉 | 领域专家 | 多个领域专家协作 |
| 对目标了解 | 公开资料 | 内部文档泄露 | 完全掌握源码 |
| 接触机会 | 远程受限访问 | 远程不受限访问 | 物理接触设备 |
| 设备资源 | 普通电脑 | 专用调试设备 | 实验室级设备 |
| 样本数量 | 无样本 | 少量样本 | 大量或源代码 |
评分时把各因素相加，超过阈值的攻击路径被评估为“攻击潜力高”，对应较高可能性。但这里必须说明：这张表的数值仅用于排序，绝对值并不神圣。一个攻击路径到底算高还是低，本质上依赖靶场和渗透测试结果来校准。
我处理过的项目里，抄通用标准里的固定数值会导致两个极端：一是把攻击潜力普遍评高，所有风险都压到最高等级，开发资源爆炸；二是拍脑袋评低，审计时被挑战。折中的做法是先按这张简化表跑一个季度，积累两三轮渗透测试数据后，再把阈值修正到自己的产品形态上。攻击潜力数字在内部的价值是让团队争论时有共同标尺，而不是给出一个绝对真理。
提示：与其争论某个数值精不精确，不如确认评级过程有没有记录假设条件。审计师更关心你凭什么这么评，而不是评出的这个数。
4.3 风险接受准则：写不写和怎么写差别很大
风险接受准则是CSMS里被轻视但极其关键的内容。它规定了组织在什么条件下可以接受残余风险。没有这个准则，每次TARA评审都会陷入无休止的讨价还价。
常见的处置方式有四种：
| 处置方式 | 含义 | 适用场景 |
|---|---|---|
| 风险降低 | 通过安全设计减少可能性或影响 | 大多数TARA输出 |
| 风险避免 | 删除功能或取消攻击面 | 成本远大于收益时 |
| 风险转移 | 转嫁给保险或供应链伙伴 | 商业场景为主 |
| 风险接受 | 明文批准残余风险 | 低影响且低可能性 |
风险接受准则写得太空，等于没写。例如“所有残余风险应尽可能降低”这句话，审计时根本无法作为判断依据。我建议至少写出两层口径：一层是量化阈值，比如“可能性为低且影响为中及以下时可接受”；另一层是审批权限，比如“CAL3以上残余风险必须由网络安全经理书面批准，CAL4必须由最高管理层批准”。
实际操作里，把量化阈值和审批权限合并成一张表，直接挂在TARA模板旁边，每次评审照着表执行，效率提高很多。这也是整个落地过程中最容易出成效的一项工作。
5. 避坑：五类最常见的21434落地翻车现场
标准落地过程中的坑，往往不在技术深度上，而在流程和习惯上。以下五类翻车现场，全部来自真实项目中的教训。每一条我都按现象、原因、解决三个层次写清楚，方便对照自查。
5.1 TARA做了一次就封存，需求变更后不再重跑
现象：TARA文档创建于项目立项时，之后就再没人打开。等到系统架构改了、新增了远程诊断功能后，安全目标还停留在最初版本，测试用例也按老需求写。
原因：TARA被当成了一个阶段性交付物，而不是持续更新的决策工具。项目排期里没有给增量TARA留时间窗口。
解决：把TARA更新作为设计变更流程的强制关卡，在变更评审记录里增加字段，写明“本变更是否影响已有TARA结论”。如果影响，必须输出增量分析记录再进入下一阶段。我在项目中通常设定一个规则：任何涉及外部接口、通信协议、密钥体系或诊断功能的变更，默认触发TARA更新。
5.2 ASIL和CAL互相替代，两套等级混在一起
现象：团队为了省事，直接把功能安全分配的ASIL等级拿来当CAL用，或者把CAL等级写进ASIL相关的安全需求里，导致两条流程的文档逻辑混乱。
原因：两个体系虽然都叫“安全”，但一个面向功能失效，一个面向恶意攻击，推导基础、分析方法和验证要求都不同。ASIL来自危害分析和风险评估，CAL来自威胁分析和风险处置。
解决：在模板上把两套等级字段分开，允许相互参考但不允许直接继承。实际项目里，我一般建议在架构设计阶段做一次对照分析，看ASIL与CAL是否存在落差。落差大的场景往往是攻击面引入的新风险，恰好是CaL要重点覆盖的。
5.3 网络安全目标写成了安全功能说明书，没法验证
现象：网络安全目标写得像需求规格，例如“ECU应使用AES-128-CBC加密通信”。验证团队拿到后不知道怎么设计测试，因为这句话既没有说明保护对象，也没有定义对抗条件。
原因：混淆了“安全目标”和“安全功能需求”。安全目标回答的是“要防范什么风险”，功能需求回答的是“怎么做到”。
解决：把每个网络安全目标写成可验证的约束。示例：“当TARA中定义的低速CAN通信链路被注入非预期数据时，网关应拒绝该数据帧并记录事件日志，拒绝率不低于99%。”这样验证团队能直接对应到模糊测试用例和日志检查项。
5.4 供应商问卷发出去，回收的只有一纸承诺书
现象：公司做供应链网络安全评估，给供应商发了一份问卷，回收后发现大部分选项填“是”，附一句“我司已建立相关流程”，没有提供任何证据文件。
原因：问卷设计本身太粗，只问“有没有”，不问“有哪些记录”“流程怎么跑”。供应商轻松填完，采购方又没精力追证据。
解决：问卷里对关键项必须要求附件证据，例如“请提供最近一个项目的TARA节选”“请提供CAL评审签字页”。没有证据的“是”一律视为未满足。同时把供应商分级，关键安全相关零部件供应商必须做现场或远程证据抽查，而不是只回收电子表格。
5.5 风险评审没人有权限拍板，CAL悬而不决
现象：TARA分析完成后，风险等级和CAL建议被提交给项目例会，但会场上没有人能对“接受残余风险”做正式决定。会议记录写“待管理层确认”，一拖就是几周。
原因：项目组织架构里没有定义风险接受权限，也没有把这项决策写进角色职责。TARA卡在等待批复，开发和验证进度全被阻塞。
解决：在CSMS里明确各级风险接受权限，并写入项目章程。常见的做法是：CAL1和CAL2由项目经理批准，CAL3由网络安全经理批准，CAL4由组织高层批准。把这条审批链固化下来之后，风险评审会基本一轮就能结束。
6. 一个能被审计师接受的最小证据包：验证前先回答六个问题
做了所有流程之后，最终要过审计这一关。我逐渐意识到，审计师不关心文档厚度，关心的是追溯链是否完整：从一个风险结论，能不能顺藤摸瓜找到目标、需求、测试和结果。与其临阵补文档，不如在每个迭代结束前，用这六个问题自检。
第一个问题：组织级证据在哪？网络安全策略、角色任命、能力培训记录能否当场拿出来。第二个问题：当前版本TARA是否覆盖了架构变更？这是审计师必翻的地方。第三个问题：每条网络安全目标能不能追溯到具体风险和决定依据？追不上的目标等于没写。第四个问题：CAL和残余风险的批准签字是否齐全？口头同意不算数。第五个问题：安全目标是否都有对应测试用例和测试结果？哪怕标记为未执行，也比空白强。第六个问题：供应商交付物里有没有安全证据包？至少包括TARA摘要、安全目标清单和安全测试报告。
六个问题全部能回答“是”时，证据包结构基本合格。我会按三个层级存放：组织层放CSMS文档和评审记录，项目层放TARA、安全目标、CAL审批和测试报告，供应商层放问卷、证据附件和准入结论。目录结构保持稳定，每次审计直接按目录抽文件。
最后说一个习惯：每个安全目标的验证证据我通常会在测试用例管理系统里打上标签，确保从TARA导出时能直接生成追溯矩阵。这件事第一次做觉得繁琐，但坚持三个项目之后，审计准备时间从两周缩短到两天。真实项目里最难补的永远是当初没留下的决策痕迹，而不是文档本身。希望帮到你。
本文还有配套的精品资源，点击获取
