汽车网络安全--ISO\SAE 21434解读

hudaren43

目录
01.标准总览

02.车灯系统描述

03.车灯系统TARA分析示例

04.车灯系统TARA实操

05.小结

01.标准总览
2015年美国黑帽大会，知名网络安全专家Charlie Miller和Chris Valasek详细描述了他们是如何在有限距离下通过WiFI入侵到Jeep大切诺基的中控系统，从此关于汽车网络安全的讨论拉开了序幕。2016 年，ISO 道路车辆技术委员会与 SAE 联合成立 SC32/WG11 Cybersecurity 网络安全工作组，基于 J3061 参考 V 字模型开发流程，提出从风险评估管理、产品开发、运行/ 维护、流程审核等四方面来保障汽车网络安全工作开展。2021年8月 ，ISO正式发布了汽车信息安全领域首个国际标准ISO/SAE 21434《Road vehicles—Cybersecurity engineering》。目前，国内汽车行业对于汽车网络安全的概念、文化属性和实施必要性还处于萌芽阶段，主要原因在于传统零部件在设计研发阶段基本没有考虑这方面的内容，要改就得大改，产品迭代风险和人员储备风险是一个比较大的考虑，但是随着信息通信技术在智能汽车扮演的角色越来越重，网络安全是怎么也绕不开的一个重要话题。那么我们就借鉴ISO/SAE 21434，看看它是如何指导工程师展开网络安全工作。
我理解，ISO/SAE 21434其实是参照了ISO26262的成功经验，所以文档在结构方面还是有所类似，只是21434面向Security，26262面向Safety。

ISO21434的具体框架如下：



这张图应该很多人都见过，缺少Part 1- 3，分别对应Scope、规范引用(ISO 26262-3)和术语。
从Part5开始每个大框里都有很多字，这里简单描述一下我个人的理解：

Part 5	描述一个组织如何建立起网络安全文化、流程、管理方法等
Part 6	描述针对特定项目如何开展网络安全活动和管理
Part 7	描述网络安全活动中OEM、Tier1\2 之间的交互、依赖关系和责任
Part 8	描述项目中可以在生命周期任何阶段执行的网络安全活动，比如说收集网络安全行管信息、鉴别分析危害事件等
Part 9	描述产品概念阶段所需要完成的目标：定义item、运行环境、明确网络安全目标和网络安全权责、明确网络安全需求等
Part 10	描述在产品开发阶段需完成的目标：细化并验证网络安全需求和架构设计;识别设计中的漏洞并进行相应危害处理;证明产品或者产品组件是符合网络安全规范
Part 11	描述在网络安全验证阶段需要完成的目标：确认item是否满足网络安全目标、剩余风险是否可接收等
Part 12	描述在生产阶段需要完成的目标，防止在生产过程中引入漏洞
Part 13	描述在运营和售后阶段需完成的目标：处理网络安全事故、保证Item更新升级的网络安全
Part 14	描述零部件或者整车在报废时的要求：必须要可信环境下进行处理
Part 15	描述了危害分析和风险评估的方法论

可以看到，ISO/SAE 21434描述了一个项目在全生命周期里对于网络安全的目标或者要求，从开开始的法律法规要求、公司网络安全文化形成，到公司间交互的网络安全权责划分，再落实到具体项目、对应Item的网络安全目标，对产品开发、量产、售后、报废不同阶段提出了相应的网络安全目标，可以说，只有一个件沾上了网络安全，那么网络安全就会一直陪着它从萌芽到死亡。上面说了这么多内容，其实对于传统汽车出身的工程师来说，最关键的还是在于Part15，掌握如何从Security的角度对一个系统进行分析，当然，如果之前就有功能安全的的基础，掌握这个内容还是手拿把攥。
那么我就借标准附录里 H中展示的车灯系统为例，来看看解析下危害分析方法论。

02.车灯系统描述

在ISO/SAE 21434 附录H中，以车灯系统为例展示了TARA的使用方法。整个系统如下：



该系统功能有：夜间照明、根据驾驶员操作切换远近光灯、夜间会车警示等。从上图我们可以看到，车灯开关信号由车身控制器进行处理，然后通过CAN总线发送灯光请求给执行器；从信息安全角度，一旦车身控制器或者网关被劫持，在夜间突然关闭车灯，或者会车突然开远光灯，有很大几率造成人车安全事故。因此有必要从security角度来分析整个系统。在分析之前，首先描述下该系统的组成。车灯系统由车灯开关(输入)、BCM、车灯切换执行机构以及前置摄像头(探测来车)组成，其中BCM和前置摄像头、车灯切换执行机构通过CAN总线连接，此为系统内部构造，那么该系统对外仅与网关通过CAN总线相连；网关最为整车通信的中转站，与其他ECU、导航系统、OBD都通过CAN或者以太网总线连接，因此我们很容易想到黑客的中远程攻击途径有蓝牙、蜂窝数据，近程物理上可以通过OBD口进行攻击。那么接下来，我们就从风险评估开始，开启我们的TARA分析之旅。

03.车灯系统TARA分析示例

可以比较肯定的是，我们定义的item为车灯系统，因此可以看到上图中画出了item boundary；同时定义出运行环境，个人理解，这块就是为TARA分析提供足够的环境支撑，不管是直接还是间接与车灯系统有关系的，都需要列举出来。
有了上述基本概念，我们接着回顾TARA分析方法的八股文：

资产定义 -> 相应破坏场景定义 -> 影响评级 -> 危害场景识别 ->

攻击路径分析 -> 攻击难易程度分级 -> 风险等级定义 -> 风险处理措施

这在标准中也给了我们示例，如下：



不过标准中到最后都没有详细给出风险处理措施，因此接着这个示例继续往下完善，总结TARA每个过程的输入输出、输出物的生命周期以及过程建议。

04.车灯系统TARA实操

在上述描述的TARA分析步骤(15.3 - 15.9)，我们可以理解为是为了给Part 9 产品开发阶段中的活动提供足够的理论支撑，因此Part15中对应这些分析也应该要有产出，产出总结如下：



可以看到，左边均为活动，通过蓝色箭头对应活动产出到右边，然后每个产出物作为下个活动的输入。
以Item定义的产出物为例，它定义了系统框架以及item边界和整体运行环境，例如车灯系统作为Item，定义了运行环境和item边界。这个产出物会作为后续活动的输入，例如item边界可以为网络安全视角下的资产定义做支撑，系统框架可以为攻击路径分析做支撑，同时这两者都可以为风险定义服务，例如什么资产在什么攻击路径下的风险比较高等等。

这些产出应该用什么方法进行量化呢？如下图所示：



有了上述理论支持，我们来看车灯系统如何做TARA分析：
步骤1：这里有一个很明显的资产需要定义，即CAN总线 ，它负责车灯开关、切换的请求传输；任何物理劫持、网络篡改、网络劫持等都会对车灯的开闭有巨大影响。

因此CAN总线对应的CIA特性就有完整性、可用性是必须要满足的。那么通过CIA就可以假想出威胁破坏场景，我们用矩阵方式进行描述，如下：

Asset	Confidentiality	Intergrity	Availability	Damage Scenario
车灯请求的报文	--	√	√	数据丢失导致夜间汽车运行期间车灯突然关闭 数据丢失不能切换远近光灯

步骤2：有了上述矩阵支撑，此时我们就要评估上述场景造成的破坏等级，

数据丢失导致夜间汽车运行期间车灯突然关闭，功能安全这肯定是最严重等级的，给个S

数据丢失不能切换远近光灯，相对温和，功能安全可以给个Moderate

那我们用SFOP矩阵分析，可以得出如下结果：

破坏场景	Safety	Financial	Operational	Privacy
场景1	Servere	Negligible	Servere	Negligible
场景2	Moderate	Negligible	Moderate	Negligible

步骤3：接下来继续分析数据丢失的原因，从Security角度来看，那就是对请求的报文进行的完整性、可用性的破坏，因此我们可以考虑如下两个方面威胁场景：

攻击者攻击CAN控制器的buffer(发送高优先级报文)，导致数据溢出，此为可用性攻击

攻击者篡改、劫持对应车灯请求的报文，导致数据丢失，此为可用和完整性攻击

上述威胁场景的攻击路径有哪些呢？很明显，我们这时候就要从整个系统框架以及预定义的运行环境来分析。攻击路径举例如下：

黑客通过蜂窝数据、蓝牙等方式攻入导航系统，控制导航借用网关的路径向车灯执行机构发送车灯请求，从而在行车过程中关闭车灯

那么针对该攻击路径，我们要分成几段来分析该攻击方式的难易程度，首先是入侵导航系统，这个在2015年已经被证明是可行的；其次是借用网关路径，这个就是一个bypass，应该不难绕过；最后就是篡改原始车灯开关请求，直接覆盖即可。这只是一个很简单的分析方式，有实力的OEM就可以按照这个假设去做渗透或者红蓝对抗。步骤4：有了攻击路径、攻击实现难易分析、资产定义、破坏场景等作为基础，我们最终就可以为这个威胁场景进行风险等级定义，在标准中使用0-5来表示风险值，例如针对上述场景1，攻击方式简单、影响分级很高，那么该威胁场景的风险等级就非常高了，给个5吧。步骤5,：最后我们来看下如何有效预防该威胁场景的发生，针对场景1，我们可以从源头就进行处理，然后针对每个攻击阶段做有效防御，示例如下：



那么具体到实际部署，CP AUTOSAR中的SecOC可以有效保证完整性和可用性，使用IdsM可以做流量监控等。

05.小结

上文，我结合ISO\SAE 21434提供的车灯系统的TARA分析示例，简化并提出自己的理解；实际上上面的每一个步骤都需要大量的实战经验，这需要传统汽车人在日常工作中不仅要从功能安全视角来审视系统架构，还需要从信息安全视角验证系统架构。
随着国家关于汽车整车信息安全、OTA等强标的推出，传统汽车人不得不接触这些新鲜事物，在时代的洪流里，大家唯有破浪前行，始终保持热爱！