智能驾驶系统：数据和网络融合安全规范

文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改

发文件起草分工： 1.

编制：	签名： 日期：
审核：	签名： 日期：
批准：	签名： 日期：

所有权声明

该文档及其所含的信息是财产。该文档及其所含信息的复制、使用及披露必须得到的书面授权。

1 前言

1.1 目的

确定数据和网络安全的设计要求，包括防范潜在威胁、提高系统的安全性、降低安全风险等，以指导后续的开发、实施和运维工作。

1.2 规范内容

本规范规定了信息安全管理体系要求、信息安全基本要求、信息安全技术要求及相应的检查与试验方法等内容 。

1.3 版本和变更

本规范的版本变更说明 如表 1 所示。

表 1  更改历史

版本	更改描述	更改日期	更改人
1.0
1.1
1.2

2. 规范性引用文件

下列文档中的条款通过本标准的引用成为本标准的条款。凡是注日期的引用文档，其随后的修改单（不包含勘误的内容）或修订版均不适用于本标准。凡是不注日期的引用文档，其最新版本适用于本标准。

2.1 国际标准和技术规范

本规范参考的国际标准和技术规范如表 2 所示。

表 2  规范性引用文件

编号	文档
Ref [1]	UL 4600: UL Standard for Safety for Evaluation of Autonomous Products
Ref [2]	ISO 26262-1: Road vehicles- Functional safety- Part 1: Vocabulary
Ref [3]	ISO 26262-2: Road vehicles- Functional safety- Part 2: Management of functional safety
Ref [4]	ISO 26262-3: Road vehicles- Functional safety- Part 3: Concept phase
Ref [5]	ISO 26262-4: Road vehicles- Functional safety- Part 4: Product development at the system level
Ref [6]	ISO 26262-6: Road vehicles- Functional safety- Part 6: Product development at the software level
Ref [7]	ISO 21448: Road vehicles- Safety of the intended functionality
Ref [8]	ISO/SAE 21434 ： Setting the Standard for Connected Car’s Cybersecurity

2.2 国内标准和技术规范

本规范参考的国内标准和技术规范如表 3 所示。

表 3  规范性引用文件

编号	文档
Ref [1]	GB/T 34590.1: 道路车辆 功能安全 第 1 部分：术语
Ref [2]	GB/T 34590.2: 道路车辆 功能安全 第 2 部分：功能安全管理
Ref [3]	GB/T 34590.3: 道路车辆 功能安全 第 3 部分：概念阶段
Ref [4]	GB/T 34590.4: 道路车辆 功能安全 第 4 部分：产品开发：系统层面
Ref [5]	GB/T 34590.6: 道路车辆 功能安全 第 6 部分：产品开发：软件层面
Ref [6]	GB/T 43267: 道路车辆 预期功能安全
Ref [7]	GB/T 44495: 汽车整车信息安全技术要求

3 术语缩写与定义

3.1 缩写

表 4 列出了本规范中专有名词的英文全称及相应的中文。

表 4   缩写

缩写	含义
AI	Artificial Intelligence( 人工智能 )
CAN	Controller Area Network( 控制器局域网络 )
E/E	Electrical and/or Electronic system( 电气和电子 )
HSM	Hardware Security Module( 硬件安全模块 )
NFC	Near Field Communications( 近场通信 )
OBD	On-Board Diagnostics( 车载诊断器 )
RASIC	Responsible( 责任 ) 、 Accountable ( 批准 ) 、 Supporting( 支持 ) 、 Informed ( 知情 ) 、 Consulted ( 咨询 )
RFID	Radio Frequency Identification( 射频识别 )
USB	Universal Serial Bus( 通用串行总线 )
VLAN	Virtual Local Area Network( 虚拟局域网 )
VIN	Vehicle Identification Number( 车辆识别代号 )
ISO	International Standards Organization （国际标准组织）
V2X	Vehicle to everything( 车辆与车外其他设备之间的无线通信 )
WLAN	Wireless Local Area Networks( 无线局域网 )

3.2 术语和定义

资产

由本规范相关要求得出的文档。具有价值或对价值有贡献的物体。

攻击可行性

由本规范相关要求得出的文档。具有价值或对价值有贡献的物体。

攻击路径

实现威胁场景的蓄意行动集。

组件

逻辑上和技术上可分离的组成部分。

消费者

接受服务或产品的客户、个人或组织。

网络安全

网络安全道路车辆网络安全状态，在该状态下，资产受到充分的保护，免受道路车辆项目、其功能及其电气或电子部件的威胁场景。

网络安全评估

网络安全评估—网络安全判断。

网络安全案例

网络安全案例结构化论证，有证据证明风险并非不合理。

网络安全声明

关于风险的网络安全索赔声明。

网络安全控制

修改风险的网络安全控制措施。

网络安全事件

与项目或部件有关的网络安全信息。

网络安全目标

与一个或多个威胁情景相关的概念级网络安全要求。

网络安全信息

与网络安全有关的信息。

网络安全接口协议

客户和供应商之间关于分布式网络安全活动的协议。

网络安全规范

网络安全要求和相应的架构设计。

分布式网络安全活动

项目或部件的网络安全活动，其责任在客户和供应商之间分配。

影响

对损害情况下的损害或身体伤害程度的估计。

项目

在车辆层面实现一个功能的组件或组件集。

风险

网络安全风险。不确定性对道路车辆网络安全的影响，以攻击可行性和影响表示。

风险管理

在风险方面指导和控制组织的协调活动。

道路使用者

使用道路的人。

裁剪

以与本文件描述不同的方式省略或执行某项活动。

威胁情况

一个或多个资产的网络安全属性受到损害的潜在原因，以实现损害情况。

分流

分析以确定网络安全信息与某一项目的相关性，或组成部分。

触发器

分流的标准。

验证

分流的标准。通过提供客观证据，确认具有合乎需要可实现的项目的网络安全目标。

脆弱性

可作为攻击路径的一部分被利用的弱点。

脆弱性分析

系统地识别和评估脆弱性。

弱点

可导致不良行为地缺陷或特征。

证据

用于支持参数的数据或其他信息

故障模型

执行故障分析时要考虑的所有故障的规范

事件

发生可能导致损失事件的安全相关故障

减轻

降低到可接受的风险水平

车辆信息安全

汽车的电子电气系统、组件和功能被保护，使其资产不受威胁的状态。

风险评估

发现、识别和描述风险，理解风险的性质以及确定风险级别，并将风险分析的结果与风险标准进行比较，以确定风险是否可接受的过程。

威胁

可能导致系统、组织或个人受到损害的意外事件的潜在原因。

漏洞

在资产或缓解措施中，可被一个或多个威胁利用的弱点。

车载软件升级系统

安装在车端并具备直接接收、分发和校验来自车外的升级包等用于实现软件升级功能的软件和硬件。

在线升级

通过无线方式而不是使用电缆或其他本地连接方式将升级包传输到车辆的软件升级。

离线升级

除在线升级以外的软件升级。

敏感个人信息

一旦泄露或者非法使用，可能导致车主、驾驶人、乘车人、车外人员等受到歧视或者人身、财产安全受到严重危害的个人信息。

3.3 约定术语

本文档中使用了下列术语：

• “ 强制性”：表示不允许出现安全案例偏差

• “ 需要”：表示仅当通过提示证明提示元素与项目和 / 或其安全案例本质上不兼容时，才允许发生安全案例偏离。

• “ 强烈推荐”：表示是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。

• “ 推荐”：表示这些是可选的提示元素，记录了良好做法和 / 或有用技术的建议。

4 数据和网络融合安全概述和组织

4.1 概述

本规范的目的是：

a) 定义数据和网络安全总体要求；

b) 定义通信与数据故障模型范围；

c) 规定网络安全管理组织规则和程序，实施网络安全的管理系统，并根据本文件的目标进行审计；

d) 定义关于特定项目的网络安全开发活动管理要求；

e) 定义客户和供应商之间分布式网络安全活动的互动、依赖和责任；

f) 定义在生命周期所有阶段进行的持续网络安全活动；

g) 定义网络安全要求及对应的检查与试验方法。

4.2 总则

如图 4.1 所示，本规范为自动驾驶系统数据和网络安全列出的要求和建议，规范内容包括数据与网络安全总体要求、通信与数据故障模型、组织网络安全管理、依靠项目的网络安全管理、分布式网络安全活动、持续的网络安全活动、信息安全要求、检查与试验方法等。

图 4.1  本规范整体架构

4.3 数据和网络融合安全原理

如图 4.2 所示，为数据和网络融合安全原理。数据与网络安全总体要求及通讯与数据故障模型对数据与网络安全开发活动提出总体要求，信息安全基本要求提出数据与网络安全开发活动的管理要求，信息安全技术要求为数据与网络安全需满足的技术要求，检查与试验方法对信息安全基本要求和信息安全技术要求进行检查和试验。

图 4.2  数据和网络融合安全原理

5 数据与网络安全总体要求

5.1 概述

5.1.1 与数据存储，数据处理和数据传输有关的风险应被可接受地减轻。

a) 数据通信和网络 ( 请参阅第 5.2 节 )

b) 数据存储 ( 请参阅第 5.3 节 )

c) 运营基础架构支持 ( 请参阅第 5.4 节 )

d) 网络安全 ( 请参阅 5.5 节 )

图 5.1  数据和网络安全整体框架

5.2 数据通讯和网络

5.2.1 应减轻与数据传输有关的物品危害和风险。

a) 识别与数据传输相关的危害

b) 减轻数据传输对风险的影响

c) 以安全可靠的方式对软件，固件，配置数据和其他与安全相关的数据进行远程更新

d) 符合《远程软件更新安全标准》 , UL5500 或同等标准

5.2.2 与项目有关的数据流应被识别。

a) 识别与安全相关的数据流 ( 如果没有，请声明 )

注： 识别范围请见以下内容

b) 标识是否存在该项目的通信数据流 ( 无论是否对安全性至关重要 ), 包括：

1) 有线网络

示例： 运行以太网， CAN ， FlexRay ， MOST 协议的有线网络

2) 通信链接包括但不限于：串行总线，多路复用布线链接，专用串行传输链接

示例： RS-232 ， RS-485 ， SPI ， I2C ， LIN

3) 无线电通讯

示例： V2x ， WiFi ，蓝牙， 3G ， 4G ， 5G ，其他移动通信，密钥卡数据链接，胎压监测项目

4) 非无线电无线通信

示例： IrDA

5) 人机界面

示例： 屏幕，键盘，驾驶控制

6) 其他传感器用于接收编码数据值的作用

示例： 视频传感器，用于接收编码为条形码的数据

7) 设备的其他外部接口

示例： 服务工具接口，智能卡接口，拨号连接， SMS 数据包接口， OBD-II

注： 上面的提示元素重叠，并且覆盖了物理媒体和协议。精确的分类将取决于子域通用术语。每个数据流仅需包含在一个类别中。

c) 对于每个标识的接口 ( 包括必需接口和任何标识的高度推荐接口 ), 请描述：

1) 直接连接的组件，功能，参与者等。

i) 交流参与者管理方法

ii) 说明是否不一定知道交流参与者的完整列表

示例： 发送或接收的广播无线电信号可能没有定义网络参与者列表

2) 在数据流上发送或接收的与安全相关的数据 ( 如果有 ) 。

3) 与安全相关的功能，直接或间接消耗数据流的任何方面

注： 如果某个功能使用基于通过通信通道接收的数据的计算结果，则可以间接使用数据。实际上，这可能需要一种至少具有非恶意故障模型的污点分析，以确保针 对安全相关功能考虑通信故障和故障的影响。

示例： 假设的间接故障情况： 一天中的时间通过 GNSS 接收，并输入到与安全无关的软件服务中。但是，异常的时间值会导致挂起与安全性无关的服务。安全相关功能调用该服务以检索时间值，但是挂起以等待响应，从而导致安全相关功能失败。

d) 标识该项目是否存在以下任何类型的通信数据流，无论是否被视为安全关键，并标识被认为是安全关键的：

1) 远程访问设备

示例： 无钥匙进入，防盗设备，遥控设备

2) 充电基础设施连接

3) 存储访问端口

示例： USB 接口， SD 卡接口

4) 触点闭合

示例： 触点闭合接口线，开关，按钮，拨盘，钥匙开关，跳线

5) 模拟数据输入

示例： 电位计，模拟接口线

6) 设备的其他内部接口

示例： TPM 接口，子板， JTAG 接口

7) 与信息娱乐和互联网服务设备的连接

8) 远程更新

示例： 软件，数据，配置

9) 实时任务相关数据流

示例： 地图数据，交通数据

10) 与第三方设备的连接

示例： 使用手机和电脑

11) 其他通讯

示例： 反射内存，共享总线的内存总线，处理器间通信总线，双端口内存

12) 配置界面

示例： 跳线板

13) 远程操作，包括驾驶命令和 / 或远程监控功能 ( 如果有 )

e) 识别与安全相关的出站数据流

示例： 紧急车辆出站交通信号控制超控设备，出站安全相关的 V2X 信号

5.2.3 安全案例应确定应用于已识别数据流的风险缓解机制和技术。

a) 为响应第 5.2.2 节而标识的每个数据流指定 ：

1) 与每个数据流相关的故障模型 ( 请参见第 6 章 ，其中讨论了通信故障模型 )

2) 数据流的安全重要性

3) 每个数据流越过的故障遏制区域边界

4) 故障和失败缓解方法的有效性的描述和分析

b) 数据完整性方法，带有所使用的特定完整性功能的描述。

示例： 奇偶校验，校验和， CRC ，密码完整性功能，冗余传输

c) 数据记录

d) 跨度数据完整性方法

示例： 逐跳，通信链路上的端到端，预先计算的完整性检查值

e) 数据认证方式

示例： 不安全的哈希 ( 例如 CRC) ，安全的哈希，数字签名

f) 时序和顺序保证

示例： 随机数，序列号，时间戳

g) 根据安全计划的数据保密方法

示例： 加密，包括使用的特定算法

h) 数据流之间的冲突解决

示例： 不同的子系统为执行器生成不同的指令位置。远程遥操作控制命令与本地自治控制命令冲突

i) 异常数据检测和报告

j) 协议版本

示例： 协议版本作为消息的一部分发送

5.2.4 风险缓解应解决与每个已识别数据流相关的危害。

a) 说明每个已识别数据流所需的缓解风险的方法以及缓解风险的方法。

b) 对于在项目的较低完整性部分和较高完整性部分之间交叉的每个数据流，主张：

1) 来自较低完整性部分的数据故障，将来自项目较低完整性部分的故障模型与较高完整性部分的故障模型的联合应用到此分析中，不会损害安全相关功能的操作。

2) 安全相关功能的输入不能以不安全的方式被项目的较低完整性部分所破坏。

3) 安全相关功能的输出不会因项目的完整性较低而以不安全的方式受到损害。

4) 考虑外部项目接口等效于项目的较低完整性部分。

示例： 安全相关项目功能和外部蓝牙设备之间的接口可能会将蓝牙通道视为该项目的较低完整性部分。如果争论说蓝牙通道实际上是高完整性的，则必须沿该通道扩展论点，直到最终到达较低的完整性边界为止，就像该扩展路径是该物品的一部分一样。

5) 外部传感器被认为是完整性较低的现实世界的接口。

c) V2X 安全

1) 车辆安全取决于 V2X 通信的程度

2)V2X 数据的及时性，完整性，准确性，可用性

d) GNSS 安全

1) 车辆安全取决于 GNSS 位置数据，时间或其他因素的程度

2) 由潜在的 GNSS 欺骗，退化和中断引起的危害

e) 与安全无关的组件和外部接口引起的时序，网络负载和其他非数据值故障

f) 在安全计划规定的范围内，对内部和外部数据连接进行恶意攻击

5.2.5 应减轻与使用远程操作员数据连接性有关的风险。

a) 标识远程操作员的角色，至少包括该项目支持的以下哪个角色：

1) 连续遥控操作 ( 即远程控制 )

2) 远程接管以响应自动警报

3) 自主模式下的远程连续监控

4) 远程监控以响应自动警报

5) 远程接管以应对持续的监督

6) 响应于计划的 ODD 离开而进行的远程操作 ( 远程控制 )

7) 响应意外的 ODD 离开而进行的远程操作 ( 远程控制 )

8) 响应自治失败的远程操作 ( 远程控制 )

9) 车辆重新定位的命令界面

示例： 维护操作，运输装载 / 卸载功能以及使用手动控制器在人工控制下重新放置车辆的操作

b) 认证远程操作员 / 主管与项目交互的权限

c) 可能会延长时间，导致失去连接性，包括相关故障和同时发生的故障。

d) 如果与安全有关，则在任务期间无法进行按需连接的连接

e) 提供给基础架构的远程控制接口的完整性

示例： 外部实施限速措施

f) 提供给执法部门的远程控制界面的完整性

示例： 目的地变更，“杀死开关”

g) 数据速率下降，拥塞或其他无法满足带宽或延迟要求的条件

h) 远程操作 / 监控软件和基础架构的完整性

i) 根据安全计划的恶意攻击

示例： 欺骗，中继攻击，拒绝服务

5.3 数据存储

5.3.1 必须确定与安全相关的数据存储。

a) 识别数据存储设备和安全相关的数据功能

b) 考虑数据的类型和位置

1) 车载固定存储设备

示例： 硬盘，固态存储等

2) 可移动存储设备

示例： SD 卡，闪存驱动器等

3) 远程存储设备

示例： 云存储，网络连接的存储设备

4) 工程数据存储位置和档案

c) 与安全相关的数据：

1) 程序指令 ( 包括引导加载程序，驱动程序和应用程序代码 )

2) 非易失性数据

3) 易失数据

4) 软件映像的配置和校准数据

5) 机器学习相关数据和配置信息

6) 车辆设备配置和状态数据

7) 车辆现场工程反馈数据

8) 工程设计数据存储库

9) 故障，失效，事件，事故的数据记录

10) 软件映像更新数据

示例： 后期制作更新，出厂配置重置数据

11) 可崩溃的事件记录器

d) 其他数据日志

e) 与减轻数据存储风险相关的数据相关的其他位置 ( 第 5.3.2 节 ) 。

5.3.2 应减轻与数据存储和数据处理有关的风险。

a) 与确定的数据存储位置有关的风险

b) 与已识别的数据存储位置有关的数据处理

c) 用于工程设计活动的数据

d) 设计过程中使用的培训数据和其他收集的数据

e) 设计验证数据

示例： 测试仪，车辆性能数据

f) 用于制造和现场服务活动的数据，至少包括以下内容：

1) 项目软件图像完整性

2) 项目软件更新完整性和新鲜度

3) 维护数据的完整性，完整性和新鲜度 ( 过程，要求，车辆状态 )

g) 制造和生产数据存储

1) 工程数据仓库

2) 制造数据存储库

3) 配置管理数据存储库

h) 更新数据存储

1) 制造商与车辆之间的数据存储和运输

2) 中间数据存储 ( 如果使用 )

示例： 本地经销商服务器，服务工具存储

i) 营运数据

1) 地图数据

i) 准确性

ii) 确定的功能

iii) 到期日期 / 时间

2) 天气数据和其他环境数据

3) 与任务有关的数据

示例： 地图路线

4) 远程存储的车辆数据

示例： 配置数据，操作历史记录，维护历史记录

5) 车辆状态数据

j) 碰撞后和事件相关的记录数据

k) 数据可靠性和新鲜度

1) 云数据

2) 基础设施数据

3)V2X 数据

4) 地图数据

5) 导航

6) 车辆姿势

7) 奇数变更和违规

8) 天气预报和其他环境因素

l) 响应此条款而确定的数据的真实性

m) 用于现场工程反馈的数据的完整性和真实性

1) 技术有效性和数据来源

2) 支持可接受的明确根本原因分析

n) 用于事故和事故征候分析的数据的法证有效性

1) 监管链

2) 篡改证据

3) 无法缓解的故障源可能会破坏数据

4) 适用于保险理赔和风险评估

5.4 基础设施支持

5.4.1 应确定基础设施的假设，依赖性和危害范围。

a) 确定有关 ODD 范围的基础架构假设和依赖性

注意： 这导致考虑了此子句中列出的项目在 ODD 内， ODD 之外， ODD 内的程度 ( 仅在某些有限条件下 ), 或要求该项目出现在其 ODD 内的程度。

b) 行驶表面设计约束

示例： 假设在坡度，曲率，摩擦系数，着色 ( 包括道路，路缘石和人行道的相关方面 ) 方面受到限制；

1) 行驶表面设计约束 道路平整度，包括坑洼，人行道隆起

2) 行驶表面设计约束 人行道变化减速带或其他交通平缓机制的限制

3) 行驶表面设计约束 飞机降落表面

c) 基础架构假设和依赖性

示例： 假设使用反射性道路条纹而不是油漆，假设 GNSS 精度，所需标记的位置精度

d) 可直接或间接依赖于该数据的项目中的危害和功能 / 组件的可追溯性

示例： 道路标记直接用于本地化模块，间接用于计划模块，用于详细的定位信息。

e)  导航基础设施

示例： GNSS, 差分 GPS 信号，正式指定的导航工具 ( 例如标记，路标，基准标记 ), 路标，地标

f)  标牌及其他与安全有关的信息设备

示例： 交通法规标牌，高速公路出口信息等信息标牌

g) 增强了与人类兼容的基础架构

示例： 机器可读的二维条形码叠加在标志上

h) 基础设施标志

示例： 边界标记，行车道标记，磁性标记，油漆，人行横道条纹，其他表面和环境标记材料，颜色和纹理

i)  缓解危险路况

示例： 闲置建筑区域的露天建筑坑，金属板覆盖物的标记

j)  特殊路况

示例： 非信号单车道双向桥的标记，低净空地下通道的标记，包括车库净空

e) 发射器

示例： 灯，无线电信标

l) 被动标记

示例： 拐角反射器，光学行驶边界标记，涂漆的识别信息 ( 例如，涂在行驶表面上的数字 ), 码头编号

m) 已找到使用的项目基础结构特征，但不一定受任何基础结构控制

示例： 门牌号，商业标牌，围栏，绿化特征的导航使用

n) 手动信号，包括手势

1) 施工区

2) 警察活动

3) 第一响应者活动

4) 学校穿越

5) 临时交通管制

示例： 平民协助的卡车机动，在事故现场的热心人交通管理

o) 特殊车辆信号

1) 校车

2) 应急车辆的产量

3) 符合警戒信号

4) 铁路平交道口 ( 信号化和非信号化 )

p) 其他路况

1) 表面摩擦系数的提高

示例： 通过道路处理，路面铣刨得到改善

2) 最高等级，外倾

3) 新鲜路面

示例： 石油和木屑的最新应用，用低于正常规格的临时道路标记代替

4) 冬季路况

示例： 雪，冰，飘雪，盐 / 砂道路处理，先前交通造成的雪 / 冰层变化

5) 扫雪机互动

6) 周围冒烟，着火，大雾

q) 不寻常的路况

1) 金属桥梁组件或路面

示例： 桥缝，钢格板桥面

2) 动态道路特征

示例： 坡道障碍，吊桥，活动车道障碍

3) 木制巷道和桥梁组件

4) 路面不平整

示例： 一车道土路过度弯度，翻修施工区铣刨路面边界

5) 乘员和货物装载区配置

6) 其他基础设施要求

r) 基础架构的其他相关方面，例如：

1) 停车场和车库

2) 充电站 / 加油站

3) 越野和临时停车场

示例： 节日期间在干草场停车

5.4.2 已确定的与基础设施灾害相关的风险应予减轻

a)  根据已确定的基础设施故障模型，识别与基础设施相关的危害

b)  对于每个确定的对风险或危害的贡献，确定风险缓解策略

注： 对于低风险项目，风险缓解策略可能是“接受”的

c)  对于每种风险缓解策略，都认为可以实现可接受的风险缓解

d)  包括减轻由于基础架构不满足假设和 / 或要求而导致的风险。

5.5 网络安全

5.5.1 应减轻与网络安全相关的危害和风险。

a)  参考网络安全计划

b)  识别与网络安全相关的危害和风险，包括以下主题：

1)  保密性

2)  完整性

3)  可用性

c)  网络安全计划涵盖与安全相关的威胁和风险

示例： 威胁分析和风险评估（ TARA ）包括与安全案例危险日志相关的安全相关威胁。

d)  追踪缓解网络安全计划内容中的网络安全相关危害和风险

示例： 与恶意软件缺陷相关的危害可追溯到网络安全计划中涵盖软件更新完整性的部分

e)  兼容的安全和网络安全声明

1)  识别出可能与项目级安全声明相关或相冲突的网络安全声明

注： 冲突分析可能需要定期进行，以应对网络安全计划的变化。

2)  主张安全案例中所描述的项目并不违反网络安全声明

3)  主张网络安全风险处理并不会使安全案例失效

f)  及时检测软件和项目完整性故障

示例： 软件映像的定期加密完整性检查，入侵检测

g)  安全和网络安全声明的共同设计

h)  能够将系统恢复到“出厂默认配置”

5.5.2 故障模型应包括恶意故障。

a)  在已识别的故障模型中包含恶意类型的故障和恶意元素故障

注： 缓解一些恶意故障可能取决于网络安全计划提供的保证。

b)  环境的改变

示例： 污损的标志，在道路上绘制的视觉错觉，道路标记的改变

c)  环境中物体的改变

示例： 反人脸识别的化妆和发型，使用伪装，故意的异常行为，应用于衣服和物体的对抗性攻击图像

d)  恶意道路使用者行为

示例： 行人组故意阻塞车辆，其他车辆试图使自车驶离道路

e)  恶意乘员行为

示例： 乘员试图使用命令覆盖功能导致故意损失事件

f)  数据源的变更

示例： 欺骗的恶劣天气警告，欺骗的 V2x 传输

g)  数据基础设施攻击

示例： 恶意更改地图数据、维护记录、车辆状态信息

h)  训练数据中毒

示例： 在收集训练数据时，故意扭曲对象、事件或其他特征的分布

i)  供应链攻击

示例： 将代码恶意地插入连接到车辆上的组件、附件和数据记录器中；对硬件的恶意破坏；对非电子组件、用品和材料的恶意破坏；加密密钥材料泄漏

j)  安装未经授权的组件

示例： 无意中安装的携带恶意软件的替代供应商更换组件， 由车主或车主添加的无线网络连接设备，带有恶意有效负载的可移动存储媒体

k)  通过已连接的设备进行攻击

示例： 连接到系统有线或无线网络的乘员电子设备

l)  对传感器的物理攻击

示例： 用于致盲相机的油漆枪，在道路上释放的金属化气球

m)  对信息系统的物理攻击

示例： 切断侧视后视镜以接入车辆网络

n)  汽车接管尝试

示例： 通过计算机网络的远程访问，通过乘员的本地访问，访问乘员语音接口，危及中央调度基础设施

o)  软件映像的更改

示例： 恶意软件插入软件更新，车主故意安装的未经授权的更新代码

p)  恶意访问数据

示例： 跟踪者，针对公众人物

6 通讯与数据故障模型

6.1 通讯故障模型

6.1.1 通信故障模型应包括一组可接受的潜在运行时间以及制造故障和失效。

a) 识别出的通信故障模型

b) 通讯链接丢失

c) 通信数据包错误

示例： 随机位翻转，突发错误，丢包

d) 拥塞

示例： 延迟过多，重复，插入

e) 通道过载

f) 通讯时间

示例： 高延迟，早期消息，较大的延迟抖动

g) 来自外部源的数据中的故障，损坏，数据丢失和完整性丢失

示例： 伪装故障，消息冲突，通道干扰

h) 数据完整性检查失败

示例： 错误检测代码的汉明距离不足以用于操作环境；错误检测功能实施不正确，从而降低了位错误检测能力

i) 基于时间的同步和计时失败

示例： 时间间隔的不一致处理，例如 handling 秒，存在故障节点时时间同步的鲁棒性不足，项目和远程设备之间的时间间隔差

j) 人际交流故障或错误，至少包括：

1)  通信功能的错误行为

2)  沟通功能模糊

示例： 由于冰，雪，照明条件，眩光，泥浆，观察者使用偏光太阳镜，车辆纵横比，车辆距离，车速

3)  人类没有注意到通信功能

4)  人对通讯功能的错误解释

5)  人为疏忽的错误

6)  人为错误

7)  人为失误

注： “滑倒”是一种不正确的操作，随后很快就会被人类自我纠正

8)  故意或挑衅性地未能遵守通信功能的意图

k) 网络中不兼容的终端

l) 恶意拒绝服务 ( 如果属于安全计划范围之内 )

m) 如果在安全计划范围之内，则进行恶意假装攻击

n) 其他恶意通信故障 ( 如果在安全计划范围内 )

6.2 数据故障模型

6.2.1 数据故障模型应包括与数据相关的故障和失效的可接受范围广泛的集合。

a) 数据存储故障

b) 数据传输故障

c) 数据值故障

1)  检测到的数据值损坏

2)  未检测到的数据值损坏

3)  数据值不正确

4)  数据格式和 / 或单位不正确

5)  过期数据值

示例： 尽管增加了时间戳，但数据值未更新

6)  符合安全计划的恶意数据值故障

7) 数据值大小不足

示例： 将 64 位浮点值转换为 16 位整数值会导致溢出

d) 元数据故障及相关故障

1)  元数据损坏

2)  元数据不正确

3)  版本和 / 或配置信息不正确

4)  错误的发件人和 / 或收件人

5)  数据路由故障

6)  无效的时间戳记信息

示例： 时间戳记不正确，时间戳记翻转，时间戳记在时间上“向后”

e) 数据排序及相关故障

1)  遗漏和 / 或丢失数据

2)  数据延迟

3)  数据顺序不正确

4)  相关数据的一致性

f) 数据保留错误

1)  数据保留时间不够长

2)  数据保留时间过长

3)  每个安全计划未正确实施数据隐私策略

g) 根据安全计划的数据真实性错误

h) 识别随机故障模型

示例： 双对称随机独立反转 (“ 位翻转” ), 突发错误，擦除错误， RAM 数据字长对应的错误， RAM 芯片宽度对应的错误

i) 识别系统故障模型

示例： 由于软件缺陷，与数据关联的错误报头不正确

j) 与存储相关的故障

示例： 动态 RAM 刷新失败，检测到瞬时存储检索故障后由于重试而导致的延迟

7 组织网络安全管理

7.1 组织网络安全管理概述

本章的目的是确定网络安全政策以及网络安全的组织规则和程序；指定开展网络安全活动所需的责任和相应的权限；支持网络安全的实施，包括提供资源和管理网络安全进程和相关进程之间的相互作用；管理网络安全风险；建立并维持一种网络安全文化，包括能力管理、意识管理和持续改进；支持和管理网络安全信息的共享；建立和维护支持维护网络安全的管理制度；提供证据表明工具的使用不会对网络安全产生不利影响；以及进行组织网络安全审计。如图 7.1 所示，本章的主要内容包括：网络安全治理、网络安全文化、信息共享、管理系统、工具管理、信息安全管理、组织网络安全审计。

图 7.1  组织网络安全管理流程

7.2 网络安全治理

7.2.1 组织应确定网络安全政策，包括：

a) 承认道路车辆网络安全风险；

b) 执行管理层对管理相应的网络安全风险的承诺；

注 1 ： 网络安全政策可以包括与组织的目标和其他政策的链接。

注 2 ： 网络安全政策可以包括一项声明，说明对组织的产品或服务组合的一般威胁情况的风险处理，考虑到外部或内部的情况。

7.2.2 组织应建立并维持规则和程序来：

a) 能够实施本文件的要求；

b) 支持相应活动的执行；

例 1 ： 过程定义、技术规则、指南、方法和模板。

注 3 ： 网络安全风险管理可以包括活动的付出 - 收益考虑。

注 4 ： 规则和流程涵盖概念、产品开发、生产、运营、维护和退役，包括危害分析和风险评估方法、信息共享、网络安全监控、网络安全事件响应和触发器。

注 5 ： 有关漏洞披露的规则和流程，例如作为信息共享的一部分，可以按照 ISO 29147 进行规定。

注 6 ： 图 7.2 概述了总体网络安全政策（见 7.2.1 ）与具体组织的网络安全规则和流程（见 7.2.2 ）、责任（见 7.2.3 ）和资源（ 7.2.4 ）之间的关系。

图 7.2   网络安全的进展情况

7.2.3 组织应分配和传达实现和维护网络安全的责任和相应的组织权力。

注 7 ： 这涉及到组织活动以及依赖项目的活动。

7.2.4 本组织应提供解决网络安全的资源。

注 8 ： 资源包括负责网络安全风险管理、开发和事件管理的人员。

例 2 ： 熟练的人员和合适的工具来进行网络安全活动。

7.2.5 组织应确定与网络安全相关或互动的学科，并在这些学科之间建立和保持沟通渠道，以便：

a) 确定是否以及如何将网络安全纳入现有流程；

b) 协调相关信息的交流；

注 9 ： 资源可以包括在各学科之间分享流程和使用策略和工具。

注 10 ： 学科包括信息技术安全、功能安全和隐私。

7.3 网络安全文化

7.3.1 组织应培养和维持一种强大的网络安全文化。

注 1 ： 例子见附录 A 。

7.3.2 组织应确保被指派网络安全角色和责任的人员具备履行这些角色和责任的能力和意识。

注 2 ： 能力、意识和培训计划可以包括：

—— 关于网络安全的组织规则和程序，包括网络安全风险管理；

—— 与网络安全相关的学科的组织规则和程序，如功能安全和隐私；

—— 领域知识；

—— 系统工程；

—— 与网络安全有关的方法、工具和准则；

—— 已知的攻击方法和网络安全控制。

7.3.3 组织应建立并保持一个持续改进过程。

例： 持续改进过程，包括：

—— 从以前的经验中学习，包括通过网络安全监测和观察内部和外部的网络安全相关信息来收集网络安全信息。

—— 学习与网络安全有关的信息，了解该领域内类似应用的产品。

—— 得出改进意见，以便在以后的网络安全活动中加以应用。

—— 向适当的人传达有关网络安全的经验教训。

—— 根据 7.2.2 检查组织规则和程序的适当性。

注 3: 持续改进适用于本文件中的所有网络安全活动。

7.4 信息共享

7.4.1 组织应培养和维持一种强大的网络安全文化。组织应界定在哪些情况下需要、允许或禁止在组织内部或外部共享与网络安全有关的信息。

注： 共享信息的情况可以基于以下几点：

—— 可以共享的信息类型；

—— 共享的批准程序；

—— 对编辑信息的要求；

—— 源头归属的规则；

—— 为特定当事方提供的通信类型；

—— 漏洞披露程序（见 7.2 的注 5 ）；

—— 对接收方处理高度敏感信息的要求。

7.4.2 组织应根据 7.4.1 的规定，将其对共享数据的信息安全管理与其他各方保持一致。

例： 公共、内部、机密、第三方机密等安全分类级别的调整。

7.5 管理系统

7.5.1 该组织应按照国际标准或同等标准建立并维持一个质量管理体系，以支持网络安全工程，其中包括：

例 1 ： IATF 16949 与 ISO 9001 相结合

a) 变革管理

注 1 ： 网络安全中的变更管理的范围是管理项目及其组成部分的变更，以便继续实现适用的网络安全目标和要求，例如，对照生产控制计划审查生产过程的变更，以防止这种变更带来新的漏洞。

b) 文件管理

c) 配置管理

d) 要求管理

7.5.2 为维护现场产品的网络安全所需的配置信息应保持可用，直到对产品的网络安全支持结束，以便能够采取补救行动。

注 2 ： 归档构建环境对确保以后使用配置信息很有用。

例 2 ： 材料清单，软件配置。

7.5.3 应建立生产过程的网络安全管理系统，以支持 7.5.2 的活动

例 3 ： IEC 62443 2-1

7.6 工具管理

7.6.1 应管理能够影响项目或部件网络安全的工具。

例 1 ： 用于概念或产品开发的工具，如基于模型的开发、静态检查器、验证工具。

例 2 ： 在生产过程中使用的工具，如闪存写入器、生产线末端测试器。

例 3 ： 用于维护的工具，如板载诊断工具或重新编程工具。注意这种管理可以通过以下方式建立：

—— 应用的用户手册与勘误表；

—— 防止非故意的使用或行动；

—— 工具用户的访问控制；

—— 对该工具的认证；

7.6.2 支持网络安全事件补救行动的适当环境应该是重复的，直到产品的网络安全支持结束。

例 4 ： 用于再现和管理漏洞的测试、软件构建和开发环境。

例 5 ： 用于构建产品软件的工具链和编译器。

7.7 信息安全管理

7.7.1 工作产品应按照信息安全管理系统进行管理。

例： 工作成果可以存储在一个文件服务器上，以保护它们不被擅自更改或删除。

7.8 组织网络安全审计

7.8.1 应独立进行网络安全审计，以判断组织程序是否达到本文件的目标。

注 1 ： 网络安全审计可以包括在根据质量管理体系标准进行的审计中，或与之相结合，例如 IATF 16949 与 ISO 9001 相结合。

注 2 ： 独立性可以基于，例如， ISO 26262 系列。

注 3 ： 执行审计的人员可以是组织的内部和外部人员。

注 4 ： 为确保组织流程仍然适合网络安全，可以定期进行审计。

注 5 ： 图 8.3 说明了组织网络安全审计与其他网络安全活动的关系。

8 依靠项目的网络安全管理

8.1 依靠项目的网络安全管理概述

本章描述了关于特定项目的网络安全开发活动管理的要求。本章的目的是确定指定有关项目网络安全活动的责任；计划网络安全活动，包括定义专门的网络安全活动；创建一个网络安全案例；进行网络安全评估（如适用）；从网络安全的角度决定该项目或组件是否可以释放后开发。如图 8.1 所示，本章主要内容包括： 网络安全责任、网络安全规划、裁剪、再利用、组件脱离背景、现成的组件、网络安全案例、网络安全评估和后续开发的发布。

图 8.1  依靠项目的网络安全管理流程

8.2 网络安全责任

8.2.1 应根据 7.2.3 分配和通报有关项目网络安全活动的责任。

注： 网络安全活动的责任可以转移，前提是要进行沟通并提供相关信息。

8.3 网络安全规划

8.3.1 为了决定项目或部件所需的网络安全活动，应分析该项目或部件以确定：

a) 该项目或组件是否与网络安全有关；

注 1 ： 附录 B 提供了一个可用于评估网络安全相关性的方法和标准；

注 2 ： 如果该项目或组件被确定为与网络安全无关，那么就没有网络安全活动，因此不继续进行网络安全规划；

b) 如果该项目或组件与网络安全有关，则该项目或部件是新开发还是重复利用；

c) 是否按照 8.4 的规定进行裁剪；

8.3.2 网络安全计划应包括：

a) 一项活动的目标；

b) 对其他活动或信息的依赖性；

c) 负责执行一项活动的人员；

d) 执行一项活动所需的资源；

e) 起始点或终结点，活动预期的持续周期；

f) 确定要生产的工作产品；

8.3.3 应根据 7.2.3 和 7.2.4 分配制定和维护网络安全计划以及根据网络安全计划跟踪网络安全活动进展的责任。

8.3.4 网络安全计划应是

a) 在开发项目计划中提及的；

b) 包括再项目计划中，从而使网络安全活动可以区分开来；

注 3 ： 网络安全计划可以纳入与其他计划（如项目计划）的交叉引用，这些计划也属于配置管理（另见 8.3.8 ）

8.3.5 网络安全计划应根据危害分析和风险评估、系统开发、软件开发、硬件开发和 AI 安全的相关要求，规定在概念和产品开发阶段需要进行的网络安全活动。

8.3.6 当确定要进行的活动发生变化或细化时，应更新网络安全计划。

注 4 ： 网络安全计划可以在发展过程中逐步完善。例如，网络安全计划可以根据网络安全活动的结果进行更新。

8.3.7 对于根据危害分析确定的风险值为 1 的威胁情景，可以省略系统设计、软件开发、硬件开发和集成验证的符合性。

注 5 ： 这些威胁情况可能会对网络安全产生影响，如果是这样，就会对相应风险进行处理，尽管可能没有本文件中定义的那么严格。

注 6 ： 可以根据网络安全案例中定义的理由来论证对此类风险的处理是否充分，该理由可以基于符合质量管理标准，如 IATF 16949 与 ISO 9001 相结合，并结合其他措施，例如：

—— 网络安全意识保证

—— 质量人员的网络安全培训

—— 组织的质量管理体系中规定的网络安全具体措施

8.3.8 网络安全计划中确定的工作产品应在开发后发布之前和发布时进行更新并保持准确性。

8.3.9 如果网络安全活动是分布式的，客户和供应商应根据第九章的规定，就各自的网络安全活动和接口各自确定一个网络安全计划。

8.3.10 网络安全计划应按照 7.5 的规定，接受配置管理和文件管理。

8.3.11 网络安全计划中确定的工作产品应按照 7.5 的规定，接受配置管理、变更管理、需求管理和文档管理。

8.4 裁剪

8.4.1 一项网络安全活动可能是量身定做的。

8.4.2 如果一项网络安全活动是有针对性的，那么应提供并审查为什么这种针对性足以实现本文件的相关目标的理由。

注： 由于由供应链中的另一实体执行而未执行的活动不被视为量身定制，而是被视为分布式网络活动（见第 9 章）。然而，网络安全活动的分布可以导致联合定制（见 9.4 ）

8.5 再利用

8.5.1 如果一个项目或组件已经开发出来自：

a) 计划进行修改

b) 计划在另一个操作环境中重新使用

例 1 ： 在新的操作环境中安装现有的项目或部件，或升级与之相互作用的其他项目或部件而导致的环境修改（见图 8.2 ）

图 8.2  依靠项目的网络安全管理流程

c) 计划不加修改地重新使用，并且有关该项目或组件的信息有相关的变化。

例 2 ： 已知攻击和漏洞的变化，或威胁情景的变化。

注 1 ： 在确定是否可以重用时，要考虑现有的工作产品。

注 2 ： 修改可以包括设计上的修改或实施上的修改，其中：

—— 设计修改可以来自于需求的修改，例如功能或性能的提升。

—— 实施的修改可能来自对软件的修正，或使用新的生产或维修工具，如基于模型的开发。

注 3 ： 修改可以包括设计上的修改或实施上的修改，其中：如果对配置数据或校准数据的更改影响到物品或部件的功能行为、资产或网络安全属性，则被视为修改。

8.5.2 对一个项目或部件的再利用分析应：

a) 确定对该项目或部件的修改以及对其操作环境的修改。

b) 分析修改的网络安全影响，包括对网络安全主张的有效性和以前作出的假设的影响。

例 3 ： 对网络安全要求、设计和实施、操作环境、假设和操作模式的有效性、维护、对已知攻击的敏感性和已知漏洞或资产的暴露的影响。

c) 确定受影响或丢失的工作成果；

例 4 ： 危害分析和风险评估考虑新的或修改的资产、威胁情景或风险值。

d) 在网络安全计划中明确规定符合本文见的必要网络安全活动（见 8.3 ）。

注 4 ： 这可能意味着裁剪（见 8.4 ）。

8.5.3 一个组件的再利用分析应评估是否：

a) 该组件能够满足将被集成的项目或组件所分配的网络安全要求；

b) 现有的文件足以支持整合到一个项目中，或整合到另一个组件中；

8.6 组件脱离背景

8.6.1 对开发的非情境组件的预期用途和情境的假设，包括外部接口，应在相应的工作产品中予以记录。

8.6.2 对于开发一个脱离背景的组件，网络安全要求应基于 8.6.1 的假设。

8.6.3 对于整合一个在背景之外开发的组件，应验证 8.6.1 的网络安全主张和假设。

8.7 现成的组件

8.7.1 在集成一个现成的组件时，应收集和分析与网络安全有关的文件，以确定是否：

a)  分配的网络安全要求可以得到满足；

b)  该部件适用于预期用途的具体应用环境；

c)  现有文件足以支持网络安全活动。

8.7.2 如果现有文件不足以支持现成组件的集成，那么应确定并执行符合本文件的网络安全活动。

例： 有关漏洞的文件不充分。

注： 这可能意味着量身定做（见 8.4 ）。

8.8 网络安全案例

8.8.1 应创建一个网络安全案例，为该项目或组件的网络安全提供论据，并由工作产品加以支持。

注 1 ： 部分论据可以是隐含的（例如，如果部分论据从汇编工作成果中可以看出，那么这部分论据可以省略）。

注 2 ： 在分布式开发中，项目的网络安全案例可以是客户和供应商的网络安全案例的组合，其中引用了各方产生的工作产品的证据。项目的整体论证由所有各方的论证来支持。

注 3 ： 网络安全案例考虑了开发后的网络安全要求。

8.9 网络安全评估

8.9.1 在决定是否对某一项目或部件进行网络安全评估时，应以基于风险的方法为依据说明理由。

注 1 ： 理由可以基于以下几点：

—— 危害分析和风险评估结果

—— 待开发的项目或部件的复杂性

—— 组织规则和程序所规定的标准（见 7.2 ）

注 2 ： 如果不进行网络安全评估，可将理由记录在网络安全案例中。

8.9.2 应独立审查 8.9.1 的基本原理。

注 3 ： 独立计划可以基于 ISO 26262 系列。

8.9.3 网络安全评估应判断该项目或组件的网络安全情况。

注 4 ： 现有的证据是由网络安全活动的记录结果，即工作产品提供的。

注 5 ： 图 8.3 说明了组织网络安全审计、项目级网络安全评估和其他网络安全活动之间的关系。

图 8.3  网络安全评估与其他网络安全活动的关系

注 6 ： 网络安全评估可以分步骤进行，以促进尽早解决所发现的问题。

注 7 ： 网络安全评估可以重复或补充，例如，由于变化，以前的网络安全评估提供了一个负面的建议或发现了一个漏洞。

8.9.4 应根据 8.2.1 任命一名负责计划和独立进行网络安全评估的人员。

注 8 ： 独立计划可以基于 ISO 26262 系列。

例： 来自组织内不同团队或部门的人员，如质量保证来自独立组织的人员。

8.9.5 进行网络安全评估的人应具备：

a) 获得相关信息和工具；

b) 执行网络安全活动的人员的合作。

8.9.6 网络安全评估可基于对是否实现本文件的目标的判断。

8.9.7 网络安全评估的范围应包括：

a) 网络安全计划和网络安全计划中确定的所有工作产品。

b) 对网络安全风险的处理。

c) 为项目实施的网络安全控制和网络安全活动的适当性和有效性；

注 9 ： 适当性和有效性可以通过使用为验证目的而进行的先前审查来判断。

d) 如果提供了理由，证明实现了本文件的目标。

注 10 ： 负责创建工作产品的人可以提供一个理由，说明为什么要实现本文件的相应目标，以促进网络安全评估，考虑 8.4.1 。

注 11 ： 满足所有相应的要求是实现本文件目标的充分理由。

8.9.8 网络安全评估报告应包括对该项目或部件的网络安全的接受、有条件接受或拒绝的建议。

注 12 ： 评估报告还可以包括持续改进的建议。

8.9.9 如果按照 8.9.8 提出有条件接受的建议，那么网络安全评估报告应包括接受的条件。

8.10 后续开发的发布

8.10.1 以下工作成果应在发布前提供给开发后的人：

a) 网络安全案例；

b) 如果适用，网络安全评估报告；

c) 开发后的网络安全要求。

8.10.2 项目或部件开发后的发布应满足以下条件：

a) 网络安全案例为网络安全提供的论据是令人信服的；

b) 网络安全评估确认了网络安全案例（如适用）；

c) 开发后阶段的网络安全要求被接受。

注： 变化可能会导致对开发后的版本进行重新评估，例如对网络安全要求的变化。

9 分布式网络安全活动

9.1 分布式网络安全活动概述

本章的目的是定义客户和供应商之间分布式网络安全活动的互动、依赖和责任。如图 9.1 所示，本章主要内容包括： 供应商能力、要求报价和职责的统一。

图 9.1  分布式网络安全活动流程

9.2 供应商能力

9.2.1 应评估候选供应商按照本文件规定进行开发和（如适用）进行后期开发活动的能力。

注 1 ： 该评价支持供应商的选择，可以基于供应商符合本文件的能力，也可以基于对另一国家或国际标准在网络安全工程方面的先前实施情况的评价。

9.2.2 为了支持客户对供应商能力的评估，供应商应提供网络安全能力的记录。

注 2 ： 网络安全能力的记录可以包括：

—— 组织有关网络安全能力的证据（例如，来自开发、开发后、治理、质量和信息安全的网络安全最佳做法）；

—— 持续的网络安全活动和网络安全事件相应的证据；

—— 以前的网络安全评估报告摘要。

9.3 要求报价

9.3.1 客户向候选供应商发出的报价请求应包括：

a) 正式要求符合本文件的规定；

b) 预计供应商将按照 9.4 的规定承担安全责任；

c) 与供应商报价的项目或部件有关的网络安全目标和 / 或网络安全要求集。

例： 与信息验证有关的网络安全要求。

9.4 职责的统一

9.4.1 客户和供应商在网络安全接口协议中规定分布式网络安全活动，包括：

a) 指定客户和供应商在网络安全方面的联络点；

b) 确定由客户和供应商分别开展的网络安全活动；

例 1 ： 由客户进行车辆层面的网络安全验证。

例 2 ： 关于开发后的网络安全活动的分布。

例 3 ： 关于供应商开发的部件或工作产品的网络安全评估可由第三方、客户或供应商进行。

c) 如果适用的话，根据 8.4 的规定，共同制定网络安全活动；

d) 将要分享的信息和工作成果。

注 1 ： 共享的信息可以包括：

—— 分发、审查和网络安全问题反馈机制；

—— 漏洞和其他网络安全相关发现的信息交流程序；例如，关于风险。

—— 与接口有关的流程、方法和工具，以确保客户和供应商之间的兼容性，如适当处理数据和确保用于该数据的通信网络的安全；

—— 角色的定义；

—— 沟通和记录项目或部件的变化的方法，包括可能的危害分析的风险评估的重复；

—— 在需求管理工具上保持一致；

—— 网络安全评估的结果。

e) 将要分享的信息和工作成果。 关于分布式网络安全活动的里程碑；

f) 对该项目或组件的网络安全支持结束的定义。

9.4.2 网络安全接口协议应在分布式网络安全活动开始前由客户和供应商共同商定。

9.4.3 如果存在需要根据 8.6.1 进行管理的已识别的漏洞，客户和供应商就行动和这些行动的责任达成一致。

9.4.4 如果要求不明确，不可行，或与其他网络安全要求或其他学科的要求相冲突，那么客户和供应商应各自通知对方，以便做出适当的决定和行动。

9.4.5 应在责任分配矩阵中规定责任。

注 2 ： 可以使用 RASIC 表，见附录 C

10 持续的网络安全活动

10.1 持续的网络安全活动概述

本章的目的是监测网络安全信息以确定网络安全事件、评估网络安全事件以确定薄弱环节、从弱点中识别脆弱性和管理已查明的漏洞。如图 10.1 所示，本章主要内容包括：网络安全监测、网络安全事件评估、脆弱性分析和漏洞管理。

图 10.1  依靠项目的网络安全管理流程

10.2 网络安全监测

10.2.1 应收集网络安全信息的来源。

注 1 ： 可以选择内部和 / 或外部来源。

注 2 ： 内部来源可以包括：

—— 项目定义

—— 项目安全索赔

—— 网络安全规范

—— 威胁情况

—— 过去的脆弱性分析

—— 从外地收到的信息

例 1 ： 漏洞扫描报告、维修信息、消费者使用信息

注 3 ： 外部来源可以包括：

—— 研究人员

—— 商业或非商业来源

—— 组织的供应链

—— 组织的客户

—— 政府来源

例 2 ： 最先进的攻击方法的来源。

10.2.2 应定义并维护触发器，以便对网络安全信息进行分类。

注 4 ： 触发器可以包括关键词、配置信息的参考、组件或供应商的名称。

10.2.3 应收集和分流网络安全信息，以确定该网络安全信息是否成为一个或多个网络安全事件。

10.3 网络安全事件评估

10.3.1 应评估网络安全事件，以确定项目和 / 或组件的弱点。

注 1 ： 此活动应与 10.2.3 的分流相结合。

注 2 ： 如果存在一个弱点，并且有可用的补救措施（例如，供应商为组件中的漏洞提供的补丁） , 组织可以将补救措施（见 10.5 ）作为一个假定的漏洞来处理，而无需任何其他活动。

注 3 ： 威胁情景可以根据该评估的结果进行更新。

10.4 脆弱性分析

10.4.1 应评估网络安全事件，以确定项目和 / 或组件的弱点。应分析弱点以确定脆弱性

注 1 ： 该分析可包括：

—— 对架构的分析

—— 攻击路径分析

—— 攻击可行性等级

注 2 ： 可以进行根本原因分析，以确定导致弱点成为漏洞的可能性的任何潜在因素。

例 1 ： 攻击路径分析显示不存在攻击路径，因此，该弱点不被当作漏洞处理。

例 2 ： 攻击路径分析显示不存在攻击路径，因此，该弱点不被当作漏洞处理。利用该弱点的攻击可行性等级很低，因此，该弱点不被视为漏洞。

10.4.2 对于未被确定为漏洞的弱点应提供理由。

10.5 漏洞管理

10.5.1 漏洞的管理应做到对每个漏洞。

a) 对相应的网络安全风险进行评估，并进行处理，使之不存在不合理的风险

b) 通过应用独立于危害分析和风险评估的可用补救措施来消除该漏洞

例： 开源软件的补丁

注 1 ： 如果脆弱性管理项目或部件的变更，则按照 7.5.1 进行变更管理。

注 2 ： 有关的信息可以在分布式网络安全活动范围内（见 9.4 ，如分享攻击路径的知识）和向其他有关各方（见 7.4 ）分享

10.5.2 如果根据做出的风险处理决定需要进行网络安全事件应对，则应适用于相关要求。

注 3 ： 网络安全事件响应过程可以独立于危害分析和风险评估而应用。

11 信息安全要求

11.1 信息安全要求概述

本章的目的是确定信息安全基本要求和信息安全技术要求。如图 11.1 所示，本章主要内容包括：信息安全基本要求和信息安全技术要求，其中信息安全技术要求由外部连接安全要求、通信安全要求、软件升级安全要求、数据安全要求组成。

图 11.1   信息安全要求流程

11.2 信息安全基本安全要求

11.2.1 车辆产品开发应遵循第 7 章和第 8 章的汽车信息安全管理体系要求。

11.2.2 车辆制造商应遵循第 9 章的要求识别和管理车辆与供应商相关的风险。

11.2.3 车辆制造商应识别车辆的关键要素，对车辆进行风险评估，并管理已识别的风险。

注 1 ： 风险评估的范围包括车辆的各个要素及其相互作用，并进一步考虑与外部系统的相互作用。

注 2 ： 关键要素包括但不限于有助于车辆安全、环境保护或防盗的要素，以及提供连接性的系统部件或车辆架构中对信息安全至关重要的部分等。

11.2.4 车辆制造商应采取基于本章的处置措施保护车辆不受风险评估中已识别的风险影响。若处置措施与所识别的风险不相关，车辆制造商应说明其不相关性。若处置措施不足以应对所识别的风险，车辆制造商应实施其他措施，并说明措施的合理性。

11.2.5 如有专用环境，车辆制造商应采取措施，以保护车辆用于储存和执行后装软件、服务、应用程序或数据的专用环境。

注： 如沙箱专用环境等。

11.2.6 车辆制造商应通过测试来验证所实施的信息安全措施的有效性。

11.2.7 车辆制造商应针对车辆实施相应措施，以确保具备以下能力：

—— 针对车辆网络攻击的识别能力；

—— 针对于车辆相关的网络攻击、网络威胁和漏洞的监测能力及数据取证能力。

11.2.8 车辆制造商应使用公开的、已发布的、有效的密码算法，应根据不同密码算法和业务场景，选择适当的参数和选项。

11.2.9 车辆制造商应满足以下密码模块要求之一：

—— 采用符合国际、国家或行业标准要求的密码模块；

—— 未采用国际、国家或行业标准要求的密码模块，说明使用的合理性。

11.2.10 车辆应采用默认安全设置，如 WLAN 的默认连接口令应满足复杂度的要求。

11.2.11 车辆数据处理活动中的数据车内处理、默认不收集、精度范围适用、脱敏处理、个人同意及显著告知等要求，应符合 GB/T 44464-2024 中 4.2.2 的规定。

11.3 外部连接安全要求

11.3.1 通用安全要求

a) 车端具备远程控制功能的系统、授权的第三方应用等外部连接系统不应存在由汽车行业权威漏洞平台 6 个月前公布且未经处置的高危及以上的安全漏洞。

注 1 ： 汽车行业权威漏洞平台如车联网产品专用漏洞库 NVDB-CAVD 等政府主管部门认可的其他漏洞平台。

注 2 ： 处置包括消除漏洞、制定减缓措施等方式。

b) 车辆应关闭非业务必要的网络端口。

11.3.2 远程控制安全要求

a) 应对远程控制指令信息进行真实性和完整性验证。

b) 应对远程控制指令设置访问控制，禁用非授权的远程控制指令。

c) 应具备记录远程控制指令的安全日志功能，安全日志记录的内容至少包括远程控制指令的时间、发送主体、远程控制对象、操作结果等，留存相关的安全日志应不少于 6 个月。

d) 应对车端具备远程控制功能的系统进行完整性验证。

11.3.3 第三方应用安全要求

a) 应对授权的第三方应用的真实性和完整性进行验证。

注： 第三方应用是指车辆制造商及其供应商之外的其他实体提供的面向用户提供服务的应用程序，包括第三方娱乐应用等。

b) 应对非授权的第三方应用的安装进行提示，并对已安装的非授权的第三方应用进行访问控制，限制此类应用直接访问系统资源、个人信息等。

11.3.4 外部接口安全要求

a) 应对车辆外部接口进行访问控制保护，禁止非授权访问。

注： 外部接口包括 USB 接口、诊断接口和其他可直接接触的物理接口。

b) 应对车辆 USB 接口、 SD 卡接口接入设备中的文件进行访问控制，仅允许读写指定格式的文件或安装执行指定签名的应用软件。

c) 车辆应对 USB 接口接入设备中的病毒风险进行处置。

d) 通过诊断接口向车辆发送关键配置及标定参数的写操作指令时，车辆应采用身份鉴别或访问控制等安全策略。

11.4 通信安全要求

11.4.1 车辆与车辆制造商云平台通信时，应当其通信对象的身份真实性进行验证。

11.4.2 车辆与车辆、路侧单元、移动终端等进行 V2X 直连通信时，应进行证书有效性和合法性的验证。

11.4.3 车辆应采用完整性保护机制保护除 RFID 、 NFC 之外的外部无线通信通道。

11.4.4 车辆应具备对来自车辆外部通信通道的数据操作指令的访问控制机制。

注： 来自车辆外部通信通道的数据操作指令包括代码注入、数据操纵、数据覆盖、数据擦除和数据写入等指令。

11.4.5 车辆应验证所接收的外部关键指令数据的有效性或唯一性。

示例： 针对远程控制服务器发送的车控指令，车端可通过网关验证该指令的有效性或唯一性。

注： 关键指令数据是指可能影响行车和财产安全的指令数据，包括但不限于车控指令数据。

11.4.6 车辆应对向车外发送的敏感个人信息实施保密性保护措施。

11.4.7 车辆应具备安全机制防御物理操纵攻击，至少具备与外部直接无线通信的零部件的身份识别机制。

注： 与外部存在直接无线通信的零部件包括但不限于车载信息交互系统等，不包括短距离无线传感器。

11.4.8 车辆应外部直接无线通信的零部件应具备安全机制防止非授权的特权访问。

注： 非授权用户可能通过调试接口获得系统的根用户或特权用户权限。

11.4.9 车辆应对内部网络进行区域划分并对区域边界进行防护。车辆内部网络跨域请求应进行访问控制，并遵循默认拒绝原则和最小化授权原则。

注： 区域边界防护措施包括物理隔离、逻辑隔离（如采用白名单、防火墙、 VLAN ）等。

11.4.10 车辆应具备识别车辆通信通道遭受拒绝服务攻击的能力，并对攻击进行相应的处理。

注 1 ： 对攻击的处理包括对攻击数据包的拦截或丢弃、受影响系统的自动恢复、日志记录等。

注 2 ： 车辆通信通道包括移动蜂窝通信、 V2X 、 CAN 总线、车载以太网等。

11.4.11 车辆应具备识别恶意的 V2X 数据、恶意的诊断数据的能力，并采取保护措施。

注： V2X 数据包括路侧单元发送到车辆的数据、车辆与车辆之间的数据。

11.4.12 应具备记录关键的通信信息安全事件日志的功能，日志存储时长应不少于 6 个月。

注： 关键的通信信息安全事件由车辆制造商根据风险评估的结果确定，日志记录内容包括事件时间、事件原因等。

11.5 软件升级安全要求

11.5.1 通用安全要求

a) 车载软件升级系统应通过安全保护机制，保护车载软件升级系统的可信根、引导加载程序、系统固件不被篡改，或在被篡改后，通过安全保护机制使其无法正常启动。

b) 车载软件升级系统不应存在由汽车行业权威漏洞平台 6 个月前公布且未经处置的高危及以上的安全漏洞。

注 1 ： 汽车行业权威漏洞平台如车联网产品专用漏洞库 NVDB-CAVD 等政府主管部门认可的其他漏洞平台。

注 2 ： 处置包括消除漏洞、制定减缓措施等方式。

11.5.2 在线升级安全要求

a) 车辆和在线升级服务器应进行身份认证，验证其身份的真实性，并在下载中断恢复时重新验证。

注： 常见的认证方式包括使用证书进行身份认证。

b) 车辆应对下载的升级包进行真实性和完整性验证。

c) 应对在线升级过程中发生的信息安全事件日志进行记录，日志存储时长应不少于 6 个月。

11.5.3 离线升级安全要求

a)  若车辆使用车载软件升级系统进行离线升级， 车辆应对离线升级包真实性和完整性进行验证。

b)  若车辆不使用车载软件升级系统进行离线升级，应采取保护措施保证刷写接入端的安全性，或验证升级包的真实性和完整性。

11.6 数据安全要求

11.6.1 车辆应采取安全访问技术或安全存储技术保护存储的对称密钥和非对称密钥中的私钥，防止其被非授权访问和获取。

11.6.2 车辆应采取安全访问技术、加密技术或其他安全技术保护存储在车内的敏感个人信息，防止其被非授权访问和获取。

11.6.3 车辆应采取安全防御机制保护存储在车内 VIN 等用于车辆身份识别的数据，防止其被非授权删除和修改。

注： 防止数据被非授权删除和修改的安全防御机制包括安全访问技术、只读技术等。

11.6.4 车辆应采取安全防御机制保护存储在车内的关键数据，防止其被非授权删除和修改。

注： 关键数据包括制动参数、安全气囊展开阈值、动力电池参数等关键配置参数，以及其他车辆运行过程中产生的可能影响行车安全的数据。

11.6.5 车辆应采取安全防御机制保护存储在车内的安全日志，防止其被修改和非授权删除。

11.6.6 车辆应具备个人信息删除功能，该功能可删除的信息不应包括法律、行政法规、强制性国家标准中规定必须保留的个人信息。

11.6.7 车辆不应向境外传输数据。

注： 用户使用浏览器访问境外网站、使用通信软件向境外传递消息、自主安全可能导致数据出境的第三方应用等用户自主行为不受本条款限制。

12 检查与试验方法

12.1 检查与试验方法概述

本章的目的是对信息安全管理体系及信息安全基本要求进行检查并对信息安全技术要求进行测试。如图 12.1 所示，本章主要内容包括：信息安全基本要求检查、信息安全技术要求测试条件、外部连接安全测试、通信安全测试、软件升级安全测试和数据安全测试。

图 12.1   检查与试验方法流程

12.2 检查与试验方法总则

检查及试验方法包括汽车信息安全管理体系检查、基本要求检查和技术要求检查：

—— 针对车辆制造商信息安全保障能力相关的文档进行检查，确认车辆制造商满足第 8 章和第 9 章的要求；

—— 针对车辆在开发、生产等过程中信息安全相关的文档进行检查，确认测试车辆满足 11.2 节要求；

—— 基于车辆所识别的风险以及第 11 章车辆技术要求处置措施的相关性，依据 12.4 确认车辆信息安全技术要求的测试范围，并依据测试范围开展测试，确认满足第 11 章的要求。

注： 测试范围包括第 11 章与待测试车辆的适用条款、各适用条款对应的测试对象等。

12.3 信息安全基本要求检查

12.3.1 检查要求

a) 车辆制造商应具备文档来说明车辆在开发、生产等过程的信息安全情况，文档包括提交的文档和留存备查的文档。

b) 提交的文档应为中文版本，并至少包含如下内容：

—— 证明车辆满足 11.2 要求的总结文档；

—— 写明文档版本信息的留存备查文档清单。

c) 车辆制造商应以安全的方式在本地留存车辆信息安全相关过程文档备查，完成检查后应对留存备查的文档进行防篡改处理。

d) 车辆制造商应对提交和留存备查的文档与车辆的一致性、可追溯性做出自我声明。

12.3.2 检查方法

a)  检查车辆制造商提交的文档，确认检查方案，包括检查范围、检查方式、检查日程、现场检查必要的证明文件清单。

b)  应依据 a ）确认的检查方案，在车辆制造商现场检查留存备查的信息安全相关过程文档，确认车辆是否满足 11.2 节的要求。

12.4 信息安全技术要求测试

12.4.1 测试条件

a) 测试环境要求

涉及无线短距离通信的测试，应保证车辆在无信号干扰的测试环境中进行。

b) 测试状态要求

测试样件包括整车及 12.2 确定的测试范围中涉及的零部件，应满足以下要求：

—— 测试样件可正常运行；

—— 整车信息安全相关功能处于开启状态；

—— 测试过程中，若测试车辆速度大于 0km/h 或测试车辆可能发生非预期启动，则将测试车辆置于整车转毂试验台或保证车辆安全运行的道路环境中开展测试。

c) 测试输入要求

车辆制造商应依据 12.2 确定的测试范围，提供必要的测试输入支持完成测试。

12.4.2 外部连接安全测试

a) 通用安全测试

1) 系统漏洞安全测试

测试人员应使用漏洞扫描工具对车辆外部连接系统进行漏洞扫描，并将测试结果与汽车行业权威漏洞平台 6 个月前公开的高危及以上的安全漏洞清单和车辆制造商提供的车辆外部连接系统漏洞处置方案进行比对，判定车辆是否满足 11.3.1.a 的要求。

2) 非业务必要网络端口安全测试

测试人员应依据车辆制造商提供的车辆业务端口列表，通过 WLAN 、车载以太网、蜂窝网络等通信通道将测试车辆与扫描测试设备组网，使用扫描测试设备测试车辆所开放的端口，并将测试得到的车辆开放端口列表与车辆业务端口列表进行比对，判定车辆是否满足 11.3.1.b 的要求。

b) 远程控制安全测试

1) 真实性和完整性验证安全测试

测试人员应按照以下测试方法依次开展测试，判定车辆是否满足 11.3.2.a 的要求：

• 登录车辆远程控制程序账户，测试是否可触发正常的远程车辆控制指令；
• 伪造、篡改并发送远程车辆控制指令，检查是否可伪造、篡改该指令，车辆是否执行该指令。

2) 远程控制指令权限控制安全测试

测试人员应依据车辆制造商提供的车辆远程控制指令应用场景和使用权限文件，构造并发送超出权限的远程控制指令。判定车辆是否满足 11.3.2.b 的要求。

3) 安全日志记录安全测试

测试人员应按照以下测试方法依次开展测试，判定是否满足 11.3.2.c 的要求：

• 触发车辆远程控制功能，检查是否存在安全日志，安全日志记录的内容是否包含远程控制指令的时间、发送主体、远程控制对象、操作结果等信息；
• 检查安全日志记录的时间跨度是否不少于 6 个月或是否具备留存安全日志不少于 6 个月的能力。

4) 完整性安全测试

测试人员应根据车辆制造商提供的车辆远程控制功能系统完整性验证功能的证明文件，判定车辆是否满足 11.3.2.d 的要求。

c) 第三方应用安全测试

1) 真实性完整性验证安全测试

测试人员应获取授权的第三方应用，使用工具篡改其代码，并安装、执行篡改后的授权第三方应用，判定车辆是否满足 11.3.3.a 的要求。若篡改后的授权第三方应用被限制访问超出访问控制权限的资源，视为应用非正常运行，满足要求。

2) 访问控制安全测试

测试人员应按照以下测试方法依次开展测试，判定车辆是否满足 11.3.3.b 的要求：

• 安装非授权的第三方应用，测试车辆是否进行提示；
• 使用已安装的非授权第三方应用访问超出访问控制权限资源，测试是否可访问控制权限外的资源。

d) 外部接口安全测试

1) 外部接口访问控制安全测试

测试人员应依据车辆制造商提供的车辆外部接口的总结文档或车辆外部接口清单，使用非授权的用户或工具访问车辆的外部接口，判定车辆是否满足 11.3.4.a 的要求。

2) USB 接口、 SD 卡接口访问控制安全测试

测试人员应依据车辆制造商提供的 USB 接口、 SD 卡接口的总结文档或 USB 接口、 SD 卡接口支持的文件类型清单，分别在具备 USB 接口、 SD 卡接口的移动存储介质中注入指定格式文件、指定签名的应用软件和其他非指定格式文件和非指定签名的应用软件，将移动存储介质分别连接到车辆 USB 接口、 SD 卡接口，尝试执行非指定格式文件和非指定签名的应用软件，判定车辆是否满足 11.3.4.b 的要求。

3) USB 防病毒安全测试

测试人员应在具备 USB 接口的移动存储介质中注入病毒文件，将移动存储介质连接到车辆 USB 接口，尝试执行病毒文件，判定车辆是否满足 11.3.4.c 的要求。

4) 诊断接口身份鉴别安全测试

测试人员应按照以下两种测试方法中适用的测试方法开展测试，判定车辆是否满足 11.3.4.d 的要求：

• 使用非授权用户或工具在诊断接口发送车辆关键配置及标定参数的写操作指令，测试车辆是否执行该操作指令；
• 使用工具在诊断接口发送车辆关键配置及标定参数的写操作指令，测试车辆是否存在访问控制机制。

12.4.3 通信安全测试

a) 云平台通信身份真实性验证安全测试

测试人员应依据车辆制造商提供的云平台清单及采用的通信协议类型，并按照如下三种测试方法中适用的测试方法开展测试，判定车辆是否满足 11.4.1 的要求。

• 若车辆与车辆制造商云平台采用专用网络或虚拟专用网络环境进行通信，测试人员应根据企业提供的车辆云平台通信身份真实性的证明文件，确认车辆是否满足 11.4.1 的要求。
• 若车辆与车辆制造商云平台采用公共网络环境进行通信，且使用公有通信协议，测试人员应使用网络数据抓包工具进行数据抓包，解析通信报文数据，检查车辆是否对车辆制造商云平台进行身份真实 性验证，若采用网络数据抓包工具无法进行数据抓包，测试人员应根据企业提供的车辆云平台通信身份真实性的证明文件，确认车辆是否满足 11.4.1 的要求。
• 若车辆与车辆制造商云平台采用公共网络环境进行通信，且使用私有通信协议，测试人员应根据企业提供的车辆云平台通信身份真实性的证明文件，确认车辆是否满足 11.4.1 的要求。

b) V2X 通信身份认证安全测试

测试人员应按照以下测试方法依次开展测试，判定车辆是否满足 11.4.2 的要求：

• 依照 12.4.1.b 的要求处置车辆，由测试设备向测试车辆下发合法证书并与测试车辆进行正常通信，测试车辆是否能够接收测试设备的直连通信消息；

• 分别构造失效证书和身份伪造证书，并向车辆发送通信消息，测试车辆是否能够识别失效证书和身份伪造证书。

c) 通信通道完整性安全测试

测试人员应依据车辆制造商提供的车辆移动蜂窝通信、 WLAN 、蓝牙等外部通信通道清单，依次触发车辆外部无线通信数据传输，并使用测试设备对车辆外部无线通信通道数据进行抓包，检查通道是否采用完整性保护机制，判定车辆是否满足 11.4.3 的要求。若使用测试设备无法对车辆移动蜂窝通信的数据进行抓包，测试人员应根据企业提供的车辆移动蜂窝通信通道完整性保护证明文件，判定车辆是否满足 11.4.3 的要求。

d) 防非授权操作安全测试

测试人员应使用非授权身份通过车辆外部通信通道对车辆的数据依次进行超过访问控制机制的操作、清楚和写入，检查是否可操作、清除和写入数据，判定车辆是否满足 11.4.4 的要求。

e) 关键指令数据有效性或唯一性验证安全测试

测试人员应依据车辆制造商提供的关键指令数据列表，使用测试设备录制关键指令数据，重新发送录制的指令数据，检查车辆是否做出响应，判定车辆是否满足 11.4.5 的要求。

f) 敏感个人信息保密性安全测试

测试人员应依据车辆制造商提供的车辆向外传输敏感个人信息的功能清单，触发车辆向外传输敏感个人信息的功能，使用车辆制造商提供的端口和访问权限抓取传输的数据包，检查是否对车辆传输的敏感个人信息进行加密，判定车辆是否满足 11.4.6 的要求。

g) 敏感个人信息保密性安全测试

测试人员应依据车辆制造商提供的车辆向外传输敏感个人信息的功能清单，触发车辆向外传输敏感个人信息的功能，使用车辆制造商提供的端口和访问权限抓取传输的数据包，检查是否对车辆传输的敏感个人信息进行加密，判定车辆是否满足 11.4.6 的要求。

h) 防御物理操纵攻击安全测试

测试人员应依据车辆制造商提供的测试车辆与外部直接无线通信的零部件清单，使用和测试车辆与外部直接无线通信零部件型号相同但未授权的零部件替换安装在测试车辆相同的位置，启动车辆，检查零部件是否功能异常或车辆是否有异常部件连接告警，判定车辆是否满足 11.4.7 的要求。

i) 车辆与外部直接通信零部件防非授权特权访问安全测试

测试人员应依据车辆制造商提供的对外直接无线通信零部件系统权限设计方案，并按照以下两种测试方法中适用的测试方法开展测试，判定车辆是否满足 11.4.8 的要求：

• 若系统只存在特权访问的用户，测试是否能非授权登录进入系统；

• 若系统存在或配置多种权限用户，依据非特权用户登录系统方式进入系统，使用系统提权方法对非特权用户进行提权，测试进行提权操作后的用户是否进行特权访问。

j) 车内安全区域隔离安全测试

测试人员应依据车辆制造商提供的通信矩阵和访问控制列表样例，并按照以下两种测试方式中适用的测试方法开展测试，判定车辆是否满足 11.4.9 的要求：

• 若使用物理隔离措施，验证车辆制造商提供的物理隔离方案是否有效；
• 若使用逻辑隔离措施，依据车辆制造商提供的逻辑隔离策略，发送不符合策略的数据帧，在指定的目的端口，测试是否可接受到不符合策略的数据帧。

k) 拒绝服务攻击识别防护安全测试

测试人员应依据 12.4.1.b 的要求处置车辆，使车辆分别处于静止和运动状态，使用拒绝服务攻击测试设备依次攻击车辆移动蜂窝通信、 V2X 、 CAN 总线、车载以太网等通信通道，判定车辆是否满足 11.4.10 的要求。

l)  恶意数据识别安全测试

测试人员应依据 12.4.1.b 的要求处置车辆，向车辆发送当前车况非预期的恶意数据，判定车辆是否满足 11.4.11 的要求。

m)  通信信息安全日志安全测试

测试人员应依据车辆制造商提供的车辆关键通信信息安全事件日志记录机制及其存储路径，并按照以下测试方法依次开展测试，判定是否满足 11.4.12 的要求：

构建并触发车辆关键通信信息安全事件，检查是否按照关键通信信息安全事件日志记录机制记录该事件；

检查日志记录的时间跨度是否不少于 6 个月或是否具备留存日志不少于 6 个月的能力。

12.4.4 软件升级安全测试

a) 通用安全要求测试

1) 安全保护机制测试

测试人员应依据车辆制造商提供的车载软件升级系统的可信根、引导加载程序、系统固件的安全保护机制的安全证明文件，判定车辆是否满足 11.5.1.a 的要求。

2) 漏洞安全测试

测试人员应使用漏洞扫描工具对车载软件升级系统进行漏洞扫描，并将测试结果与汽车行业权威漏洞平台 6 个月前公布的高危及以上的安全漏洞清单和车辆制造商提供的车载软件升级系统漏洞处置方案进行比对，判定车辆是否满足 11.5.1.b 的要求。

b) 在线升级安全测试

1) 服务器身份认证安全测试

测试人员应依据车辆制造商提供的在线升级服务器清单及采用的通信协议类型，并按照以下三种测试方法中适用的测试方法开展测试，判定车辆是否满足 11.5.2.a 的要求。

• 若车辆与在线升级服务器采用专用网络或虚拟专用网络环境进行通信，测试人员应根据企业提供的在线升级服务器身份认证安全功能的证明文件，确认车辆是否满足 11.5.2.a 的要求。

• 若车辆与在线升级服务器采用公共网络环境进行通信，且使用公有通信协议，测试人员应使用测试设备进行数据抓包，解析通信报文数据，检查车辆是否对在线升级服务器进行身份真实性验证；中断下载并恢复，使用测试设备进行数据抓包，解析通信报文，检查是否重新进行身份真实性验证。若使用测试设备无法进行数据抓包，测试人员应根据企业提供的在线升级服务器身份认证安全功能的证明文件，确认车辆是否满足 11.5.2.a 的要求。

• 若车辆与在线升级服务器采用公共网络环境进行通信，且使用私有通信协议，测试人员应根据企业提供的在线升级服务器身份认证安全功能的证明文件，确认车辆是否满足 11.5.2.a 的要求。

2) 在线升级包真实性和完整性验证安全测试

测试人员应按照以下测试方法依次开展测试，判定车辆是否满足 11.5.2.b 的要求

• 使用车辆制造商提供的正常升级包触发在线升级，测试升级功能是否正常。

• 确认在线升级功能正常后，构造真实性和完整性被破坏的升级包，并依据车辆制造商提供的方法和权限，将真实性和完整性被破坏的升级包下载或传输到车端，执行软件升级，测试是否升级成功。若车辆的信息安全防护机制不支持将真实性和完整性被破坏的升级包下载或传输到车端，则依据车辆制造商提供的在线升级信息安全防护机制证明文件，检查车辆是否满足 11.5.2.b 的要求。

3) 在线升级信息安全事件日志安全测试

测试人员应按照以下测试方法依次开展测试判定是否满足 11.5.2.c 的要求：

• 构造升级安全事件，检查是否存在在线升级信息安全事件日志；

• 检查日志记录的时间跨度是否不少于 6 个月或是否具备留存日志不少于 6 个月的能力。

c) 离线升级安全测试

1) 使用车载软件升级系统的离线升级安全测试

测试人员应分别构造被伪造、被篡改的升级包，使用离线升级工具将该升级包下载或传输到车载端，执行离线升级，判定车辆是否满足 11.5.3.a 的要求。

2) 不使用车载软件升级系统的离线升级安全测试

测试人员应按照如下测试方法中适用的测试方法开展测试，判定车辆是否满足 11.5.3.b 的要求：

• 将非认证的刷写接入端接入车辆刷写接口并执行离线升级，测试车辆是否能够识别非认证的刷写接入端；

• 分别构造被伪造、被篡改的升级包，使用刷写接入端接入车辆刷写接口，执行离线升级，测试是否执行升级或升级是否成功。

12.4.5 数据安全测试

a) 密钥防非法获取和访问安全测试

测试人员应依据车辆密码使用方案，确认测试零部件，并按照如下三种测试方法中适用的测试方法开展测试，判定车辆是否满足 11.6.1 的要求。

• 若采取安全访问技术存储密钥，通过零部件访问接口进行破解、提取等攻击操作，测试是否可以对密钥非授权访问和获取；

• 若采取 HSM 等硬件安全模块存储密钥，应依据硬件安全模块安装位置说明文档，检查车辆是否在文档标识位置安装了硬件安全模块来保护密钥；

• 若采取安全的软件存储形式存储密钥，应依据车辆制造商提供的保证车辆密钥安全存储证明文件，检查是否安全存储密钥。

b) 敏感个人信息防泄漏安全测试

测试人员应依据敏感个人信息功能清单和存储地址清单，确认测试零部件，依次触发车辆记录敏感个人信息的功能，并按照以下测试方法依次开展测试，判定车辆是否满足 11.6.2 的要求：

• 若采用安全访问技术保护存储的敏感个人信息，依据敏感个人信息存储和地址范围说明，通过零部件调试接口，使用未添加访问控制权限的用户访问存储的敏感个人信息，测试是否能非授权访问敏感个人信息；；

• 若采取加密技术保护存储的敏感个人信息，依据敏感个人信息存储区域和地址范围说明，通过零部件调试接口，使用软件分析工具提取存储的敏感个人信息，测试是否为密文件存储；

• 依次触发车辆记录敏感个人信息的功能，然后依据系统登录方式进入系统，对测试零部件进行敏感个人信息检索，测试是否可检索出不在敏感个人信息功能清单和存储地址清单中存储的敏感个人信息。

c)  车辆身份识别数据防非授权删除和修改安全测试

测试人员应依据车辆内存储的 VIN 等用于车辆身份识别的数据清单及存储地址，确定测试零部件，使用软件分析工具非授权删除和修改存储在车辆内的 VIN 等用于车辆身份识别的数据，判定车辆是否满足 11.6.3 的要求。

d) 关键数据防非授权删除的修改安全测试

测试人员应依据车辆内存储的关键数据清单及存储地址，确定测试零部件，通过零部件调试接口，使用软件分析工具修改存储在车内的关键数据，判定车辆是否满足 11.6.4 的要求。

e) 日志文件防修改和非授权删除安全测试

测试人员应依据车辆内存储的安全日志清单及存储地址，确定测试零部件，并按照以下方法依次开展测试，判定车辆是否满足 11.6.5 的要求：

• 依据车辆内存储的安全日志清单及存储地址，通过零部件调试接口，修改安全日志文件，测试是否可修改安全日志文件；

• 依据车辆内储存的安全日志清单及存储地址，通过零部件调试接口，使用软件分析工具测试是否可非授权删除安全日志文件。

f) 个人信息清除功能测试方法

测试人员应使用测试车辆个人信息清除功能，确认测试零部件，依次触发车辆记录个人信息的功能，清楚车辆内存储的个人信息，依据车辆制造商提供的车辆内存储的个人信息清单及存储的地址，通过零部件调试接口检索，检查个人信息是否被完全删除，判定车辆是否满足 11.6.6 的要求。

g) 防数据直接出境测试方法

测试人员应开启车辆全部移动蜂窝通信通道和 WLAN 通信通道，依次模拟车辆处于未上电、仅上电、各项预装的数据传输功能正常启用的状态，并使用网络数据抓包工具对对外通信网络通道同时抓包，且总抓包时长不少于 3600s ，解析通信报文数据，检查目的 IP 地址中是否包含境外 IP 地址，判定车辆是否满足 11.6.7 的要求。

附录 A 网络安全文化的例子

本附录阐述了软件层面开发过程中基于模型的开发方法的可能收益和潜在问题。表 A.1 提供了薄弱和强大的网络安全文化的例子。

表 A.1   薄弱和强大的网络安全文化的例子

表明网络文化薄弱的例子	表明强大的网络安全文化的例子
与网络安全有关的决定的责任是无法追溯的。	该程序确保与网络安全有关的决定的责任是可追溯的。
性能（所实施的功能或特性）、成本或时间表优先于网络安全。	网络安保和安全具有最高优先权。
奖励制度偏向于成本和进度，而不是网络安全。	奖励制度支持和激励有效实现网络安全，并惩罚那些走捷径、危害网络安全的人。
网络安全人员不考虑项目 / 活动的具体需要，就强行对网络安全进行不适当的、非常严格的遵守。	网络安全人员作为榜样，具有良好的适当性和实际执行力，导致整个组织对其行动的信任。
评估网络安全及其管理程序的人员受到负责执行程序的人员的不当影响。	该程序提供了充分的制衡，例如，网络安全评估中适当的独立程度
对网络安全的被动态度，如： —— 严重依赖开发结束时的测试。 —— 没有为实地的潜在弱点或事件做好准备。 —— 只有在生产中、现场发生网络安全事件时，或者媒体对竞争对手的产品给予大量关注时，管理层才会做出反应。 ——“ 群体思维”的确认偏见（即不加批判地接受或顺应流行的观点）。 —— 在组建审查小组时，要“堆满甲板”（即选择成员以确保预期结果），以防止潜在的异议。 —— 异议者被排斥或被贴上“不是团队成员”的标签（如不合作、不妥协、有毒的人）。 —— 不同意见对绩效有负面的影响。 —— 少数民族的异议者被贴上“麻烦制造者”、“非团队成员”或“告密者”（即煽动者、不受欢迎者或告密者）的标签或被视为“麻烦制造者”。 —— 表达关切的员工害怕受到打击。	对网络安全采取积极主动的态度，如： —— 在产品生命周期的最早阶段就发现并解决网络安全问题（设计中的网络安全）。 —— 组织准备好对现场的漏洞或事件作出快速反应。 这个过程利用了多样性的优势 —— 在所有过程中寻求、重视和整合知识多样性。 —— 反对使用多样性的行为被阻止并受到惩罚。 支持沟通和决策的渠道是存在的，而且管理层鼓励使用这些渠道。 —— 鼓励自我披露。 —— 我们鼓励任何人（内部或外部）负责任地披露潜在地漏洞。 —— 发现和解决的过程在现场、在制造和在开发其他产品中继续进行。
没有系统的持续改进过程、学习周期或其他形式的经验总结。	持续改进是所有过程的组成部分。
流程是临时性的或隐形的。	遵循确定的、可追踪的和受控的流程。
没有为网络安全分配所需的资源	为网络安全分配所需的资源。 熟练的资源具有与分配的活动相称的能力。

附录 B 网络安全的相关性——方法和标准的例子

B.1 综述

本附录提供了确定一个项目或组件是否与网络安全有关的示例方法（见 8.3.1 ）。

B.2 方法

候选项目或组件的网络安全相关性可以通过图 B.1 中的决策图来确定，该图给出了示例标准。

图 B.1  网络安全相关性示例方法和标准

网络安全的相关性也可以根据经验和多个专家的判断来确定，例如，涉及安全专家和网络安全专家。

附录 C 网络安全接口协议模板的例子

C.1 综述

如果不同的组织参与了分布式网络安全活动，那么在不同的组织之间就责任、信息披露程度以及每个里程碑的实现程度达成一致是非常重要的。

本附录根据 9.4.1 提供了一个网络安全接口协议的示例模板。该模板对如何定义客户和供应商之间分布式网络安全活动的角色和责任提供了指导（图 C.1 ）。

其他信息也可以添加到模板中，如联络点、目标里程碑、合作的方法或工具。

C.2 示例模板

本例模板中的栏目条目是：

a) 阶段： 本文件的阶段。

b) 工作产品： 本文件中与分布式活动的接口有关的工作产品。

c) 文件编号： 本文件的相关条款。

d) 供应商： RASIC 的供应商责任。

e) 客户： 由 RASIC 负责的客户。

注 1 ： 本模板使用 RASIC 来展示组织间特定工作产品的责任分配。 RASIC 可按以下方式使用：

— R （ responsible ） : 负责开展该活动的组织

— A （ accountable ） : 活动完成后，有权批准该活动的组织

— S （ supporting ） : 将帮助负责该活动组织的组织

— I （ informed ） : 被告知活动进展和正在作出的任何决定的组织

— C （ consulted ） : 提供建议或指导的组织，但不积极从事该活动

f)  保密程度： 供应商和客户就每个工作成果的保密性达成一致；

注 2 ： 可能的保密级别可以是：

— 高度机密：只有创造工作成果的组织才被允许访问它

— 保密：客户和供应商都被允许访问工作成果

— 与第三方保密：根据 7.4 的规定，该工作成果允许与授权的外部各方共享

— 公开：工作成果可以不受任何限制地分享

g)  评论： 关于各组织之间谈判和讨论结果地补充信息。

图 C.1   网络安全接口协议模板的例子