汽车工程师如何敲出更“安全”的代码，“硬核”工具春天来了

“软件供应链安全在2022年将比以往任何时候都更加重要&＃xff0c;”近日在CES展上&＃xff0c;黑莓公司预测&＃xff0c;进一步加大软件定义汽车的开发模式进入深水区&＃xff0c;安全、可靠的用户体验将成为重要里程碑&＃xff0c;汽车制造商将迈向数据驱动的未来。

几周前&＃xff0c;当Apache软件基金会&＃xff08;Apache Software Foundation&＃xff09;披露其Java日志库Log4j存在一个巨大的安全漏洞时&＃xff0c;与车辆通信相关的应用服务器也成为被“潜在攻击”的对象。

类似的安全预警&＃xff0c;在汽车行业已经并非新鲜事。

2019年&＃xff0c;一名白帽黑客发现特斯拉的跨站脚本攻击漏洞 (XSS) 可以被用来非授权地获取其他车辆信息&＃xff0c;例如车辆的VIN、速度、温度、胎压等等信息。

一年后&＃xff0c;比利时安全研究人员发现特斯拉Model X密钥卡存在漏洞可用来快速解锁车辆。攻击者可以使用从旧的Model X车辆中回收的电子控制单元&＃xff08;ECU&＃xff09;来利用此漏洞。

去年5月&＃xff0c;德国的两名安全研究员公布了Tbone漏洞&＃xff08;wifi热点&＃xff09;&＃xff0c;可实现无接触对特斯拉的近距离攻击&＃xff0c;通过操控一辆无人机实现了开启特斯拉的后备箱&＃xff0c;解锁等操作。

为此&＃xff0c;特斯拉还有一个专门的官方漏洞奖励计划&＃xff0c;并且还为发现安全漏洞的工程师设立了“安全研究人员名人堂”&＃xff0c;从而提高特斯拉的产品和服务安全。

由于高阶智能驾驶系统的不断增加&＃xff0c;以及未来车路协同数据交互的落地&＃xff0c;汽车制造商以及监管机构对安全性的关注&＃xff0c;尤其是软件安全&＃xff0c;是一大变化。

在西门子EDA汽车集成电路测试解决方案负责人看来&＃xff0c;多层安全性和设备可靠性将是接下来智能汽车面临的最大挑战之一。此外&＃xff0c;车辆联网成为标配之后&＃xff0c;确保外部无法访问敏感数据也是关键工程难题。

这意味着&＃xff0c;围绕安全测试和监控的需求已成为主流。

比如&＃xff0c;过去几十年汽车行业的零部件召回问题&＃xff0c;很多时候只是因为有少部分车辆出现问题&＃xff0c;并且不会出现大面积的同时出现。汽车制造商可以通过大规模召回&＃xff0c;来避免故障的“暴露”。

但&＃xff0c;网络安全改变了这个范式。

“如果一辆存在软件安全漏洞的车辆被攻击&＃xff0c;那么路上所有搭载统一版本软件的车辆都有可能受到攻击&＃xff0c;这意味着漏洞可以在同一时间攻击所有的汽车。”在行业人士看来&＃xff0c;整车OTA、V2X等不断增加的外部通信&＃xff0c;也在大幅提升网络安全的重要性。

当然&＃xff0c; 值得庆幸的是&＃xff0c;目前全球范围内还没有重大的汽车软件安全事故发生。信息娱乐系统、网关及车身控制是比较常见的受攻击部位。

比如&＃xff0c;去年初&＃xff0c;一名安全研究人员入侵了日产Xterra车上来自博世的信息娱乐系统&＃xff0c;通过插入一个USB设备&＃xff0c;可以获得对系统的root shell访问权限&＃xff0c;并获得安装未经授权软件的权限。

按照汽车网络安全公司Upstream Security给出的报告&＃xff0c;还有很多汽车制造商在不同车型上安装了类似的博世信息娱乐系统&＃xff0c;这可能会使他们面临同样的风险。

实际上&＃xff0c;在传统的开发模式下&＃xff0c;并非所有汽车制造商都会追踪与上述组件相关的潜在网络安全漏洞。这意味着&＃xff0c;谁都不清楚&＃xff0c;博世是否解决了全球数百万辆搭载类似系统的漏洞。

而过去多层级的供应链关系&＃xff0c;更是让汽车制造商无从下手。这一点&＃xff0c;从已经正式发布的UNECE WP.29 R155法规和ISO/SAE 21434标准中都要求对供应链进行安全管理&＃xff0c;可见一斑。

在云驰未来副总裁杨洋看来&＃xff0c;智能网联汽车的信息及网络安全需要在产品规划阶段就开始考虑&＃xff0c;只有这样才能将安全融入到架构设计、软硬件开发、测试、量产以及售后的全生命周期。

比如&＃xff0c;WP.29 R155规定&＃xff0c;供应链网络安全管理的责任在于汽车制造商&＃xff0c;后者有责任确保所有汽车零部件&＃xff08;包括硬件和软件&＃xff09;的安全。而ISO/SAE 21434标准还强调了供应链管理的重要性&＃xff0c;比如汽车制造商与一级和二级供应商之间的网络安全关系。

而随着整车电子架构的集中化趋势&＃xff0c;软硬解耦以及模块化配置趋势&＃xff0c;意味汽车制造商未来更加多元化的软硬件合作伙伴需要一个“统一”的嵌入式安全管理模块。

比如&＃xff0c;云驰未来推出的车联网安全中间件是面向未来的、集中式电子电气架构设计的信息安全软件框架&＃xff0c;可以被集成到域控系统中&＃xff0c;为各个车内的域控系统&＃xff08;如动力域、底盘域、自动驾驶域等&＃xff09;提供安全能力。

Upstream Security推出的AutoThreat®工具&＃xff0c;则是通过记录车辆、组件和基础设施级别的安全漏洞&＃xff0c;并提供与单个车型相关的ECU和漏洞映射&＃xff0c;来检测车辆组件和设备漏洞。同时&＃xff0c;通过各种威胁分析工具&＃xff0c;捕获各种威胁指标。

云驰未来也在近日重磅发布了国内第一款自主研发的高度自动化车辆信息安全威胁分析与风险评估的TARA工具——InTARA&＃xff0c;使用者可以通过图形化界面和建模方法编辑管理与安全分析评估工作&＃xff0c;大幅提升了安全分析师的工作效率。

对于软件定义汽车进程的下一个阶段重点&＃xff0c;来自大陆集团的软件战略主管Martin Schleicher认为&＃xff0c;在实现这一目标之前&＃xff0c;我们必须彻底解决一系列工程问题。“尤其是软件复杂性的急剧增长&＃xff0c;给安全管理带来了巨大挑战。”

可扩展的嵌入式边缘开放架构(SOAFEE)&＃xff0c;是一个由Arm牵头&＃xff0c;联合大众集团旗下软件子公司Cariad、博世、大陆集团、Green Hills、Marvell、红帽、丰田旗下软件子公司Woven Planet等汽车行业主要玩家合作构建的下一代软件架构和参考设计。

SOAFEE在开发基于Arm平台的汽车软件方面&＃xff0c;加速了云原生技术在汽车软件开发和部署方面的应用&＃xff0c;涉及软件可移植性、更快的开发时间和更低的成本&＃xff0c;并且集成了多种主流软件开发技术&＃xff0c;包括软件容器、微服务体系结构、虚拟化和DevOps等。

作为持续集成、持续交付的工作流&＃xff0c;DevOps在汽车生命周期内的软件管理方面将起到重要的作用&＃xff0c;包括网络安全、漏洞修复、功能软件更新等等&＃xff0c;后者也被持续融入DevOps每个阶段过程。

这背后&＃xff0c;类似TARA分析工具这样的安全工具成为市场焦点。

在ISO/SAE 21434汽车网络安全标准中&＃xff0c;讨论的焦点就在威胁分析与风险评估&＃xff08;Threat Analysis and Risk Assessment&＃xff0c;TARA&＃xff09;&＃xff0c;主要是将外部威胁纳入安全评估。企业在整个车辆生命周期中需要对潜在网络威胁进行威胁分析和风险评估&＃xff0c;监控网络安全事件。

根据ISO/SAE 21434标准&＃xff0c;联网汽车的所有电子系统&＃xff0c;从概念设计到生产再到最终报废的每个阶段&＃xff0c;都必须考虑到网络安全&＃xff0c;系统的设计必须能够为不断变化的威胁提供强有力的保护。上述标准定义的要求必须嵌入到公司的组织DNA中&＃xff0c;包括一套完整的网络安全管理系统(CSMS)。

按照云驰未来的介绍&＃xff0c;InTARA完全支持ISO21434中对于TARA过程的要求&＃xff0c;包括分析对象、可以完整的编辑评估对象涵盖的内容、资产识别和影响评估、分析威胁场景和攻击路径和按照需求模板输出评估报告等步骤&＃xff0c;企业通过对信息安全相关项进行TARA分析就可以得到产品信息安全目标。

与此同时&＃xff0c;云驰未来的InTARA软件以工程文件的形式保存数据与评估结果&＃xff0c;并且支持与后台服务器通信实现数据共享与业务协同。

此外&＃xff0c;与市场上其他TARA分析工具不同&＃xff0c;云驰未来的InTARA有明确的导航指示&＃xff0c;可以帮助用户快速了解业务位置与进度。同时&＃xff0c;InTARA还可以自主学习历史TARA数据&＃xff0c;面对全新的评估对象实现更迅速的脆弱性发现。

在具体的商业模式上&＃xff0c;云驰未来提供免费License的方式&＃xff0c;向OEM或Tire1提供TARA工具使用权。另一方面&＃xff0c;还可以结合TARA工具中给出的风险应对建议&＃xff0c;为客户提供系列的安全产品&＃xff0c;比如车联网安全中间件、安全合规咨询与技术服务等。

而行业现状是&＃xff0c;比如&＃xff0c;软件分析安全测试(SAST)并不是敏捷开发的&＃xff0c;大部分是人工&＃xff08;有些企业采用的是模糊测试&＃xff09;一行一行地检查代码。同时&＃xff0c;也缺乏必要的自动化验证手段。

此前&＃xff0c;包括GitHub和GitLab在内的平台&＃xff0c;都已经进入了应用程序安全测试市场&＃xff0c;强调开发人员编写安全代码的必要性。其中&＃xff0c;后者在支持企业软件开发过程实现ISO26262的功能安全遵从性。

事实上&＃xff0c;随着软件在整车价值占比的快速提升&＃xff0c;代码质量以及网络安全&＃xff08;代码漏洞&＃xff09;不再是“事后监管”。比如&＃xff0c;一款自动化且高效的TARA分析工具能够极大地解决主机厂及Tier1厂商的潜在威胁和安全漏洞分析难题。

此外&＃xff0c;目前OTA所处阶段大部分仍是以软件Bug修复、功能更新以及付费订阅为主&＃xff1b;而以特斯拉、小鹏汽车为代表的一批企业已经开启“软件即服务”阶段&＃xff0c;代表性功能就是远程诊断及修复&＃xff0c;也就是常说的DOTA。

相较于传统的诊断方案&＃xff0c;以科络达为代表的OTA厂商正在推动量产的远程诊断技术使诊断由被动变为主动&＃xff0c;能够随时或者定期对车辆进行远程诊断&＃xff0c;并远程修复故障。

市场的多管齐下&＃xff0c;正在打开汽车软件开发及网络安全的新赛道。从某种角度来看&＃xff0c;类似的第三方平台、工具的增值空间将远高于传统的软件外包开发。