汽车软件安全建模新方法

安全抽象模型：汽车软件系统的安全抽象模型

马库斯·佐佩尔特(B)和拉明·塔瓦科利·科拉加里(B)
纽伦堡理工大学，德国纽伦堡{markus.zoppelt,ramin.tavakolikolagari}@th‐nuernberg.de

摘要

由于汽车领域中（半）自动驾驶车辆和联网技术的出现，开发安全可靠的车辆在保护道路使用者方面正发挥着越来越重要的作用。安全的道路运输是一项重要的社会与政治目标，欧盟委员会提出的“在道路交通中接近零死亡”这一具体目标（欧盟委员会白皮书 Roadmap to a Single European Transport Area—Towards a competitive and resource efficient transport system，2011年，第10页）充分证明了这一点，该目标计划在未来三十年内实现。在汽车系统开发中，这一目标有一个历史上常被忽视的方面，即安全，也就是免受恶意实施的威胁。在汽车软件行业中，基于模型的工程是当前的实践现状。目前，安全通常并未被集成到整个系统开发流程中，而往往是事后才被考虑。由于组件之间紧密的相互依赖性和集成性，严重的安全漏洞将带来严重的后果。本文的贡献在于提出一种安全建模方法，使汽车工程师能够在工业级基于模型的工程背景下，在早期阶段对软件系统进行分析。本文提出了作为相关行业标准EAST‐ADL建议附录的安全建模语言规范，从而为架构与安全方面提供了一种统一的建模方法。所有安全扩展均符合该标准及其与AUTOSAR共享的元层次。本文通过一个小型建模示例展示了该安全建模语言规范，并结合采用扎根理论方法对一组专家访谈进行的形式化评估，表明该规范具有全面性，并涵盖了非标准化的相关研究。

关键词 ：汽车安全 · Safety和安全 · 安全需求

1 引言

汽车系统电气化的日益复杂性迫使原始设备制造商（OEMs）在所有与软件相关的质量目标，特别是安全性、安全性和可靠性方面具备专业知识。此外，行业背景正在发生变化，控制权正逐渐脱离原始设备制造商（OEMs），即他们无法完全控制智能手机、平板电脑、信息娱乐系统等外部组件的售后市场。然而，他们仍需负责提供一个具有安全接口的通用平台，以连接必要的外部组件。汽车用户要求可靠性、隐私保护和安全性，同时希望拥有无钥匙进入和互联网连接等常见便利特性。在大多数情况下，这些便利特性与基本的安全原则相冲突，最终导致产品安全性降低。缺乏安全性可能导致安全风险，并危及驾驶员、同车乘客和其他道路使用者。汽车黑客攻击、路线赞助甚至致命事故可能成为迫在眉睫的后果。制造商声誉也面临威胁。因此，有必要为汽车系统的安全软件建模提供一个平台无关基础。本文所解决的问题是在与汽车系统相关的系统工程过程中缺乏在开发中主动应用的构造性安全措施。目前安全往往被视为事后补充，而非集成到整个系统开发过程中。忽视安全性总是致命的，尤其是在现代汽车系统中各组件之间存在紧密相互依赖和高度集成的情况下。系统架构师和软件工程师需要在系统开发的早期阶段拥有一个共同的基础，以促进协作并共享概念。第3.1节描述了汽车核心开发流程的概述。

在本论文中，我们展示了：
– 结合安全原则与体系结构系统模型，将已确立的安全属性形式化并迁移至汽车软件工程领域。
– 以传统安全建模方法的用户故事为基础，提取汽车安全建模的相关需求。
– 扩展面向汽车领域的架构描述语言EAST‐ADL，以弥补汽车领域在安全建模方法与工具方面的不足。
– 基于该用户故事的实际示例，应用所提出的扩展，用以说明当前的解决方案。
– 通过与行业专家进行基于扎根理论的访谈，对本综合方法的实际相关性进行简要分析。

然而，本文并未提供实证可行性研究，因为所使用的技术本身是可行的。我们仅提出一种结合性方法，以语言规范的形式，在架构模型中对安全与安全之间的相互作用进行建模。

2 面向“驾驶计算机”

开发安全的汽车系统是一个重大挑战，特别是对于智能汽车而言，它们的功能更像一台计算机，而非传统车辆。现代汽车是相互连接的网络，在豪华车型中可能包含超过150个电子控制单元（ECUs），[18]这些单元彼此之间以及与环境（车对外通信）进行通信。攻击者对汽车的攻击方式不同于他们对标准计算机系统的攻击；汽车使用不同的网络、协议和架构[30,33]。目前汽车尚无防火墙等缓解措施。即使是简单的拒绝服务（DoS）攻击也容易实施。[23]此外，汽车在系统设计中沿用了带有不安全且未加密协议（例如CAN，控制器局域网）的遗留机制，最初并未按照现代安全原则设计。[8,13]由于过去三十年普遍认为汽车因其技术复杂性而具备安全性（隐蔽式安全），因此安全的汽车网络架构在过去并未被优先考虑。然而，针对汽车及其ECU、执行器和传感器网络的攻击向量大量存在。[20,31]与台式计算机不同，当这些“驾驶计算机”成为攻击目标时，人类生命将面临威胁。当乘客的生命处于危险之中时，网络攻击应始终被视为高度严重的问题。如今，所有人都充分意识到提高汽车安全标准的必要性，并且频繁发布的关于汽车攻击的新闻稿不断提醒着我们这一事实。[20]本文通过在汽车系统开发过程初期引入安全措施来解决汽车安全问题，使汽车工程师能够记录、分析和控制安全设计，这是在汽车系统中实现安全的至关重要的前提条件。

3 汽车软件系统工程

本节概述了汽车软件系统工程，特别关注根据EAST‐ADL和AUTOSAR这两个主要的国际汽车标准对汽车系统进行建模。为了理解本文其余部分，特别是第5节所描述的创新性贡献，有必要了解汽车软件开发流程的一般特点以及EAST‐ADL和AUTOSAR所采用的（元）建模方法。熟悉汽车软件开发流程的读者可以跳过本节。

3.1 汽车核心开发流程

汽车核心开发流程基本上是根据传统的软件工程V模型进行组织的[14]。核心开发过程通过并行展示硬件和软件层面的产品开发，反映了汽车系统通常是嵌入式的这一事实——对硬件和软件有特定要求——其结构遵循ISO26262标准[12]，该标准是汽车系统功能安全的国际标准，参见第5.2节。V模型的每个阶段代表一组连贯的过程步骤，在这些步骤中将产生一组工件。该阶段在逻辑上进行组织，而非时间上的划分。在系统分析阶段，需求被提取并记录；在系统设计阶段，开发出一种基于逻辑的、面向功能的体系结构，该结构作为硬件和软件开发阶段的基础，最终实现汽车系统的构建。“V模型”的下行分支涵盖了系统开发过程中的构造阶段：较低阶段产生的工件（具体工件）必须符合其直接上层阶段所产生的所有工件（抽象工件），即通过抽象工件对具体工件进行验证。“V模型”的上行分支则涵盖验证与集成阶段。核心开发过程由一系列支持过程所伴随，如功能安全、配置、变更、需求管理等，但这些过程不在本论文的范围之内。

3.2 使用EAST‐ADL和AUTOSAR对汽车系统进行建模

EAST‐ADL[4]是一种通过信息模型以标准化方式表示技术信息来描述汽车软件密集型系统架构的语言。其涵盖的方面包括车辆功能、特性以及功能和硬件架构。EAST‐ADL模型按抽象层次进行组织，每个子模型在相应抽象层次上以相关细节表示完整的嵌入式系统。

架构模型可以转换为多种软件架构，包括AUTOSAR[1], JasPar[26]以及内部框架，参见图1。特性模型在最高抽象层次上描述系统，并不构成架构。它在分析阶段（系统分析、硬件分析、软件分析）与相应的需求一起开发。功能分析架构在系统设计阶段开发。硬件设计架构在硬件设计阶段开发，而功能设计架构在软件设计阶段开发。汽车系统的AUTOSAR规范（见第3.3节）在软件实现阶段生成。半形式化建模语言EAST‐ADL通过语言规范进行描述和解释。该规范介绍了语言的所有特性，即所有概念、其基本含义、相互关系、适用用途和约束。

本质上，该规范可以用自然语言描述（只有完全形式化的语言才需要逻辑/数学规范），但通常也采用基于模型的方式描述语言规范。用于定义语言的模型位于所谓的元层次（简称M2）；因此，具体的语言规范模型称为元模型。该元模型包含了前述对语言的精确定义。利用元模型中规定的实体所构建的系统具体模型位于类型层（简称M1，有时也称为用户模型）。根据需要，可对选定的元模型实体进行实例化并填充具体值。

3.3 自适应AUTOSAR

AUTOSAR[1]是由所有主要原始设备制造商、供应商和工具供应商组成的国际联盟，旨在开发汽车软件架构的标准，即实现模块的语言规范（M2）。这些实现模块被称为软件组件，用于封装可运行体，而可运行体是基本的C函数。

AUTOSAR的方法是抽象掉所有（无关的）细节，并将其隐藏在运行时环境中；通过这种方式，系统工程师能够在系统级别上开发应用，整个汽车（及其复杂的底层硬件拓扑）看似如同一台单一计算机。AUTOSAR自适应平台[2]比传统方法（AUTOSAR经典平台）更进一步，为自适应应用实现了运行时环境（RTE），这在不久的将来针对（完全）自动驾驶汽车系统的背景下将变得日益重要。该平台使用虚拟机而非嵌入式系统，并在其运行时动态链接服务与客户端。自适应平台还包含一个专用组件“安全管理”，负责加密栈、身份和访问管理、安全通信以及受保护的运行时环境[2, p. 7]。此外，它还提供针对内存损坏攻击的防护，通过虚拟内存和操作系统级虚拟化实现横向隔离，以及纵向隔离（即“沙箱机制”）。

4 用户故事

为了说明对专用安全建模支持的需求，本节简要概述了汽车软件系统开发团队在识别安全威胁时的当前实践现状。我们的主要贡献将在第5节中描述。

4.1 汽车安全管理——实践现状

我们的假设：一家汽车公司组建了一个专项小组，以提高其发动机ECU的安全性。该专项小组由系统架构师、安全专家和软件工程师组成。安全专家负责识别系统的威胁和漏洞，而软件工程师则致力于修复缺陷并实现安全功能，例如加密功能。系统架构师负责定义系统架构（即软硬件拓扑），并在其中考虑安全需求等因素。该团队的任务是识别当前开发中的威胁、攻击和漏洞，并加以应对。他们首先针对其主要产品线创建不同攻击的威胁风险分析。该公司使用EAST‐ADL来设计功能架构。团队中的安全专家需要向团队报告现实场景中的威胁及相关情况。安全专家已经构建了攻击树[27]，并估算了可能攻击的攻击潜力[10]。团队的发现被记录在一份文本形式的需求规范中。安全专家在已建模的设计功能（DesignFunction）上附加了一条文本注释，解释所识别的威胁及可能的缓解措施。现在，软件工程师需要手动检查这些文本注释并予以实施。然而，系统架构师通常并不负责检查这些注释或验证其内容。在后续的系统测试过程中，安全专家疑惑为何该设计功能未实施任何缓解措施。他们发现，软件工程师最初并未考虑该注释，原因是工程师未能正确理解该威胁的相关性，或无法判断该注释所针对的目的或安全目标。

团队的工作将被迫中断，因为他们需要再次讨论该用例，以确定最初设定的安全目标究竟是什么。由于对攻击及攻击者动机的唯一记录仅以一条文本注释的形式存在，安全专家也不得不完全重新构想整个攻击向量。然而，安全本身具有内在复杂性，而文本注释无法充分解释这种复杂性，尤其是涉及相关需求时。此外，仅靠需求本身也远远不够。系统架构师和安全专家需要某种互操作性和相互协作的可能性，以便对同一模型进行注释。只有这样，他们才能对系统的架构做出必要的调整。迄今为止，系统架构师与安全专家之间尚未建立通过迭代过程进行的明确定义的交互方式。此外，有关安全预防措施的信息可能会不断累积并出现交叉引用。

与其他质量特性（如安全、安全性和时序）相比，这可能表明某个组件从一开始设计就存在问题。

4.2 识别汽车系统建模的需求

Classic AUTOSAR 目前仍是事实上的标准。然而，它仅允许在汽车中的嵌入式 ECUs 及其模型表示中使用。这一事实本身限制了对安全的关注。存在一些领域特定的架构描述语言（ADL），如 EAST‐ADL 和 AADL1，但建模环境分散且不具备平台无关性。

对于我们结合已建立的安全技术与汽车安全建模的方法而言，最相关的需求是：
– 对攻击和安全威胁进行分类。
– 定义安全目标。
– 通过添加实体来扩展元模型，以表示参与者，并将其与后果和受影响的建模实体关联起来。
– 表示攻击向量及其所有阶段——从攻击者到发生漏洞——直至受影响的车辆特性。
– 一种处理攻击向量的核心解决方案思路。

5 安全抽象模型—安全抽象模型

在本节中，我们介绍我们的创新性贡献：一种用于汽车建模环境的安全抽象模型（SAM）语言规范，作为EAST‐ADL的扩展。SAM是针对第4节所示用户故事中所提出挑战和影响的解决方案。我们阐明了安全建模与功能安全建模之间的区别，并描述了SAM的元模型实体。SAM以开源项目形式提供2。SAM的完整元模型（包括实体描述）也可通过在线HTML版本获取3。

5.1 安全抽象模型 元模型

SAM 包含一组具体的符合 EAST‐ADL 和 AUTOSAR 规范的安全建模实体。因此，SAM 提议作为对 EAST‐ADL 的一个附录扩展，以增加目前现有语言规范尚未涵盖的安全建模功能。为了提供充分的汽车安全建模环境，我们为 EAST‐ADL 元模型引入了新的建模实体。这些实体可在类型层（M1）上使用，用于创建安全汽车系统的功能架构。

1 www.aadl.info。 2 https://github.com/MarkusZoppelt/SAM。 3 http://www.in.th-nuernberg.de/SAM。

实体是：
– 攻击 ：表示通过攻击向量描述的针对系统的网络物理攻击。攻击向量是攻击者获取对目标系统未授权访问或损害一个或多个安全目标的路径或手段。攻击向量可通过攻击树识别和提取。
– 攻击者 ：攻击由个体或系统环境发起。无论哪种情况，攻击者均源自系统环境，因为他们不属于主系统模型的一部分，而是从外部进行交互。然而，攻击者也可能来自系统内部，例如来自未经授权的部件或设备。
– 攻击动机 ：对攻击者动机的抽象表示。每棵攻击树中至少存在一个攻击动机（即其根节点）。攻击动机与安全目标相冲突。
– 伤害 ：指攻击所构成的威胁，旨在主动或被动地伤害乘客及其他道路使用者。
– 信息获取 ：指攻击所构成的威胁，例如侵犯乘客、其他道路使用者以及情境或政治相关方（如OEM）的隐私。此外，还包括通过逆向工程等手段获取其他类型的信息，例如软件/固件。
– 经济利益 ：指攻击所构成的威胁，旨在为攻击者、维修服务车间或保险公司窃取或获取经济或物质利益，通常导致车主或OEM遭受经济损失。
– 产品修改 ：指通过篡改产品规格构成的威胁，例如从汽车中获取更多功能，或对软件整体进行篡改，如降级/升级。
– 抽象失效 ：一组项目未能满足其一个或多个需求的抽象性失效状态。
– 可攻击属性 ：攻击者为成功实施攻击而寻找或需要的项目特性或特定属性，例如无线通信能力。
– 漏洞 ：为了表示系统架构中的薄弱环节，漏洞用于描述弱点及其与一个或多个项目的关联。
– 安全目标 ：该实体提供适用于任何通信或数据流的通用安全目标枚举[6]，这些目标包括：保密性、完整性、可用性、真实性、可靠性和可问责性。
– 需求 ：为修复漏洞而定义的需求，所谓需求是经验教训的总结结果，并源自攻击。
– 功能安全概念 ：表示一组共同实现安全目标的功能安全需求集合，例如根据通用准则（CC）ISO/IEC 15408。
– 技术安全概念 ：表示一组技术安全需求，这些需求共同实现一个功能安全概念和安全目标，例如根据通用准则（CC）ISO/IEC 15408。
– 安全等级（SecL） ：安全等级（SecL）是一个枚举元类，其枚举字面值表示按照 SAHARA方法定义的安全级别[17]。
– 环境 ：环境并非新引入的实体，因为它已存在于其自身的包中，但由于攻击者能够利用环境进行攻击，并且在概念上攻击者本身也是环境的一部分，因此对环境进行了扩展。
– 安全专家 ：一个抽象类，用于提供一个属性knowledgeLevel，供攻击者继承。了解攻击者的知识或技能来源可能很有帮助，即使安全专家可能并非攻击的直接原因。
– 车辆特性 ：由可靠性包提供，车辆特性表示一种特殊类型的特性，专为车辆层级使用而设计。项目启用一个特性。

5.2 安全抽象模型的方法论背景

为了保护系统并抵御攻击和威胁，首先需要识别和分类这些威胁。对攻击动机进行分类已经在识别攻击方面带来了方法论上的优势。可以使用系统的安全分析来量化潜在攻击所需的努力。攻击者所付出的努力与系统工程师设计的安全层级之间存在着持续的对抗。由于没有任何系统能够完全防范各种攻击，系统工程师只能在不同层次的安全抽象之间进行权衡，以达到可接受的安全程度。因此，任何安全系统最终都是一种权衡的结果。

尽管安全抽象模型（SAM）不会直接在系统设计中注入安全性，但它强制要求对攻击及其对系统的影响进行反思，理想情况下这应由系统工程师与安全专家协作完成。虽然SAM的元层次较为抽象，但其应用在元层次M1上变得具体。请注意，从攻击动机（AttackMotivation）到项目（Item）的多重性为1..*到1..*，这意味着系统工程师必须为汽车系统的每个项目至少描述一个攻击动机。这对于发现威胁提供了重要的方法学支持。如果某个项目没有关联的攻击动机，则需要格外谨慎，例如可能是因为目前尚无已知针对该项目的攻击。在这种情况下，系统工程师可能会简单地放弃对该项目潜在攻击动机的深入审查。

安全抽象模型（SAM）在结构和方法上与安全建模（可靠性）具有相似性。对于汽车软件系统而言，安全建模与安全建模之间的主要区别在于对危险（安全）与攻击（安全）的分类。在功能安全方面，危险根据ISO 26262[12] ASIL等级进行分类。而对于安全威胁，目前尚无相应的标准。存在一项名为 ISO/SAE AWI 21434的ISO标准，“道路车辆——网络安全工程”，在撰写本论文时该标准正在制定中。

SAM 对功能安全概念 或技术安全概念没有明确的规范。然而，SAM 提出了通用准则（CC）ISO/IEC 15408 保护轮廓[32]作为一种可能的解决方案。通用准则是安全领域中一项成熟的标准，可在开发可靠系统期间提供指导。

安全风险与安全威胁之间的主要区别在于，安全威胁并非随机发生（即不受概率约束），而是总是在最坏情况下出现。而对于安全危害，则可以假设其具有统计概率。网络攻击由智能攻击者在对攻击者最有利的时机、且在防御最薄弱的环节发起。SAHARA方法[17]中使用了适当的度量方式来将攻击划分为不同等级。SAHARA方法结合了汽车HARA（危害分析与风险评估）与安全领域的STRIDE[5]，以进一步增强功能安全与安全之间的兼容性。因此，安全抽象模型（SAM）采用SAHARA方法中的安全等级（SecL）作为分类依据。此外，将安全目标与安全目标混淆可能会产生误导。然而，安全威胁可能引发安全危害，反之亦然。尽管如此，由于上述原因，在系统设计阶段不建议以相同的方式处理两者。另外，使用文本注释是一种不良做法。通常，从自然语言的注释转换过程中存在不精确性，可能导致安全专家的原始意图在转换过程中丢失，而这些意图对于准确表示系统模型及其安全机制至关重要。通过将安全抽象模型（SAM）嵌入EAST‐ADL的“可靠性”（Dependability）包中，并进一步集成到AUTOSAR中，可以实现安全解决方案的广泛复用。这使得开发工作量保持在最低水平，并能够在车辆的多种应用中实施全面的安全与安全解决方案。

安全抽象模型（SAM）通过提供建模实体“攻击者”，提供了对社会技术系统进行建模的可能性。安全目标需要在社会-技术背景或社会技术系统中得以实现。社会技术系统的定义是由人类和互联技术组成的组织化群体，以特定方式构建以产生特定结果[6]。然而，试图仅通过向系统添加密码学来提升安全性是一种谬误。密码学最多只能确保机密性，但无法涵盖可用性、可靠性或可问责性等安全目标。通过我们的方法，我们为汽车软件工程提供了安全与安保的协同工程流程（设计阶段的安全与安全保障）。

安全抽象模型：面向汽车软件系统的安全抽象模型 68

M. 祖佩尔特 和 R.T. 科拉加里

6 评估

为了证明安全抽象模型的可行性，我们通过开展一个建模示例以及采用“扎根理论”对来自汽车行业的专家进行访谈[7]来评估我们的解决方案。该建模示例采用了用户故事中的场景，并说明了第5节中介绍的方法。作为元模型的一个实例化。这些访谈提供了令人 compelling 的证据，表明在安全抽象模型元模型中添加的实体是正确且足够充分的，能够解决汽车系统建模的问题。

6.1 建模示例

安全抽象模型（SAM）使系统架构师能够根据第4节中描述的用户故事，为汽车软件系统建模安全架构。通过使用所提供的模型实体，系统架构师可以相应地表示攻击并建模威胁。他的团队计划对通过无线钥匙扣实施的劫持攻击向量进行分析。执行该攻击的攻击者是一名窃贼。他是唯一攻击车辆的人，企图通过无线方式打开汽车并悄然驾驶离开，以盗取他人的汽车。他的知识水平等于所定义的最低知识水平，即钥匙扣攻击的级别。为了实施攻击，他正在寻找可攻击属性可攻击属性滚动码，且目标车辆必须处于停车状态，即其状态为“静止且锁定”（模式）。可能发生的钥匙扣攻击的安全等级（SecL）被划分为2级。该攻击的动机是经济利益，与汽车盗窃相关。如果攻击者成功实施攻击，则意味着存在一个影响用于无线漏洞的项目的车辆特性无钥匙进入功能的无线漏洞。为防范可能的攻击，团队需要将无线加密定义为相应的需求。此建模示例在图2中以M1模型的形式展示。

6.2 与来自汽车行业的专家的访谈

我们通过扎根理论[7]对来自汽车行业的两位专家（安全与软件工程）进行了访谈，开展了一项实证分析。这些访谈旨在确定在安全抽象模型元模型中添加的实体是否正确或足够充分以解决该问题。

70 M. 祖佩尔特 和 R.T. 科拉加里

安全汽车系统建模。两位访谈对象均具有汽车系统工程和/或嵌入式安全领域的专业背景。尽管访谈对象的数量看似较少，但由于他们在汽车、安全与软件工程领域具有高度重合的专业性，因此非常符合本次评估的要求。我们的评估结果已公开发布于网络4，包括扎根理论的编码网络、精选引文以及编码表。访谈分为多个部分：首先，我们提出了一些关于汽车安全的通用问题，以了解我们所提出的解决方案的相关性。随后，我们向专家介绍了我们的方法，并展示了安全抽象模型（SAM）及其元模型。接着，我们针对概念及所引入的实体等细节对他们进行了访谈。最后，我们询问了他们对该方案在工业界接受程度的估计。

以下是访谈记录的相应摘要：我们询问了专家，他们将如何定义安全汽车系统的需求，以及如何以可视化方式描述攻击。他们提到的需求（例如，防篡改保护，且不危及生命和经济价值、无法从车辆中获取未授权信息等）符合我们定义的安全目标。他们也都同意使用图表来描述攻击场景，而非纯文本。同时，也有人提议使用攻击树。

我们询问了专家，我们的攻击动机分类是否充分，或者是否缺少某些额外类别。除了某些细微的措辞差异（例如，经济利益之前被称为经济损失）外，受访者完全认同我们的分类。专家们甚至强调了独特的攻击动机对其自身工作领域的 importance，并帮助阐明了不同攻击动机在不同场景下的益处。他们也接受了引入攻击者实体以在EAST‐ADL模型中表示攻击者的做法。

根据专家的说法，安全抽象模型（SAM）扩展往往对安全专家比对系统工程师更有用。“尽管在某种程度上，系统工程师可以从这样的模型中推导出一些可扩散的软件需求，”一位专家表示，“但它主要的价值体现在开发流程的早期阶段。因此，一旦开发人员开始关注软件架构和软件实现，他们就会确保掌握这些信息。” 其中一位专家强调了攻击动机和SecL分类级别的重要性。他表示，将攻击动机与安全等级（SecL）相结合，是向管理人员展示某一安全场景的重要性的良好方式。我们还向EAST‐ADL协会的一名成员展示了安全抽象模型（SAM），他确认我们的方法具有价值且有效，特别是因为它与可靠性包之间呈现出明显的对称性。所描述的机制也符合EAST‐ADL范式。自访谈以来，我们已根据专家的期望和建议对SAM进行了所有必要的修改。

4 https://www.in.th-nuernberg.de/Professors/AS2E/SAM/GT-Eval.pdf.

7 相关工作

通过SAM，我们致力于填补现有相关方法与解决方案之间的空白，并将这些知识转移到汽车领域背景中，通过将其集成到EAST‐ADL中，使其能够在汽车行业中实际应用。本节讨论了来自安全建模、安全需求分析以及汽车软件系统工程领域的相关工作。SAM利用了所列项目及相关工作中的一些通用概念。其中一项重要的基础工作包括Holm[11],提出的用于企业架构的网络安全建模语言（CySeMoL），Mouratidis[21]提出的安全Tropos（Secure Tropos），以及诸如“面向信息物理系统的基于模型的安全工程：系统性映射研究”等论文[22], Jürjens[15],提出的UMLSec，该方法允许在系统规格说明的图示中表达与安全相关的信息，国际系统工程理事会（INCOSE）关于将系统工程与系统安全工程相集成的工作[9],NIST SP 800-160[25]以及其他美国国家标准与技术研究院（NIST）关于信息物理系统的研究工作[16]。SAM相较于这些现有方法的独特特征和优势在于，它已经被集成到一个现有的系统模型（即 EAST‐ADL）中。SAM使用EAST‐ADL系统模型中的已有实体（例如，环境、危害、项目等），因此与系统模型紧密耦合。这使得安全模型能够无缝集成到汽车行业中广泛使用的系统模型中。

Thing和吴[29]在汽车领域背景下给出了一个阐述清晰的攻击与防御分类法，从攻击者和防御者的角度描述了常用术语。史密斯[28]描述了多种用于监控和操控汽车功能的渗透测试技术，并进行了图示说明。他还简要介绍了威胁评级系统[28,第11页–14]，如DREAD[24]和CVSS[19]，并与ISO 26262 ASIL等级进行了比较。汽车使用CAN总线在ECUs之间传输和接收信息。史密斯列出了开始监控CAN总线以及逆向工程汽车功能所需的基本硬件和软件工具。

除了自适应AUTOSAR（见第3.3节）之外，还有其他致力于汽车系统和信息物理系统安全的项目：PRESERVE 是一个“欧盟资助项目，运行时间为2011年至2015年，为未来车对车和车对基础设施通信系统的安全与隐私做出了贡献。它提供了车辆安全架构的安全需求”[3]。EVITA 项目旨在“设计、验证和原型化一种汽车车载网络架构，其中安全相关组件受到保护以防止篡改，敏感数据受到保护以防止泄露。它专注于V2X（车对万物）通信，并为电子安全应用的安全部署提供基础”[10]。

8 结论和未来工作

在本论文中，我们提出了一种在系统早期开发阶段对安全汽车系统进行建模的解决方案，以降低相关风险。在汽车系统生命周期中，安全威胁和漏洞的识别较晚。该方法通过抽象描述汽车安全建模原则，将安全管理与基于模型的系统工程紧密结合。由此产生的 SAM语言规范基于从常见工业场景中提取的安全需求，是表示车辆攻击向量的合适解决方案，并为汽车行业提供了全面的安全建模支持。通过依据扎根理论的方法进行定性分析，我们收集到证据表明，该解决方案与行业相关，并符合汽车软件工程的一般范式。通过改进对安全攻击向量的识别和探测，我们为汽车安全测试提供了坚实的基础。

未来工作将集中于以一种新颖的应用形式实现当前工作的成果，供原始设备制造商应用和实施本文所述的安全原则。例如，SAM的概念及其优势可以作为进一步开发自适应AUTOSAR平台（见第3.3节）的推动力。此外，安全等级目前缺乏一定的动态性。一旦某种攻击被公开，场景立即变为3级，而该特定攻击随即被明显低估。因此，需要一个更加动态的安全等级体系来涵盖这一方面。一个超出本文语言中心范畴的重大挑战是，如何支持安全专家从功能安全概念系统性地推导出技术安全概念。即使通用准则也未提供系统性的推导过程。一旦该过程得以实现，任何人都能够在实施层面定义硬件和软件。进一步的工作还可能聚焦于为SAM开发一个集成开发环境（IDE），用于对每个基于SAM的软件项目进行一致性、完整性和完整性检查，例如在MetaEdit+中。理想情况下，这将验证SAM在汽车软件规模、现实复杂性以及面对广泛存在的网络和物理攻击时的可扩展性。此外，我们用于功能架构描述的自上而下的方法，为网联车辆技术的一个主要应用奠定了基础：高度自动化和自动驾驶的电子控制单元架构。