ISO/SAE 21434 汽车网络安全：从TARA到CSMS的工程落地指南

1. 为什么这两年突然都在讨论 ISO/SAE 21434

先说个我工作里常见的场景：原来只做车身控制器或者车载娱乐系统的团队，最近几年的需求文档里开始频繁出现一时间看不明白的缩写，TARA、CIA、CAL、CSMS，供应商还被甲方要求提供一份叫"网络安全概念"的文档，客户来审厂时问的问题也从"代码走查怎么做"变成了"你们怎么识别和跟踪漏洞"。这些变化背后都指向同一个编号：ISO/SAE 21434。简单说，这是一部专门讲"汽车网络安全工程怎么做"的国际标准，全称是 Road vehicles — Cybersecurity engineering，2021 年 8 月正式发布。它要解决的核心问题很直白：智能汽车越来越像带轮子的电脑，我们过去那套造车的安全方法，已经兜不住"被人恶意攻击"这类新风险了。

这篇文章我不会上来就抄标准条款，而是先帮大家把"为什么会出现这个标准、它到底是什么、里面的关键概念怎么理解、落地时有哪些坑"讲清楚。目的是让做研发、做项目管理、做质量或者做供应商对接的朋友，读完能对 21434 有一个整体框架，后面不管是读客户模板还是自己组织 TARA，都不至于发怵。

1.1 汽车联网后，攻击面已经不是"实验室假设"

十年前的汽车电子系统，大部分控制器之间用 CAN 总线通信，诊断接口放在车里面，外部想接触它得先物理上靠近这台车。那时候谈"汽车被黑客攻击"，很多人觉得是电影情节。但现在不同了，现在的车几乎都有远程控制 App、OTA 升级、语音助手、第三方应用、车路协同通信，充电的时候还要跟充电桩交互，甚至路边一个蓝牙信标都可能被车辆系统误读。

攻击面扩大之后，攻击者不需要拿到车钥匙，也不需要拆开内饰板，坐在家里就可能通过云端接口、移动网络或者短信钓鱼拿到某种控制权限。2015 年著名的 Jeep 切诺基远程控制事件，已经让整个行业认识到：一辆在高速上行驶的车，可以被研究者在几公里外用笔记本通过娱乐系统漏洞踩下刹车。这不是电影，而是已经真实发生过的演示。

所以"汽车网络安全"不是实验室里的一种假设，而是量产车在真实道路上必须具备的属性。问题是，以前没有一套通用的方法论告诉所有车企和供应商："你应该在什么阶段分析风险、用什么格式记录、怎么验收。"每个公司都是自己摸索，做出来的东西五花八门，OEM 审供应商也没有统一抓手。ISO/SAE 21434 就是来填这个空位的。

1.2 功能安全管不住"故意使坏"的对手

很多人第一次接触 21434 时会问：我们不是已经有 ISO 26262 了吗？功能安全不就是管安全的吗？这个疑问我几乎在每个客户现场都会遇到，需要先把它掰开。

ISO 26262 针对的"安全"是一个英文词 Safety，它解决的是"系统因为随机硬件失效、系统性设计错误而导致的伤害"。它的世界模型里，故障是"不小心"发生的，概率可以统计，失效率可以计算，所以可以用 FMEDA、故障树、安全完整性等级（ASIL）这套工具来控制。安全界有一个很重要的原则：对手是"随机失效"，它没有智商，不会因为你在某个地方加了防护就改变策略。

网络安全对应的英文是 Security，面对的是"有智力的恶意攻击者"。攻击者会主动探测、会寻找薄弱环节、会组合多个漏洞、会持续利用你的信任链。你堵住一个口子，他会换一条路。这就意味着"出现概率"很难计算，因为攻击者不是随机事件，而是有针对性地做决策。安全性的经典方法论，比如"失效率越低越好"，对网络攻击并不成立的。

这也是为什么 ISO 26262 不能直接延伸到网络安全领域的原因。21434 的设计哲学完全不同：它不追求"绝对安全"，而是引入风险管理的思想——承认漏洞存在，承认攻击可能发生，通过系统的威胁分析和风险评估（TARA），把有限的资源花在最该防御的资产上，并且把这一套决策过程做成可视、可审计、可持续更新的机制。

1.3 法规和准入要求把它变成了硬门槛

如果说标准本身是"怎么做"的方法论，那真正倒逼车企行动的是法规这条线。联合国欧洲经济委员会（UNECE）在 2020 年通过了关于车辆网络安全的第 155 号法规（UN R155），从 2022 年 7 月开始，在缔约方市场，新车型要获得型式批准就必须证明整车厂建立了符合要求的网络安全管理体系（CSMS），并且在整个车辆生命周期都有持续的网络安全活动。到 2024 年 7 月之后，所有新注册车辆都要满足这个要求。

简单说，没有 CSMS 证书，新车在欧洲市场就上不了公告，这是实实在在的商业门槛。国内对应的情况也很清楚，近几年发布了一系列汽车信息安全相关的强制性国家标准，对整车信息安全提出了准入层面的要求。所以不管你是主机厂还是 Tier 1、Tier 2，只要产品最终要装到量产车上，21434 就不再是"可选的学习资料"，而是"必须回答的考试题"。

2. 把 ISO/SAE 21434 拆开看：它到底是什么、管到哪里

2.1 一份标准的"出身"和定位

ISO/SAE 21434 由 ISO 和 SAE International 联合制定，背景可以追溯到 2016 年前后 SAE 发布的网络安全指南 J3061。J3061 是行业里第一份比较系统地讨论汽车网络安全工程流程的指导文件，但它只是"指南"，不是"标准"，没有强制性，也没有统一的认证口径。后来 ISO 和 SAE 觉得需要把这个共识升级成一个全球统一的标准，于是联合工作组花了几年时间，在 2021 年正式发布了 ISO/SAE 21434：2021。

它的定位是一份"过程标准"，或者说"管理类标准"。什么意思呢？它不规定"你这辆车必须用 AES 加密"或者"防火墙必须部署在哪个网段"，它规定的是：你作为一家造车或者做汽车零部件的组织，应该建立什么样的网络安全治理结构，开发过程中应该做哪些分析活动，每个活动应该产出什么证据，证据应该如何流转和评审。

这一点很关键。很多做技术的工程师初次看标准会失望：怎么通篇都是"应规划""应评估""应记录"，没有一条具体的算法和配置？但反过来想，汽车产业链非常长，主机厂、Tier 1、Tier 2、软件服务商、云平台，大家的技术栈完全不同，如果标准规定死了某种加密算法，它一定无法适应全行业的场景。所以 21434 故意做成"留白"的方式：过程和方法我给你框架，具体细节你结合自己的产品和组织裁剪。

2.2 风险驱动加全生命周期，是它的底层逻辑

21434 有两条贯穿全篇的主线，我称之为"风险驱动"和"全生命周期"。

先说风险驱动。标准把网络安全风险定义为威胁场景发生的可能性和对相关人员、组织造成损害的严重程度的组合。所有活动都围绕风险展开：先识别资产，再分析损害场景，推演威胁场景和攻击路径，评估攻击可行性和影响，计算出风险值，然后决定"这个风险要不要处理、怎么处理"。这跟保险公司的业务逻辑很像——你不可能给所有东西都上最贵的保险，你得先评估哪个最值钱、最容易出事，再决定保费和保单。

再说全生命周期。车辆交付给用户并不是终点，甚至可以说发布之后才是网络安全工作的主战场。因为漏洞不是在设计阶段全都能发现，软件系统会持续暴露新的问题，攻击手法也在进化。所以标准把覆盖范围从概念、开发、生产一路延伸到运行维护、最终报废，要求组织建立持续的漏洞监测和事件响应机制。一台车卖出去五年十年，这段时间里的网络安全责任并没有消失，这正是 21434 跟传统软件研发"上线即结束"逻辑最大的不同。

2.3 它既管"组织"也管"项目"，缺一不可

很多刚接触 21434 的人以为它只管项目开发流程，比如"做一个新车型的时候做一轮 TARA 就完事了"。但这个标准明确区分了两个层面：组织级网络安全管理（Organizational cybersecurity management）和项目级网络安全管理（Project-dependent cybersecurity management）。

组织级关注的是这家公司有没有能力持续地做对网络安全，包括是否任命了网络安全负责人、有没有安全政策、员工培训怎么开展、工具链怎么管理、第三方怎么评估、安全事件怎么上报、漏洞信息怎么共享。这些不是某一个项目上的产出物，而是整个公司层面的长期机制。

项目级则是在具体项目里落实风险分析和安全工程，比如新的 T-Box 项目、新一代中央网关项目，在项目启动时做网络安全计划，在概念阶段做 TARA，在开发阶段把安全需求落到设计和测试，在量产阶段做安全相关的生产控制，在运行阶段持续监控。

这两个层面之间的关系，有点像"公司通过了 ISO 9001"和"这个具体订单做了首件检验"之间的关系。前者证明你有体系、有流程、有资质；后者证明你在这个项目上真的按流程做了。21434 明确要求这两层都要有证据，这也是它跟以往很多"做技术防护"类标准的显著差别。

3. 先建立这套术语体系，后面讨论才不吵架

3.1 从资产到损害场景：一条因果链

真正按 21434 做项目的时候，你会发现团队里交传最多的是这么几个词：资产、损害场景、威胁场景、攻击路径。它们之间是一条完整的因果链。

先说资产（Asset），指的是"需要被保护的、对利益相关者有价值的东西"。它可以是数据，比如用户的位置信息、车主的支付凭证；可以是功能，比如远程刹车、ACC 自适应巡航；也可以是硬件或软件资源，比如诊断端口被滥用、OTA 服务器被控制等。做安全分析的第一步，不是问"哪里可能被攻击"，而是问"如果这个东西没了、坏了、被改了，车主或者企业会不会很受伤"。这就是在识别资产。

损害场景（Damage Scenario）描述的是一个不好的后果——如果资产受到侵害，事故最终会对人员、财产、运营、隐私造成什么样的负面结果。比如"攻击者恶意禁用刹车导致车辆碰撞，造成人员伤亡"就是一个损害场景，另一个例子是"大量用户车辆被远程锁死，导致品牌声誉受损和巨额赔偿"。

威胁场景（Threat Scenario）描述的是"攻击者通过什么样的抽象方式去利用资产漏洞"从而可能造成损害。比如"攻击者通过网络远程向制动系统注入伪造的 CAN 报文"。它不一定写具体的攻击步骤，而是描述一种攻击模式。

攻击路径（Attack Path）则是更具体的那一步：从攻击入口到最终达成威胁场景的一连串技术步骤。比如"攻击者先渗透娱乐系统，再通过网关漏洞向动力 CAN 发送报文"。从资产到损害场景，再到威胁场景和攻击路径，是从"我们要保护什么"一路推导到"敌人要怎么进来"的过程。

3.2 用一个真实例子串起所有概念

光讲概念容易飘，我用一个汽车圈里非常经典的无钥匙进入系统中继攻击（Relay Attack）来串一遍。

假设要分析一辆支持无钥匙进入和无钥匙启动的车型。先从资产出发：关键资产是"车辆的整车访问权限"和"无钥匙启动功能"，如果这个权限被非法获取，车主会丢车，保险公司和厂商要赔钱，甚至可能因为车辆被非法开走造成交通事故。

损害场景可以写成："攻击者在车主附近通过信号中继方式，在无车主授权的情况下打开车门并启动车辆，导致车辆被盗、财物损失以及潜在的道路安全事故。"

威胁场景就可以写成："攻击者远程或近距离捕获车钥匙的射频信号，并中继转发给车辆，使车辆误以为合法钥匙在车内。"

攻击路径就具体多了："攻击者甲携带信号放大器在车主家门口接收钥匙信号，通过中继发送给站在车旁的攻击者乙，乙手里的转发装置模拟钥匙与车辆完成握手认证，车锁打开，车辆启动。"整个过程里，车辆本身的电子锁系统没有任何代码被破解，它只是被骗了。

这个例子能看出整个因果链是怎么层层递进的：资产有没有价值？有。损害严重吗？严重。攻击者做得到吗？现实里已经有大量被盗案件，可行性很高。那风险就高了，需要在 TARA 里给一个很高的风险等级，然后提出网络安全目标，比如"整车必须具备对密钥射频信号的合法性校验机制，防止中继放大攻击"。这就是概念阶段持续要做的事情。

3.3 TARA 到底在做什么事

TARA 是 Threat Analysis and Risk Assessment 的缩写，也就是威胁分析和风险评估，它是 21434 里出现频率最高的方法，属于整条安全链路的发动机。很多第一次接触的人以为 TARA 是一张固定的表格，填一下就完事，实际上它是一个有明确步骤、并需要反复迭代的分析过程。

标准的 TARA 大体上要做这几件事：先确定分析对象和边界，通常叫 Item Definition，也就是把你正在分析的系统功能、物理边界、外部接口、数据流定义清楚；然后识别资产并分类，比如对安全类资产和隐私类资产分别标注；接着推导损害场景，评估安全（S）、财务（F）、运营（O）、隐私（P）等维度的影响等级；再结合资产特点，用 STRIDE 这类威胁建模方法推导威胁场景，拆出攻击路径；然后评估攻击可行性，这个维度通常看攻击者的技能、资源、进入系统的机会，以及攻击路径的复杂度；最后把影响和可行性映射到风险矩阵，得出风险值，再决定风险处置方式。

风险处置的四种典型选择是规避、减缓、分担和接受。规避就是干脆不做这个功能、拿掉这个接口；减缓就是上安全控制措施，比如身份认证、加密、防火墙、入侵检测；分担可以是买保险或者由多个环节共同扛；接受则是经过管理层正式确认，认为残余风险可以容忍。这四类决策都要记录理由。TARA 的输出物就是一堆网络安全目标，它们会成为后续安全需求、安全概念设计的输入。所以可以这么理解：TARA 不是一张表格，而是把"安全问题"翻译成"工程需求"的那道工序。

4. 双层治理：组织级能力和项目级执行的配合

4.1 没有 CSMS，项目级活动就是无根之木

前面反复提到 CSMS（Cyber Security Management System），字面意思是网络安全管理体系。我经常跟别人打比方：CSMS 之于网络安全，就相当于质量管理体系之于质量。你可以单独在一个项目里做一次高质量的项目评审，但如果没有一套常设的制度去定义谁负责、什么标准算达标、问题怎么升级、知识怎么沉淀，那每一次项目的成功都是"碰运气"，不可持续。

ISO/SAE 21434 里组织级要求覆盖的正是这套"制度"：公司要有信息安全政策，要指定网络安全责任人，从董事会到研发执行层都要有明确的角色分工；人员要有能力模型和培训计划，做 TARA 的人不是谁都能做，至少他要理解资产识别和威胁建模；工具链要管理和评估，比如使用的静态扫描工具、漏洞管理平台是不是满足要求；还要建立审计和量化的机制，定期检查项目到底有没有按流程走。

为什么这套"虚的东西"反而被法规看得很重？因为 UN R155 的型式批准思路很清晰：它不可能在公告阶段把每一台车的每一个字节都检查一遍，它要求的是"你有一套体系能保证批量生产出来的产品和你提交审批的那台原型车是一致的，并且你在全生命周期里都能持续处理安全事件"。如果组织没有 CSMS，那所有项目都是孤岛，监管机构没有理由相信这个企业能负起长期责任。

4.2 项目级流程：从概念到退役的完整脚本

项目级网络安全活动，本质上就是一套和传统 V 模型高度对应的脚本。概念阶段，先做 TARA，分析清楚风险和应对方向，形成网络安全目标和网络安全概念；开发阶段，把网络安全目标分解成系统级、软件级、硬件级的网络安全需求，在架构设计里加入安全机制，然后做设计评审和实现；测试阶段，针对安全需求做集成测试、渗透测试和漏洞扫描，还要做安全验证，证明这些安全目标真的在整车环境里达成；生产阶段，要保证生产环节本身不引入漏洞，比如安全编程工具的访问控制、密钥烧录的防泄漏、自动测试台的权限管理；最后是运营和维护阶段，建立产品安全事件响应团队，对已量产车辆进行漏洞监测，收到漏洞报告就要评估、修复，需要 OTA 升级支持的还要跟软件升级体系配合。

这个流程里有个词值得单独拿出来说：网络安全案例（Cybersecurity Case）。很多项目团队到了项目后期才想起来要写最终报告，但其实网络安全案例是伴随整个开发过程成长起来的"论证档案"，它要用证据链回答"我们凭什么说自己达成了网络安全目标"。比如你说自己防护住了中继攻击，那证据可以是架构设计文档、具体的认证算法实现说明、测试报告、渗透测试结果。没有证据的网络安全目标，只能算一句口号。

另外还有一个"事前评估"和"事后评估"的区别：有些环节你是要请独立于项目组的角色来评审的，比如重大安全设计的变更、TARA 结果的合理性、缓解措施是否足够。这种"独立评审"在标准里反复出现，因为它防止"开发和测试是同一拨人，自己给自己放水"。国内团队对这个往往不习惯，觉得流程繁琐，但真正做过安全事故复盘的人都会认同，一个"红队式"的搅局者比十个填鸭式的评审有用得多。

4.3 供应链怎么切责任：甲方乙方都别想着甩锅

现代汽车产业链太长了，一个整车域控制器里可能有自研的软件，也可能有来自三四个不同供应商的中间件、底层软件和芯片方案。网络安全的责任怎么切？21434 给出的答案是：通过"网络安全接口协议"来分。

这个接口协议通常在项目启动早期就要签，内容大致包括：双方的安全角色和职责边界；供应商需要提供哪些信息来支持 OEM 做 TARA，比如组件的硬件安全能力、SoC 的安全启动支持、已知漏洞清单；供应商自己发现漏洞后要在多长时间内通知 OEM；OEM 收到漏洞后如何反馈给供应商；双方都认可的取证和沟通流程。

在实际项目里，最让人头疼的不是定职责，而是"信息不对称"。OEM 要做系统级 TARA，需要知道底层 Linux 内核的某个驱动是否暴露了攻击面，但供应商往往觉得这是我的商业机密。反过来，供应商手里明明有某个模块的已知漏洞信息，但又担心告诉 OEM 之后要承担无限责任。所以 21434 通篇强调的"信息共享机制"在供应链环节特别重要。一个比较实用的做法是：在接口协议里写清楚共享信息的范围、保密义务、免责条款，并把漏洞响应时限量化，比如"发现严重漏洞后 24 小时内发出通知，两周内提供初步缓解方案"。把边界量化，比反复强调"双方应及时沟通"管用得多。

5. 落地时最常见的几种误解，以及给团队的起步建议

5.1 误解一：这是一本"安全技术手册"

我见过不少安全工程师拿到 21434 之后翻了几页就说"这标准什么都没说，连加密算法都不推荐"，然后继续埋头写代码。这个反应其实暴露了一个误解：标准的目标读者不完全是"写安全功能的人"，更多是"管理安全活动的人"。

它关心的是你有没有一套方法判断"哪个资产值得保护、攻击者可能走哪条路、防护措施有没有效果、漏洞出现后谁来响应"。具体用什么算法，哪个网段放防火墙，那是后面解决方案层的事情。所以落地 21434，首先要做的是把心态从"标准要告诉我怎么做安全"切换成"标准要求我证明自己是安全可控的"。前者是技术视角，后者是治理视角，两者都很重要，但不能互相替代。

5.2 误解二：TARA 就是填一张表

很多模板里 TARA 都被做成了 Excel 表格：一行一个攻击路径，填攻击可行性、填影响等级、填风险值，填完就锁文档。这种做法的问题在于，TARA 的价值不在"打分"本身，而在分析过程中对系统架构、数据流、信任边界的深度理解。

同样的一个远程诊断功能，如果团队只是对着模板填，很可能写出的威胁场景都是网上抄来的通用项，最后分数全凭感觉。真正有效的 TARA 应该是一个多角色参与的研讨会：让系统架构师讲清楚数据从哪来到哪去，让软件工程师补充接口的认证方式，让安全研究员提出攻击假设，让功能安全工程师指出哪些风险会演变成人身伤害。分析过程里的争论和论证，往往比最终那张矩阵表更有价值。所以我的建议是，TARA 的评审记录里不要只留分数，还要留下关键假设和讨论结论，否则半年后技术方案一变，你根本不知道当初为什么给这个风险打了中等级别。

5.3 误解三：文档做齐了就是合规

有一点必须说清楚：21434 不是"写完文档就完事"的标准，它有很强的审计和审计追溯属性。整车厂在审核供应商时，会随机抽取一个安全需求，问你：这个需求是从哪条威胁场景推导出来的？你怎么验证它实现了？测试用例在哪个版本固件上跑过？如果这些问题你答不上来，即使文档成套也没用。

这背后其实是一种"证据链"思想：从资产到损害场景，从威胁场景到网络安全目标，从安全需求到设计方案，再到测试用例和测试结果，最后到量产和运维阶段的监控数据，整条链必须是可追溯、可检验的。我建议团队从项目第一天就建立一个可追溯性矩阵（Traceability Matrix），哪怕是临时用表格管理都行，关键是不要让这条链断掉。工程实践里，因为人员流动导致"人走了，安全设计的理由也带走了"的案例实在太多了。用一套结构化的记录把推理过程沉淀下来，是标准给你上的最贵的一课。

5.4 如果让我从零带团队，我会怎么排优先级

如果你所在的公司刚开始推行 21434，我建议不要追求大而全，先把业务里最痛、最容易被客户盯上的项目拎出来做试点。第一步，建一个最精简的组织级框架：明确一个网络安全负责人，编一个三页纸的网络安全政策，定义好每个角色在安全活动里的职责；第二步，选一款成熟度比较高的车型项目，完整走一轮 TARA，输出网络安全目标，再挑两三个高风险目标落到设计和测试里；第三步，把试点项目积累的模板、评审清单、经验教训沉淀成公司内部的知识库；第四步，再考虑构建跨项目的漏洞响应机制和供应链审核体系。

顺序很重要。很多公司的失败经验是：一开始就急着让所有项目同时做 TARA，结果大家都在填模板，填出来的东西没人看得懂，三个月后项目一忙，安全活动就彻底停摆。先试点、先建立样板，其实是用较小的成本把团队能力锻炼起来，然后再靠体系的杠杆去覆盖更多项目，这才符合 21434 里"持续改进"的精神。

另外想单独提醒一句：如果你现在做的是功能安全相关工作，千万别把 21434 和 ISO 26262 完全割裂。两个标准虽然在方法论上有本质区别，但在实际操作层面很多活动可以共用上下文。比如 TARA 里的损害场景，经常要参考功能安全里的危害分析；安全需求和功能安全需求也可能作用在同一个网关上。两个团队如果能共用一个需求管理平台、一套变更管理流程，后面做联合评审和证据管理都会省力很多。我见过那种安全团队和功能安全团队各建一套体系、两套模板互不相通的公司，到项目集成阶段光是"对需求 ID"都够折腾两周。

ISO/SAE 21434 这套体系真正落地并体现出价值，不是在第一次项目交付的时候，而是在产品上市两三年后某一天，外部安全研究员真的提交了一个漏洞报告，而你发现整个团队居然能按预案有条不紊地响应、评估、修复、升级的时候。那种"体系救了一命"的感觉，只有亲历过才能体会。下一篇我打算把 TARA 的具体操作步骤拆细，结合一个从资产识别到风险处置的完整案例，把每一步的输入输出和评审要点讲透。如果你现在正准备在公司里启动第一次 TARA，可以先按这篇文章把组织层面的负责人和项目边界理清楚，到时候你会轻松不少。