ChinaAutoRegs｜GB/T 38628-2020英文版/English/翻译/信息安全技术 汽车电子系统网络安全指南
Information security technology—Cybersecurity guide for automotive electronics systems

CONTENTS

Foreword II
1 Scope 1
2 Normative References 1
3 Terms and Definitions 1
4 Abbreviations 2
5 Cybersecurity Activity Framework of Automotive Electronics Systems 2
6 Cybersecurity Organization Management of Automotive Electronics Systems 5
7 Cybersecurity Activity of Automotive Electronics Systems 9
8 Cybersecurity Support Guarantee of Automotive Electronics Systems 20
Annex A (Informative) Typical Cybersecurity Risks of Automotive Electronics Systems 24
Annex B (Informative) Examples of Protective Measures for Cybersecurity of Automotive Electronics Systems 27
Annex C (Informative) Example of Incident Handling Checklist 29
Bibliography 30

1 范围
本标准给出了汽车电子系统网络安全活动框架，以及在此框架下的汽车电子系统网络安全活动、组织管理和支撑保降等方面的建议。
本标准适用于指导整车厂、零部件供应商、软件供应商、芯片供应商以及各种服务提供商等汽车电子供应链上各组织机构开珉网络安全活动，指导相关人员在从亊汽车电子系统的设计开发、生产、运行 和服务等过程中满足基本的网络安全需求。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 18336-2015(所有部分）信息技术安全技术信息技术安全评估准则
GB/T 20984-2007 信息安全技术信息安全风险评估规范
GB/T 29246-2017 信息技术安全技术信息安全管理体系概述和词汇
GB/T 30279-2013 信息安全技术安全漏洞等级划分指南
GB/T 31167-2014 信息安全技术云计算服务安全指南
GB/T 31168-2014 信息安全技术云计算服务安全能力要求
GB/T 31509-2015 信息安全技术信息安全风险评估实施指南
GB/T 31722-2015 信息技术安全技术信息安全风险管理
3术语和定义
GB/T 29246—2017界定的以及下列术语和定义适用于本文件。
3.1
汽车电子系统 automotive electronics systems
在汽车中通过电子技术实现控制或服务的系统，是一类应用于汽车领域的嵌人式系统，包含车体控 制电子系统和车载服务电子系统。
注1:车体控制电子系统与车上机械系统配合使用，包括发动机控制系统、底盘控制系统、车身电子控W系统等，
注2:车载脤务电子系统能够独立于汽车环境使用•包括车载佰息娱乐系统及个人设备交互佰息系统等，
3.2
未决问题 pending question
在进行安全性评估时，现有网络安全控制措施不能降低或不确定能够降低的网络安全威胁，以及需要在后续过程中进一步分析和处理的问题。
3.3
系统上下文 system context
定义系统软硬件接口、关键数据流、存储和信息处理等内容的集合。
3.4
攻击树分析 attack tree analysis
由系统应用层出发，分析攻击者可能进行的攻击路径的方法 。
3.5
信息物理系统 cyber-physical system
由计算部件和物理控制部件组成的系统 。
3.6
信息物理车辆系统 cyber-physical vehicle system
在系统的计算部件和物理部件以及系统周围环境之间存在紧密搞合的车辆嵌入式控制系统 。
3.7
网络安全状况说明 cybersecurity statement
在所有的阶段检查完成后，在产品即将正式发布的生产环节之前进行的网络安全评估 ，为每一个设计和开发的特性提供其满足网络安全目标的结论与证据 。
3.8
网络安全目标 cybersecurity goal
从威胁分析和风险评估结果中获得的，针对某系统功能特性需要达到的网络安全目 标。
注 2 网络安全目标是最高抽象层次的安全需求 ，在产品的开发阶段将会以它（们〉为基础导出具体功能的和技术的 网络安全需求 。
3.9
信任边界 trust boundary
程序的数据或执行流的“信任”级别发生改变的边界 。
注 z 一个执行流的信任边界可以是在一个应用的权限被提升的地方 。

4 缩略语

下列缩略语适用于本文件 。
CAN ：控制域网络（Control Area Network)
ECU ：电子控制单元（Electronic Control Unit)
FOTA ：固件空中下载（Firmware Over The Air)
IVI ：车载信息娱乐系统 (In-Vehicle Infotainment)
JTAG ：联合测试访问组 (Joint Test Access Group)
MISRA ：汽车工业软件可靠性协会（ Motor Industry Software Reliability Association)
OBD ：车载诊断系统（ On-Board Diagnostic)
SIM ：用户身份模块（ Subscriber Identity Module)
SOTA ：软件空中下载（Sof tware Over The Air)
T-BOX ：智能网联汽车的通信网关（ Telematics BOX)
USB ：通用串行总线（ Universal Serial Bus)
V2X ：车对车 、车对外界的信息交换（Vehicle to Everything)

5 汽车电子系统网络安全活动框架

5.1 概述

汽车电子系统网络安全活动框架如图 1所示，包含汽车电子系统网络安全活动 、组织管理以及支撑保障，其中网络安全活动是框架的核心 ，主要是指在汽车电子系统生命周期各阶段开展的相关安全活 动，这些阶段包括概念设计阶段 ，系统层面的产品开发阶段 ，硬件层面的产品开发阶段 ，软件层面的产品 开发阶段，产品生产 、运行和服务阶段 。
组织可以根据自身实际情况 ，对网络安全活动框架中各部分进行配置和裁剪 ，并考虑与组织现有的 管理体系（比如质量管理体系）的机构设置 、过程活动进行结合 ，以便落实本标准所建议的网络安全措 施，以较小的代价实现高效的安全 。
5.2 组织管理
组织管理是指开展汽车电子系统网络安全活动所需要具备的组织 、人员能力 、制度等方面的条件 ， 主要包括组织机构设置 、建立沟通协调平台 、制度建设与员工培训 、建立网络安全测试与评估 、阶段检查 能力等。
5.3 网络安全活动

5.3.1 概念设计阶段

概念设计阶段主要包括系统功能定义 、网络安全过程启动 、威胁分析及风险评估 、网络安全目标确 定、网络安全策略设计 、网络安全需求识别 、初始网络安全评估 、阶段检查等环节的活动 。
5.3.2 产品开发阶段

产品开发阶段包括系统层面产品开发阶段 、硬件层面产品开发阶段和软件层面产品开发阶段。 图 2展示了产品开发阶段的基本过程 ，以及系统层面、硬件层面和软件层面产品开发之间的关系 。图 2 没有包含迭代过程，但实际上许多阶段都需要反复迭代 ，才能最终实现开发目标 。
系统层面产品开发阶段主要包括系统层面产品开发启动 、网络安全技术需求规格（包括系统层面漏 洞分析 、网络安全策略具体化 、确定网络安全技术需求等〉 、系统设计 、系统功能集成和网络安全测试 、网 络安全验证 、网络安全评估和检查以及产品发布等环节的工作 。
硬件层面产品开发阶段主要包括硬件产品开发启动 、硬件网络安全需求规格（包括硬件层面漏洞分 析、确定网络安全需求〉 、硬件设计 、硬件集成和网络安全测试 、硬件网络安全需求验证 、细化网络安全评 估等环节 。
软件层面产品开发阶段主要包括软件产品开发启动 、软件网络安全需求规格（包括软件层面漏洞分 析 、确定网络安全需求） 、软件架构设计 、软件单元设计与实现 、软件单元测试 、软件集成和网络安全测 试、软件网络安全需求验证 、细化网络安全评估等环节 。
在产品开发阶段需要用到密码技术时需要符合国家密码管理相关规定 。
注 1 ：图中双向箭头线表示对应或一致性关系 ，比如“系统设计”和“系统功能集成和网络安全测试”之间的双向箭 头线表示，系统的功能集成和网络安全测试以与系统设计相一致的方式进行，集成和测试的内容 、顺序以及 具体方式等以系统设计为依据 。
注 2 ：图中单向箭头线表示过程活动之间的顺序关系。箭头左边的活动在前面执行，箭头右边的活动在后面执行 。

圈 2 系统层面 、硬件层面与软件层面产晶开发的关系

5.3.3 产晶生产 、运行与服务阶段

产品生产 、运行与服务阶段主要包括现场监测 、事件响应和后续相关的事件跟踪管理等活动 。

5.4 支撑保障

汽车电子系统网络安全支撑保障主要包括配置管理 、需求管理、变更管理 、文档管理 、供应链管理 、 云管端安全等方面的内容。

6 汽车电子系统网络安全组织管理

6. 1 组织机构设置

组织需高度重视网络安全 ，把网络安全放在组织的战略层面进行考虑 ，并具体通过如下方面体现:
a) 制定和实施组织的网络安全战略 、方针和目标 ；
b) 落实网络安全的领导责任制 ，可建立有组织高层领导负责的网络安全领导小组 ，负责网络安全战略、方针和目标的制定和实施监督，并协调各部门之间的配合协作 ；
c) 设置专门的机构，负责有关网络安全方面的文化建设 、信息沟通 、培训＂、跨部门资源调配以及其 他相关工作 p
d) 员工能够清楚地知道组织内部与网络安全相关的机构设置及职责分工 。

6.2 建立沟通协调平台
组织宜建立有关网络安全的内 部及外部信息沟通协调渠道 ，包括但不限于以下方面 ：
a) 制定组织内部或外部的个人或组织报告突发网络安全事件的流程 ，明确组织内相关各部门之 间的衔接方式及应承担的责任 ；
b) 制定组织向相关方通报有关网络安全事件的流程 ，对事件的严重性程度进行分级管理 ；
c) 制定响应和处理来自政府 、媒体、公众和组织内部的有关网络安全事件的处理流程 。
6.3 制度建设与员工培训
组织宜将网络安全制度作为组织建设的重要内容 ，创建 、培养和维持组织的网络安全文化 ，以增强 员工的网络安全意识能力 。可具体从如下方面开展组织工作 ：
a) 编制有关网络安全的制度或过程文件 ；
b) 收集 、积累和传播网络安全相关的实践经验 、网络安全漏洞的解决方案和相关产品的应用案 例，包括与汽车电子领域相关的网络安全内容 ；
c) 密切关注国际国内在网络安全方面的最新进展情况 ，包括汽车电子领域重大安全漏洞的情况 z
d) 及时响应网络安全相关事件 ，优先处理风险程度高的网络安全威胁 z
e) 制定培训计划，定期组织有关网络安全的培训活动 ，通过培训提升员工的网络安全意识和能 力，使得员工能够理解在产品的开发 、生产 、运行和服务中可能出现的各种网络安全漏洞和威 胁，掌握威胁分析和风险评估的流程与方法 。
6.4 测试与评估

6.4.1 网络安全测评团队

网络安全测试与评估工作宜由有经验的 、有公正性的测评团队完成 。具体条件可包括 ：
a) 测评团队与被测评对象的开发 、生产、运行和服务以及网络安全控制措施的设计没有任何利益 冲突 ；
b) 测评团队与被测评组织没有建立利益关系或产生利益冲突 z
c) 测评团队不宜测评自己的工作 p
d) 测评团队不宜是被测评组织的员工 z
e) 测评团队不宜诱导组织使用自己的服务 ；
f) 测评团队宜将测评结果详细记录在案 ，包括找到的新漏洞 。
注 ：这里主要是针对组织聘请第三方测评团队的建议要求，组织自建测评团队的情况可以参考 。

6.4.2 网络安全测试内容

漏洞测试 、渗透测试和模糊测试是评价一个对象网络安全能力的重要方法 。其中，漏洞测试是较为 常用的方法，可包含但不限于如下具体方式 z
a) 漏洞扫描，检测对象是否存在可能被攻击的漏洞 z
b) 探测性测试，检测和探查可能在软件或硬件实现中产生的漏洞 ；
c) 攻击性测试，通过破坏 、绕过 、篡改网络安全控制措施等手段入侵对象 ，以达到测试对象抗攻击能力的目的。

6.4.3 网络安全评估

网络安全评估用于检验当前所实施的网络安全策略是否满足网络安全需求 ，以及是否能有效降低 威胁和风险，可包括但不限于以下内容 ：
a) 评估各阶段的网络安全策略是否满足网络安全需求 ；
b) 评估各阶段的网络安全设计是否符合网络安全策略 ；
c) 对于网络安全策略未能解决的威胁 ，将其定义为相应的未决问题 ，并评估该未决问题是否可以 被接受 p
d) 如果未决问题可被接受，则提供相应的说明，解释该网络安全问题可以被接受的原因；如果未 决问题不可被接受，并且可以通过后续阶段的活动解决 ，则记录该未决问题 ，以便将其作为下 一阶段开发的依据 。
6.5 阶段检查

在生命周期的每个阶段结束前宜进行阶段检查 ，以确保在下一阶段开始之前已经正确 、一致地执行 完成了当前阶段的活动 。
阶段检查可由组织的技术专家小组来进行 ，该小组宜独立于产品开发团队 。此外 ，为了保持产品在 整个生命周期中所有功能的一致性和完整性 ，该小组宜参与产品整个开发过程中的所有检查工作 。检 查结果以“通过川有条件通过”（即需要采取一些整改措施）或“不通过”表示 ，只有当检查结果是“通过” 或“有条件通过”并且相关整改措施已实施和确认的情况下 ，才能进入到下一阶段的工作 。各阶段检查 的主要内容如图 3 所示 ，具体内容见各阶段对应章节 。
注 ：在进入生产和运行阶段后，也可根据需要开展阶段检查活动 ，进一步确保安全措施执行到位 。
7 汽车电子系统网络安全活动

7.1 概念设计阶段

7. 1.1 概述

概念设计阶段的活动流程如图 4 所示，包括系统功能定义 、网络安全过程启动 、风险评估与目标确 定、网络安全策略设计 、网络安全需求识别、初始网络安全评估及概念设计阶段检查等 。
7.1.2 系统功能定义

组织宜明确汽车电子系统中被开发的 、可以实施网络安全的子系统及其功能的适用范围 ，并对其进 行如下内容的分析 ：
a) 子系统的物理边界 ；
b) 子系统的网络边界 z
c) 子系统的信任边界 ；
d) 子系统的网络安全边界 。

7.1.3 网络安全过程启动

在启动汽车电子系统的网络安全生命周期过程时 ，组织宜制定相应的网络安全计划 ，包括但不限于 以下内容 z
a) 需要执行的网络安全活动 z
b) 确定各项活动的负责人 ；
c) 明确各项活动的开始时间和截止时间 z
d) 明确各项活动状态的报告和监督规则 。

7.1.4 威胁分析及凤险评估

组织宜对汽车电子系统开展威胁分析及风险评估 ，以便系统性地识别汽车电子系统可能面临的网 络安全威胁，并对网络安全风险进行合理的估算 ，为确定汽车电子系统的网络安全目标 、采取相应的风 险处置措施提供依据 。掌握威胁分析及风险评估的技术 ，在产品的早期开发阶段实施 ，能够尽量降低在 产品生命周期较晚阶段发现问题而导致的昂贵修复代价 ；另外 ，随着产品开发过程的不断深入 ，威胁分 析及风险评估活动还可以适时地针对产品的逐步细化而不断地迭代 ，为产品各开发阶段的网络安全评 估提供依据 。
汽车电 子系统的威胁分析及风 险评估活 动宜按照 GB/T 18336-2015 、GB/T 20984-2007 、 GB/T 31509-2015 和 GB/T 31722-2015 等标准内容，并结合汽车行业的实践经验开展 ，主要可包括 以下步骤z
a) 准备 z 确定威胁分析及风险评估的目标与范围 。
b) 功能定义：识别汽车电子系统主要功能和需要被保护的资产 。
示例 1 : 汽车电子系统需要保护的资产可主要从以下方面考虑 ：
一一车载设备 z 包括 ECU 、传感器 、执行器 、网络通信设备等 ;
←一运行于在设备上的功能安全关键和非功能安全关键的应用 ；
ECU 内部、ECU 之间 、ECU 和传感器／执行器之间 、ECU 和网络通信设备及应用程序之间的数据链路 。
c) 威胁分析 ：识别来自组织外部或内部各种渠道的 、针对汽车电子系统资产的潜在威胁并进行分 析，可包括如下内容：威胁模型 、系统功能用例分析 、数据流／控制流分析 、安全边界分析 、攻击 树分析等 。组织可综合应用各种分析技术 ，形成规范化的分析流程 。在威胁分析过程中，需要 综合考虑威胁来源 、威胁动机（或攻击动机〉等因素 ，对威胁进行合理的分类 。
示f§IJ 2:
针对汽车电子系统的攻击动机可能是 z 获取车辆信息：获取驾驶员信息 F 对驾驶员 、乘客等个人身体和精神造 成伤害 E 扰乱行业经济或造成大规模基础设施损坏；恐怖袭击；使攻击者获得声誉；获取经济利益 E 获取其他利益 ，
注 1 ：一种常用的分类方法是将威胁分为仿冒 、篡改 、抵赖 、信息泄露 、拒绝服务 、特权提升等几种类型 。
d) 脆弱性分析：分析针对汽车电子系统资产可能的攻击途径和漏洞 ，其目标是基于汽车电子系统 的具体实现 ，识别其中的薄弱环节或缺陷 ，以便对风险评估提供依据 。可参考通用的信息系统 脆弱性数据库，针对已发现的脆弱性，对汽车电子系统的实现进行分析或开展渗透测试 ，检验 相关脆弱性是否真的存在 。另外，组织还需要建立或参考本行业相关机构所建立的专业性脆 弱性（或漏洞）数据库 ，以便针对汽车电子系统进行特定的脆弱性分析 。
e) 风险评估 z 基于威胁和脆弱性分析的结果 ，主要从两个方面对风险等级进行估算 z 一是威胁可 能造成影响的严重程度，二是威胁成功实施攻击的概率 。综合这两方面的评估数据，对每个具 体的资产威胁 ，明确其风险等级。
注 2 ：有关汽车电子系统典型网络安全风险参见附录 A.
注 3 ：对于威胁可能造成结果的严重程度，可从对汽车的功能安全 、隐私、经济 、操控性等方面的影响进行综合 分析；对于威胁成功实施攻击的概率，可综合考虑多方面因素，包括攻击所需要花费的时间（包括识别漏 洞 、开发攻击程序 、成功安装程序等的时间） 、专业知识 、对被攻击对象的了解程度 、机会的时间窗口和对 特殊设备的要求等 。
f) 风险处置 z 根据风险等级对资产威胁进行优先级排序 ，尤其需要识别出高风险等级的威胁 ，并
评估各个资产威胁的风险等级是否处于可接受的水平 d日果风险等级属于不可接受的，宜考虑 应用适当的方法或风险控制措施（具体措施参见附录 白，使系统的残余风险降低到可接受的 范围。

示例 3:
针对附录 A 中所描述的 ECU
CAN 总线的安全通信功能（软件〉，实现通信数据的防篡改 、抗重放机制 ．
示例 4 :
针对附录 A 中所描述的车载网关“FOTA/SOTA”可能面临的网络安全风险，可采取的风险控制措施是实现 安全的 FOTA/SOTA 过程，防止车载网关固件 ／软件或数据在其更新过程中被仿胃 、篡改或信息泄露 。
示例 5:
针对附录 A 中所描述的车载接入设备 USB 接口可能被非授权访问的网络安全风险 ，可采取的风险控制措施 是对 USB 接口实施安全访问控制，并通过安全日志对访问事件进行记录 ，以便及时发现可能出现的非授权访问 。
7.1.5 网络安全目标确定 组织宜基于风险评估结果中识别的高风险威胁尤其是最高风险威胁来确定网络安全目标 。
示例 1 :
针对车辆与外部环境的 4G 通信，攻击者可能会嗅探 4G 信号中的数据流，这将影响车辆外部通信数据的机密性 ，可 能导致敏感信息的泄露 。因此，相应的网络安全目标是保证车辆外部 4G 通信数据的机密性，需要采取加密通信数据的 措施 。
示倒 2:
攻击者基于读取的 4G 通信数据信息，可能攻击车辆系统的其他部分 ，比如篡改发送给车内网关的远程控制指令 ， 导致更为严重的安全事故 。相比前一种情况，该威胁的风险程度更高，相应的网络安全目标则是防止车辆的远程控制指 令被篡改，保证数据的完整性，需要采取的措施是针对关键数据信息进行完整性校验 。
7.1.6 网络安全策略设计 组织宜确定满足网络安全目标所需的策略 ，包括但不限于 z
a) 每个网络安全目标所对应的风险 ；
b) 满足网络安全目标的 、可行的策略 ；
c) 针对不同类别的威胁，制定网络安全策略设计说明 。

7.1.7 网络安全需求识别

组织宜从确定的网络安全目标中提取和识别网络安全需求 ，或者通过对网络安全策略的细化定义 具体的网络安全需求 。
7.1.8 初始网络安全评估

组织宜开展初始网络安全评估 ，主要用于描述当前阶段系统功能对于网络安全的各项要求 ，形成的 初始评估报告内容可包括但不限于 1
a) 通过风险评估所确定的所有网络安全目标 z
b) 每个网络安全目标所对应的风险 z
在当前阶段的所有网络安全未决问 题。

7.1.9 概念设计阶段检查

组织宜在概念设计阶段活动完成时进行阶段检查 ，以确保概念阶段所有活动均已完成并产生适宜 的输出，主要检查以下内容 z
a) 网络安全计划 ；
b) 系统功能定义 3
c) 风险评估结果 ；
d) 网络安全目标；
e) 网络安全策略设计;
f) 网络安全需求 ；
g) 初始网络安全评估结论 。

***********************************************
现成译文，到款即发。
任取样页验证译文质量。
免费提供正规增值税发票。
提供WORD/PDF版本，可自行编辑！
请联系 手机/微信: 133-0649-6964/Email: standardtrans@foxmail.com/QQ: 564965870 购买完整译文。
专业源于专注|舍吾予言标准翻译[ChinaAutoRegs]深耕于机动车标准翻译！迄今为止已翻译上千个国内外汽车法规标准！独家打造千万级汽车专业术语库和记忆库。