《ISO/SAE 21434-2021 道路汽车--网络安全工程》标准解读

1 范围

略

2 归一化引用

略

3 术语定义

相关项： 实施车辆级功能的组件或组件集; 例如 安全气囊打开系统
组件： 逻辑上和技术上可分离的部分；例如 微控制器
资产： 具有价值或对价值有贡献的对象；例如 密钥
网络安全目标： 与一个或多个威胁场景相关联的概念级网络安全需求；例如 应防止未经授权披露用户敏感信息
网络安全要求： 实现网络安全目标的要求；
威胁场景： 网络安全属性受到损害的潜在原因；例如 伪造 ECU 和 User 之间的通信
网络安全属性： 值得 保护的属性； 机密性，完整性，可用性
损害场景： 涉及车辆或车辆功能并影响道路使用者的不利后果； 例如 安全气囊以外打开，导致驾驶员受伤
确认： 通过提供客观证据， 确认该相关项的网络安全目标已足够， 并已实现
验证： 通过提供客观证据， 确认已满足了规定的需求

4 总则

相关项、 功能、 组件和相关术语之间的关系如下：



第5章节~第15章节，每个章节包含5部分内容：
总则： 条款的概述信息
目标： 条款的目标
输入： 必要的文件和其他支持文件
要求和建议： 描述条款的具体要求
工作成果： 该条款所需要输出的工作成果

5 组织级网络安全管理

总则，目标 略。

5.1 输入

先决条件：
无

进一步支持信息：
符合支持质量管理的标准的现有证据。IATF16949

5.2 要求和建议

5.2.1 网络安全管理

【RQ-05-01】组织应制定网络安全政策， 其中包括：
a) 了解知晓道路车辆的网络安全风险； 以及
b) 执行管理层对管理相应的网络安全风险的承诺。

【RQ-05-02】组织应建立和维护以下规则和流程：
a) 能够实现本文件的要求； 以及
b) 支持相应活动的执行。
注4: 规则和流程包括概念、 产品开发、 生产、 操作、 维护和退役， 包括 TARA 方法、 信息共享、 网络安全监控、 网络安全事件响应和触发器

【RQ-05-03】组织应分配和传达实现网络安全的职责和相应的组织权限来实现和维护网络安全

【RQ-05-04】组织应提供解决网络安全问题的资源

【RQ-05-05】组织应确定与网络安全相关或与其互动的学科， 并建立和维护这些学科之间的沟通渠道，以便：
a) 确定网络安全是否以及如何集成到现有流程中； 以及
b) 协调相关信息的交流。

5.2.2 网络安全文化

【RQ-05-06】组织应培养和维护强大的网络安全文化

【RQ-05-07】组织应确保网络安全角色和职责的人具备履行这些角色和职责的能力和意识

【RQ-05-08】组织应建立并保持持续改进过程
例如：持续改进过程， 包括：
— 借鉴以往经验， 包括网络安全监控和网络安全内外部网络安全相关信息收集的网络安全信息；
— 从网络安全相关信息中学习该领域类似应用的产品；
— 获得将在后续网络安全活动中应用的改进；
— 向相关人员传达有关网络安全的经验教训； 以及
— 根据[RQ-05-02]检查组织规则和流程的充分性。

5.2.3 信息共享

【RQ-05-09】组织应定义在何种情况下需要、 允许或禁止在组织内外部进行网络安全相关的信息共享

【RC-05-10】组织应根据[RQ-05-09]， 将其对共享数据的信息安全管理与其他各方保持一致

5.2.4 管理系统

【RQ-05-11】组织应按照国际标准或同等标准建立和维护质量管理体系， 以支持网络安全工程，解决
a) 变更管理；
b) 文档管理；
c) 配置管理；
d) 需求管理；

【RQ-05-12】现场维护产品网络安全所需的配置信息应保留， 直至产品网络安全支持结束， 以便采取补救行动

【RC-05-13】应建立一个针对生产过程的网络安全管理系统， 以支持第 12 条的活动

5.2.5 工具管理

【RQ-05-14】应管理能够影响项目或组件网络安全的工具

【RC-05-15】支持网络安全事件补救措施的适当环境（见13.3）应可重复，直到产品的网络安全支持结束。

5.2.6 信息安全管理

【RQ-05-16】工作产品应按照信息安全管理系统进行管理

5.2.7 组织级网络安全审计

【RQ-05-17】网络安全审计应独立进行， 以判断组织过程是否实现了本文件的目标

5.3 工作成果

【WP-05-01】网络安全政策、 规则和流程， 由 5.4.1 至 5.4.3 的要求制定
【WP-05-02】5.4.2中【RQ-05-07】产生的能力管理、意识管理和【RQ-05-08】产生的持续改进的证据
【WP-05-03】5.4.4和5.4.6要求产生的组织管理体系的证据
【WP-05-04】5.4.5要求产生的工具管理证据
【WP-05-05】根据5.4.7的要求输出的组织网络安全审计报告

6 依赖项目的网络安全管理

6.1 输入

先决条件：
无

进一步支持信息：
组织网络安全审计报告；
项目计划。

6.2 要求和建议

6.2.1 网络安全责任

【RQ-06-01】应按照[RQ-05-03]分配和沟通项目网络安全活动的责任

6.2.2 网络安全计划

【RQ-06-02】为了确定相关项或组件是否需要网络安全活动，应对相关项或组件进行分析，以确定：
a） 该相关项或组件是否与网络安全相关；
注1：附件D提供了一种可用于评估网络安全相关性的方法和标准。
注2：如果相关项或组件被确定为与网络安全无关，则没有网络安全活动，因此网络安全规划不会继续。
b） 如果该相关项或组件与网络安全相关，则该相关项或部件是新开发还是重用；以及
c）是否应用了根据6.4.3的裁剪。

附D 网络安全相关性判定方法和标准：

【RQ-06-03】网络安全计划应包括：
a） 活动的目的；
b） 对其他活动或信息的依赖性；
c） 负责执行活动的人员；
d） 执行活动所需的资源；
e） 活动的开始点或结束点以及预期持续时间；
f）待生产工作产品的标识。

【RQ-06-04】制定和维护网络安全计划以及根据网络安全计划跟踪网络安全活动进展的责任应按照[RQ-05-03]和[RQ-05-004]分配

【RQ-06-05】网络安全计划应为：
a） 在开发项目计划中引用；或
b）包含在项目计划中，以便区分网络安全活动。

【RQ-06-06】网络安全计划应根据第9、10、11和15条的相关要求，明确在概念和产品开发阶段网络安全所需的活动。

【RQ-06-07】当确定要执行的活动发生变化或改进时，应更新网络安全计划。

【PM-06-08】对于根据15.8的分析确定的风险值为1的威胁情景，可以省略对9.5、第10条和第11条的遵守。

【RQ-06-09】网络安全计划中确定的工作产品应进行更新和维护，以确保准确性，直至发布后进行开发。

【RQ-06-10】如果网络安全活动是分布式的，客户和供应商应根据第7条分别制定关于各自网络安全活动和接口的网络安全计划

【RQ-06-11】网络安全计划应按照5.4.4进行配置管理和文件管理。

【RQ-06-12】网络安全计划中确定的工作产品应按照5.4.4进行配置管理、变更管理、需求管理和文档管理。

6.2.3 裁剪

【PM-06-13】网络安全活动可以裁剪。

【RQ-06-14】如果一项网络安全活动被裁剪，那么应提供并审查裁剪是否足以实现本文件相关目标的理由。

6.2.4 重复使用

【RQ-06-15】如果已经开发了一个相关项或组件，并且：
a） 计划进行修改；
b） 计划在另一个操作环境中重复使用；或
c） 计划在不进行修改的情况下重复使用，并且与项目或组件有关的信息发生了相关变化。

【RQ-06-16】相关项或组件的重复利用分析应：
a） 识别相关项或组件的修改及其操作环境的修改；
b） 分析修改对网络安全的影响，包括对网络安全声明和先前假设的有效性的影响；
示例3对网络安全要求、设计和实施、操作环境、假设和操作模式的有效性、维护、对已知攻击的敏感性以及已知漏洞或资产的暴露的影响。
c） 识别受影响或缺失的工作产品；示例4 TARA考虑了新的或修改后的资产、威胁情景或风险值。
d） 在网络安全计划中规定符合本文件所需的网络安全活动（见6.4.2）

【RQ-06-17】组件的重用分析应评估：
a） 该组件能够满足其要集成的相关项或组件的分配网络安全要求；
b）现有文件足以支持集成到一个相关项或另一个组件中。

6.2.5 组件上下文

【RQ-06-18】对脱离上下文开发的组件的预期用途和上下文（包括外部接口）的假设应记录在相应的工作产品中。

【RQ-06-19】对于脱离上下文开发组件，网络安全要求应基于【RQ-06-18】的假设。

【RQ-06-20】对于脱离上下文开发的组件的集成，应验证【RQ-06-18】的网络安全声明和假设。

6.2.6 现成组件

【RQ-06-21】在集成现成组件时，应收集和分析网络安全相关文件，以确定是否：
a） 可以满足分配的网络安全要求；
b） 该组件适用于预期用途的特定应用环境；
c）现有文件足以支持网络安全活动。

【RQ-06-22】如果现有文件不足以支持现成组件的集成，则应确定并执行符合本文件的网络安全活动。

6.2.7 网络安全案例

【RQ-06-23】应创建网络安全案例，为相关项或组件的网络安全提供论据，并辅以工作成果。

6.2.8 网络安全评估

【RQ-06-24】是否对相关项或组件进行网络安全评估的决定应得到应采用基于风险的方法的理由的支持。

【RQ-06-25】应独立审查【RQ-06-24】的合理性。

【RQ-06-26】网络安全评估应判断相关项或组件的网络安全性

【RQ-06-27】应根据【RQ-06-01】任命一名独立负责规划和执行网络安全评估的人员。

【RQ-06-28】进行网络安全评估的人员应具备：
a） 获取相关信息和工具；以及
b）执行网络安全活动的人员的合作。

【PM-06-29】网络安全评估可能基于对本文件目标是否实现的判断。

【RQ-06-30】网络安全评估的范围应包括：
a） 网络安全计划和网络安全计划中确定的所有工作成果；
b） 网络安全风险的处理；
c） 为项目实施的网络安全控制和网络安全活动的适当性和有效性；
d） 证明实现本文件目标的理由（如有）。

【RQ-06-31】网络安全评估报告应包括接受、有条件接受或拒绝项目或组件网络安全的建议。

【RQ-06-32】如果根据【RQ-06-31】提出有条件接受的建议，则网络安全评估报告应包括接受的条件。

6.2.9 开发后期的发布

【RQ-06-33】在开发后期的发布之前，应提供以下工作产品：
a） 网络安全案例【WP-06-02】；
b） 如果适用，网络安全评估报告【WP-06-03】；
c）开发后期的网络安全要求【WP-10-02。

【RQ-06-34】相关项或组件的后期开发发布应满足以下条件：
a） 网络安全案例提供的网络安全论点令人信服；
b） 网络安全案例经网络安全评估确认（如适用）；
c）接受开发后期阶段的网络安全要求。

6.3 工作产物

【WP-06-01】网络安全计划，源于6.4.1至6.4.6的要求
【WP-06-02】网络安全案例，源于第6.4.7节
【WP-06-03】根据6.4.8的要求生成的网络安全评估报告（如适用）
【WP-06-04】根据6.4.9的要求发布开发后期报告

7 分布式网络安全活动

7.1 输入

无

7.2 要求和建议

7.2.1 供应商能力

【RQ-07-01】应评估候选供应商根据本文件开发和（如适用）执行开发后期活动的能力。

【RQ-07-02】为了支持客户对供应商能力的评估，供应商应提供网络安全能力记录。

7.2.2 报价请求

【RQ-07-03】客户向候选供应商发出的报价请求应包括：
a） 正式要求遵守本文件；
b） 供应商将根据7.4.3承担网络安全责任的期望；以及
c）与供应商报价的相关项或组件相关的网络安全目标和/或网络安全要求集。

7.2.3 责任对齐

【RQ-07-04】客户和供应商应在网络安全接口协议中规定分布式网络安全活动，包括：
a） 指定客户和供应商的网络安全联系人；
b） 确定客户和供应商分别开展的网络安全活动；
c） 如果适用，根据6.4.3对网络安全活动进行联合定制；
d） 共享的信息和工作成果；
e） 分布式网络安全活动的里程碑；以及
f）确定该相关项或组件的网络安全支持结束。

【RQ-07-05】在分布式网络安全活动开始之前，客户和供应商应共同商定网络安全接口协议。

【RQ-07-06】如果存在根据【RQ-08-07】进行管理的已识别漏洞，客户和供应商应就这些行为的行动和责任达成一致。

【RQ-07-07】如果要求不明确、不可行或与其他网络安全要求或其他学科的要求相冲突，则客户和供应商应各自通知对方，以便采取适当的决策和行动。

【RQ-07-08】应在责任分配矩阵中明确责任。

8 持续的网络安全活动

8.1 网络安全监控

8.1.1 输入

先决条件：
用于开发触发器的规则和流程；

进一步支持信息：
项目定义[WP-09-01]；
网络安全声明[WP-09-04]；
网络安全规范[WP-10-01]；
威胁情景[WP-15-03]；
过去的漏洞分析[WP-08-05]；
从现场收到的信息

8.1.2 需求和建议

【RQ-08-01】应选择来源收集网络安全信息。
–研究人员；
–商业或非商业来源；
–组织的供应链；
–组织的客户；和/或
–政府来源。

【RQ-08-02】应定义和维护触发器，以便对网络安全信息进行分类。
【RQ-08-03】应收集和分类网络安全信息，以确定网络安全信息是否成为一个或多个网络安全事件。

8.1.3 工作成果

【WP-08-01】网络安全信息来源，来源于【RQ-08-01】
【WP-08-02】触发器，由【RQ-08-02】产生
【WP-08-03】网络安全事件，由【RQ-08-03】产生

8.2 网络安全事件评估

8.2.1 输入

先决条件：
网络安全事件【WP-08-03】；
开发后的网络安全要求【WP-10-02】（如适用）；
符合【RQ-05-12】配置信息。

进一步支持信息：
项目定义【WP-09-01】；
网络安全规范【WP-10-01】；
过去的漏洞分析【WP-08-05】。

8.2.2 需求和建议

【RQ-08-04】应对网络安全事件进行评估，以识别相关项和/或组件中的弱点。

8.2.3 工作成果

[WP-08-04]网络安全事件的弱点，由[RQ-08-04]引起

8.3 漏洞分析

8.3.1 输入

先决条件：
项目定义【WP-09-01】或网络安全规范【WP-10-01】。

进一步支持信息：
网络安全事件的弱点【WP-08-04】；
产品开发过程中发现的弱点【WP-10-05】；
过去的漏洞分析【WP-08-05】；
攻击路径【WP-15-05】；
验证报告【WP-1-04】和【WP-1-07】；
过去网络安全事件的信息。

8.3.2 需求和建议

【RQ-08-05】应分析弱点以识别漏洞。
注1：分析可以包括：
–架构分析；
–根据15.6进行攻击路径分析；和/或
–根据15.7的攻击可行性评级。

【RQ-08-06】应为未被识别为漏洞的弱点提供理由。

8.3.3 工作成果

【WP-08-05】漏洞分析，由【RQ-08-05】和【RQ-08-06】得出

8.4 漏洞管理

8.4.1 输入

先决条件：
漏洞分析[WP-08-05]。

进一步支持信息：
无

8.4.2 需求和建议

【RQ-08-07】应对漏洞进行管理，以便针对每个漏洞：
a） 根据15.9评估和处理相应的网络安全风险，确保不存在不合理的风险；
b）通过应用独立于TARA的可用补救措施来消除漏洞。

【RQ-08-08】如果根据15.9的风险处理决定需要网络安全事件响应，则应适用13.3。

8.4.3 工作产品

【WP-08-06】管理漏洞的证据，由【RQ-08-07】产生

9 概念

9.1 相关项定义

9.1.1 输入

先决条件：
无

进一步支持信息：
有关相关项和操作环境的现有信息。

9.1.2 需求和建议

【RQ-09-01】应确定相关项的以下信息：
a) 相关项边界
b) 相关项功能
c) 初步架构
【RQ-09-02】应描述与网络安全相关的相关项的操作环境信息。

9.1.3 工作成果

【WP-09-01】项目定义，根据9.3.2的要求得出

9.2 网络安全目标

9.2.1 输入

先决条件：
项目定义【WP-09-01】。

进一步支持信息：
网络安全事件【WP-08-03】。

9.2.1 需求和建议

【RQ-09-03】应进行基于相关项定义的分析，包括：
a）根据15.3进行资产识别；
b）根据15.4进行威胁情景识别；
c）攻击等级符合15.5；
d）根据15.6进行攻击路径分析；
e）根据15.7的攻击可行性评级；
f）根据15.8确定风险值。

【RQ-09-04】根据[RQ-09-03]的结果，应根据15.9为每种威胁场景确定风险处理方案。

【RQ-09-05】如果威胁场景的风险处理决策包括降低风险，则应指定一个或多个相应的网络安全目标。

【RQ-09-06】如果威胁情景的风险处理决策包括：
a）分担风险；
b）由于【RQ-09-03】分析期间使用的一个或多个假设而保留风险，
则应指定一个或更多相应的网络安全声明。

【RQ-09-07】应进行验证以确认：
a）【RQ-09-03】关于相关项定义的结果的正确性和完整性；
b）【RQ-09-04】的风险处理决策与【RQ-09-03】的结果的完整性、正确性和一致性；
c）【RQ-09-05】网络安全目标的完整性、正确性和一致性，以及【RQ-09-06】网络安全声明与【RK-09-04】风险处理决策的一致性；以及
d）该项目【RQ-09-05】的所有网络安全目标和【RK-09-06】的网络安全声明的一致性。

9.2.3 工作成果

【WP-09-02】TARA，由【RQ-09-03】和【RQ-09-04】产生
【WP-09-03】网络安全目标，源自【RQ-09-05】
【WP-09-04】由【RQ-09-06】产生的网络安全声明

9.3 网络安全概念

9.3.1 输入

先决条件：
相关项定义【WP-09-01】；
网络安全目标【WP-09-03】；
网络安全声明【WP-09-04】；

进一步支持信息：
TATA 【WP-09-02】

9.3.1 需求和建议

【RQ-09-08】应描述实现网络安全目标的技术和/或操作网络安全控制及其相互作用，同时考虑到：
a） 相关项功能之间的依赖关系；和/或
b）网络安全声明。

【RQ-09-09】应根据【RQ-09-08】的描述，为网络安全目标定义相关项的网络安全要求和运行环境要求。

【RQ-09-10】网络安全要求应分配给该相关项，如果适用，还应分配给其一个或多个组件。

【RQ-09-11】应验证【RQ-09-08】、【RQ-09-09】和【RQ-09-10】的结果，以确认：
a）网络安全目标的完整性、正确性和一致性；
b）网络安全声明的一致性。

9.3.3 工作成果

【WP-09-06】网络安全概念，源于【RQ-09-08】、【RQ-09-09】和【RQ-09-10】
【WP-09-07】网络安全概念验证报告，由【RQ-09-11】产生

10 产品开发

10.1 输入

先决条件：
来自更高级的体系结构抽象层次的网络安全规范：
注 1： 这可能仅限于与正在开发的组件相关的信息， 例如。
— 分配给正在开发的组件的网络安全要求；
— 正在开发的组件的外部接口规范；
— 关于正在开发的组件的操作环境的信息。

进一步支持信息：
–相关项定义【WP-09-01】；
–网络安全概念【WP-09-06】；
–现有架构设计；
–已经建立的网络安全控制；
–重用组件的已知弱点和漏洞。

10.2 需求和建议

10.2.1 设计

【RQ-10-01】网络安全规范应基于以下内容进行定义：
a） 来自更高层次架构抽象的网络安全规范；
b） 选择实施网络安全控制措施（如适用）；
c） 现有架构设计（如适用）。

【RQ-10-02】定义的网络安全要求应分配给架构设计的各个组成部分。

【RQ-10-03】如果适用，应规定在组件开发后期确保网络安全的程序。

【RQ-10-04】如果设计、建模或编程符号或语言用于网络安全规范或其实现，在选择此类符号或语言时应考虑以下因素：
a） 在语法和语义上都有明确和可理解的定义；
b） 支持实现模块化、抽象和封装；
c） 支持使用结构化结构；
d） 支持使用安全的设计和实施技术；
e） 整合现有组件的能力；
f） 语言对因使用不当而造成的漏洞的弹性。

【RQ-10-05】设计、建模和编码指南或开发环境应涵盖语言本身未涉及的网络安全适当设计、建模或编程语言的标准（见[RQ-10-04]）。

【RQ-10-06】应采用既定和可信的设计和实施原则，以避免或尽量减少引入弱点。

【RQ-10-07】应分析【RQ-10-01】中定义的架构设计，以确定弱点。

【RQ-10-08】应验证定义的网络安全规范，以确保其完整性、正确性和与更高层次架构抽象的网络安全规格的一致性。
注10：验证方法可包括：
–审查；
–分析；
–仿真；和/或
–原型制作

10.2.2 集成和验证

【RQ-10-09】集成和验证活动应验证组件的实施和集成是否符合规定的网络安全规范。

【RQ-10-10】【RQ-10-09】的集成和验证活动应考虑以下因素：
a） 已定义的网络安全规范；
b） 用于批量生产的配置（如适用）；
c） 有足够的能力支持所定义的网络安全规范中规定的功能；
d）符合【RQ-10-05】的建模、设计和编码指南（如适用）。
注1：这可能包括车辆集成和验证。
注2：验证方法可能包括：
–基于需求的测试；
–接口测试；
–资源利用评价；
–控制流和数据流的验证；
–动态分析；和/或
–静态分析。

【RQ-10-11】若采用测试验证，则应使用定义的测试覆盖率指标来评估测试覆盖率，以确定测试活动的充分性。

【RQ-10-12】应进行测试，以确认组件中未识别的弱点和漏洞被最小化。

【RQ-10-13】如果未按照【RC-10-12】进行测试，则应提供理由。
注9：基本原理可能包括以下考虑因素：
–访问组件攻击面的可行性；
–（直接或间接）访问组件的能力，以及其他组件的妥协；和/或
–组件的简单性。

10.3 工作成果

【WP-10-01】网络安全规范，由【RK-10-01】和【RQ-10-02】产生
【WP-10-02】根据【RQ-10-03】制定的开发后期网络安全要求
【WP-10-03】由【RQ-10-04】和【RK-10-05】产生的建模、设计或编程语言和编码指南的文件（如适用）
【WP-10-04】网络安全规范验证报告，由【RQ-10-08】产生
【WP-10-05】产品开发过程中发现的缺陷，由【RQ-10-07】和【RC引起-10-12】，如适用
【WP-10-06】集成和验证规范，由【RQ-10-10】产生
【WP-10-07】集成和验证报告，由【RQ-10-09】、【RK-10-11】和【RC-10-12】得出

11 网络安全确认

11.1 输入

先决条件：
项目定义【WP-09-01】；
网络安全目标【WP-09-03】；和
网络安全声明【WP-09-04】（如适用）

进一步支持信息：
网络安全概念【WP-09-06】；
产品开发中的工作成果（见10.5）。

11.2 需求和建议

【RQ-11-01】考虑批量生产配置的相关项在车辆层面的验证活动应确认：
a） 网络安全目标在威胁情景和相应风险方面的充分性；
注1：如果在验证过程中发现了网络安全目标未解决的任何风险，则可以根据9.4解决。
b） 实现该相关项的网络安全目标；
c） 网络安全声明的有效性；以及
d）操作环境要求的有效性（如适用）。

【RQ-11-02】应提供选择验证活动的理由。

11.3 工作成果

【WP-11-01】验证报告，由【RQ-11-01】和【RQ-11-02】得出

12 生产

12.1 输入

先决条件：
开发后期的发布报告【WP-06-04】；和
开发后期的网络安全要求【WP-10-02】

进一步支持信息：
无

12.2 需求和建议

【RQ-12-01】应制定生产控制计划，将网络安全要求应用于后期开发。
注1：生产控制计划可以作为整体生产计划的一部分。

【RQ-12-02】生产控制计划应包括：
a） 将网络安全要求应用于后期开发的一系列步骤；
b） 生产工具和设备；
c） 网络安全控制，防止生产过程中未经授权的更改；以及
示例1 防止对保存软件的生产服务器进行物理访问的物理控制。
示例2 应用加密技术和/或访问控制的逻辑控制。
d） 确认满足后期开发网络安全要求的方法。
注2：方法可以包括检查和校准检查。

【RQ-12-03】应实施生产控制计划。

12.3 工作成果

【WP-12-01】生产控制计划，由【RQ-12-01]和【RQ-12-02】产生

13 运营和维护

13.1 网络安全事故响应

13.1.1 输入

先决条件：
无

进一步支持信息：
与导致网络安全事件响应的漏洞相关的网络安全信息；
漏洞分析【WP-08-05】

13.1.2 需求和建议

【RQ-13-01】对于每个网络安全事件，应制定网络安全事件响应计划，其中包括：
a） 补救措施；
注1：补救措施由8.6中的漏洞管理决定。
b） 沟通计划；
c） 为补救措施分配责任；
d） 记录与网络安全事件相关的新网络安全信息的程序；
e） 用于确定进度的方法；

【RQ-13-02】应实施网络安全事件响应计划。

13.1.3 工作成果

【WP-13-01】网络安全事件响应计划，由【RQ-13-01】产生

13.2 更新

13.2.1 输入

先决条件：
开发后期发布报告【WP-06-04】。

进一步支持信息：
网络安全事件响应计划【WP-13-01】；
与更新相关的开发后期网络安全要求【WP-10-02】。

13.2.2 需求和建议

【RQ-13-03】车辆内的更新和更新相关功能应按照本文件进行开发。

13.2.3 工作成果

无

14 网络安全支持的结束和停用

14.1 网络安全支持的结束

14.1.1 输入

先决条件：
无

进一步支持信息：
无

14.1.2 需求和建议

【RQ-14-01】当组织决定终止对某个相关项或组件的网络安全支持时，应制定一个程序与客户进行沟通。

14.1.3 工作成果

【WP-14-01】根据【RQ-14-01】传达网络安全支持结束的程序

14.2 停用

14.2.1 输入

先决条件：
开发后期的网络安全要求【WP-10-02】。

进一步支持信息：
无

14.2.2 需求和建议

【RQ-14-02】应提供退役后开发的网络安全要求。
注：与此类要求相关的适当文件（如说明、用户手册）可以实现网络安全方面的退役。

14.2.3 工作成果

无

15 威胁分析和风险评估方法

15.1 资产识别

15.1.1 输入

先决条件：
相关项定义【WP-09-01】

进一步支持信息：
网络安全规范【WP-10-01】。

15.1.2 需求和建议

【RQ-15-01】应识别损坏场景。
注1：损坏场景可能包括：
–项目功能与不良后果之间的关系；
–对道路使用者的危害描述；和/或
–相关资产。

【RQ-15-02】应识别具有网络安全属性的资产，其受影响会导致损坏场景。
资产的识别可以基于：
–分析相关项定义；
–执行影响评级；
–从威胁场景中提取资产；和/或
–使用预定义的目录。

15.1.3 工作成果

【WP-15-01】由【RK-15-01】产生的损害场景
【WP-15-02】由【RQ-15-02】产生的具有网络安全属性的资产

15.2 威胁场景识别

15.2.1 输入

先决条件：
相关项定义【WP-09-01】

进一步支持信息：
网络安全规范【WP-10-01】；
损坏场景【WP-15-01】；
具有网络安全属性的资产【WP-15-02】。

15.2.2 需求和建议

【RQ-15-03】应识别威胁场景，包括：
–目标资产；
–资产的网络安全属性受损；和
–网络安全属性受损的原因

15.2.3 工作成果

【WP-15-03】由【RQ-15-03】产生的威胁情境

15.3 影响评级

15.3.1 输入

先决条件：
损坏场景【WP-15-01】。

进一步支持信息：
相关项定义【WP-09-01】
具有网络安全属性的资产【WP-15-02】。

15.3.2 需求和建议

【RQ-15-04】
【RQ-15-05】
【RQ-15-06】
【RQ-15-07】

15.3.3 工作成果

【WP-15-04】影响评级及相关影响类别，由【RQ-15-04】到【RQ-15-06】产生

15.4 攻击路径分析

15.4.1 输入

先决条件：
相关项定义【WP-09-01】或网络安全规范【WP-10-01】；
威胁场景【WP-15-03】。

进一步支持信息：
网络安全事件的弱点【WP-08-04】；
产品开发过程中发现的弱点【WP-10-05】；
架构设计；
先前识别的攻击路径【WP-15-05】（如果可用）；
漏洞分析【WP-08-05】。

15.4.2 需求和建议

【RQ-15-08】应对威胁场景进行分析，以确定攻击路径。

【RQ-15-09】攻击路径应与攻击路径可以实现的威胁场景相关联。

15.4.3 工作成果

【WP-15-05】攻击路径，由【RQ-15-08】和【RQ-15-09】产生

15.5 攻击可行性分析

15.5.1 输入

先决条件：
攻击路径【WP-15-05】。

进一步支持信息：
架构设计；
漏洞分析【WP-08-05】

15.5.2 需求和建议

【RQ-15-10】对于每条攻击路径，应按照表1所述确定攻击可行性评级。

【RC-15-11】攻击可行性评级方法应基于以下方法之一进行定义：
a） 基于攻击潜力的方法；
b） 基于CVSS的方法；
c）基于攻击向量的方法。

【RC-15-12】如果使用基于攻击潜力的方法，则应根据以下核心因素确定攻击可行性评级：
a） 经过的时间；
b） 专业知识；
c） 对物品或组件的了解；
d） 机会之窗；
e）设备。

【RC-15-13】如果使用基于CVSS的方法，则应根据基本指标组的可利用性指标来确定攻击可行性评级，包括：
a） 攻击向量；
b） 攻击复杂性；
c） 所需特权；以及
d）用户交互。

【RC-15-14】如果使用基于攻击向量的方法，则应根据评估攻击路径的主要攻击向量（参见CVSS[24]2.1.1）来确定攻击可行性评级。

15.5.3 工作成果

【WP-15-06】攻击可行性评级，由【RQ-15-10】得出

15.6 风险值确定

15.6.1 输入

先决条件：
威胁情景【WP-15-03】；
具有相关影响类别的影响评级【WP-15-04】；和
攻击可行性评级【WP-15-06】。

进一步支持信息：
无

15.6.2 需求和建议

【RQ-15-15】对于每种威胁场景，风险值应根据相关损害场景的影响和相关攻击路径的攻击可行性来确定。

【RQ-15-16】威胁场景的风险值应在1到5之间（包括1和5），其中1表示最小风险。

15.6.3 工作成果

【WP-15-07】由【RQ-15-15】和【RQ-15-16】得出的风险值

15.7 风险处理决策

15.7.1 输入

先决条件：
相关项定义【WP-09-01】；
威胁场景【WP-15-03】;
风险值【WP-17-07】。

进一步支持信息：
网络安全规范【WP-10-01】；
先前相关项或组件或类似相关项或组件的风险处理决策；
具有相关影响类别的影响评级【WP-15-04】；
攻击路径【WP-15-05】；
攻击可行性评级【WP-15-06】。

15.7.2 需求和建议

【RQ-15-17】对于每种威胁场景，考虑其风险值，应确定以下一个或多个风险处理选项：
a） 规避风险；
示例1：通过消除风险源、决定不开始或继续导致风险的活动来避免风险。
b） 降低风险；
c） 分担风险；
示例2：通过合同分担风险或通过购买保险转移风险。
d） 保留风险。

15.7.3 工作成果

【WP-15-08】【RQ-15-17】产生的风险处理决策