汽车网络信息安全分析方法论概述

lixinfu

目录

1.典型信息安全分析方法

1.1 HEAVENS威胁分析模型

1.2  OCTAVE威胁分析方法

1.3 Attack Trees分析方法

2. 功能安全与信息安全的关系讨论

     与Safety的典型分析方法一样，Security也有一些典型的信息安全威胁分析方法(TARA分析)，根据SAE J3061、ISO/SAE 21434和EVITA项目的推荐，整理如下。

01
信息安全分析方法概述1.1 HEAVENS威胁分析模型HEAVENS(HEAling Vulnerabilities to ENhance Software Security and Safety)，是一种比较完整的风险评估方法，针对汽车系统的E/E架构的威胁分析和风险评估提出了方法论、流程和工具的顶层概念。其工作流如下：

在威胁分析环节，该模型嵌套使用STRIDE危险分析模型。STRIDE模型由微软安全通信部门提出的系统威胁建模方法，从六类危险对应信息安全三要素三属性，如下所示：

威胁	安全属性	定义
假冒 （Spooling）	认证	冒充人或物
篡改 （Tampering）	完整性	修改数据或代码
否认 （Repudiation）	审计	不承认做过某行为
信息泄露 (InformationDisclosur)	机密性	信息被泄露或窃取
拒绝服务 (DenialOfServie)	可用性	消耗资源、服务可不用
特权提升 (Elevation of privilege)	授权	未经授权获取、提升权限

该模型可应用在系统级分析，确定系统级别的威胁场景，常用在汽车、轨道交通系统。风险评估环节采用威胁分级的形式，基本步骤如下：风险评估包括三个步骤:(a)确定威胁级别(TL):这对应于风险的“可能性”成分的估计;(b)确定影响级别(IL):这对应于风险的“影响”成分的估计;(c)确定安全级别(SL):这对应于最终的风险评级

定义威胁等级：对威胁出现的可能性进行预估(TL)

确定威胁影响等级：对威胁出现造成的影响进行评估(IL)

确定信息安全等级：根据最终风险的打分情况(SL)

        常见的评价模板如下：



这也是ISO/SAE 21434进行TARA分析采纳的方法，在形式模板上有些许差异。
1.2  OCTAVE威胁分析方法
OCTAVE(Operationally Critical Threat, Asset, and Vulnerability Evaluation) 该方法同样是基于流程驱动的威胁、风险评估的方法论。该方法由三个阶段组成如下图：


上述阶段共计8个流程，如下：

建立风险度量准则

建立资产定义概要机制

建立信息安全需求和目标

识别关键风险资产

识别威胁攻击场景

识别风险

分析风险

设计缓解方案

1.3 Attack Trees分析方法

该方法是EVITA项目用于脆弱性分析的主要手段。攻击树将攻击目标作为顶层节点，并开始评估各种达成攻击的各种手段（即子目标），以分层的方式从顶层节点开发树的枝叶直到确定最基本的攻击手段。子目标使用与或逻辑进行组合，在EVITA使用攻击树进行脆弱性分析时，将攻击树分成了如下结构：

AG：Attack goal（与故障树顶层事件类似），level 0；

AO：Attack objectives，level 1；

AM：Attack methods，Level 2；

GT：intermediate goals/methods，Level 3:(n-1)；

AA：Asset attacks，Level n.

在上述图片中，我们可以看到最基础的AA中AA3在AM1/2两个地方均出现了，意味着这个攻击手段很有针对性，需要重新研究；AA4表示当前未识别到攻击手段，需要进一步分析。02
—

功能安全与信息安全关系讨论功能安全风险分析是对系统的系统性失效和随机性失效进行风险评估，该过程称为之HARA（Hazard Analysis and Risk Assessment ），目的是识别可能导致 E/E 系统失效的潜伏顶层故障类型，结合行驶工况来评估相关的危害程度，我们把这个危害结果用来制定对应的安全目标（Safety Goal），确保汽车能够在发生目标故障后，能够在预期故障响应时间（FTTI）之内进入预期的安全状态。信息安全风险，主要是通过威胁分析方法来识别当前系统的威胁场景，用于形成有对应威胁的控制措施和有效的分层防御，从而保护车载设备的敏感信息安全。
     但是功能安全和信息安全又是相辅相成，对于一个系统来说是两种不同的设计方向，以设计某芯片的安全启动为例，在做TARA分析时，首先要定义的是风险资产及对应攻击方式，譬如固件的签名结果被篡改导致系统处于非安全状态；但在做HARA分析时，首先要定义的是失效模式，而这些失效根源有可能是随机硬件失效，也有可能是被篡改，这也会导致系统处于非安全状态。故同样的安全目标，对应的分析方式是不同的。

     再比如，OTA升级时Flash或者RAM某些位置出现了随机硬件失效，这属于safety范畴，结果当然是可能造成车机无法启动；但OTA升级如果升级包被篡改，这又属于security范畴，同样也可能造成车机崩溃，上述两个方向都可能对车、人造成损失。

     所以我们在兼顾Safery和Security的时候，通常是首先基于功能安全的危害分析，进一步开展针对信息安全的威胁分析，针对功能定义和应用场景来设计安全防护措施，例如OTA升级时首要保证功能安全，其次升级时对升级包进行加密签名等用于保证信息安全。