一个涵盖整个车辆生命周期和生态系统的网络安全管理系统CSMS

摘要    

网络安全越来越被认为是汽车系统的一个重要话题，特别是在联网和自动驾驶领域。即将出台的法规对汽车领域的网络安全提出了多层次的要求，以获得型号批准。在组织层面，需要一个涵盖整个车辆生命周期和生态系统的网络安全管理系统（CSMS）。此外，必须对申请型号批准的每一种车辆类型的网络安全进行论证。

由于这些要求与现有的型号批准要求相比具有新颖性，因此正在进行测试阶段。CSMS的组成部分和范围是一个开放的问题。本文概述了CSMS的要求，确定了方法和差距，并对能够满足这些要求的潜在框架进行了展望。

I.简介

汽车正在从孤立的、主要是电子机械系统向带轮子的连接计算机发展。目前，这是由监管和汽车工业提供额外服务的愿望所驱动的。进一步迈向部分和全自动化的车辆只会加速这一趋势。像进一步减少交通事故或减少交通能源这样的目标，只有通过合作和自动驾驶车辆才能实现。为了实现安全、自动化和交互的车辆，网络安全需要提高。最近的评估和披露显示，目前车辆的几乎所有连接元件都存在多个漏洞。

为了确保越来越高的安全水平，联合国欧洲经济委员会（UNECE）WP29自动驾驶/自主驾驶和联网汽车工作组（GRVA）启动了一个网络安全和软件更新（CS/OTA）的特别小组。图1给出了作为UNECE WP29的缔约国的62个国家的概况（状态2016）。签约国意味着在这些国家销售车辆所需的车辆型号认证是基于ECE的法规。在此，我们将重点讨论整车型式认证（WVTA）。图2给出了关于车辆类型批准过程的概述。



图2. 整车型式认证（WVTA）过程

该工作组制定并提交了一份关于整合网络安全和软件更新的法规以进行车辆类型审批的建议。关于网络安全的建议包含以下几章： (1)简介 (2)定义（和缩略语） (3)网络安全原则 (4)对车辆系统和生态系统的威胁 (5)缓解措施 (6)网络安全程序的要求和如何证明其应用 (7)结论和对进一步程序的建议 (8)附件A 关于引入网络安全条例的建议草案 (9)附件B 威胁和相应的清单 (10)附件C 与缓解措施有关的安全控制措施清单，包括例子。

(11)附件D 参考文件清单 根据已交付的建议，目前有一个测试阶段正在进行。在这个测试阶段，对需求进行评估，必要时进行完善。同时，指导文件也被制定。 在第二节中重点讨论了网络安全流程的要求和如何证明其应用，以及附件A关于引入网络安全条例的建议草案，以确定和分析汽车领域的网络安全流程要求。

之后，在第三节中概述了汽车网络安全的现有构建模块和开放点。在第四节中，提出了一个起点来定义一个符合CSMS的流程，涵盖整个生命周期。

II.对网络安全流程的要求和拟议的法规

建议的要求分为三个部分。第一部分描述了汽车行业中网络安全管理系统（CSMS）的要求。下一节描述了后期生产阶段的要求，最后一节涉及到车型的批准。对于拟议的法规，有一个章节描述了cms合规证书，一个章节描述了网络安全管理系统的要求，然后是车辆类型的要求。在下面几节中总结了这些需求。

A.网络安全管理系统

网络安全管理系统是一个总的结构，它收集了所有与网络安全有关的过程。汽车制造商必须确保供应商和服务提供商实施CSMS。 

制造商及其供应商和服务提供商的CSMS由审批机构或技术服务部门评估。虽然审批机构或技术服务部门可以在任何时候要求重新评估，但基本有效期为三年。如果有可能影响评估的变化，车辆制造商必须通知审批机构或技术服务部门。CSMS中定义的流程必须包括开发、生产和后期生产，并考虑对车辆的风险和威胁的监测以及事故响应流程。 对于流程的定义需要在汽车领域的不同生命周期之间有所区别(参见图3)。对于欧洲经委会的条例，生命周期是指车辆类型的生命周期，例如从开发到开始生产到停止生产。如果看一下ISO 26262]和SAE J3061，生命周期的重点是一个系统（元素，组件）的工程，可以在多个车辆中使用。对于车辆本身，有生产、使用和退役的生命周期。为了获得型号批准，例如，开始生产，OEM需要证明该组织和所有参与的供应商都有一个经过认证的CSMS。


 
图3.汽车领域的不同生命周期 这些流程需要确保安全问题得到充分考虑，并包括以下重点：

•组织中的网络安全管理

•对车辆类型风险的管理（识别、评估、归类和处理）

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

•在开发和生产过程中的安全测试

•检测和应对针对车辆类型的网络攻击

•识别和管理新的网络威胁和车辆类型的脆弱性

•风险评估的更新

此外，汽车制造商必须确保所有流程在分布式开发环境中工作。

B.后期生产阶段

对生产后阶段的要求主要是对CSMS的要求进行细化，以确保网络安全被整合到车辆的生命周期中。车辆制造商必须证明如何在车辆生命周期内保持对法规的遵守和保护。这包括监测威胁状况和漏洞的变化。需要对已实施的安全措施的有效性进行监测。重点是确保不断变化的环境不会导致对安全和可用性的影响。为了确保这一点，需要建立事件响应程序。

C.车辆类型

只有当原始设备制造商和所有供应商的CSMS认证到位后，才能进行整车型式批准。整车型式批准的证据需要包括： •在风险评估中如何考虑已知的漏洞和威胁。风险评估需要考虑整个车辆、所有车辆系统以及它们之间的相互作用。 •在风险评估中被确定为关键的要素，被设计成适当的安全措施，以使风险降低到可接受的水平。

要素包括： –车辆架构和系统 –与网络安全有关的组件和系统 –与网络安全有关的部件和系统与其他车内和外部系统之间的相互作用 •从确定的风险到实施的缓解措施再到测试结果的追踪，以证明所有的风险都得到了充分的覆盖

如果车辆支持售后软件、服务、应用程序或数据的存储或执行，则需要有专门的受保护环境。所需要的信息需要通过整个供应链收集和验证。

III.汽车网络安全框架的技术现状

UNECE对CSMS的要求是一个完整的网络安全流程框架，涵盖了在整个车辆生命周期中与实现网络安全相关的所有活动。它必须涵盖所有可能影响网络安全的利益相关者。这个框架应该产生证据，证明为什么车辆的网络安全得以实现。 虽然这样的整体框架还不存在，但已经有了发展的起点。我们将在接下来的章节中概述a）汽车领域现有的网络安全流程和b）现有的保证方法。在这个过程中，必须在以下方面有所区别：

•在开发、生产和后期制作中管理网络安全的流程

•处理汽车领域的分布式性质的过程

第一套流程可以被概括为风险管理流程，第二部分可以被概括为汽车供应链管理。

A.汽车网络安全风险管理

ISO 31000中提出了通用的风险管理流程。风险管理被定义为一个反复的过程，它必须在整个生命周期中执行。NIST对组织和系统层面的风险管理进行了更详细的描述。

这两种方法都在高层次上涵盖了CSMS风险管理的要求。

1)风险识别：汽车风险识别的一个著名方法是威胁建模。事实表明，威胁建模可以贯穿整个车辆生命周期，用于识别由于设计漏洞和潜在威胁造成的风险，甚至可以用来监测已部署系统的漏洞。

最近的方法证明了威胁建模如何支持安全测试过程，也可以作为安全和保障的组合方法的一部分。威胁建模依赖于有关威胁和网络安全状况的最新知识，其中包括对整体威胁状况的监测，也包括对车辆的取证能力。

2)风险评估：对于风险评估，存在不同的方法，这些方法部分包含在风险识别方法中。一个成熟的方法是由评估攻击概率的通用标准来定义的。攻击概率可以根据现有的信息和生命周期阶段进行调整。这被用作EVITA项目的出发点。在HEAVENS项目中，收集了一套风险识别和评估方法并发表了报告。在CySiVuS项目中，开发了一个基于FAIR的统一的安全和保障的定量风险评估。

3)风险归类：风险分类目前仍是一个开放的话题。现有的方法是，它将威胁分为安全相关和非安全相关。在提出了安全、财务、操作和隐私（SFOP）的分类。其他方法使用自动方法对风险进行分类。

4)风险处理：风险处理包括所有适合缓解和减少风险的措施，以及验证所应用措施有效性的必要步骤。深度防御策略是汽车领域的一个合适的出发点。

在此基础上，风险处理的技术措施主要分为四个层次。

1)接口：现代汽车拥有广泛的接口，可以作为潜在的攻击面。我们的目标是尽量减少接口的数量，并确保所有的接口都受到保护。

2)网关：网关用于互联不同的总线系统，因此很适合放置额外的安全措施，以隔离网络部分和控制访问。

3)网络：汽车车辆使用多个内部通信系统，为各自的性能和安全要求量身定做。性能限制了密码学解决方案的适用性。由于机器对机器通信的预定性质，入侵检测系统是一个很好的方法。

4)控制单元:保护控制单元的大多数方法都使用基于硬件的安全性，以确保设备完整性、关键功能的隔离和启用受保护的存储。这些方法也可以用于篡改保护和确保安全引导。 风险管理的过程需要被整合到生命周期中，以确保在生命周期的正确阶段考虑风险识别、评估和分类，并确保以安全的方式实施风险处理措施。

5)过程:为了安全开发，最早的方法之一是SAE J3061，它基于ISO 26262定义的过程模型。ISO/SAE 21434是汽车系统网络安全工程标准的进一步发展，计划于2020年发布。 除了这些主要关注于整体工程过程的标准外，IEC 62443还适用于生产环境和NIST出版物，如用于密钥管理。另外，安全编码指导和如何使用基于硬件的安全指导也可以被整合。

B.汽车网络安全供应链管理

根据UNECE的要求，这里的供应链不仅包括汽车工业的分层结构，还包括售后市场。 对于汽车领域的互动，确保供应商的网络安全能力的方法可以基于现有的能力和评估方案。

例如，OEM可以要求其供应商根据TISAX评估证明其系统的信息安全，以确保关键信息得到保护。一个受保护的生产环境可以通过基于IEC 62443的环境评估来证明。汽车SPICE评估，扩展了安全，也可用于评估流程。

对于责任和任务的分配，可以使用现有的安全的方法。开发界面协议（DIA）是为安全关键系统的分布式开发而开发的。类似的接口协议可以用来定义车辆生命周期不同阶段的责任。例如，监测不断变化的威胁和漏洞的责任可以由汽车制造商以外的组织来承担。我们看到像AUTO-ISAC这样的组织在这方面的初步做法。

在这里，关于如何分享事件信息的方法也很重要。图4给出了不同类型的接口协议如何涵盖生命周期的不同阶段的例子。



图4. 生命周期中不同接口协议的例子

与汽车制造商没有合同关系的组织的管理更具挑战性。反向工程显示，许多目前可用的安卓汽车信息娱乐系统应用程序包括潜在的漏洞。这里的问题是，汽车制造商是否可以通过为第三方应用程序提供安全的执行环境来解决这个问题，或者除此之外，系统需要被限制，只允许由汽车制造商测试的应用程序。

一个类似的分析表明，当车辆在维修店访问时，诊断界面是一个潜在的风险因素。解决这个问题的一个建议是扩展的车辆概念。扩展的车辆概念包括由外部组织控制对车辆数据的访问，该组织根据实施情况充当数据交换中心或认证机构。这里的一个挑战是安全和控制访问与竞争法的规定之间的潜在冲突。

C.汽车网络安全保障

根据ISO/IEC/IEEE 15025-1的定义，保证是 "有理由相信一项要求已经或将要实现"。这是通过一个保证案例来完成的，该案例由一个系统的论证及其支持的证据和假设组成，以证明一个最高级别的要求已经实现。虽然ISO/IEC/IEEE 15025对保证案例的结构给出了数学定义，但GSN等图形符号也有好处。这两种方法都有一个挑战，那就是需要考虑网络安全不断发展的性质，例如，威胁者的能力在不断增强。

证据需要显示网络安全的完整性和充分性。完整性表明，根据目前的最先进的技术，所有的风险都得到了考虑。充分性表明，处理风险的方式是充分的。 

完整性可以通过提供证据证明在整个生命周期内采用了系统的程序来证明。充分性的证据需要表明风险得到了充分的处理。这方面的保证要求可以从通用标准和NIST的测试指南中获取。提出的技术从文件审查开始，包括对已经使用的系统进行持续测试和评估的技术。对于网络安全保障来说，一个挑战是如何确定什么时候产生的证据是足够的。

IV.CSMS框架

正如前面几节所概述的，需要一个总体框架，涵盖完整的生命周期并整合开发和运营。我们提出了一种DevOps的方法，它适合于将开发、生产和运营的过程构建成一个一致的框架。提出的框架是基于Dobaj等人以前的工作，结构上分为两个主要部分，如图5所示：

1)第五代的车辆E/E架构，首先，能够将车辆系统连接到云系统，以便继续监测；其次，提供技术基础，以建立一个可以轻松更新和重新配置的模块化系统架构。

2)在模块化的E/E架构之上，可以建立一个DevOps生命周期，以实现持续的改进周期。



图5. 拟议的DevOps框架涵盖了从开发到生产再到运营的整个车辆生命周期 监控和分析过程是这个生命周期的核心特征，因为这些过程为检测开发和运行期间的故障和安全事件提供了基础。 如图5中的V型模型所示，拟议的DevOps框架与基于V型模型的传统系统开发流程是兼容的。无论是系统开发周期还是系统改进周期，都由同样的三个主要阶段组成：计划、创建/实施和验证与确认（V&V）。

开发周期由业务需求触发，而改进周期则由监控和分析过程自动触发，只要在V&V阶段或车辆运行期间检测到故障或安全事件。 在成功的V&V阶段之后，在持续的质量阶段进行集成测试、故障注入测试和渗透测试，以保证系统的安全、保障和质量。

在随后的发布阶段，代码签名和信息安全管理被应用，以提供一种措施来确保分布式软件部署过程中的系统完整性。在随后的预防阶段，安全由每辆车单独确保。异常情况会在本地进行分析，并传送到外部系统进行进一步调查。

每当车辆运行过程中检测到事故或故障，响应阶段就会转发一份报告。然后，该响应在预测阶段由人工处理和分析，或通过[50]中提出的自动推理机制进行处理和分析。获得的结果被转发到故障或事件库，这是CSMS的一部分。这个存储库在适应阶段经常被扫描，根据优先级标准，选择一个报告的故障或事件进行调查，从而触发下一个持续改进周期。

V.结论

本文提出了在汽车领域即将到来的网络安全法规的挑战，并确定了现有的构建模块。对于CSMS的整体结构，介绍了一种DevOps的方法。 公开的挑战是将构件映射到DevOps流程中，例如，对流程进行细化以包括方法和活动。此外，需要一个分布式的DevOps流程来考虑汽车领域的分层结构，而即将出台的法规不仅涉及网络安全，还涉及软件更新，需要通过质量认证。认证取决于保证，这需要考虑汽车工程的分布式性质和网络安全的演变性质。

审核编辑：刘清