内容提要：在本文中，我们就如何在车辆的整个生命周期内对其进行管理提出了建议。汽车网络防御中心的建立是确保OEM车队安全运营的关键因素。我们阐述了为什么需要建立这样一个中心，它需要执行什么样的安全运营，以及哪些利益相关者参与了确保公共道路运输安全运营。

摘要

随着车辆转变为人类运输计算机器，需要更加具体地关注长期安全运行的问题。为了防止对车队的网络攻击，需要监控各个车辆的IT基础设施的内部状态。

在本文中，我们就如何在车辆的整个生命周期内对其进行管理提出了建议。汽车网络防御中心的建立是确保OEM车队安全运营的关键因素。在本文中，我们阐述了为什么需要建立这样一个中心，它需要执行什么样的安全运营，以及哪些利益相关者参与了确保公共道路运输安全运营。

由于网络防御中心和所需技术在经典IT基础设施中得到了完善，我们提出了一种使用这些技术的汽车架构，突出了从网络运营到车队运营过渡的差距。最重要的区别是车队的分布式、非同质化和游牧性质。

为了克服这一差距，我们提供了一个案例，旨在使用物联网技术使安全相关信息在网络防御中心内可供使用。

1.动机

今天的车辆有很多不同的在线连接点，例如乘客娱乐系统、实时交通导航、智能手机连接或软件更新。除了这些已经上市的消费服务，车辆将相互连接，车辆与公共基础设施（Vehicle-2-X/V2X）交互，以实现未来的自动驾驶场景。因此，将会有一个分布式系统，其中包含许多不同的利益相关者、不同的服务和不同的生态系统，具有控制公共交通的巨大攻击面。因此，有必要详细考虑车辆的（网络）安全性。

至少自2015年吉普车的在线远程攻击和无线控制以来，汽车制造商(OEM)也对安全性进行了深入研究。很明显，被黑客攻击的车辆除了造成经济损失外，还可能造成人身伤害。因此，需要一个从典型IT系统中获知的网络安全系统来确保车辆和后续运输的安全。

联合国(UN)关注这一主题的案例表明，它不仅对OEM的产品质量很重要，而且对人类的福祉也很重要。“联合国网络安全和OTA问题特别工作组(CS/OTA)”定义了网络安全系统的必要部分。其中包括具有事件响应功能的网络安全管理和监控系统。

2.最先进的网络防御中心

我们观察到，围绕网络安全管理使用了许多不同的方法、描述和定义。为了对本文的上下文进行分类，以下部分提供了本文中使用的定义的简短概述，并列出了一些专注于汽车领域的示例性公告和出版物。

2.1术语

欧盟于2004年成立了欧盟网络和信息安全机构，并于2018年商定了新的网络安全法案。

根据来自“联合国网络安全和OTA问题特别工作组(CS/OTA)”的UNECE WP.29 ITS/AD，需要建立一个网络安全管理系统（CSMS），以支持车辆在其整个生命周期内的安全。这补充了开发过程中漏洞处理的安全开发技术，即使在生产符合ISO/SAE 21434中描述的安全流程之后，也可以通过对汽车进行反应性监控来进行处理。

这种方法在其他一些企业中广为人知，这些企业通过信息安全运营中心(ISOC/SOC)保护其关键信息基础设施，并通过计算机或产品安全事件响应团队（CSIRT、PSIRT）对其系统或产品中的事件做出反应。

一种成熟的技术是使用安全信息和事件管理(SIEM)系统，该系统包含匹配特定事件日志记录信息的规则，以检测环境从而对可疑行为做出反应。

我们打算为汽车业务创建这样一个安全运营中心(SOC)，提供专门的服务来分析和应对车内、车与车之间的现场事件，并与OEM的后端系统进行数据通信。这意味着网络防御中心(CDC)是上述大多数元素的组合，用于保护正在运行的IT系统免受攻击，确保该系统的安全运行。

2.2定义汽车网络防御中心的角色和任务

上一节简要介绍了用于确保IT系统安全运行的不同资产或角色。可以说，网络防御系统的任务目前还没有明确定义。

IT和汽车行业的一些主要参与者针对类似的汽车网络防御中心(ACDC)发布了他们的计划或概念。这些想法源自前面章节中提到的概念，并由汽车典型主题进行扩展。汽车的典型主题主要是要处理的信息类型、将此信息传输到SOC以及为车辆生成和提供更新（空中更新-OTA）。

图1.ACDC是确保系统安全运行的不同元素的集合

下面列出了汽车和非汽车网络防御系统的例子：德国电信使用网络防御系统来保护他们的系统和客户系统，并且正在开发一个汽车网络防御中心。在华威大学的一个研究项目中，车辆安全系统对运行时间和处理能力的限制进行了详细审查。英国标准协会正在制定一项受自动驾驶驱动的汽车安全标准，在SAE的一项调查中，84%的汽车专业人士担心他们的组织网络安全实践跟不上不断发展的技术。博世正在为汽车安全引入一种完整的方法，包括制造IT安全、嵌入式IT安全和企业IT安全。Vector提到了网络防御中心的要素，但没有将它们组合起来。

可以说，所有这些提案都涉及上一章中提供的基本要素（比较图1）。这些示例表明汽车网络防御系统或中心正在开发中。今天，汽车领域没有可用于生产用途的商业或非商业CDC。尤其是没有适合车辆边界的整体解决方案。

3.ISO和UNECE的要求

关于ACDC的要求有两个主要来源。一方面，UNECE在WP.29 ITS/AD中宣布了一个用于运输系统的网络安全管理系统。另一方面是ISO/SAE 21434“道路车辆-网络安全工程”。为了获得概述，我们总结了本章【图2】中UNECE WP.29 ITS/AD和【图3】中ISO/IEC 21434的主要方面。

图2.UNECE WP.29 ITS/AD的要求：网络安全

图3.ISO/SAE 21434“道路车辆—网络安全工程”的要求

4.汽车CDC简介

汽车CDC是适应汽车环境的CDC。

4.1 ACDC的保护重点

与传统的CDC相比，ACDC不仅保护单个网络或IT基础设施，它还必须观察和保护公共道路基础设施内人员或货物运输周围的车辆和服务。原则上，存在要保护的系统的系统边界问题。在ACDC的情况下，这是与CDC相比的一个重要区别。

简单来说，可以假设ACDC必须观察单个车辆的行为以保护该车辆用户的安全。然而，这种观点似乎过于局限。在许多情况下，使用受感染的汽车攻击公共基础设施被认为是可能的。此外，我们还讨论了分布式(IoT)系统。众所周知，分布式系统中正确行为的证明是困难的。

总体目标是保护公共交通和所有可能因安全隐患而受损的实体。因此，整体重点需要远远超过单个车辆的安全运行。它需要以某种方式控制车辆行为的交通服务的安全运行。这显然可以是对汽车本身的攻击，也可以是对交通信息系统或V2X系统等的攻击。

4.2控制观测层

为了了解ACDC需要关注的不同视角和系统级别，我们建议为公共道路上的交通系统设置以下保护层（比较图4）。

1.公共交通安全运行（公共区域所有车辆）

2.OEM控制的移动服务的安全运行

3.车队安全运营

4.单车安全运行

运行的元素是车辆本身。由此，车辆可以抽象为一组网络和节点(ECU)。车辆运营商运营这些实体。我们的区别在于

5.车内网络的保护

6.保护车辆内的单个实体（例如ECU）

图4.运营层概览

两个较低层的汽车网络和ECU提供了观察车辆状态的功能，并且是车辆内防御活动的行动实体。

这些不同的观点可以转化为不同的利益相关者和不同层次的

─反应时间

─临界性

─自治

─数据聚合

─控制流

这些不同级别之间的关系如图5所示

图5.ACDC的不同视角和运营层

5.建议的ACDC架构

基于来自其他领域的参考架构，我们定义了ACDC的要求，并提出了一个包含其基本元素的架构。此外，我们展示了我们提出的架构如何适应实施。

5.1观察和控制层次结构

为了监视和控制所有层的安全运行，不同的CDC必须协同工作。ACDC的核心元素是车队运营和车辆运营层，因为它们是嵌入式车辆安全机制和典型IT SOC之间的链接。因此，我们专注于为这些层设计监控架构，并为其定义以下高层需求：

图6.ACDC架构的要求

为了创建一个满足这些要求的框架，我们不能完全遵循汽车标准。联网车辆可以看作是物联网中的事物，这也导致了与工业控制系统（ICS）的一些相似之处。因此，我们正在调整来自联网车辆、IoT和ICS的网络安全参考架构，这些架构显示出与ACDC要求的相似性，并且进一步符合IEC 62443以创建ACDC框架。

ICS的安全架构遵循普渡(大学)企业参考架构的改编。它基于定义安全区域，安全区域是共享共同安全要求和管道定义的一组逻辑或物理资产，管道定义是两个区域之间信息流的路径。正如所提议的，安全区域可以在信息技术(IT)和运营技术(OT)中分离，这使公共移动性和OEM移动性层可以由现成的IT SOC控制的方式适应这些层；而下层需要具有特殊汽车知识的OT SOC。

网络安全参考架构在OT安全区内提出了三个级别，这些级别将适应我们的框架：

1.I/O和设备

2.控制

3.监督

图7.车辆操作层和车队操作层的ACDC架构

建议的框架使用边缘计算，并基于安全设计原则以及类似领域的参考架构。提出了一种智能SOC架构，它显示了一个通用框架，但缺少一个抽象层，无法将其用于联网汽车。与此相反，文献1（关注“牛喀网”微信公众号后台咨询下载）中显示了一个用于管理安全事件和对联网汽车攻击做出响应的框架。假定SOC从车辆收集日志，并由事件响应团队进行协调。此外，还提供边缘计算解决方案以减少移动网络流量。这个概念正朝着正确的方向前进，但缺乏对多个独立层的分解。此外，通过附加网络防御系统的范围，使用IDS可以将更多智能带入车辆内部。文献2（关注“牛喀网”微信公众号后台咨询下载）中的多层网络安全参考架构推荐了一个运营层和一个智能层。运营层负责安全监控和事件响应，适配为车辆运营层。同样，进行详细威胁分析的情报层被改编为舰队作战层。使用边缘计算的最初选择是因为它经历了连接车辆的日益增长的使用。从更技术的角度来看，可以说边缘计算平台为软件部署和日志分析提供了各种内置功能[图.6，Req. ID 04]，[图.6，Req. ID 08]。此外，与使用第3方边缘计算平台的专有解决方案相比，减少了时间、开发成本、基础设施成本（无服务器计算），保证了控制级别的最先进安全机制，并促进了不同OEM之间的合作。

ECU和车辆网络保护层被抽象为安全传感器和安全执行器，因为它们使用的嵌入式硬件或软件安全机制不是该框架的重点。在车队运营和车辆运营层中，将实施监控和分析模块，以检测事件和分析攻击模式。事件响应模块将负责对某些事件做出反应。因此，边缘设备和云端的模块在自主性、反应时间和可用性方面有所不同。

作为车辆运营层的一部分，车辆ACDC充当综合IDS和IPS，可以自主启动简单的预防措施，例如调整防火墙规则或向驾驶员显示警告。车辆ACDC的功能不依赖于云连接，因为边缘模块始终在车辆内可用[图. 6，Req. ID 09]。每个事件也将由车辆ACDC转发到车队运营层进行进一步调查。因此，如果无法建立移动网络连接，车辆ACDC需要保留事件信息。图7中未明确显示的车辆运营层内的其他一般数据处理任务将改编自文献3（关注“牛喀网”微信公众号后台咨询下载）。对数据进行分类以确定是否需要更高级别的处理（评估）。对于这种更高级别的处理，数据应采用一致的格式（格式化）。此外，使用附加信息（扩展/解码）处理加密数据。由于车辆，尤其是车队会产生大量数据，因此对其进行汇总是为了减少车辆网络、移动网络和更高级别处理系统（蒸馏/减少）上的数据和流量。处理数据以确定它是代表阈值还是警报（评估）。

车队运营层的核心元素是ASIRT（汽车SIRT），它是OEM特定安全专家和来自不同领域（例如IT）的外部搜索团队的协作。ASIRT将调查车队中单个车辆的事件，并将所有车辆的信息串联起来，以发现车队内的异常情况。为了调查事件，ASIRT与公共机构（例如研究人员）、私营部门供应商（例如tier1、服务提供商）和威胁交换平台（例如开放威胁交换）等外部实体交换信息。ASIRT将启动反措施，这些措施将由车辆ACDC报告的事件、车队ACDC检测到的事件或外部实体报告的威胁触发。应对措施可以是为车队部署的安全更新，这导致需要车队软件管理模块来识别所有需要特定更新的车辆。

5.2实现示例

作为概念证明，我们使用Microsoft的边缘计算解决方案Azure IoT edge实现了图7中的架构，这是因为汽车OEM在云和边缘计算应用方面处于领先地位。

每个设备必须至少具有边缘集群、边缘代理、容器引擎和安全守护程序。边缘集群充当物联网集群（云GW）的代理，并支持每个设备上的模块间通信。边缘代理实例化模块并监视其状态。云或边缘设备中的所有模块都在容器中执行。因此，需要一个与开放容器计划（例如Docker）兼容的容器引擎。安全守护程序管理证书并建立安全的设备内通信以及设备到云通信。Azure IoT Edge使用基于TLS1.2和X.509证书的HTTPS连接进行设备到云通信，这是OSI模型的传输层之上安全通信的最新技术。

图8.示例的ACDC架构

物联网中心负责设备配置和所有端点之间的消息路由。通过使用ELK堆栈（Elasticsearch、Logstash、Kibana）实现车队监控和车队分析；一个开源项目，可以同时处理和转换来自多个来源的数据。搜索引擎是基于JSON的，因此日志和事件报告以JSON格式转发。ELK堆栈还提供了一个可视化工具，可帮助ASIRT调查事件。

车队软件管理可以实现为存储来自每辆车的元数据的数据库。在设备配置期间，车队软件管理数据库中会创建一个条目，只要车辆的软件发生变化，该条目就会进一步更新。作为补救管理措施，可以提供包含ECU更新包的安全更新。车辆修复模块将在合适的时间启动更新过程；这可能是在驾驶员将车辆停在家里并同意开始更新过程之后。

考虑到车辆操作层和车队操作层层间和层内通信，需要至少四个接口才能报告事件或部署安全更新：

1.将日志和安全传感器事件转发到边缘设备的接口。

2.控制安全执行器的接口。

3.将日志和车辆元数据（例如位置）转发到云端的接口。

4.启动补救措施和转发安全更新的接口。

6.讨论与展望

正如我们所展示的，由于联网车辆及其环境中的潜在威胁，网络安全机制的使用越来越多，这需要多个系统来管理不同层的安全运营。为了实现安全传输，必须建立每一层的安全运营及其交互。因此，OEM必须实例化一个安全运营中心和更好的网络防御中心。大部分技术都是可用的。最重要的课题是将信息从车辆传输到运营中心，以及为车辆提供软件或配置更新等安全措施。为此，我们建议使用物联网方法，因为它们已成功集成到其他领域。

为确保公共道路交通的安全运行，不同OEM和基础设施的运营中心必须进行交互，以交换有关可能的攻击和漏洞的信息。OEM需要考虑网络防御中心的架构和接口，因为需要在其车辆内构建支持。OEM很可能不会自己运营网络防御中心。

为了实现这一目标，我们提出了这个架构，该架构可以适应其他领域（例如ICS）的架构元素，并额外考虑UNECE WP.29 ITS/AD和ISO/SAE 21434的要求。

6.1讨论

可以说，从车辆到OEM后端的数据传输、大量结果数据的处理、隐私要求以及最后ACDC可以运营单个车辆的模式，是未来需要进行研究的关键主题。对于数据的传输、存储和处理，有很多机制可以从其他行业重用。但如果有人使用来自车辆的数据，则尤其需要讨论隐私主题。如果需要观察车辆，立法者必须定义如何使用这些信息的界限。

此外，为了让运营人员通过ACDC控制车辆本身，需要汽车专有的解决方案，以确保车辆的安全性和稳定性。

6.2展望与未来工作

需要对本文中提供的概念实施证明进行评估，以确定其在边缘计算机制这一新用例中的性能、局限性和可扩展性。

此外，需要研究ACDC在运行时如何运行车辆的方式。已经建立的机制之一是车辆的在线更新功能。但是更新无法实时对威胁做出反应。一种可能的解决方案是在车辆内预配置后备方案，该方案可由运营人员控制。需要研究此解决方案或其他解决方案，以找出其局限性及其确保车辆控制系统安全目标的能力。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！