37、汽车系统的网络安全监控、漏洞管理与更新解决方案-优快云博客

本文链接：https://blog.youkuaiyun.com/stem5/article/details/151603832

汽车系统的网络安全监控、漏洞管理与更新解决方案

1. 汽车系统网络安全现状与挑战

随着汽车连接能力和先进软件的增加，汽车系统面临着新的网络安全挑战。传统上，由于攻击向量有限，汽车并非网络攻击的主要目标，因此持续的网络安全监控活动需求不大。但如今，越来越多的汽车可能成为攻击目标，汽车组织需要建立网络安全监控流程。

例如，2017 年 10 月发布的一个汽车相关软件包包含了 2017 年 2 月发布的开源组件 curl（版本 7.53.1）。然而，在 2018 年 3 月，即软件包发布仅五个月后，curl 中就发现了三个关键漏洞（CVE - 2017 - 8816、CVE - 2017 - 8817、CVE - 2018 - 1000120）。如果没有适当的持续网络安全监控流程，汽车组织可能无法及时知晓软件发布后不久发现的关键漏洞。

此外，汽车软件更新能力不足也是一个挑战。汽车软件更新通常由汽车修理厂进行，部分软件可通过空中下载（OTA）更新，还有部分可由用户通过车辆的 USB 接口更新。调查显示，61%的组织没有能够及时解决关键安全漏洞的软件更新交付模型，只有 37%的组织具备 OTA 更新能力。因此，当检测到关键安全问题时，修复受影响车辆的漏洞的方法可能有限。

2. 解决方案概述

为应对上述挑战，提出了一个基于三步流程的解决方案：
- 发布管理 ：明确了解发布的软件及其版本，以及软件发布到哪些车辆和系统。
- 监控与跟踪 ：具备持续监控新威胁和漏洞的能力，并能将新漏洞追踪到特定车辆、系统和软件版本。
- 安全的 OTA 更新 ：能够远程安全地更新车辆车队中的易受攻击系统和软件。

2.1 发布管理

2.1.1 PLM 系统与 BOM 管理

汽车行业传统上使用产品生命周期管理（PLM）系统来集成和管理与汽车系统设计、制造和维护相关的数据。PLM 系统还可管理复杂的物料清单（BOM），相比使用 Excel 文件等旧方法，具有更强大的功能。

PLM 系统常用于管理硬件 BOM，以便在出现硬件组件故障导致的安全或质量问题时，汽车制造商能够追踪受影响的车辆。例如，有缺陷的安全气囊导致超过 4100 万辆汽车召回，涉及 2002 - 2015 年款的 19 家不同汽车制造商的车辆。如果没有 BOM 管理，就无法确定哪些车辆安装了有缺陷的安全气囊。

2.1.2 软件 BOM 管理的重要性

随着汽车中软件的增加，管理软件 BOM 变得同样重要。汽车制造商需要确切知道软件组件的包含情况、供应来源以及哪些系统使用了哪些版本的软件，以便在检测到安全、质量或安全问题时，能够追踪受影响的车辆并进行更新或召回。

例如，一个车载主机的漏洞导致 140 万辆汽车召回，该主机安装在 2013 - 2015 年款的多个不同车型中。这凸显了汽车组织能够追踪哪些车辆和系统包含特定易受攻击软件的重要性。

2.1.3 软件透明度与相关活动

为了能够正确创建和管理软件物料清单（SBOM），汽车行业需要在整个供应链中实现软件透明度。为此，有许多正在进行的活动：
- NTIA 的工作 ：美国国家电信和信息管理局（NTIA）正在制定一些文件，以帮助提供供应链中软件的共同理解。这些文件涵盖了如何识别和命名组件、如何共享 SBOM 以及如何基于各种工具和不同的 SBOM 格式自动创建和使用 SBOM。例如，SBOM 可以使用软件成分分析工具自动生成。
- OpenChain WG 的标准 ：OpenChain 工作组开发了一个新的标准 ISO/IEC 5230，于 2020 年 12 月发布，以帮助供应链中的组织在提供方和接收方之间实现软件透明度。OpenChain 汽车工作组于 2019 年 7 月成立，专门针对汽车主题。

2.1.4 开源软件的发布管理步骤

对于开源软件，建议采取以下发布管理步骤：
1. 全面盘点开源软件 ：为软件包生成 SBOM。
2. 使用适当的软件成分分析方法 ：当只有二进制文件可用时进行二进制扫描，当有源代码时进行源代码扫描以获得更全面的结果，以识别包含的开源组件。
3. 将识别的开源组件映射到已知的安全漏洞 ：使用来自美国国家标准与技术研究院（NIST）国家漏洞数据库（NVD）等漏洞数据库的已知漏洞信息。
4. 识别许可证、质量和安全风险 ：考虑不遵守开源许可证的法律风险，以及使用维护不善的开源软件组件的质量和安全风险。

2.1.5 发布流程示例

以下是一个简化的发布流程示例，用于管理 SBOM：

graph LR
    A[软件开发] --> B[软件成分分析]
    B --> C[软件仓库]
    C --> D[生产线末端刷机]
    B --> E[ALM/PLM 系统]
    D --> E

在软件开发阶段，开发和集成各种软件，并在适用时通过基于源代码扫描的软件成分分析工具。开发的软件存储在软件仓库中，第三方应用程序或库等二进制软件也可存储在此，并在适用时进行二进制扫描。软件成分分析工具的扫描结果用于生成 SBOM，存储在应用程序生命周期管理（ALM）/PLM 系统中。最后，软件仓库中的软件在车辆生产时用于生产线末端刷机，将特定软件刷入汽车系统，同时相关信息存储在 ALM/PLM 系统中。

2.2 监控与跟踪

2.2.1 其他行业的解决方案

在 IT 和企业等其他行业，已经有一些解决方案用于实现威胁和漏洞的监控与跟踪。
- 安全运营中心（SOC） ：是组织内的一个集中职能部门，负责监控、分析和响应安全威胁、漏洞和事件。需要安全人员处理操作，定义要执行的活动流程，并部署技术解决方案辅助工作。例如，IT 组织的 SOC 会持续监控和分析网络、服务器、网站、应用程序、数据库等系统的活动。当监控触发可疑行为警报时，SOC 会分析警报并根据优先级采取行动，如关闭系统、隔离目标系统或终止有害进程。
- 产品安全事件响应团队（PSIRT） ：是一个集中职能部门，负责管理与组织产品相关的漏洞报告和处理。漏洞信息可能来自客户、独立安全研究人员和行业团体。PSIRT 会分析和优先处理漏洞报告，评估漏洞对产品的影响，研究缓解方法，协调资源进行修复，并提供更新后的软件版本并通知客户。
- 漏洞赏金计划 ：一些组织通过漏洞赏金计划与第三方安全研究人员和安全社区合作，接收漏洞信息。安全研究人员可以测试组织的基础设施或产品的某些部分，并通过该计划报告发现的漏洞，根据漏洞严重程度获得数百美元到数千美元的奖励。例如，开源网络浏览器 Firefox 从 2004 年就开始了漏洞赏金计划。
- 行业团体的协调努力 ：对于金融行业，金融服务信息共享与分析中心（FS - ISAC）是一个行业联盟，为金融机构提供威胁和漏洞信息。

2.2.2 汽车行业的解决方案

汽车行业也在朝着类似的方向发展，需要建立类似的威胁和漏洞监控与跟踪解决方案。ISO/SAE DIS 21434 标准描述了汽车组织进行持续网络安全活动的要求，包括威胁和漏洞监控。

汽车组织正在开展各种活动，如建立汽车 SOC 或车辆 SOC。汽车 SOC 的功能与其他行业的 SOC 类似，但监控的目标系统是汽车组织生产的车辆车队，目的是保护联网车辆免受网络安全威胁和攻击。

2.2.3 汽车 SOC 示例

一个汽车 SOC 的示例流程如下：

graph LR
    A[Auto - ISAC] --> B[威胁和漏洞信息收集]
    C[漏洞赏金计划] --> B
    D[现场信息] --> B
    E[软件成分分析工具] --> B
    B --> F[PSIRT]
    F --> G[事件管理]
    G --> H[首次分析]
    H --> I[影响范围和对策分析]
    I --> J[评估对策有效性]
    J --> K[验证更新发布方法]
    K --> L[发布到现场]

威胁和漏洞信息从多个来源收集，包括：
- Auto - ISAC ：一个行业驱动的社区，成立于 2015 年，成员包括轻型和重型车辆原始设备制造商（OEM）、供应商和商用车部门。其目标是分享威胁和漏洞信息，提高整体车辆网络安全，并提供车辆网络安全的最佳实践。
- 漏洞赏金计划 ：虽然在汽车行业相对较新，但一些汽车制造商如特斯拉、通用汽车、菲亚特克莱斯勒汽车和丰田已经开始实施。最初主要关注汽车组织的网站和移动应用，现在越来越多地将车辆纳入目标范围。
- 现场信息 ：包括从车辆本身获取的信息，例如车辆内传感器或安全解决方案检测到的异常，通过远程信息处理单元将异常数据和警报发送到汽车 SOC。例如，汽车入侵检测系统（IDS）可检测车辆网络和电子控制单元（ECU）上的可疑行为和事件，并向汽车 SOC 报告。
- 软件成分分析工具 ：在发布过程中使用软件成分分析工具，帮助汽车组织创建 SBOM，了解哪些汽车系统包含哪些开源软件组件。

2.2.4 汽车 SOC 各环节详细分析

汽车 SOC 的各个环节在保障车辆网络安全方面都有着重要作用，以下对各环节进行详细分析：

信息收集环节

信息收集是汽车 SOC 的基础，不同来源的信息为后续的分析和决策提供了依据。
- Auto - ISAC ：作为行业驱动的社区，它整合了众多汽车相关企业的资源。成员之间共享威胁和漏洞信息，使得汽车组织能够及时了解行业内的安全动态。例如，当某个成员企业发现了一种新的针对汽车网络的攻击方式，通过 Auto - ISAC 可以迅速将这一信息传递给其他成员，从而让整个行业能够提前做好防范。
- 漏洞赏金计划 ：鼓励了外部安全研究人员参与到汽车网络安全的检测中来。这些研究人员具有不同的技术背景和视角，能够发现汽车组织内部可能忽略的漏洞。例如，特斯拉通过漏洞赏金计划，吸引了全球范围内的安全专家对其车辆系统进行检测，发现了一些潜在的安全隐患，及时进行了修复，提升了车辆的安全性。
- 现场信息 ：直接来源于车辆本身，能够反映车辆在实际运行过程中的安全状况。车辆内的传感器和安全解决方案就像是汽车的“眼睛”和“卫士”，实时监测着车辆的各种状态。当检测到异常时，如异常的网络连接、异常的系统操作等，会立即将信息传递给汽车 SOC。例如，汽车入侵检测系统（IDS）可以检测到车辆网络中是否存在非法的数据传输，如果发现异常，会及时发出警报。
- 软件成分分析工具 ：在软件发布阶段就对软件进行分析，帮助汽车组织了解软件中包含的开源组件及其版本信息。这对于及时发现开源组件中的已知漏洞非常重要。例如，如果软件中包含了某个存在已知漏洞的开源库，通过软件成分分析工具可以及时发现，并采取相应的措施，如更新该开源库或对其进行修复。

分析与处理环节

PSIRT ：产品安全事件响应团队在整个流程中起着核心的协调和决策作用。当收到各种来源的漏洞信息后，PSIRT 会对这些信息进行全面的分析和评估。首先，会根据漏洞的严重程度和影响范围对其进行优先级排序。例如，对于可能导致车辆失控的严重漏洞，会将其列为最高优先级进行处理。然后，PSIRT 会组织相关的技术人员对漏洞进行深入研究，评估其对车辆系统的具体影响，并制定相应的缓解措施。
事件管理 ：负责对整个安全事件的流程进行管理和跟踪。从漏洞信息的接收到最终的修复完成，事件管理团队会确保每个环节都按照预定的流程进行。例如，会记录每个环节的处理时间、处理结果等信息，以便后续进行审计和评估。
首次分析 ：对收集到的信息进行初步的筛选和判断。确定信息的真实性和可靠性，判断是否真的存在安全威胁。例如，如果收到的信息是由于车辆传感器的误报导致的，通过首次分析可以及时排除这种干扰信息，避免不必要的后续处理。
影响范围和对策分析 ：在确定存在安全威胁后，需要进一步分析该威胁的影响范围。这包括哪些车辆、哪些系统受到了影响，以及影响的程度如何。例如，如果一个漏洞影响到了车辆的制动系统，那么需要确定哪些车型、哪些批次的车辆安装了可能受影响的制动系统软件。然后，根据影响范围制定相应的对策，如是对受影响的车辆进行召回，还是通过 OTA 更新进行修复。
评估对策有效性 ：在制定了对策后，需要对其有效性进行评估。通过模拟测试、实际验证等方式，确保对策能够真正解决安全问题。例如，如果制定的对策是通过 OTA 更新修复漏洞，那么需要在测试环境中对更新后的软件进行全面的测试，确保其不会引入新的问题，并且能够有效修复已知的漏洞。
验证更新发布方法 ：在确定对策有效后，需要验证更新发布的方法是否可行。这包括更新的传输方式、更新的安装过程等。例如，需要确保 OTA 更新能够安全、稳定地传输到车辆上，并且能够正确地安装到车辆系统中。同时，还需要考虑更新过程中可能出现的异常情况，如网络中断、车辆故障等，并制定相应的应对措施。

2.3 安全的 OTA 更新

2.3.1 OTA 更新的重要性

安全的 OTA 更新是汽车网络安全解决方案中的关键一环。随着汽车软件的不断发展和更新，OTA 更新可以及时修复软件中的漏洞，提升车辆的性能和安全性。例如，如果车辆的某个软件模块发现了安全漏洞，通过 OTA 更新可以在不召回车辆的情况下，及时将修复后的软件推送给车辆，避免了因漏洞被利用而导致的安全事故。同时，OTA 更新还可以为车辆添加新的功能，提升用户的使用体验。例如，汽车制造商可以通过 OTA 更新为车辆添加新的驾驶辅助功能，让车辆更加智能和便捷。

2.3.2 OTA 更新面临的挑战

安全风险 ：OTA 更新涉及到软件的远程传输和安装，这过程中存在着被攻击的风险。例如，攻击者可能会拦截更新数据包，篡改其中的内容，导致车辆安装了恶意软件。为了确保 OTA 更新的安全性，需要采用加密技术对更新数据包进行加密，防止数据在传输过程中被窃取或篡改。同时，还需要对更新的来源进行验证，确保更新是由合法的汽车制造商发送的。
兼容性问题 ：不同车型、不同版本的车辆系统可能存在兼容性问题。例如，某个更新可能只适用于特定版本的车辆软件，如果将其推送给不兼容的车辆，可能会导致车辆系统出现故障。因此，在进行 OTA 更新之前，需要对车辆的软件版本进行精确的识别和匹配，确保更新能够与车辆系统兼容。
网络稳定性 ：OTA 更新依赖于网络连接，如果网络不稳定，可能会导致更新失败。例如，在车辆行驶过程中，如果进入了信号较弱的区域，可能会导致更新数据包丢失，从而影响更新的完成。为了解决这个问题，可以采用断点续传技术，当网络恢复后，能够从上次中断的位置继续进行更新。

2.3.3 实现安全 OTA 更新的步骤

为了实现安全的 OTA 更新，可以按照以下步骤进行：
1. 软件更新包的准备 ：汽车制造商首先需要对软件进行更新和测试，确保更新后的软件能够解决已知的问题，并且不会引入新的漏洞。在更新包中，需要包含更新的内容、更新的版本号、更新的适用车型等信息。
2. 更新包的加密 ：使用加密算法对更新包进行加密，确保更新包在传输过程中的安全性。常见的加密算法有 AES 等。加密后的更新包只有在车辆端使用正确的密钥才能进行解密和安装。
3. 更新包的签名 ：对加密后的更新包进行签名，以验证更新包的来源和完整性。签名使用汽车制造商的私钥进行，车辆端使用公钥进行验证。如果签名验证失败，说明更新包可能被篡改或来源不可信。
4. 更新的推送 ：通过远程信息处理单元将更新包推送给车辆。在推送过程中，需要确保网络的稳定性和安全性。可以采用分批次推送的方式，先对部分车辆进行推送测试，确保更新没有问题后，再逐步扩大推送范围。
5. 车辆端的验证 ：车辆收到更新包后，首先对更新包的签名进行验证，确保更新包的来源和完整性。然后，对更新包的内容进行检查，看是否与车辆的软件版本兼容。如果验证和检查都通过，车辆会提示用户是否进行更新。
6. 更新的安装 ：用户确认更新后，车辆会开始安装更新包。在安装过程中，车辆会进行一系列的检查和验证，确保更新能够正确安装。如果安装过程中出现问题，车辆会回滚到更新前的状态，以保证车辆的正常运行。

3. 总结

汽车系统的网络安全是一个复杂而重要的问题，涉及到软件发布管理、威胁和漏洞的监控与跟踪以及安全的 OTA 更新等多个方面。通过建立完善的发布管理流程，汽车组织能够清晰地了解软件的使用情况，及时发现和处理软件中的安全问题。监控与跟踪环节借鉴了其他行业的成功经验，并结合汽车行业的特点进行了创新，通过汽车 SOC 等方式实现了对车辆网络安全的实时监控和快速响应。安全的 OTA 更新则为车辆软件的及时更新提供了保障，能够有效降低车辆受到网络攻击的风险。

未来，随着汽车技术的不断发展，如自动驾驶、车联网等技术的普及，汽车系统的网络安全将面临更多的挑战。汽车制造商和相关企业需要不断加强网络安全技术的研究和应用，建立更加完善的网络安全体系，以保障车辆和用户的安全。同时，行业内的合作和信息共享也将变得更加重要，只有通过整个行业的共同努力，才能应对日益复杂的网络安全威胁。

通过以上的解决方案和措施，汽车行业能够在不断发展的过程中，有效地保障车辆的网络安全，为用户提供更加安全、可靠的出行体验。

graph LR
    A[软件更新包准备] --> B[更新包加密]
    B --> C[更新包签名]
    C --> D[更新推送]
    D --> E[车辆端验证]
    E --> F[更新安装]

这个流程图展示了安全 OTA 更新的主要步骤，从软件更新包的准备到最终的更新安装，每个步骤都紧密相连，确保了更新过程的安全性和可靠性。