摘要

网络物理系统是控制机械部件的计算机化系统。这些系统必须既功能安全又网络安全。因此，已建立的功能安全与网络安全标准需求创建网络安全档案（ACs），以论证系统是功能安全与网络安全的，即所有功能安全与网络安全目标都已实现。然而，在实践中，功能安全与网络安全团队往往分开工作，网络安全档案通常在开发后期以手动方式创建。除了重建已采取的设计决策需要付出巨大努力外，这种方法还会导致在更改几乎不可能的后期才发现冲突。由于工程师经常利用缓解策略和对策模式来实现既定的功能安全与网络安全目标，因此我提出了一种方法，通过增加这些模式的额外设计原理和网络安全档案片段，以半自动方式支持完整网络安全档案的创建。通过这种方法，我希望通过在开发的早期阶段将功能安全与网络安全专家聚集在一起，为集成的“设计即功能安全与网络安全”流程铺平道路。这一目标将通过允许他们基于共同的设计原理开展工作来实现，而这些设计原理还将被用于自动推导网络安全档案。从而，减少了创建网络安全档案的手动工作量，并降低了出错的可能性。

1、引言

网络物理系统（CPSs）是计算机控制的机械系统（例如，现代汽车或工业控制系统）。这些系统通常由大量相互连接的子系统和组件组成。由于由此产生的高度复杂性，网络物理系统通常采用基于模型的技术进行设计。此外，网络物理系统通常是安全关键的，因为它们通常由人类操作，或者以某种方式与人类或环境交互。为了能够远程访问网络物理系统，它们越来越多地连接到互联网。结果，这种连接性也使它们成为攻击者的诱人目标。因此，网络物理系统也变得越来越网络安全关键。

为了使这些系统安全，必须识别和缓解对人类健康和生命或环境的潜在危害。例如，在汽车领域，ISO 26262 标准要求工程师在危害分析和风险评估（HARA）阶段执行安全活动。在HARA 阶段，识别潜在危害并定义系统必须实现的安全目标。在部署系统之前，工程师必须通过论证这些安全目标已实现且所有相关危害已被预防，来证明系统是安全的。这种论证在安全档案中进行。安全档案通过论证所应用的缓解策略和对策的有效性，展示安全目标是如何得到满足的。

类似地，为了使网络物理系统网络安全，必须识别对系统的潜在威胁。网络安全的重要性日益增加，这也反映在工业领域（参见 IEC 62443）和汽车领域（参见 ISO 21434）采用新的网络安全标准上。例如，在汽车领域，ISO 21434 标准要求工程师在威胁分析和风险评估（TARA）阶段执行网络安全活动。在 TARA 阶段，识别系统面临的威胁以及系统必须实现的网络安全目标。同样，为了论证系统是网络安全的（即所有网络安全目标都已实现），需要构建一个网络安全档案。

仔细观察这两个过程会发现，在功能安全与网络安全这两个领域，都进行了早期分析（分别是 HARA 和 TARA）。此外，所有相关的功能安全与网络安全标准都要求构建功能安全与网络安全档案（或更一般的网络安全档案）。此外，这两个领域之间存在相关性。出于安全原因做出的决策（例如，要求信息公开可用）可能与网络安全决策（例如，要求信息隐藏）相冲突。因此，安全档案需要参考网络安全档案中论证的决策，反之亦然。为了处理相互冲突的功能安全与网络安全目标，功能安全与网络安全团队在开发过程中协同工作（设计即功能安全与网络安全）是有利的。

然而，在实践中，功能安全与网络安全团队往往各自为政。但至少在创建网络安全档案方面，两个领域的团队应该相互沟通，以协调功能安全与网络安全决策，因为功能安全与网络安全档案之间存在依赖关系。然而，网络安全档案通常在开发结束时以基于文本的方式手动创建。这是有问题的，因为潜在的冲突可能在开发后期才被发现。此外，由于网络安全档案的目的是传达和解释所选对策与已定义的安全或网络安全目标之间的关系，因此其构建需要早期开发阶段（例如，系统设计阶段）的决策。这些决策，即设计原理，包括设计决策背后的原因、其合理性、考虑的替代方案和权衡，以及导致该决策的论证。然而，设计原理通常没有记录，仅作为隐性知识存在于相关工程师的脑海中。如果在开发后期创建网络安全档案，工程师就必须手动重建隐性的设计原理，这会导致大量的工作量和较高的出错可能性。

为了简化网络安全档案的创建并提高其构建效率，我提出了一种方法，通过形式化这些措施和相应策略背后的意图和原理，积极支持从更高层次的目标（无论是安全还是网络安全）到实际更具体的对策的决策制定和细化过程。然后，这种形式化的设计原理将用于自动推导网络安全档案。

本文的其余部分结构如下：在第2节中，我将详细描述问题，并提出我希望通过工作解决的研究问题。第3节介绍相关工作，并说明当前最先进的研究为何不足以解决所述的研究问题。第 4 节通过解决每个所述的研究问题来呈现我的解决方案。在第 5 节中，我将介绍评估我的研究结果的评估方法。最后，第 6 节总结本文，并展示研究的当前状态。

2、问题描述

为了进一步说明研究挑战，图 1 展示了一个基于 ISO 21434 汽车网络安全标准附录 G 中的示例的汽车领域简化示例。该图显示了一个 UML 组件图，包含汽车前照灯系统的五个组件：HeadlampSwitch（前照灯开关）、BodyControlECU（车身控制电子控制单元）、PowerSwitchActuator（电源开关执行器）、GatewayECU（网关电子控制单元）和 NavigationECU（导航电子控制单元）。这些组件代表汽车电子控制单元（ECUs），其功能是打开和关闭汽车的前照灯。在汽车系统中，电子控制单元通常通过总线系统（例如，CAN 总线）相互通信，每个电子控制单元都被允许在总线上写入和读取数据。为了按功能分隔电子控制单元，现代汽车有多个用于不同任务的 CAN 总线。为了使电子控制单元能够在不同的总线网络之间通信，使用了网关（参见 GatewayECU）。

在我们的示例中，NavigationECU 通过蓝牙和蜂窝网络提供与外部世界的连接。由于与互联网的连接，在 TARA 阶段识别出的一个潜在威胁是攻击者向 CAN 总线网络注入恶意消息（参见 TamperingThreat）。如果攻击者设法将被操纵的 CAN 消息传播到前照灯系统，攻击者可能能够在夜间关闭前照灯。这导致了 CrashHazard（碰撞危害），即前照灯意外关闭可能导致碰撞。为了应对潜在的威胁和危害，为系统定义了功能安全与网络安全目标。例如，为了防止意外关闭车灯，相应的消息请求应受到保护（参见网络安全目标 LampSwitchIntegrity）。此外，为了防止碰撞，应防止前照灯意外关闭（参见安全目标 HeadlampFunctionality）。

图1：根据ISO 21434的HARA/TARA阶段结果（附录G示例）

设计原理仅隐含存在。为了消除某些威胁和危害，工程师对系统做出假设。例如，前照灯系统可以使用防篡改外壳进行物理保护，以防止未经授权的修改。对于所有剩余的危害和威胁，必须在系统中实施适当的对策。找到合适的对策并非易事，需要一种结构化的方法来评估潜在的缓解方法和策略。本质上，找到对策是功能安全与网络安全需求提取过程的一部分，在该过程中，功能安全与网络安全目标得到细化。这种缓解策略的一个例子可以是 “纵深防御” 方法，该方法涉及多个网络安全层以防止攻击的蔓延。

功能安全与网络安全需求通常由不同学科的独立团队提取，尽管存在需要考虑的依赖关系和权衡。这是一个问题，因为可能在开发生命周期的后期才发现相互冲突的目标和策略。此外，工程师的许多隐性知识参与到需求提取过程中，而这些知识往往没有被记录。然而，所选缓解策略背后的这种设计原理是后续网络安全档案所需要的，因此如果没有被记录，就需要进行重建。但是，即使过程中做出的战略决策被记录下来，它们的可重用性也往往有限，因为这取决于决策的存储形式（例如，如果记录为非结构化文本）。这导致在重建和重用确保系统功能安全与网络安全所需的设计决策方面需要付出大量努力。

为了有效地支持两个领域的工程师进行目标细化过程，我提出了第一个研究问题（RQ1）：如何存储目标细化过程中更高层次缓解策略背后的隐性设计原理，以便日后重用并将其用于创建网络安全档案？

高效找到合适的对策。为了实施预期的策略，需要找到具体的对策。对于某些类型的危害和威胁，可以考虑已建立的对策模式目录（参见 Mitre ATT&CK 网络安全模式目录）。如果我们考虑我们的运行示例，防止向 CAN 网络注入恶意消息的一个潜在对策是在 GatewayECU 上实施白名单，只允许可信消息在网络之间传输。选择这些对策时会考虑某些因素，例如在当前系统环境中的适用性以及对该措施的安全或网络安全影响的假设。还必须考虑功能安全与网络安全方面之间的潜在冲突。例如，所采用的白名单不得阻止任何与安全相关的数据。因此，真正的挑战实际上不是找到任何对策，而是找到满足某些要求的合适对策。提取合适对策过程中做出的设计决策是每个应用对策背后的设计原理的一部分。与所选缓解策略背后的设计原理类似，每个实际对策背后的原理也是创建网络安全档案所需要的。在网络安全档案中，需要有关所应用对策有效性的证据，以论证已实现所述目标。对于这种论证，每个措施背后的原理至关重要。然而，与更高层次的缓解策略一样，对策背后的设计原理通常也仅表现为隐性知识。

因此，为了有效地支持工程师选择对策，我提出了以下研究问题（RQ2）：如何存储具体对策背后的设计原理，并将其用于对策的高效选择以及网络安全档案的创建？

减少创建网络安全档案的工作量。在最终部署网络物理系统之前，工程师必须确保系统可以功能安全与网络安全地运行。这必须记录在网络安全档案中，该案例论证所选对策实现所述目标的有效性。如前所述，创建网络安全档案需要所应用的缓解策略和实际对策背后的设计原理。然而，设计原理和网络安全档案是不同的，尽管两者都旨在论证为什么所述的功能安全与网络安全目标已经得到满足。但它们从两个相反的角度处理这个方面：设计原理是在需求分析期间创建的，表达例如所选对策的意图，而网络安全档案侧重于论证和合规性评估，即它们基于已做出的决策。

如果在开发过程的后期创建网络安全档案，大多数决策已经确定，如果可以找到更好的解决方案，系统设计的更改也几乎不可能。另一方面，在开发的早期阶段做出的设计决策非常不稳定，容易发生变化（例如，由于变更请求）。因此，简单地在增量系统设计过程的同时开始创建网络安全档案会导致工作量增加和频繁的变更。如果手动创建网络安全档案，情况会更糟，因为必须不断调整它们。为了利用早期创建的网络安全档案，需要从系统设计时存在的设计原理中推导它们。

因此，我提出了第三个研究问题（RQ3）：如何（半）自动地从缓解策略和所应用对策背后的设计原理中推导网络安全档案？

3、背景和相关工作

在本节中，我将介绍解决第 2 节中提出的研究问题的现有工作。这项工作涉及设计原理捕获、对策模式和网络安全档案领域。我还将概述我希望在我的方法中解决的现有方法的缺点。

在系统设计阶段进行目标细化建模和捕获设计原理的研究有着悠久的传统。该领域一种流行的方法是面向目标的需求工程（GORE），其起源于 20 世纪 90 年代初。GORE 的一个著名建模方法是 van Lamsweerde 等人提出的 Keep All Objectives Satisfied（KAOS）方法。Darimont 和 van Lamsweerde 还基于 KAOS 定义了一个正式框架，以允许定义通用目标细化模式。虽然 GORE 和 KAOS 通常应用于需求提取领域，但它们最近通过应用于网络物理系统的功能安全与网络安全工程而受到关注。

结合设计原理捕获和网络安全档案（RQ1）。尽管最近对前置保障活动的研究感兴趣，但是关于将更高层次设计策略的显式建模设计原理与网络安全档案相结合的工作却很少。Ito 等人在他们的工作中提出了一种方法，将汽车 ISO 26262 安全标准定义的概念阶段创建的 KAOS 模型与目标结构表示法（GSN）中定义的网络安全档案模型相链接。GSN 是一种广泛使用的论证表示法，以基于模型的方式图形化地表示此类网络安全档案。它通常用于定义安全论证，但作为一种通用的论证表示法，它不仅限于安全方面，也可用于网络安全论证。此外，Ito 等人的方法仅限于安全领域，目标模型和安全档案仍然必须并行创建，因为该方法侧重于使用链接矩阵保持它们彼此同步。

Habli 等人从不同的角度解决研究挑战。他们提出了一种通过在需求工程阶段早期以 GSN 创建网络安全档案来扩展 GORE 与论证的方法。然而，在这种方法中，GSN 用于一般性地论证目标和需求的实现，而没有特别关注安全或网络安全。此外，GSN 默认缺乏显式建模目标之间冲突的可能性。这是因为 GSN 作为一种论证表示法，主要用于事后建模论证。正如作者所建议的，通过简单地限制节点的描述来在 GSN 模型中建模反目标，会使冲突更难识别。

结合对策模式和网络安全档案（RQ2）。Martin 等人在他们的工作中（扩展了 Preschern 等人的工作）提出了一种结合功能安全与网络安全模式工程的工作流。在这个工作流中，功能安全与网络安全模式以及它们的原理、潜在冲突和相应的 GSN 网络安全档案片段被一起使用和存储。该方法通过工具支持实现，该工具支持提供网络安全档案片段的自动组合和实例化。尽管这种方法匹配设计模式和相应的网络安全档案片段，但选择模式的过程仍然主要是手动的。因此，除了仅根据模式描述手动选择模式之外，工程师在选择合适对策的决策过程中没有得到指导。此外，将网络安全档案片段与单个模式匹配导致论证在很大程度上局限于所选的相应模式。

Šljivo 等人提出了一种基于契约的模式实例化框架，其中架构设计模式（例如，防火墙）与静态网络安全档案论证模式相结合。通过基于所选设计模式实例化此论证模式，所提供的工具支持能够生成 GSN 中的网络安全档案。然而，由于设计模式应用于系统模型中的特定组件，他们的方法仅限于具体的对策模式。因此，它缺乏对不能应用于单个组件的更高层次设计策略的支持。

Meng 等人提出了一种相关方法，他们提出了一种基于公开可用的攻击模式自动生成网络安全档案片段的工具支持方法。然而，尽管论证再次局限于单个对策，但他们的方法也仅关注一组预定义的网络安全模式。

Dantas 等人提出了一种自动检查安全或网络安全模式在架构系统模型中适用性的方法。该方法基于线性时序逻辑，根据所应用的模式提供自动化的功能安全与网络安全推理。虽然这允许在架构模型中自动化应用具体的功能安全与网络安全模式，但它缺乏关于这些模式如何以及为何满足给定的功能安全与网络安全目标的详细原理。与 Martin 等人的方法一样，他们的方法更多地关注具体模式及其设计原理，而较少关注更广泛的缓解策略。

自动推导网络安全档案（RQ3）。有几种方法可以从系统模型中找到的对策中推导出基于模型的网络安全档案。然而，这些方法侧重于基于实际应用的措施，即局部受限的系统信息，在 GSN 中推导网络安全档案。因此，它们没有考虑更高层次的缓解策略。

总之，有一些方法涉及设计原理、对策和网络安全档案之间的关系，但它们只关注个别方面。然而，据我所知，没有一种方法像我打算在我的工作中做的那样，综合考虑所有子方面。

4、解决方案思路

为了解决第 2 节中提出的研究问题，我提出了一种从开发早期阶段做出的设计决策中自动推导基于模型的网络安全档案的方法。为此，我的方法旨在支持系统设计阶段从更高层次的功能安全与网络安全目标到具体对策的目标细化过程。特别是，目标是使找到适当对策的过程更高效，并跟踪和重用在选择这些对策时做出的决策以推导网络安全档案。为了实现这一点，我希望利用模式来存储重复出现的对策，因为关于对策背后设计原理的重要信息，例如它们的适用性、合理性或与其他措施可能存在的冲突等，都可以嵌入到模式描述中。

图 2 展示了所提出的解决方案如何整合到更广泛的系统设计流程中。现有的流程步骤用灰色标注，而新提出的流程步骤用蓝色标注。流程步骤左侧的齿轮图标表示该步骤可通过自动化方式提供支持。图右侧显示了我的工作的拟议贡献（C1 至 C3），橙色星形图标指示了它们对流程的影响。第一步（步骤 1）是定义系统模型，即项目定义，在此基础上确定危害、威胁以及功能安全与网络安全目标（参见 ISO 21434）。这些目标在系统的概念阶段进行细化，在此阶段找到适当的功能安全与网络安全要求（即对策）。在目标细化过程中，制定缓解策略（步骤 2）。

图 2：拟议解决方案的流程整合

为了允许日后重用缓解和目标细化策略并简化网络安全档案的创建（参见 RQ1），我提出了第一个贡献（C1）：定义一个复杂的对策模式目录。在这个模式目录中，反复出现的功能安全与网络安全对策应作为对策模式存储。利用这个目录，工程师应能在多个层级上对所含模式进行分层结构化。每个层级对应不同粒度的不同缓解策略和目标细化技术。这使得不同的模式能够通过更广泛的缓解策略相互关联，具体取决于该对策模式所服务的安全或网络安全目标。为了在模式目录中捕捉这些缓解策略背后的设计原理，每个存储的策略还应关联一个相应的论证片段。这些论证片段组合起来，就形成了一个能反映为实现所述功能安全与网络安全目标而采取的选定缓解方法的网络安全档案。

在制定缓解策略后，需要找到能实施这些策略的合适对策（图 2 中的步骤 3）。为了有效地支持工程师选择此类对策（参见 RQ2），对策模式目录（参见贡献 C1）中的模式需要提供关于其预期用途和适用性的额外元信息。因此，作为我的第二个贡献（C2），我提议将模式的明确建模设计原理与模式本身一同存储。设计原理通过提供关于模式的环境假设、合理性、在系统模型中的适用性以及与其他模式的潜在冲突等有用信息，对模式描述进行补充。通过明确建模模式的设计原理，我的目标是捕捉那些通常仅以隐性形式存在的知识。由于这些信息也是创建网络安全档案所必需的，因此与缓解策略相关联的片段（参见贡献 C1）类似，论证片段也应与模式的设计原理一同存储。

图 3 通过示例展示了第 2 节中提到的白名单对策如何补充了额外的设计原理和保障信息。白名单对策在 GatewayECU 内部实施。为了重用该对策，可以将其定义为一个模式并存储在拟议的模式目录中，以备日后参考。在定义该模式时，其设计原理和目标结构表示法（GSN）中的网络安全档案片段（绿色）会附加到具体的对策实现中。然后，该模式可以存储在模式目录中，该目录还包含用于更高层级缓解策略的 GSN 网络安全档案片段（紫色）。采用基于模型的方法来表示和推导网络安全档案，有助于工程师重用和链接现有的模型和设计原理工件（例如，来自模式目录和模式描述）。系统模型工件与网络安全档案元素之间的链接（例如，通过跟踪链接）更是有利的，因为这样可以使关系更加清晰，并且更容易追踪。

图 3：为白名单对策模式补充额外的设计原理和保障信息

最后，来自模式目录的模式元信息以及所应用的模式本身都可以作为推导网络安全档案的基础。因此，作为我的第三个贡献（C3），我提出一种（半）自动推导网络安全档案的方法，以减少其创建工作量（参见 RQ3）。为了创建系统的完整网络安全档案，可以重用预定义的网络安全档案片段（图 2 中的步骤 4）。这些片段对应于更高层级缓解策略（参见贡献 C1）和具体模式（参见贡献 C2）背后的设计原理。因此，重建先前设计决策的繁琐手动工作得以减少。通过组合这些片段（图 2 中的步骤 5），可以在系统设计期间（此时关于对策的决策至关重要）部分自动推导网络安全档案。

除了对所提出方法进行正式描述外，我还期望开发上述方法的原型概念验证软件实现。该原型预计将提出的现有功能安全与网络安全分析工具方法构建。因此，它是在 Eclipse 平台上运行的工具原型的扩展。通过补充现有的分析流程，我还能够在推导的网络安全档案中链接所选对策的效果（例如，分析结果）。

5、评估

为了评估我的方法，我计划根据 Kitchenham 等人的指导方针进行案例研究。该案例研究将与汽车和 / 或工业领域的行业合作伙伴一起进行。我在德国弗劳恩霍夫研究机构的工作使我能够在研究和行业项目中直接与行业合作伙伴验证所述的研究挑战。对于该案例研究，将与合作伙伴合作开发一个真实世界的运行示例，作为讨论的共同基础。基于此示例，识别危害、威胁以及功能安全与网络安全目标。之后，为了证明我的方法确实解决了所述问题，我将评估使用我的方法在目标细化和对策选择过程中对工程师的支持程度。在此过程中，我特别关注功能安全与网络安全对策设计原理的表示、找到对策的效率以及在此过程中推导的最终网络安全档案的质量。

为了更好地评估所提出的方法，我计划将其实现为概念验证。实现过程将通过原型设计来驱动，以确保并与合作伙伴持续评估已识别的挑战是否得到解决。

6、结论

总之，为了使网络物理系统安全且网络安全，功能安全与网络安全团队需要协同工作，在尊重两个领域之间相互依赖关系的同时细化共同目标。著名的解决方案，即缓解策略和对策模式，可用于实现所述的功能安全与网络安全目标。为了论证所有目标确实都已实现，我提出一种方法，通过补充这些模式的额外设计原理和网络安全档案片段，来支持规定网络安全档案的创建。