汽车网络安全管理系统的需求分析及潜在框架设计

摘要

网络安全日益被视为汽车系统的核心议题，尤其是在联网驾驶和自动驾驶领域。即将出台的法规对汽车领域多个层面的网络安全提出了要求，以实现车型认证。在组织层面，需要一套覆盖整个车辆生命周期和生态系统的网络安全管理系统（CSMS）。此外，还需为申请车型认证的每款车型提供网络安全论证。与现有车型认证要求相比，这些新要求具有创新性，目前相关测试阶段正在进行中。网络安全管理系统（CSMS）的组成部分和适用范围仍是一个开放性问题。本文概述了网络安全管理系统（CSMS）的要求，明确了相关方法和存在的差距，并对可满足这些要求的潜在框架进行了展望。

一、引言

车辆正从孤立的、以机电一体化为主的系统，逐渐向带车轮的联网计算机转变。这一趋势目前受到法规要求以及汽车行业提供附加服务意愿的推动。向部分自动驾驶和完全自动驾驶车辆的进一步发展，将只会加速这一转变。只有通过协同式自动驾驶车辆，才能实现进一步减少交通事故、降低交通能耗等目标。为实现安全、自动化且具备交互能力的车辆，必须加强网络安全。近期的评估和披露表明，当前车辆中几乎所有联网组件都存在多个漏洞。

图 1、参与世界车辆法规协调论坛的国家

为确保安全水平的持续提升，联合国欧洲经济委员会（UNECE）第 29 工作组（WP29）下属的自动驾驶与联网车辆工作组（GRVA）成立了网络安全与软件更新（CS/OTA）任务组。图 1 展示了 2016 年加入联合国欧洲经济委员会（UNECE）第 29 工作组（WP29）的 62 个缔约国概况。缔约国意味着，在这些国家销售车辆所需的车辆型式认证需基于欧洲经济委员会（ECE）法规。本文将重点关注整车型式认证（WVTA）。图 2 概述了车辆型式认证流程。

图 2、整车型式认证（WVTA）流程

该任务组已制定并提交了一项建议，旨在将网络安全和软件更新相关法规纳入车辆型式认证体系。该网络安全建议包含以下章节：

引言
定义（及缩写）
网络安全原则
车辆系统及生态系统面临的威胁
缓解措施
网络安全流程要求及其应用证明方法
结论与后续工作建议
附件 A：引入网络安全法规的提案草案
附件 B：威胁清单及相应内容
附件 C：与缓解措施相关的安全控制清单（含示例）
附件 D：参考文件清单

基于提交的建议，目前相关测试阶段正在进行中。在测试阶段，将对各项要求进行评估，并在必要时进行完善。同时，相关指导文件也在编制中。

第二节将重点关注 "网络安全流程要求及其应用证明方法" 章节以及附件 A "引入网络安全法规的提案草案"，以识别和分析汽车领域网络安全流程的相关要求。之后，第三节将概述汽车网络安全的现有构成要素和待解决问题。第四节将提出一个合规的网络安全管理系统（CSMS）流程定义起点，该流程将覆盖完整的生命周期。

二、网络安全流程要求及拟议法规

拟议要求分为三个部分。第一部分描述了汽车领域网络安全管理系统（CSMS）的要求；第二部分描述了生产后阶段的要求；最后一部分涉及车型认证相关要求。拟议法规中包含网络安全管理系统（CSMS）合规证书相关章节、网络安全管理系统（CSMS）要求相关章节，以及车型要求相关章节。以下各节将对这些要求进行总结。

（一）网络安全管理系统（CSMS）

网络安全管理系统（CSMS）是一个总体框架，涵盖所有与网络安全相关的流程。车辆制造商必须确保供应商和服务提供商均实施网络安全管理系统（CSMS）。制造商及其供应商和服务提供商的网络安全管理系统（CSMS）将由认证机构或技术服务机构进行评估。认证机构或技术服务机构可随时要求重新评估，该评估的基本有效期为三年。若发生可能影响评估结果的变更，车辆制造商必须通知认证机构或技术服务机构。网络安全管理系统（CSMS）中定义的流程必须涵盖开发、生产和生产后阶段，并考虑车辆风险与威胁的监控以及事件响应流程。

对于这些流程，我们需要区分汽车领域中不同的生命周期定义（见图 3）。根据联合国欧洲经济委员会（UNECE）法规，生命周期指车型的生命周期，例如从开发、量产启动到停产。而在 ISO 26262和 SAE J3061中，生命周期侧重于可用于多款车辆的系统（元件、组件）的工程设计过程。对于车辆本身而言，其生命周期包括生产、使用和报废阶段。为获得型式认证（例如启动量产），原始设备制造商（OEM）需证明其自身及所有相关供应商均已获得网络安全管理系统（CSMS）认证。

图 3、汽车领域的不同生命周期

这些流程必须确保充分考虑安全性，并包含以下重点：

· 组织内的网络安全管理

· 车型相关风险的管理（识别、评估、分类和处理）

· 已识别风险的充分管理验证

· 开发和生产阶段的安全测试

· 车型网络攻击的检测与响应

· 车型新网络威胁和漏洞的识别与管理

· 风险评估的更新

此外，车辆制造商必须确保所有流程在分布式开发环境中有效运行。

（二）生产后阶段

生产后阶段的要求主要是对网络安全管理系统（CSMS）要求的细化，以确保网络安全融入车辆全生命周期。车辆制造商必须证明如何在车辆生命周期内持续遵守法规要求并维持防护水平。这包括监控威胁态势和漏洞的变化，以及监控已实施安全措施的有效性。核心目标是确保环境变化不会对安全性和可用性造成影响。为实现这一目标，必须建立事件响应流程。

（三）车型要求

只有当原始设备制造商（OEM）及所有供应商均已建立经认证的网络安全管理系统（CSMS）时，才能进行整车型式认证。整车型式认证的证明材料需包括：

· 风险评估中如何考虑已知漏洞和威胁。该风险评估需涵盖整车、所有车辆系统及其相互作用。

· 风险评估中确定的关键元件，其设计方式和所采用的安全防护措施需能将风险降低至可接受水平。关键元件包括：

· 与网络安全相关的车辆架构和系统

· 与网络安全相关的组件和系统

· 与网络安全相关的组件和系统与其他车载系统及外部系统之间的交互

· 从已识别风险到实施缓解措施再到测试结果的追溯，以证明所有风险均已得到充分覆盖。

若车辆支持存储或运行售后软件、服务、应用程序或数据，则需建立专门的受保护环境。相关所需信息需通过整个供应链收集并验证。

三、汽车网络安全框架的现状

联合国欧洲经济委员会（UNECE）对网络安全管理系统（CSMS）的要求是建立一个完整的网络安全流程框架，涵盖车辆全生命周期内所有与实现网络安全相关的活动。该框架需覆盖所有可能影响网络安全的相关方，并应能提供车辆网络安全已实现的相关证据。

尽管此类整体性框架尚未完全建立，但已存在一些初步成果。以下各节将概述：a）汽车领域现有的网络安全流程；b）现有的防护方法。在此过程中，需区分以下两类流程：

· 开发、生产和生产后阶段的网络安全管理流程

· 应对汽车领域分布式特性的流程

第一类流程可概括为风险管理流程，第二类流程可概括为汽车供应链管理流程。

（一）汽车网络安全风险管理

ISO 31000提出了通用风险管理流程。风险管理被定义为一个迭代过程，需在整个生命周期内执行。美国国家标准与技术研究院（NIST）在组织层面和系统层面对风险管理进行了更详细的描述。这两种方法在较高层面上均满足了网络安全管理系统（CSMS）风险管理的要求。

风险识别：威胁建模是汽车领域广泛认可的风险识别方法。研究表明，威胁建模可在车辆全生命周期内用于识别因设计缺陷和潜在威胁引发的风险，甚至可用于监控已部署系统的漏洞。近期研究还展示了威胁建模如何支持安全测试流程，并可作为安全与安保综合方法的一部分。威胁建模依赖于最新的威胁和网络安全态势知识，包括对整体威胁态势的监控以及车辆的取证能力。

风险评估：风险评估方法多样，部分已融入风险识别方法中。通用准则 [21] 定义了一种成熟的风险评估方法，可评估攻击概率。攻击概率可根据可用信息和生命周期阶段进行调整。EVITA 项目以及文献均以此为起点。HEAVENS 项目收集并发布了一系列风险识别和评估方法。CySiVuS 项目基于 FAIR（信息风险分析框架）开发了一套统一的安全与安保定量风险评估方法。

风险分类：风险分类目前仍是一个开放性问题。现有方法包括将威胁分为安全相关或非安全相关，以及提出的安全、财务、运营和隐私（SFOP）分类法。其他方法则采用自动化方式进行风险分类。

风险处理：风险处理包括所有适用于缓解和降低风险的措施，以及验证所应用措施有效性的必要步骤。纵深防御策略是汽车领域合适的起点。基于此，风险处理的技术措施主要分为四个层面：

· 接口：现代车辆拥有多种接口，这些接口可能成为潜在的攻击面。目标是尽量减少接口数量，并确保所有接口均受到保护。

· 网关：网关用于连接不同的总线系统，因此非常适合部署额外的安全措施，以隔离网络部分并控制访问权限。

· 网络：汽车采用多种内部通信系统，这些系统是根据相应的性能和安全要求量身定制的。性能限制了加密解决方案的适用性。由于机器对机器通信具有预定义特性，入侵检测系统是一种有效的方法。

· 控制单元：大多数控制单元安全防护方法采用硬件级安全技术，以确保设备完整性、关键功能隔离，并支持受保护存储。此类方法还可用于防篡改保护和确保安全启动。

风险管理流程需融入生命周期，以确保在生命周期的正确阶段考虑风险识别、评估和分类，并确保以安全的方式实施风险处理措施。

流程：在安全开发方面，SAE J3061是较早的方法之一，其基于 ISO 26262定义的流程模型。ISO/SAE 21434 是进一步的发展成果，作为汽车系统网络安全工程标准。

除了这些主要关注整体工程流程的标准外，IEC 62443适用于生产环境，美国国家标准与技术研究院（NIST）的相关出版物适用于密钥管理。此外，还可融入安全编码指南和硬件级安全使用指南。

（二）汽车网络安全供应链管理

根据联合国欧洲经济委员会（UNECE）的要求，此处的供应链不仅包括汽车行业的层级结构，还包括售后市场。

在汽车领域的合作中，确保供应商网络安全能力的方法可基于现有的能力评估方案。例如，原始设备制造商（OEM）可要求其供应商通过 TISAX 评估来证明其系统的信息安全水平，以确保关键信息得到保护。可通过基于 IEC 62443的环境评估来证明生产环境的安全性。扩展了安全要求的汽车 SPICE 评估也可用于流程评估。

对于责任和任务的分配，可采用安全领域的现有方法。开发接口协议（DIA）是为安全关键系统的分布式开发而制定的。类似的接口协议可用于定义车辆生命周期不同阶段的责任。例如，可由车辆制造商以外的组织负责监控不断演变的威胁和漏洞态势。AUTO-ISAC 等组织已率先开展了相关工作。此外，事件信息共享方法也至关重要。图 4 展示了不同类型的接口协议如何覆盖生命周期不同阶段的示例。

图 4、生命周期内不同接口协议的示例

对于与车辆制造商无合同关系的组织的管理则更具挑战性。逆向工程表明，目前许多可用的 Android Auto 信息娱乐应用程序存在潜在漏洞。问题在于，车辆制造商是否可通过为第三方应用程序提供安全的执行环境来解决这一问题，或者是否需要限制系统仅允许经车辆制造商测试的应用程序运行。

一项类似的分析表明，当车辆进入维修店时，诊断接口是一个潜在的风险因素。解决这一问题的一个提案是扩展车辆概念。该概念要求车辆数据的访问由外部组织控制，该组织根据实施方式可充当数据交换中心或认证机构。其中一个挑战是，安全性和受控访问与竞争法法规之间可能存在冲突。

（三）汽车网络安全防护

根据 ISO/IEC/IEEE 15025-1 的定义，防护是 "有充分理由确信某项声明已实现或将要实现的依据"。这通过防护案例实现，防护案例由系统的论证过程及其支持证据和假设组成，用于证明顶层声明已实现。尽管 ISO/IEC/IEEE 15025 为防护案例的结构提供了数学定义，但图形符号（如 GSN）也具有一定优势。这两种方法都面临一个挑战，即需要考虑网络安全的动态演变特性（例如，威胁行为者的能力不断增强）。

证据需证明网络安全的完整性和充分性。完整性表明，基于当前技术水平，所有风险均已被考虑；充分性表明，风险处理方式是适当的。完整性可通过提供证据证明在整个生命周期内应用了系统的流程来体现。充分性的证据需表明风险已得到充分处理。相关防护要求可参考通用准则和美国国家标准与技术研究院（NIST）的测试指南。拟议技术从文档审查开始，包括对已投入使用系统的持续测试和评估技术。对于网络安全防护而言，一个挑战是确定所生成的证据何时足够充分。

四、网络安全管理系统（CSMS）框架

如前几节所述，需要一个总体框架，涵盖完整的生命周期，并整合开发和运营环节。本文提出一种 DevOps 方法，该方法适合将开发、生产和运营流程构建为一个统一的框架。该拟议框架基于Dobaj等人的前期研究，分为两个主要部分，如图 5 所示：

第五代车辆电子电气（E/E）架构：首先，该架构支持车辆系统与云系统的连接，以实现持续监控；其次，为构建可轻松更新和重新配置的模块化系统架构提供技术基础。

在模块化电子电气（E/E）架构之上，可建立 DevOps 生命周期，以实现持续改进循环。监控和分析流程是该生命周期的核心特征，因为这些流程为在开发和运营阶段检测故障和安全事件提供了基础。

图 5、拟议的 DevOps 框架，涵盖从开发、生产到运营的车辆全生命周期

如图 5 中的 V 模型所示，拟议的 DevOps 框架与基于 V 模型的传统系统开发流程兼容。系统开发周期和系统改进周期均包含三个主要阶段：规划、创建 / 实施以及验证与确认（V&V）。开发周期由业务需求触发，而改进周期则由监控和分析流程自动触发，每当在验证与确认（V&V）阶段或车辆运营过程中检测到故障或安全事件时，便会启动改进周期。

在验证与确认（V&V）阶段成功完成后，将在持续质量阶段进行集成测试、故障注入测试和渗透测试，以确保系统的安全性、可靠性和质量。在后续的发布阶段，将应用代码签名和信息安全管理，为确保分布式软件部署过程中的系统完整性提供防护。在后续的预防阶段，每辆车辆将独立确保安全性。车辆将在本地分析异常情况，并将相关信息传输至外部系统进行进一步调查。

每当在车辆运营过程中检测到事件或故障时，响应阶段将提交报告。该响应随后将在预测阶段进行处理和分析，分析方式可为人为手动分析，或通过自动推理机制进行。所得结果将提交至网络安全管理系统（CSMS）中的失效或事件数据库。在适应阶段，将定期扫描该数据库，并根据优先级标准选择需要调查的已报告故障或事件，从而触发下一个持续改进周期。

五、结论

本文阐述了汽车领域即将出台的网络安全法规所带来的挑战，并明确了现有的构成要素。针对网络安全管理系统（CSMS）的整体结构，本文引入了 DevOps 方法。

目前面临的开放性挑战包括：将各构成要素映射到 DevOps 流程（例如，细化流程以纳入具体方法和活动）；考虑到汽车领域的层级结构，需要建立分布式 DevOps 流程；即将出台的法规（不仅涉及网络安全，还包括软件更新）需要制定认证质量关口。认证依赖于防护措施，而防护措施需要考虑汽车工程的分布式特性和网络安全的动态演变特性。