智能汽车的网络安全与弹性优秀实践及指引

（上海社会科学院应用经济研究所博士研究生）

编者按：欧洲网络与信息安全局（ENISA）在2016年12月发布了“智能汽车的网络安全与弹性优秀实践和指引报告”。该报告定义了智能汽车的典型架构及相关技术，在分析智能汽车面临的风险和威胁，列举了主要四类攻击场景的基础上，进一步指出如今智能汽车当前主要在三个领域存在差异及挑战，并推荐了三类优秀实践，最后提出七条综合性发展建议。中国将智能汽车视作战略性新兴产业，正在投入资源以构建智能汽车生态圈，本报告提出的智能汽车优秀实践、部件分类及网络威胁模型可供借鉴。

1 智能汽车安全指南报告综述

欧洲网络与信息安全局（ENISA）这份报告的宗旨是保障当今智能汽车的安全、为明日更安全的无人汽车做准备，报告中讨论的相关实践不仅只关注智能乘用车辆的安全，还将其他类型如公交车辆、长途客运车辆等涵盖在内。ENISA将智能汽车定义是“为提高车辆用户体验或安全性而提供联网、增值特性的系统”，包含信息通讯、联网娱乐信息及车内通讯三个场景。如前所述，本报告仅关注目前所涉及到的技术，并不讨论如车车通讯等全自动车辆技术。

过去数年间，针对汽车系统尤其是对智能汽车的网络攻击屡见于报，此类威胁不仅给乘客还给其他人员带来安全隐患和隐私泄露风险，也同样给汽车厂商带来压力，厂商除承担由于存在安全漏洞而被迫召回数百万辆车的经济损失外，还要承担因为成为头条负面新闻后快速传播所带来的商誉损失。

本研究立足点是智能汽车的网络安全应首先能保障物理人身安全，再总结出智能汽车在面临网络威胁还能确保安全的优秀实践。首先通过列出汽车智能化中的关键设备清单，整理出各部件、子系统中潜在的威胁和风险，寻找风险缓解的关键因素，最后探讨可行的安全措施。采取的方法是访谈该领域的专家并现场调研，综合他们的知识和经验，最后形成三领域优秀实践：政策与标准、组织措施和安全功能。

1.1 智能汽车的网络安全

智能汽车通过集成物联网元件从而为驾驶者和乘客提供增值服务，这些物联网元件不仅各自互相通讯，还与外部的其他车辆或服务等相互链接。

攻击汽车系统并不鲜见，有些攻击根本就是在媒体面前进行演示，再加上部分攻击可能非常容易而且所需道具极为廉价，汽车厂商更是颜面大失。曾有一个少年做过一次攻击演示，仅使用区区15美元的简易电动马达就远程解锁并发动了一台联网汽车。对于厂商而言，网络安全不仅仅只是面子问题，也是实实在在的经济损失，可能一个小小的安全漏洞就遭至召回数量可观的车辆：

● 2015年7月，安全研究人员Charlie Miller和Chris Valasek针对吉普汽车做过一次攻击演示，通过互联网远程接管了一辆由媒体记者驾驶并在高速公路上行使的汽车，成功迫使它驶离路面，此演示最终让吉普汽车召回约140万辆车；

● 对整个行业影响更大的是宝马汽车的ConnectedDrive概念车被安全研究人员攻破，220万辆车被召回；

● 而近期发现部分车辆的“无钥匙进入”部分存在漏洞，估计全球受影响的车辆超过1亿辆；

● 特斯拉电动车被发现有安全漏洞，需要升级车载操作系统。

1.2 范围和目标

主要分析智能汽车的网络安全现状和寻找可行关键因素，重点关注如下三点：

● 联网如何改变车辆的安全模型？

● 层级森严的车辆生态圈如何应对网络安全？

● 网络安全如何整合进现存车辆、人身安全导向的车辆设计理念、汽车这类产品全生命周期等？

设定目标如下：

● 评审和分析智能汽车的架构和接口；

● 研究车辆生态圈的参与者和生命周期；

● 分析智能汽车面临的主要威胁；

● 收集优秀网络安全实践认知；

● 定义优秀实践并分析当前实施中存在的差异；

● 评估目标受众在实施网络安全措施面临的限制因素、障碍、约束等，并探讨可行的激励手段。

1.3 欧盟政策背景

从监管角度看，与智能汽车相关的法规不多，仅如下寥寥数个：

● 欧洲议会在2015年投票决定在2018年4月之后强制实现eCall系统商用化；

● 由于智能汽车包含信息-物理部件，因此也就和以下这两个规章相关：

→ 通用数据保护法规 (General Data Protection Regulation，GDPR)；

→ 网络与信息系统安全指令（Directive on Security of Network and Information Systems，NIS）：对智能汽车中相关部件使用的云服务有影响；

● 除此之外，欧洲议会在2015年发起的旨在强化物联网参与各方沟通机制的物联网创新联盟(AIOTI)，AIOTI的智慧移动工作组已设计部分物联网用例，在该工作组2015年的报告中介绍了部分与汽车产业的进展，大致如下：

→ 欧洲道路运输研究的技术平台（European Technology Platform for Road Transport Research ，ERTRAC）；

→ 欧洲Horizon 2020研究和创新计划；→ C-ITS 部署框架；

→ 欧洲振兴电子元器件及系统计划（Electronic Components and Systems for European Leadership，ECSEL)；

→ 欧洲共同利益重要专案 (Important Project of Common European Interest，IPCEI)；

→ 主要的标准制定组织(Standards Developing Organizations，SDOs)制定的标准、联盟及开源计划；

→ 欧洲基金资助的物联网开源平台FIWARE；

→ 部分国际或企业解决方案。

1.4 目标受众

本报告主要面向三类人群：

● 汽车制造商：汽车制造商根据市场的需求设计新汽车、选择设备，在汽车装配制造中，厂商依赖于供应商提供的各类部件，因此不仅要求供应商提供合格部件，还在功能、网络安全和人身安全等方面对供应商提出要求。除此之外，厂商还必须考虑整车的物理安全性、网络安全性及隐私的设计，尤其是在售后用户还可能添加后续市场部件；

● 一级、二级供应商：车辆生态圈中零部件供应商的层级关系非常明显，从车企到Tier 1、 Tier 2等以链条式将部件供应关系逐层展开；

● 后续市场产品供应商：用户通常购买后续产品辅助驾驶和增强车辆特性，如支持OBDII接口的组件、媒体播放器或第三方的导航系统等。

2 智能汽车的关键要点

2.1 智能汽车的定义

本研究不仅只关注智能乘用车辆的安全，还将其他类型如公交、长途客运等商用车辆涵盖在内。智能汽车定义是“为提高车辆用户体验或安全性而提供联网、增值特性的系统”，可分为信息通讯、联网娱乐信息及车内通讯三类应用。当前对于智能汽车并无统一概念，因此在本报告中也偶用“联网汽车”这一概念。根据SAE-J3016规范，车辆根据自动化能力划分为不同的等级；而在阿姆斯特丹宣言（amsterdam declaration）中将联网汽车与全自动汽车概念做了区分，前者指的是“包含协同驾驶，车辆之间及车路之间可以进行通讯”，而后者指的是可以自主控制和驾驶的车辆，使用的技术包括板载传感器、摄像头、辅助软件、地图等用于侦测周边环境。

如前所述，本报告仅关注目前所涉及到的技术，并不讨论如车车通讯（V2V）、车路协同技术（V2X）等全自动车辆相关的技术。

本研究覆盖的用例如下：

（1）信息通信：在车队管理或地理围栏中的应用示例；

（2）联网娱乐信息：集成多媒体信息展示提供潜在增值服务，如访问应用商店、获取如车速等驾驶信息及如空调等非关键单元的控制等；

（3）车内通讯：典型的则是作为热点，为乘员的各类设备提供网络链接。

图1 SAE J3016驾驶自动化等级与本课题的研究范围示意

2.2 典型架构与关键部件

本节主要列出智能汽车的典型架构及相应的关键部件，当然不同车辆其架构的子网络及协议也不尽相同。

图2 智能汽车高级架构

如图2所示，架构大都采用中心网关相连，车辆各域互不相干，甚至互相独立。如果对各子系统的网络安全要求妥协，则可能会带来相当的风险，同时由于在人身安全、网络安全和隐私等影响将表现不一，因此对智能汽车各组成部件都应当提供恰当的防护。图3展示了智能汽车的关键部件。

图3 智能汽车关键部件

关键部件主要分为如下六类：

● 动力总成控制；

● 底盘控制；

● 车身控制；

● 娱乐信息控制；

● 通讯控制；

● 诊断和维保系统。

2.3 人身安全、网络安全和隐私关注

关键部件将在如下方面影响人身安全：

● 动力总成或底盘ECU和网络被攻破将显然导致难以预料的后果：例如黑客可能非法攻击点火装置、转向、刹车、速度及档位控制，或者驾驶支持（如ABS）；

● 车身ECU和网络一旦受攻击失灵将不仅可能对乘员产生危害，还可能对周边车辆带来干扰，如灯光、转向灯、警示灯等；

● 娱乐信息ECU和网络被攻击也有安全隐患：如错误的导航数据让车辆驶入不安全区域、甚至娱乐系统的高音量啸叫也会惊吓到驾驶人员；

针对性的攻击车辆网络也会产生人身安全风险：

● 车内网络（包括CAN总线、胎压监测无线网络）：这类网络中断或被攻击可致车辆失控；

● 车内使用蜂窝通讯连接也可能会对人身安全造成影响，如可通过SMS短消息更新的虚拟固件；

● 车内网络（如蓝牙、Wifi等）与用户手机连接理论上只与娱乐部分模块有关，但研究表明在娱乐模块和驾驶模块中缺乏隔离，将导致产生接入端脆弱点，此问题同样可扩展到使用无线遥控的网络链路中；

● V2X通讯如果被干扰或欺骗可能引发事故；

● 对eCall或警告警报进行干扰极可能引发事故；

网络安全风险体现在如下方面：

● 攻击者可获得并非为用户提供的功能的访问权（如车队管理、行车记录仪、地理围栏等），可能提供虚假态势，一方面可能引发车辆系统失灵，另一方面也可能因为司机分心而酿成重大事故；

● 系统可能会对商业秘密有影响：如对厂商保持竞争优势有帮助的TCU/ECU固件，这类厂商尤其需要防止设备被克隆；

● 组合多个部件实现的功能特性，如ADAS若集成不妥当将使风险急剧增加；

● 知识产权易被侵犯：智能汽车应用、娱乐信息应用或相关信息易被破解；

数据机密性和隐私保护也同样存在风险，例如攻破车载摄像头将可能泄露驾驶员和乘客的隐私。

3 威胁和风险分析

3.1 威胁类型

威胁类型仍然延续ENISA的传统，同时根据专家调研进行行业调整，威胁分类如图4所示：

图4 智能汽车威胁分类

3.2 攻击潜力

本研究主要采用CC（Common Criteria，计算机安全国际认证的通用准则）所定义的攻击潜力方法分析，该方法在CC评估体系中进一步细化，并非实地测试。CC评估安全水平基于该产品所能抵御攻击者的攻击潜力，如在产品脆弱性评估过程中，评估者一旦发现潜在的漏洞后，将计算攻击者利用该漏洞所需的攻击潜力，若攻击被利用的可能性低于产品预期的抵御能力，即为该项评估任务失败。该方法评估或估算要点如下：

● 识别和利用该漏洞所需的时间；

● 专业技能要求；

● 对该产品的设计与运行所应具备的知识；

● 时机窗口；

● 利用该漏洞所需的专用IT软硬件或其他需求；

在实践中即便某些产品非常容易被攻破，但利用这些脆弱点可能需要比产品抵御能力更高的专业知识、资源或动机。CC认证定义了评估保证级别（Evaluation Assurance Level，EAL ），获得更高等级的EAL认证意味着产品具有更强的抵御能力。

但在现实中攻击者的攻击潜力随着时间的推移而增加，因为攻击者可获得更多关于汽车系统的专门知识和经验，可能还会设计更复杂的工具，而且攻击潜力有时可能会迅速增长，如黑客老手发布相关漏洞及其使用介绍，新手可能迅速利用并组织攻击，因此认证工作也应当根据场景差异及潜在需求进行调整。

3.3 网络攻击示例

表1列出智能汽车面临的威胁攻击示例：

3.4 远程攻击场景示例

在本报告中实际展现了四类攻击场景：远程攻击、持续车辆改变、偷盗和监视，本文节选了远程攻击场景介绍，远程攻击一般认为将可能对乘员物理安全造成威胁，相关场景如表2所示：

表1 网络攻击示例

威胁　攻击　经验教训中间人攻击设计和计划不足或应用受限偷盗研究人员演示了远程无钥匙进入和启动系统的相关攻击，该漏洞由于加密系统存在缺陷，实际早在2005年就出现，而且利用此漏洞只需极为廉价的设备以及很短的利用时间，野外易于导致车辆被盗。有漏洞的加密体系。超限使用系统或设备的超级管理权限偷盗在无钥匙进入和免钥匙启动系统中，这类有管理员权限的设备原本是给车辆经销商和修理厂所使用。尤其对于维护设备等需要身份识别、谨慎授权和认证以获得管理权限。信息泄露、滥用信息泄露监视研究人员曾利用ITS通讯接口使用专用硬件验证和评估中等距离的监视攻击。中等距离的监视攻击现实可行；接口（包括ITS接口）缺乏可消解攻击的匿名化手段。

此类攻击似乎在公众想象中应该比较普遍，但攻击可能性微乎其微，也被认为是“不大可能”，但此攻击成功会会带来毁灭性的后果。远程攻击场景可参见图5粗略示意：

表2 远程攻击场景示例

?

图5 智能汽车远程攻击场景示意

解释如下：

（1）第一步，攻击者可能已知车辆型号中有一个短信（SMS）链接漏洞连接，并且知道其移动识别号（MSIN），还能根据MSIN按序分配的规律，进而发现其他脆弱的车辆。

由于智能汽车的攻击面非常大因此确认类似漏洞代价较高的，如果车辆的直接IP连接受到很好的保护，攻击者还可以转移到类似短信这样的接入点；

通过攻击蜂窝网络（如“伪基站”）可能成功，但与其他攻击手段如直接网络攻击相比还是过于复杂；

（2）第二步，利用短信更新无需认证的漏洞，上传精心伪造的TCU固件。

有个极端的示例：攻击者通常意图对某类TCU的访问，但这种访问的有用性基于是否是简单会话、是否为高特权会话或能否更新恶意固件等条件而有所不同，将对后续第三及最后一步的结果产生影响。

（3）最后一步，制作的固件能合法地与CAN总线进行通讯，允许与驾驶系统交互。

造成的后果也大相径庭，可以是轻微的破坏（如激活喇叭），有可能出现危及生命的情况，如使刹车失灵、停止发动机或激活气囊等。

描述完整的场景需要若干漏洞按顺序逐个利用，要实现类似攻击其实很难。试图在车辆CAN总线上发送精心设计的消息来欺骗ECU执行恶意操作并非轻而易举。应当留意，此类攻击有可能来自意想不到的地方，例如数字音频广播（DAB）接收机甚至车载调频无线电数据系统。

4 现状差异分析和优秀实践

4.1 差异及挑战

智能汽车当前主要在三个领域存在差异及挑战：设计和开发不安全、责任、人身安全与网络安全流程整合。

（1）设计和开发不安全

虽然汽车工业在人身安全方面有着悠久的专门知识，但大多数厂商联网汽车中的网络安全问题及其对汽车安全性的潜在影响了解不足。部分研究已经尽力定义常被厂商忽略的网络安全问题清单，在经过访谈后复核这类问题后，我们认为如下问题值得认真对待：

● 系统设计时未考虑纵深防御策略：如安全引导过程、隔离可信计算基础、限制开放端口、自我防护等；

● 未采取设计即安全性或设计即隐私的方法：如信息通讯方案可能要求车辆制造商将大部分在CAN总线上交换的信息发送给第三方，例如车辆速度、节气门位置、冷却液和油温、发动机工作状态等，但部分数据并非外界真实需要，虽然有些参与者意识到不应该毫无理由地导出私有数据，但该原则并未普遍应用到敏感数据的处理上；

● 内外部接口均缺乏通讯保护；

● 普遍缺乏认证和授权，尤其是需要有特权访问ECU，如：

→ 固件更新无需验证或签署；

→ 更新过程无服务器许可，甚至不指定来源服务器；

→ 无安全引导；

→ 无手机认证，或采用弱认证机制，或不通过提供身份认证功能组件等；

→ 未给修理厂分发加密密钥。

● 匮乏硬化手段，如：

→ 未在固件中设置数据执行保护或攻击缓解技术；

→ 常见漏洞也置之不理，如DNS代理、HTTP服务等；

→ ECU服务暴露给不同接入点，开放不必要的通信端口，所有网卡均绑定一些如Telnet、SSH 、Web服务；

→ 弱密码政策；

→ 配置错误（如VPN）。

● 匮乏诊断和回应能力。

完全不同的安全文化：

智能汽车生态圈参与方来自不同领域，就是使得安全理解差异极大，如精于软件的参与者更喜欢使用“无线更新”，而且愿意和白帽黑客合作或者采用漏洞悬赏计划。

我们一直倡导在安全研究人员和产业之间创立一个对话机制，确保整个社区建立一个“负责任”的漏洞披露流程。但现状实在差的离谱，主要表现如下：

● 由于厂商和安全人员之间可能存在法律风险，部分研究成果一直未公开，有的可利用漏洞甚至暴露在外无人处置长达两年之久；

● 还有研究人员因为厂商不积极回应而选择向媒体公布漏洞，但厂商此时尚没有漏洞修复计划；

● 有些厂家并不总是及时更新软件，将使汽车设备的已知漏洞（如在软件框架中早就发现的SSL库或浏览器库漏洞）迟迟得不到更新，但即便厂商及时更新，由于极少可远程更新，往往还需要车主使用USB设备来安装更新或只能去汽车经销商的修理厂；

● 通过访谈也证实了实践中不重视日志等安全功能这一观点，而这些功能在安全性诊断中不可或缺。

（2）责任

研究表明，多数用户关心的是在车辆中因集成联网功能而产生的网络安全问题。拿智能汽车连接智能手机后出现漏洞来说，一旦发生安全事件，用户将对指责整个生态系统的参与各方，包括应用商店、应用程序开发商和厂商等。另外，由于无法将驾驶系统、调试和信息娱乐系统等相互之间圆满隔离，这意味着包括售后市场组件之内的任一参与方，都可能危及车辆的安全相关特性。因此有必要明晰各参与方在发生安全事件时应当承担的责任。

（3）人身安全与网络安全流程整合

汽车产业的发展过程已充分考虑到人身安全问题，尽管这些过程包括明确的安全措施，但在车辆开发周期中总体集成人身安全和网络安全方面事务仍缺乏共同标准。

对于那些试图构建安全开发过程的人来说，缺乏共同的车辆安全技术标准将是个不小的负担。最终加上这个层级森严的生态系统所特有的复杂性所带来的供应链障碍及组件之间的粘合代码等问题。

已有的措施和局限性：

SAE-J 3061系其中一个解决智能汽车安全事项的规范，致力于实现安全的产品，具有极强的安全性要求和明确的安全工程流程。

该体系力图在车辆开发方法中区分系统级和车辆级问题，既要考虑安全问题，还要相容于产业生命周期。因此，该体系有可能适用于智能汽车领域，但还是缺乏诸多可操作的细部，如SAE-J 3061并未明确如何解决如下问题：

● 智能车辆有异常大的攻击面（有大量的接入点和各种攻击方法）；

● 攻击者易于接触到此产品和后果严重（对用户及其他车辆产生安全后果）这两个问题叠加；

● 由于产品的寿命较长因此威胁同样持久；

● 事实上智能化的特点并非车辆的核心功能。

另外还有数个行业举措同样可用于定义汽车行业实施安全的准则或规则（见图6所示），当然汽车产业也同样呼吁在安全事务方面进行协作。虽然如ISO／AWI 21434等也在发展，但都还称不上是标准。与航空安全或智能卡安全领域的标准完整性和一致性相比，汽车产业相距甚远。

图6 智能汽车远程攻击场景示意

当前尚未有认证框架可作为安全评估或安全测试的标准，能在产品发布之前检测漏洞。现有认证框架存在物理安全特性，例如自动刹车系统等；但大多数行业参与者对网络安全认证的概念和方法仍然是陌生的（如渗透测试的概念）。

其他行业如航空系统已最终定义了独有的体系框架，但一旦面临层级森严的场合，通常的认证标准会被认为是不切实际的。若对汽车产品采用同样方法，首先应当谨慎评估这种努力是否已在实践中取得成功。

技术标准的特殊问题：

缺乏统一标准最终会带来附加的安全问题：如车辆若干关键部件系采用专有技术开发（常见的是CAN通信所使用的协议），这种情况存在将使得第三方供应商更难开发适用于大市场的安全解决方案（如防火墙或入侵检测），因此也很难有效地降低厂商的安全成本。

其他问题：供应链和代码复用的影响

汽车制造业层级森严的生态系统信任带来安全集成问题，有可能后续市场产品都要共享车载总线，这会带来重大风险。如TCU等单元可以由制造商、各层级供应商、售后市场供应商提供，这从理论上讲同等安全或同样脆弱，若从补救角度看，由层级供应商或后续市场产品供应商提供ECU或将更有价值。

正如研究人员一直所强调的一样，从定义划分后续市场产品的安全问题不能由制造商控制，但在实践中售后市场供应商又被认定能提供完全支持，基于供应链关系的复杂性，即便厂商已发布安全补丁的情况下，最终还是得不到部署。

其他研究则强调在生产中整合软硬件所带来的问题，特别是部分参与者套用在以往安全问题上的经验将使他们分离软件和硬件问题，从而忽略全局安全漏洞。更普遍的情况是，外包模式中由于对第三方代码的安全假设理解不够，会导致粘合代码和安全方面的缺陷。认识到业界为整合物理安全和网络安全方法所做的努力，就应当在这些活动和供应链参与者之间设定明确的同步点。

行业等级森严的生态环境带来诸多问题，如安全补丁本身需要在整个供应链中验证后才可以部署，但往往现实中即便二级供应商已完成开发和分发补丁，这些安全补丁还是无法部署。

4.2 约束及激励因素

智能汽车网络安全的动态发展既有约束，也有激励因素。约束主要存在于用例及架构；而激励因素主要有三类：商业因素、顾客因素和规制与基础设施，如表3所示：

4.3 优秀实践

优秀实践主要分为三类：政策与标准、组织措施和技术，如图7所示：

表3 激励因素

（注：字体加粗表示该选项更为重要）

图7 智能汽车领域的优秀实践

5 七点建议

5.1 提高智能汽车网络安全

适用于：智能汽车制造商、各层级供应商和售后市场供应商。

这也是最显而易见的建议：行业参与者必须为其产品设立全面的安全开发流程，应包含设计、开发、测试和安全维护。本报告构建优秀实践提供了出发点，期望行业参与者积极采纳，有效地提高其产品的安全性。通过这套优秀实践，帮助行业能够克服不安全的设计或开发过程带来的挑战。

5.2 促进行业参与者之间的信息共享

适用于：智能汽车制造商、各层级供应商和售后市场供应商。

信息共享非常必要，有助于行业参与者取得如下优势：

● 利益相关者（汽车制造商、各层级供应商等）之间建立信任关系；

● 共同制定、接受标准；

● 通过普遍接受的做法来促成整合；

● 帮助行业参与者找到各自安全机制的对策和挑战；

● 提供一种机制来锻炼和开发安全团队的技能

● 支持安全检测和消解安全问题。

因此利益相关者应该及时分享和研讨市面上发现的新攻击，协助整个社区寻找对策，信息共享也将有助于克服不安全的设计或开发过程带来的挑战。

存在信息共享框架，可让其他产业参与者、实验室或国家机构等共同应对相关事项，也是提高安全团队技能的有效途径之一，类似的信息共享社区已有美国的Auto-ISAC、ENISA的CarSEC工作组等。

5.3 明确行业参与者各方责任

适用于：智能汽车制造商、各层级供应商、售后市场供应商和保险公司。

在报告的前面部分明确了责任将带来行业挑战的观点，责任问题应当解决，责任也应在各层级供应商、厂商、销售商、售后支持运营商和最终用户之间分摊，责任分担也必须在国家立法和判例法的范围内处理。如果在国家立法中发现差距，则应加以解决。

标准和流程：

有多种方法可用来定义标准和过程从而明确网络安全问题中的责任，示例如下：

● 硬件厂商可采用“担责”来认证硬件。如果操作系统或运行环境符合硬件安全指南，则硬件供应商应对硬件中出现的任何问题承担责任；

● 操作系统或运行环境的供应商也同样采用“担责”来进行组合产品认证（包括运行环境和特定的安全硬件）。假设使用符合特定的规则，供应商应承担任何在操作系统或运行环境发生的问题带来的责任。需要注意的是这些规则应可自动验证，通常采用代码分析。如当程序被提交到应用程序商店时，就可以执行此类分析。

本例遵从CC评估方案的实践，也是如今智能卡环境所采用的方法。虽然不建议智能汽车制造商直接采纳CC方案，但类似的方法将有助于保证：

● 给定的硬件是ECU安全的基础；

● 给定操作系统在特定硬件应用是安全的；

● 为应用程序定义清晰、易于验证的规则，使应用程序不危及操作系统安全。

虽然人们普遍认为要为前述几点内容提供证据，但遵循的流程应有所不同。

保证这类系统安全首先是构建健壮的、清晰的安全规范，这些规范将贯穿开发和部署汽车的整个生命周期，遵循规范的证据应该有系统地提供。通过执行安全评估和（或）认证，应基于被广泛采用的认证计划，通过验证可以确认这类需求的执行情况。

汽车行业参与者也同样受到产品责任的法律法规（包括“智能”设备）的约束，其中也应包含由分包商提供的系统或服务。因此厂商应与其分包商、产品责任保险公司等及早接触，合约可以用来维护每个参与者的权益。

5.4 就优秀实践的技术标准达成共识

适用于：产业团体和协会。

本报告列出了一些优秀实践，并不意味着就可直接应用于车辆设计，它们只是作为标准化努力的输入。行业参与者应该认识到，智能汽车的安全标准应满足这些优秀实践中描述的全部类别，从而达成安全智能。另一方面，安全需求的细节必须在实际产品中认真构建，本报告建议不同参与方之间应将透明和共享作为首要出发点。

本次调研参与者均不建议再试图创建全新的适用于现有和未来汽车的全球标准，不同的参与者可使用和组合现行标准，更好地在自身的用例中应用，形成共识应该是各标准、规范和内部解决方案之间的中庸之道。

5.5 定义独立第三方评估方案

适用于：产业团体和协会。

随着厂商安全意识的增强，现在对产品的生命周期中提出安全性要求：

● 产品的设计阶段即提出安全需求；

● 产品一旦准备就绪即进行安全验证，复核安全功能的需求和健壮性；

● 通过更新来维护产品安全。

然而汽车行业目前评估网络安全依然以采用类似人身安全的手段（遵循如ISO 26262或MISRA等方法）为主，这类标准可表面性的解决网络安全问题，的确能减少故障和失误（包括随机和系统性的故障），但并不能防止被攻击。

这个问题与人身安全和网络安全流程集成相关，为了克服这一障碍，行业应该确认安全认证过程，明确地处理用例滥用和攻击，有必要的进行网络攻击模拟（亦即渗透测试）。

如同验证测试主要基于规范，渗透测试需要不同的技能和心态，为此建议在现有技能、安全人员已使用的评估方案的基础上再重新整合。

例如可发起一个车车通讯联盟，在CC认证EAL 4级基础上定义车载通信设备的CC保护轮廓（Protection Profile，PP），该PP可不必包含本报告优秀实践中全部类别。

但应确保统一标准方案，在国家网络安全机构监督下，由第三方实验室遵循标准程序进行安全评估。

一些倡议要求在汽车行业的安全主题上进行协作，并建议在渗透测试中采用专门的安全测试，AUTOSAR和GENIVI已经着手创建了自己的安全项目，均由安全专家牵头。

我们建议业界这些先行者基础上，明确安全认证的共享标准。需要明确应当使用何种方法（从基本安全检查到渗透测试）、根据要测试的组件确定预期检测数量和测试的深度，以及这些测试的信任模型（谁有权授予第三方安全评估审核员的认证证书）。

5.6 构建安全分析工具

适用于：产业团体、协会和安全公司。

行业参与者可采用类似方法来提高安全测试技能，特别是专用工具的开发，应与相关活动密切有关。软件行业中很多已开发的工具易于复用而无需进行重大修改。

本报告为定义工具提供了部分尝试：

● 关键部件识别：见2.2节关键部件分类；

● 威胁模型：

● 见3.1节威胁类型；

● 另见附录中提供的示例场景和基于TVRA方法的风险评级公式。

行业参与者可尝试使用这类工具，也可为工具做出贡献：

● 在开发过程中通过静态分析来实现安全，可在车辆情境下进行规则调整；

● 安全测试：如定义模糊测试工具；

● 安全监测：如在CAN等技术中定义入侵检测。

5.7 加强与安全研究人员和第三方的交流

适用于：智能汽车制造商、各层级供应商和售后市场供应商。

在研究人员、学术界和业界之间建立沟通渠道对参与各方都大有裨益，为推动交流，可组织研讨班、会议、工作组等，诸如责任披露准则、漏洞悬赏计划等工具也对加强信息交流特别有价值。

此类交流对该车辆产业显然有益，这样从系统生命周期的早期到实现和部署，都能兼顾网络安全需求。

6 小结

智能汽车领域在中国已被明确为战略性新兴产业，按照国家发改委发布的《智能汽车创新发展战略（征求意见稿）》中提出的目标，到2020年新增车辆智能化比例达到50%，2025年新车基本实现智能化，这不仅有利于民生，同时也是增强中国制造业核心竞争力的行动计划之一。因此，需要对智能汽车基础安全保持足够关注，制定智能汽车安全需求规范，设立与之相应的网络安全架构、统一的网络安全需求、标准体系及相应的检测认证，并完善相关法律法规，形成有效监管，尽早实现产业化。

ENISA的这份报告也可为我国进行智能汽车产业推进及相关法律法规的拟订提供参考，相关观点和方法也可为我国设计、制造更安全的智能汽车提供有益的借鉴。