本文摘自汽车精英荟公众号文章
目录：
ISO/SAE 21434 《道路车辆 网络安全工程》是SAE和ISO共同制定的一项针对道路车辆的网络安全标准，它是一个面向汽车行业全供应链（OEM及各级供应商）的车辆网络安全管理指导文件，其目的是指导行业内相关组织：
定义网络安全方针和流程；
管理网络安全风险；
推动网络安全文化。
去年欧盟发布了网络安全法规UNECE R155，在其解释文件中明确引用了该标准，此外，国内汽标委也正在推动该项标准的本土化工作，车辆网络安全在今后极有可能成为一项强标，因此，无论是对于技术研发还是网络安全合规认证来说，21434都是其中最为重要的指导文件之一。
ISO/SAE 21434 文件概览
ISO/SAE 21434正式版于2021年8月31日发布，标准共由15个章节组成，其中主体部分为4-15章。
第4章 概述：包含本文件中采用的道路车辆网络安全工程方法的背景和总体信息。
第5章 组织级网络安全管理：包含组织层级网络安全方针、规则和流程的规定和管理要求。
第6章 基于项目的网络安全管理：包含项目层级的网络安全活动和管理要求。
第7章 分布式网络安全活动：包含客户与供应商之间网络安全活动的职责确认的要求。
第8章 持续的网络安全活动：包含对项目生命周期中，需持续实施的风险分析和E/E系统的漏洞管理活动的要求.
第9-14章 描述了从概念设计到产品开发、验证、生产及后期运维和退役全生命周期的网络安全活动和相关要求。
第15章 威胁分析和风险评估方法：提供了一套网络安全威胁分析、风险评估及处置的方法论。
组织级网络安全管理
第5章 组织级网络安全管理（organizational cybersecurity management）规定了公司/组织层面网络安全管理的要求，是组织内部最高层面的安全方针，标准中从7个方面提出了要求：
一、网络安全治理（cybersecuritygovernance）
网络安全治理是最宏观的层面的安全治理方针，总共有5条要求，可总结为以下几点：
领导层重视
公司最高层必须具备网络安全管理的概念，认可并且重视网络安全的体系和能力建设，以保证安全工作的顺利实施。
流程认证
这里可以理解为CSMS体系的保证，流程包含了概念、开发、生产、运维、退役、TARA方法论，安全监控，信息共享，应急响应等21434中提及的所有环节的流程。每个模块的体系文件又可以分为程序、指导手册，方法论和模板多级文件。
职责划分
CSMS体系建立好后，必须将各环节的职责分配给相应的部门/人员，确保流程真正落地。
资源保证
必须保证相关能力的人员、技术和工具等资源。
与现有流程结合
考虑如何将网络安全管理活动嵌入组织现有的流程中。
二、网络安全文化（cybersecurity culture)
这一节规定了组织实施网络安全管理需具备的“软实力”，可归结为以下3点：
建立良好的网络安全文化
对于什么是“良好”的网络安全文化，可参考文件后的附录B，内容和26262中提及的安全文化示例基本一致。
保证人员的能力和意识
能力涵盖了多个方面，如具备风险管理的流程和规定，具备功能安全、隐私保护的相关流程规定，人员具备相关专业领域的知识以及渗透、安全防护的知识等。
持续改进
持续改进需贯穿在网络安全工程的所有活动中，改进可以来源于内/外部的监控获取的信息、lessons learn, 相似项目的经验，开发过程中发现的问题、体系/流程审核中发现的问题等。
三、信息共享（Information Sharing）
信息共享要求组织必须考虑组织内外部哪些数据共享是必须的、允许的，哪些是被禁止的，并根据这个准则去管理与第三方共享的数据。
在具体实施层面，通常会对信息进行分级，制定相关的信息共享流程，使用专门的信息传输工具，与第三方确定漏洞披露原则等。
四、管理体系（Management System)
组织应建立一个质量管理体系来支撑网络安全工程。主要支持网络安全工程中的变更管理、文档管理、配置管理和需求管理。其中产品的安全配置信息必须在产品终止维护前保持可用。此外，本节中还建议组织制定生产制造环节的网络安全管理体系。
目前行业内绝大部分企业都通过了16949的认证，在实际实施中需要考虑的是将网络安全开发活动纳入原有的变更、文档、配置和需求管理流程中进行管理。
五、工具管理（Tool Management)
组织应对能够影响相关项和组件网络安全的工具进行管理，这些工具可能包括:
开发过程中的工具如模型开发，静态代码检查，验证工具。
生产中的工具如软件刷写工具、产线检测仪。
运维阶段的工具如在线诊断工具等。
工具可以通过以下的方法进行管理：使用用户手册和勘误表，访问控制，权限控制，预防非预期行为和操作等。
此外，本节还建议在产品退役前，应保持相关环境（如软件编译、开发环境、测试环境）可复制，以便在后续发生网络安全事件时，可对漏洞进行复现和管理。
六、信息安全管理（Information security management)
建议：相关的工作产品应该由一个信息安全管理系统来管理
七、网络安全审计（organization cybersecurity audit）
组织应进行网络安全审计，以判断组织的流程是否达到了本标准的要求。需要注意几点：
审计人可以来自组织内部或外部，但必须保证审计的独立性，关于独立性的要求可以参考26262中的相关描述。
网络安全审计可以包含在质量体系的审计中（如IATF 16949）。
审计可以分阶段进行
最后在总结一下本章节要求输出的工作产品：
[WP-05-01]网络安全方针、规则和流程
[WP-05-02]能力管理、意识管理和持续改进的证据
[WP-05-03]质量管理体系的证据
[WP-05-04]工具管理的证据
[WP-05-05]网络安全审计报告
小结
本章规定了组织最高层级的网络安全管理要求，企业中CSMS的牵头部门应基于本章内容制定企业网络安全管理的总体方针，然后识别和推动各相关责任方建立各自模块（如开发，运维，供应商管理等）的网络安全管理体系。
随着联合国ECE R155法规被纳入GSR，以及国内网络安全标准制定的快速推进，CSMS建设已经变成各大OEM迫在眉睫的工作。强标的驱动保证了网络安全工作在组织中得以自上而下的进行，因此对于相关企业来说，工作的难点就在于识别出网络安全开发流程与现有流程相比，新增了哪些活动，有哪些活动可与现有活动融合，从而在合规的基础上，制定出最适宜、变更成本最低的网络安全管理体系搭建方案。
基于项目的网络安全
项目相关的网络安全管理（Project dependent cybersecurity management) 一章描述了普适性的针对项目网络安全活动的管理原则。包括各项活动的职责分配，制定网络安全活动计划，裁剪原则，以及网络安全案例和网络安全评估、后开发阶段释放的要求。
一、网络安全职责（Cybersecurity Responsibilities)
根据第5章[RQ-05-03]的原则进行沟通和分配。
二、网络安全计划（Cybersecurity Plan）
制定网络安全计划是项目网络安全开发前期一项重要的工作，有以下几个要点：
识别网络安全开发范围：
通过分析识别出整车中与网络安全相关的组件，
区分新开发组件和复用组件，并分析判断是否需要对安全活动进行裁剪。
对于网络安全相关项的判断，21434中给出了一个参考方法：
制定网络安全计划：根据本文档的规定和裁剪原则，确定项目中需实施的网络安全活动，以及各项活动的目的、负责人、所需的资源、开始和结束的时间点以及持续时间、与其它活动或信息的关联、要输出的工作产品。同时还要确定由谁来制定和维护该计划，谁来跟踪计划中安全活动的实施进展。
与项目计划匹配：网络安全计划主要规定概念阶段和产品开发阶段要求的网络安全活动，它应包含在项目计划中，与开发计划相匹配。
实施证据的管理：网络安全计划及其相关工作产品需持续维护和更新，并进行配置管理和文档管理，直至后开发释放。这对于后续形成网络安全案例，进行网络安全评估和后开发释放有重要的意义。
三、裁剪（ Tailoring）
在21434中允许对网络安全活动进行必要的裁剪，在裁剪前必须进行充分的分析和评审，并提供相应的证据，以证明裁剪后仍然可以充分实现21434中要求网络安全的目标。在标准中规定了4种可进行裁剪的情况，分别是复用、独立组件、现成组件和更新，在这4种情况下，需根据标准中的要求和建议进行裁剪。
四、复用（ （Reuse）
件复用在整车研发中十分的常见，即使复用的组件已按照网络安全的要求开发，但是由于复用时组件的变更，运行环境、配置信息等的变化，以及攻击技术的不断发展，新漏洞的发现，仍然需要对其进行必要的分析，实施相应的网络安全活动。在以下几种情况下，需要进行复用的分析：
复用组件发生了修改（包括设计和实施上的修改）
组件在另一个运行环境中复用
不加修改地复用，但相关项或组件的信息发生变化（如已知攻击、漏洞和威胁场景的变化）
以上几乎涵盖了实际开发中95%的情况，因此可以说复用的组件都必须进行复用分析。
在复用分析时，有以下几点需要重点考虑：
确定复用组件修改了哪些地方，或所在环境发生了哪些变化；
分析修改导致的网络安全影响，包括对网络安全声明的有效性和之前的假设的影响；
确定因此受影响或缺失工作产品，比如TARA中新的资产、威胁场景等；
确定复用的组件是否能满足即将被分配到的网络安全需求。
五、独立的组件（Component out of context)
独立的组件通常指供应商开发的通用组件或产品，该组件的开发是基于一个假设的环境，而非基于特定的项目。对于此类组件，21434要求在工作产品中对其预期的用途、环境假设和外部接口进行记录，然后基于以上的假设进行网络安全开发，并对假设和安全声明进行验证。
六、现成组件（Off-the-shelf Component）
现成组件指在不修改其设计和实现情况下集成到系统中的组件，如第三方的软件，开源软件库等。对于此类组件，21434要求其必须收集其相关的网络安全文档，且相关文档需足以支持本文规定的网络安全活动。同时，该组件还要能满足分配到其上的网络安全需求。
七、网络安全案例（Cybersecurity case)
网络安全案例是网络安全评估的对象，它是从概念阶段到开发验证和生产运维阶段整条逻辑链上完整的网络安全开发证据，可以通过相应的工作产品加以支持。在形式认证中，认证机构大概率会以网络安全案例为对象，进行相关的审核。
八、网络安全评估（Cybersecurity Assessment)
网络安全评估的对象是某个相关项或组件，依照本文档的规定评估其网络安全的实施情况，评估可基于工作产品和网络安全活动证据，评估的结果包括接受、带条件接受和拒绝。带条件接受通常会在评估结果中提出整改要求，并会在项目各个阶段对整改项的完成情况进行监控。下图显示了组织网络安全审计，项目网络安全评估和其它网络安全活动之间的关系：
后开发的释放（Realease for Post-Development)
这里所说的后开发的释放，其实就是指开发阶段完成，批准进入到生产阶段，有点类似于网络安全开发的ESO。21434规定在进入生产阶段前，必须提供以下工作产品：
网络安全案例
网络安全评估报告
生产阶段的网络安全要求
并且必须保证：
网络安全案例提供的证据是令人信服的
网络安全案例通过了网络安全评估
生产阶段的网络安全要求被接受
最后总结一下本章中需输出的工作产品
网络安全计划
网络安全案例
网络安全评估报告
后开发释放报告
小结
在欧盟R155法规中，车辆的网络安全准入包含了两个部分: 网络安全体系认证（CSMS）和车辆形式认证（VTA)，本章的内容可作为开展VTA工作的重要参考，它主要规定了在项目角度必须实施的网络安全活动。这部分工作通常由网络安全项目管理工程师负责，其核心内容是在项目前期确定安全工作的范围，并制定相应的网络安全开发计划，规定安全活动和输出的工作产品。在项目实施的过程中，需收集和管理网络安全活动的证据及工作产品，以形成逻辑链完整的网络安全案例。在批产前，需完成相关的网络安全评估和审核。
分布式网络安全
第7章规定了分布式开发中的网络安全活动，可以理解为在网络安全角度如何进行供应商管理。21434是一份面对整个汽车行业的指导标准，因此对供应商管理要求的适用范围不仅限于OEM，同时也适用于Tier 1, Tier 2等供应链上各环节的企业和组织，此外，组织的内部供应商也需要遵循本章要求。在21434中，分布式的网络安全活动主要有3项：
供应商能力评估
报价
网络安全职责界定
供应商能力评估
供应商网络安全能力的评估类似于16949、ASPICE等其它质量体系的评估，目的在于考察供应商在开发、生产阶段执行相关网络安全活动的能力，评估通常在供应商准入或定点前进行。供应商可提供以下证据以证明其网络安全能力：
以往项目中网络安全开发，治理，质量管理和信息安全方面的最佳实践的证据；
证明具备可进行持续的网络安全活动和网络安全事件响应的能力；
对过往网络安全评估报告的总结。
报价
客户应在询价阶段明确提出网络安全相关的需求，包括：
相关的网络安全技术需求
明确要求供应商按照本文档进行产品的开发（体系要求）
要求供应商履行接口协议中约定的职责
在实际定点过程中，通常将网络安全的技术要求和接口协议放在SOR包中，提供给供应商进行报价。
网络安全职责界定
在完成供应商定点后，需识别客户和供应商各自执行的网络安全活动，通过签署《网络安全接口协议》确定双方的职责。在后续的分布式开发活动中，双方根据接口协议完成各自的安全活动，以下是21434提供的一个《网络安全接口协议》模板：
可以看出，接口协议的作用是确定21434中规定的各项网络安全活动客户和供应商分别充当什么角色。这个协议由双方协商确认，例如，零件的TARA由供应商来做，客户进行审批，那么威胁分析和风险评估这项，供应商勾选R（Responsible), 客户勾选A（accountable)。
除了接口协议，客户与供应商的接口还需要规定好：
双方的接口联络人
信息共享的策略（包括信息共享的流程、工具，漏洞披露的流程等）
安全活动的目标里程碑
漏洞和风险的反馈机制和网络安全事件的处理机制。
小结
网络安全相关的标准和政策到目前为止出台仅一年多的时间，各大整车厂、Tier的安全能力建设都还在起步阶段，因此在初期对于供应商的能力评估更多还是基于裁剪给过的体系要求，等到行业水平达到一定程度，相关的认证、审核机制日益成熟，可能会发展成与ASPICE或16949类似相对标准的评估模式。对于定点后的供应商管理，主要基于网络安全接口协议，要求供应商提供零件从TARA，安全方案设计到测试、生产整个完整逻辑链的实施证据。
持续的网络安全活动
第8章主要描述持续的网络安全活动。车辆网络安全工程是一项贯穿产品全生命周期的持续性的活动，OEM不仅要进行TARA分析、安全概念设计、网络安全开发测试和生产，还要在项目的全生命周期中，持续地收集和监控与项目有关的网络安全信息，建立信息监控和漏洞管理机制，持续地保证产品的网络安全。新漏洞的发现、网络安全突发事件的发生、新攻击技术的出现等都有可能触发相应的网络安全工作。
本章节中描述了4项需要持续进行的网络安全活动：
网络安全监控（Cybersecurity Monitoring)
网络安全监控要求组织持续地收集网络安全信息（如最新的漏洞，安全事件，攻击技术等），并使用定义的规则对收集的信息进行筛选，获取有价值的信息。
监控信息可来源于组织内部或外部。
外部来源：网络安全研究人员、商业/非商业来源、供应链、客户、政府
内部来源：网络安全声明，网络安全规范，过往的漏洞分析，威胁场景，现场获取的信息（如漏洞扫描报告，维修信息，客户使用信息等）
在监控过程中会从各种渠道收集到海量的信息，因此需要定义触发器(Trigger)，以从收集的信息中高效地筛选出有价值的网络安全信息。触发器可以是某些关键词，相关的配置信息，组件的名称或供应商的名称。经过Triggers的筛选后的网络安全信息将构成一个或多个网络安全事件。
网络安全事件评估（Cybersecurity Event Assessment)
对网络安全事件进行评估，识别出相关的组件及其脆弱点（weakness)。这一步可以合并到安全监控活动中，通过Trigger直接将安全事件关联到受影响的组件上。
漏洞分析（Vulnerability Analysis)
在该环节中，需对脆弱点进行分析，判断其是否构成一个漏洞。在这里可采用TARA分析中的方法，结合组件的架构信息，识别可能的攻击路径并计算攻击可行性。如果不存在相应的攻击路径，或者攻击可行性非常低，则该脆弱点不构成一个漏洞。否则，该脆弱点将被视为一个漏洞，需要对其进行处置。需要注意的是，对于不构成漏洞的脆弱点，应提供合理的理由。
漏洞管理（Vulnerability Management）
需对识别出的漏洞进行管理：
应采用TARA中的方法对漏洞进行风险评估和处置，确保所有不可接受的风险都被良好地处置。
也可以通过TARA之外的方法对漏洞进行处置。（例如某第三方软件的漏洞可通过补丁修复，则可直接通过更新补丁处置该漏洞，不需要再走一遍TARA。）
部分漏洞如果需要通过应急响应进行处置，则应遵循网络安全事件应急响应流程。
小结
该章节主要涉及的是漏洞管理的内容，包含了漏洞信息的收集，分析和处置。漏洞信息的收集要求组织建立长效的网络安全信息收集机制，通过内外部多种渠道（如订阅威胁情报服务，供应商上报，监测互联网漏洞平台，定期的漏洞扫描等）收集和识别与项目相关的网络安全事件。在分析阶段，应首先定位安全事件影响的功能、组件，识别脆弱点，然后由业务部门和安全部门对脆弱点进行分析，判断其是否应被作为漏洞进入漏洞管理流程。对于已查明的漏洞，需分析其风险等级，制定漏洞处置计划。针对不同严重等级的漏洞，还应设置对应的漏洞关闭时间，跟踪处置进度直至关闭。
概念阶段
从第9章至第14章，21434描述了车辆从概念设计到退役的全生命周期各阶段的网络安全要求。第9章概念阶段（Concept phase）的主要工作是定义网络安全对象，并通过TARA分析，确定网络安全目标，产生相应的网络安全概念。接下来将对这3个环节进行详细的描述。
一、对象定义（Item Definition)
首先解释一下什么是“对象”，在21434原文中表述为item，可翻译为“对象”或“相关项”, Item的定义为：实现整车特定功能的相关电子器件和软件，它可以由一个或多个Component组成，具体来说可以是整车中实现某个/某类功能的系统、零部件甚至是整车的E/E架构。item是网络安全工程的研究的对象，它是后续一系列网络安全活动的基础。”item definition”就是要定义研究的对象及其运行环境，以及其在网络安全语境下与其它对象的交互。对象定义可以参考以下输入信息：
如何定义对象？
对象定义必须描述对象的以下基本信息：
对象边界
功能
初步的架构
举个例子，在该示例中，对象为胎压监测系统。
对象边界：对象包含胎压传感器、网关和仪表盘与胎压监测相关的功能，以及这三个模块之间的通讯数据、协议和网络安全措施，对象与其运行环境的接口为网关上的OBD及其相关的诊断功能。
功能：该对象的功能为传感器监测胎压信息，然后将处理后的胎压信息显示在仪表盘上。
初步架构：初步架构如下图所示，包含了对象涉及的模块、块间的通讯协议以及模块与外部交互的接口等相关信息。
2. 描述对象与网络安全相关的运行环境信息，例如对象的外部接口，内部通讯协议信息，以识别可能的攻击界面和路径。相关信息也可以包含假设，例如假设对象内相关的PKI电子认证服务机构默认是安全的等，以保证后续的分析过程合理可控。
二、网络安全目标（Cybersecurity goals)
网络安全目标是最高层级的网络安全要求，它基于威胁分析和风险评估（TARA）得出的，TARA的方法论将在第15章中进行介绍。根据网络安全目标制定对应的网络安全要求，对于保留风险和转移风险的项，还应解释其合理性。
如何制定网络安全目标？
风险分析：对上一章定义的对象进行风险分析，分析包含资产识别、威胁场景识别、影响评级、攻击路径分析、攻击可行性分析，风险确定等环节，具体方法在之后的15章中会详细解释。
风险处置决策：根据15章中的方法，确定每个风险项的处置方法，风险处置决策包括消除风险，降低风险，转移风险和保留风险等。
制定网络安全目标：对于需要消除或降低的风险，须制定一个或多个相应的网络安全目标，这个目标通常是High level的，可以用类似“保护xx资产的xx属性。”的颗粒度进行描述。目标也包括生产、运维和报废阶段的网络安全目标。21434还在附录E中提供网络安全保证等级（CAL）的分级方法，CAL等级定义了执行网络安全活动的严格程度，因此也可以将CAL等级作为网络安全目标。
制定网络安全声明：对于决定保留和转移的高风险项，以及通过环境假设降低威胁场景风险的风险项，需要制定网络安全声明来阐述适当的理由，且该声明在后续的阶段必须被监控。21434以及车型认证十分重视开发链条逻辑的合理性，因此网络安全声明是概念阶段不可忽视的重要工作。
保证完整性和一致性：这部分属于网络安全质量保证的工作，需要保证以下各环节之间的完整性和一致性：
风险分析与项目定义
风险处置决策与风险分析结果
网络安全目标、声明与风险处置决策
网络安全要求与网络安全目标
三、网络安全概念
网络安全概念包含了网络安全要求和对运行环境的要求，是对于分析对象全面的网络安全需求。
如何制定网络安全概念？
确定技术层面的网络安全控制措施，如通过安全通信处理车外通讯的风险，通过IDPS监测和预防非法入侵口等。
基于安全控制措施，制定网络安全要求和对运行环境的要求，以达成相应的网络安全目标。
将安全要求分配给对象中对应的组件或零件。
保证需求与目标的完整性和一致性。
举个简单的例子：
总结
概念阶段的主要进行3项工作：对象定义；TARA分析；网络安全概念制定。该阶段的工作通常由网络安全开发部门负责，项目的网络安全团队应在项目早期识别项目的范围，对网络安全相关的系统/功能进行TARA分析，识别出高风险的点，针对高风险点制定相应的网络安全控制措施，形成网络安全需求输入给对应的开发部门。
网络安全确认
第11章节的题目是“Cybersecurity Validation”, 可译为”网络安全确认“。这里的Validation需要与上一章节产品开发中的Verification进行一下区分。”Verification”我们通常理解为是否“do the things right“，即验证开发是否满足设计阶段的规范和要求，对象通常是零件或子系统。而本章节的”Validation“则是验证是否”do the right things“，即所开发的产品是否满足网络安全的目标，更直白的讲，是验证车辆是否安全。在该阶段，确认活动的对象是整车，并且是符合量产状态的整车。
该阶段的主要目标有以下3个：
验证网络安全目标和网络安全声明
确认对象达到了网络安全目标
确认没有不合理的风险存在
如何进行网络安全确认？
1.渗透测试
通过渗透测试来验证网络安全目标是否实现，以及网络安全声明的有效性。除此之外，渗透测试还可验证网络安全目标是否充分，车辆是否还存在未被识别的风险 ，如果发现之前未识别的风险，则需要重新进行分析，制定安全目标并对其进处置。渗透测试通常是黑盒测试或灰盒测试，测试的效果很大程度上也取决于测试工程师的经验和专业能力，这部分工作也属于传统开发过程中没有的增量工作，主机厂通常需要建立专门的团队或通过第三方实验室完成该环节的工作。
2. 专家评审
对于一些难以通过测试验证的目标和声明的目标，评审也是一个重要的方法。通过专家评审、跨部门联合评审的方法，对概念阶段和开发阶段的输出物进行评审，以确认网络安全目标是否已实现，网络安全声明是否有效，开发过程中发现的弱点和漏洞是否得到了有效管理。需要注意的是，应保证网络安全确认的完整性和一致性，对于每项目标和声明确认的方法和理由应进行说明。
网络安全确认结束后应输出一份网络安全确认报告，该份报告应作为必要的交付物在SOP前完成交付。
