《汽车整车信息安全技术要求》（征求意见稿）5.5

ICS43.020 CCST40 中华人民共和国国家标准 GBXXXXX—XXXX 汽车整车信息安全技术要求 Technicalrequirementsforvehiclecybersecurity (点击此处添加与国际标准一致性程度的标识) （征求意见稿） 在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。 XXXX-XX-XX发布XXXX-XX-XX实施 GBXXXXX—XXXX 目次 前言II 1范围1 2规范性引用文件1 3术语和定义1 4缩略语2 5信息安全管理体系要求2 6车辆信息安全一般要求3 7车辆外部连接安全要求4 8车辆通信安全要求4 9车辆软件升级安全要求5 10车辆数据代码安全要求6 11审核评估及测试方法6 12车辆型式的变更和扩展6 13实施日期7 附录A（规范性）车辆信息安全要求测试验证方法8 I GBXXXXX—XXXX 前言 本文件按照GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由中华人民共和国工业和信息化部提出并归口。 II 汽车整车信息安全技术要求 1范围 本文件规定了汽车信息安全管理体系要求、车辆信息安全一般要求、车辆信息安全技术要求、审核评估及测试验证方法。 本文件适用于M类、N类及至少装有1个电子控制单元的O类车辆，其他类型车辆可参考执行。 2规范性引用文件 本文件没有规范性引用文件。 3术语和定义 下列术语和定义适用于本文件。 3.1 汽车信息安全管理体系cybersecuritymanagementsystem网络安全管理体系cybersecuritymanagementsystem 一种基于风险的系统方法，包括组织流程、责任和治理，以处理与车辆网络威胁相关的风险并保 护车辆免受网络攻击。 [来源：GB/Txxxxx智能网联汽车术语和定义] 3.2 开发阶段developmentphase 车型获得批准之前的时期。 3.3 生产阶段productionphase 车型生产持续的时期。 3.4 后生产阶段post-productionphase 从车型不再生产，直至该车型的所有车辆使用寿命结束的时期。在这一阶段，该车型的车辆仍可 使用，但不再继续生产，当该车型不再有可使用的车辆时，此阶段结束。 3.5 风险risk 车辆信息安全不确定性的影响，可用攻击可行性和影响表示。 3.6 风险评估riskassessment 1 发现、识别和描述风险，理解风险的性质以及确定风险级别，并将风险分析的结果与风险标准进行比较，以确定风险是否可接受。 3.7 威胁threat 可能导致系统、组织或个人受到伤害的意外事件的潜在原因。 3.8 漏洞vulnerability 在资产或缓解措施中，可被一个或多个威胁利用的弱点。 3.9 车载软件升级系统on-boardsoftwareupdatesystem 安装在车端并具备升级包接收、校验和分发等功能的软件和硬件。 3.10 在线升级over-the-airupdate 通过无线方式而不是使用电缆或其他本地连接进行数据传输的软件升级。 3.11 离线升级offlineupdate 除在线升级以外的软件升级。 3.12 敏感个人信息sensitivepersonalinformation 一旦泄露或者非法使用，可能导致车主、驾驶人、乘车人、车外人员等受到歧视或者人身、财产安全受到严重危害的个人信息，包括车辆行踪轨迹、音频、视频、图像和生物识别特征等信息。 [来源：汽车数据安全管理若干规定（试行），第三条] 4缩略语 下列缩略语适用于本文件。下列缩略语适用于本文件。CAN：控制器局域网络（ControlAreaNetwork） ECU：电子控制单元（ElectronicControlUnit）HSM：硬件安全模块（HardwareSecureModule） MD5：MD5信息摘要算法(MD5Message-DigestAlgorithm)NFC：近距离无线通讯技术(NearFieldCommunication)TLS：安全传输层协议(TransportLayerSecurity) USB：通用串行总线(UniversalSerialBus) VLAN：虚拟局域网（VirtualLocalAreaNetwork）VIN：车辆识别代号（VehicleIdentificationNumber）WLAN：无线局域网(WirelessLocalAreaNetworks) 5汽车信息安全管理体系要求 2 5.1车辆生产企业应建立车辆全生命周期的汽车信息安全管理体系。 注：车辆全生命周期包括车辆的开发阶段、生产阶段及后生产阶段。 5.2汽车信息安全管理体系中应涵盖必要流程，以确保充分考虑安全风险。 5.2.1应建立企业内部管理信息安全的流程。 5.2.2应建立识别、评估、分类、处置车辆信息安全风险及核实已识别风险得到适当处置的流程，并确保车辆风险评估保持最新状态。 5.2.3应建立用于车辆信息安全测试的流程。 5.2.4应建立针对车辆的网络攻击、网络威胁和漏洞的监测、响应及上报流程，要求如下： a)应包含漏洞管理机制，明确漏洞收集、分析、报告、处置、发布等活动环节； b)应建立针对网络攻击提供相关数据并进行分析的流程； 示例：企业具备从车辆数据和车辆日志中分析和检测网络攻击、网络威胁和漏洞的能力。 c)应建立确保已识别的网络攻击、网络威胁和漏洞得到响应，且在合理的时限内得到处置及上报的流程； d)应建立评估所实施的信息安全措施在发现新的网络攻击、网络威胁和漏洞的情况下是否仍然有效的流程； e)应建立确保对网络攻击、网络威胁和漏洞进行持续监控的流程； 注：车辆登记后即纳入监控范围。 5.2.5应建立管理企业与合同供应商、服务提供商、车辆生产企业子组织之间信息安全依赖关系的流程。 6车辆信息安全一般要求 6.1车辆产品开发流程应遵循汽车信息安全管理体系要求。 6.2应识别和管理车辆与供应商相关的风险。 6.3应识别车辆的关键要素，对车辆进行详细的风险评估，合理管理已识别的风险。 注：风险评估应考虑车辆的各个要素及其相互作用，并进一步考虑与任何外部系统的相互作用。 示例：关键要素包括有助于车辆安全、环境保护或防盗的要素，提供连接性的部件或车辆架构中对信息安全至关重要的部分等。 6.4应采取基于第7章、第8章、第9章、第10章的信息安全技术要求处置措施保护车辆不受 风险评估中已识别的风险影响。 注1：若处置措施与所识别的风险不相关，则车辆制造商应说明其不相关性。 注2：若处置措施与所识别的风险不充分，则车辆制造商应实施其它的处置措施，并说明其使用措施的合理性。 6.5如有专用环境，则应采取相应适当的措施，以保护车辆用于存储和执行后装软件、服务、应用程序或数据的专用环境。 6.6应通过适当和充分的测试来验证所实施的信息安全措施的有效性。 6.7应针对车辆实施相应措施，以识别和防御针对该车辆的网络攻击、网络威胁和漏洞，并为车辆生产企业在识别与车辆相关的网络攻击、网络威胁和漏洞方面提供监测能力，以及为分析网络攻击、网络威胁和漏洞提供数据取证能力。 6.8应采用符合国际通用、国家或行业标准要求的密码模块。若使用的密码模块未采用国际通用、国家或行业标准要求，则应说明其使用的合理性。应使用公开的、已发布的、有效的密码算法，并选择适当的参数和选项；应根据不同密码算法和场景，选择适当长度和有效的密钥。 3 注：有效的密码算法指安全有效且未被破解的算法，如MD5已被破解，此类算法相对不安全。 6.9车辆应采用默认安全设置。 示例：如WLAN的默认连接口令应满足复杂度的要求。 6.10车辆数据处理活动中的数据车内处理、默认不收集、精度范围适用、脱敏处理、个人同意及显著告知等要求，应符合GB/TXXXXX《智能网联汽车数据通用要求》中4.2.1、4.2.2的规定。 7车辆外部连接安全要求 7.1远程控制系统安全要求 7.1.1应对远程控制系统的指令信息进行真实性和完整性验证，并应具备验证失败的处理能力。 7.1.2应对远程控制系统的指令设置访问控制，禁用非授权的远程控制指令。 7.1.3应具备远程控制系统的安全日志记录功能，安全日志记录的内容至少包括远程控制指令的日期、时间、发送主体、远程控制对象、操作结果等。 7.1.4应对车端具备远程控制功能的系统的程序和配置数据进行完整性验证。 7.2第三方应用安全要求 7.2.1应对授权的第三方应用的真实性和完整性进行验证。 注：第三方应用是指车辆生产企业及其供应商之外的其他法人实体提供的面向用户提供服务的应用程序，包括第三方娱乐应用等。 7.2.2应对非授权的第三方应用的安装运行进行提示，并对已安装的非授权的第三方应用进行访问控 制，避免此类应用直接访问系统资源、个人信息等。 7.3外部接口安全要求 7.3.1应对外部接口进行访问控制保护，禁止非授权访问。 示例：外部接口包括USB接口、诊断接口和其他接口等。 7.3.2应对USB接口接入设备中的文件进行访问控制，只允许读写指定格式的文件或安装执行指定签名的应用软件。 7.3.3应具备抵御USB接口接入设备中的病毒程序和携带病毒的媒体文件/应用软件的能力。 7.3.4通过诊断接口发送车辆关键参数的写操作请求时，应采用身份鉴别、访问控制等安全策略。 7.4车辆远程控制系统、授权的第三方应用等外部连接系统不应存在由权威漏洞平台6个月前公布且未经处置的高危及以上的安全漏洞。 注：处置包括消除漏洞、制定减缓措施等方式。 7.5车辆应关闭不必要的网络端口。 8车辆通信安全要求 8.1车辆与车辆生产企业云平台通信时，应对其通信对象的身份真实性进行验证。 8.2车辆与车辆、路侧单元、移动终端等进行直连通信时，应进行证书有效性和合法性的验证。 8.3车辆应采用完整性保护机制保护外部通信通道。 示例：车辆外部通信通道包括移动蜂窝通信、WLAN、蓝牙等，不包括射频、NFC等短距离无线通信通道。 4 8.4车辆应具备对来自车辆外部通信通道的数据操作指令的访问控制机制。 注：来自车辆外部通信通道的数据操作指令包括代码注入、数据操纵、数据覆盖、数据擦除和数据写入等指令。 8.5车辆应验证所接收的关键指令数据的有效性或唯一性。 注：关键指令数据是指可能影响行车和财产安全的指令数据，包括但不限于车控指令数据。 示例：针对远程控制服务器发送的车控指令，车端可通过网关校验该类指令的有效期或唯一性。 8.6车辆应对发送的敏感个人信息实施保密性保护措施。 8.7车辆与外部直接通信的零部件应具备身份识别机制。 注：与外部存在直接通信的零部件包括但不限于车载信息交互系统等，不包括短距离无线传感器。 8.8车辆与外部直接通信的零部件应具备安全机制防止非授权的系统特权访问。 注：非授权用户可能通过调试接口获得系统的根用户权限。 8.9车辆内部网络应划分安全区域，并实现安全区域之间的隔离，对跨域请求应进行访问控制，并遵循默认拒绝原则和最小化授权原则。 注：隔离措施包括物理隔离、逻辑隔离（如采用白名单、防火墙等措施），如车载以太网可采用VLAN技术实现不同功能域之间的逻辑隔离。 8.10车辆应具备识别车辆通信通道遭受拒绝服务攻击的能力，并对攻击数据包进行相应的处理。 注：对攻击数据包的处理包括拦截、丢弃等。 示例：车辆通信通道包括移动蜂窝通信、V2X等车外通信通道，也包括CAN总线和车载以太网等车内通信通道。 8.11车辆应具备识别恶意的V2X数据、恶意的诊断数据、恶意的专有数据等的能力，并采取