深入探讨 ISO/SAE 21434 标准

ISO/SAE 21434 是汽车工程领域确保网络安全的事实标准。它提供了一个全面的框架，用于在产品开发生命周期（从规划、设计到生产及后续阶段）中管理网络安全风险。在第 4 章中，我们介绍了 ISO/SAE 21434 标准，并强调了采取系统化方法设计安全产品的重要性。本章将深入探讨这种方法的各个方面，并阐述其对于克服开发安全产品所面临的技术和流程挑战至关重要的原因。本文不会专注于标准的每个具体要求，而是详细总结每个条款的目标，并提供实现这些目标的最佳实践和实际案例。我们将涵盖广泛的主题，包括：

• 组织网络安全管理
• 采购和供应商管理
• 概念阶段
• 设计与实施
• 验证测试
• 确认测试
• 产品发布
• 生产规划* 运行和维护
• 产品生命周期终止支持

批注说明

阅读本章时，我们期望您能经常查阅 ISO/SAE 21434 标准，以便更好地理解流程要求或工作产品。在查阅时，了解国际标准化组织（ISO）标准使用的一些约定会有所帮助。首先，标准通过 [RQ-xx-yy] 标记强制性流程要求，其中 xx 是章节号，yy 是该章节内的要求编号。未能满足流程要求将导致审核员提出发现项，因此关注这些要求至关重要。另一方面，推荐实践则标记为 [RC-xx-yy]。将所有推荐实践纳入到您的网络安全工程流程中是一个良好的实践。请注意，评估人员会质疑为什么特定项目忽略了某个推荐实践。[PM-xx-yy] 指的是项目管理相关的流程声明，在符合特定标准要求时可以考虑。此外，通过工作产品 [WP-xx-yy] 来记录网络安全活动。工作产品是证明已执行特定网络安全活动相关的流程要求的证据，用于构建整体网络安全案例。

现在我们已经介绍了批注说明，接下来在深入探讨详细章节之前，先了解一下标准的总体范围。

ISO 21434 标准一览

任何网络安全工程管理系统的最终目标都是生产适用于其预期用途的安全系统。这通过准确识别和评估产品生命周期中出现的网络安全风险，并提供机制将这些风险降低到合理水平来实现。如果没有结构化的系统工程方法，工程师在识别已知风险时会采用临时（ad hoc）方法，并混合使用安全最佳实践和专家知识来应用网络安全控制措施。这通常会导致三种结果：

• 某些风险仍然未知，因为项目无法确定所有风险源都已考虑在内，或者所有技术风险都已分析。
• 选择了不充分的网络安全控制措施，留下未量化或未理解的残留风险。
• 网络安全控制过度设计，导致资源误用，从而增加成本并延误进度。

与临时方法相反，基于风险的网络安全工程系统方法旨在为组织提供对其网络安全风险敞口的清晰视图。这有助于正确设定应用安全措施的优先级，同时避免随意应用安全控制。通过提供工具来枚举和量化残留风险，组织可以更好地有条不紊地应对这些风险。同样，拥有指导正确选择网络安全控制的流程可以确保在设计的正确层级应用缓解措施，以最大限度地提高其有效性。在深入细节之前，让我们看一下网络安全工程方法的总体图景，以及它如何应用于完整的产品生命周期：

图 5.1 – 项目特定流程图

图 5.1 将生命周期分为四个主要项目阶段：

1. 项目启动： 此阶段为必须规划的网络安全活动奠定基础，并捕获与组件采购相关的风险。
2. 概念阶段： 此阶段通过应用威胁分析和风险评估方法，捕获系统级的安全目标和要求。
3. 产品开发： 此阶段在整个设计和实施过程中融入网络安全控制措施，同时最大程度地减少安全漏洞。这通过安全验证和确认测试确保安全控制已正确实施和部署。 4.开发后阶段： 此阶段定义了为产品发布做准备的安全先决条件，以及对生产、运行、维护和生命周期终止的网络安全影响。

如图 5.1 所示，不同阶段之间存在流程依赖关系。具体来说，漏洞管理以及威胁和风险评估流程领域贯穿多个阶段，因此它们被显示为纵向流程。在后续章节中，我们将持续参考此流程，以强调项目阶段和流程领域之间的相互依赖关系。接下来，我们将探讨组织在建立网络安全管理系统（CSMS）中扮演的角色，并提供适当的资源以确保其成功部署。

组织网络安全管理

与任何优秀的网络安全工程流程一样，ISO 21434 从组织层面的期望开始。由于网络安全工程方法是关于风险管理的，并且不同的组织有不同的风险承受能力，因此关于网络安全的讨论必须从任何组织的管理层开始。这通过网络安全政策（Cybersecurity Policy）来体现，该政策通过定义流程、责任和分配资源，为管理网络安全风险奠定了基础。通常，组织习惯于管理信息安全管理系统（ISMS）的安全政策（Security Policy）。该政策可以被利用，以扩展现有政策，通过 CSMS 来管理运营技术（OT）：

图 5.2 – 网络安全政策与网络安全管理系统流程手册之间的关系

简而言之，政策是要求建立网络安全管理系统的基础，该系统将通过流程手册（Process Handbook）来体现。这可以是一个简单的文档，也可以是一个交互式的流程定义工具。政策的一个非常重要的方面是使产品工程的风险矩阵与组织的整体风险矩阵保持一致。尽管信息技术（IT）和运营技术（OT）系统的风险评分方法可能不同，但制定一项政策来规定哪些风险级别必须缓解，哪些可以共享或接受，是高层管理人员帮助工程团队建立产品所需安全水平基线的一种方式。

注意： 风险评分方法结合了攻击可行性与相应的危害级别，从而得出风险评分，以指导风险处理决策。这将在本章稍后的概念阶段详细描述。

为了启动 CSMS 的采用，组织应考虑以下路线图：

1. 进行差距分析： 假设组织尚未建立 CSMS，第一步是进行差距分析，以评估实现合规所需的时间和资源。网络安全工程不应建立一个并行工程流程，而必须与现有的质量管理和安全管理系统集成。同样，支持性管理系统必须扩展以应对安全风险。这需要来自多个领域的专家汇聚一堂，以确保为网络安全而进行的流程调整不会与现有流程和程序产生冲突或重复。关于管理系统的更多内容将在下一节介绍。

   提示： 必须针对 ISO/SAE 21434 标准中的每个要求进行差距分析，以确保所有流程要求（而不仅仅是工作产品）都得到考虑。

2. 建立网络安全意识文化： 除了政策之外，组织还有责任通过建立频繁的培训和信息共享及风险上报流程来建立网络安全意识文化。但在拥有网络安全意识的组织之前，您需要为网络安全角色提供充足的人员配置。拥有合适的安全专业人员是确保产品网络安全领域的输入能够传达至适当管理渠道的先决条件。这种输入对于帮助网络安全角色消除不合理风险至关重要，这些风险如果得不到处理，将来会演变为代价高昂的安全漏洞。通过配备合适的员工，组织可以通过强调网络安全并非事后考虑或营销策略来建立网络安全文化。相反，它应该在产品生命周期的所有层面促成网络安全警惕性，将网络安全事件视为迫在眉睫的事件，并提前规划以应对它们。为实现这一点，员工必须意识到所有产品都存在漏洞，并面临被攻破的风险。经验丰富的网络安全工程师的指导也至关重要。这使得员工能够获得指导并学习最佳实践，从而将其融入到工作中。鼓励开放的思想交流和提问，以创建协作文化。因此，员工将明白，了解网络安全并将其融入设计是他们的责任。这可以通过将网络安全意识适当整合到现有流程和论坛中来实现。

3. 发展持续学习环境： 组织应投资于持续教育，同时鼓励参与行业网络安全机构（例如 AutoISAC），并监控各种安全渠道（包括暗网），以预判网络安全事件。与信息共享相伴随的是漏洞披露规则和流程的建立。组织必须制定一项政策，规定漏洞披露的及时性、谁可以进行披露、此类披露的沟通渠道以及如何处理敏感信息。此类流程必须跨各个部门保持一致，以防止常见的失误，例如未经授权披露供应商的漏洞，或在通知客户其产品将受影响的关键漏洞之前等待过长时间。

4. 确保最佳工具： 提供合适的工具对于在工程人员中获得广泛接受至关重要。例如，如果工具链繁琐且难以部署，工程师将选择绕过流程或寻找捷径，从而违背最初的意图。此外，建议将以往产品漏洞的经验教训融入到新产品和未来产品中，因为人们往往会重复过去的错误。

在组织层面整合网络安全流程的一个重要部分是扩展支持系统，使其包含安全方面。接下来我们将通过考虑对管理系统的影响来探讨这一点。

管理系统

管理系统是网络安全管理的推动者。没有此类系统的公司将难以满足 ISO 21434 的要求，尤其是在提交流程审核时。以下是必须进行调整以纳入网络安全的强制性管理系统。

质量管理

如第 4 章所述，质量管理是网络安全管理的前提条件。质量管理系统（QMS）确保产品开发以受控和可衡量的方式进行，这自然有助于减少可能演变为漏洞的缺陷。不仅需要 QMS，而且还需要适当的质量成熟度水平，以满足安全工程流程的期望。例如，如果 QMS 允许在无需生成需求或设计工件的情况下创建软件，那么它就不适用于网络安全管理，因为这些是生成产品开发工作产品（例如网络安全规范）的先决条件。此外，质量管理可以通过要求在通过质量门之前提供一套最低限度的网络安全工作产品来帮助强制执行质量门。将网络安全指标与质量指标一起包含，可以更全面地了解系统的成熟度，并允许管理层通过权衡成本效益来优先解决问题。

配置管理

配置管理系统确保工作产品和设计工件以可追溯和可重复的方式存储。这通过控制每个工作产品的版本、日期和所有权信息来实现，从而可以查看变更历史。在网络安全产品评估期间，所有安全工作产品都应进行版本控制并可追溯。

需求管理

需求管理的主要目标是双重的：

• 首先，确保需求在其属性和特性方面得到准确定义。
• 其次，在系统整个生命周期中保持对这些需求管理的一致性。

需求管理系统能够正确地将需求分类为安全需求，并建立与其他工作产品的可追溯性。这包括将功能安全需求追溯到更精细的技术安全需求、架构元素和接口，以及测试规范。

变更管理

变更管理的目标是确保对系统或产品所做的更改在整个产品生命周期中得到系统化的分析、控制、监控、实施和文档化。在此分析过程中，会分析对成本、项目进度和所需资源的影响。通常，变更控制委员会（CCB）会在接受或拒绝变更之前权衡这些因素。从网络安全的角度来看，每个功能或变更请求都有可能扰乱系统的安全态势。网络安全工程师的主要职责之一是持续监控变更请求，以确保它们不会引入在功能接受后难以缓解的风险。因此，CCB 必须评估网络安全的影响，并将网络安全工程师纳入决策和签署流程中，以避免接受使产品面临重大安全风险的变更。维护变更历史日志是任何变更管理系统的重要功能，以确保变更请求捕获变更的来源，包括日期、请求变更的原因和影响分析的描述。

文档管理

网络安全计划、手册、案例等需要在一个文档管理系统中进行管理，该系统能够追溯文档版本、文档所有者、预期受众等。文档管理系统必须支持文档审查和文档变更跟踪。此外，文档应根据其安全重要性进行分类，以强制执行数据共享策略。

网络安全与其他学科的交集

汽车网络安全与多个组织级别的学科交叉，例如信息安全管理系统（ISMS）、功能安全和质量管理。定义这些独立组之间的流程和沟通渠道有助于避免冲突和遗漏。例如，网络安全管理系统将依赖 ISMS 提供证据，证明基础设施工具对入侵和安全漏洞是安全的。此外，在某些情况下，CSMS 可能希望利用 ISMS 程序来获取云和后端服务受保护的证据。在这些部门之间建立并鼓励沟通可以防止工作的重复和收集所需信息（例如在审计期间）的漫长延迟。同样，功能安全流程与 CSMS 存在显著重叠，例如在概念、产品开发和测试阶段。定期召开安全和安保专家会议，以识别重叠、冲突和协同作用，对于防止在开发生命周期后期发现冲突时进行大量返工至关重要。

注意： 下一章专门讨论安全和安保的重叠。目前，请注意您的流程绝不能忽视这一领域。

工具管理

在产品工程生命周期的各个方面都使用工具。无论是用于建模系统设计、配置软件，还是生成签名二进制文件并在现场刷写，每种工具都可能为产品引入网络安全风险。例如，用于代码签名的第三方工具可能包含一个漏洞，导致在应用数字签名之前将恶意代码注入软件二进制文件。在其他情况下，工具本身可能由于使用了易受攻击的开源代码而受到损害，使其成为对产品进行更恶意攻击的发射台。

为了管理与工具相关的风险，首先需要一个将工具分类为网络安全相关的流程，以涵盖所有应纳入网络安全管理的工具。对于每个此类工具，需要一个流程来评估工具的安全级别，启用工具供应商指定的安全控制措施，并应用任何缺失的控制措施来缓解在工具安全评估期间识别到的风险。维护所有网络安全相关工具的数据库是必不可少的步骤，这样您就可以跟踪与工具相关的漏洞报告，以确保在所有使用工具的团队中部署最新的补丁。工具管理的证据可以通过一份报告来捕获，该报告显示所有网络安全相关工具都已正确识别，并且已采取措施来跟踪和维护这些工具的安全性。

为了表明符合第 5 条，表 5.1 中的所有工作产品都必须完成。这在衡量网络安全流程的合规性和有效性并确定是否已制定持续改进程序的网络安全审计期间是必需的。结果将记录在审计报告中，也称为 WP-05-05：

表 5.1 – ISO 21434 定义的组织管理条款涵盖的工作产品

现在我们已经了解了汽车网络安全的组织方面，接下来我们将探讨网络安全标准如何影响产品工程生命周期的每个阶段，从规划阶段开始。

规划

听起来可能很琐碎，但准备一份网络安全计划对于指导团队在产品发布前必须完成的全部所需工作至关重要。网络安全计划涵盖分配网络安全角色和职责、与项目和安全计划的交叉关系、必须完成的网络安全活动、任何活动的定制、复用理由以及处理现成组件和语境化组件。团队可以利用现有项目计划，并简单地扩展它们以纳入网络安全活动。或者，也可以准备一份专门的网络安全计划来捕获网络安全活动。ISO/SAE 21434 要求网络安全计划中至少描述概念阶段、产品开发阶段、验证阶段以及威胁分析和风险评估（TARA）活动。然而，涵盖其他方面（例如规划网络安全评估和发布活动）也可能会有所帮助。

注意： TARA 活动以及与概念、产品开发和验证阶段相关的其他网络安全活动将在本章中详细描述。

如图 5.1 所示，网络安全计划是准备网络安全案例的输入。通过审查网络安全计划，评估团队可以判断网络安全案例中汇编的证据是否符合网络安全计划，以及两者之间是否存在任何差距。

每项网络安全活动必须涵盖以下方面：

• 网络安全活动的目标。
• 负责执行、审查和批准该活动的指定资源。* 执行该活动所需的输入。例如，网络安全验证要求已从概念阶段定义并提供了网络安全目标。
• 根据项目需求定制活动。
• 关于活动是否可以利用以前工作的复用论证。
• 活动的预期输出——例如，验证测试报告。

定义活动目标可确保负责执行计划的团队成员了解需要执行哪些操作才能认为活动已完成。分配角色和职责有助于防止团队之间在谁做什么、向谁寻求适当级别的批准以标记活动完成方面出现沟通不畅。建议在项目级资源分配表中预定义角色和职责，并在网络安全计划中引用该表，以便轻松查找资源的姓名和角色。每个角色的能力证明可以在资源分配管理文档中找到，这在回答评估员关于职位是否由合适人员填补的问题时会派上用场。

注意： 项目特定资源分配管理文档通常用于捕获给定项目所需的所有角色、已分配给每个角色的个人，以及证明分配人员具备履行角色职能的足够技能的证据。

该计划还可以酌情包含每个活动的定制部分。项目团队可能会争辩说某些活动并非完全适用，因此可以完全或部分定制。例如，如果产品是未直接集成到车辆级别的组件，导致产品供应商无法验证网络安全目标，则可以提供排除网络安全验证测试的论证。在这种情况下，网络安全计划会描述活动哪些部分已定制以及原因。

由于大多数项目并非从零开始，在许多情况下，如果满足复用条件，复用组件可以复用其各自的网络安全工作产品。要确定是否可以复用，复用分析要么记录在网络安全计划中，要么作为由网络安全计划引用的独立文档。分析应列出从先前产品版本中复用的组件，以及复用条件的特征——例如，组件是否未经任何修改就被复用，组件集成的操作环境是否仍然相同，或者最初设计时所依据的假设是否仍然有效。根据这些问题的答案，可以论证复用组件部分或全部网络安全工作产品。例如，一个已集成到新微控制器中且在相同车辆环境和用例下的库可以复用相同的安全要求和设计工件，但可能需要重新执行安全测试，以确保该库在新目标上仍能实现其安全要求。实际上，大多数复用案例都涉及变更，导致网络安全工作产品被更新。通常，必须执行 TARA，以确保现有安全工作产品仍能解决额外网络安全风险，如果不能，则需考虑额外工作。

最后，网络安全活动必须记录预期的输出，以及关于团队应如何准备此输出的任何具体说明。例如，在定义准备网络安全概念的计划时，输出应捕获概念捕获的格式以及存储位置。

除了规划开发中产品的网络安全活动外，该计划还必须考虑在产品集成范围内的外部供应组件。此类组件有两种类型：现成组件（off-the-shelf）和脱离语境开发的组件（CooC）。

该计划必须考虑到所有此类组件，并明确缓解因使用这些组件而引入的额外风险所需的网络安全活动。如表 5.2 所示，所有与规划相关的网络安全活动都由一个工作产品——网络安全计划所涵盖：

表 5.2 – 涵盖网络安全计划的工作产品

在下一节中，我们将学习如何通过遵循采购和供应商管理流程来解决第三方组件引入的风险。

供应商组件的采购与集成

您已经开始规划项目和网络安全活动，在此过程中，您已经确定了几个必须为项目采购的组件。您有两种选择：使用为广泛用例开发但未考虑您精确产品的现成组件，或者与第三方合作开发或调整现有组件以适应您的产品需求。在这两种情况下，您都希望证明您的集成产品仍然符合 ISO/SAE 21434，无论这些组件的安全成熟度如何。通过集成新组件，您实质上暴露于该组件固有的网络安全风险。为了解决这些风险，您必须实现以下目标：

• 识别组件中 ISO/SAE 21434 合规性差距
• 评估组件是否能够满足您分配的网络安全要求
• 验证预期用途、外部接口和操作环境的假设，以及任何已转移或被组件供应商接受的风险

就流程差距而言，您可以寻求供应商的帮助以提供流程合规性证据。就评估组件对其预期用途的适用性而言，您必须首先执行 TARA 以识别风险和必须由组件满足的相应网络安全缓解措施。

注意： TARA 方法识别由组件管理或影响的资产，以及影响这些资产的潜在威胁。通过执行 TARA，我们可以得出组件必须满足的网络安全要求，并确定组件是否能够实现这些要求。有关 TARA 方法的更多详细信息将在项目级概念部分提供。

例如，假设您需要将一个现成的微控制器集成到您的安全网关电子控制单元（ECU）中，该单元需要使用密码加速器和密钥存储来处理车载通信安全要求。如果微控制器单元（MCU）不支持硬件保护的安全环境（HPSE）或密钥管理功能，则不应考虑将其集成到智能网关中。如果 MCU 支持 HPSE，则您可以与组件供应商进一步确认其是否能满足您的流程级期望。同样，如果您计划集成一个 CooC，您必须确认除了组件满足您要求的能力外，在组件开发期间考虑的使用假设对您来说是可接受的。如果不可接受，则集成产品需要额外的安全对策来弥补这些差距。为了促进与供应商的沟通以及共享网络安全活动的职责分配，ISO/SAE 21434 定义了一个通过网络安全接口协议（CSIA）进行供应商选择和分配分布式活动的流程。这最好集成到管理采购和供应商管理的现有流程中。

###供应商能力评估与 CSIA 的作用

ISO/SAE 21434 要求组织在供应商选择过程中建立评估供应商网络安全能力的流程，然后将其添加到批准的供应商列表中。这确保只有能够满足组织设定的流程级安全要求的供应商才能被考虑用于询价（RFQ）。供应商能力评估可以通过问卷调查进行，该问卷调查根据信息管理系统安全和产品安全等领域的供应商安全成熟度进行评分。尽管标准没有为捕获供应商能力证据指定工作产品，但通过评分系统汇编跟踪每个供应商网络安全能力的文档是一个良好的实践。应积极监控存在重大差距的供应商，以确保他们正在采取措施弥补这些差距。应将拒绝或未能解决网络安全发现的供应商排除在未来的投标之外，以此消除供应链风险。

一旦供应商被批准响应询价（RFQ），建议建立一份网络安全接口协议（CSIA），以明确客户和供应商之间的职责。在 RFQ 阶段分享网络安全目标和要求至关重要，这有助于供应商评估他们是否能够实现这些要求，以及是否需要调整成本以应对额外工作。在某些情况下，供应商可能未计划符合 ISO/SAE21434，因此可能会反对填写 CSIA 的必要性。在这种情况下，CSIA 有助于识别供应商交付物中的差距，并帮助项目团队规划如何通过执行网络安全活动来弥补这些差距。例如，项目团队可能会规划额外的安全测试，或者决定对所供组件执行 TARA，以解决供应商未缓解的风险。

CSIA 中涵盖了诸如谁将执行每个网络安全工作产品、结果能否共享以及以何种形式共享、网络安全支持期限、共享漏洞报告等信息的频率、软件物料清单 (SBOM) 共享、评估预期以及每个交付物的详细程度等方面的要求。CSIA 必须被视为具有法律约束力的合同，以确保供应商不会违背先前的承诺。在达到里程碑时，必须经常查阅此协议，以确保就网络安全交付物进行信息交换。供应商通常会抵制共享详细的工作产品（例如 TARA 文档），而更倾向于以摘要形式共享结果。这取决于供应商和客户协商适当的共享细节级别，同时兼顾知识产权保护的合法担忧与验证工作产品正确性和严谨性所需的必要性。在这种情况下，依靠外部评估来证明符合标准可以帮助解决其中一些担忧：

表5.3 – 供应商管理和分布式网络安全活动涵盖的工作产品

现在我们已经理解了网络安全规划和供应商管理活动，是时候进入网络安全产品工程的第一阶段，即概念阶段了。

概念阶段

如果您正在开发一个新车功能（作为一个项目或一个脱离上下文的单个组件），并且需要确定您的项目或组件必须实现的网络安全目标和要求，那么您正处于概念阶段。如图 5.3 所示，您位于 V 型开发周期的左上方，您的目标是识别和处理与您的系统相关的风险：

图 5.3 – 带有安全叠加层的 V 型图

为实现此目标，您必须依赖图 5.1 所示的 TARA 方法。实际上，每当系统引入新的安全相关功能时，就会启动此流程，以确保任何新的网络安全风险都能得到理解，并且整体网络安全概念能适应处理此新风险。这被称为“安全设计”（secure by design）方法，它有望降低在产品生命周期后期发现问题时进行昂贵返工的可能性。

在深入了解本节的细节之前，建议您参考 ISO/SAE 21434 标准的第 3 节，以复习术语和定义。

项目级概念

项目（item）简单来说，就是一组 ECU、传感器、执行器和网络通道，它们共同工作以在车辆级别实现一个功能。在项目级别执行分析的实践是继承自功能安全标准，该标准也要求将车辆功能划分为项目，以识别危险和安全目标。在网络安全中，项目定义必须暴露操作环境及其外部接口，这对于识别威胁源至关重要。为了正确捕获项目定义，您必须识别分析范围内的车辆功能，然后将项目边界围绕参与实现该车辆功能的组件绘制，确保包含车辆边界处的外部接口。过度扩展项目边界将导致包含可能属于不同项目的资产，从而导致重复的威胁分析。另一方面，选择过于严格的项目边界将导致排除与威胁分析活动相关的资产。让我们看一个实现 SAE 3 级自动驾驶功能（如自动紧急制动（AEB））的项示例。为了执行 AEB 功能，该项必须处理车辆传感器数据，融合传感器数据，并通过车辆网络向制动 ECU 提供执行命令：

表 5.4 – 概念阶段工作产品

第一步是确定项目边界。我们将其命名为 ADAS 系统边界，如图 5.4 所示。所有实现 AEB 功能所需的组件都在项目边界内，从执行 AEB 感知、控制和执行算法的片上系统（SoC），以及存储 AEB 软件、固件和机器学习模型的存储单元，到各种传感器及其数据，以及传输感知和执行数据所需的通信通道。一个作为安全监控器和故障转移系统的微控制器也包含在内，因为它确保了我们的 AEB 功能可用，即使 SoC 发生严重故障。MCU 还提供车载通信支持，用于发送和接收车辆状态数据。请注意，我们还包含了后端服务，因为系统可以通过其 Wi-Fi 和蜂窝通道向遥测服务报告紧急制动事件：

图 5.4 – 未包含完整操作环境的项目定义

接下来，我们需要包含操作环境，其中包含与我们的项目直接接口且可能影响项目安全性的组件。请注意，安全分析必须考虑所有构成车辆攻击面的车辆接口，即使它们与安全无关。强调分析项目外部接口的原因是，威胁源于通过恶意攻击从车辆外部发起，而危险（在功能安全范围内）源于系统故障从车辆内部发起。让我们看看添加操作环境如何扩展项目定义：

图 5.5 – 显示操作环境的项目定义

为了支持我们的 AEB 功能并将紧急制动事件报告给后端，我们必须包括中央网关，它允许 CAN、LIN 和以太网帧发送和接收到/来自车辆侧；这包括执行器和车辆动力学传感器。遥测单元包含在内，以显示遥测数据如何通过 Wi-Fi 和蜂窝链路传输到后端。OBD2 端口显示为它支持 ADAS SoC 基于 UDS 的闪存编程。图中未显示与其他 AEB 功能不交互的其他 ECU，仅表示它们被有意排除。

为了改进分析，最后一步是暴露与项目可能相关或不相关的、但与威胁分析相关的任何其他外部接口。例如，车载信息娱乐（IVI）系统通过蓝牙和 Wi-Fi 接口连接，并连接到中央网关 ECU。在项目定义中包含此接口将有助于我们稍后尝试识别可能影响此项目范围内资产的威胁和攻击路径。

一旦您对项目定义感到满意，并假设所有利益相关者都已审查并批准了您的分析范围，现在是时候着手准备 TARA 了：

图 5.6 – 执行 TARA 的四步流程

如图 5.6 所示，根据 ISO/SAE 21434 执行TARA 主要有四个步骤：

注意： 在本章中，我们将简要描述每个步骤，并将完整细节留待第 7 章深入探讨优化方法和整合功能安全方面。

1. 第一步已经通过定义项目涵盖；然而，我们还收集了可以描述系统如何与操作环境交互的数据流图，以帮助识别威胁和攻击路径。

2. 在第二步，我们使用描述项目、上下文及其硬件和软件组件的图表来识别具有价值的对象。通过检查破坏这些资产的网络安全属性的影响，我们可以确定车辆层面的不利后果，也称为损害场景。

   利用这些资产，我们可以应用诸如 STRIDE 之类的威胁建模框架来枚举影响这些资产的威胁。每个威胁场景进一步扩展为实现威胁必须执行的攻击步骤列表。每个攻击路径的影响都映射到损害场景。

3. 在第三步，识别所有资产，列举所有威胁，并定义攻击路径并映射到损害场景之后，现在可以评估攻击可行性和损害影响。因此，在第三步中，损害场景根据其对安全性、车辆操作、经济损害和用户隐私的影响进行影响评级，而攻击路径根据攻击参数（如耗时、所需专业知识、对项目或组件的了解、发起攻击的机会窗口以及所需设备）进行攻击可行性评级。在风险管理框架的帮助下，影响评级和攻击可行性将转换为介于 1 到 5 之间的风险值。

4. 在第四步，分析所有风险值以确定风险处理决策。风险可以通过消除风险源（例如，修改系统架构）、通过定义网络安全控制来降低风险、通过提供风险接受理由来保留风险，或者通过将其转移给另一方（例如系统集成商或购买网络安全保险）来共享风险来避免。已降低的风险会导致创建网络安全目标，而已保留或共享的风险会导致网络安全声明。网络安全目标将进一步细化为系统级网络安全要求，而网络安全声明则阐明了保留或共享风险为何可接受。

网络安全目标（cybersecurity goal）是网络安全要求的最高抽象级别。它仅说明了需要保护哪些资产属性的目标。

假设我们的 ADAS 系统已得到充分分析，我们期望制定一套必须实现的网络安全目标，以确保 ADAS 系统不存在不合理风险。以下是一些示例目标：

1. ADAS 系统应保护软件、校准和机器学习模型的完整性，防止物理和逻辑威胁。
2. ADAS 系统应保护通过 CAN 和以太网接收的传感器通信数据的完整性和真实性，防止物理和网络威胁。

也可以通过直接纳入车辆功能来编写目标：

ADAS 系统应防止因网络或物理威胁导致的 AEB 功能丧失。

虽然这在技术上可能是有效的网络安全目标，但它可能导致许多冗余目标，因为系统具有许多将暴露于相同威胁的功能。因此，我们更倾向于基于资产的目标定义。

概念阶段的另一个输出是网络安全声明（cybersecurity claims）的定义。后者仅仅是关于保留或共享风险背后的理由的声明。该声明必须记录在案，以允许组件的集成商验证此类声明。例如，ADAS 系统所有者可能已决定接受 SoC 和 MCU 之间的心跳消息容易受到物理篡改的风险，这可能导致 ADAS 系统不必要的关闭。

这导致了以下声明：

ADAS 系统接受“心跳信号（SoC 与 MCU 之间）物理篡改”的风险，原因是此类攻击的局部影响和车辆行驶中执行攻击的可行性较低。建议用户使用防篡改外壳以降低此类攻击的可能性。

在创建网络安全目标和声明之后，需要进行审查以验证 TARA 的正确性和完整性。这通过检查项目的资产覆盖范围、损害场景暴露车辆后果的正确性、威胁场景的覆盖广度以及攻击路径的详细程度来评估攻击可行性评级实现。审查员还可以检查影响评级是否合理地涵盖了受影响的利益攸关者，以及攻击可行性评级是否遵循了 ISO/SAE 21434 设定的约定。最后，必须检查风险处理决策的正确性，以确保需要降低的风险已分配了有效的网络安全目标，并且在适用情况下已提出了网络安全声明。由于典型的 TARA 可能包含数十甚至数百个威胁和攻击路径，因此同时验证所有网络安全目标和声明的一致性非常重要。

网络安全概念

现在您已经完成了 TARA 并获得了审查和批准，是时候阐明您要解决的安全问题以及实现这一目标的总体网络安全策略了。问题可以通过说明分析范围内的项目功能、包括系统上下文图、需要保护的系统级资产以及在 TARA 期间考虑降低或消除的风险来定义。另一方面，解决该问题的策略是通过指定网络安全控制和要求，并将其分配给项目及其组件来定义的。在控制、要求和网络安全目标之间建立可追溯性对于证明目标已得到充分覆盖至关重要。

在选择网络安全控制时，建议考虑以下类别：

• 防护
• 检测
• 恢复
• 日志记录

在我们的示例系统中，保护存储介质中软件二进制文件的目标可以通过应用控制来实现，例如使用安全更新机制和对闪存编程工具（如 UDS 客户端）强制执行严格的访问控制来防止未经授权的二进制文件替换。如果攻击者成功篡改了二进制文件，则必须在启动期间使用安全启动机制检测到此类篡改。还可以规定用于恢复系统软件的控制，以确保系统的可用性受到保护——例如，通过要求使用备用存储分区，以便在一个分区无法启动时可以从中启动。最后，可以规定用于记录安全异常的控制，以便在系统部署到生产环境后分析和识别安全事件。每个控制可以通过定义系统级网络安全要求进一步细化，这些要求捕捉系统对必须缓解的每个威胁场景的预期行为。在这里，您会发现 TARA 中的攻击路径对于帮助推导网络安全要求非常有用，因为您的目标本质上是防止或至少显著降低这些攻击的可能性。在某些情况下，网络安全要求被分配给操作环境中项目边界之外的组件。此类要求必须记录在案并与系统集成商共享，集成商必须确保这些要求得到满足。回到我们的示例，对诊断客户端强制执行访问控制机制将为客户端产生一个操作环境要求，即客户端支持基于公钥基础设施（PKI）的例程，以向 ADAS 系统进行身份验证。此要求将需要 ADAS 系统提供商和诊断客户端所有者都同意一种在启用闪存编程之前对客户端进行身份验证的方案。ISO/SAE 21434 标准要求对网络安全概念进行验证，以确保网络安全要求和控制在实现网络安全目标方面的正确性和完整性。

阅读网络安全概念的读者应该相信您已经制定了一个合理的网络安全策略，足以指导产品设计的其余部分。因此，网络安全概念作为最高级别的功能安全要求，因为它充当项目团队推导组件级安全控制和要求的基础。所有团队都必须能够回溯到网络安全概念，以了解他们在开发精细组件时必须考虑哪些威胁类型。这将在设计和实施部分更详细地探讨。

对组件级开发的影响

ISO/SAE 21434 从车辆级别项目的角度阐述了概念阶段。它（在要求 RQ-09-01, 注 6 中）提示，开发一个脱离上下文的组件可以基于假定的或通用的项目，以及对操作环境和外部接口的假设。将概念阶段应用于组件不如应用于项目那么明显，因此我们将通过一个示例来澄清这些差异。

在图 5.4 所示的 ADAS 项目中，一些组件是在脱离上下文的情况下开发的，例如以太网交换机、监控 SoC AEB 功能的 MCU 软件以及为 ADAS 系统提供相机帧的相机传感器。如果您正在开发这些组件中的任何一个，您不能简单地探索您的组件可以集成的所有可能项目，因此您必须对您的组件将要使用的项目、其操作环境以及可能存在的接口做出一些假设。建议组件供应商在准备其网络安全概念之前，假设最恶劣的环境。即使您作为组件供应商可能无法缓解或消除该环境中的所有威胁，您至少能够记录操作环境必须满足的网络安全要求，以实现您的组件的安全使用。例如，以相机传感器为例。如果您假设相机传感器与车辆其他部分良好隔离，并且攻击面很小，您可能会开发一个没有网络安全控制的传感器，以缓解相机帧欺骗、篡改或重放等威胁。对于希望在相机传感器容易被替换的环境中使用相机传感器的客户来说，此类传感器将不适用，客户可能被迫切换到不同的传感器。另一方面，假设一个恶劣的环境将帮助您作为传感器供应商考虑所有威胁，其中相机帧可能被中间人（MiTM）攻击拦截，以伪造、篡改或重放这些帧。因此，该传感器的网络安全概念将提供足够的网络安全控制来保护传感器的资产。

一旦捕获了假定的上下文，就可以准备一个假定的项目来促进安全分析。虽然该活动可能看起来与 OEM 所做的工作重复，但在这种情况下，TARA 的重点是组件本身。换句话说，在执行 TARA 时，您希望深入研究组件接口，以确保为组件生成可操作的网络安全目标和网络安全要求。这种方法可以扩展到任何组件供应商，无论他们是在嵌入式系统中提供软件栈，还是在多种用例中使用的 MCU。为了丰富对远离项目边界的组件的威胁分析，建议考虑与组件相关的常见弱点。通过简单地考虑所有适用的弱点，可以推导出有意义的威胁和攻击路径，并反向工程出需要保护的组件资产。例如，MCU 供应商必须准备 TARA。除了捕获常见的安全相关用例以准备自上而下的威胁分析外，供应商还可以自下而上地考虑弱点，例如 JTAG 端口的访问控制不当、嵌入式闪存命令锁定不当、用于隔离混合临界性软件的弱存储管理机制以及缺乏 IP 块级隔离控制。这些都可以产生一组可以通过考虑如何利用这些弱点来定义的威胁。结果是一个更完整的 TARA，可确保组件以足够的安全严谨性交付。

既然我们已经涵盖了项目和脱离上下文开发的组件的概念阶段预期，是时候转向产品开发阶段了，在该阶段，概念阶段的结果将应用于设计和实施。

设计与实施

重新审视图 5.3 中的 V 型图，我们可以看到网络安全概念中的要求被进一步细化为网络安全规范，并分配给架构及其子组件。网络安全规范的主要目标是确保架构满足来自更高层级（例如概念或父组件）的网络安全要求。此时，可以利用现有架构规范来满足此工作产品，只需提供与父网络安全要求的可追溯性即可。

接下来，您必须将高级安全需求和架构细节细化为组件级别的安全需求和架构片段。组件级别的安全需求和架构片段构成组件网络安全规范。假设您正在开发为其他软件应用程序提供密钥管理服务的软件。网络安全概念将包含关于加密密钥保护免受非法访问和泄露的要求。网络安全规范必须推导出详细说明实现这些要求的精确机制的安全要求，例如使用自主访问控制和启用针对侧信道攻击的硬件对策。此外，组件架构应至少提供一个安全叠加层，显示这些要求如何通过架构得到满足。在考虑网络安全时，对架构有两个主要影响。对于导致新系统功能的安全要求，可以有描述它们的新架构元素和接口。例如，强制使用 MACsec 来保护以太网帧的完整性和机密性的安全要求将导致新的序列图和静态架构图，这些图表概述了 MACsec 如何在软件和硬件中得到支持。与其将这些细节捕获在独立的架构文档中，不如将其集成到通用系统架构文档中，以简化与其他支持功能的追溯和交叉链接。在某些情况下，安全要求仅约束现有功能。例如，安全要求可以指定所有进程在从初始化模式转换到操作模式之前都应放弃根权限。这可以在架构中通过首先识别描述进程启动方式的架构元素和接口，然后添加关于根权限如何放弃的约束来实现。结果是一个增强现有架构图的安全叠加层。

开发后要求

作为推导安全要求的一部分，将会出现一些影响组件集成商的要求。这些要求被捕获为开发后要求，告知用户如何安全地安装、初始化或操作组件。

这些要求可以作为安全程序捕获，以便在组件部署后应用网络安全控制。这包括安全设置、初始化、生产和退役系统的程序。示例包括在工厂中配置加密密钥、烧熔保险丝以将芯片转换为安全生命周期状态、锁定调试端口以及在将设备转换为退役状态之前清除私有数据等程序。请注意，这些程序必须标记为通过面向客户的文档（例如网络安全手册）与系统集成商共享。

配置和校准

与组件相关的、用于启用网络安全控制或满足网络安全要求的所需配置和校准设置，也必须记录在网络安全规范中——例如，定义在芯片转换为特定生命周期状态后强制执行安全启动的配置选项。

根据系统的复杂性，网络安全规范可以在设计的多个层级进行细化，直到达到单元级，以确保充分指定安全行为以实现单元实施。

弱点分析

在网络安全规范的制定和架构的逐步形成过程中，预计会出现新的风险。简而言之，网络安全控制的引入为系统带来了新的资产，而这些资产又会暴露于系统级 TARA 中可能未考虑的新威胁。建议进行残留风险分析，以检查可能违反更高级别网络安全要求的威胁。这将导致一个迭代过程，用于处理残留风险，直到风险水平达到可接受的程度。

例如，在尝试保护持久存储中的资产免受篡改时，您决定派生一个用于生成存储记录的 HMAC（带密钥的哈希消息认证码）的新密钥。但是，该密钥可能会被未经授权的应用程序滥用，该应用程序可以使用该密钥生成一个新的 HMAC，并将其与被篡改的存储记录一起写入。这种风险需要通过应用额外的安全控制来缓解，例如通过基于软件的访问控制机制将密钥的使用限制给单个所有者。这种分析残留威胁和细化安全要求的过程可以称为设计级 TARA 或残留风险评估。虽然 ISO/SAE 21434 没有强制要求在设计的每个层级重复 TARA，但通过迭代的 TARA 过程来考虑残留风险是一个良好的实践，该过程将威胁从系统级别进一步分解到组件和子组件级别。这确保了随着设计的演进，高级网络安全目标仍然得到满足。

除了全面设计 TARA 的替代方案是架构弱点分析。ISO/SAE 21434 将这种类型的分析作为一项要求，并指出攻击路径分析是执行该分析的一种方式。根据组件的关键性，可能足以依靠常见弱点清单，并在安全专家的帮助下进行咨询，以确保遵循最佳实践并消除已知弱点。

提醒： 在第 3 章中，我们探讨了车辆所有层面的威胁和漏洞。了解常见的弱点是解决实际设计中漏洞的重要先决条件。

通常用于报告事件时的漏洞分析过程，也可用于在设计阶段分析潜在弱点。例如，可以分析处理更新软件认证方面的弱点，以识别利用该弱点的攻击路径。如果识别出可行的攻击路径，则该弱点应被视为漏洞，并可计算 CVSS 评分以确定修复的优先级。可以通过修改架构或引入新的对策来消除该弱点。

单元实施

ISO 标准的产品开发部分还指出需要应用安全设计原则和安全编码指南。前者可以在成熟的受信任设计原则的帮助下准备，这些原则在第 2 章中介绍。在做出新的设计选择时，必须考虑诸如执行输入验证、输入净化、应用最小权限和域分离等原则。为了支持安全的单元实现，必须使用静态代码分析工具和安全代码审查。如果您正在开发硬件组件，可以利用信息流分析和形式化验证工具来消除在特定情况下硬件安全资产可能暴露的弱点。

在涵盖了设计和实现之后，是时候转向测试阶段执行的网络安全活动了，以验证我们的安全要求是否已满足，并且我们的实现没有安全漏洞。

验证测试

涵盖所有硬件和软件网络安全要求的网络安全测试是必要的，以确定硬件和软件设计是否符合网络安全规范。安全要求和安全测试用例之间的可追溯性是确保安全措施按预期实施的重要步骤。

同样，可以采用形式化验证技术来验证特定硬件模块是否能够实现其安全目标。在单元级别，ISO/SAE 21434 没有提出具体的流程要求，除了标准单元验证之外。遵循通用的质量管理体系将确保软件单元在集成到更大的组件之前经过适当级别的覆盖测试。单元测试的一个良好实践是应用测试用例来验证单元的输入、输出、数据和控制流。测试应涵盖错误处理、故障注入和恢复方法，以确保单元按预期运行。从安全角度来看，这些领域的单元级错误可能引入可利用的漏洞。因此，纠正单元测试失败会增加对软件或硬件不存在未知漏洞的信心。应用回归测试以消除单元更改对其他软件单元产生不利影响的可能性也很重要。在设计单元测试用例时，应从通用测试数据、边界情况、错误处理和故障/恢复处理中抽取代表性测试用例。值得注意的是，边界情况是漏洞的一个良好来源，测试人员在正常环境的假设下可能会忽略这些边界情况，即使它们在恶意行为者存在的情况下非常有可能发生。

在网络安全验证测试方面，ISO 标准规定了几种方法，包括模糊测试、漏洞扫描、基于需求的测试、检查，甚至渗透测试。

注意： 基于需求的测试和检查是功能安全和质量管理实践中常用的测试方法。在网络安全方面，基于需求的测试的目的是验证产品是否确实实现了安全要求，同时考虑评估安全功能是否足以处理相应攻击场景的测试场景。同样，检查旨在通过考虑攻击者可能违反要求的情况来验证设计和代码是否真正体现了要求的意图。在这两种情况下，区别因素是在验证过程中考虑攻击者的心态。

模糊测试是一种软件测试方法，通过注入畸形输入来暴露可能构成系统漏洞的软件缺陷。模糊测试工具将这些输入注入系统，然后监控异常情况，例如崩溃或信息泄漏。除了能够生成正确的测试输入集之外，模糊测试器还必须能够检测对系统的不利影响，例如系统崩溃或异常。

最简单的模糊测试用例依赖于基于固定种子生成的随机数据，以确保随机集是可重复的。基于模板的模糊测试引入无效输入，然后根据系统的行为反馈调整后续测试，以使测试更有效。生成式模糊测试需要理解被测协议、API 或数据源，以确保测试将系统地违反底层规则，以期望触发意外的可利用行为。

请注意，模糊测试并不直接测试安全措施，而是暴露可能导致安全措施未能实现其目标的错误。

模糊测试已被证明是一种具有成本效益的方法，用于识别软件系统中潜在的网络安全漏洞。这些漏洞包括缓冲区溢出、资源耗尽和解析错误，所有这些都有可能被恶意攻击者利用，从而未经授权访问 ECU。

例如，一个加密功能在正常情况下可以产生正确的结果，从而实现安全目标。然而，一个导致秘密密钥泄露的缓冲区溢出错误可能只有通过模糊测试工具才能发现，该工具会提供畸形输入以暴露该错误，从而揭示加密功能的安全性漏洞。巧合的是，模糊测试既是测试工具也是黑客工具，攻击者可以利用它来识别易于发现的、可利用的漏洞。发现安全漏洞的额外好处是增强了系统对异常或随机输入的鲁棒性的信心。模糊测试人员面临的一个挑战是，如果触发崩溃，恢复系统的时间可能很长，复杂 ECU 的情况就是如此。这使得重现和分析错误变得更加困难。为了帮助进行根本原因分析，需要代码检测以识别触发崩溃的精确事件。

对在信任边界处提供接口的软件组件进行模糊测试是一个良好的实践。模糊测试对于对输入数据执行复杂操作（例如解析或数据转换）的组件特别有用。这可确保组件能够处理畸形输入，并且不会因无效输入而降低系统安全性。根据 ISO/SAE 21434，通过独立分析或探测在组件级别进行的渗透测试是可选的。通常，组件供应商可能会由于其安全关键性而选择系统中的特定部分进行外部分析或测试。例如，芯片供应商可能希望其引导 ROM 代码在流片前由独立的安全性审查员进行分析，以避免昂贵的修复。| 标准章节 | 涵盖的工作产品 | | :——————– | :————————————————————————————————————————– | | 10.4.1 设计 | [WP-10-01] 网络安全规范
[WP-10-02] 开发后网络安全要求
[WP-10-03] 建模、设计或编程语言以及编码指南的文档
[WP-10-04] 网络安全规范验证报告
[WP-10-05] 产品开发阶段发现的弱点 | | 10.4.2 集成和验证 | [WP-10-05] 产品开发阶段发现的弱点
[WP-10-06] 集成和验证规范
[WP-10-07] 集成和验证报告 |表 5.5 – 产品开发阶段涵盖的工作产品

请注意，必须对每个工作产品进行审查，以确保工作产品的质量。

完成了集成和验证测试后，我们必须验证网络安全目标的实现情况。

##确认测试

ISO/SAE 21434 将验证定义为在车辆级别执行的活动。本条款的目标是验证在概念阶段已识别的网络安全目标是否已在项目集成到实际车辆环境中后真正实现。组件供应商可以通过在模拟车辆的环境中应用测试来执行网络安全目标验证。虽然这不是强制性的，但通常在 OEM 发现产品不符合网络安全目标之前，验证您为产品设定的网络安全目标是否已满足是一个良好的实践。验证通常通过渗透测试进行，通过发现未知漏洞来尝试违反网络安全目标。OEM 在优先考虑用于渗透测试的 ECU 时，可能希望所有面向外部的 ECU（例如遥测或信息娱乐）在测试其他更深层次嵌入式 ECU 之前，由第三方进行测试：

表 5.6 – 涵盖网络安全验证测试阶段的工作产品

渗透测试旨在发现网络安全控制措施纳入后的残留风险。渗透测试可以在多个层面进行。例如，可以执行网络渗透测试以识别不安全的端口、开发协议的使用等。可以执行接口渗透测试以识别开放的接口或服务，例如 SSH 和 Telnet。ECU 级渗透测试可以执行半侵入式和全侵入式测试，以使用故障注入（glitching）和侧信道分析（side-channel analysis）提取加密密钥。让我们仔细看看通过执行渗透测试可以实现的目标：

• *识别安全漏洞：**渗透测试有助于识别可能被攻击者利用的安全漏洞。这些漏洞可能包括过时的软件、弱密码、不安全的网络配置以及其他可能使敏感数据面临风险的问题。
• 降低数据泄露风险： 通过识别和解决安全漏洞，组织可以降低数据泄露的风险。数据泄露可能代价高昂，并损害公司的声誉，因此采取积极措施预防数据泄露非常重要。
• 增强整体安全态势： 定期渗透测试可以帮助组织通过识别改进领域和实施安全最佳实践来增强其整体安全态势。

随着与产品开发相关的网络安全活动完成，现在是时候准备发布阶段了。下一节将详细介绍在完成特定的安全检查和保证后，认定产品具备发布资格所需的步骤。

产品发布

至此，您已完成了网络安全计划中定义的所有网络安全活动。现在，您已准备好进行正式的产品发布。但在进行此操作之前，您必须证明工作产品已按照组织的 CSMS 准备，并且您的产品已完全实现了 CSMS 的目标。获得发布批准需要您准备一份网络安全案例并接受网络安全评估。

网络安全案例

快进到项目结束时，关于产品为何在其预期用例中达到了足够的网络安全水平的论证必须在网络安全案例中捕获。通常，该案例依赖于两种论证：流程论证和技术论证。流程论证表明产品遵循了网络安全工程流程，并提出了任何偏差，以及为什么这些基于偏差的风险是可接受的论证。所有网络安全工作产品的整体汇编到一个存储库中，作为所有计划活动都已充分完成的证据。技术论证解释了计划中的网络安全目标，以及为确保实现这些目标而在整个生命周期中整合的所有技术对策。同样，任何残留风险都包含在内，并附有关于为什么残留风险处于合理水平以允许产品投入生产的论证。

网络安全评估

以计划为路线图，进行评估以衡量产品相对于组织网络安全工程流程的符合性水平。评估通常在工作产品可用时分阶段进行。这是首选方法，以确保在有时间进行纠正时检测到不符合项，而不是等到项目临近生产才开始进行调整。评估员通常会要求将工作产品交付给一个独立的小组，无论是组织内部还是外部，以评估符合性。除了流程符合性之外，评估团队还可能依赖独立的专业技术审查员来判断工作产品的质量——例如，TARA 是否充分考虑了与产品相关的所有威胁，或者技术对策是否被正确选择和实施。成功的评估将导致开发后报告获得签署发布，表明产品已实现了其所有预期的流程和技术目标：

表 5.7 – 产品发布阶段涵盖的工作产品

注意： 产品可以以多种成熟度级别发布（例如，alpha、beta 和生产意图）。选择每个产品发布级别必须执行哪些网络安全活动非常重要。例如，即使软件产品仅用于道路测试，也应执行漏洞扫描。同样，如果底层资产在发布版本之间是通用的，则某些网络安全控制应应用于所有发布类型。例如，如果某些机器学习模型被认为是机密的，那么即使是仅供台架测试的版本，也应对其进行加密，以防止攻击者在获得早期产品发布时泄露信息。

产品被认定适合生产意图发布后，便为下一阶段铺平了道路，即制造和生产。在下一阶段，我们将考虑与网络安全相关的生产方面，这些方面必须针对经历生产周期的项目和组件进行考虑。

生产规划

您已经发布了产品，表明它已准备好进行生产。此时，它必须在制造环境中进行实际生产。无论是生产单个组件还是完全集成的车辆，在制造过程中应用网络安全措施都是在正常运行期间保护系统的重要组成部分。在设计阶段确定的开发后要求在生产阶段由系统集成商应用。所有此类活动都必须通过生产计划进行捕获。例如，MCU/SoC 供应商可能指定在制造过程中注入秘密密钥或锁定特定接口的程序。这些程序必须捕获在芯片供应商（如果他们负责执行此步骤）或相应的集成商（例如 ECU 供应商）的生产计划中。同样，与 ECU 和车辆组装相关的开发后要求必须捕获在各自的生产计划中。请注意，如果 TARA 已充分分析了制造流程，则网络安全对策应集成到制造流程中。例如，关于在制造线中使用硬件安全模块（HSM）来执行代码签名并生成封装密钥以在 ECU 转换为生产状态之前注入的规范必须已经到位。

在软件组件的情况下，生产计划通常涉及二进制加密和代码签名方面。如果组件以加密形式交付，并且供应商有意禁止修改软件，那么他们可能会选择在交付前用自己的私钥对其进行签名。规划代码如何签名以及密钥如何管理可以在软件网络安全生产计划中记录：

表 5.8 – 生产阶段涵盖的工作产品

注意： 预计 ECU 或硬件组件将有生产计划，但某些软件组件可以豁免。例如，集成到更大系统中的软件库不需要正式的生产计划。相反，只需在用户手册中记录如何安全地将库集成到更大的系统中就足够了。如果在设计过程早期未考虑制造环节，那么当组件进入生产阶段时，很可能无法进行更改，因此必须让制造工程师尽早参与威胁和风险分析，以避免后期出现不愉快的意外：

图 5.7 –映射到网络安全风险管理的各个阶段

产品退出生产阶段后，现在进入运行和维护阶段。在下一节中，我们将探讨确保产品在此阶段的网络安全对于完成生命周期至关重要。

运行与维护

您已经生产了您的部件，它现在正在道路上行驶。恭喜您——您可以庆祝了！但是，别急——您的网络防御工作现在已转变为事件响应。在如图 5.7 所示的前三个阶段，我们的目标是尽可能消除或降低风险。对于无法降低的风险，我们提供了理由来接受风险或将其转移给其他方。一旦进入运行和维护阶段，我们的目标是通过一个流程来响应新出现的风险，该流程能有效、及时地识别和解决这些风险。

当系统处于实际环境中时，它会暴露在您在概念和设计阶段考虑过的所有假设威胁之下。现在，来自各个领域的攻击者可能正在积极尝试颠覆您的系统，因此，在运行模式下规划网络安全维护是必不可少的。这可以通过两种主要方法实现：

• 网络安全监控
• 事件响应和补救

运行阶段还包括服务，在威胁分析期间必须考虑这一点，以确保在该事件期间维护网络安全。例如，如果 ECU 必须在经销商处更换，则必须定义网络安全程序，以便新 ECU 可以安全地配置。同样，如果执行诊断例程以排除车辆问题或重新刷写部件，则必须考虑适当的诊断客户端身份验证。这可以扩展到所有车辆组件，以确保在不损害运行系统安全性的情况下执行故障分析。例如，启用 JTAG调试故障部件不应导致泄露全局秘密，从而使生产意图系统不安全。

监控

首先，了解您的产品在现场面临的新兴威胁非常重要。通过监控与您的产品相邻的领域，您可以及时了解可能适用于您的漏洞。例如，如果您正在构建遥测单元，跟踪对手机和蜂窝基础设施的攻击对于识别相关漏洞至关重要。这需要建立一个流程来摄取风险、分类事件，并通过事件响应做出反应。图 5.8 显示了可以监控的典型信息源，以识别潜在的网络安全事件：

图 5.8 – 网络安全监控期间考虑的信息源

漏洞分析

在产品开发过程中，漏洞分析是识别和消除可利用安全弱点的关键工具。我们在“设计与实施”部分提到了这一点，强调了安全检查清单与设计级威胁分析相结合的必要性，以分析潜在漏洞。

一旦产品出货，漏洞分析就成为一个流程，通过该流程可以分析事件，以确定系统是否受到影响以及影响程度。假设某个研究员联系贵公司，声称您的 ECU 包含一个漏洞，允许通过诊断服务回滚车辆里程表。此事件首先进行分类，以确定问题是否适用于您的车辆，以及组织内受影响的群体有哪些，因为他们必须被纳入。如果事件被证实为合理，团队将执行攻击路径分析，以确定利用该漏洞所需的攻击步骤。其可行性可以通过基于攻击潜力的办法或基于 CVSS 的办法进行评分。前者依赖于 HEAVENS 等风险评分方法，而后者则依赖于事件响应和安全团队论坛（FIRST）定义的漏洞利用性指标。结合攻击路径分析，评估影响以确定整体网络安全风险级别。如果整体风险级别高于组织可容忍的级别，则漏洞将从分析阶段转变为管理阶段。

注意： 攻击路径分析不仅限于开发阶段执行的 TARA。它也是在已发布产品的漏洞分析阶段应用的重要工具。攻击路径分析的目标是描述漏洞如何被利用，以准确评估漏洞的严重性并确定是否需要修复。

漏洞管理

事件响应流程必须确保及时分析和处理有关网络安全漏洞/事件的报告。掌握事件报告程序对于让受影响方有充足的时间制定缓解计划，包括准备和测试补丁后再部署至关重要。为漏洞分配一个问题ID（例如 JIRA 工单），并指定合适的人员跟踪解决方案，是确保漏洞得到管理的第一步。接下来，团队必须制定一份事件响应计划，其中包括识别受影响方、向受影响方传达关于缓解措施的信息，以及执行缓解措施的行动计划。在后台，将触发根本原因和纠正措施（RCCA），以找出事件原因并采取纠正措施以防止其在未来再次发生。在某些情况下，如果缓解成本高于解决成本，OEM 可能会选择不缓解漏洞并接受风险。在我们的里程表篡改场景中，OEM 可能会认为由于里程表回滚导致的虚假保修索赔的影响远小于修改软件和发布更新的成本（假设软件不再维护且不存在 OTA 机制）。在所有情况下，缓解或接受风险的理由必须记录在案：

表 5.9 –漏洞管理涵盖的工作产品

更新

缓解新出现的网络安全风险的一个关键方法是能够及时修补易受攻击的车辆系统。近年来，这意味着添加空中下载（OTA）更新功能已成为强制性要求，以防止车辆系统处于不安全和潜在危险的状态。除了软件更新，车辆系统在绝对必要时还必须能够接收硬件更新。由于硬件更改的巨大成本，汽车公司必须投资于网络安全工程系统，以避免组件需要物理更改的情况。例如，如果硬件包含无法修补的漏洞（例如引导 ROM 错误），这可能导致安全启动被绕过，则可能会发生这种情况。

在涵盖了运行和维护阶段之后，从网络安全角度来看，最后一个需要考虑的阶段是产品生命周期终止（End of Life）。在下一节中，我们将探讨保护生命周期这一最后方面如何有助于仍在使用的产品的安全性，并保护各种利益相关者的资产。

产品生命周期终结（End of Life）

产品已达到其生命周期终结。现在，您可以放心，没有人能够攻击您的系统，对吗？不——即使您准备将该产品埋葬在最终的安息之地，您也必须处理可能被一个有决心的攻击者“挖掘”出来的活跃资产，该攻击者希望对其他仍在运行的产品发起攻击。例如，知识产权或用户私人数据可能仍然可以在一辆准备报废的车辆中访问。爱好者在 eBay 上购买此类零件是很常见的，因此产品必须有将此类系统转换为安全状态的程序，在该状态下资产无法暴露。这可以通过调用随机化秘密密钥或清除用户秘密的例程来实现。生命周期终结准备还必须包括所有权变更事件。当所有权发生变更时，OEM 必须提供删除个人身份信息（PII）的程序：

表 5.10 – 生命周期终结和停用阶段涵盖的工作产品

除了解决停用问题外，ISO/SAE 21434 还要求所有相关方明确定义网络安全支持的终止，以确保系统在计划的到期日期之前都能获得充分支持。考虑到车辆在生产后可能在道路上行驶超过十五年，与组件供应商协商网络安全支持非常重要，以确保即使供应商不再营业，您仍然可以维护和修补供应链中的关键产品。

总结

本章全面概述了 ISO/SAE 21434 标准及其在实施系统化网络安全工程方法开发汽车系统方面的关键作用。通过深入探讨 V 型开发生命周期各个阶段的复杂性，并展示它们如何相互依赖，我们强调了在产品工程过程的每一步都遵循安全设计方法的重要性。正如我们所展示的，网络安全活动必须从头到尾嵌入到该过程中，而不是作为事后考虑补丁上去。我们的讨论强调了理解与标准相关的各种工作产品以及如何利用它们来实现安全系统的重要性。此外，我们阐述了标准的网络安全活动在系统整个生命周期（从规划到生命周期结束）中的相关性。

总而言之，本章提供的见解强调了采用遵循 ISO/SAE 21434 标准的系统化网络安全工程方法的必要性。采用这种方法将确保有效管理网络安全风险，为所有人创建更安全、更可靠的汽车系统。在下一章中，我们将探讨网络安全与功能安全之间的异同之处。通过整合这两个领域的程序和技术工作产品，我们可以创建一种更全面、更强大的汽车系统开发方法，同时解决功能安全和网络安全风险。

现在我们已经对 ISO/SAE 21434 标准有了深入的了解，我们将把注意力转向安全标准与其对应的汽车功能安全标准 ISO 26262 之间重叠和冲突的领域。