工业自动化软件测试安全分析框架-优快云博客

保障工业自动化软件的测试过程安全

摘要

随着信息物理系统（CPS）的普及，自动化应用的测试已成为每个生产系统工程（PSE）项目的关键支柱。鉴于由日益增长的连通性等因素引发的针对信息物理系统（CPS）的新攻击向量，必须在整个生产系统工程过程（PSE process）中考虑安全性方面。在此背景下，软件测试是一项关键活动，因为缺乏充分的安全机制会使多种有价值资产（例如系统配置和生产细节）面临信息窃取和破坏的风险。因此，组织必须定期分析其工业自动化软件测试过程的安全性，以应对这些威胁。然而，由于所需的安全知识或安全相关支出的预算限制，这些工作可能注定失败。在本研究中，我们提出了一种框架，用于支持对组织工业自动化软件测试过程进行半自动化安全分析。该框架基于VDI/VDE 2182指南，并集成了一种本体方法，用于建模必要的背景知识，包括数据流、资产、实体、威胁和对策。该框架包含一个测试过程的默认模型，用户可对其进行调整，以适应目标检查准确反映了其软件测试环境。特别是，创建默认模型所考虑的测试过程基于在一家主要系统集成商处观察到的最佳实践，并与ISO/IEC/IEEE 29119系列软件测试标准保持一致。此外，我们开发了一款工具，能够从组织的软件测试过程的形式化模型自动生成攻防树。我们展示了所提出的框架如何应用于通用的软件测试过程，以回答进行安全风险分析时的关键问题。示例性安全分析的结果提供了指导，应在工业领域提高意识，并支持有效且成本和时间高效的安全分析。最后，我们通过对合适的安全分析工具进行更全面的比较，评估了所提出的框架。

关键词 ：安全性分析，威胁建模，风险评估，安全性本体，软件测试，工业自动化软件，信息物理系统，工业控制系统， VDI/VDE 2182，ISO/IEC/IEEE 29119

1. 引言

在过去几十年中，工业自动化领域对软件的采用显著增加。根据机械工程行业协会（VDMA）发布的一份报告1, ，在自动化系统的工程项目中，软件开发活动的成本从2000年的约20%上升到2010年的超过40%，并且预计这一比例将继续增长（Gausemeier，2010；Vyatkin，2013）。这些发现表明，软件工程已经开始主导PSE项目，在支出方面已超过其他工程学科（即机械和电子）。诸如工业4.0（Kagermann等，2013）等战略举措进一步印证了这一趋势，因为信息物理系统被视为实现“智能工厂”的重要一步。信息物理系统紧密耦合“网络”（例如软件）与物理组件（例如传感器、执行器），并在两个维度上运行（即与其他cyber系统通信以及与物理环境交互）（Baheti 和 Gill，2011）。由于这些系统的行为由软件所控制，它们所执行的软件测试是确保信息物理系统按预期运行的关键活动。由于信息物理系统与现实世界交互，例如通过工业控制系统（ICSs）控制制造过程，因此必须保证这些系统的功能安全以及安全性。

事实上，安全性和安全性是相互依赖的属性（Knowles等，2015年），这意味着针对信息物理系统的成功网络攻击可能会损坏工厂设备、危及人类健康或对环境造成危害。例如，过去的信息物理系统或更具体地说 ICSs安全事件2导致污水流入马鲁奇郡的水道（Slay和Miller，2008年）、伊朗纳坦兹核设施离心机被毁（Langner，2013年；Falliere等，2011年）以及德国一家钢铁厂高炉遭受严重物理损害（Lee等，2014年）。为了应对信息物理系统的网络威胁，必须遵循“设计安全”原则，将安全性集成到产品系统工程过程的每个阶段。产品系统工程过程嵌入在多学科环境中，不同领域的工程师使用各种专用工具协同工作，生成异构的规划制品（ Biffl等，2017年）。通常情况下，未受保护的PSE数据（即工程制品）构成严重的安全威胁，因为攻击者可能窃取技术知识，甚至在制品（如信息物理系统的蓝图或代码）中引入漏洞，以便在系统生命周期后期加以利用（Kieseberg和Weippl，2018年；Weippl和Kieseberg，2017年）。

特别是自动化应用的软件测试，代表了每个工程项目中的一个关键阶段，因为被破坏的测试过程可能使攻击者得以窃取或篡改工程制品。除了软件盗版或知识产权（IP）盗窃之外，测试制品还可能被用来在工厂运行期间对信息物理系统发起高效且隐蔽的攻击。例如，如果这些制品增强了攻击者对被控物理过程的了解，则他或她可能能够以一种隐蔽的方式引入细微更改，从而悄悄降低工厂的运行效率（de S´a 等，2017）。震网病毒就是此类隐蔽攻击中最著名的例子之一，该攻击需要深入了解目标系统和受控的工业过程（Langner, 2013；Falliere 等, 2011）。

另一方面，测试结果的篡改可能使攻击者得以隐藏在测试过程或之前的PSE阶段中注入的恶意代码。植入的恶意软件可能在测试执行期间激活，或一直潜伏直至工厂运行期间被触发。由于所涉及资产的关键性以及工业自动化软件测试过程的独特特性，有必要对软件测试活动进行彻底的威胁与风险评估。此外，由于不同组织之间的软件测试方法通常存在差异，因此评估每个组织的具体情况至关重要。

在本文中，我们提出了一种更全面的框架，以促进对工业自动化软件测试过程中的安全方面进行分析。本文的总体目标是帮助组织保障其软件测试方法的安全性，并提高对针对产品系统工程过程（PSE process）的网络威胁的意识。

首先，我们开发了一个考虑工业领域特殊特性的软件测试通用过程模型，以定义我们的评估范围。为了定义该模型，我们与一家主要的奥地利系统集成商进行了访谈，并与一家软件质量咨询公司共同进行了审阅，最后将其与国际公认标准的软件测试标准保持一致。

其次，我们介绍了所开发的安全分析框架，该框架基于VDI/VDE 2182‐1 (2011)指南中规定的风险分析过程模型，以确保符合推荐的现有技术。该框架还集成了基于STRIDE的威胁建模方法（Shostack，2014），用于识别与相关资产相关的威胁。为了确保威胁模型适用于本文所述测试过程的变体，我们开发了一款工具，使用户能够自动生成针对其环境量身定制的攻防树（ADTrees）（Kordy 等，2011）。在风险的定量评估方面，我们利用了开源软件 ADTool（Kordy 等，2013a）。通过这种方式，用户能够回答诸如“哪些角色被授权访问哪些资产？”或“软件测试过程可能面临哪些威胁，以及如何缓解这些威胁？”等问题。

最后，我们通过将我们的框架与其他安全分析工具进行比较，对其进行了全面评估。

本文的贡献可以总结如下：我们研究了工业自动化测试的实践现状

通过以下方式分析软件：(i) 分析一家主要系统集成商的测试方法，以及 (ii) 将其与软件测试的国际标准（即 ISO/IEC/IEEE 29119 系列）保持一致。结果是得到一个通用且深入的软件测试过程版本，适用于工业自动化软件。

我们提出了一种基于VDI/VDE 2182‐1 (2011)指南的新型框架，用于在 PSE项目中对软件测试过程进行半自动化的安全性分析。此外，我们还展示了如何应用该框架来理解威胁并回答与软件测试过程相关的安全性问题。

最后，我们介绍了一个公开可用的框架原型实现以及底层安全性和过程知识的数据模型。其中包括ADTGenerator，这是一种允许用户为特定测试设置自动生成ADTree（Kordy 等，2011）的工具，以促进威胁建模和定量风险评估。

本文的其余部分结构如下：第2节讨论了本研究的方法论，并简要回顾了在本研究中所借鉴的现有安全概念。第3节介绍了一个适用于自动化应用的通用软件测试过程，该过程也定义了所提出框架的评估范围。第4 节详细阐述了安全分析框架及其在软件测试背景下的应用方式。特别是，本节首先描述了用于建模相关知识的本体，然后展示了所提出的框架如何支持安全分析的各个步骤。在展示本工作的主要贡献之后，第5节通过将所开发的框架与其他工具进行比较来对其进行评估，其中一些工具支持（半）自动化安全分析。接着，第6节讨论了信息物理系统威胁建模、自动化威胁建模以及信息安全本体领域的相关工作。最后，第7节对全文进行总结，并提出了未来研究方向的建议。

2. 方法论

这项工作基于 Hevner 等（2004）的 Design Science 方法。Design Science 过程如图1所示，一方面受Environment的影响，另一方面受一个Knowledge Base的影响

示意图0

信息系统研究

分析

解决方案设计

评估

环境

人员

组织

技术

知识库

基础

方法论

提供基础和方法论。研究过程分为三个任务：分析、解决方案设计和评估，它们相互依托并相互促进。在分析阶段，通过现有技术和适用知识对研究问题进行探究。在解决方案设计阶段，提出一个解决方案，该方案可能包含理论、特定设计或其他制品。所提出的方案随后在评估阶段进行检验和论证。

为了构建自动化应用的通用软件测试过程，我们首先对一家大型奥地利本地系统集成商的不同角色进行了定性非结构化访谈，将得到的模型与现有软件测试标准进行对齐，然后与一家在工业自动化软件测试方面经验丰富的公司进行了讨论。具体而言，我们采访了四位实例，以深入分析他们对软件测试的经验和观点。所有男性受访者均在不同部门工作，并担任多种角色，即：（i）自动化工程部门的项目经理，（ii）PLC编程部门负责人，（iii）SCADA部门负责人，以及（iv）MES部门的软件质量负责人。

在进行访谈之前，我们根据从一个独立研究合作项目中获得的背景信息，准备了我们对组织测试过程的理解。我们使用业务流程模型和标记法（BPMN）（OMG，2011）对测试过程进行了图形化建模，因为这是一种用于业务流程建模的标准标记法。然而，我们仅将准备好的BPMN模型用作引导讨论的工具。由于采用了非结构化访谈，我们能够

关注未回答的问题和空白之处。此外，这种设置鼓励受访者进一步阐述软件测试问题和安全问题。

随后，我们与一家专注于软件质量的奥地利咨询公司共同审阅了我们的结果，以确保建模的软件测试过程是可靠的。此外，我们将测试自动化应用的实践现状与国际公认标准（即ISO/IEC/IEEE 29119系列）以及相关文献（Spillner 等，2011；Lewis，2008）进行了比对。通过这种方式，我们进一步完善了过程模型，为安全分析建立了共同基础。

在开发我们的安全分析框架时，我们分析并借鉴了以下简要描述的安全模型与标准。该分析步骤基于VDI/VDE 2182‐1 (2011)指南，该指南规定了一种统一的方法来提高自动化系统的安全性。VDI/VDE 2182‐1 (2011)指南从结构分析开始，以确定评估范围。随后执行以下八个步骤： (i) 识别资产，(ii) 分析威胁，(iii) 确定相关安全目标，(iv) 分析并评估风险，(v) 识别措施并评估有效性，(vi) 选择对策，(vii) 实现对策，以及 (viii) 执行过程审计。

此外，我们采用STRIDE（Shostack，2014），因为它提供了威胁的结构化模型，从而支持威胁分析步骤。STRIDE是一个首字母缩略词，表示一组安全威胁，即：（i）伪装，（ii）篡改，（iii）抵赖，（iv）信息泄露，（v）拒绝服务，以及（vi）权限提升（Shostack，2014）。使用STRIDE可能有助于发现威胁，特别是当应用其变体之一时，即按元素划分的STRIDE或按交互划分的STRIDE（Shostack，2014）。然而，在应用STRIDE之前，我们通过使用数据流图（DFD）来绘制目标检查范围内的数据流，该数据流图包含以下元素：（i）过程（即正在执行的代码），（ii）数据流（即元素之间交换的数据），（iii）数据存储（即存储数据的元素），（iv）外部实体（即人员）（Shostack，2014）。

此外，我们使用攻击防御树（ADTrees）（Kordy 等，2011年）以树形结构图形化地表示枚举出的威胁。攻击防御树通过引入防御节点扩展了攻击树（ Schneier，1999；Mauw 和 Oostdijk，2006），使用户能够从攻击者和防御者的视角分析系统的安全性（Kordy 等，2011年）。适当的工具支持是可用的

可用，即 ADTool（Kordy 等，2013a），这可能会促进更广泛的应用。

考虑到不同组织之间的测试方法存在差异，数据流的建模必须是动态的，以便能够准确识别威胁。因此，我们提供了一个本体，允许用户对其测试过程中的数据流进行DFD建模。此外，我们创建了一个用于建模通用 ADTree的本体，该本体基于（Shostack，2014）中定义的威胁树。为了简化威胁建模的过程，我们开发了一款名为ADTGenerator的工具，该工具可自动提取DFD并为选定的威胁场景生成ADTree。ADTree生成器使用Scala开发，其源代码以及两个本体均已公开发布在GitHub3上。

此外，我们展示了如何通过所开发的框架来回答能力问题（参见表2）。

由于篇幅限制，我们无法在此展示用于回答这些问题的SPARQL查询及其相应的查询结果。但是，我们通过上述GitHub仓库3提供了这些 SPARQL查询以及知识库，用户可利用该知识库执行这些查询。

最后，我们通过将该框架与其他最先进的威胁建模和安全分析工具进行全面比较来评估其性能。

3. 自动化应用的通用软件测试过程

一般来说，测试工业自动化软件的过程与测试传统IT软件的过程非常相似。其中一个主要区别在于，工业自动化软件运行在集成了物理组件的信息物理系统（CPSs）上，以与现实世界进行交互（Baheti 和 Gill， 2011）（例如，作为装配线一部分的机械臂）。因此，被测系统（SuT）由可能在生产系统的仿真环境或测试台中运行的软件组成。另一个后果是，由于特定测试难以自动化以及缺乏有效的测试措施，自动化领域的测试目前仍普遍以手动方式进行（Dubey，2011）。

据我们所知，目前尚无专门定义PSE中测试过程的工业界标准，因此我们基于工业界

计划与控制

分析与设计

评估与报告

实施与执行

完成图2：高层级测试过程（Graham 等，2008；Spillner 等，2011）

自动化系统，如图2所示，基于Graham 等，2008和Spillner 等，2011提出的高层软件测试过程。在这两部著作中，测试过程由五个任务组成：(i) 计划与控制，(ii) 分析与设计，(iii)实施与执行，(iv) 评估与报告，以及 (v) 完成，这些任务在软件系统的测试阶段中执行。计划与控制活动贯穿于其他各项活动之中，以便在必要时对测试过程进行调整。各任务的结果和产物将传递给过程中的下一个任务，例如作为逻辑测试用例和测试源代码。此外，为了使控制机制正常运作，任务的特定结果会反馈至先前的任务，作为进一步决策的基础，并用于改进特定测试过程和质量。

利用（Spillner 等，2011；Graham 等，2008）中的过程描述，我们开发了一个详细但易于理解的软件测试过程，该过程特别考虑了工业自动化软件的需求。与非自动化软件非常相似，工程解决方案的测试在不同级别上进行（Dubey，2011）——从单元和模块测试到现场测试。然而，生产系统调试阶段的现场验收测试级别（Dubey，2011）不在本文的讨论范围之内。图3展示了该软件测试过程。为进一步说明，我们将提供对过程步骤的描述，并介绍相关利益方角色。

图3 中五个 BPMN 泳道的第一个代表了活动

对应于图2所示高层过程中的计划与控制任务的测试管理，我们是在访谈了咨询公司的测试专家并将流程与ISO/IEC/IEEE 29119系列标准对齐后，为测试管理泳道选择了这一不同名称，以更好地符合该标准。其他所有名称均遵循图示高层过程中的惯例。此过程中的管理活动定义了测试策略（例如自动化行为驱动测试），创建考虑质量期望并定义测试需求的测试计划，以及监控和控制测试过程。第二个泳道包含测试分析与设计活动，其中工程师分析测试依据，派生测试条件，定义逻辑测试用例和测试环境，并描述测试程序。与软件测试过程不同，工业自动化软件的测试过程必须在环境描述中描述其仿真或物理系统所构成的环境。测试实现与执行泳道中包含了使用正确的测试数据实现测试用例、准备环境并执行测试以及收集测试结果等活动。我们的访谈和调查表明，在自动化软件工程中，被测系统在测试执行前需进行适当准备，测试执行后需进行拆卸。这种必要性例如出于安全性考虑，因为物理系统与员工之间可能存在交互，或者组件可能造成物理损坏。此外，物理系统及其组件无法像软件系统那样轻松地重置到初始状态，通常需要工程师执行手动操作。因此，我们引入了与测试环境准备相分离的准备被测系统和拆卸被测系统活动，后者涵盖测试系统、其工具以及自动化软件本身的准备。第四个泳道是测试报告泳道，包括创建测试报告并评估测试结果，或在发生测试事件时记录该事件。

BPMN流程的最后一个泳道包含测试完成的任务，包括清理环境、归档测试以及创建包含本次测试运行经验教训的完成报告。

在采访了我们的合作伙伴后，我们汇总了调查结果，并将测试过程与 ISO/IEC/IEEE 29119标准进行了比较，补充了缺失的部分。为了清晰起见，我们将 Test Management Pro-cess和Dynamic Test Process及其相关子过程整合为一个集成的软件测试过程，但省略了Organizational Test-

S o f t w a r e T e s t i n g P r o c e s s f o r A u t o m a t i o n A p p l i c a t i o n s T e s t M a n a g e m e n t T e s t A n a y s s & D e s g n T e s t I m p e m e n t a t o n & E x e c u t o n T e s t C o m p e t o n T e s t R e p o r t n g 启动测试过程创建测试计划计划和分配资源确定 Test 目标确定 Test 标准优先排序测试需求质量期望定义测试环境需求创建测试数据开发测试用例逻辑测试用例创建测试过程描述 Test 过程描述创建测试报告评估测试结果准备被测系统执行 Test 流程事件发生？文档测试事件收集测试结果 Test 结果测试事件报告模拟物理组件混凝土测试用例测试数据测试报告 SuT 拆解 SuT 测试计划环境需求经验教训已学习改进测试问题 Test 归档归档的工件环境描述改进识别于先前周期设计 Test 策略测试计划组织的政策 Yes No 监控和控制测试过程调整测试计划监控测试过程测试完成？控制测试过程报告进度测试状态报告清理 Test 环境分析测试依据派生测试条件测试条件准备 Test 环境 Test 环境描述需求、测试计划、… 实现测试用例混凝土测试用例派生测试套件测试套件创建测试完成报告测试计划测试结果测试完成报告测试状态报告测试事件报告测试策略构建规格说明书构建 Yes No 否，变更需要测试计划图3：基于（Spillner 等，2011；Lewis，2008；ISO/IEC/IEEE 29119‐2，2013）的工业自动化软件测试过程

ing Process，该过程描述了高于项目级别的过程。此外，我们省略了该标准中的少数任务，因为这些任务在合并形式下似乎会降低可理解性，例如就测试计划达成一致。然而，我们的软件测试过程是一个通用蓝图，仍需根据使用该过程的各个自动化工程公司的具体需求进行实现。这也意味着所展示的测试过程可能不会在监督或控制级别被严格遵循。

我们测试过程中的每个任务都与特定角色相关联。表1定义了这些角色及其职责。在实践中，尽管明确区分角色更为理想（Winkler 等，2018），但通常由一个人承担多个角色。

缩写	Role 职责
PM	项目经理项目控制，测试控制
TM	测试经理测试计划，测试设计，测试管理，测试控制
RM	发布经理软件打包，软件发布
D	开发人员被测系统代码实现
T	测试员测试数据创建，测试用例实现
TAE	Test自动化工程师被测系统准备与清理，环境准备与清理测试执行
DE	领域专家测试数据提供，业务测试用例派生，领域知识边缘规格说明书，需求规格说明

表1：软件测试团队中的角色与职责（Winkler 等，2018；ISO/IEC/IEEE 29119‐2，2013）

根据所开发的测试过程，安全性分析将重点关注测试过程的组织层面和高层次技术视角。因此，作为测试过程一部分使用的具体工具不在本研究范围内，但可由用户或未来的研究进行扩展。然而，我们确实考虑了在威胁建模过程中用于测试活动的工具类型（例如，测试管理工具）。

4. 安全分析框架

本节讨论了用于软件测试过程半自动安全性分析的框架。首先，通过描述该框架的结构以及其如何支持组织的

努力保护其软件测试过程。其次，我们在第4.1节中概述了如何通过使用本体来表示关于（i）软件测试过程以及（ii）潜在威胁及其相应对策的知识。

第三，第4.2节展示了安全分析的步骤，并强调了该框架的优点。

如第2节所述，所提出的框架基于VDI/VDE 2182‐1 (2011)指南，旨在对程序化方法的多个步骤进行半自动化。从图4可以看出，程序化方法本质上是循环的，该框架重点关注前六个步骤，包括结构分析（其余两个用 x标记的步骤不在范围内，因为它们无法被自动化）。

识别资产
识别资产
识别资产
识别措施 & 评估有效性
分析威胁
确定相关安全目标
分析与评估风险
选择对策
实现对策
执行过程审计 x	执行过程审计 x
过程文档
开始（结构分析） x

图4：程序化方法，描述并改编自（VDI/VDE 2182‐1, 2011年）；标有x的步骤不在所提出框架的范围内

在执行该过程之前，必须进行结构分析，以确定评估范围。该分析的结果是生成检查目标的规格说明书，即对需要评估的对象（例如设备）进行详细描述。此外，安全性分析应进行的具体时间由某些间隔（例如定期审计）或事件（例如发现漏洞、安全事件）决定。

检查目标的重大变更。为确保过程的可追溯性，VDI/VDE 2182‐1 (2011) 指南建议创建一个在程序化方法过程中逐步开发的过程文档。（ VDI/VDE 2182‐1, 2011）表2总结了本研究的贡献，或者更准确地说，展示了本文提出的框架如何支持VDI/VDE 2182‐1 (2011)指南中所述过程方法的各个阶段（参见图4）。由于我们采用了本体方法，下一节中描述的知识模型为该框架奠定了基础。正因如此，该框架也有助于创建过程文档。

4.1. 知识表示

由于各组织的软件测试过程步骤、所用工具以及现有的防御机制各不相同，检查目标在一定程度上是动态的。为了确保安全性分析的范围既明确定义又具备足够的灵活性以分析各种软件测试过程，我们开发了一种工具支持的半自动威胁建模方法。

该方法的基础包括两个本体，一方面用于建模软件测试过程中的数据流，另一方面用于建模攻击防御树。这两个本体均使用开源本体编辑器 Prot´eg´e（Noy 等，2001）以网络本体语言（OWL）开发而成。尽管我们预先为这两个本体提供了一组实例作为起点，但我们期望用户根据其测试过程调整建模的DFD，并在必要时扩展预定义ADTrees。

数据流图本体由数据流图的典型元素构成，即Process、 DataFlow、 DataStore和 ExternalEntity类。此外，使用一个 Asset类及其子类 Hardware、 Software和 Document，将这些类型的实例与建模的DFD元素关联起来。资产可通过对象属性 usedBy链接到数据流图元素。此外，双向数据流通过两次添加 flows对象属性（每个端点各一次）来表示，而单向数据流可采用对象属性 flowsFrom和 flowsTo。

另一方面，攻击防御树本体（ADTrees）包含以下类： AttackNode、 DefenseNode、 Goal（即攻击防御树的根节点）、TargetElement（即数据流图元素类型）、 Threat（根据STRIDE）以及 Connector ，其下包含两个子类 AndConnector和 OrConnector

用于分别表示节点的合取和析取精化。目标、攻防节点与连接器通过对象属性 connectedTo相互连接。此外，目标通过对象属性 hasTarget指向 DFD目标元素，通过对象属性 hasType指向STRIDE威胁。这两个对象属性也可被 Connector的子类用于引用受特定威胁影响的资产。为了识别最经济有效的对策，攻防节点可以具有数据属性 successProbability和 cost。

为了向用户提供一组通用的威胁及其相应的对策，我们使用ADT本体对（Shostack，2014）中定义的威胁树进行了建模。尽管Shostack（ 2014年）提供了面向开发人员和IT运维人员的缓解措施，但我们仅关注后者，因为我们假设所提出的威胁建模方法的用户无法修改软件测试过程中使用的软件（例如，测试管理工具）。由于已建模的DFD和威胁树，可以通过执行SPARQL查询自动推导出某些威胁场景（例如，获取测试数据），原因在于可以联合查询与资产（例如，测试数据）相关联的数据流图元素以及已建模的威胁。然而，为了覆盖多阶段攻击（例如，对测试代码的隐蔽破坏），我们建模了额外的ADTrees，以表示与自动化应用的软件测试过程相关的特定威胁场景。这些预定义的ADTrees可以引用其他威胁树作为子树，但必须保持树的无环性。

4.2. 安全分析步骤

本小节首先概述了评估范围，然后展示了该框架如何以半自动方式对软件测试过程进行安全性分析，以回答表2中列出的问题。

4.2.1. 结构分析

在本研究中，检查目标是自动化应用的软件测试过程。因此，CPS测试的其他活动（如硬件测试）不在本研究范围内。更具体地说，我们重点关注第3节所述测试过程的安全性分析。此外，安全性分析涵盖两个测试级别，即单元测试和集成测试。其他级别的测试，例如工厂验收测试（ FAT），均不在此范围之内。

未涵盖，因为它们通常过于多样化而无法包含在通用模型中，但可以在未来工作中予以考虑。

为了进一步分解信息的传输方式，我们使用数据流图（DFD）对上一节中描述的软件测试过程的数据流进行了建模（参见图5）。我们为DFD 中的每个元素分配了一个标识符，以便在安全分析过程中引用这些元素；这种处理引用的方式借鉴了Khan 等人 (2017) 所采用的基于STRIDE的威胁分析方法。图5所示的DFD还使用了数据流图本体进行建模，以向用户提供结构分析的起点。通过这种方式，用户可以调整建模的DFD，使其检查目标准确反映其实际环境。例如，如果没有使用测试数据生成器，或部署了两个源代码仓库而非一个，可以通过添加或删除相应的过程元素来轻松优化建模的DFD。此外，通过扩展数据流图本体，还可以扩展检查目标（例如，为了DevOps的目的而纳入IT运维组件）。

如图5所示，软件测试活动中使用的工具被建模为过程，而数据存储库则表示为数据存储。此外，我们使用外部实体来建模软件测试团队中的角色，并使用数据流来表示工具、存储库和角色之间的通信。通过建模的 DFD，我们可以执行SPARQL查询，以回答与检查目标相关的各种问题，例如：哪些过程、外部实体或数据存储向测试管理工具传输数据？

4.2.2. 资产识别

程序化方法的第一步是在评估范围内识别资产。VDI/VDE 2182‐1 (2011)指南指出，必须考虑自动化设备的组件、通信基础设施（例如数据流）以及法律权益（即可能由安全事件引发的主张）。（VDI/VDE 2182‐1, 2011）对于软件测试过程中涉及的资产识别，我们使用了BPMN图（参见图 3）和DFD（参见图5）。特别是，BPMN图中所示的数据输入和输出，除了模拟、物理组件和构建之外，均被归类为文档。此外，DFD中的过程和数据存储元素被分类为硬件和软件资产。

由于所有这些信息都在数据流图本体中进行了建模，因此我们可以推导出

测试管理 Tool

测试数据生成器

构建（自动化） Tool

测试执行工具

软件开发工具

源代码仓库构建仓库测试管理仓库

项目经理

测试经理发布经理

测试自动化工程师

领域专家

E-5

E-6

S-1 S-2 S-3

P-1 P-3

P-5 E-1

E-2

开发人员

P-4

P-2

E-3 E-4

E-7

F-1

F-5 F-8

F-7

F-9 F-1

F-11

F-12 F-13

F-14

F-2

F-17 F-18

F-16

F-15

F-19

F-21 F-22


测试员	测试员	测试员	测试员
测试员	测试员	测试员	测试员
测试员	测试员	测试员	测试员

	F-3	F-3
	F-3	F-3		F-4	F-4
				F-4	F-4
				F-4	F-4

F-6	F-6

F-2	F-2

图5：软件测试过程的数据流图

通过执行SPARQL查询，即可获取有关风险资产的宝贵技术知识。一方面，这些建模的链接可用于推导出特定资产的攻击目标；另一方面，我们可以确定哪个角色（即外部实体）可以访问哪些资产。此外，通过使用语义推理器，还可以获得关于潜在攻击策略的额外知识（例如，由涉及的资产数量所定义的目标吸引力）。

除了为每个资产分配数据流图标识符（DFD‐IDs）和授权角色外，我们还分析了资产遭到泄露后可能产生的法律影响。因此，我们审查了在因资产受损而引发诉讼时，组织可能面临的法律权益状况。具体而言，所考察的法律权益包括：（i）专有技术保护，（ii）产品责任，以及（iii）安全性。例如，文档机密性的泄露可能构成对组织知识产权的侵犯，而完整性遭到破坏则可能因安全问题或产品缺陷导致针对组织的索赔，进而引发机械故障等问题。

已识别资产、数据流图标识符、需考虑的法律方面以及授权使用这些资产的角色，如表3所示。

保障工业自动化软件的测试过程安全

4.2. 安全分析步骤

4.2.2. 资产识别

已识别资产、数据流图标识符、需考虑的法律方面以及授权使用这些资产的角色，如表3所示。

#	资产	数据流图标识符	法律地位	授权角色
			K L S	PM TM RM D T TAE DE
Hardware
1	测试管理服务器	P-1
2	Test管理存储库服务器	S-1
3	源代码仓库服务器	S-2
4	构建 (自动化) 服务器	P-3
5	构建仓库服务器	S-3
6	物理组件	-
Software
7	测试管理工具	P-1
8	Test管理仓库	S-1
9	测试数据生成器	P-4
10	软件开发工具	P-2
11	源代码	P‐2、S‐2、F‐11、F‐1 2, F‐13, F‐14
12	源代码仓库	S-2
13	构建（自动化）工具	P-3
14	构建	P‐3、F‐17、S‐3、F‐1 8
15	构建仓库	S-3
16	模拟	F‐4，F‐21，P‐5
17	测试执行工具	P-5
Document
18	组织政策	F‐1、F‐2、F‐5、P‐ 1, S-1
19	测试策略	F‐1，F‐2，F‐5、P‐ 1, S-1
20	测试计划	F‐1，F‐2，F‐5、P‐ 1, S-1
21	测试状态报告	F‐2，F‐3，F‐4，F‐ 5，P‐1，S‐1
22	测试条件	F‐2、F‐3、F‐5、P‐ 1, S-1
23	逻辑测试用例	F‐3，F‐4，F‐5 P-1, S-1
24	Test环境 de- 描述	F‐3、F‐4、F‐5、P‐ 1,S‐1
25	测试程序描述- tion	F‐3、F‐5、P‐1、S‐1
26	具体的测试用例	F‐3、F‐4、F‐5、P‐ 1, S-1
27	测试数据	F‐6、F‐7、F‐8、P‐ 4,S‐1
28	测试套件	F‐3、F‐5、P‐1、S‐1
29	构建规格说明书	F‐15， F‐17， P-3, S-3
30	测试事件报告	F‐2、F‐3、F‐5、P‐ 1, S-1
31	测试结果	F‐2、F‐5、F‐19、F‐ 20，F‐21，F‐22，P‐ 5,P‐1,S‐1
32	测试报告	F‐2、F‐3、F‐5、P‐ 1, S -1
33	测试问题	F-1, F-2, F-3, F- 5,P‐1,S‐1
34	改进报告	F‐1、F‐2、F‐3、F 5,P‐1,S‐1
35	归档的工件	F‐2、F‐5、F‐17、P‐ 1，P‐3，S‐1，S‐3
36	测试完成报告	F‐1、F‐2、F‐3、F 5，P‐1，S‐1

表3：已识别资产及数据流图中相关元素的对应ID（参见图5），包括对法律权益的考虑（K =专有技术保护，L =产品责任，S =安全性）以及有权访问这些资产的软件测试团队角色（角色缩写参见表1）

4.2.3. 威胁分析

根据VDI/VDE 2182‐1 (2011)指南，威胁分析分为两个阶段，即威胁识别和威胁矩阵的创建。在开展威胁建模活动之前，我们将首先讨论潜在的威胁行为者、攻击者的目标以及攻击目标。

攻击者画像 。正如工业领域过去的事件所示，常见的威胁行为者是拥有国家资源的组织以及犯罪组织或个人（Miller和Rowe，2012；Langner， 2013年；McLaughlin等，2016）。由于这些攻击通常是针对性地发起的，因此应特别关注高级持续性威胁（APT），即来自攻击者所实施的多阶段攻击策略，以特定组织为目标，旨在长期潜伏不被发现的威胁。

一般来说，攻击工业自动化软件测试过程的对手目标可分为两类：信息窃取和（隐蔽）破坏。旨在窃取测试制品的攻击背后的动机可能包括： (i) 经济利益（例如，模仿竞争对手的被测系统），(ii) 声誉损害（例如，涉及工件丢失的数据泄露），以及 (iii) 侦察（例如，获取有关被测系统的信息，以用于杀伤链中的后续步骤）。另一方面，针对测试过程的破坏性攻击背后的动机可能如下：(i) 设备损坏（例如，系统加速劣化），(ii) 环境与人身安全风险（例如，对真实硬件进行被破坏的测试执行，从而危害人类健康），(iii) 制造产品操纵（例如，产品质量下降），(iv) 拒绝服务（例如，阻碍PSE流程）。最后，获取信誉可能是网络攻击背后的另一动机。

表4总结了在测试自动化应用背景下考虑的威胁行为者，包括其预估能力和网络攻击背后的潜在动机。

请注意，攻击者还可能利用工业自动化软件中存在漏洞的测试过程，攻击正在运行工厂的集成商客户。因此，如果缺乏适当的安全措施来保护测试过程，可能会导致严重后果，不仅对负责测试过程的集成商造成影响，也对依赖自动化软件来控制物理过程的操作人员造成严重影响。

威胁行为者	能力
基本用户	Low
内部人员	中等
竞争对手	中等
黑客活动分子	中等
恐怖分子	中等
网络犯罪分子	中等
有组织的网络‐ 犯罪集团	High
国家支持的	High

表4：与软件测试过程相关的攻击者画像

威胁建模 。如第2节所述，我们采用基于STRIDE的威胁建模方法。具体而言，我们使用按元素划分的STRIDE（Shostack，2014）来促进威胁的自动化识别。本质上，这种STRIDE变体预先确定了哪些类型的威胁与哪些数据流图元素相关（参见表5）。基于此，可以定义威胁树（ Shostack，2014），它们提供通用的攻击向量，以简化威胁建模过程。

数据流图元素	S	T	R	I	D	E
外部实体
过程
数据流
数据存储

图例：适用，部分适用

表5：根据按元素划分的STRIDE（Shostack，2014年）对数据流图元素的威胁适用性

由于我们使用ADT本体对威胁树进行建模，因此可以推导出具体的威胁场景，通过攻击防御树展示攻击者目标可能如何实现。此外，我们将这些威胁场景按攻击者目标（即信息窃取或（隐蔽）破坏）进行分组，并分析了潜在的后果。表6显示了此次威胁建模活动的结果。由于这些威胁场景描述了所涉及的行动

以恶意意图执行以实现特定目标，攻击者即构成主张方。

为了在表6中形式化表示攻击防御树，我们采用了攻防术语（ADTerms）（Kordy 等，2011）。简而言之，ADTerms 是 TΣ 的元素，其中 TΣ= T p Σ ∪ T o Σ（主张方和对手的 ADTerms 集合的并集），且 Σ=(S, F)，即一个 AD‐签名，表示由类型集合 S={p, o} 和函数符号集合 F 组成的一对，该函数符号集合包含析取（∨）和合取（∧）细化操作符，以及针对主张方（ p）和对手（o）的对抗动作（c）（Kordy 等，2011）。此外，用于表示攻击防御树 T 的 ADTerm 记为 ι(T)（Kordy 等，2011）。

因此，我们用 ι(T† i,j)表示用于描述通用ADTree的ADTerm，该通用 ADTree基于(Shostack, 2014)中定义的威胁树，并涉及图5中所示的一个或多个DFD元素，其中 i表示DFD标识符， j表示STRIDE中的威胁。为简洁起见，我们将特定威胁类型的通用ADTree按资产进行分组，即 ι(T ∗ a,j) =∨p(ι(T† i1,j) . . . , ι(T† ik,j))，其中 a表示资产的编号（参见表3）， i 表示DFD标识符， j表示威胁类型（若适用于该DFD元素），以及 k ≥ 1。例如， ι(T ∗ 27,T) = ∨p(ι(T† F‐6,T) ι(T† F‐7,T) ι(T† F‐8,T),ι(T† P‐4,T) ι(T† S‐1,T))是由篡改测试数据（资产编号27）的威胁树组成的ADTree。此外，用于表示威胁场景（参见表6）的ADTree的ADTerm表示为 ι(T‡ n)，其中 n 是相应威胁场景的编号。

#	Goal	ADTerm	Potential Consequences
1	Obtain Source Code	∨p[ι(T† F-11,I), ι(T † F-12,I), ι(T† F-13,I), ι(T † F-14,I), ι(T† P-2,I), ι(T † S-2,I) ]	The disclosure of algorithms, design concepts, and configurations would allow adversaries to gain profound knowledge about the automation application to be developed. This knowledge can be used to replicate the application, develop exploits that take advantage of newly discovered weaknesses, and may also provide insights into the industrial processes under control, especially if the application is custom-tailored. Furthermore, an understanding about the code coverage may incite attackers to manipulate only those parts of the code that are not executed during test runs, so that the sabotage remains undetected.
2	Obtain Build	∨p[ι(T† F-17,I), ι(T † F-18,I), ι(T† P-3,I), ι(T † S-3,I) ]	Capturing the binary would allow adversaries to perform reverse engineering activities, such as static analysis, which may result in similar consequences as the theft of source code has.
3	Obtain Build Specification	∨p [ι(T† F-15,I), ι(T † F-17,I), ι(T† F-19,I), ι(T † P-3,I), ι(T† S-3,I) ]	Various malicious actions can be undertaken based on knowledge gained about the build process, as a result of obtaining the build settings. In particular, the configured build steps, parameters, build schedule, versioning information, build failure conditions, clean-up rules, dependencies, and reporting information are valuable targets to be used for reconnaissance purposes. Furthermore, captured version control settings and SSH keys may allow adversaries to gain additional information by pivoting to other systems. Settings related to code signing may be abused by attackers to disguise malware as benign, legitimate applications, as was the case with Stuxnet(Falliere et al., 2011; Langner, 2013).
4	Obtain Simula-tions	∨p [ι(T† F-4,I), ι(T † F-21,I), ι(T† P-5,I) ]	Depending on the type of the obtained simulation, adversaries may acquire comprehensive knowledge about systems, indus-trial processes, and even the overall plant. This knowledge can either be used to recreate components and manufacturing processes or as an attack preparation step. To give two examples of the former, a 3D simulation of a robot provides details about its mechanical structure, whereas a plant simulation could reveal the material flow and the resources used as part of the manufacturing process. On the other hand, simulations may be exploited to learn the physical dynamics of systems, allowing opponents to launch covert attacks(cf.(de S´a et al., 2017)). Furthermore, simulations may reveal the features of physical components(e.g., payload or rotation capabilities of a robotic arm), which represent valuable information for performing attacks that aim to cause physical damages or injure individuals. In this context, adversaries can also benefit from simulating failures caused by attacks, ensuring that physical damage is induced in a controlled manner.
5	Obtain Test Plan	∨p [ι(T† F-1,I ), ι(T† F-2,I ), ι(T† F-5,I ), ι(T† P-1,I ), ι(T† S-1,I ) ]	According to the ISO/IEC/IEEE 29119 standard(ISO/IEC/IEEE 29119-3, 2013), the test plan includes, inter alia, the features to be tested, a risk register, roles and responsibilities, and the overall testing approach. If this information were to fall into unfriendly hands, adversaries may be able to significantly increase the sophistication of planned attacks. For example, depending on the attacker’s objective, the test scope can be used to sabotage either specific test items for the purpose of causing harm during the test execution(e.g., destroying SuT) or manipulate only the ones that are excluded from testing in order to go unnoticed during PSE and wreak havoc during plant operation. Furthermore, the risk register may suggest additional targets that may be worth attacking, whereas staffing information could be exploited to attack particular users in order to gain a foothold in specific testing activities. Details about the overall testing approach(e.g., schedules, third-party tools used for testing, paths of stored documents, versioning information) could be a target of further reconnaissance activities.
6	Obtain Test Cases	∨p [ι(T † F-3,I ), ι(T † F-4,I ), ι(T † F-5,I ), ι(T † P-1,I ), ι(T † S-1,I ) ]	Attackers being equipped with knowledge about test cases may be able to understand the happy paths, but also how the SuT can be run into error conditions. In particular, this know-how is useful for exploit development.
7	Obtain Test En-vironment De-scription	∨p [ι(T † F-3,I ), ι(T † F-4,I ), ι(T † F-5,I ), ι(T † P-1,I ), ι(T † S-1,I ) ]	Since the test environment description comprises details related to the used test bed, including information about the hard-ware, software, and configurations, the disclosure thereof may allow adversaries to gain knowledge about the structure and inner workings of physical components. This knowledge, again, may be useful for creating product clones or reconnaissance.
8	Obtain Test Data	∨p [ι(T † F-6,I ), ι(T † F-7,I ), ι(T † F-8,I ), ι(T † P-4,I ), ι(T † S-1,I ) ]	Test data can be composed of highly sensitive, business-critical information. While data privacy may be an issue when it comes to using realistic, unmasked test data for typical IT software, inputs for test cases related to automation applications may reveal valuable know-how about the manufacturing processes and systems. To give a concrete example, the interviewed company partner uses real-world data collected from customers during plant operation for the purpose of testing customized MES applications. product to be manufactured. Since these data dumps contain, inter alia, details about past orders, production logs, as well as scheduling and sequencing information, the leakage thereof as a result of industrial espionage activities would obviously damage the company’s customers.
9	Obtain Test In-cident Report	∨p[ι(T† F-3,I), ι(T † F-5,I), ι(T† P-1,I), ι(T † S-1,I) ]	Incidents that occur during testing(e.g., unexpected failures) are recorded in a test incident report(ISO/IEC/IEEE 29119-3, 2013). Furthermore, these reports typically document if, and how to reproduce the incidents, while also providing supple-mentary material(e.g., logs, screenshots)(ISO/IEC/IEEE 29119-3, 2013). The disclosure of this information may allow adversaries to force the SuT into a critical state, provided that the exploited issues have not been fixed before releasing the software.
10	Obtain Test Re-sults	∨p[ι(T† F-2,I), ι(T † F-5,I), ι(T † F-19,I), ι(T† F-20,I), ι(T † F-21,I), ι(T† F-22,I), ι(T† P-1,I), ι(T † P-5,I), ι(T† S-1,I) ]	Stealing test results may constitute preparatory work an adversary undertakes as part of an attack that is launched during plant operation. In particular, failed tests would indicate that the SuT exhibits undesired behavior, providing attackers clues on potential flaws that might still be exploitable after the software release if the corresponding bugs have not been fixed in a timely manner.
11	Obtain Test Re-port	∨p [ι(T† F-2,I), ι(T † F-3,I), ι(T† F-5,I), ι(T † P-1,I), ι(T† S-1,I) ]	The test report summarizes test activities, outlines the progress made based on the achieved test results, and discusses incidents as well as new or changed risks that the team faces in future iterations(Spillner et al., 2011; ISO/IEC/IEEE 29119-3, 2013). While stealing the test report is certainly not an attacker’s top-priority goal, the test metrics, defect summary, open issues with their estimated severity, and the distribution of discovered bugs in software modules, still provides valuable hints where to search for vulnerabilities.
12	Obtain Archived Arti-facts	∨p [ι(T† F-2,I), ι(T † F-5,I), ι(T† F-17,I), ι(T† P-1,I), ι(T† P-3,I), ι(T† S-1,I), ι(TS-3,I) ]	Upon test completion, test assets, such as test plans, test procedures, test data, and artifacts related to the test environment, are archived for reuse(ISO/IEC/IEEE 29119-2, 2013). The disclosure of archived artifacts has similar consequences as the theft of individual assets that are included in the archived bundle. However, the aggregated nature of archived test artifacts makes them generally more attractive targets for information theft.
13	Inject malicious code into source code	∧p [ι(T‡ 1),∨p (ι(T∗ 11,S), ι(T∗ 11,T), ι(T∗ 11,E) ),∧p (ι(T∗ 13,T), ι(T∗ 17,T), ι(T∗ 26,T), ι(T∗ 30,T), ι(T∗ 31,T))]	Injecting malicious code into the codebase is certainly a worthy goal for attackers, since the resulting damage can have devastating effects for victims. For instance, attackers can tamper with the code to put either the SuT or, if the malicious code gets through QA and then shipped, the automation application in production into a critical state, potentially destructing equipment and putting human health at risk. Furthermore, attackers may be able to plant backdoors in order to gain command and control of the targeted system during plant operation. This would then also enable adversaries to exfiltrate data related to the industrial process under control.
14	Substitute SuT	∧p [ι(T‡ 3 ),∨p (ι(T∗ 14,S ), ι(T∗ 14,T ), ι(T∗ 14,E ) ),∧ p(ι(T∗ 13,T ), ι(T∗ 15,T ), ι(T∗ 30,T ), ι(T∗ 31,T ), ι(T∗ 35,T ))]	If an attacker is able to substitute the SuT with a stale version and, in further consequence, conceals this malicious act, the organization may ship a defective software product. Besides product liability claims that may arise from failing to meet quality standards, the organization may face a project delay and cost overrun due to the caused impediments, provided that the attack was detected during a subsequent phase of the PSE process.
15	Manipulate test environment description	∧p [ι(T ‡ 5 ),∨ p (ι(T∗ 24,S ), ι(T∗ 24,T ), ι(T∗ 24,E ) ),∧ p (ι(T∗ 17,T ), ι(T∗ 24,T ), ι(T ∗ 30,T ), ι(T ∗ 35,T ))]	Manipulating the test environment description may trick domain experts and users into misconfiguring the test bed. While errors in the setup of hardware or software may be obvious to domain experts, an incorrect parametrization may be more difficult to spot. A misconfigured test bed could destroy physical components either during the preparation of the test environment or during text execution and certainly impedes the testing process.
16	Manipulate test results	∧p [∧p (ι(T ‡ 5 ), ι(T ‡ 6 ) ), ∨p (ι(T ∗ 31,S ), ι(T ∗ 31,T ), ι(T ∗ 31,E ) ), ∧p (ι(T ∗ 30,T ), ι(T ∗ 32,T ))]	Adversaries who aim to manipulate the test results may try to conceal malicious acts by disguising failed tests as passed ones. In this way, stakeholders of the testing process may erroneously think that the SuT fulfills the QA requirements, potentially leading to PSE process impediments, successfully buried malware, and ultimately an undesirable behavior of the automation application.
17	Manipulate archived arti-facts	∧p [∧p (ι(T ∗ 18,I ), ι(T ∗ 19,I ) ), ∨p (ι(T ∗ 35,S ), ι(T ∗ 35,T ), ι(T ∗ 35,E ))]	If manipulated artifacts are archived, subsequent iterations of the testing process may be fundamentally flawed if they use these artifacts as a basis. Furthermore, potential legal or regulatory requirements for documenting information related to QA may not be met.

Table 6: Threat scenarios

与信息窃取相关的威胁场景的ADTree构建是完全自动化的，因为我们可以通过针对使用风险资产的数据流图元素，检索具有STRIDE威胁信息泄露的通用ADTree来实现。然而，属于（隐蔽）破坏类别的威胁场景更为复杂，因此推导这些威胁场景需要事先基于ADT本体进行建模。具体而言，我们假设攻击者若要对资产实施隐蔽破坏，必须首先发起侦察攻击，接着实际操纵资产，最后执行某些攻击以掩盖破坏行为。因此，用于表示此类威胁场景的ADTree由多个子树组成，分别对应于以下攻击阶段：(i) 侦察，(ii) 对资产的实际破坏，以及 (iii) 隐匿。表6中描述的所有（隐蔽）破坏威胁场景均包含这三个阶段，但威胁场景编号17除外，因为其检查目标不涉及归档的工件的重用（参见图3），因此缺少隐匿阶段。对于破坏阶段的子树，可通过检索适用于风险资产的具有STRIDE威胁伪装、篡改和权限提升的通用ADTree全自动构建；而对于其他两个阶段的子树，则需要我们手动建模。更具体地说，我们为表示这两个阶段的ADTree与相应资产之间建立了关联，这些资产必须在破坏前获取（用于侦察），或在破坏后被操纵（用于掩盖）。举例而言，对测试结果的隐蔽操纵（参见表 6中的威胁场景编号16）可通过以下方式实现：(i) 获取测试计划和测试用例，使攻击者能够准确了解将要执行的测试内容；(ii) 对使用测试结果的适用数据流图元素实施伪装、篡改或权限提升；(iii) 篡改测试事件报告和测试报告，以掩盖破坏行为。

由于表6中描述的攻击防御树可以从本体导出，用户可以选择一个威胁场景并启动ADTGenerator以生成包含相应攻击防御树的XML文件。完成后，他们可以将生成的XML文件导入ADTool（Kordy 等，2013a）。通过这种方式，用户可以获得关于潜在威胁的更全面视图，并可以直接开始详细检查每条攻击路径，重点关注涉及的具体情况（例如，系统的软件版本）。例如，图6描绘了获取源代码的攻击防御树的一部分（表6中的威胁场景编号1）。

VDI/VDE 2182‐1 (2011)指南规定要创建一个威胁 ma‐

获取源代码

源代码仓库：信息泄露（S‐2）

侧信道（#5）

辐射（#5）

其他辐射（#5）

屏蔽（#5）

声音（#5）

移除麦克风（#5）

文件系统影响（#5）

分离虚拟机（#5）

功耗（#5）

保护功耗日志（#5）

定时 (#5)

存储攻击

备份

密码学

未清理存储

销毁磁盘保护物理访问

物理访问

物理保护

防御节点

对策

析取精化

合取精化

加密文件系统

重用内存

攻击节点

图6：获取源代码的ADTree节选

使用威胁矩阵来完成威胁分析步骤。该威胁矩阵可包括威胁、受影响的资产、原因、漏洞以及导致的直接后果。创建此类威胁矩阵所需的信息（不包括具体的漏洞）可以从知识库或表3和表6中获得。然而，由于篇幅限制，本文省略了专门的威胁矩阵的呈现。

4.2.4. 安全目标

在威胁分析之后，必须确定相关的安全目标。本质上，可能会被一个或多个威胁破坏的资产的安全目标将被添加到威胁矩阵中。（VDI/VDE 2182‐1, 2011）由于每个建模的通用ADTree均根据STRIDE表示一种特定威胁，而每种威胁又对应一个安全目标，因此用户可以通过执行SPARQL查询自动推导出面临风险的以下目标：(i) 真实性（伪装）、(ii) 完整性（篡改）、 (iii) 不可否认性（抵赖）、(iv) 机密性（信息泄露）、(v) 可用性（拒绝服务）以及 (vi) 授权（权限提升）。该本体还可进一步扩展以包含其他安全目标，例如可审计性。

4.2.5. 风险评估

根据VDI/VDE 2182‐1(2011)指南，该步骤侧重于评估威胁发生的可能性以及损害的程度。该指南并未规定必须采用某种特定的风险测量技术，也未说明应使用定性还是定量方法。

应优先进行风险分析。然而，该指南提供了一个风险矩阵作为示例，用于将风险分为三类，即低、中和高。此外，指南中提到，在测量风险时，通常选择定性方法。（VDI/VDE 2182‐1, 2011）然而，由于定性方法本身具有一定程度的模糊性（Bojanc 和 Jerman‐Blazic, 2008年），定量风险分析可能是不可或缺的。因此，我们在本节中展示如何应用定量风险测量技术，以确保实现成本效益风险处理。

攻击防御树可用于回答与威胁场景相关的多种定量问题（Kordy 等， 2013b）。特别是，Kordy 等人 (2013b) 定义了可通过攻击防御树回答的三类问题，即：(i) “涉及单个参与方的问题”（例如，主张方的最小成本）， (ii) “可从彼此推导出双方答案的问题”（例如，威胁场景的成功概率），以及 (iii) “涉及外部第三方的问题”（例如，威胁场景的最大功耗）（ Kordy 等人 (2013b)）。

回顾一下，ADTGenerator 能够基于知识库生成表示 ADTree 的 XML 文件。这些 XML 文件随后可以导入到 ADTool 中，用于进行手动定量风险分析。为了说明如何执行风险分析，我们重用图6中所示的示例 ADTree。由于篇幅限制，我们重点关注与通用ADTree目标相连的攻击节点Side Channels和Storage Attacks，该通用ADTree的目标表示从数据存储（源代码仓库）中发生的信息泄露。此通用ADTree又连接到完整 ADTree的根节点，构成表6中描述的威胁场景编号1。

为了确定需要处理哪些风险才能达到可接受风险水平，我们使用 ADTool计算了示例性威胁场景的成功概率。假设所有操作相互独立，具有析取精化的节点（连接基本操作 A和 B）的成功概率可通过以下公式计算： P ∪( A, B) = P(A) + P(B) − P(A)P(B)；而具有合取精化的节点的成功概率可按如下方式计算：P ∩ = P(A)P(B)，其中 P表示概率分布（Kordy 等，2013b）。我们在图6中为每个基本操作分配了攻击或防御（根据相应节点类型）成功的概率值。在此值得指出的是，该成

防御节点的成功概率代表了对策有效性的估计值，该值也由对策是否已实施来确定。在手动赋值后，ADTool会自动计算其余节点（包括攻击防御树的目标）的概率。各节点成功概率的赋值和计算结果见表7。如表所示，攻击者从源代码仓库成功获取数据的可能性为0.798。

请注意，在使用 ADTool 计算成功概率时，假设所有操作都是独立的（Kordy 等，2013b）。然而，通过将攻击防御树与贝叶斯网络（Pearl， 1988）相结合，可以克服这一限制，如 Kordy 等（2014b）所提出的。

Node	可能性计算	概率
Attack Node
Code Reposi-tory: 信息泄露- 披露	-	0.798
侧信道	-	0.211
排放	-	0.011
其他辐射	0.01	0.01
声音	0.001	0.001
文件系统影响	0.1	0.1
功耗	0.03	0.015
时序	0.1	-
存储攻击	-	0.744
备份	0.75	0
未清理存储	0.65	0.65
物理访问	0.25	0.188
重用内存	0.1	-
Defense Node
屏蔽	0	-
移除麦克风	0	-
分离虚拟机	0	-
保护功耗日志	0.5	-
密码学	1	-
销毁磁盘	0	-
物理访问对策	-	0.25
物理保护	0.25	-
加密文件系统	0	-

表7：图6中所示ADTree节点的成功概率

所提出方法的优点在于，风险分析的结果可以传回知识库，以便能够

可在后续的过程迭代中重复使用。然而，从ADTool获得的定量评估结果必须在知识库和ADTool之间手动传输，因为我们将开发一个自动化此步骤的原型作为未来工作。

4.2.6. 对策

在分析风险后，必须确定对策并评估其针对威胁的有效性。此外， VDI/VDE 2182‐1 (2011) 指南指出，在选择经济有效的对策时，必须考虑对策的实施成本，以支持决策过程。（VDI/VDE 2182‐1, 2011）

此步骤可通过使用SPARQL查询予以支持，前提是攻击和防御节点的成功概率以及对策的实施成本已在知识库中表示。例如，我们通过 GitHub仓库3提供的相应SPARQL查询可检索出一系列潜在对策，包括估计的有效性、实施成本、所针对缓解的相应攻击，以及这些攻击成功实施的估计概率。该查询按攻击成功概率降序排列结果，并按对策的成功概率及其实现成本升序排列。通过这种方式，用户可制定防御策略，目标是将风险降低到可接受水平，同时兼顾其实施相关的成本。尽管为清晰起见我们采用了简化的示例，但该本体可扩展以支持其他可能对投资决策具有重要意义的因素（如业务需求）。

现在，最具成本效益的对策已经确定，可以开始实施。最后，必须由未参与该过程之前步骤的人员进行过程审计（VDI/VDE 2182‐1, 2011）。尽管这些步骤对于确保安全措施生效至关重要，但它们超出了本文的范围。