设计网络弹性汽车系统需要的不仅仅是对汽车安全威胁环境的表面理解。它需要一种有序的、流程驱动的方法，以确保汽车开发、生产和运行的每个方面都受到网络安全威胁的保护。为此，标准化机构已经发布了许多关于在汽车整个生命周期内保护车辆及其支持系统的流程和技术措施的标准。这些标准确立了最先进的水平，帮助组织了解其工程流程和技术产品中的差距。它们还提供了一个框架，通过遵守一套通用的程序和做法，在整个汽车供应链中保持一致的安全水平。
除了遵守最先进的技术外，遵守标准还有助于通过使用通用语言的通用框架减少从业者之间的争论。标准格局在不断发展，除了这里描述的标准之外，还会有其他标准值得您关注。一般来说，汽车安全标准可以根据所需的合规级别分为三大类：主要标准、次要标准和支持标准。第一类标准定义了一般安全框架，这些框架根据法规必须遵守。第二类标准涉及车辆安全的特定领域，这些领域的合规性取决于汽车制造商的需求。第三类标准包括有助于遵守前两类标准的标准和资源。
在本章中，我们将简要介绍最相关的汽车网络安全标准和资源，如图4.1所示。对于每项标准，我们将描述标准的目的、目标受众和总体范围。这些标准应被视为网络安全标准和资源领域的钥匙，因此，无论以何种标准衡量，此列表都不应被视为结论性的：
图 4.1 – 本章范围内的标准
在本章中，我们将讨论以下主要主题：
1.主要标准
2.二级标准
3.支持标准和资源
4.有用的资源和安全最佳实践
主要标准
三具有约束力的标准管理网络安全方面车辆及其支持系统的开发、生产和维护方式。不遵守这些标准可能会给 OEM 和供应商带来法律和财务影响，因此让我们深入了解一下。
联合国欧洲经济委员会WP.29
不同的政府和国际机构已制定了强制性网络安全标准和法规，用于管理其所在地区的 OEM。联合国欧洲经济委员会( UNECE )世界车辆法规协调论坛( WP.29 ) 已制定两项适用于 UNECE 地区成员的此类法规[17]。第一项法规涉及强制汽车制造商实施网络安全管理系统( CSMS ) [3]，而第二个涉及建立软件更新管理系统（SUMS）的规定[6]。这些法规涵盖四个不同的领域，包括管理车辆网络安全风险、通过设计确保车辆安全以降低整个供应链的风险、检测和应对整个车队的安全事件，以及提供安全可靠的软件更新，同时确保车辆安全不受损害。具体而言，SUMS 引入了对车载软件无线( OTA ) 更新进行监管的法律基础，因为它既是篡改车辆软件的攻击媒介，也是将安全补丁应用于车辆系统的安全机制。
REG 155：CSMS
在为应对联网汽车面临的新威胁，REG 155 要求汽车制造商及其供应链同时建立 CSMS。联合国法规提供了全面的为汽车行业制定了应对日益增长的道路车辆网络安全风险的框架。该框架旨在确保在整个产品生命周期内建立必要的流程来识别和管理这些风险[3]。
为了在适用 UNECE WP.29 法规的市场销售车辆，制造商必须向国家技术服务或认证机构证明他们已建立符合 REG 155 要求的 CSMS，并且已遵守 CSMS。成功实施 CSMS 必须实现以下目标：
1.进行风险评估以识别关键车辆部件
2.实施缓解措施来处理已识别的风险
3.通过测试提供这些措施有效性的证据
4.通过监控活动实施检测和预防网络攻击的措施，并支持针对特定车辆类型的数据取证
5.与相关认证机构分享监控活动报告：
什么时候遵守出现这种情况时，OEM 和供应商主要关注的是如何对其产品进行评估以满足法规要求。汽车产品的网络安全评估需要采用两阶段方法：
1.如图4.2所示，评估的第一方面涉及审核和认证车辆制造商的 CSMS。此步骤评估制造商在道路车辆的开发、生产和维护过程中管理网络安全风险的流程、程序和总体方法。
2.评估的第二个方面是通过评估产品层面的程序在将网络安全风险降低到合理水平方面的有效性来衡量汽车产品对 CSMS 的遵守情况。此步骤评估每辆车实施的具体网络安全措施，并验证它们是否能有效防范潜在的网络威胁。
这种两阶段方法可确保制造商的整体网络安全方法和在单个车辆上实施的具体措施都得到彻底评估和认证[5]。
一个成功的审核和评估使 OEM 有权获得车辆的型式批准，这表明该车辆在 UNECE WP.29 地区使用是安全可靠的。此外，该法规还影响需要帮助网络安全相关部件的供应商OEM 可以证明自己遵守了 CSMS，从而证明整个供应链的网络安全风险得到了充分管理。从 SAE 3 级开始，具有自动驾驶功能的乘用车、厢式货车、卡车、公共汽车和轻型四轮车都属于必须获得型式批准的车辆类别。为了帮助 OEM 确保充分考虑网络安全风险，该法规包括有关应考虑和防范的威胁和漏洞基线的指导。附件 5 列出了汽车制造商或零部件供应商在开发系统时必须考虑的网络安全威胁的最低限度。图4.3提供了安全分析范围内的威胁和漏洞的快照：
在进行威胁分析和风险评估时，请查阅REG 155中的威胁类型，以确保您的产品至少已考虑到所有适用的威胁。
图 4.3 – REG 155 附件 5 网络安全威胁和漏洞类型
在除了需要考虑的威胁和漏洞，REG 155 提供了常见缓解措施列表，以帮助 OEM 和供应商选择正确的技术对策。这些缓解措施的示例包括使用安全通信通道、删除调试功能以及依赖加密功能。
通过结合附件 5 中的对策开始构建您自己的安全控制目录。
REG 155 并未强制要求采用特定的 CSMS，而是让 OEM 自行选择能够实现法规目标的框架。不过，REG 155 确实指出，ISO/SAE 21434 就是这样一种能够满足 CSMS 要求的框架。由于 ISO/SAE 21434 标准的可用性和普及性，大多数 OEM 和供应商选择它作为证明符合REG 155 的 CSMS。
ISO/SAE 21434:2021，道路车辆 - 网络安全工程
打造设计安全的车辆需要网络安全意识产品生命周期，从概念和设计阶段开始，一直到生产以及生产后直至车辆退役。了解车辆的生命周期是理解 ISO/SAE 21434 范围的重要先决条件，因此让我们来了解一下[ 15]：
图 4.4 – 生命周期流程
在概念阶段，产品具有初步架构和特性或功能候选列表。这是首次考虑产品的网络安全相关性，以消除有风险的功能并调整架构以降低网络安全风险的机会。在此阶段结束时，必须分析产品范围内的威胁并制定风险处理计划。
1.在发展阶段，网络安全通过定义安全需求并将其反映在实际产品架构中来考虑。此外，网络安全测试被纳入整体产品测试计划。
2.一旦进入在生产阶段，必须考虑与安全设置、初始化和安装产品相关的方面，例如加密密钥配置、代码签名、固件安装以及将产品转换为安全状态，从而标志着从生产模式的明确过渡。
3.进入运行模式后，现在，产品有望在设计阶段假定的环境中安全运行。在此阶段，将监控产品是否存在新的网络安全威胁和漏洞，以确保在发生网络安全事件时做出适当的响应。
4.当维护例如，需要通过软件更新解决漏洞，或者执行故障排除或修复，需要网络安全控制将产品过渡到维护阶段。
5.最后，当产品当其达到使用寿命后，预计将进入一个生命周期状态，其中用户的私人数据、知识产权和产品机密将被安全销毁或无法访问。
提示
了解您最关心的生命周期阶段，并熟悉与该阶段相关的网络安全活动。
ISO/SAE 21434提供了全面的框架通过组织层面的行动和项目层面的活动，应对生命周期各个阶段的网络安全威胁。这同样适用于汽车制造商和零部件供应商，他们必须合作证明车辆已经充分应对了网络安全风险：
图 4.5 – ISO/SAE 21434 涵盖的流程领域
深看下一章将详细介绍图 4.5所示的 ISO/SAE 21434 的各个条款，但现在，我们将仅提供该标准涵盖的所有流程领域的高级视图，以阐明它们与本章中介绍的其他标准之间的关系：
1.第 5 条重点关注组织网络安全管理，体现在建立网络安全文化、网络安全风险信息共享流程以及支持配置、变更和文档管理等支持系统。本节还重点介绍了管理工具的重要性，对暴露于网络安全风险的工具进行分类，并确保这些工具处于安全管理之下，以防止风险在汽车产品中传播并最终影响车辆。
2.第 6 条将通过强调能力管理和网络安全规划的必要性，将重点从组织转移到产品。此外，它还设定了开发脱离上下文的组件和集成现成组件的期望。本条款介绍了网络安全案例以及评估产品发布准备就绪条件的期望。
3.第 7 条针对在供应商选择过程中评估供应商的网络安全能力以及在报价请求中纳入网络安全要求以确保在采购阶段不会忽视网络安全的重要性。它还解决了在汽车 OEM、供应商和合作伙伴之间的分布式开发过程中明确定义网络安全责任的需要。
4.第 8 条重点持续的网络安全活动，例如在开发阶段以及产品进入运行状态时执行的活动。这些活动包括网络安全监控以检测新出现的威胁和弱点、网络安全事件评估以分类风险报告、漏洞分析以评估已确认事件的影响，以及漏洞管理以解决已确认的漏洞并通知受影响方。
5.根据第 9 条，从概念阶段开始，工程条款就出现了。此阶段的目标是制定一个网络安全概念，提供所需的高级网络安全控制和要求，以确保所有已识别的产品网络安全风险都在可容忍的水平之内。这些要求追溯到网络安全目标，这些目标在特定资产需要降低风险时定义。这些目标通过以下方式得出基于项目定义的威胁分析和风险评估 (TARA) 流程。后者定义了分析的范围，包括项目内的组件和操作环境。
6.第 10 条利用第 9 条的结果来反映在产品开发阶段。这通过网络安全规范来捕获，这些规范描述了分解的网络安全要求和组件级别的相关架构，以实现概念阶段更高级别的网络安全要求和控制。产品开发阶段的活动包括将安全设计原则应用于完善的架构，并为软件实现提供安全编码实践。然后，为了进行验证，标准要求安全测试通过集成和验证测试（例如基于需求的测试、模糊测试和渗透测试）进行。
7.第 11 条规定通过验证概念阶段的网络安全目标和供应商提出的可接受风险假设，满足车辆层面网络安全验证的期望。
8.第 12 条要求制定生产计划，将后期开发的网络安全要求纳入其中，以确保在生产过程中正确应用安全的安装和设置方法。
9.第 13 条要求制定事件响应计划，以应对已确认的事件，并通过安全更新机制发布补丁。
10.第 14 条规定通过在车辆退役期间通过禁用通道或销毁资产来保护资产，满足对报废阶段的期望。
11.最后，第 15 条描述了TARA 方法和实践可视为 ISO/SAE 21434 标准的标志。TARA 方法基于资产驱动的威胁分析。威胁和攻击路径被映射到损害场景，以计算总体风险并确定风险处理决策。
ISO/PAS 5112:2022 – 道路车辆 – 网络安全工程审核指南
由于随着 ISO/SAE 21434 标准的广泛接受，汽车组织面临的一个共同挑战是如何证明遵守标准。为了应对这一挑战，ISO/PAS 5112:2022应运而生，用以指导审计团队对组织的网络安全流程进行审计。根据ISO/PAS 5112的定义，审计是对某个过程的检查，以确定过程目标的实现程度。为了证明过程目标的实现，必须使用根据该过程（ISO/SAE 21434）开发的项目作为审计团队的参考[14]。对于从未根据ISO/SAE 21434执行过项目的组织，可以分阶段使用参考项目中可用的工作产品进行审计。
该标准以 ISO 19011（审核管理系统指南）为基础，并将其应用于汽车行业，特别是 ISO/SAE 21434。标准提供的指南涵盖管理审核计划、规划和执行网络安全管理系统审核以及评估审核团队的能力。此外，它还提供了一套基于 ISO/SAE 21434 目标的审核标准，并在附件 A 中包含一个示例问卷，供审核团队使用。审核问题旨在直接源自 ISO/SAE 21434 流程目标。以下是基于附件 A 问卷中有关ISO 标准第 6 条的示例审核问题：
是否建立、实施和维护一个流程来管理与项目相关的网络安全？
审计师应核实以下内容：
1.已建立制定网络安全计划的流程。此处的证据是 [WP-06-01]：网络安全计划。
2.已建立网络安全案件立案流程。此处的证据为 [WP-06-02]：网络安全案件。
3.已建立网络安全评估流程。此处的证据是 [WP-06-03]：网络安全评估报告。
虽然任何汽车供应商都要接受审计，但如果供应商的零部件不涉及网络安全生命周期的某些阶段，则可以将其排除在外。例如，提供软件库的供应商不需要演示定义车辆级验证活动的过程，如ISO/SAE 21434 第 11 条所述。
准备中审计团队将联系流程专家，提供组织内与网络安全管理系统相关的信息。他们还将联系项目团队，该项目团队的网络安全工作成果可用作网络安全管理系统有效性的证据。调查结果按下表分类：
如果没有重大或轻微不符合项，审核将通过。如果一个或多个轻微不符合项不能证明 CSMS 缺乏有效性，则审核将有条件通过。但是，如果发现一个或多个重大不符合项或多个轻微不符合项，表明 CSMS 明显缺乏有效性，则审核将失败。审核失败和有条件通过都必须采取纠正措施。
ISO/PAS 5112 范围内的审核旨在确保组织流程符合 ISO/SAE 21434。产品级评估不在本标准的范围内。成功审核组织流程是执行产品级网络安全评估的先决条件，以衡量产品是否符合审核流程。
接下来，我们将把注意力转向第二个主要标准，该标准决定了确保 OEM 能够对成功的攻击做出反应以保证车辆安全的一个关键方面。
REG 156：总计
尽管存在能够发布 OTA 更新以使汽车系统使用最新的安全修复程序进行修补是一种强大的安全措施，但它也是对车辆系统软件和固件完整性的主要威胁来源。认识到远程更新机制的重要性，UNECE WP.29 制定了第二项汽车网络安全法规，以确保 OEM 实施完善的 SUMS 以防止滥用此功能。该法规解决了符合要求的SUMS必须解决的四个主要关注领域[6]。
软件版本管理
一个部署正确的软件更新的一个重要方面是有一个流程来识别目标系统中的所有初始和更新软件版本以及相关硬件组件。这使 OEM 能够将软件版本追溯到特定的车辆类型和系列。当发现影响一个或多个车辆组件的漏洞时，这一点至关重要。一方面，OEM 急于找出哪些 ECU 受到影响，以确定何时可以发布补丁，另一方面，供应商正在竞相确定他们的任何组件是否包含漏洞，以便他们可以通知客户并制定解决方案。鉴于 ECU 数量庞大且汽车供应链的多样性，维护这些信息是一项艰巨的任务。汽车供应商使用库或驱动程序而不跟踪真实来源的情况非常普遍，这使他们及其客户面临这些组件中的潜在漏洞。应对这一挑战的常见做法是通过可与供应链中的其他利益相关者共享的软件物料清单( SBOM ) 来跟踪软件内容和版本。SBOM 可以以多种格式捕获，例如软件包数据交换( SPDX ) 或 CycloneDX。两者都是用于传达软件组件、许可证和版权信息的开放标准。除了使组织能够跟踪可能受漏洞影响的软件组件之外，SBOM 还有助于检测开源许可证违规行为。
安全兼容性
导出SUMS 支持识别目标车辆软件，符合要求的 SUMS 必须确保安全部署软件更新。了解软件组件及其各自的版本可让 OEM 确认软件更新与目标车辆配置的兼容性。此外，在软件可能与其他系统相互依赖的情况下，SUMS 必须防止部署会对其他 ECU 产生不利影响的软件。例如，如果软件更新导致新的通信矩阵不受目标车辆 ECU 之一的支持，则从更新中排除该 ECU 将导致通信错误和安全关键系统的潜在故障。
通信矩阵只是一个表格，其中描述了消息标识符、消息长度信息以及 ECU 通过串行总线（如 CAN）执行基于信号的通信所需的其他参数。代码生成器使用通信矩阵作为输入来生成源文件和头文件，然后将其包含在 ECU软件构建中。
制定一个评估软件更新影响的流程对于防止对车辆安全和持续运行产生意外后果至关重要。使用预期的车辆配置对更新进行充分测试是防止部署不兼容更新的一种方法，因为不兼容的更新会对车辆安全和运行产生意外后果。同样，需要考虑启用未经原始车辆软件集测试的新功能的影响，以避免新启用的功能产生不利影响。
更新的网络安全
法规要求 SUMS 强制实施安全措施，以保护软件更新免受操纵，以及保护更新过程不受破坏。在这里，SUMS 将与 CSMS 携手合作，采用基于风险的方法来识别相关威胁并确定适当的风险处理计划。如果更新失败，则需要一个流程来支持回滚到安全版本，而不会出现攻击者滥用此漏洞，强制将软件回滚到未打补丁的版本。在某些情况下，更新本身也可能带来新的风险或漏洞，因此 SUMS 必须支持评估变更的网络安全风险并应用充分的安全审查和测试的流程。
用户意识
法规要求制定流程，在车辆更新即将安装时通知用户。这样，用户就可以决定是否准备好接收更新，或者是否必须推迟更新，直到更合适的时候再进行。
接下来，我们将关注 ISO 24089，这是旨在满足REG规定的 SUMS 要求的标准156.
ISO 24089
请注意撰写本文时，ISO 24089标准仍在开发中。ISO 24089 文件的目标是使 SUMS 标准化，类似于 ISO/SAE 21434 使 CSMS 的实施标准化。因此，预计汽车制造商和供应商将使用 ISO 24089 来满足 UNECE REG 156 的要求，以获得汽车软件更新支持的批准。ISO 标准的目的是为车辆软件更新的开发、实施和维护提供一套指南和要求。因此，它要求整个汽车行业采用一致的软件更新方法，从而确保车辆软件更新的安全性、可靠性。为此，它涵盖了软件更新的所有方面，包括规划、设计、实施、测试、部署和维护，并为管理软件更新的生命周期提供了建议[ 16]。
中国法规和标准化
继效仿其他国家和国际机构的做法，中国国家互联网信息办公室（CAC）发布了多份网络安全影响设计、开发、生产、销售和维护的原始设备制造商和供应商的标准在中国，汽车的标准化程度越来越高。了解这些标准对于计划在该市场销售汽车产品的国际供应商来说非常重要。这些标准包括定义流程相关要求以及规定汽车系统和基础设施的技术要求。在撰写本文时，其中一些标准仍在起草中，因此我们将仅关注已发布的标准：
1.GB/T 38628-2020：本是第一个也是最重要的标准，被称为信息安全技术-汽车电子系统网络安全指南 [19]。该标准涵盖与ISO/SAE 21434重叠的领域，但提供了更多关于软件和硬件安全最佳实践和测试方法的背景信息。
2.GB/T 40861-2021：本标准称为《车辆网络安全通用技术要求 》[20]，旨在突出车辆资产并提供技术要求、技术和原则以确保其得到保护。该标准涵盖的领域包括车内和车外通信以及 ECU 软件的保护。该标准对于理解网络安全原则以及从这些原则中衍生的控制措施以应对车辆网络安全威胁具有参考价值。
3.GB/T 40856-2021：本标准名为《车载信息交互系统网络安全技术要求和测试方法》 [67]，对车辆的关键领域（如硬件组件、网络协议、操作系统和应用软件）提供了更具体的技术要求。技术要求与安全测试方法相辅相成，以确保这些要求得到正确实施。
4.GB/T 40857-2021：本标准名为《汽车网关网络安全技术要求及测试方法》 [68]，其结构与 GB/T 40856-2021 类似，但重点关注 CAN、以太网和混合网关。它指定了诸如删除后门、实施消息过滤以及通过监控消息标识符和消息频率来检测异常等要求。同样，它还指定了测试要求，以验证网关安全功能的正确性和安全性。
5.GB/T 40855-2021：本标准名为《电动汽车远程服务和管理系统网络安全技术要求和测试方法》 [69]，规定了与企业和公共服务和管理平台结合使用时电动和混合动力汽车车载终端的安全要求。这些要求及其相应的测试方法涵盖了安全通信、安全更新和访问管理等领域。
回想一下，在第 2 章中，我们讨论了中国密码算法。这些算法通过以下方式进行标准化：
1.GB/T 32907.2-2016：数字签名算法SM2
2.GB/T 32907.3-2016：哈希算法 SM3
3.GB/T 32907.9-2016：基于身份的密码算法SM9
这些标准规定了 SM2、SM3 和 SM9 算法实施的技术要求、测试方法和评估标准。它们旨在确保使用这些算法的加密系统和应用程序的安全性、可靠性和互操作性。例如，打算在中国销售其产品的汽车供应商应通过硬件 IP 和软件加密库为这些算法提供支持。
建议定期监测 CAC 的标准发布情况，以确保为产品路线图中的新标准做好充分准备。
正如我们在本节中看到的，构建合规的汽车系统需要不断了解网络安全标准和法规，这是在某些市场推出汽车的先决条件。在下一节中，我们将重点介绍应考虑的突出网络安全标准和参考资料，以简化对主要安全标准的遵守并确保安全最佳实践正在被跟踪。
二级标准
尽管主要的标准可以为设计安全的汽车产品提供整体框架，但它们依靠次要标准和支持标准来解决工程生命周期的特定技术领域。了解此类标准对于判断它们是否适用于您的组织是必要的或产品供应。
IATF 16949:2016
发展汽车质量管理体系（QMS ）框架内的产品服务作为先决条件实现产品安全。ISO/SAE 21434 将遵守 QMS 作为一项要求，这是合理的，因为很难在无法证明产品质量的情况下证明其安全性[9]。例如，由于缺乏正式的质量检查（例如代码审查和软件测试），在 QMS 之外开发的软件预计会包含更多错误。这些软件错误中有一部分可能被攻击者利用。如果没有 QMS 的帮助，我们就无法有效地管理软件错误的数量，这使得管理漏洞的数量变得更加困难。
IATF 16949 标准是旨在为整个汽车供应链提供质量管理的通用框架，以促进质量的一致性、提高客户满意度和提高效率。通过遵循 IATF 16949 的要求，组织可以确保其汽车产品满足客户要求和持续高效地生产。IATF 16949 标准的主要目标受众是汽车供应商、原始设备制造商( OEM ) 和相关服务提供商。IATF 16949 标准由 10 个条款组成，前三个为引言，其余七个条款按照计划、执行、检查、行动（PDCA ）循环进行构建，如图 4.6所示：
图 4.6 – 按照 PDCA 循环排列的 IATF 16949 条款
在探讨 IATF 标准的条款时，考虑 QMS 和 CSMS 要求之间的相似之处，以确定两者之间的协同作用是很有用的。例如，变更管理、配置管理和文档管理的各个方面都是 CSMS 要求的有用流程，QMS 只需稍加修改即可利用这些流程来解决网络安全问题。同样，QMS 的需求跟踪和可追溯性方法可用于创建网络安全要求并将其追溯到较低级别的网络安全规范。让我们简要介绍一下IATF 条款：
1.在第1条中，该标准为建立质量管理体系奠定了基础，该质量管理体系提供了持续改进的框架和预防缺陷的需要，同时减少了汽车供应链中的浪费。
2.第 2 章仅提供了标准应用所必需的规范性引用文件，包括 ISO 9001 [71]。
3.第 3 条列出了术语和定义，以确保对标准的解释和应用一致。
4.第 4、5和6条属于规划周期，第 4 条首先强调组织需要确定与 QMS 相关的利益相关者的需求和期望。确定系统范围对于建立正确的质量目标和确定需要管理的风险至关重要。
5.第 5 条涉及发挥领导作用，建立并维持对 QMS 的遵守。这可以通过多种方式实现，例如传达降低风险和持续改进流程的重要性。此外，将质量目标设定为 QMS 的可衡量目标，并分配角色和职责以确保 QMS 能够实施和维护，这些都是强制性措施。这与 ISO/SAE 21434 第 5 条关于组织在建立有效的网络安全管理系统中的作用相呼应。
6.第 6 条规定了为实现质量目标而进行规划的要求，例如提高产品质量、减少缺陷和提高客户满意度。组织应识别和评估与质量目标相关的风险，并建立流程来减轻这些风险。第 6 条的一个突出方面是变更管理，这要求组织建立流程来控制产品和流程的变更。在网络安全方面，变更管理至关重要，因为变更通常与新的网络安全风险有关。规划方面还延伸到产品设计和开发，包括规划需求引出、建立产品规范以及验证产品是否符合其预期目标。
7.第 7和第8条属于“执行”循环。与任何流程一样，有效地应用“执行”循环流程需要建立正确的资源、能力和意识，这是第 7 条的范围。该标准要求组织拥有必要的人力和基础设施资源。它涵盖培训和专业发展等方面，以确保员工了解并能够应用该流程。有效沟通和文件管理是本条款涵盖的两个方面，以确保所有利益相关者都拥有了解质量管理体系及其在其中的角色所需的信息。
8.另一方面，第 8 条重点关注生产满足客户要求的产品和服务所需的流程。通过运营规划和控制，组织必须通过制定工作指令和质量检查表来规划和控制产品设计、生产和服务交付。设计评审流程和设计验证等领域属于本条款的范围，以确保产品设计处于质量控制之下。当从供应商处采购零部件时，标准要求执行供应商管理流程来选择、评估和监督供应商，以确保其产品满足组织的需求。此外，本条款还涵盖生产方面，通过制定生产计划、生产控制流程和服务交付。本条款的额外要求是能够在整个生产和服务交付过程中识别和追踪产品和材料。最后，还涵盖对客户财产（如原型或产品样品）的管理，以防止财产损失或损坏。
9.第 9 条涵盖了检查周期，重点关注监测和测量 QMS，以及处理指标以推动改进。建立关键绩效指标( KPI ) 是衡量和评估 QMS 有效性的方法之一就是定期对 QMS 进行内部审核。识别不合格品并采取必要的纠正措施。为了持续改进，组织必须有方法收集需要改进的领域的数据，并建立可以实现改进的流程。
10.最后，第 10 条涵盖了法案周期，重点关注实际改进措施。这是通过建立持续改进的文化并让所有利益相关者参与进来，不仅要识别问题区域，还要应用解决问题的方法来解决问题来实现的。防错流程是这一领域的一个重要方面，因为防错比改正错误更可取。拥有根本原因分析方法是避免将来重复同样错误的有效方法之一。
正如我们可以看出，IATF 16949 为建立网络安全管理系统所需的许多流程提供了基础。QMS 可以看作是一个构建模块，它可以通过利用质量和网络安全方面的通用做法来显著减轻采用 CSMS 的负担。该标准可以作为汽车行业组织展示其对质量的承诺和满足客户需求的能力的重要工具。
遵守 IATF 16949 或同等质量管理体系是实现符合ISO/SAE 21434 的先决条件。
汽车 SPICE (ASPICE)
继续围绕质量管理这一主题，我们现在将讨论一个被广泛认可的行业标准，即Automotive SPICE [1]，帮助组织建立汽车 ECU 的软件开发流程。该标准专为汽车行业采用 ISO/IEC 15504-5 标准，也称为软件过程改进和能力测定( SPICE )标准。ASPICE 定义了一个过程参考模型，该模型提供了一组最佳实践，可应用于各个产品生命周期的软件开发过程中。ASPICE 将过程领域分为三大类：主要生命周期过程、支持生命周期过程和组织生命周期过程。此外，该标准还包含一组通过过程评估模型评估这些过程完成情况的方法。评估结果确定组织的成熟度能力级别，范围从 0 到 5。OEM 通常要求供应商在报价阶段展示其过程能力。这些评估有助于确保供应商能够满足汽车行业为开发安全、可靠软件系统而设定的高标准。
遵守 ASPICE 的好处是可以利用多个过程组作为支持过程，以实现 CSMS 的要求。ASPICE 更具吸引力的地方在于，在 ISO/SAE 21434 发布后，ASPICE 扩展了六个专门针对网络安全的过程组，如《Automotive SPICE for Cybersecurity》 [7]中所定义。这是一个评估模型，旨在支持实施 UNECE R155 和 ISO/SAE 21434（道路车辆 - 网络安全工程）。ASPICE for Cybersecurity 的目的是识别和解决网络安全相关项目中的产品风险。图 4.7显示了覆盖 V 模型的过程组，其中受安全影响的组标记为绿色：
图 4.7 – ASPICE 中的网络安全特定流程领域
这下列的下表展示了 ASPICE 网络安全过程组[7]与 ISO/SAE 21434 条款和标准 ASPICE 过程组[1]的映射：
表 4.1 – ASPICE 网络安全过程组与 ISO/SAE 21434 章节和一般 ASPICE 过程组的映射
在更新软件开发流程以考虑网络安全时，我们鼓励您将 ISO/SAE 21434 中的要求映射到 ASPICE 内的相应流程区域，以证明流程覆盖范围。
可信信息安全评估交换 (TISAX)
由于高度分布的性质汽车供应链中，供应商信息安全系统的漏洞可能会对供应链的其他成员产生连锁影响，危及用户的私人数据、安全敏感数据、商业机密和知识产权。为了应对这一风险，德国汽车工业协会 (VDA) 制定了 TISAX [23]，目前已被全球汽车公司广泛使用。该标准提供了一个评估和认证组织信息安全措施的框架，重点是保护整个汽车供应链中的敏感数据。这使合作伙伴可以相信，一旦他们的数据与供应链中的其他成员共享，就会有充分的措施来保护这些信息。汽车组织可以在与供应链中的另一个合作伙伴合作之前要求提供 TISAX 认证的证据。
ISO/SAE 21434 要求您在供应商选择阶段评估供应商的网络安全能力。TISAX 可以解决 ISMS能力方面的问题。
一个获得 TISAX 认证的先决条件是建立 ISMS管理组织内的安全敏感信息。获得 TISAX 认证的过程包括注册步骤（收集公司信息）、评估（TISAX 审计提供商检查合规性）和交换步骤（公司与合作伙伴共享结果）。
TISAX 定义了八个评估目标，所有这些目标都可能属于审计范围。这些目标包括处理需要高度保护的信息、保护原型零件、部件和车辆，以及保护个人数据，如欧盟《通用数据保护条例》（GDPR）[21]所规定的那样。保护需求越高，审计师必须采用的评估方法就越严格。因此，TISAX定义了三个评估级别，由申请方确定组织。信息安全评估( ISA ) 问卷[22]中的问题可供组织在接受外部审计之前进行自我评估。ISA 期望每个问题的成熟度级别在 0 到 5 之间。图4.8显示了ISA的摘录：
图 4.8 – ISA 调查问卷摘录
每个问题涵盖了关注的领域，例如物理安全或身份和访问管理。问题随附根据必须满足的目标以及允许审计师确定相应目标的满足程度的具体要求。
一旦自我评估的结果在可接受的范围内，可以进行外部评估，组织就可以联系 TISAX 审计供应商安排外部评估。审计结果将记录在 TISAX 评估报告中，该报告将结果分为符合、严重不符合或轻微不符合。制定纠正措施计划以解决发现的问题，包括根本原因、计划的行动、纠正措施的实施日期以及无法立即解决的不符合情况的补偿措施。评估完成后，可以使用交换门户与合作伙伴共享评估结果。
最后，TISAX标签被授予作为可见的指示，组织已完成对其信息安全措施的严格评估，并能够保护其客户和合作伙伴的机密数据。TISAX 标签提供了一种标准化和公认的方法来验证合作伙伴是否已实施必要的安全控制措施来保护数据免受网络攻击吃。
SAE J3101 – 地面车辆的硬件保护安全
不同于标准定义流程，SAE J3101 [24]专注于被视为 ECU 网络安全推动者的特定技术领域。该标准定义了一组嵌入式硬件安全模块( HSM ) 的安全要求，这些模块通常用于支持汽车安全用途安全车载通信和无线( OTA ) 更新等情况。该标准将 HSM 称为硬件保护的安全环境( HPSE )，并提倡使用它来实现安全机制对于构建 ECU 的安全弹性至关重要。如果没有 HPSE 的支持，ECU 将不得不依赖纯软件解决方案，而这些解决方案在支持安全启动和加密密钥保护等安全控制方面的能力有限。
SAE J3101 中的安全要求涵盖八个主要领域：加密密钥保护、加密算法、随机数生成、安全非易失性数据、加密灵活性、接口控制、安全执行环境和自测试。例如，在解决加密密钥保护问题时，该标准定义了密钥生成、密钥所有权、包装、配置和归零的要求。该标准从汽车的角度说明了为什么以及何时强制执行这些要求，这使得 SAE J3101 对汽车行业特别有用。
使用 HPSE 作为硬件信任根，以及安全执行环境和受保护的内存是保护 ECU 安全关键资产的基本组件。使用 HPSE，可以构建安全协议，以在整个产品生命周期阶段保护 ECU 数据的机密性、完整性和真实性。HPSE 可以发挥重要作用的示例用例包括身份验证诊断客户端通过不可变的公钥使用数字签名，使用受硬件保护的加密密钥加密用户的私人数据，并使用消息认证码对车载通信进行认证。
此外，安全案例的增多和对加密性能的不断增长的需求导致了对更强大的 HPSE 的需求，这些 HPSE 具有更多的加密加速器、更大的内部系统内存和更快的主机 CPU 接口。后者有助于在传感器数据认证和基于云的通信等应用中以高吞吐量加密处理数据。需要共同参考来定义 HPSE 技术路线图的 OEM 和芯片供应商可以利用 SAE J3101 来定义 HPSE 的基线及其需要实现的目标。该标准对于设计硅片 HPSE 硬件的芯片供应商以及开发HSPE 软件功能的固件供应商同样有用。
编码和软件标准
软件实现错误是漏洞的常见来源。消除可被攻击者利用的软件错误是一项艰巨的任务，尤其是在使用本质上不安全的语言（如 C 或 C++）时。为了帮助减少对安全或安全性有影响的软件错误的发生，开发人员依靠编码标准，通过语言子集和实施防御性编码技术来禁止编程语言的危险特性。应用编码规则是通过静态代码分析工具（也称为SAST）自动完成的。这些工具通常在每次软件提交时或达到某个发布里程碑时启用。编码规则违规行为会以警告的形式由工具返回，如果警告无法证明其合理性，则由软件开发人员处理。当这些规则违规警告可以解释为非关键偏差时，组织通常会抑制这些警告。但是，如果开发人员没有接受足够的培训来区分指向真正问题的警告和仅仅是误报的警告，那么盲目依赖 SAST 可能会适得其反。使用 SAST 的另一个陷阱是在程序中等待太晚才运行工具来修复违规行为。从事这种做法的团队可能在进行大量测试后不得不重写大量代码，这既成本高昂，对项目进度和客户承诺的风险也很大。与所有安全发现一样，重要的是根据风险严重程度对规则违规进行优先排序，以避免遗漏一些严重违规行为而不是修复与外观或无关紧要的问题相关的问题。汽车软件适用多种编码标准，因此我们将调查这些标准ost com接下来是星期一。
米斯拉
这汽车工业软件可靠性协会( MISRA )的宗旨是为 C 和 C++ 编程语言的安全关键系统开发提供编码标准。虽然 MISRA 规则的主要重点是生成可靠且安全的代码，但可以利用它们通过适当的代码卫生和防御性编码技术来防止软件漏洞[10]。对于一直在开发安全关键代码的团队来说，在扩展到更以安全为中心的编码标准之前，遵守 MISRA 是良好的第一步。
AUTOSAR C++
由于这AUTOSAR Adaptive 对 C++ 的依赖以及该语言在域控制器和车载计算机中的广泛使用（第 1 章介绍），AUTOSAR 和 MISRA 联手为 C++14 语言变体制定了安全可靠的编码指南。最终发布了《在关键和安全相关系统中使用 C++14 语言的指南》 [25]。此子集是通过添加规则创建的，这些规则针对已被证明会对内存安全构成风险、影响运行时确定性或导致特定于实现的行为的语言领域。在其汽车应用程序中使用 C++ 的组织可以遵循 AUTOSAR C++14 指南，即使他们不在 AUTOSAR Adaptive 框架内开发软件。
认证 C/C++
喜欢MISRA、CERT C 和 CERT C++ 的创建是为了提供一个语言子集来消除已知的安全漏洞。但与 MISRA 不同的是，CERT 专注于安全性，因此对软件实现漏洞的覆盖范围更大。这些规则由卡内基梅隆大学软件工程研究所维护[26]。每条规则代表一组软件弱点，如果遵循规则集中的编码检查，这些弱点可以得到缓解。
例如，规则 06 解决了数组中的弱点，并列出了六个需要考虑的编码检查：
此外，CERT C/C++ 根据关键性将规则分为 L1、L2 和 L3，其中 L1 最为关键。作为一般最佳实践，旨在消除大型代码库中的软件安全漏洞的组织应先解决 L1 违规问题，然后再转向 L2 和 L3。
NIST 加密标准
什么时候实施加密功能，必须参考 NIST 标准以确保正确实施并避免常见的安全陷阱。NIST 提供了大量标准，描述了如何实施加密功能，以及必须遵循哪些约束以确保安全部署该机制。除了加密功能外，一些 NIST 标准还提供了有关密钥管理和平台固件弹性等领域的宝贵建议。忽略这些建议或这些限制削弱了加密机制的安全性，增加了系统被篡改和非法访问的风险。让我们来概述一些常见的 NIST 加密标准，并对每个标准进行简要描述：
1.FIPS 180-4：安全哈希标准( SHS ) 规定一组密码哈希函数可用于从任意长度的输入生成固定长度的输出。输出称为哈希值，可用于各种应用，包括数字签名和数据完整性检查[27]。
2.FIPS 197：高级加密标准（AES）是联邦信息加工标准加密电子数据。AES 广泛应用于各种应用中的数据加密，包括安全通信和数据存储[28]。
3.FIPS 186-4：数字签名标准（DSS）是联邦信息处理数字签名标准。DSS提供了一种验证数字数据真实性和完整性的安全方法[29]。
4.SP 800-131A :标准名为“转换加密算法和密钥长度的使用”，为从较弱的加密算法和密钥长度过渡到更强的加密算法和密钥长度提供了指导方针。它提供了建议通过禁止某些加密算法并指定允许的最小密钥强度，组织可以维护其系统和数据的安全[30]。
5.SP 800-57 第 1 部分：密钥管理建议用于管理各种应用中的加密密钥，包括安全通信、数字签名和数据加密[31]。
6.SP 800-38A :标准《分组密码操作模式建议》为分组密码加密模式的使用提供了建议，包括格式保留加密[32]。
7.SP 800-38B :标准名为“分组密码操作模式建议：CMAC 身份验证模式”建议使用基于密码的消息认证码（CMAC）操作模式，这是一种可用于消息认证的分组密码模式[33]。
8.SP 800-56A :标准“使用离散对数密码的成对密钥建立方案的建议”为使用成对密钥建立方案提供了建议，该方案用于建立双方之间的安全通信[ 34]。
9.SP 800-56B :标准《使用整数分解密码术的成对密钥建立方案的建议》为使用整数分解密码术的成对密钥建立方案提供了建议[35]。
10.SP 800-133：《加密密钥管理建议》标准提供了安全管理加密密钥的指南，包括密钥生成、密钥存储、密钥分发和密钥销毁[36]。
11.SP 800-90A :标准名为《使用确定性随机位生成器生成随机数的建议》，提供了使用确定性随机位生成器生成随机数的指南。它涵盖了广泛的主题，包括熵源、随机数生成器和熵测试方法[37]。
12.SP 800-90B :标准名为《用于随机比特生成的熵源建议》，提供了使用熵源生成随机比特的指南，这些比特随后可用于通过 DRBG 生成随机数。它涵盖了广泛的主题，包括熵源、随机比特生成器和测试方法[38]。
13.SP 800-90C :标准名为《密钥生成技术使用建议》，为使用密钥生成技术提供了指导方针。它涵盖了广泛的主题，包括密钥生成算法、密钥强度和密钥管理实践[39]。
14.SP 800-108：标准名为《使用伪随机函数进行密钥派生的建议》，提供了使用伪随机函数派生加密密钥的指南。它涵盖了广泛的主题，包括密钥派生函数、伪随机数om功能和密钥建立协议[40]。
15.SP 800-193：标准名为NIST 平台固件弹性指南，提供了一套全面的建议，用于提高平台固件的安全性和弹性，以降低嵌入式计算机系统遭受未经授权访问和恶意攻击的风险。标准包括针对平台固件制造商、开发者和用户的建议，并涵盖固件更新和恢复、安全启动和防止未经授权的访问等主题。指南强调了保护平台固件免受恶意攻击以及确保固件更新安全可靠的重要性。它涵盖了以下领域：固件保护、检测和恢复通过信任根( RoT ) 和信任链( CoT ) 。该标准要求固件只能通过经过身份验证的机制进行更新。它还要求在固件或关键数据的情况下，应该能够损坏、检测和恢复。它提供了有关如何安全地存储和管理用于保护固件的加密密钥和证书的指南。它可以应用于任何提供闪存重新编程功能或 OTA更新的ECU [30]。
了解次级标准可以丰富安全流程，同时为组织提供有价值的参考，供其在定义安全要求和探索安全解决方案时参考。在下一节中，我们将介绍一些对任何网络安全专业人员都有用的著名支持标准和资源。虽然这只是参考样本，但鼓励每个组织创建一个支持标准数据库并保持更新，以确保最新的并正在遵循最先进的安全技术。
支持标准和资源
本章的剩余部分重点介绍有用但非强制性的标准和资源。鼓励组织维护此类资源的列表，以提高安全从业人员的意识，并及时了解安全最佳实践的最新出版物。
MITRE 常见弱点列举 (CWE)
米特编制软件和硬件清单根据定期在国家漏洞数据库( NVD ) [72]中归档的漏洞，可以发现安全漏洞。这些漏洞为了便于搜索，我们将漏洞分为几类。每年，MITRE 都会根据全年报告的漏洞发布Top 25 CWE [42] ：
图 4.9 – 2022 年排名前 25 位的 CWE 快照
作为如图 4.9所示，CWE-787 仍然位于前 25 个 CWE 之列，是内存安全漏洞最常见的根本原因产生越界写入的漏洞。了解前 25 个 CWE 以及 CWE 类是确保您的系统考虑并避免常见陷阱的有效方法。在执行威胁分析时，查阅 CWE 网站以识别分析系统中可能存在的弱点并帮助丰富威胁识别阶段很有用。同样，在安全审查期间，了解针对特定系统的常见弱点ic 组件可以帮助审阅者集中注意力于问题点。
美国交通部国家公路交通安全管理局 (NHTSA) 网络安全最佳实践，保障现代车辆安全
帮助为应对联网汽车面临的新威胁，美国国家公路交通安全管理局( NHTSA ) 发布了一份指南，通过应用网络安全最佳实践来增强机动车网络安全。这些实践主要分为两类：一般网络安全最佳实践（涉及流程和管理相关活动）和技术网络安全最佳实践（涉及车辆和 ECU级别的对策） [2]：
图 4.10 – NHTSA 最佳实践分类
NHTSA 定义了 45图 4.10中显示了关键领域的一般网络安全最佳实践。以下是一般最佳实践的精简版：
1.采用基于 NIST 网络安全框架的系统方法，为车辆制定分层网络安全保护
2.领导层应致力于分配资源、促进与网络安全问题相关的沟通，并将网络安全声音纳入车辆安全设计流程
3.建立一个基于安全工程方法的稳健流程
4.采用优先考虑车辆乘员和道路使用者安全的风险评估方法
5.考虑针对传感器的威胁，例如 GPS 欺骗、激光雷达/雷达干扰和摄像头致盲
6.消除或减轻安全关键风险
7.创建层层保护，并向保护供应商传达明确的安全要求定义
8.维持车辆内软件和硬件组件的清单，以追踪新发现的漏洞的影响
9.应用网络安全测试，包括渗透测试，并对每个已知漏洞进行漏洞分析
10.当检测到网络攻击时，实施监控、遏制和补救措施，以减轻车辆乘员和道路使用者的安全风险
11.与Auto-ISAC 等行业机构应用强大的文档管理和信息共享
12.定期评估网络安全形势变化带来的风险
13.积极参与行业标准化组织并与行业伙伴合作应对新风险
14.建立以汽车为中心的漏洞报告程序
15.支持创建事件响应计划和跟踪
16.对网络安全相关活动进行内部审查和审计
17.通过教育培训提高员工的网络安全意识
18.考虑售后设备连接到车辆系统时的风险，尤其是通过 Wi-Fi和蓝牙提供外部连接的设备
19.将售后设备制造商纳入必须对其产品应用网络安全保护的各方范围
20.平衡网络安全需求，限制 ECU 访问与第三方维修服务的车辆可维护性
此外，25 项技术最佳实践分布在与调试访问、加密方法、车辆诊断/工具、内部通信、日志记录、无线接口、网络分段、与后端通信相关的几个关键领域，以及软件更新。以下是技术最佳实践的精简版：
1.部署ECU 后限制或消除开发人员级调试访问
2.使用强大的加密方法并保护与车辆平台绑定的加密凭证
3.限制或消除可能被滥用的诊断功能
4.当诊断工具请求诊断服务或重新编程操作时强制访问控制
5.解决车辆内部渠道中安全关键信息的欺骗和重放威胁
6.在发生网络攻击时创建事件日志支持，以协助数据取证
7.保护外部网络接口和无线路径
8.应用网络分段和隔离，防止一个通道的损坏蔓延到安全关键域
9.在车辆网关上应用基于白名单的过滤，以限制跨车辆域的流量
10.消除可能被攻击者滥用的不必要的网络协议并应用端口级保护
11.通过加密和身份验证与后端建立安全的通信渠道
12.保护固件和软件免受未经授权的修改并防止回滚攻击
13.安全的 OTA 服务器解决针对OTA 更新的MITM 攻击
在准备 ECU 的网络安全要求时，请交叉检查 NHTSA 最佳实践，以确定网络安全要求覆盖范围内的潜在差距。
ENISA 智能汽车安全方面的良好实践
ENISA，这是一个欧洲的专注于网络安全的机构，已经发布了多份汽车安全报告，以提高汽车行业的安全意识，并为应对网络威胁的实践和技术措施提供指导。ENISA智能汽车安全良好实践 [43]报告就是这样一份出版物，其中包含汽车供应链所有成员的相关信息。报告中提出的资产分类法提供了对车辆安全运行至关重要的有形资产的整体视图，例如传感器数据、车载网络、车辆功能、决策算法、支持后端服务器和外部网络保护系统。另一方面，威胁分类法列举了各种类型的威胁，例如会话劫持、数据重放、通信系统拒绝服务、软件操纵等。提供了攻击场景列表，以阐明常见的攻击步骤、受影响的利益相关者和潜在的对策。ENISA 资产、威胁和攻击场景可用于预填充或增强车辆级 TARA。报告还列出了通过政策、组织实践和技术对策采取的安全措施。后者对于构建网络安全控制目录非常有用，可以帮助安全从业人员创建特定车辆系统的网络安全概念。
SAE J3061 – 信息物理车辆系统的网络安全指南
虽然J3061 已被 ISO/SAE 21434 取代，但仍有效作为可以提高汽车系统安全性的通用方法和实践的良好资源。SAE J3061 指南的目的是提供一个全面的框架，以确保联网汽车的网络安全[8]。与 ISO/SAE 21434 一起使用时，它可以提供有用的参考资料，例如在安全和安保交叉分析领域，以及风险评估框架（如 EVITA 和 HEAVENS）。该指南还包括有关设计和验证网络物理车辆系统的常用工具和方法的信息。
ISO/IEC 27001
ISO/IEC 27001是国际标准概述了信息安全管理系统（ISMS）[45]的要求。它提供了全面的通过制定和实施管理信息安全风险的政策和程序，为保护敏感信息（如财务数据、知识产权和个人信息）而建立了一个框架。这是通过系统地进行风险评估、处理以及持续监控和改进来实现的。该标准强调了领导在建立和维护支持 ISMS 的管理框架中的作用。它描述了风险评估方法在识别和评估数据机密性、完整性和可用性风险方面的作用。此外，它要求实施安全控制来管理已识别的风险。通过事件管理来补充保护，以建立报告、调查和响应信息安全事件的程序。持续改进和合规管理也是ISMS 的两个重要方面。
预计开发安全汽车产品的工程团队将与处理安全汽车产品的 IT 团队产生交叉由于前者在整个产品生命周期中都依赖 IT 系统，因此信息安全至关重要。因此，ISO/IEC 27001 有助于在发生冲突时协调期望。
NIST SP 800-160
NIST SP800-160提供了对安全工程过程的一般理解。对汽车网络安全有用的是安全控制的枚举。由于 ISO/SAE 21434 要求组织建立网络安全控制目录，以协助工程师选择完善的安全对策来缓解特定威胁，因此 NIST 标准的目录可以作为构建产品特定目录的良好起点。
同样，ISO/SAE 21434 要求组织在架构设计阶段建立安全设计原则来指导工程师。NIST 提供了一份全面的安全原则列表，如第 2 章所述，作为可信安全设计的原则[13]。调整这些原则并用范围内的产品领域中的示例进行补充是一种很好的做法，可以帮助团队做出安全意识设计决策。
乌普坦
Uptane [12]是最初是学术界和行业专家之间的合作努力，旨在提供安全架构用于车辆的 OTA 更新。Uptane 的目标是解决针对 OTA 更新基础设施以及目标 ECU 的威胁，以提高这一关键车辆功能的安全性和可靠性。Uptane 可应用于参与 OTA 系统设计和实施的所有各方，例如 OEM、后端解决方案提供商和 ECU 开发商。Uptane 标准强制分离管理 OTA 更新的角色，以确保任何单一违规都会导致 OTA 功能完全丧失完整性。为此，它将软件存储库分为包含二进制映像的映像存储库和部署软件二进制文件的主管存储库。此外，PKI 分为四个角色。根签名角色是 Uptane 环境的证书颁发机构，它为所有其他角色分发公钥。时间戳签名角色指示何时有新的元数据或软件二进制文件需要更新。快照签名角色创建存储库在特定目标的某个时间点发布的镜像的签名元数据。最后，目标角色提供目标元数据，例如二进制哈希和文件大小。Uptane 标准旨在防止各种类型的攻击，包括重放攻击、回滚攻击和 MITM 攻击。保护措施使用多种技术，例如数字签名、安全哈希和时间戳。Uptane 安全模型确保软件更新的完整性和真实性，Uptane元数据格式提供有关软件更新的内容和属性的信息，包括用于签署和验证软件更新的加密密钥。
概括
总之，理解和实施汽车网络安全标准不仅仅是一项监管要求，也是构建网络弹性汽车系统的基石。在本章中，我们将标准分为三大类：主要标准、次要标准和支持标准，以提供合规层的整体视图。虽然主要标准构成了骨干标准并且通常是强制性的，但次要标准和支持标准在实施强大的网络安全管理系统方面发挥着重要作用。它们也是了解安全弱点和安全最佳实践的有用资源，并为开发安全的汽车系统及其支持基础设施提供一般指导。此外，遵守这些标准可确保有序、流程驱动的方法，从而加强车辆生命周期从开发到运行的每个阶段。鉴于汽车网络安全格局瞬息万变，保持更新并适应新规范可确保以一致的方式采用全行业的网络安全实践，从而加强供应链中各个成员的能力。因此，本章应作为标准化意识的起点，提供当今主要标准的快照，同时激励您及时了解对您的专业领域至关重要的相关标准。
