关于车联网网络安全开发的思考

网络安全威胁将成为未来车企的主要市场责任之一。国内网络安全正在逐渐完善法规，以GBT40856为例，国内标准具有很强的落地指导作用，能够客观全面地识别车辆信息交互系统中的信息安全隐患。

上汽大众网络安全经理吴建建表示，持续的安全软件开发文化，无论采用瀑布、敏捷还是DevOps策略，持续的安全软件开发思想文化需要被贯彻到开发过程的所有阶段，包括需求、设计、开发、测试和发布。将车端网络安全开发融入到传统产品开发流程中，车型立项之初就要制定该车型的网络安全政策文件，定义该车型采用的网络安全目标、风险分析模型、TARA方法论、风险管理办法、风险接受流程等。在零部件定点的同时签署CIA，明确供应链责任，完善网络安全开发流程。

吴建建 | 上汽大众网络安全经理

以下为演讲内容整理：

车联网网络安全的挑战

信息安全涵盖车端和后台，所有的链路很复杂，车辆对外的通讯接口很多。现在有个流行的说法，汽车正在变成轮子上的计算机，这使得汽车成为一种新的诱人目标，吸引大量的网络攻击。这些网络攻击不仅来自传统，还来自于专业的组织。如下图所示，像典型的重放攻击、密码攻击、蓝牙中继攻击等。

图源：上汽大众

关于网络安全风险的态势，我查找了些2022年的报告。数据显示，2022年整年，有300起媒体报道的安全事件；2023年3月，意大利个人数据保护局禁止使用ChatGPT，并暂时限制OpenAI处理意大利用户数据；另外是今年2月北京的一个友商因数据泄密问题，被法院判决；最严重的是去年7月，某网约车因违反《网络安全法》《数据安全法》《个人信息保护法》被罚款近百亿元。关于网络安全漏洞的数量，有报告显示，其增长态势非常迅猛，已接近成倍的数量。

图源：上汽大众

这么多人利用漏洞对我们的车辆发起攻击，到底是谁在攻击呢？专业化的黑客组织就是其中之一。漏洞到底分布在哪里？从报告上看，最严重的是在芯片上；其次是整车，以及基础软件模块的供应商。

网络安全法律法规

网络安全政策法规的发行越来越密集，从2017年《网络安全法》出台到今年3月广东会议结束，软件升级基本冻结了。

国内的法规与国际还是有差异的。我国的法规有一个体系：会有一个法规，还有大量的政策文件。在欧洲可能一个法规，跟一个标准就结束了。而我们要要考虑到大量的政策文件，这些政策文件搞不准什么时间就发布了。网络安全工作者需要持续关注，我们的输入源非常多，落地的标准较具化，所以一些指导文件还需要行业群策群力，共同去解读。

例如，关于GBT标准40856，就是大家共同做的GBT标准。下图是该标准最基础的结构，与大家常提到的网络安全的各种手段措施、架构体系惊人的一致。在我们寻找解决方案时，GBT已经可以解决大部分问题，前提是我们在严格遵守，或直接将该标准引入到开发中。

图源：上汽大众

网络安全应对措施

在体系架构层面，网络安全从公司体系来讲是跨部门的，作为网络安全工作者，要推动从开发、测试、运营、质量、生产的各个部门，甚至采购部门的安全工作。一个5-10人的网络安全小组不可能完成整车厂的网络安全。最近，我也看到一些友商分享的网络安全管理的关键模块。就我个人而言，风险管理、应急响应、风险监控和开发大家都会做，但若想做好，可以进一步细化。我们主要参考21434，每个模块都有独立部门去领导，当发现问题、评估风险时，有个专业的人可以站出来精细化地提升。

图源：上汽大众

有了体系结构后，要把信息安全、网络安全理念开发出来，还存在着一个问题：对很多供应商而言，信息安全是新的事物，大家都在齐头并进，导入在线融合，引入新的信息安全基因，但这个毕竟还需要时间。我们没有办法一次性把供应商全部拉齐。首先从法律意义上，我们要传递责任，CIA是较好的传导网络安全责任的手段。我们在很多项目上，一旦识别出零件是网络安全的，做完整车预分析发现属于关键系统，就与车机供应商在定点的同时签署CIA，避免后签或者补签。但实际工作中，CIA还远远不够。我们可能很擅长开发零件，再去开发一个网络安全零件似乎没什么大问题。但网络安全零件会持续更新，在SOP时，该零件的确具备了网络安全特性，是合规的，但漏洞每天都在产生，操作系统不断升级，内核年年变。CIA只定义了供应商有升级的义务，但没定义代价是多少。我们对此有些思考，也有一些应对手段，在CIA基础上，补充网络安全基础要求，从义务和成本控制上双重落实。

作为主机厂，我们要积极的加入标准组织；要履行安全开发责任，安全开发是一个全新的程，在开发中引入风险处置，要创立企业自己的网络安全工具具箱（安全基线）。

如果未来有要更加模块化，或许要把安全组件直接标准化。目前行业也在推SDK，每家SDK都不相同，做安全测试和安全认可的工作量就会重复，主机厂也没有办法永远绑定一个SDK厂商。更合理的合作模式或许是由主机厂定义模块，与安全厂商或芯片厂商加强合作，共同定义OEM级安全标准或安全组件，也可以节约Tier1的开发时间。因为即便是很大的Tier1，也可能没有设立单独的安全软件模组开发部门，对于他们而言也是个负担，因为他需要拿着合同，再去找Tier2、Tier3，供应链会特别长。与其如此，为什么不与芯片厂商、HSM、SE或安全启动芯片把启动的方案、启动的BSP、各种安全API直接定下来，一次性用到所有项目？这对主机厂的前期要求较高，我们之前的工作也没下探这么深，所以对双方来讲是很大的挑战。

网络安全测试

安全测试有两个级别：最基本的级别可以称之为安全基线测试，安全基线的测试是主机厂的首要义务，其输出目标应该是让车辆达到准入的水平，可以合规。企业也可以提更高的要求，但我认为那是安全基线外围的测试范围。

总体来看，安全测试至少包含零部件级测试，如果零部件与其他模块交流较少，就用零部件级测试；如果是与用户相关的网联功能，功能级的风险测试就非常必要了。

当前，大家谈信息安全，在与主机厂对接中有个很困惑的问题。安全到底由谁管？关于整车的网络安全，要把云、管、端三个模块连接起来，要定义清楚模块间的握手协议。

就网络安全而言，整车网络安全应该从设计阶段开始嵌入到传统开发的各个阶段，在各个开发部门、各个阀点加入安全检测点，各个开发部门都要有安全概念。

车企如何将网络安全开发融入到工作流程？首先定点是最重要的，定点后，在A样B样时要有安全实现，此时要准备足够多的安全工具。最后是验证，APP和第三方生态引入对主机厂来说，并不是拿来主义，APP不是一定有安全开发和监控的过程，在开发中我们至少要签名和加固，渗透测试也是必须的，监控中对于风险大的APP还要加装探针。

图源：上汽大众

关于残余风险管理，我们会对一些残余风险进行分级，根据残余风险等级不同，对应不同等级的安全责任人进行决策授权。做到对每个风险的处置都有据可查，强化网络安全风险管控。

作为网络安全开发的负责人，下图是我总结的一些安全基线。从控制器到车内的模块与模块，再到整车EE架构，最后是车辆对外通信。从下往上，模块内部至少所有的Spec是完备的。车内零件与零件间，要有常规的SecOC报文认证，IDS入侵检测，IP安全， APP探针。架构手段是最有效的，做到整车的体系认证、安全风险分析、做好预隔离，做好安全网关，把安全域和非安全域分隔开可以节约大量的工作，当然因为要定义一个全新的架构，所以对企业的开发要求很高。对外通信方面，常规的安全防火墙、黑白名单等组成了目前的整车安全基线。  

图源：上汽大众

总而言之，网络安全测试范围应该包含代码审核、符合性测试、漏洞扫描、模糊测试、合规测试、渗透测试六部分。

图源：上汽大众

针对合规，我认为很有必要建立独立的测试。与其把每个合规的功能分散到小模块，不如全部收拢，在出报告、修复问题时，应对审核人员的专业度也会更高，这也是一种方案。

（以上内容来自上汽大众网络安全经理吴建建于2023年4月20日-21日在2023第二届中国汽车信息安全与数据安全大会发表的《车联网网络安全开发思考》主题演讲。）