Towards the Model-Driven Engineering of Security Requirements for Embedded System

面向嵌入式系统安全需求的模型驱动工程

摘要

本文讨论了为什么以及如何必须将安全需求工程调整为通常用于设计和开发嵌入式系统的模型驱动方法。 特别是，我们讨论了在多大程度上可以实现对安全性要求的启发和Y型图划分方法（嵌入式系统中的一种主要设计方法）可以相互充实。 我们还将展示SysML，它已经被普遍用来设计嵌入式系统中的需求，如何仅通过少量扩展就能代表安全需求，资产和威胁，从而支持更全面的需求工程方法。 我们以汽车嵌入式系统领域的示例为例，说明了整体方法和工具包的使用，以证明我们方法的相关性。

索引词-通信系统安全性； 计算机安全； 设计方法； 系统级设计； 组件架构； 嵌入式系统; 安全需求工程

1 介绍

嵌入式系统已经渗透到我们在各种设备，设备或命令与控制系统中的日常技术经验。 嵌入式系统由软件和硬件电子组件组成，它们紧密耦合在一起以形成嵌入式系统体系结构。 这些系统的软件部分会在产品发布到市场后为它们提供灵活性，例如通过固件更新-对于普通硬件而言，这是不可能的。 这些系统中的许多系统呈现出异构和分布式的体系结构，其特征在于使用通信总线互连的多个计算单元（微处理器或微控制器）。

在我们技术驱动的环境中，嵌入式系统的安全性正成为一个巨大的问题。已经为此类系统开发了许多安全性机制，但是它们的使用通常会忽略所表达的功能和其他非功能性要求，并且通常在设计周期的后期引入它们。尽管如此，已经有许多安全需求分析方法学并未与嵌入式系统架构师的常规工作流程集成在一起。本文讨论了为什么用于设计和开发嵌入式系统的模型驱动的工程技术，特别是它们捕获硬件/软件分区和安全性需求工程的方法应该齐头并进。我们定义一个新的基于SysML的框架，称为SysML-Sec，以支持嵌入式系统的安全性要求。 SysML通常用于捕获嵌入式系统体系结构和功能要求。我们将说明如何仅使用非常有限的SysML扩展就可以同时表示资产和复杂的攻击序列，从而适应嵌入式系统的模型驱动设计过程。

2 动机和贡献

安全需求和威胁分析通常被视为IT系统中风险分析的序言。 此过程通常旨在决定是否在系统中引入安全对策，这会导致额外的成本。 对于嵌入式系统，我们认为安全性分析对系统体系结构的设计也有很大的影响。 在安全性至关重要的系统中尤其如此，在这种系统中，攻击可能具有毁灭性，但安全功能的开销也可能导致绝对无用的系统。 我们还声称，在说服日益复杂的嵌入式系统的设计人员其安全架构的一致性和详尽性方面，安全分析也应发挥重要作用，至少在确定的威胁方面。

A 嵌入式系统的安全攻击

与IT系统中的情况相反，在嵌入式系统的环境中，安全问题受到的关注很少。 但是，越来越多的嵌入式系统已成为通信工件，具有与其直接环境或后端系统的新交互功能，因此容易受到犯罪分子的攻击。 以下示例说明了典型的攻击和安全问题：

机顶盒。 微软XBox的攻击[1]是对不受保护的总线进行物理攻击的著名案例。 其他类型的机顶盒也受到了应用软件或协议栈攻击的攻击，例如ADSL路由器[2]。

移动设备。 与通常的移动电话一样，移动设备在现有漏洞方面也面临许多安全挑战。 攻击变得越来越复杂，例如，黑客试图实现iOS越狱，通常涉及在链中使用多个漏洞[3]。

航空电子。 现代飞机具有少量的嵌入式系统，每个系统都与特定的任务有关。 飞机内部网络现在与地面系统以及乘客或乘务员网络互连，因此引起了严重的关注，需要引入过滤机制。 导航系统的最新研究反复报告了其设计缺乏对安全性的关注，以及对这些不足的可能利用的风险和手段[4]，[5]。

汽车系统。 现代汽车车载网络通过网关将数百个微控制器（称为电子控制单元（ECU））互连到特定应用域中。通过绕过域之间执行的过滤或基于蛮横的ECU密码学保护机制，攻击似乎是非常可行的[6]。 实际上，此类攻击可能源于车辆中越来越多的Internet连接，甚至源于受损的移动电话与车辆车载网络的蓝牙配对。 预计在即将到来的Car2X应用程序中会出现进一步的攻击，这些应用程序将具有车辆到车辆或车辆到基础设施的通信功能。

B 贡献

我们的第一项工作旨在将安全性分析引入当前用于嵌入式系统的设计方法中，并确保设计趋于可行的解决方案。该解决方案应通过适当的安全机制显着缓解相关威胁，但要确保这些机制不会由于通信资源（安全机制的开销过多，尤其是加密协议的开销过多）和执行资源（过多的开销）而妨碍系统的正确运行。实时假设下来自安全性计算的开销，例如，验证两个微控制器之间所有消息的签名）。这本质上是一个迭代过程，必须集成到现有的设计工具和方法中。例如，只有在系统设计者确定了总线的存在及其上交换的消息之后，才能识别对CPU及其内存之间总线的攻击，并且安全专家和系统设计者应该有一种方法使用统一框架传达各自的关注点。

其次，我们的工作旨在定义支持威胁建模和相关对策的机制。 在嵌入式系统中必须考虑的多个抽象级别上，该建模应该很有用。 例如，可以描述对一组物理互连的硬件组件或映射到它们的逻辑功能的攻击（这些区域甚至可能在CPU内定义）。 受信任的计算小组的TPM或ARM的受信任的区域可以很好地说明虚拟化和受信任的计算等技术，它们可以防止攻击者侵入此类区域。 防篡改硬件（例如智能卡）也通常用于保护机密或计算。无安全性方法的威望描述了这种受信任的边界并将威胁映射到它们。

最后，我们还打算提供一个框架，以通过记录组件漏洞来支持组合。 系统产品线产品组合中组件的重用要求将这些知识转化为资本，以便在将几个软件和硬件组件组合在一起时更好地评估潜在风险。 我们在本文其余部分中提出的框架也旨在支持这项活动。 但是，我们不在本文范围内讨论风险评估。 我们认为我们的提案可以与该领域中的多个现有提案兼容，包括我们在EVITA案例研究中开发和使用的提案[7]，[8]。

C 用例

在整个本文中，我们将在不影响通用性的情况下，举例说明SysMLSec的使用方法，并给出了我们在FP7欧洲研究项目EVITA范围内进行的研究结果。 该项目包括一家主要的汽车制造商和一级设备供应商，研究了汽车车载网络的安全性。 EVITA合作伙伴设计和开发了一种原型安全汽车车载网络。

大约有20种场景中的两种场景专门用于说明我们的需求工程方法。 第一个是固件刷新，用于处理车间的维护操作。 它特别解决了以安全方式更新ECU固件的需求，这种方式应同时保护汽车制造商或设备供应商的知识产权和更新过程的完整性。 第二个用例是“本地危险警告”，用于防止对汽车安全关键功能的攻击，以显示来自内部传感器或附近利益相关者（路边设备或其他车辆）的警告。 开发的体系结构应特别防止显示伪造的警告，例如有关事故的虚假通知。

3 带有安全需求工程的扩展嵌入式设计方法

由于许多嵌入式系统对安全性至关重要，因此，嵌入式系统的面向安全的模型驱动工程方法已被很好地建立起来，即它们的故障可能会伤害其用户。 但是，尚未评估嵌入式系统的安全性及其对嵌入式系统安全性的影响。

A MDE和嵌入式系统：当前实践

OMG的模型驱动架构定义了两个抽象级别，即平台无关模型（PIM）和平台特定模型（PSM）：因此，嵌入式系统显然是MDE的目标。 OMG还定义了SPT [9]和MARTE [10]配置文件，以更专门地解决嵌入式系统，但它们都没有解决需求建模问题。 相反，SysML OMG配置文件[11]明确考虑了具有明确建模功能和图表的需求，但仅在非常有限的范围内解决了分区阶段。

嵌入式系统领域中特定设计实践的存在和使用，使得必须开发出一种可适应的安全需求工程方法论，该方法论可以集成到设计者的工具箱中。 我们决定采用SysML进行模型驱动工程，因为它被越来越多的采用和广泛的应用范围。 可以使用MARTE方法代替分区。

B 硬件/软件划分的重要性

以软件为中心的系统通常使用Vcycle进行设计，其构建阶段（需求，分析，设计，实施）随后是验证阶段（例如测试，形式证明）。 对于嵌入式系统，显然只有在功能在软件和硬件中进行分区后，V周期才能启动。

系统分区是一个过程，用于分析系统规范的各种功能上等效的实现。 它通常依赖于图1所示的Y图方法[12]：

1）首先将应用程序描述为抽象通信任务：任务结合了几个相关功能。 任务和功能的定义独立于其实现。

2）目标架构是从任务中独立描述的。 通常用一组抽象执行节点（例如，带有操作系统和中间件的CPU，硬件加速器），通信节点（例如，总线）和存储节点（例如，存储器）来描述它们。

3）映射过程定义了如何将应用程序任务和任务之间的抽象通信分别分配给计算和通信/存储设备。 例如，映射在硬件加速器上的任务是硬件实现的功能，而映射在CPU上的任务是软件实现的功能。

该过程的结果将是针对特定系统的关键标准（例如成本，面积，功率，性能，灵活性等）的最佳硬件/软件架构。 此分区过程至关重要。 确实，如果由于问题（性能，功耗等）的发现较晚而使关键的高级设计选择无效，那么这可能会导致重新设计的成本过高，以及市场的可用性不足。 因此，我们认为，必须对安全要求和相关的威胁分析进行详尽的标识，然后再进行划分。

在“本地危险警告”用例的范围内，图2给出了功能映射的示例。 代表两个ECU子域。 左侧的机箱安全控制器，右侧的车身电子模块。 每个子域都有一个主处理器，一个本地闪存，一个本地主存储器，一组硬件加速器以及一个通往主系统总线的桥。 功能既可以映射到处理器上（这些功能将由软件实现），也可以映射到硬件加速器上（将功能进行硬件编码）。 任务之间的通信也将通过总线和内存进行映射，以突出显示数据传输。

C SysML-Sec：一种基于安全意识的模型驱动方法

我们引入SysML-Sec框架，旨在指导和提供与非安全专家的从业人员的MDE方法兼容的安全要求。特别是，安全专家将通过这种方式与系统工程师进行协作。

我们的方法是SysML-Sec框架的一部分，可以灵活地随着体系结构规范的发展而捕获前几节中描述的设计目标。 我们可以通过以下迭代过程总结其不同阶段：

初始架构映射： 选择一个或几个典型用例作为起点。 这些用例中突出显示的系统功能首先被建模为任务。 任务之间的通信以信息流和事件流为模型。 还捕获了基于事件的通信，以控制信息流。 然后可以将任务和通信映射到系统的架构草案。 设计师的经验对于确定初稿架构起着关键作用。

系统资产标识。 系统资产在体系结构元素（处理器，软件片段，通信通道）之间进行标识，并且首先涉及通用组件，例如：“所有系统总线”。 当体系结构变得更加详细时，资产更有可能被细分为特定元素。

威胁识别和评估。 所选资产的威胁和安全漏洞使用我们对SysML参数图的扩展来记录。 威胁应尽可能描述攻击者应达到或超过的功能，以及有关攻击起源的信息（本地，远程，通过特定接口）。 我们还通过安全目标实施了自动检查软威胁覆盖。 基于风险分析（本文未讨论），还应该确定映射到威胁的安全目标并确定优先级。 最重要的安全要求应进一步完善。 在此阶段，其他需求可能会被搁置甚至放弃，但在SysML图中仍会记住，特别是在需要其他分析的情况下。

安全目标识别。 可以（1）从上述用例中确定安全目标，例如，由于强加的标准或系统预期的属性，或者（2）未解决的威胁或对资产的攻击，或者（3）作为另一个的改进 迭代过程且体系结构的详细级别已更改时的安全性目标。 它们使用SysML需求图表示。 在进一步的迭代中，对体系结构的修改不赞成删除安全目标。

**体系结构优化。**完善了架构，包括资产规范。一方面，随着使用案例或体系结构变得越来越精确，这种改进将导致对体系结构组件的更详细描述（例如，新的通信渠道，将执行环境限定为OS /中间件/应用层等）。 。另一方面，它也可能导致需求与系统信息流的链接。最后，正在进行的过程被反复用于识别新的安全问题。如果架构和安全性要求不兼容，例如，如果安全性机制的性能开销过高，则优化阶段可能会失败。还应该执行一致性检查，以确保安全目标不与针对同一资产表达的另一要求冲突。失败表示该分析应追溯到先前的详细级别，并且可能应采用其他安全解决方案。 SysML-Sec图的版本控制可能支持这种方法论上的回溯。

D SysML-Sec：配置文件和工具支持

前面提到的方法已经用TTool [13]实现。 TTool是一个开源工具箱，它支持多个UML配置文件，包括DIPLODOCUS [14]和AVATAR [15]。 TTool包括制图工具，正式和非正式代码生成器，模型模拟器，模型检查器和分析工具。 TTool的主要优势是隐藏有关基础模拟或形式证明技术的知识，从而提供按按钮的方法来执行安全性或安全性证明。

SysML-Sec依赖于DIPLODOCUS进行分区。 特别是，与硬件元素（例如，总线探测，内存转储等）高度相关的安全要求和攻击可以更容易地识别，有时甚至可以进行评估。 还可以测试和正式验证安全机制的影响，例如，研究是否由于安全功能而违反了给定的安全相关期限。 SysML-Sec是基于AVATAR构建的，用于需求确定，威胁捕获和安全机制设计。 可以捕获并进一步证明与安全性相关的属性。 我们的工具还提供了一些基本的自动化功能，例如验证具有适当安全要求（或不存在安全要求）的威胁的覆盖范围，如图3所示。

4 基于架构识别和分析安全需求

A 安全目标和要求

海利等。文献[16]表明，安全要求的含义在文献中有很大不同。正如他们指出的那样，安全性要求必须足够精确，并且应该能够描述我们需要保护哪些对象以及原因，以及描述如何解决体系结构漏洞。海利等。结论是，应该遵循基于目标的方法以及与执行环境紧密相关的上下文描述。它们按以下方式区分安全目标和要求：后者“以可操作的术语表达系统的安全目标，要足够精确以提供给设计者/架构师”并提供“规范”。尽管我们大多数都同意这种观点，但在代表的情况下我们并未划清界限。例如，某些精确的安全性要求可以在设计的早期阶段就表现出来，因为它们非常通用。相比之下，在将体系结构及其分区候选者定义为较低的抽象级别之前，无法实现某些安全目标。在我们的案例研究中，有时我们认为看似精确的安全要求有时也只是复杂的安全目标。因此，即使将安全目标和要求明确地定型为目标和要求以区分其抽象级别，我们也将它们分别描述为SysML要求。 SysML需求属性与其他需求的依赖关系数量一起也有助于精确化其抽象级别。

B 安全资产

海利等。 [16]进一步描述资产是定义安全目标背后的中心概念。特别是，发现资产会导致对资产的威胁，并选择适用于保护资产的特定安全原则。尽管我们建议评估所考虑的安全资产的类型，但这会影响嵌入式系统中相关安全要求的性质，我们同意这一观点。具体来说，我们将资产分为三类：（1）硬件组件（处理器，内存，通信通道，时钟等），包括它们包含的数据（和秘密）； （2）软件资产（虚拟化机制，驱动程序，协议栈，应用程序……）； （3）捕获通信的信息和事件流：这些流反映了用于实现特定服务的功能的组成以及通信功能，以传输其数据和控制事件。这样的流通常可以表示为SysML框图，其中每个块对应一个系统功能，两个块之间的每个链接对应一个事件或数据流。例如，图4示出了功能视图的子集-在划分的阶段-将导致汽车在EVITA系统中接收或转发紧急情况。这些元素（资产，攻击和需求）之间的关系将由我们在下面进一步描述的模型定义。

C 安全威胁与架构

安全威胁定义了在存在恶意行为的情况下可能导致系统故障（即成功的攻击）的情况。我们有兴趣描述攻击者必须破坏哪些资产才能执行成功的攻击。对目标安全资产的任何安全目标均未涵盖的安全威胁的识别，显然是对安全要求的不完全理解。设计人员通常必须重新考虑安全目标到资产的映射（如下所述），或者确定丢失或不完整的安全目标。另一方面，虽然对威胁的识别对于验证安全目标是值得的，但我们并不希望对它们进行详尽的识别。安全需求可能只是由于需要与某个安全标准互操作，甚至超出了针对保护配置文件的系统认证（例如在通用标准方案中定义的）。

攻击包括针对资产的操作列表（读取总线上的消息等）。现在，对嵌入式系统的威胁通常不仅包括对系统组件的一系列漏洞的利用，而且还包括对系统组件的一系列漏洞以及系统设计中的错误的利用。威胁通常使用各种各样的攻击树来建模。我们在SysML-Sec模型中表示类似的概念，该模型将给定威胁的攻击阶段映射到体系结构。图5描述了如何通过SysML参数图的简单扩展来实现这种映射。特别地，每个块代表攻击映射到的资产。一些方法旨在定义安全威胁，作为对攻击者目标的精细定义，例如KAOS的反目标[17]。尽管逐步应对威胁和最终攻击步骤是适当的，但我们认为这不足以捕获所有体系结构映射。对于仅解决计算单元和通信通道（在SysML参数图中被视为块）的攻击，普通的改进是令人满意的。但是，嵌入式系统具有的数据和事件流分布在整个体系结构上。可以将对这些资产的攻击建模为对先前两种资产的攻击的组合：例如，攻击者控制中间网关（例如，网桥CSCU_to_CAN）可能会威胁两个ECU之间的通信，见图2- ，然后删除所有到达频道的消息。因此，我们定制了SysML参数图约束，以引入诸如AND和OR之类的逻辑运算符，以及诸如AFTER之类的时间因果运算符来表示攻击序列（参见图5）。这些新限制对于描述嵌入式系统中遇到的分布式攻击情形特别有用。

D SysML捕获安全目标

SysML始终支持需求的概念。但是，我们通过添加安全性种类（例如，隐私，机密性，真实性，完整性，不可否认性，受控访问，可用性，免疫力，新鲜度）对SysML-Sec通用SysML要求进行了专门化，以进一步对模型中使用的安全目标和要求。需求之间的SysML关系-例如组成，派生需求和副本-可以应用于安全需求以及其他需求。例如，在图6中，ControlledAccessToFlashMemory由两个子需求组成：ControlledAccessToFlashingFunction和ControlledAccessToReadFromFlash。从语义上讲，R1由要求R2和R3组成，这意味着R1比R2和R3更抽象，并且必须满足R2和R3才能满足R1。将安全需求与其他种类的需求集成在一起，尤其可以通过依赖关系来验证不断发展的需求，这对于安全需求而言可能非常重要。

E 将安全需求映射到架构

即使使用其他语义扩展了SysML需求结构，需求仍然与资产无关。 如前所述，嵌入式系统中的资产由系统的功能和体系结构元素组成，这使我们可以在分区阶段将需求映射到资产。这还使我们有可能将需求与攻击相关联，因为只能定义攻击 从资产。

新资产的引入显然可能导致新需求的定义。 例如，在分区阶段引入闪存（参见图2）可能会导致对存储在这些闪存中的软件代码的安全性有专门的要求（例如，如图6所示）。 但是，引入闪存并不意味着它们全部都将存储机密软件代码。 这两个例子说明了两个重要点：（1）在分区阶段研究候选架构时，可能会发现新的要求。 （2）需求需要与建筑元素相关，以便准确地确定哪些需求适用于哪些建筑元素。

SysML提供了两个主要功能来将SysML构造的实例关联在一起，即使它们源自不同的视图：依赖关系和分配关系。 第一个模型对主元素和从元素之间的显式依赖进行建模。 相反，分配关系用于提及提供给元素的资源，例如在映射阶段分配给处理器的任务。 最后，需求和体系结构元素之间的关系用依赖关系链接表示。

5 根据安全要求改进架构

A 从安全要求到安全机制

所表达的安全性要求有助于确定需要实施的安全性机制，例如加密或访问控制。但是，很可能在架构规范结束之前无法完全定义这些机制。我们认为，将广泛的安全功能的描述引入体系结构以弥合需求分析阶段和体系结构指定阶段之间的差距仍然是可能的，也是可取的。特别是，重要的是描述用于实现安全性相关算法的代码将在何处运行，以及其执行的弹性。在定义需求时，有关实现弹性的假设应转移到硬件/软件分区模型中。这样，我们也将安全要求与建筑资产相关联，从而精确地确定其实现可能面临的威胁：例如，对于远程攻击者来说，使用基于硬件的实现来实现对汽车头部单元的访问控制将足以缓解所有绕过此控件的尝试。我们在第六节中说明了这种映射过程可以在多大程度上实现更完整和准确的威胁分析。最后，该映射甚至可能揭示任何令人满意的实现的可能性。

找到哪些资产处于危险之中，也有助于定义相关安全目标所实现的防御边界，并因此有助于确定从该目标衍生而来的安全机制。 通常，从驾驶员的手机向车辆骨干总线注入假交通的可能性可能暗示在引擎，底盘和安全域中过滤掉手机消息。 反过来，这可以通过使用加密方法对发件人进行身份验证，也可以根据流量的来源通过相应域网关的访问控制来实现。

由于我们关注的威胁以通信为中心，因此安全功能的引入还将修改嵌入式系统的纯功能信息和事件流。 我们通过向现有实体添加安全功能或引入新实体来引入安全性。 这些新实体通常会具有特定的安全属性，这些特定的安全属性应与体系结构中的最终实现相匹配：例如，一个这样的附加实体可能反映了使用防篡改硬件模块（以及与其进行后续通信）或网关的需求 定义一个受信任的域。 到体系结构的那些其他安全性映射可能会在顺序图中引入，或者最好在部署图中引入。

B 检测冲突的需求类别

模型驱动工程显然是指抽象级别，并建议依靠模型转换技术来处理两个不同级别之间的转换。 系统元素的优化（例如，将功能拆分为两个子功能，将计算硬件域拆分为两个子域）可能会影响需求和攻击的定义。 改进需求和攻击，或者识别新的需求和攻击，也可能影响系统设计本身的定义。 即使未定义特定的优化方法，SysML也可以提供优化的运算符来表达这种优化的设计。

安全需求通常可能会影响其他类别的需求，尤其是诸如互操作性之类的非功能性需求，或者对于嵌入式系统而言，更为关键的是安全性。 这可能会导致冲突。 例如，过大的安全有效载荷可能会减少总线的可用带宽，并危及制动传感器与制动执行器之间紧急制动通知的安全性至关重要的传输。 同样，安全性可能会产生额外的成本，例如用于验证消息的签名，这可能会导致低成本ECU的等待时间过长。 必须发现这种冲突。

我们认为，由于我们专注于以架构为中心的安全性资产，因此我们的SysML-Sec方法与可以将需求链接到体系结构的其他需求工程方法兼容。 虽然我们没有尝试将现有工程方法学用于其他类型的需求，但是我们通过从嵌入式系统模型中生成测试和仿真来验证一些安全需求的满足[18]。

6 得到教训

我们在本文中介绍的案例研究的全部结果可以在EVITA项目网站1和[8]中找到。我们提取了大约32个通用需求，即适用于所有用例的需求。这些需求已分为四类：可用性（7个需求），隐私（7个需求），伪指令（9个）和与环境相关的需求（9个）。从特定需求到第一个分析用例，已经逐渐提取出一般需求。它们可能构成定义面向安全的模式的良好基础。然后，对于每个用例，我们都定义了特定要求。例如，对于固件更新用例，提出了9个其他安全要求：图6中显示了其中的一些。一般要求和特定要求都与资产和攻击相关联。需求，体系结构和攻击之间的迭代使我们发现的攻击比基于安全专业知识和集思广益的会话简单地识别出的攻击要多：识别出的攻击次数乘以2到4之间的倍数，具体取决于用途案件。

成就： 我们最初的目标之一是实现对车载系统安全问题的全面，系统的分析。 我们的方法显着改善了对安全要求的启发。 例如，坚持循序渐进的过程有助于我们抵制不断寻求直接为系统设计选择特定安全机制的需求。 这可能会导致对车辆威胁的了解不够完整，并且对安全要求之间的依存关系的了解也较差。 同样，对体系结构和功能布局的使用帮助我们理解了用例，并指出了它们所表达的安全要求方面的一些不一致之处。 例如，当用户特别要求在其用例中使用数字签名时，就无需要求拒绝固件更新。

我们的分析结果也可以与Bar-El [19]在汽车车载网络上的工作进行比较。 后者的工作捕获了许多安全要求，仅着眼于要在车载网络中部署的加密协议。 但是，[19]无法捕获硬件/软件分区或安全机制与安全要求之间的兼容性，这在车辆中非常重要，例如发送和验证消息所需的延迟。 相比之下，我们依赖于安全要求与资产以及信息流的映射，以便稍后通过正式验证[18]以及在同一开放环境中通过测试和模拟来评估安全，实时或性能要求的满意度。 源工具箱[20]。 我们进一步认为，我们的分析还捕获了更高级别的安全性要求，因为它是从安全性属性而不是机制开始的，并描述了它们的依赖性。

局限性。 我们的方法无法弥合实施差距。 特别是，我们没有描述有关实现所描述需求的安全机制的有效性的需求。 最值得注意的是，诸如缓冲区溢出之类的安全编程问题正在困扰着所生产的各种软件，但是它们并不是架构设计不佳的结果，正如我们在SysML和UML中所描述的那样。 同样，基于硬件的实现可能做得不好，例如容易受到定时或电源攻击的影响。 我们认为，解决此类问题本身并不是体系结构设计问题，可以通过软件或硬件安全性强化工程配方的系统应用来解决。 我们的方法论或开发的工具都无法为这些任务提供支持（尽管它们可能记录了COTS的此类弱点）。

7 相关工作

在过去的十年中，安全需求工程领域取得了相当可观的进步。 在[21]中，Nhlabatsi等人。 根据四个维度对软件系统中的安全需求工程工作进行分类，即：（1）基于目标的方法，（2）基于模型的方法，（3）面向问题的方法，（4）面向过程的方法。

我们自己的建议基本上将针对安全性目标的面向目标的描述（从KAOS框架[17]启发而来）与模型驱动的系统设计方法联系在一起，尤其是对安全资产的提炼。

尤其是，我们受益于基于目标的方法的改进和跟踪质量，这些方法在需求工程的其他领域也同样取得了成功。 面向目标的方法的另一个优势在于，即使具有高度抽象的安全需求之间，也能够捕获依赖关系。

根据[22]，[23]中表达的观点，我们强调资产对于设定基于目标的需求的重要性。但是，相比之下，我们认为嵌入式系统在架构的不同级别具有不同性质的资产，我们不打算在完整的因果图中进行互连（尽管我们引入了一些有限且局部的关系来执行）一致性检查）。

另一方面，模型非常擅长捕获体系结构细节，并且已被证明是描述有关加密协议的安全性要求的出色工具。例如，像UMLSec [24]这样的方法专注于将安全机制映射到软件体系结构。据我们所知，然而，没有这样的方法能够解决硬件和协同设计问题。在我们的框架中，安全要求和功能可以逐步完善，直到在我们的工具包中集成了正式的验证步骤[15]。 TTool实施模型转换技术，以便将经过提炼和正式表达的安全要求转换为由基于Dolev-Yao的安全证明工具包ProVerif作为输入的pi演算规范[25]。

如前所述，我们的方法旨在实现可行的设计。其他提议也暗示需要确定满足安全要求以及功能或其他非功能要求的正确折衷方案[26]，[27]，[28]，[29]。将安全要求引入SysML框架的方法论进一步丰富了这些贡献是通过在模型驱动工具的支持下确定对折衷效果的满意度进行定量评估来确定的。例如，我们模拟了CAN总线，以评估实现我们的身份验证要求的加密包络的影响[20]。我们还通过自动生成AVATAR模型中虚拟原型环境的软件来评估EVITA紧急制动用例中的制动等待时间[30]。通过使用SysML测试用例，甚至可以在安全需求的目标级别描述中描述其中的一些验证。

值得一提的是，在嵌入式系统领域，研究人员长期以来一直支持模型驱动的需求工程[31]，[32]，[33]。但是，只有Peraldi等人。 [34]提倡将系统架构的模型驱动工程与我们在方法中遵循的以目标为导向的表达联系起来的需要。据我们所知，这些提议都没有解决安全要求的表达。

我们的方法学建议也与Nuseibeh提出的TwinPeaks方法[35]有很多相似之处，尽管后者仅涉及软件系统。并非像TwinPeaks所建议的那样，在需求和体系结构之间进行简单的螺旋交替，而是在软件的Y-Chart建模及其对硬件组件的映射，资产的识别和对其的威胁以及安全需求的识别之间进行交替。特别是，我们还处理了TwinPeaks旨在解决的三个管理问题：（1）尽早探索解决方案空间（在我们的示例中，嵌入式系统体系结构和该设计可能导致的攻击）使之有可能逐步进行提供有关需求的反馈； （2）设计者必须依靠现成的商业软件（例如TwinPeaks）或可用的电子组件，或者标准的加密算法和要求（我们的建议中的安全要求）有助于缩小选择范围； （3）快速变化，这在我们的案例中也与完善架构息息相关。

8 总结

我们引入了SysML-Sec，这是一个在嵌入式系统中支持安全需求工程过程的环境，而一个开源工具（TTool）可以支持该过程。 我们在定义中的车载系统上进行了一项实验，这有助于我们评估方法的适当性。 从这些经验中，我们的主要主张是，安全需求工程方法应捕获安全问题与系统体系结构之间的关系。 安全要求应映射到此体系结构上，进而通过迭代优化设计过程扩展嵌入式系统中使用的经典Y型图方法来影响系统体系结构。

我们还认为，从早期定义安全需求开始，就可以使用我们采用的SysML支持的模型驱动的安全资产预定义，从而将安全专家的面向目标的观点与嵌入式系统设计人员的以模型为中心的观点联系起来 并在他们中的任何一个做出不适当的解决方案之前就可以进行协作。

我们计划进一步研究验证需求的问题。 我们已经进行了评估安全性要求之后引入的安全机制可能如何影响安全性的实验，例如评估通过安全通信执行制动操作所增加的等待时间。 我们还计划在我们的建模环境中引入面向安全的推理能力。