登录 | 注册 退出 投稿

基于模型的汽车网络安全风险分析建模

专栏作者 2023-05-22

内容提要:本文重点介绍如何用基于模型的方法为风险评估阶段提供有效和高效的支持。并提出了丰富的目标导向的元模型,以捕捉汽车资产和系统属性,估计破坏场景的影响,识别威胁并评估其可行性。该方法作为概念验证来实现,通过元模型适配一个通用的协同工程平台,并在车灯控制子系统上进行了展示。


摘要

随着汽车日益智能化和联网化,它们也变得更容易受到网络安全威胁。在涉及多个层次和复杂的安全关键系统的大型行业中,提供强大的保护和对此类威胁的响应具有挑战性,需要开发新的ISO 21434标准,与专注于安全的ISO 26262标准一起,为安全-防护协同工程提供坚实的基础。本文重点介绍如何用基于模型的方法为风险评估阶段提供有效和高效的支持。并提出了丰富的目标导向的元模型,以捕捉汽车资产和系统属性,估计破坏场景的影响,识别威胁并评估其可行性。该方法作为概念验证来实现,通过元模型适配一个通用的协同工程平台,并在车灯控制子系统上进行了展示。

1.引言

汽车已成为完全互联的载体,并需要进行通信以支持广泛的场景,从信息和娱乐到新的操控汽车的方式,例如驾驶辅助、互联车队和自动驾驶模式。这种快节奏的功能演变显著增加了连接车辆的攻击面。

不幸的是,保护汽车资产的网络安全方法没有以相同的速度提高,并且有一段时间仅依赖于J3061最佳实践,没有提供有关如何继续操作的指导。为了填补这一空白,ISO和SAE共同努力制定了ISO/SAE 21434标准,通过可执行步骤、符合性要求的清单、管理流程和全球规范提供更多指导,从而取代了J3061。

ISO 21434标准通过覆盖网络安全方面来补充ISO 26262,而ISO 26262则涉及功能安全方面。安全和防护领域的差异在于考虑到的影响不同:安全风险与人或环境的后果相关,而网络安全风险则主要涉及金融、运营和隐私影响。然而,两者共享一种共同的文化。从风险管理的角度来看,通过威胁分析和风险评估(TARA)来分析网络安全风险,而通过危害分析和风险评估(HARA)来执行功能安全性分析。几十年来,安全一直是汽车开发文化的一部分,这为构建更广泛的安全-防护协同工程方法开辟了道路。鉴于这种演变,预计汽车供应商将被要求证明符合ISO 21434,这也可能带来竞争优势。

采用基于模型的工程是一个现实的方法,因为汽车开发过程中的大多数步骤已经基于模型。例如,SysML和UML被广泛用作体系结构过程的一部分或用于基于模型的软件开发,并集成在汽车工具链中。支持基于模型的风险评估非常有益,以支持资产、漏洞、威胁和对策的系统化识别。

我们的文章采用了这种基于模型的方法进行风险评估。为了考虑安全和防护维度,我们依靠面向目标的需求工程(GORE)框架来结构化系统属性和相关风险。这种方法支持以下方面:

•关键资产、安全和资产及相关风险的识别。

•共同采用的方法,将TARA与HARA集成,实现协同工程实践。

•支持分析、转换和文档生成功能的基于模型的工具链。

•在灯光控制的汽车子系统上进行实例验证。

本文的结构如下。第2节介绍了ISO 26262和ISO 21434标准的更多背景信息。第3节介绍了我们基于资产、目标和危害/威胁建模的方法,并介绍了我们的案例研究。第4节介绍了我们在工具支持的应用程序上执行的HARA,用于处理汽车场景。最后,第5节得出了一些结论,并确定了进一步的工作。

2.汽车标准背景

本节简要介绍了ISO 26262标准和ISO/SAE 21434标准的内容。

2.1汽车安全ISO 26262标准

ISO 26262“道路车辆-功能安全”是量产汽车中电气和/或电子系统功能安全的国际标准。它是一个以ISO 31000为基准的风险导向标准。是IEC 61508的专门化应用,IEC 61508是适用于所有行业的基本功能安全标准。该标准使用定性HARA方法处理危害运行情况的风险,并定义避免或减轻系统性或随机性失效影响的安全措施。

从过程角度来看,它遵循汽车W形生命周期,分别结合硬件和软件设计的两个V形周期。HARA在概念阶段执行,完成潜在危害的识别。相应的风险是使用驾驶情况的评级功能,控制其能力和所造成的伤害严重程度来调查的。它使用分配给每个安全目标的汽车安全完整性等级(ASIL)进行评估,ASIL从A到D分配关键系统的级别。对于风险较低的系统,质量管理活动被认为是足够的。

关于网络安全,该标准为开发阶段定义了基线网络安全指南。对后期制造、退役阶段、汽车网络安全或处理特定网络安全事件没有具体要求。

2.2 汽车网络安全ISO 21434

这个标准旨在推动汽车领域关键网络安全问题的行业共识。它将替代J3061的良好实践,提供更有结构的建议,表明行业正在全面拥抱确保汽车网络安全的挑战。其范围包括道路车辆(例如汽车、卡车、公共汽车)及其子系统、部件、连接和软件。其目的是确保制造商和供应链中的所有参与者都有结构化的流程,支持“安全设计”过程。

从流程角度来看,与ISO 26262类似,它关注整个车辆的开发过程和生命周期。它遵循V型模型,考虑了广泛的活动,例如设计分支中的TARA,测试分支中的验证和确认,以及运行阶段中的安全监控、事件和响应管理。

该标准分为10个章节和15个条款。它首先定义了(1)范围,(2)规范参考,(3)术语表,(4)一般考虑因素和(5/第5-6-7条款)管理方法。然后(6/第8条款)着重于风险评估。接下来是三个分别涵盖(7/第9条款)概念阶段、(8/第10-11条款)产品开发和(9/第12-13-14条款)产品、运行和维护的章节。最后一节(10/第15条款)涉及支持流程。

关于风险评估,标准不强制执行任何TARA方法,但它的第8条款提醒了应涵盖的强制步骤,与ISO 27005的精神相同。如图1所示。

1.png

图1:ISO 21434 TARA过程

3.面向目标的共同工程模型

本节介绍基于GORE的方法论框架。需求工程领域中已经制定了不同的目标建模变体,如i*,KAOS,GSN。本文依赖KAOS。所需建模符号在本节中进行描述,并在图2的图例中绘制。为了说明该方法,我们使用一个车灯的控制子系统。实际上,这是标准本身中使用的案例。尽管规模有限,但它包含有趣的问题,可以凸显我们方法的优点。我们的建模将分为三个观点:捕获范围的对象模型、属性的目标模型和风险的障碍模型。

2.png

图2:照明子系统的对象模型(带符号图例)

3.1 对象/资产模型

对象(或资产)模型定义,并关联系统中涉及的所有概念。它必须能够捕捉表达属性(特别是安全和防护)所需的所有词汇,并在目标模型中进行结构化。它还必须识别所有可能受到网络安全威胁的有价值资产。

该模型使用实体、关系、事件或代理人/攻击者来捕捉领域概念。所使用的建模符号接近于UML类图。

图2表示了我们案例研究的资产模型。该系统使用不同的抽象进行建模,可以在许多子系统中重复使用:电子控制单元(ECU)、传感器(在我们的例子中是灯开关)、执行器(灯控制器)以及各种控制设备(车头灯以及一些通信设备)。通信通过内部CAN总线进行管理,在其中交换消息。网关还可以确保跨子系统的桥梁,例如将通信设备连接到CAN总线。对象可以具有反映重要状态信息的特定属性,例如开关和灯状态。

3.2 目标模型

目标在不同的抽象层次上捕获所考虑的系统应该实现的关键属性。目标模型将目标结构化为AND-OR树,这些树表达了目标之间的细化关系。通过将父目标与多个子目标链接,使用不同的满足条件,如“AND-refinement”(需要满足所有子目标)或“OR-refinement”(一个子目标就足够,即可能的备选方案),可以将高级目标逐步细化为更具体和操作性的目标。细化可以通过一些策略来表征,这些策略可以帮助检查它们的完整性和一致性,例如基于案例的策略(进行设计区分)或基于里程碑的策略(即时间步骤)。目标还可以具有表征特定性质的特定属性,例如可以通过特定装饰器(SAFE/SEC)以图形方式显示的安全性。

图3显示了一个安全属性的建模:灯应该在晚上亮起(由蓝色平行四边形表示)。在我们的手动设计中,这依赖于一个事实:只有当开关被激活并且司机会在晚上将开关打开时,灯才会亮起(由黄色平行四边形表示)。考虑到属性(由小房子表示)开关只能开或关(不考虑自动照明),基于案例的细化用于区分通过打开或关闭开关导致的两种可能的状态变化。AND-refinement由一个黄色圆圈表示,该圆圈连接细化的目标和实现更高级别目标的有用属性。“TurnOn WHEN SwitchON”目标通过遍及整个通信链的里程碑分解进一步细化:ECU检测开关变化,然后在CAN总线上发送消息,灯控制器处理它最终打开灯。该过程涉及不同的监控和控制代理,并由黄色六边形表示。代理直接控制下的目标称为需求,并且具有较粗的边框。

3.png

图3:车灯子系统的目标模型

3.3 障碍模型

障碍表示不良属性。它是目标的对立概念,可用于表示安全隐患或安全威胁。它用红色平行四边形表示,方向与目标相反。障碍可能来自环境(例如安全隐患),也可能是攻击者有意造成的(例如安全威胁),如攻击者试图控制灯光系统。攻击者用红色代理表示。与目标一样,障碍可以使用AND/OR树进行细化,导致分解结构与安全的FTA或安全性的AT非常相似。细化链接还可以通过更具体的安全/安全门(本文未说明)通过具体策略进一步表征。叶子障碍通常是根本原因(在安全性方面)或漏洞(在安全性方面)。障碍通常通过阻碍关系与它所影响的目标相连接。对称地,障碍可以通过额外的要求得到缓解。攻击者特定的关系也明确攻击目标或利用的漏洞。

图4展示了部分攻击分解中障碍的示例,导致灯光突然开启。攻击者可以通过访问总线并欺骗CAN消息来实现。可能的缓解措施是实施消息完整性检查。请注意,顶层安全目标未被破坏,但类似的攻击可以在夜间关闭灯光。

4.png

图4:车灯子系统上的障碍(部分攻击)模型

4.基于模型的风险分析

为了符合ISO 21434 TARA流程,我们将使用支持安全和防护协同工程的目标建模框架,在第3节中描述的条款8.3到8.5,如图1所示。Objectiver平台被用作工具来构建模型和执行风险评估,也作为原型平台,得益于其插件机制。

4.1 资产识别(8.3)

当介绍对象/资产模型时,已经涵盖了资产识别步骤。通过分析系统目标来识别资产。例如,目标“Lamp is On IFF Switch is On”可以识别灯和开关。目标细化过程将导致整个命令传输链的识别。可以使用更通用的概念来结构化资产,这些概念构成汽车的构建块(例如传感器、ECU、执行器),如图2所示。然后可以在各个子系统中实例化这些概念。

请注意,资产模型可以进一步丰富体系结构信息,这些信息对攻击路径分析有用,并且稍后还可以添加处理对策的组件(本文未详细介绍)。

4.2 破坏情景

通过引入障碍,可以试图系统地破坏目标来提取破坏情景。可以在以下安全维度上进行操作:

•保密性。在这种情况下,这并不重要,因为每个人都可以看到灯何时打开。

•完整性会导致与意外地打开或关闭灯有关的障碍。

•可用性会导致与无法打开或关闭灯有关的障碍。

4.3 威胁情景识别(8.4)和攻击路径分析(8.6)

这一步通过攻击树来完成,可以采用自上而下的损害情景细化方法,或基于已知漏洞的自下而上方法。后者需要更丰富的架构模型,促使对象模型进行详细描述,如图2所示。对威胁的完整细化自然会探索和发现不同的攻击路径。在我们的情况下,资产模型分析揭示了一个可能通过媒体通信进行的攻击路径,可以通过蓝牙或蜂窝接口实现。从那里,可以发起特定的攻击行动,影响完整性或可用性。可以单独对这些安全维度进行分析,以实现更模块化。图5显示了我们对完整性攻击路径的分析,两个通道都可以用来控制网关,然后可以通过总线发送一些伪造的消息,使灯泡执行器认为开关状态已经改变。这通过OR-refinement表示为破坏导航系统,尽管每个路径的风险可能不同。

5.png

图5:完整性攻击路径的分析

4.4 影响评估(8.5)

必须对四个维度进行评估:安全、财产、运行和隐私(SFOP)。在我们的情况下,由于灯具是公开可见的,因此没有隐私影响。运行影响很大,因为它改变了汽车的预期行为。虽然没有直接的财务影响,但图像损坏可能会对此产生重要的间接影响。关于安全影响,可以通过对每个威胁的安全影响,与建模的安全目标进行推理来进行更详细的评估,指出在夜间应该开启灯具:

•R1-意外打开灯具:对驾驶员没有影响,但可能会让其他驾驶员感到惊讶。

•R2-意外关闭灯具:如果发生在夜间,可能会产生重大影响。

•R3-无法关闭灯具:虽然会耗尽电池,但影响可忽略。

•R4-无法打开灯具:影响适中,因为它需要切换到降级模式,即在夜幕降临时停止行驶。

4.5 攻击可行性评级(8.6)

为评估攻击的可行性,首先要评估每条攻击路径。可以使用攻击因素来评估每条攻击路径相对于时间、专业知识、知识、机会和设备因素的优劣。为支持此功能,我们扩展了我们的工具,使其能够使用元模型扩展来捕获这些属性。不同的攻击路径可以通过查看攻击树中导致叶节点的不同路径来确定。这可以通过模型查询来实现,并在图6中显示的表格中显示。结果表格可以直接在我们的工具中进行编辑。

第二步是根据路径组合的方式结合因素:AND-refinement需要考虑最小可行性水平,而OR-refinement需要考虑最大水平。注意,可以考虑其他方法来处理更丰富的细化门集,但在此处未详细说明。

6.png

图6:攻击路径的可行性分析

基于这种分析,完整性欺骗攻击和可用性DOS攻击都可以评估为中等水平。

4.6 风险确定(8.9)

基于影响和可行性评级的组合,可以将可行性作为列和影响作为线来定位定性风险矩阵中的每个风险,如表1所示。这可以直接从模型中的信息由工具计算,然后导出到文本处理器表格或电子表格中。

表1.png

表1:车灯子系统的安全风险矩阵

4.7 风险处理决策

最后,必须采取行动将风险降至可接受水平。可以依靠接受、避免、缓解或转移等策略来实现。限于篇幅,本步骤不在此详细阐述。

5.结论与下一步

本文展示了如何在汽车领域符合新的ISO 21343标准进行网络安全风险分析。所提出的方法是基于模型的,也与符合ISO 26262标准的安全分析相结合,为安全和安保协同工程铺平了道路。它在一个通用的目标导向工具集上进行了演示,并在一个汽车子系统上进行了说明。虽然规模有限,但我们的案例研究可以展示该方法与威胁的引出、攻击路径的分析和风险评估相关的优点。它还具有良好的自动化、可扩展性和子系统间的重复使用可能性。

基于这个概念验证,我们的下一步是详细阐述风险处理阶段,并在正在进行的自动驾驶项目的背景下考虑更大的案例。我们还计划改进我们的工具支持,并转向领域特定的系统工程工具,更适合于在汽车工具链中进行集成和采用。

基于模型的网络安全分析工具REANA,试用联系牛小喀(微信:NewCarRen)




作者:牛喀网专栏作者
牛喀网文章,未经授权不得转载!


下一篇: 使用基于模型的方法来评估汽车嵌入式软件的安全性
上一篇: 当汽车功能安全遇上机器学习,ISO 26262 该如何改编?
相关文章
返回顶部小火箭