汽车信息安全标准ISO/SAE21434与UN/WP.29阅读总结

1 序言

        伴随着汽车与外界的交互手段不断丰富，车联网相关设备、系统间的数据交互更加频繁，万物互联下的网络攻击也逐渐渗透延伸到车联网的领域。这给汽车行业带来了新的“专属挑战”。

        我这几天简要阅读了汽车信息安全领域的几个重要的国际规范，本文就简要讨论下这几个汽车信息安全相关的标准和规范。

2 ISO/SAE21434标准

        2021年8月31日，汽车信息安全领域首个国际标准ISO/SAE 21434“Road vehicles—Cybersecurity engineering（道路车辆 信息安全工程）”正式发布。ISO/SAE 21434由国际标准化组织（ISO）/美国汽车工程师学会（SAE）联合起草并发布，用于指导规范行业发展。ISO21434标准定义了车辆网络安全的完整框架和产品网络安全生命周期的相关流程。

2.1 ISO/SAE 21434与ISO 26262 标准关系

        ISO/SAE 21434与ISO 26262 标准有没有关系呢？应该还是有关的。

        ISO 26262 标准出现的较早，主要讨论功能安全。功能安全旨在保障功能按照设计要求正常进行，尽量减少因系统设计问题导致的功能失效；而信息安全旨在抵御外界攻击，更注重系统在外界攻击下能够正常运行，不产生财产损失，同时保护个人隐私不受侵犯。二者均专注于系统级功能，且彼此的定义和过程均相互关联。ISO 26262中针对功能安全与信息安全之间的相互作用给出了指南建议。如：概念阶段中HARA与TARA之间的相互作用及流程之间的协调等。随着汽车智能化、网联化的深入推进，功能安全、信息安全并不是独立、割裂存在的，总体呈现与企业现有结构化流程进行融合的趋势。

2.2 ISO/SAE 21434章节结构

        ISO/SAE 21434共有15个章节。分别是 1.范围 2.参考文献 3.术语和缩略语 4.总则 5.全局网络安全管理 6.项目相关的网络安全管理 7.分布式网络安全活动 8.持续的网络安全活动 9.概念设计 10.产品研发 11.信息安全验证 12.生产 13.运营和维护 14.报废 15.风险评估方法(TARA) 。

        ISO/SAE 21434章节机构如下图所示。

        标准的1-4章是对标准的基本说明，包括标准的范围、参考以及术语定义以及标准总则。

        5-8章是在企业的整体管理方面提出的信息安全相关要求，其目标是希望企业从公司维度建立信息安全流程与机制，做到“谋全局”。

        9-14章按照产品全生命周期的顺序，定义了概念设计、研发、验证、生产、运维以及报废等各阶段对于车辆信息安全的要求，其目标是在产品全生命周期中分阶段将信息安全威胁导致的风险降低到合理的范围，做到“谋一域”。

        15章提出了车辆信息安全风险评估方法论——TARA。

        在标准中，全局信息安全管理为产品全生命周期中的各个信息安全活动提供支撑，产品全生命周期中的各个信息安全活动环环相扣，二者相辅相承。如下图所示，在概念阶段需对信息安全相关项进行定义，并展开TARA分析，输出信息安全目标与需求，作为研发阶段的输入；在研发阶段，需对概念阶段输入的信息安全目标与需求进行细化，完成软硬件设计以及系统集成与测试，对信息安全需求的完成情况进行确认；验证阶段则需对标概念阶段定义的信息安全目标，确认其已被达成，形成闭环。

2.3 产品全生命周期信息安全管理中重要环节

    以下是产品全生命周期信息安全管理中需要重点关注的环节：

01  相关项定义
        在概念阶段，从产品整个生命周期的维度明确相关项定义对于汽车信息安全来说十分重要，这是澄清管理范围，为后续信息安全管理活动输如管理对象的重要一环。

02  TARA分析
        TARA分析包括资产识别、威胁场景识别、影响分析、攻击路径分析、攻击可行性评级、风险等级评定和风险处理措施等步骤，企业通过对信息安全相关项进行TARA分析从而得到产品信息安全目标。

03  信息安全需求
        为了实现产品信息安全目标，企业应制定信息安全需求，将其分解至各个系统与组件，并制定相应的信息安全缓解措施。

04  信息安全开发
        在研发阶段，企业应对信息安全需求以及缓解措施进行细化，并依据细化后的需求以及缓解措施开展产品研发工作，完成架构设计和软硬件设计，并对系统进行集成。

05  信息安全测试与验证
        信息安全测试是通过测试方法、测试用例等手段来验证产品已满足前期制定的信息安全需求，信息安全验证的目的确认在项目前期定义的信息安全目标已达成，至此信息安全设计冻结。

06  开发后阶段的信息安全要求
        此外，企业应采取措施确保落实产品在开发后阶段的信息安全要求。例如，在生产阶段制定信息安全生产控制计划，在运维阶段通过信息安全事件应急响应以及漏洞收集管理等方式应对外界攻击手段的变化，并考虑产品报废后的信息安全问题。

        总体而言，ISO/SAE 21434全面规定了道路车辆及其部件和接口的信息安全要求，详细描述了如何根据信息安全问题实现车辆信息安全管理目标，是目前汽车信息安全领域在政府监管、行业指导以及企业内控的重要参考文件，同时有利于促进社会各界在汽车信息安全领域达成重要共识。

3 UN/WP.29车联网标准

        2020年6月，联合国世界车辆法规协调论坛（简称为UN/WP.29）发布了3项关于智能网联汽车的重要法规R155/R156/R157，即信息安全（Cybersecurity）/软件升级（Software updates）/自动车道保持系统（ALKS）。该系列法规适用于1958协议下成员国（UNECE 1958年协议的缔约方已增加到54个，其中包括所有欧盟国家和其他OECD国家，虽然中国不在1958协议国中，但是生产的汽车只要销售到这些国家中就必须通过相关认证。

        WP.29其实规范很多，但是之前的规范都与信息安全无关。而R155/R156是我比较关心的规范。

3.1 R155

        R155（信息安全与信息安全管理系统）是全球第一个汽车信息安全强制法规，这意味着车辆的信息安全已经从符合标准进入到遵从法规的时代。

        R155规范有12个章节 1.范围 2.定义 3.审批申请 4.标记 5.审批 6.CSMS合规证书 7.规范要求 8.车型修改和延期 9.产品符合性 10.产品不符合惩罚 11.产品停产 12.负责审批测试的技术服务方和车型审批机构的联系方式。

        法规规定了车辆制造商需要满足的信息安全强制要求，强制实施意味着有计划出口至欧盟或其他OECD国家的车辆制造商将面临着严峻的准入挑战。

3.1.1 R155使用范围

        R155在网络安全方面基本涵盖了乘用车和商用车的适用范围，适用于

a) M类车型、N类车型

b) 至少装备了一个ECU的O类车型

c) 具备L3级及以上自动驾驶功能的L6和L7类车型。

3.1.2 R155法规时间规划

几个重要时间节点：
•  2021年1月22日法案正式生效，开放申请CSMS（Cyber Security Management System/网络安全管理体系认证）证书、VTA（Vehicle Type Approval/车辆型式认证）证书；
•  2022年7月起适用于新车型；2024年7月起适用于所有车型；
•  2022年-2024年两年内的现有架构新车型上市，若无法按照CSMS开发，则VTA必须证明在开发阶段已充分考虑网络安全；
•  2025年1月过渡期结束，要求所有架构所有车型通过认证（CSMS+VTA）。

3.1.3 R155合规认证要求

        R155合规认证主要分为两部分，一是网络安全管理体系认证（CSMS）；二是车辆网络安全型式认证（VTA）。

        CSMS认证主要审查车辆制造商是否在车辆完整生命周期的各个阶段均制定了网络安全管理流程，以确保汽车全生命周期中都有对应的流程措施。各流程实施于开发、生产、量产运维各个阶段，保证信息安全设计、实施及响应均有流程体系指导。

        VTA认证则是针对信息安全开发中具体的工作项进行审查，旨在保证实施于车辆的信息安全防护技术在进行审查认证时足够完备。换言之，CSMS认证是VTA认证的前提，而最终车辆准入必须完成CSMS认证及VTA认证。

3.1.4 网络安全管理体系要求(CSMS认证)
 

        车辆制造商应满足R155法规中“7.2 网络安全管理体系要求”的内容，其中7.2.2章节具体阐述了CSMS认证应涵盖的具体方面。

● 7.2.2.1 在车辆完整生命周期的各个阶段均制定了网络安全管理体系要求：
·  开发阶段；
·  生产阶段；
·  后期生产阶段。

● 7.2.2.2 确保在CSMS中充分考虑了安全性并在车辆全生命周期中都有流程措施以控制相关风险：

·  具备管理CSMS实施的完整流程；
·  具备用于识别车型所有可能风险的流程（需要考虑R155附件5A部分提及的风险和其他相关风险）；
·  具备用于评估/分类/处理所识别风险的流程；
·  具备管理风险的流程和标准；
·  开发阶段和生产阶段均具备测试车型的能力和过程；
·  风险评估及时更新，处于最新状态；
·  监控、检测和响应网络攻击、网络威胁和漏洞的流程；
·  全生命周期阶段的车型均具备有效措施应对网络攻击、网络威胁和漏洞；
·  提供网络攻击过程分析所需相关数据。

● 7.2.2.3 响应与缓解：
·  车辆制造商需对网络威胁和漏洞进行响应；
·  响应应在合理时间范围内得到缓解。

● 7.2.2.4 持续监测：
·  对车型网络攻击、网络威胁和网络漏洞的监测过程是可持续性的；
·  首次登记后的车辆便纳入监测范围；
·  具备从车辆数据和日志中分析和检测的能力；
·  隐私权和同意权（GDPR&ISO27701&个人信息保护法&数据安全法……）。

● 7.2.2.5 网络安全管理系统的供应链管理：
·  证明来自供应商/服务提供商/子公司的风险是明确的，并根据7.2.2.2的要求进行管理；
·  表明对供应商/服务提供商/子公司所携带的风险采取相应的措施。
 

3.1.5 R155 车辆型式要求（VTA认证）
 

车辆制造商应满足R155法规中“7.3车辆型式要求”的内容。

VTA具体内容要求如下：

● 7.3.1应持有与被认证车型相关的有效的CSMS合规证书：
·  2024年7月1日之前的车型认证，如果无法按照CSMS进行开发，则需证明在相关车型的开发阶段已充分考虑网络安全。

● 7.3.2 应识别和管理与供应商相关的风险：
·  来自供应商的可知且可被管理的风险；
·  车辆制造商可提供与供应商签订的符合R155要求的合同条款等证据。

● 7.3.3 车型要素识别、风险评估、处理/管理已识别风险。

● 7.3.4 实施对应的缓解措施：
·  实施的缓解措施应包括R155附录5中B部分和C部分提及的与已知风险相关的所有环节措施；
·  R155附录5中B部分或C部分中提及的缓解措施与所识别的风险无关或不足，车辆制造商应确保实施另一种适当的缓解措施。

● 7.3.5采取适当相称的措施，确保车型的专用环境安全，以存储和执行售后软件、服务、应用或数据：

·  证明来自供应商/服务提供商/子公司的风险是明确的，并根据7.2.2.2的要求进行管理；
·  表明对供应商/服务提供商/子公司所携带的风险采取相应的措施。

● 7.3.6 车辆制造商应在认证之前进行适当且充分的测试，以验证所执行的安全措施的有效性：

● 7.3.7 规定了车辆制造商应对车型采取的措施：
·  监测安全威胁，检测并阻止网络攻击；
·  具备数据取证能力，以支持分析未遂或成功的网络攻击。

● 7.3.8 加密模块应符合共识标准：
·  如果使用的加密模块不符合共识标准，则车辆制造商应证明其使用的合理性。

3.1.6 R155 威胁和响应缓解措施清单

R155的附录5是“威胁和响应缓解措施清单”。

        本附件由三部分组成。

        A部分描述了威胁、漏洞和攻击方法的基线。

        B部分描述了缓解针对车辆类型的威胁的措施。

        C部分描述了针对车辆以外区域(如IT后端)的威胁的缓解措施。

A 部分 威胁相关的漏洞或攻击方法列表

4.3.1后端服务器威胁	1 后端服务器被用作攻击车辆或提取数据的手段
	2 后端服务器业务中断，影响车辆正常运行
	3 后端服务器上的车辆相关数据丢失或泄露(“数据泄露”)
4.3.2对车辆通信通道的威胁	4 车辆受接收到的信息或数据欺骗
	5 利用通信信道对车辆持有的代码/数据进行未经授权的操作、删除或其他修改
	6 通信通道允许接受或接受不可信/不可靠的或易受会话劫持/重放攻击的消息
	7 信息容易泄露。例如，通过窃听通信或允许未经授权的访问敏感文件或文件夹
	8 通过通信通道破坏车辆功能的拒绝服务攻击
	9 非特权用户能够获得特权访问车辆系统
	10 传播媒介中的病毒能够感染车辆系统
	11 车辆接收的消息(例如X2V或诊断消息)或在其内部传输的消息包含恶意内容
4.3.3 车辆因更新程序而受到威胁	12 误用或破坏更新程序
	13 拒绝合法更新的可能
4.3.4人为无意行为可能促进网络攻击而对车辆造成的威胁	15 合法的行为者能够在不知情的情况下为网络攻击提供便利
4.3.5对车辆外部连通性和连接的威胁	16 通过操控车辆功能的连接，可以进行网络攻击，包括远程信息处理;允许远程操作的系统;以及使用短程无线通信的系统
	17 托管的第三方软件，例如娱乐应用程序，用作攻击车辆系统的手段
	18 连接到外部接口的设备，如USB端口、OBD端口，用作攻击车载系统的手段
4.3.6对车辆数据/代码的威胁	19 车辆数据/代码提取
	20 操纵车辆数据/代码
	21 擦除数据/代码
	22 引入恶意软件
	23 引入新软件或覆盖现有软件
	24 系统或操作的中断
	25 车辆参数操纵
4.3.7 如果没有充分保护或加固，可能被利用的潜在漏洞	26 密码技术可能遭到破坏或应用不足
	27 零部件或供应可能会受损，从而使车辆受到攻击
	28 软件或硬件开发存在漏洞
	29 网络设计引入漏洞
	31 可能会发生意外的数据传输
	32 系统的物理操作可能会引发攻击

       对于上图的攻击漏洞/威胁，R155举了不少例子。后续的“B部分”和“C部分”还分析了防御/缓解漏洞/威胁的方法。

High level and sub-level descriptions of vulnerability/ threat			Example of vulnerability or attack method
Back-end servers used as a means to attack a vehicle or extract data	1.1	Abuse of privileges by staff (insider attack)
	1.2	Unauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)
	1.3	Unauthorized physical access to the server (conducted by for example USB sticks or other media connecting to the server)
Services from back-end server being disrupted, affecting the operation of a vehicle	2.1	Attack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on
Vehicle related data held on back-end servers being lost or compromised ("data breach")	3.1	Abuse of privileges by staff (insider attack)
	3.2	Loss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers
	3.3	Unauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)
	3.4	Unauthorized physical access to the server (conducted for example by USB sticks or other media connecting to the server)
	3.5	Information breach by unintended sharing of data (e.g. admin errors)
Spoofing of messages or data received by the vehicle	4.1	Spoofing of messages by impersonation (e.g. 802.11p V2X during platooning, GNSS messages, etc.)
	4.2	Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road)
Communication channels used to conduct unauthorized manipulation, deletion or other amendments to vehicle held code/data	5.1	Communications channels permit code injection, for example tampered software binary might be injected into the communication stream
	5.2	Communications channels permit manipulate of vehicle held data/code
	5.3	Communications channels permit overwrite of vehicle held data/code
	5.4	Communications channels permit erasure of vehicle held data/code
	5.5	Communications channels permit introduction of data/code to the vehicle (write data code)
Communication channels permit untrusted/unreliable messages to be accepted or are vulnerable to session hijacking/replay attacks	6.1	Accepting information from an unreliable or untrusted source
	6.2	Man in the middle attack/ session hijacking
	6.3	Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway
Information can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders	7.1	Interception of information / interfering radiations / monitoring communications
	7.2	Gaining unauthorized access to files or data
Denial of service attacks via communication channels to disrupt vehicle functions	8.1	Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner
	8.2	Black hole attack, in order to disrupt communication between vehicles the attacker is able to block messages between the vehicles
An unprivileged user is able to gain privileged access to vehicle systems	9.1	An unprivileged user is able to gain privileged access, for example root access
Viruses embedded in communication media are able to infect vehicle systems	10.1	Virus embedded in communication media infects vehicle systems
Messages received by the vehicle (for example X2V or diagnostic messages), or transmitted within it, contain malicious content	11.1	Malicious internal (e.g. CAN) messages
	11.2	Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)
	11.3	Malicious diagnostic messages
	11.4	Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)
Misuse or compromise of update procedures	12.1	Compromise of over the air software update procedures.  This includes fabricating the system update program or firmware
	12.2	Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware
	12.3	The software is manipulated before the update process (and is therefore corrupted), although the update process is intact
	12.4	Compromise of cryptographic keys of the software provider to allow invalid update
It is possible to deny legitimate updates	13.1	Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features
Legitimate actors are able to take actions that would unwittingly facilitate a cyber-attack	15.1	Innocent victim (e.g. owner, operator or maintenance engineer) being tricked into taking an action to unintentionally load malware or enable an attack
	15.2	Defined security procedures are not followed
Manipulation of the connectivity of vehicle functions enables a cyber-attack, this can include telematics; systems that permit remote operations; and systems using short range wireless communications	16.1	Manipulation of functions designed to remotely operate systems, such as remote key, immobilizer, and charging pile
	16.2	Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)
	16.3	Interference with short range wireless systems or sensors
Hosted 3rd party software, e.g. entertainment applications, used as a means to attack vehicle systems	17.1	Corrupted applications, or those with poor software security, used as a method to attack vehicle systems
Devices connected to external interfaces e.g. USB ports, OBD port, used as a means to attack vehicle systems	18.1	External interfaces such as USB or other ports used as a point of attack, for example through code injection
	18.2	Media infected with a virus connected to a vehicle system
	18.3	Diagnostic access (e.g.  dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)
Extraction of vehicle data/code	19.1	Extraction of copyright or proprietary software from vehicle systems (product piracy)
	19.2	Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.
	19.3	Extraction of cryptographic keys
Manipulation of vehicle data/code	20.1	Illegal/unauthorized changes to vehicle’s electronic ID
	20.2	Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend
	20.3	Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)
	20.4	Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)
	20.5	Unauthorized changes to system diagnostic data
Erasure of data/code	21.1	Unauthorized deletion/manipulation of system event logs
Introduction of malware	22.2	Introduce malicious software or malicious software activity
Introduction of new software or overwrite existing software	23.1	Fabrication of software of the vehicle control system or information system
Disruption of systems or operations	24.1	Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging
Manipulation of vehicle parameters	25.1	Unauthorized access of falsify the configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.
	25.2	Unauthorized access of falsify the charging parameters, such as charging voltage, charging power, battery temperature, etc.
Cryptographic technologies can be compromised or are insufficiently applied	26.1	Combination of short encryption keys and long period of validity enables attacker to break encryption
	26.2	Insufficient use of cryptographic algorithms to protect sensitive systems
	26.3	Using already or soon to be deprecated cryptographic algorithms
Parts or supplies could be compromised to permit vehicles to be attacked	27.1	Hardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack
Software or hardware development permits vulnerabilities	28.1	Software bugs. The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present
	28.2	Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit access to ECUs or permit attackers to gain higher privileges
Network design introduces vulnerabilities	29.1	Superfluous internet ports left open, providing access to network systems
	29.2	Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages
Unintended transfer of data can    occur	31.1	Information breach. Personal data may be leaked when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)
Physical manipulation of systems can enable an attack	32.1	Manipulation of electronic hardware, e.g. unauthorized electronic hardware added to a vehicle to enable "man-in-the-middle" attack Replacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware Manipulation of the information collected by a sensor (for example, using a magnet to tamper with the Hall effect sensor connected to the gearbox)

B 部分 减轻对车辆的威胁

B.1 缓解与"车辆通信通道"有关的威胁

Table A1 reference	Threats to "Vehicle communication channels"	Ref	Mitigation
4.1	Spoofing of messages (e.g. 802.11p V2X during platooning, GNSS messages, etc.) by impersonation	M10	The vehicle shall verify the authenticity and integrity of messages it receives
4.2	Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road)	M11	Security controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules)
5.1	Communication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream	M10   M6	The vehicle shall verify the authenticity and integrity of messages it receives Systems shall implement security by design to minimize risks
5.2	Communication channels permit manipulation of vehicle held data/code	M7	Access control techniques and designs shall be applied to protect system data/code
5.3	Communication channels permit overwrite of vehicle held data/code
5.4 21.1	Communication channels permit erasure of vehicle held data/code
5.5	Communication channels permit introduction of data/code to vehicle systems (write data code)
6.1	Accepting information from an unreliable or untrusted source	M10	The vehicle shall verify the authenticity and integrity of messages it receives
6.2	Man in the middle attack / session hijacking	M10	The vehicle shall verify the authenticity and integrity of messages it receives
6.3	Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway
7.1	Interception of information / interfering radiations / monitoring communications	M12	Confidential data transmitted to or from the vehicle shall be protected
7.2	Gaining unauthorized access to files or data	M8	Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Example of Security Controls can be found in OWASP
8.1	Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner	M13	Measures to detect and recover from a denial of service attack shall be employed
8.2	Black hole attack, disruption of communication between vehicles by blocking the transfer of messages to other vehicles	M13	Measures to detect and recover from a denial of service attack shall be employed
9.1	An unprivileged user is able to gain privileged access, for example root access	M9	Measures to prevent and detect unauthorized access shall be employed
10.1	Virus embedded in communication media infects vehicle systems	M14	Measures to protect systems against embedded viruses/malware should be considered
11.1	Malicious internal (e.g. CAN) messages	M15	Measures to detect malicious internal messages or activity should be considered
11.2	Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)	M10	The vehicle shall verify the authenticity and integrity of messages it receives
11.3	Malicious diagnostic messages
11.4	Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)

B.2 缓解与“更新过程”有关的威胁

Table A1 reference	Threats to "Update process"	Ref	Mitigation
12.1	Compromise of over the air software update procedures. This includes fabricating the system update program or firmware	M16	Secure software update procedures shall be employed
12.2	Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware
12.3	The software is manipulated before the update process (and is therefore corrupted), although the update process is intact
12.4	Compromise of cryptographic keys of the software provider to allow invalid update	M11	Security controls shall be implemented for storing cryptographic keys
13.1	Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features	M3	Security Controls shall be applied to back-end systems.  Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP

B.3 缓解与“人的意外行为导致网络攻击”有关的威胁

Table A1 reference	Threats relating to "Unintended human actions"	Ref	Mitigation
15.1	Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack	M18	Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege
15.2	Defined security procedures are not followed	M19	Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions

B.4 减少与"外部连接"有关的威胁

Table A1 reference	Threats to "External connectivity and connections"	Ref	Mitigation
16.1	Manipulation of functions designed to remotely operate vehicle systems, such as remote key, immobiliser, and charging pile	M20	Security controls shall be applied to systems that have remote access
16.2	Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)
16.3	Interference with short range wireless systems or sensors
17.1	Corrupted applications, or those with poor software security, used as a method to attack vehicle systems	M21	Software shall be security assessed, authenticated and integrity protected. Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle
18.1	External interfaces such as USB or other ports used as a point of attack, for example through code injection	M22	Security controls shall be applied to external interfaces
18.2	Media infected with viruses connected to the vehicle
18.3	Diagnostic access (e.g.  dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)	M22	Security controls shall be applied to external interfaces

B.5 减轻与"攻击的潜在目标或动机"有关的威胁

Table A1 reference	Threats to "Potential targets of, or motivations for, an attack"	Ref	Mitigation
19.1	Extraction of copyright or proprietary software from vehicle systems (product piracy / stolen software)	M7	Access control techniques and designs shall be applied to protect system data/code.  Example Security Controls can be found in OWASP
19.2	Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.	M8	Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Examples of Security Controls can be found in OWASP
19.3	Extraction of cryptographic keys	M11	Security controls shall be implemented for storing cryptographic keys e.g. Security Modules
20.1	Illegal/unauthorised changes to vehicle’s electronic ID	M7	Access control techniques and designs shall be applied to protect system data/code.  Example Security Controls can be found in OWASP
20.2	Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend
20.3	Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)	M7	Access control techniques and designs shall be applied to protect system data/code.  Example Security Controls can be found in OWASP. Data manipulation attacks on sensors or transmitted data could be mitigated by correlating the data from different sources of information
20.4	Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)
20.5	Unauthorised changes to system diagnostic data
21.1	Unauthorized deletion/manipulation of system event logs	M7	Access control techniques and designs shall be applied to protect system data/code.  Example Security Controls can be found in OWASP.
22.2	Introduce malicious software or malicious software activity	M7	Access control techniques and designs shall be applied to protect system data/code.  Example Security Controls can be found in OWASP.
23.1	Fabrication of software of the vehicle control system or information system
24.1	Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging	M13	Measures to detect and recover from a denial of service attack shall be employed
25.1	Unauthorized access to falsify configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.	M7	Access control techniques and designs shall be applied to protect system data/code.  Example Security Controls can be found in OWASP
25.2	Unauthorized access to falsify charging parameters, such as charging voltage, charging power, battery temperature, etc.

B.6 减轻与“如果不充分保护或加固就可能被利用的潜在漏洞”有关的威胁

Table A1 reference	Threats to "Potential vulnerabilities that could be exploited if not sufficiently protected or hardened"	Ref	Mitigation
26.1	Combination of short encryption keys and long period of validity enables attacker to break encryption	M23	Cybersecurity best practices for software and hardware development shall be followed
26.2	Insufficient use of cryptographic algorithms to protect sensitive systems
26.3	Using deprecated cryptographic algorithms
27.1	Hardware or software, engineered to enable an attack or fail to meet design criteria to stop an attack	M23	Cybersecurity best practices for software and hardware development shall be followed
28.1	The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present	M23	Cybersecurity best practices for software and hardware development shall be followed. Cybersecurity testing with adequate coverage
28.2	Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit an attacker to access ECUs or gain higher privileges
29.1	Superfluous internet ports left open, providing access to network systems
29.2	Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages	M23	Cybersecurity best practices for software and hardware development shall be followed. Cybersecurity best practices for system design and system integration shall be followed

B.7 缓解与"车辆数据丢失/数据泄露"有关的威胁

Table A1 reference	Threats of "Data loss / data breach from vehicle"	Ref	Mitigation
31.1	Information breach. Personal data may be breached when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)	M24	Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data.

B.8 减少与“通过物理操作系统来实现攻击”相关的威胁

Table A1 reference	Threats to "Physical manipulation of systems to enable an attack"	Ref	Mitigation
32.1	Manipulation of OEM hardware, e.g. unauthorised hardware added to a vehicle to enable "man-in-the-middle" attack	M9	Measures to prevent and detect unauthorized access shall be employed

C部分 减轻车辆外部的威胁

C.1 缓解与“后端服务器”相关的威胁

Table A1 reference	Threats to "Back-end servers"	Ref	Mitigation
1.1 & 3.1	Abuse of privileges by staff (insider attack)	M1	Security Controls are applied to back-end systems to minimise the risk of insider attack
1.2 & 3.3	Unauthorised internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)	M2	Security Controls are applied to back-end systems to minimise unauthorised access. Example Security Controls can be found in OWASP
1.3 & 3.4	Unauthorised physical access to the server (conducted by for example USB sticks or other media connecting to the server)	M8	Through system design and access control it should not be possible for unauthorised personnel to access personal or system critical data
2.1	Attack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on	M3	Security Controls are applied to back-end systems.  Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP
3.2	Loss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers	M4	Security Controls are applied to minimise risks associated with cloud computing. Example Security Controls can be found in OWASP and NCSC cloud computing guidance
3.5	Information breach by unintended sharing of data (e.g. admin errors, storing data in servers in garages)	M5	Security Controls are applied to back-end systems to prevent data breaches. Example Security Controls can be found in OWASP

C.2 减少与"非故意人类行为"有关的威胁

Table A1 reference	Threats relating to "Unintended human actions"	Ref	Mitigation
15.1	Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack	M18	Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege
15.2	Defined security procedures are not followed	M19	Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions

C.3 缓解与"数据丢失的物理丢失"有关的威胁

Table A1 reference	Threats of "Physical loss of data"	Ref	Mitigation
30.1	Damage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft	M24	Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data. Example Security Controls can be found in ISO/SC27/WG5
30.2	Loss from DRM (digital right management) conflicts. User data may be deleted due to DRM issues
30.3	The (integrity of) sensitive data may be lost due to IT components wear and tear, causing potential cascading issues (in case of key alteration, for example)

 应考虑对A、B和C部分进行风险评估，并由汽车制造商实施风险缓解措施。

        在A部分中对高级漏洞及其相应的示例进行了索引 .在B部分和C部分的表中引用了相同的索引，将每种攻击/漏洞与相应的缓解措施列表联系起来。

        威胁分析还应考虑可能的攻击影响。这些可以帮助确定风险的严重性，并识别额外的风险。可能的攻击影响包括:

        (a)受影响车辆的安全操作;
        (b)车辆功能停止工作;
        (c)修改软件，改变性能;
        (d)更改软件但无业务影响;
        (e)违反数据完整性;
        (f)违反数据保密性;
        (g)资料缺乏;
        (h)其他，包括犯罪。

        SO21434标准定义了车辆网络安全的完整框架和产品网络安全生命周期的相关流程，对R155法规的落地起到支撑作用，尤其是有助于车辆制造商在供应链上实施CSMS要求。对于法规中的相关要求，可通过描述文件、技术文件、演示、审计等手段来证明。

3.2 R156

        UN R156讨论的是软件升级与软件升级管理系统的统一规定。R156章节名字和R155基本一致。

3.2.1 R156 主要规定要求

 R156的第七章是规定要求。

7.1 汽车厂商软件更新管理系统的要求

7.1.1 在初步评估时要验证的过程
列举了一些过程

7.1.2 汽车制造商应记录和存储下列信息，适用于特定车型的每次更新

描述汽车制造商用于软件更新的过程和用于证明其合规性的任何相关标准的文件;

在更新之前和之后描述任何相关类型批准系统配置的文件，这应包括类型批准系统的硬件和软件(包括软件版本)的唯一标识，以及任何相关的车辆或系统参数;

对于每个RXSWIN，在更新之前和之后，都应该有一个可审计的寄存器，描述与车辆类型的RXSWIN相关的所有软件。这应包括每个RXSWIN的所有相关软件的软件版本信息及其完整性验证数据。

列出用于更新的目标车辆的文档，并确认这些车辆的最新配置与更新的兼容性。

该车型所有软件更新的文档说明如下:
(a)更新的目的;
(b)更新后会影响车辆的哪些系统或功能;
(c)其中哪些型号是经批准的(如有);
(d)如适用，软件更新是否影响该类型核定系统的任何有关要求的履行;
(e)软件更新是否影响任何系统类型批准参数;
(f)是否要求核可机构核可更新情况;

(g)如何执行更新以及在什么条件下执行更新;
(h)确认软件更新将安全可靠地进行;
(i)确认软件更新已经完成并成功通过了验证和验证程序。

7.2. 车辆类型的要求

7.2.1.软件更新的要求

7.2.2. OTA更新的附加要求

车辆制造商应确保车辆在更新失败或中断时能够将系统恢复到以前的版本，或者在更新失败或中断后能够将车辆置于安全状态。

车辆制造商应确保只有在车辆有足够的功率完成更新过程时才能进行软件更新
(包括可能恢复到以前版本或使车辆处于安全状态所需要的)。

当执行更新可能会影响车辆的安全时，车辆制造商应演示如何安全执行更新。
这应该通过技术手段来实现，确保车辆处于可以安全执行更新的状态。

车辆制造商应证明车辆用户能够在执行更新之前被告知更新。提供的资料应包括:

(a)更新的目的。这可能包括更新的关键性，以及更新是否用于召回、安全和/或安全目的;
(b)车辆功能更新所作的任何改变;
(c)预计完成执行更新的时间;
(d)在更新执行期间可能无法使用的任何车辆功能;
(e)任何可帮助车辆使用者安全执行更新的指示;

在驾驶时执行更新可能不安全的情况下，汽车制造商应演示他们将如何:
(a)确保车辆在更新执行期间不能驾驶;
(b)确保司机不能使用任何会影响车辆安全或成功执行更新的车辆功能

执行更新后，汽车制造商应演示如何执行以下内容:
(a)车辆使用者能够被告知更新的成功(或失败);
(b)车辆用户能够被告知已实施的更改和用户手册的任何相关更新(如适用)

在执行软件更新之前，车辆应确保满足前提条件。

4 总结

汽车的信息安全已经从符合标准进入到遵从法规的时代，必须要将信息安全贯穿于汽车的全生命周期。