汽车信息安全WP.29 R155法规要求与安全基线
联合国世界车辆法规协调论坛(UN/WP.29)发布了3项关于智能网联汽车的重要法规R155/R156/R157,即信息安全/软件升级/自动车道保持系统。R155是全球第一个汽车信息安全强制法规,这意味着车辆的信息安全已经从符合标准进入到遵从法规的时代。
1. 文件核查
批准机关需要通过文件核查的方式核实车辆制造商已采取与该车型相关的必要措施。
- 收集和核实供应链符合本法规所规定的安全要求,确保供应商的安全风险已识别和管理。
- 风险评估相关的记录、测试结果和风险的缓解措施
- 车型设计中实施适当的网络安全措施
- 发现并应对可能的网络安全攻击
- 检测网络攻击、数据取证以及网络攻击分析等数据记录
2. 批准要求
- 执行详尽的风险评估和实施相应的缓解措施
- 充分考虑下文中的车辆网络安全基线要求
- 采取适当的措施确保车辆专用环境安全、后市场软件、服务、应用程序、数据安全存储与执行
- 适当的渗透测试以验证已经实施的安全措施
3. 流程制定要求
- 制造商组织内部的网络安全管理流程
- 确定车辆风险的程序,对已识别的风险进行评估、分类和处理的流程
- 制定验证风险得到适当处理的管理流程
- 测试车辆网络安全的流程
- 确保风险评估持续更新的流程
- 监测、检测和应对网络攻击和车辆漏洞的流程
- 针对新的网络威胁、漏洞或者0day漏洞,评估已实施的网络安全措施是否有效的流程
- 网络扫描、探测和攻击的相关分析过程的流程
4. 持续性监测要求
- 首次登记的车辆即纳入监测
- 具备检测和分析来自车辆数据、车辆日志的网络威胁、漏洞和网络攻击的能力
5. 车辆网络安全基线
| R155法规车辆网络安全基线-威胁漏洞与攻击方法 | |||
| 脆弱性/威胁描述 | 漏洞攻击方法 | 缓解措施 | |
| 来自后端服务器的威胁 | 攻陷后端服务器 | 员工滥用特权(内部攻击) | 安全控制应用于后端系统,将内部攻击的风险降至最低 |
| 未经授权的服务器互联网访问(后门、系统漏洞和SQL注入等) | 安全控制应用于后端系统,以尽量减少未经授权的访问 | ||
| 未经授权的对服务器的物理访问 | 通过系统设计和访问控制,未经授权的人员不可能访问个人或系统关键数据 | ||
| 后端服务器服务中断,影响服务运行 | 对后端服务器的攻击会使其停止工作,会阻止与车辆交互或者阻止为车辆提供服务 | 安全控制应用于后端系统。当后端服务器对服务的提供至关重要时,在系统中断的情况下有恢复措施。 | |
| 后端服务器保存的车辆相关数据丢失或泄露 | 员工滥用特权(内部攻击) | 安全控制应用于后端系统,将内部攻击的风险降至最低 | |
| 云端信息丢失(第三方服务商存储数据时,敏感信息可能会因攻击或者事故而丢失或者泄露) | 采用安全控制将与云计算相关的风险降至最低。 | ||
| 未经授权的服务器互联网访问(后门、系统漏洞和SQL注入等) | 安全控制应用于后端系统,以尽量减少未经授权的访问。 | ||
| 未经授权的对服务器的物理访问 | 通过系统设计和访问控制,未经授权的人员不可能访问个人或系统关键数据 | ||
| 无意共享数据造成的信息泄露(管理错误) | 安全控制应用于后端系统,以防止数据泄露。 | ||
| 车辆通信通道的威胁 | 欺骗车辆接收的信息和数据 | 通过模拟欺骗信息(GNSS欺骗信号、排队的802.11p V2X) | 车辆应当核实所接收信息的真实性和完整性 |
| Sybil Attack(女巫攻击)通过多个虚假车辆身份欺骗其他正常车辆 | 应对存储加密密钥实施安全控制(例如,使用硬 件安全模块) |
||
| 对车辆持有的代码/数据进行未经授权的操作、删除和修改 | 通信通道允许代码注入,例如,可以将篡改的软件二进制流注入到通信流中 | 车辆应验证其接收信息的真实性和完整性系统应通过设计实现安全,以最小化风险 | |
| 通信通道允许操纵持有的数据/代码 | 应用访问控制技术和设计来保护系统数据/代码 | ||
| 通信通道允许覆盖持有的数据/代码 | |||
| 通信通道允许删除持有的数据/代码 | |||
| 通信通道允许将数据/代码引入车辆(写入数据/代码) | |||
| 通信通道允许不可靠信息被接受或易受会话劫持、重放攻击等 | 接受来自不可靠/不可信来源的信息 | 车辆应当核实所接收信息的真实性和完整性 | |
| 中间人攻击/会话劫持 | 车辆应当核实所接收信息的真实性和完整性 | ||
| 重放攻击,例如,针对通信网关的攻击 | |||
| 信息可以很容易披露,例如,通过监听通信或者通过允许访问未经授权的敏感文件访问 | 拦截信息/干扰辐射/监测通信 | 车辆传输或从车辆传输的机密数据应受到保护 | |
| 未经授权访问文件或数据 | 通过系统设计和访问控制,不应允许未经授权的 人员访问个人或系统关键数据。 |
||
| 通过通信通道进行拒绝服务攻击,破坏车辆功能 | 向车辆系统发送大量垃圾数据使其无法正常提供服务 | 应采用检测和从拒绝服务攻击中恢复的措施 | |
| 黑洞攻击(服务器受攻击的流量超过本机房黑洞阈值时,云提供商会屏蔽外网访问,直到监测到攻击流量停止才会自动解封),攻击者可以中断车辆之间的通信。 | 应采用检测和从拒绝服务攻击中恢复的措施 | ||
| 非特权系统可以获取对车辆的特权访问权限 | 非特权用户可以获取特权访问权限(横向越权/纵向越权) | 应采取措施防止和发现未经授权的访问 | |
| 嵌入通信数据中的病毒可以感染车辆系统 | 通信数据中可以注入病毒感染车辆系统 | 应该考虑采取措施保护系统免受嵌入式病毒/ 恶意软件的侵害 |
|
| 车辆接收的信息(X2V或诊断信息)或在车内传输的信息包含恶意内容 | 恶意的内部(CAN)消息 | 应该考虑检测恶意内部消息或活动的措施 | |
| 恶意的V2X消息,例如基础实施到车辆、车到车 | 车辆应当核实所接收信息的真实性和完整 性 |
||
| 恶意诊断信息 | |||
| 恶意的专有信息(通常来自OEM、组件、系统、功能供应商的信息 | |||
| 车辆更新程序的威胁 | 更新程序的误用和破坏 | 空中软件更新程序(OTA)的完整性威胁。包括车辆系统的更新程序或固件 | 安全的软件更新程序因具备完整性校验 |
| 本地物理软件更新程序的完整性威胁。包括编制系统更新程序和固件 | |||
| 软件在更新之前被损坏,尽管更新过程是完整的 | |||
| 软件供应商的加密密钥泄露,允许无效更新 | 应对加密密钥的存储实施安全控制 | ||
| 拒绝合法正常更新 | 针对更新服务器或网络的拒绝服务攻击,以阻止关键软件的更新的推出或以此来解锁客户特定的功能 | 安全控制应该应用于后端系统。当后端服务器对服务的提供至关重要时,应在系统中断的情况下采取恢复措施。 | |
| 合法用户的意外操作行为对网络安全的威胁 | 合法行为者无意中为网络攻击提供方便 | 受害者(所有者、运营商、维护工程师)被欺骗,无意中加载恶意软件或启动攻击 | 实施措施,确定和控制用户角色和访问权限,基于最小访问权限原则。 |
| 没有遵循定义的安全程序操作 | 组织应确保安全程序定义并遵循包括管理相关的操作以及访问安全功能 | ||
| 车辆远程连接和近场连接的威胁 | 通过网络攻击操纵车辆系统,包括远程信息处理,系统运行远程操作和近场通信 | 为远程操作车辆系统而设计的功能操作,如远程钥匙、防动器和充电桩 | 安全控制设计的功能操作应该应用于远程操作车辆系统,例如具有远程访问权限的系统 |
| 操控车辆远程信息处理(例如操控敏感货物的温度测量,远程解锁货舱门) | |||
| 远程无线系统或传感器的干扰 | |||
| 托管的第三方软件,例如娱乐 应用程序,被用作攻击车辆系 统的载体 |
损坏的应用程序,或软件安全性较差的应用程序,被用作攻击车辆系统的载体 | 软件应进行安全评估、认证和完整性保护。安全 控制应应用到最低限度预期或可预见托管在车辆上的第三方软件带来的风险 |
|
| 连接到外部接口的设备,如 USB 端口、 OBD 端口,用作攻 击车辆系统的手段 |
外部接口,如
USB 或其他端口用作攻击点,例如通过代 码注入 |
安全控制应应用于用作攻击点的外部端口或接口 | |
| 被连接到车辆系统的病毒感染的媒体 | |||
| 易于攻击的诊断访问(例如 OBD 端口工具),(直接或间接地)操纵车辆参数 | 外部端口工具应该应用安全控件 | ||
| 对车辆数据/代码的威胁 | 车辆数据/代码的提取 | 从车辆系统中提取版权或专有软件(产品盗版) | 应用访问控制技术和设计来保护系统数据/代码。 |
| 未经授权访问车主的隐私信息,如个人身份、支付账户信息、地址簿信息、位置信息、车辆电子ID 等。 | 通过系统设计和访问控制,不应允许未经授权的人员访问个人或系统关键数据。 | ||
| 密码密钥的提取 | 应对加密密钥的存储实施安全控制,例如安全加密模块 | ||
| 操作车辆数据/代码 | 非法/未经授权更改车辆电子标识 | 应该应用访问控制技术和设计来保护系统数据/代码。 | |
| 身份欺诈,例如,如果用户想在与收费系统通信时篡改身份 | |||
| 规避监控系统的行动,例如,黑客/篡改/封锁跟踪器数据或运行次数等消息 | 访问控制技术和设计应该应用于保护系统数据/代码。数据操纵攻击传感器或传输的数据可以通过 将来自不同来源的数据关联访问授权 |
||
| 操纵数据,伪造车辆行驶数据(例如里程、行驶速度、行驶方向等) | |||
| 未经授权更改系统诊断数据 | |||
| 擦除数据代码 | 未经授权的删除/操纵系统事件日志 | 应用访问控制技术和设计来保护系统数据/代码。 | |
| 介入的恶意软件 | 引入恶意软件或恶意软件活动 | ||
| 引入新软件覆盖现有软件 | 车辆控制系统或信息系统软件的制作 | ||
| 系统或操作的中断 | 拒绝服务可能在内部网络上通过泛滥
CAN 总线触 发,或通过高速率的消息传递在 ECU 上引发故障 |
应采用检测和从拒绝服务攻击中恢复的措施 | |
| 车辆参数操纵 | 未经授权访问伪造车辆关键功能的配置参数,如刹车数据、安全气囊部署阈值等。 | 应用访问控制技术和设计来保护系统数据/代码。 | |
| 未经授权擅自访问伪造的充电参数,如充电电压、充电功率、电池温度等。 | |||
| 潜在的漏洞可能被利用的威胁 | 密码可能被破坏或应用不足 | 弱密码或长期有效组合密钥被攻击者蛮力破解 | 应遵循软件和硬件开发的网络安全最佳实践 |
| 未充分使用加密算法来保密敏感系统 | |||
| 使用已经或者即将被弃用的加密算法 | |||
| 零件或组件可能被破坏,从而使车辆受到攻击 | 硬件或软件,设计用于支持攻击但未能满足阻止攻击的设计标准 | ||
| 软件或者硬件的开发漏洞 | 软件bug的存在会是潜在可利用漏洞的基础,测试以验证已知的bug以降低未知错误的风险、代码缺陷。 | 应遵循软件和硬件开发的网络安全最佳实践,充分覆盖的网络安全测试 | |
| 使用来自开发的遗留物(例如调试端口、 JTAG 端 口、微处理器、开发证书、开发人员密码等等)可以 允许访问 ECU或允许攻击者获得更高的特权 |
|||
| 网络设计引入漏洞 | 多余的互联网端口保持开放,提供对网络系统的访问 | 应遵循软件和硬件开发的网络安全最佳实践。 应遵循系统设计和系统集成的网络安全最佳实践 |
|
| 规避网络分离以获得控制权。使用不受保护的网关或接入点(如车载网关),以绕过保护措施,进入其他网络段执行恶意行为,如发送任意 CAN 总线消息。 | |||
| 可能会发生意外的数据泄露 | 当车辆更换用户时(例如被出售或被新用户用作出租车辆),个人数据可能会被泄露。 | 数据保护的最佳实践,遵循完整性和保密性来存储个人数据。 | |
| 对系统的物理操作可以使攻击成为可能 | 电子硬件的操作,例如,未经授权添加到车辆上的电子硬件 以实现“中间人” 攻击。更换授权电子硬件,用未经授权的跟换已经授权的电子硬件。操纵传感器收集的信息(例如,用磁铁进行篡改连接到变速箱的霍尔效应) |
应采用安全流程通道,防止和发现未经授权的措施。 | |
0
