万字长文解读汽车信息安全框架

汽车安全探讨中，传统意义上的被动安全是大家最具共识性的，也是消费者最易理解的，但被动安全已经足够得成熟和足够得不必争论。

所以，老百姓不太理解，但理论体系和实践经验更为充实的功能安全实际上成了当下事实上的核心安全主题（注意是当下）。

我们不妨先从功能安全讲起，来引出信息安全的内涵。

这里有3点要注意。

(1) 安全即风险够低

第一，这世上没有绝对的安全。所谓安全与否，是指风险高低，只要风险够低就是安全，如图1所示。

进一步问，高与低的界线在哪里呢？在“老百姓”心里。不过，对“老百姓”更精准的表达应该是State of the Art，即当前技术水平。

也就是说，功能安全的目标是将风险降低到大众可接受的水平。这有很大的伦理意味，这也是目前自动驾驶要考虑的课题。

图1 风险与安全的含义

(2) 本质安全

第二，虽然这世上没有绝对安全，但有本质安全，本质安全是消除内在的风险。举个例子。

小的时候，离家不远的地方有一条铁轨，横穿过离家的小路，这不仅仅让行人车辆经常与火车擦肩而过，也是我们小孩子压硬币和铁钉的乐园，自是十分危险。

后来不知是谁在铁轨之间加装了方便快速通过的木板，并且增加了简易栏杆，火车快到时，还有红色警示灯......

不过，还是不够，直到有一次，还是出了一次惨烈的事故。再后来，铁轨下深挖了一个小的隧道，路口附近的铁轨也都被围栏围了起来，尽管下雨总是聚水，但再没听说过什么事故......

这个小事例说了两个安全，铁轨下挖隧道就属于从根本上规避风险的本质安全，而加装木板、栏杆及警示灯等安全机制属于无法实现本质安全后的功能安全的范畴，如图2所示。

图2 本质安全与功能安全

(3) 以人为本

第三，功能安全以人为本，关注的是人身安全的伤害，包括驾驶员、乘客、行人及其他车辆内的人员，并不关注财产的安全。

2.3 功能安全解决什么问题

功能安全虽然带有功能二字，但不能解决功能不足、性能不好的问题（属于SOTIF），也就是不改变系统的标称特性，而是正向指导我们如何通过降低系统失效风险达到安全目标，并最终来减少对人的伤害。

比如，电子手刹，功能安全是要实现“避免非预期刹车失灵”的安全目标，关注的是整个电子手刹回路某一环节发生失效时的诊断、监控及处理行为，不是增加卡钳设计夹紧力改变功能与性能。

再进一步看，功能安全要处理的失效来源于哪里呢？两方面。

• 第一，人总是有局限的，所以人在产品及项目开发过程中，会为软件或硬件带来“系统性失效”，比如，标定时设置错了参数值或方向，理论上，这些失效是有确定根因的，只能通过过程执行或设计变更来消除。

2.4 功能安全如何处理这些失效

失效很重要，但不是最重要的。我们要关注失效给人身安全带来的风险。风险也很重要，但依然不是最重要的，因为没有100%的零风险与安全。所以我们要识别出不可接受的风险，然后通过一些安全机制（过程与技术）将其降低到可接受的程度。不那么精准的说法就是足够的“功能安全”。

这里其实引出了功能安全方法论的核心目的是，通过增加安全机制将不可接受的风险降低到可接受的程度。

本节通过对比功能安全来看信息安全的特点。

3.1 从“伤人”到“伤心”

功能安全的指向很明确，就是关注对人的伤害，且限于肉体的伤害，姑且称之为“伤人”，为什么说信息安全是“伤心”呢？这不得不引出第一节也提到的信息安全的一个核心概念——资产，“资产”的破坏将导致“伤心”。

(1) 资产

在中文的语境里，提到资产，很容易想到钱，钱和资产有部分关系，但不能用钱来直接代替，这里的资产的概念更加宽泛。

接下来，我们从更学术的角度看，先串一下21434中资产及附属概念的含义。

• 资产：有价值或对价值有贡献的对象（有形的或无形的），它具有一个或多个值得保护的属性（即信息安全属性），其违背可能导致一个或多个不良后果（即损害场景）。

(2) 信息安全的目的

对应地，我们来寻找信息安全要解决的问题，汽车E/E系统或组件（即item）拥有一些对人有价值的资产，这资产里的一些属性被损害后，会对人造成一些不良后果。

信息安全要做的就是，通过保护资产的属性尽可能不被破坏，来让这不良后果的风险达到可以接受的程度，让相关人不要太“伤心”（伤人也属于一种伤心，即信息安全也会关注对人的伤害），如图3所示。

图3 汽车信息安全的基本目的

3.2 从“HARA”到“TARA”

再回顾下功能安全的开发逻辑，大体是从危害事件来识别risk大小，并定义ASIL及对应的安全目标，从而获得功能安全的大目标和总标准，随后通过拆解而进入V模型的常规开发中。对于功能安全而言，HARA是核心的增量方法。

现在来看信息安全，大家大的指引方向都是，让对人不好的东西的发生被控制在较低的水平。于是，信息安全引出了一个核心方法论——TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）。

看到这个词，大家首先会注意到其中威胁，延伸一点，威胁其实是来源于威胁场景这个概念，它可以类似对应于功能安全中的危害，即潜在的危险（在26262中也明确指出，可以从功能安全角度将信息安全威胁作为危害进行分析，以支持危害分析和风险评估以及安全目标的完整性）。而前述的损害场景相当于功能安全中的伤害，即由潜在的危险转化而成的实际发生的后果。后面的风险评估又和HARA在字面上完全一致（具体方法会有些不同）。

这样一对比，TARA和HARA有着高度紧密的映射关系，基本的方法论逻辑是一致的。类似于HARA，TARA也是信息安全的主要增量内容，我们也可以TARA来牵引出信息安全开发的脉络。

写到这里，大约是对汽车信息安全是什么有了一个模糊的轮廓，但很多细节还未展开，比如，威胁的源头是什么，资产主要包括什么，属性里的机密性、完整性及可用性怎么理解，怎么保护，不良后果的影响有哪些，形成的概率高低，相应的风险等级如何评定，TARA如何将这些东西串联起来......关于这些问题将在下面回答。

TARA主要分为7个部分，逐个来展开。但要注意一点，在21434中，整体并不具有明确的线性化次序，包含TARA中7个部分在内的各个部分都会有一定的独立性，输入输出相互交织。

4.1 资产识别

资产的识别有一定的事后性与动态性，也就是说资产不会全部清清楚楚摆在一个列表里（一般会有一部分参考，但不是唯一来源），需要分析、确认、更新。

其他渠道有哪些呢？一般，可以在相关项定义中识别、从威胁场景中获取，以及通过不良后果的影响评级来判断。

当然，这种泛泛之谈会让人不明就里，我们通过一个实例来理解下这个逻辑。

先回顾下有关资产的定义，资产是有价值或对价值有贡献的对象（有形的或无形的），它具有一个或多个值得保护的属性，其违背可能导致一个或多个不良后果。

(1) 潜在资产识别

于是，第一步，在相关项定义中识别研究对象时，我们可以先粗略划定一个有价值对象的范围。比如，分析到软件中的刹车CAN报文，它的被篡改可能会造成功能的缺失，显然面向价值，这就可以被划归为潜在的资产范围。

(2) 威胁与损害场景识别

再进一步，还提到了资产的3个属性——机密性、完整性与可用性，对应于刹车CAN报文的篡改，它可划归为完整性的违背，它会首先形成一个威胁场景。

那么，这个威胁场景会带来什么呢？或许会造成刹车失灵，乃至车毁人亡，这种后果就是所谓的损害场景。

(3) 影响评级

可是这损害场景的影响真的如此严重吗？我们需要再进行影响评级，如果评下来发现，确实挺严重，那这时就可以将这条“刹车CAN报文”作为资产了，或者说有必要开展进一步信息安全活动的资产。

所以说，资产的识别对应着一个认识的过程。为了更具象地理解什么是资产，举一些典型的例子，如表1所示。

表1 信息安全资产示例

看得出来，这些资产和钱有关系，但不那么紧密。

最后，总结一下，在该环节需要输出的内容包含：资产、资产的信息安全属性及违反相关属性导致的“损害场景”。

4.2 威胁场景识别

威胁场景是损害场景的潜在来源，其识别是对技术根因的向上溯源。

通常，需要体现出什么信息安全属性被违背及违背的原因是什么，比如，对EPS转向助力CAN报文进行欺骗篡改会导致CAN报文的完整性被违背，从而导致转向助力功能的异常。

• safety（人身安全）
• financial（财产）
• operational（车辆操作）
• privacy（个人隐私）

当然，也可以有其他合理的分类方式，但需要在开发供应链中达成共识。

从级别的角度看，每个类别可以从以下4个等级展开：

• severe（严重的）
• major（重大的）
• moderate（中等的）
• negligible（可忽略的）

其中，safety的部分在功能安全中有较为全面的、详细的论述，完全可以参考，必要时，也可以结合暴露度与可控度来综合定义，相对而言，safety的评价会更充分。对于其余类别，基于经验的、基于团队评价的模式居多。

4.4 攻击路径分析

走到这里，我们还没有谈到另一个重要的因素，究竟是谁造成了这种后果？信息安全本质是人与人的攻防较量，我们需要知道攻击者是如何执行攻击的，是如何造成威胁场景的，而这攻击者的一系列有预谋的蓄意行为就是攻击路径的概念。比如，对于第2部分威胁场景识别处的示例，黑客通过网关转发反向助力信号就是一条攻击路径。

形式上，攻击路径的分析可以按照“自上而下”和“自下而上”的方式展开。

• 自上而下是从威胁场景始，考虑其可能实现的不同方式，进而推断攻击路径。
• 自下而上的方法是，从已识别的漏洞来构建攻击路径。

• 所需攻击时间。一个专家从漏洞识别到开发应用的持续时间。
• 所需专业知识。普通小白和攻击各个步骤都需要专业人士的难度显然不同。
• 需要对产品或部件的了解程度。有些攻击可能只有内鬼才能做到。
• 机会窗口。可攻击的时间段，比如，漏洞公开到修复这段时间或者蓝牙连接过程的时间段）。
• 所需设备。发现漏洞和执行攻击是否需要专业的工具。

在确定好各个参数的取值并相加后，再根据预先定义的取值范围进行等级评定。

(2) 基于CVSS的方法

21434中选择了CVSS评估框架中的可利用度指标来评价可行性等级，而可利用度指标是将以下4个参数的取值代入特定公式中进行计算得到的。

• 攻击向量。在攻击可行性评级随物理或逻辑的攻击距离增加而增加的前提下评价，比如，从JATG口、U盘、蓝牙到移动网络的攻击可行性依次升高。
• 攻击复杂度。攻击者成功利用漏洞前所需要的条件多寡难易。
• 权限要求。攻击者在利用漏洞时需要的权限级别和授权次数等。
• 用户交互。攻击者与受攻击者越需要交互攻击可行性越低，比如，需要诱导用户点击车机链接提示。

(3) 基于攻击向量的方法

仅利用攻击向量评价也是一种简单粗暴的方法，这种方式常用于项目早期或其他还没有充足信息的阶段的粗略估计。

基于风险值高低，需要确认下一步的应对策略，一般分以下4种：

由于后两种并没有针对风险本身做什么处理，整个供应链的风险并未得到处理，所以需要特定的声明或监管。

在这里，我们会发现一个情况，就是风险值实际上是随着应对举措的执行而变化的。

那么，我们用什么目标线来确定该做什么和做到什么程度，类似于功能安全中的ASIL和预期功能安全中的两层接受准则。信息安全中增加了一个逻辑类似ASIL的概念——CAL（Cybersecurity Assurance Level，信息安全保证等级），它会作为一个固定的指标来牵引要做的信息安全活动及严格程度。

• 业务适用性原则：产品的信息安全设计应结合业务或功能环境的实际需求，同时考虑对业务或功能的正常使用的影响。

• 软件无后门原则：软件系统不应留有后门。

• 功能最小化原则：越复杂的系统有越多的潜在攻击面，无用的软件组件、协议端口和ECU硬件调试接口应禁用或移除；器件的管脚信息不宜暴露。

• 最小化授权原则：产品的访问和信息处理活动应只授予最小的必要权限。

• 权限分离原则：重要保护对象的信息处理活动应具备两个或两个以上的权限，且各权限应相互分离和单独授予。

• 默认设置原则：产品应完成默认的信息安全设置，该设置对用户的信息安全设置诉求应做到最小化和最简单化，即尽可能默认设置下就是安全的。

• 失效安全原则：即便系统崩溃，信息安全机制仍然有效。

• 不信任原则：第三方软硬件及数据须先完成合法性检验，再进行使用。