汽车网络信息安全-ISO/SAE 21434解析（中）

第七章-分布式网络安全活动

第7章规定了分布式开发中的网络安全活动，可以理解为在网络安全角度如何进行供应商管理。21434是一份面对整个汽车行业的指导标准，因此对供应商管理要求的适用范围不仅限于OEM，同时也适用于Tier 1, Tier 2等供应链上各环节的企业和组织，此外，组织的内部供应商也需要遵循本章要求。在21434中，分布式的网络安全活动主要有3项：

供应商能力评估
报价
网络安全职责界定

1. 供应商能力评估

此评估支持供应商选择，可以基于供应商符合本标准的能力，也可以基于对先前实施的有关网络安全工程的另一个国家或国际标准的评估。

网络安全能力的记录可以包括：
—   组织有关网络安全能力的证据（例如：来自开发、开发后、治理、质量和信息安全的网络安全最佳实践）。
—   持续的网络安全活动（见第8章）和网络安全事件响应（见第13章）的证据；以及
—   以前的网络安全评估的摘要

2. 报价

顾客向候选供应商提出的报价要求应包括：
a) 符合本标准的正式要求。
b) 供应商根据7.4.3章节的规定所承担的网络安全责任的预期；以及
c) 与该供应商报价的项目或部件有关的网络安全目标和/或网络安全要求集。

3. 网络安全职责界定

客户和供应商应在网络安全接口协议（CIA Cybersecurity Interface Agreement）中规定分布式网络安全活动，包括：
a) 指定客户和供应商关于网络安全的联络点。
b) 确定由客户和供应商分别开展的网络安全活动。
c) 如果适用，按照6.4.3的规定，共同定制网络安全活动。
d) 要共享的信息和工作产品。
e) 关于分布式网络安全活动的里程碑；以及
f) 对该项目或组件的网络安全支持结束的定义。

第八章-持续的网络安全活动

第8章主要描述持续的网络安全活动。车辆网络安全工程是一项贯穿产品全生命周期的持续性的活动，OEM不仅要进行TARA分析、安全概念设计、网络安全开发测试和生产，还要在项目的全生命周期中，持续地收集和监控与项目有关的网络安全信息，建立信息监控和漏洞管理机制，持续地保证产品的网络安全。新漏洞的发现、网络安全突发事件的发生、新攻击技术的出现等都有可能触发相应的网络安全工作。

本章节中描述了4项需要持续进行的网络安全活动：

1. 网路安全监控

2. 网络安全事件评估

3. 漏洞分析

4. 漏洞管理

1. 网路安全监控

网络安全信息的收集

外部的信息：政府，研究机构，盈利或非盈利组织，供应商，客户

内部信息：售后field，使用现场，FFA（Field failure analysis），

收集网络安全信息并进行分类，以确定该网络安全信息是否成为一个或多个网络安全事件event。

1. 信息的来源是否可靠

2. 威胁是新的还是再发生

3. 威胁会导致风险的提高或降级

4. 有没有触发阈值：影响车辆的范围，损害影响的程度，触发的话就会升级

没有风险的信息就会被筛选掉，不需要关注

有风险的信息就是event事态：当Event被利用，确实发生了，就是事件incident

2. 网络安全事件评估

评估网络安全事态event，以确定一个功能项和/或组件的弱点weakness。

Weak是事态event的根本原因，root cause

3. 漏洞分析

对弱点进行分析，以确定漏洞，弱点如若被利用，就成为漏洞。

注释：该分析可以包括：
—   架构的分析；
—   根据15.6规定的攻击路径分析；和/或
—   根据15.7的攻击可行性评级

示例1：攻击路径分析显示不存在攻击路径，因此该弱点不被视为漏洞。
示例2：攻击可行性评级对于利用该弱点来说非常低，因此该弱点不被作为漏洞处理。

4. 漏洞管理

漏洞的管理应做到对每个漏洞：
a) 对相应的网络安全风险进行评估，并按照15.9章节的规定进行处理，使之不存在不合理的风险；或
b) 通过应用独立于 TARA 的可用补救措施消除该漏洞。

漏洞分析，漏洞管理之后，就会涉及到安全事件incident的响应（客户投诉也会触发事件的响应，13.3章中有描述）

第九章-概念阶段

从第9章至第14章，21434描述了车辆从概念设计到退役的全生命周期各阶段的网络安全要求。

第9章概念阶段（Concept phase）的主要工作是定义网络安全对象，并通过TARA分析，确定网络安全目标，产生相应的网络安全概念。接下来将对这3个环节进行详细的描述。

1. 对象定义

应识别功能项的以下信息：
a) 功能项边界；
b) 功能；和
c) 初步架构。

应描述功能项运行环境中关于网络安全的相关信息。

注释:

对运行环境及其与功能项的相互作用的描述，可以识别和/或分析相关的威胁场景和攻击路径。
相关信息可以包括假设，例如，假设该功能项所依赖的每一个公钥基础设施证书机构都得到了适当的管理。

2. 网路安全目标

应在功能项定义的基础上进行分析，其中包括：
a) 根据15.3章节的规定进行资产识别；
b) 按照15.4章节的规定进行威胁场景识别；
c) 按照15.5章节的规定进行影响评级；
d) 按照15.6章节的规定进行攻击路径分析；
e) 根据15.7章节的规定，对攻击的可行性进行评级；以及
f) 按照15.8章节的规定确定风险值。

根据分析的结果，应按照15.9的规定为每种威胁场景确定风险处理方案。

如果一个威胁场景的风险处理决定包括减少风险，那么应规定一个或多个相应的网络安全目标。

如果对某一威胁场景的风险处理决定包括：
a) 分享或转移风险；或
b) 由于分析过程中使用的一个或多个假设而保留风险，则应规定一个或多个相应的网络安全声明。

3. 网络安全概念

在描述技术和/或操作性网络安全控制及其相互作用以实现网络安全目标时，应考虑到：
a) 功能项的功能之间的依赖性；和/或
b) 网络安全声明。

输入时Tara报告：包括网络安全目标和申明

Verification report：验证网络安全概念，

一致性：跟网络安全目标的一致性，概念大于等于目标

Cybersecurtiy Goal, Concept, Specification的区别

1. Cybersecurity Properties：C.I.A.

2. Cybersecurity Goals: 举例：保护个人隐私数据的机密性

3. Cybersecurity Concept: 举例：需要把个人数据进行加密

4. Cybersecurity Specification：举例：个人数据用AES128进行加密

第十章 - 产品开发

在上一章中，通过对相关项的TARA分析，已经得出了针对高风险项的网络安全要求（网络安全概念），在产品开发阶段，应根据网络安全概念，制定详细的网络安全技术规范，并将需求逐层分解到下游的子系统、零部件层，完成相应的架构设计和详细设计。在V模型右端，进行集成和符合性测试，以保证相关的组件、系统符合V模型左端对应的网络安全设计规范。

第十一章 - 网络安全确认

第11章节的题目是“Cybersecurity Validation", 可译为”网络安全确认“。这里的Validation需要与上一章节产品开发中的Verification进行一下区分。"Verification"我们通常理解为是否“do the things right“，即验证开发是否满足设计阶段的规范和要求，对象通常是零件或子系统。而本章节的”Validation“则是验证是否”do the right things“，即所开发的产品是否满足网络安全的目标，更直白的讲，是验证车辆是否安全。在该阶段，确认活动的对象是整车，并且是符合量产状态的整车。

在车辆层面的验证活动，对于考虑批量生产的配置的功能项，应确认：
a) 网络安全目标在威胁场景和相应风险方面的充分性。
b) 功能项的网络安全目标的实现。
c) 网络安全要求的有效性；以及
d) 对运行环境的要求的有效性（如果适用）。