36、汽车生产后的网络安全保障：监测、管理与更新

汽车生产后的网络安全保障：监测、管理与更新

1. 汽车网络安全监测与安全OTA更新的必要性

随着汽车系统搭载的软件规模不断增大、复杂度持续提升，软件代码中出现漏洞和缺陷的风险也日益增加。如今，许多汽车系统不再由单一组织开发，而是包含了来自众多不同组织和各方的软件，这使得汽车行业在软件开发方面面临诸多挑战。

一项针对汽车行业网络安全实践的调查显示，在接受调查的593名汽车行业专业人士中，62%的人认为未来12个月内，针对其所在组织开发的汽车软件、技术和组件的恶意或概念验证攻击很可能或非常可能发生。这表明负责汽车系统安全的人员对安全风险和潜在攻击深感担忧。

同时，69%的受访者表示在其所在组织中，他们没有足够的权力提出安全方面的担忧。这可能是因为30%的受访组织没有建立产品网络安全计划或团队，仅有10%的受访者所在组织拥有指导和支持多个产品开发团队的集中式产品网络安全计划或团队。

此外，超过50%的受访者表示，他们在网络安全活动方面的预算和人力资源都不足。即使组织拥有网络安全团队，仍有62%的受访者表示团队缺乏必要的网络安全技能。而且，这些通常雇佣数千甚至数万名员工的组织，其产品网络安全管理项目平均仅配备9名全职人员。

该调查还指出，只有47%的组织在需求和设计阶段、开发和测试阶段的早期评估漏洞，这一比例本应更高。导致汽车软件和组件出现漏洞的主要因素是满足产品截止日期的高压，这可能致使某些网络安全活动的范围被缩减、执行不当甚至完全被跳过。除了截止日期压力外，另外三个主要因素与编码、测试和开源软件有关：
|因素|挑战详情|
|----|----|
|编码|缺乏对安全编码实践的理解或培训，以及意外的编码错误|
|测试|普遍缺乏质量保证和测试程序|
|开源软件|使用不安全或过时的开源软件组件|

另外，调查强调了对汽车软件和技术构成最大网络安全风险的三大领域，包括射频（RF）技术（如Wi-Fi和蓝牙）、远程信息处理和自动驾驶车辆。

由于新车辆的复杂系统包含来自多方的软件，供应链管理变得愈发重要。73%的受访者非常担心第三方提供的汽车软件和技术的网络安全状况。56%的受访组织未向供应商提供任何特定的网络安全要求，即使提供了要求，40%的组织也没有正式的流程来验证要求是否得到满足。因此，建立适当的供应链管理，包括创建软件物料清单（SBOM）以了解供应商提供的软件，显得尤为必要。

尽管组织可以在开发和测试阶段采取多种网络安全活动来减少漏洞数量，但为了应对车辆生命周期内检测到的关键网络安全漏洞，仍需要进行持续的网络安全监测，并具备及时进行更新的能力，这通常通过安全的OTA更新功能来实现。然而，目前汽车行业在这方面还落后于其他行业，61%的组织没有能够及时解决关键安全漏洞的软件更新交付模型，仅有37%的受访者所在组织目前提供OTA更新功能，但超过50%的受访者计划在未来五年内提供该功能。

在网络安全监测方面，ISO/SAE DIS 21434和UNECE WP.29规定组织需要具备监测新威胁和漏洞的能力。同时，这些标准也对软件更新提出了要求，规定组织需要具备对车辆进行软件更新的能力。此外，AUTOSAR平台为电子控制单元（ECU）软件的OTA更新提供了标准化方法，包括数据传输和闪存中的加密等安全考虑，以及避免ECU功能退化和在出现异常时允许软件回滚等可靠性考虑。

综上所述，汽车组织有必要考虑适用于车辆生产后的解决方案，如网络安全监测和安全OTA更新，以便及时发现和解决问题。除了复杂汽车软件带来的固有网络安全风险外，标准和法规也明确了网络安全监测和更新的必要性。

2. 问题陈述：软件清单、漏洞监测和受影响车辆

基于上述对网络安全监测和安全OTA更新的需求，汽车组织在满足这些需求时面临以下三个主要挑战：

graph LR
    A[汽车组织面临的挑战] --> B[保持最新的软件清单]
    A --> C[持续的网络安全监测]
    A --> D[及时进行更新]

2.1 保持最新的软件清单

由于复杂的供应链和车辆中大量的软件，汽车组织难以监测和跟踪哪些软件及其版本存在于哪些车辆上。传统上，汽车公司常使用产品生命周期管理（PLM）系统来管理车辆和汽车系统的硬件物料清单（BOM），从硬件角度来看，对车辆及其ECU和硬件组件有清晰的了解。

然而，从软件角度来看，汽车行业在进行相同水平的库存管理时面临挑战。汽车系统中的软件复杂且来源多样，包括自主开发的软件、第三方开发的软件、商业软件和开源软件。软件有各种配置和版本，与硬件不同，软件易于更新，因此特定的软件配置比硬件配置更可能随时间频繁变化。虽然硬件BOM在车辆中普遍使用，但软件物料清单（SBOM）的使用尚不普遍。

此外，软件更新可能由汽车维修厂进行，部分软件可通过空中更新，还有部分软件可由用户通过车辆的USB接口更新。这可能导致车辆制造商不知道软件是否成功更新到车辆上，即使为特定车辆创建了初始SBOM，也可能很快过时。因此，汽车制造商往往不清楚哪些软件及其具体版本在哪些车辆上运行。

2.2 持续的网络安全监测

汽车行业传统上没有定义明确的网络安全监测流程来主动监测车辆的威胁、漏洞和攻击。如前文所述，ISO/SAE DIS 21434和UNECE WP.29规定了网络安全监测的要求，但由于这些文件在撰写时仍处于草案版本，许多汽车组织尚未能够建立适当的能力来监测新的威胁和漏洞。

虽然网络安全监测在IT和企业等其他行业很常见，因为这些行业的系统由于易于访问的在线服务器和系统，几十年来一直面临网络安全威胁和攻击，但汽车行业在这方面仍有待加强。

2.3 及时进行更新

汽车组织在及时进行软件更新方面也面临挑战。一方面，如前面提到的，大部分组织缺乏能够及时解决关键安全漏洞的软件更新交付模型。另一方面，即使有更新机制，确保更新的安全性和可靠性也是一个难题。

安全OTA更新需要考虑诸多因素，比如数据传输的加密、更新过程中的错误处理、更新后系统的兼容性等。例如，在更新过程中，如果出现网络中断、数据损坏等情况，可能会导致车辆系统出现故障。而且，新的更新可能会引入新的已知或未知漏洞，这就要求在更新前进行严格的测试和验证。

3. 解决方案：保障车辆生产后的安全

为了解决上述问题，保障车辆生产后的安全，可以从以下几个方面入手：
|解决方案|具体内容|
|----|----|
|发布管理|建立完善的产品网络安全计划和团队，合理分配资源，确保在产品开发和发布过程中及时评估和处理安全漏洞。例如，制定明确的安全标准和流程，对软件的开发、测试和发布进行严格的管控。|
|监测和跟踪|建立有效的网络安全监测系统，实时监测车辆的软件状态和安全情况。利用先进的技术手段，如大数据分析、机器学习等，对海量的安全数据进行分析，及时发现潜在的威胁和漏洞。同时，建立软件清单管理系统，确保能够准确跟踪车辆上运行的软件及其版本。|
|安全OTA更新|制定标准化的安全OTA更新流程，确保更新过程的安全性和可靠性。在更新前，对更新包进行严格的安全检查和测试，确保不引入新的漏洞。在更新过程中，采用加密技术保护数据传输的安全，同时设置错误处理和回滚机制，以应对可能出现的问题。|

以下是一个简单的安全OTA更新流程示例：

graph LR
    A[检测到漏洞] --> B[生成更新包]
    B --> C[安全检查]
    C --> D[发送更新通知]
    D --> E[用户确认更新]
    E --> F[下载更新包]
    F --> G[验证更新包]
    G --> H[安装更新]
    H --> I[更新验证]
    I --> J{更新成功?}
    J -- 是 --> K[完成更新]
    J -- 否 --> L[回滚到旧版本]

通过以上解决方案，汽车组织可以更好地应对车辆生产后的网络安全挑战，确保车辆在整个生命周期内的安全性。持续的网络安全监测可以及时发现新的漏洞，有效的漏洞管理和事件响应流程可以确保及时处理这些漏洞，而安全的OTA更新则可以快速修复受影响的车辆系统，保障用户的安全和车辆的正常运行。