GB／T 38628-2020 标准规范下载简介

GB／T 38628-2020 信息安全技术 汽车电子系统网络安全指南

示了硬件层面产品开发过程及其与系统层面产品

图6硬件层面产品开发过程

硬件层面网络安全需求宜从系统层面产品开发阶段分配给硬件的网络安全需求中导出，并在硬件 层面产品开发过程中进一步细化。组织需要进行硬件的漏洞分析以帮助识别潜在的漏洞和所需要的网 络安全控制措施，这些控制措施能够覆盖所识别出来的潜在漏洞。在硬件集成及其功能测试之后，可将 洞测试和渗透测试应用于硬件设计，并进行硬件层面网络安全需求的验证和评估，在此初始的网络安 全评估会被进一步细化

DB12／T 775-2018 防雷装置检测业务规范.3.2硬件层面产品开发

组织宜针对硬件层面产品开发启动网络安全活动，具体可包括： a）确定所有与硬件相关的网络安全需求，包括功能安全、隐私、财务、业务、法律和法规等方面； b）定义网络安全与硬件/软件和功能安全之间的关系； c）确定硬件网络安全测试和评估的范围

7.3.3硬件层面漏洞分析

组织宜开展硬件层面漏洞分析，以便识别、量化其网络安全风险，并进行优先级排序。 示例： 针对汽车电子系统硬件漏洞的具体分析方面可包括但不限于： a）ECU硬件本身是否存在设计上的缺陷或者漏洞，比如缺乏防信号干扰、防逆向分析等机制，导致其易受到相应 的攻击而信息泄露， b 用于调试的JTAG接口：是否在最终硬件产品中移除，如果未移除，是否采取了相应的访问控制措施（比如在非 调试状态下关闭该接口）。如果该接口被非法访问，可能导致恶意程序被植入系统 用于车辆诊断的OBD接口：是否对该接口采取了相应的访问控制措施。OBD接口如果被非法利用，非授权设 备可能通过未受保护的OBD总线与汽车网关通信，读取网关内的敏感数据，甚至直接读写车内总线，发送伪造 控制信息，严重干扰汽车正常功能 d）串口、USB以及各种无线通信接口：是否采取了相应的访问控制措施。未受保护的接口访问，可能导致访问者 身份被仿冒、数据泄露、访问数据被复改等风险

组织宜开展硬件层面漏洞分析，以便识别、量化其网络安全风险，并进行优先级排序。 示例： 针对汽车电子系统硬件漏洞的具体分析方面可包括但不限于： a）ECU硬件本身是否存在设计上的缺陷或者漏洞，比如缺乏防信号干扰、防逆向分析等机制，导致其易受到相应 的攻击而信息泄露 b）用于调试的JTAG接口：是否在最终硬件产品中移除，如果未移除，是否采取了相应的访问控制措施（比如在非 调试状态下关闭该接口）。如果该接口被非法访问，可能导致恶意程序被植入系统 C 用于车辆诊断的OBD接口：是否对该接口采取了相应的访问控制措施。OBD接口如果被非法利用，非授权设 备可能通过未受保护的OBD总线与汽车网关通信，读取网关内的敏感数据，甚至直接读写车内总线，发送伪造 控制信息，严重干扰汽车正常功能 d）串口、USB以及各种无线通信接口：是否采取了相应的访问控制措施。未受保护的接口访问，可能导致访问者 身份被仿冒、数据泄露、访问数据被算改等风险

GB/T 386282020

7.3.4确定网络安全需求

组织宜结合实际情况进一步确定硬件层面的网络安全需求，可包括如下内容： a）检查并根据需要更新系统上下文； b）明确硬件是如何支持整个系统所需要实现的网络安全目标和任务的； c）定义其他方面的约束，包括组织内部或外部的威胁、法律法规要求和成本约束等

组织宜对硬件层面的网络安全进行设计，满足设计层级安全要求，具体包括系统设计方案、硬件组 牛选型、安全组件、实施（如PCB布局）和配置安全漏洞（如调试端口安全配置）等，这些漏洞并非抓立存 在，而是相互影响的，因此硬件设计漏洞宜从系统层级综合考虑分析。 示例1： 为ECU硬件设计防信号干扰、防逆向分析等机制。 示例2： 用于调试的JTAG接口，在最终硬件产品中移除该接口，或者设计相应的访问控制措施（比如在非调试状态下关闭 该接口）。 5 示例3： 针对OBD接口，采取相应的访问控制措施，防止OBD接口被非法利用。 示例4： 针对串口、USB以及各种无线通信接口，根据各种接口的不同特点，设计相应的访问控制措施，保护对这些接口的 访。

7.3.6硬件集成和测试

组织宜对集成后的硬件进行网络安全测试，可包括： a）进行漏洞测试，以验证已知或潜在的漏洞是否已被修复； b）进行渗透测试，模拟攻击者绕过网络安全控制措施并取得系统控制权的行为，以验证硬件设计 是否可以抵御此类威胁； c）测试宜由具备相应资质的、独立的测评团队来进行

7.3.7网络安全验证

组织宜对硬件层面网络安全需求的有效性进行检验和验证，以确定硬件设计是否能产生符合需求 所预期的效果。该验证活动宜由独立的网络安全测评团队进行，

7.3.8细化网络安全评估

组织宜通过独立的网络安全测评团队开展本阶段细化的网络安全评估活动，主要评估先前的未决 问题，可包括以下步骤： a）评估未决问题是否已得到解决，如果尚未解决则进人下一步。 b 根据硬件层面产品开发的情况，决定是否接受该问题。如果接受，则需要提供解释性文件，说 明可以接受此网络安全问题的原因；如果不接受，则继续标识为未决问题，以便在后续的产品 开发过程中进行处理

.9硬件层面产品开发E

组织在硬件层面产品开发阶段最后宜通过独立的技术专家小组，参照6.5进行阶段检查。

7.4软件层面产品开发阶段

了软件层面产品开发过程及其与系统层面产品开

图7软件层面产品开发过程

软件层面网络安全需求宜从系统层面产品开发阶段分配给软件的网络安全需求中导出，并在软件 层面产品开发过程中进一步细化。软件架构设计之后，进行漏洞分析以帮助识别潜在的设计漏洞和所 需要的网络安全控制措施，这些控制措施能够覆盖所识别出来的潜在漏洞。在软件单元设计和实现之 后，还可以进行软件单元设计及实现层面的漏洞分析，之后进行软件单元测试、软件集成和网络安全测 试。为了验证软件的网络安全需求，可应用漏洞测试和渗透测试等方法。最后进行网络安全评估，之前 的网络安全评估会被进一步细化

7.4.2软件层面产品开发启动

7.4.3确定网络安全需求

组织宜结合实际情况进一步确定网络安全需求，具体可包括如下内容： a）检查并根据需要更新系统上下文； b）明确软件是如何支持整个系统所需要实现的网络安全目标和任务的

C）定义与网路安全箱关的生 d）定义软件开发其他方面的约束，包括 织内部或外部的威胁、法律法规要求和成本约束等

7.4.4软件架构设计

组织宜注重从安全方面考虑软件架构设计，可包括不限于如下内容： a 保持数据的机密性、完整性和可用性的设计； b 采用分区的软件架构和隔离技术保障软件层面的安全； c） 提供错误检测和错误恢复功能； d）提供日志和审计功能

7.4.5软件层面漏洞分析

7.4.6软件单元设计和实现

组织开展软件单元设计和实现过程可参考行业内的相关规范（如MISRAC、CERTC等建立软件 编程规范），网络安全方面可包括但不限于如下内容： a 对输入信息和数据进行有效性验证； b 使用安全的字符串，禁止对已过时或废弃的API的调用，禁止使用非安全的函数； C 禁止使用没有长度限制的字符串或数组，可能导致缓冲区溢出； d 使用静态和动态的代码分析方法识别可能存在的软件漏洞

7.4.7软件实现的分析与评估

组织在软件实现的分析与评估过程中，可开展的网络安全活动包括但不限于： a 对代码和数据结构进行分析，以便查找可能对系统造成或引入的漏洞和风险； b）评估可能由开发工具引人的风险； c）评估函数、类、模块等软件单元之间数据传输的一致性； d）分析第三方软件库的脆弱性

7.4.8软件单元测试

组织开展软件单元测试过程中宜遵循以下要求： a 从软件的最下层开始，对所有软件单元开展测试，包括测试软件的输入、输出、数据流/关键路 径、边界条件、错误处理、异常处理、故障和恢复处理等； b）考虑与安全有关的测试内容； C 一旦有软件单元未通过测试，则立即采取纠正措施，并在软件单元修改后进行回归测试，以确 保修改的软件单元不会对其他单元产生不利影响（包括安全方面的影响）

7.4.9软件集成和测试

GB/T38628—2020

软件集成完成后，组织宜检验相应的网络安全需求是否得到满足，包括如下内容： a 对所有的数据接入点（例如，无线接口、以太网接口、USB接口和CAN接口等）进行模糊测试； b 进行渗透测试和漏洞测试，可由独立的内部团队或外部第三方团队实施； C 记录测试结果和剩余风险； d）制定处理剩余风险的行动计划； e）编写软件的操作指南

7.4.10网络安全验证

7.4.11细化网络安全评估

问题，可包括以下步骤： a）评估未决问题是否已得到解决，如果尚未解决则进入下一步。 b）根据软件层面产品开发的情况，决定是否接受该问题。如果接受，则需要提供解释性文件，说 明可以接受此网络安全问题的原因；如果不接受，则继续标识为未决问题，以便在后续的产品 开发过程中进行处理

7.4.12软件层面产品开发阶段检查

组织在软件层面产品开发阶段最后宜通过独立的技术专家小组，参照6.5进行阶段检查

产品生产、运行和服务阶

7.5.1.1监测能力

7.5.1.2 分析评估

GB/T 386282020

8汽车电子系统网络安全支撑保障

配置管理工作可包括： a）确保产品开发过程中的工作环境受控，保证在产品的后续开发过程中，可重现产品开发的工作 环境； b） 使用配置管理系统或工具，保证产品的各个版本之间的差异和关系是可追溯的； c）审计并汇报系统的配置基线； d）在系统配置管理计划确定后，确保其生命周期各阶段的初始条件都得到满足

需求管理的目标是：确保需求符合系统特征和属性并被正确定义，并保证需求在生命周期各阶段的 致性。需求管理的具体内容可包括： a 维护各阶段的需求，包括更新系统用例，确保每项需求自身没有矛盾，每项需求与其他需求之 间没有冲突，确保没有重复的需求； b 创建测试过程，以确认需求得到满足； C 维护网络安全目标到其实现的可追溯性，以便对需求进行有效性检验和验证； d）确保需求属性和内容的清晰性（没有歧义、容易理解）、一致性、完整性、可实现性和可测试性。 18

需求管理的目标是：确保需求符合系统特征和属性并被正确定义，并保证需求在生命周期各阶段的 致性。需求管理的具体内容可包括： a 维护各阶段的需求，包括更新系统用例，确保每项需求自身没有矛盾，每项需求与其他需求之 间没有冲突，确保没有重复的需求； b） 创建测试过程，以确认需求得到满足； C 维护网络安全目标到其实现的可追溯性，以便对需求进行有效性检验和验证； d）确保需求属性和内容的清晰性（没有歧义、容易理解）、一致性、完整性、可实现性和可测试性。

变更管理的目标是：分析和控制系统或产品在生命周期过程中的变更情况，系统性地开展变更的计 划、变更的控制与监测、以及变更的实施等活动，并形成文档，执行变更的决策和责任分配。变更管理的 具体内容可包括： a）保存并维护系统或产品的变更日志，对于每一个修订版本，记录修订日期、修订原因（如果有的 话，还需附加变更请求的编号）、修改的细节描述等； b） 设置变更评审委员会，负责决定是否批准变更请求，并确保变更文档（包含变更请求者姓名、日 期、变更原因和变更细节）内容的准确性； C 在系统或产品的修订版发布之前，宜通过变更评审委员会的评审，包括对变更的影响进行分 析，制定变更实施计划（包括发布变更内容的方式），确定所有的参与者，分配各参与者的职责： 口 变更完成后，宜对受到变更影响的产品进行测试，以便确认变更所针对的问题已得到解决，以 及确认变更没有引入新的问题

文档管理的目标是：为系统的整个： 过程。组织需要制定文档的编制计划，确保文档在相应阶段的活动开展之前是可用的。下列类型的文 档可被纳人到文档管理策略中： a） 网络安全计划； b） 系统功能定义； c） 系统上下文； d) 威胁分析与风险评估文件； e 网络安全策略； f） 网络安全需求； 网络安全评估和网络安全状况说明

8.5.1供应商评估和选择的依据

组织在评估和选择供应商时，宜综合考虑供应商的产品开发能力及其在网络安全领域的专业水平 包括但不限于如下方面： a）供应商是否能提供证据，表明其具备开发网络安全相关产品的能力： b）供应商是否能提供证据，表明其具备良好定义的网络安全产品开发过程； c）供应商是否能提供证据，表明其具备相应的质量管理系统； d）供应商是否能提供证据，表 有能力为产品提供整个生命周期的网络安全支持

8.5.2开发交付协议

组织宜与供应商签订《开发交付协议》，以明确供应商对特定系统或产品项目的责任范围，并保证供 应商实现其所承诺的责任。《开发交付协议》可包括但不限于如下内容： a）确定供应商的网络安全负责人，该负责人宜监督所提供产品的开发过程，并成为组织的主要联 系人； b）明确供应商需要遵守的网络安全法律法规条款； SAG c）明确供应商可以接触的工作产品范围

GB/T 386282020

为具备联网功能的汽车电子系统提供后台服务的云服务商，宜按照GB/T31167一2014和 B/T31168一2014，结合具体服务项，部署完善相应安全措施，建立健全云服务的安全保障能力。相关 全措施包括但不限于： a）在云服务系统访问过程中使用身份认证机制； b）对于云服务系统中存储和处理的关键、敏感信息，如车辆ID、车辆状态信息、车辆配置信息、用 户信息、密钥等，宜根据这些信息的重要性及风险评估的结果，采取相适宜的安全防护措施（包 括但不限于安全存储、访问控制等），确保这些信息的数据安全（至少包括机密性、完整性和可 用性； C 对于接入云平台的移动终端、车辆端设备或其他关联终端设备，云服务系统宜提供安全防护支 持功能，包括密钥管理、身份认证管理、远程升级管理、终端应用软件管理、安全监测、入侵防 御、恶意代码防护等安全功能

与汽车电子系统进行通信与交互的终端设备或设施主要包括移动端、车辆端设备以及路边单元 等。对于这些终端设备或设施，也需要进行网络安全风险评估，并采取相适宜的安全防护措施，可包括 但不限于： a）移动终端及车辆端设备中的应用宜采用身份认证、敏感信息输人安全保护、代码防篡改、防逆 向、防重打包等防护技术进行安全加固 b） 对车体控制相关的重要数据进行安全存储和管理； 移动终端与云服务系统、车辆端设备以及路边单元之间，采取安全的接入方式，防止由外接终 端引人新的网络安全风险

■汽车电子系统资产概述

GB/T38628—2020

附录A （资料性附录） 汽车电子系统典型网络安全风险

A.2ECU典型网络安全风险

ECU主要面临的网络安全风险包括： a）ECU硬件（比如处理芯片）本身可能存在设计上的缺陷或者漏洞，比如缺乏防信号干扰、防逆 向分析等的机制，导致其易受到相应的攻击而信息泄露。 b ECU固件刷新：未受保护的固件刷写过程，可能导致ECU固件或其配置数据被篡改，给系统 带来较大的安全风险。 C CAN总线访问：ECU之间、ECU与传感器/执行器之间可通过CAN总线通信。由于CAN总 线的消息通信缺乏必要的加密、校验、认证和访问控制机制，面临通信消息泄露或篡改、拒绝服 务、重放攻击等一系列威胁，可能影响行车安全。 JTAG、串口等物理访问接口：如果被非法访同，可能导致恶意程序被植人系统，获取系统的IF 信息，最终可能导致非法数据进人CAN总线的情况。 e 受ECU硬件资源的限制及其工作时的实时性需求，一些传统的安全机制不适用或无法直接 部署到ECU上，导致ECU在遭受攻击时影响汽车正常的行驶功能，甚至造成严重的安全 威胁。 关键、敏感数据（如系统数据、配置数据等）在这些数据的存储、访问过程中，如果未采取加密

GB/T38628—2020

存储和访问控制等防护措施，则可能导致数据被套改或泄露。被套改的数据可能导致系统功 能偏离预期，甚至带来其他网络安全方面的隐患；系统数据、配置数据等的泄露则可能导致系 统的IP泄露。

A.3车载网关典型网络安全风险

车载网关主要面临的网络安全风险包括： a）关键、敏感数据（比如系统数据/配置数据等）：在这些数据的存储、访问过程中，如果未采取加 密存储和访同控制等防护措施，则可能导致数据被改或泄露。被复改的数据可能导致系统 功能偏离预期，甚至带来其他网络安全方面的隐患；配置数据/系统数据的泄露则可能导致系 统的IP泄露。 b）FOTA/SOTA：在网关固件（包括启动加载程序在内）或其他软件（比如网关操作系统）的更新 过程中，如果未对更新的过程进行安全防护，软件或数据的更新包有可能被改，导致设备无 法正常启动或正常执行其功能；如果引起信息泄露或是非法数据进入CAN总线，可能导致严 重的安全隐惠。 c） 软件资产如操作系统等，如果存在设计或实现上的漏洞或缺陷，则可能被利用。尤其如果操作 系统是源自传统计算机信息系统的操作系统，则面临各种已知漏洞的威胁，更易于被攻击者利 用：攻击者通过安装未知应用程序或植入恶意软件，窃取各类数据，甚至可能将风险传导至车 体控制系统，对驾驶安全造成隐患。 d）与CAN总线、以太网等的通信：由于CAN总线、以太网等的消息通信缺乏必要的加密、校验 认证和访向控制机制，面临通信消息泄露或纂改、拒绝服务、重放攻击等一系列威胁，可能影响 行车安全。 e）JTAG、串口等物理访问接口：如果被非法访问，可能导致恶意程序被植人系统，获取系统的IP 信息，最终可能导致非法数据进人CAN总线的情况。 ） OBD接口：OBD接口如果被非法利用，非授权设备通过未保护的OBD总线与网关通信，读取 网关内的敏感数据，甚至直接读写车内总线，发送伪造控制信息，严重干扰汽车正常功能。 g 网关域隔离、防火墙/过滤器、入侵行为集中式检测（IDS）：如果没有进行域隔离防火墙/过滤 器、人侵行为集中式检测（IDS），非法的信息将进人车内网络，给相应的ECU发送危害报文， 可能影响行车安全

A.4车载接入设备典型网络安全风险

GB/T38628—2020

GB/T 386282020

附 录B （资料性附录） 汽车电子系统网络安全防护措施示例

本附录王要从技术的角度，对现 统网路安全的防护增施提供部分示例，主要从 边界安全防护、访问控制、安全软件选择与管理、身份认证、远程访问安全、数据安全等不同的方面进行 说明，可供组织在进行汽车电子系统网络安全相关设计开发时参考

T／CMSA 0012-2019 爆炸和火灾危险场所雷电监测预警技术要求B.4安全软件选择与管理

本项要求包括： a）基于风险评估结果以及车辆端设备在资源、性能方面的约束，选择相适宜的安全措施，比如安 全启动、安全升级、安全通信、安全存储、安全监测、人侵防御、恶意代码防护等。 b 对车辆端设备上的应用软件，可采取非授权软件安装防护、授权软件卸载防护、授权软件改 防护等安全措施；车辆端设备应用软件宜采用身份认证、敏感数据安全存储、安全传输等防护 措施。 C） 可采用远程软件升级的方法，对车辆端设备进行功能更新或漏洞修复，包括车辆端设备固件升 级、操作系统升级、应用软件升级或配置参数更新等。如需进行远程软件升级，升级过程需在 具有系统安全的条件下进行，具备通信安全（如真实性、完整性、保密性等），以及异常检测、响 应的能力，并且升级过程需记录完整的日志信息

GB/T38628—2020

本项要求包括： a）在对车辆进行远程/近程控制、移动终端应用登录、云服务系统访问等过程中使用身份认证机 制。在关键业务场景下（如远程升级、远程控制等），可采用多因素认证方式（如组合采用静态 密码验证、动态密码验证、基于密钥的认证、生物特征识别等两种或两种以上认证方式）。 D 保障车辆端设备及访问点等的登录账户及口令的安全，可在设备初次启动使用时要求用户更 改默认口令，避免使用弱口令，并采用定期更新口令的机制。 在汽车电子系统与云服务系统、移动终端、路边单元之间的通信过程中使用身份认证机制

本项要求包括： a）车辆端设备需对提供远程访问的服务端口进行严格控制，关闭不必要的端口。 b）确需远程访问的关键业务场景（如远程升级、远程控制等），采用安全通信，可对访问时限进行 控制，并采用身份认证、数据安全传输、访问控制等机制。 保留对汽车电子系统的相关访问日志，以便后续对操作过程进行安全审计

本项要求包括： a）车辆端设备需对提供远程访问的服务端口进行严格控制，关闭不必要的端口。 b）确需远程访问的关键业务场景（如远程升级、远程控制等），采用安全通信，可对访问时限送 控制，并采用身份认证、数据安全传输、访问控制等机制。 c）保留对汽车电子系统的相关访问日志，以便后续对操作过程进行安全审计

本项要求包括： a）对在汽车电子系统中采集、存储并传输至云服务系统或移动终端的数据，定期开展风险评估和 安全检测。 D 关键业务数据和用户信息须在存储和传输过程中使用安全机制（如加密、防篡改等），并在使用 过程中采用适宜的访问控制策略

GB/T38628—2020

GBT 13477.8-2017建筑密封材料试验方法 第8部分：拉伸粘结性的测定GB/T38628—2020