网络安全风险评估中元模型构建与实例应用

摘要

网络安全风险评估是系统工程中的一项重要工作，可用于推导安全系统设计所需的安全需求，评估设计方案及漏洞。同时，网络安全风险评估也是一项复杂的跨学科工作，需要应用领域与安全领域的专家协作并达成共识。目前，人们亟需自动化且工具支持的方法来应对这种复杂性。然而，系统工程中常用的模型通常侧重于功能行为，缺乏与安全相关的维度。因此，本文提出一种建模方法，该方法不仅能促进相关专家之间的沟通，还融入了计算机辅助建模步骤，以确保一致性并避免遗漏错误。本文通过实例演示该方法，同时阐述如何以模块化方式对影响等级和攻击可行性评估进行建模，以及如何通过模型对这些评估结果进行传播和聚合。最终，专家能够在模型中做出局部决策或修改，而模型可反过来呈现这些决策或修改对整体风险状况的影响。最后，本文还探讨了基于模型的方法所具备的优势。

1、引言

网络安全风险评估（SRA）是需求工程的关键组成部分，能够系统性地推导安全需求。此外，在工程生命周期中，网络安全风险评估还可为后续与安全相关任务的优先级排序和执行提供支持。因此，在众多法规和国际标准中，网络安全风险评估都是强制性环节。

然而，风险评估是一项极具复杂性的艰巨任务，因为所有可能与待开发系统（SUD）发生的交互（不仅包括所有已明确规定的交互）都可能导致保护需求遭到破坏。因此，有必要借助计算机辅助的、基于模型的方法为分析人员提供支持，以避免遗漏或其他 “人为错误”，并应对这种复杂性。

一般而言，实现网络安全风险评估高度计算机辅助所需的数据往往较为匮乏：定义系统的功能和结构属性是系统开发不可或缺的一部分，而对潜在滥用情况进行建模却并非如此。系统模型的设计都围绕特定目标展开。正如 “所有模型都是不完美的，但部分模型具有实用价值”这一观点所述，系统开发过程中现有的模型仅在一定程度上适用于安全评估的目标。有些维度可能被过度呈现，而有些维度则可能未得到充分涵盖。因此，本文提出的假设是：为网络安全风险评估构建专门的模型，能更贴合该任务的需求。尽管如此，专门的网络安全风险评估模型仍然是对开发系统（SUD）的简化。这种简化具有实用价值，因为它能降低复杂性。但攻击者会与实际存在的系统进行交互，并不会受模型局限性的影响。因此，要开展合理的网络安全风险评估，以人类的创造力去探究攻击者可能采取的手段，安全分析人员的专业经验仍然不可或缺。

本文提出的基于图的建模方法，旨在实现理论与实践的最佳结合。完整的图能为网络安全风险评估各要素间的关系提供丰富的呈现，从而支持计算机辅助功能；同时，也可对图中的特定部分进行可视化处理，为人类专家提供辅助。该方法有助于从模型中识别关键路径和推导影响链，同时让人类分析人员始终参与其中。例如，组件之间的连接可通过数据流推导得出，并以图表形式可视化呈现；同样，图中的攻击路径也可采用类似攻击树的方式进行可视化展示。图形化呈现还有助于开发人员、安全专家及其他相关方（如管理层）之间的沟通，使所有相关方都能理解并验证分析过程。

本文基于之前在汽车领域的研究成果和实践经验，并对参考文献中提出的研究内容进行了拓展。本文的贡献如下：

1. 优化用于网络安全风险评估的扩展元模型，以基于待开发系统（SUD）来呈现安全目标、威胁、控制措施和假设之间的复杂依赖关系；

2. 定义用于评估这些依赖关系的基本形式化属性；

3. 制定针对所有相关要素的风险值计算规则集。

这些贡献所带来的益处包括：可对所有相关要素的风险值进行全局计算评估。由此，能够识别关键的安全目标、威胁、假设和控制措施，并可评估不同设计方案可能产生的后果。除了呈现控制措施和假设对攻击可行性的影响外，本文的贡献还为呈现和评估其对安全目标保护需求的影响提供了方法。

本文其余部分的结构安排如下：第2节探讨相关工作；第 3 节提供所用风险评估方法的背景信息；第 4 节介绍并演示基于图的建模方法；第 5 节阐述信息流和风险计算过程；最后在第 6 节进行总结。

2、相关工作

正如参考文献所揭示的，网络攻击的威胁日益严峻。为应对这一情况，协调一致的法规和国际标准已将网络安全风险评估列为未来开发流程中的强制性活动。要在开发、生产和后期生产阶段强制实施网络安全风险评估与管理流程，就需要适用的方法。通常，开发过程中基于模型的风险评估包括构建待开发系统（SUD）的模型、影响评估以及威胁评估。

STRIDE 方法是当前先进的威胁评估方法，也是众多网络网络安全风险评估方法体系的基础。STRIDE 代表六种被关注的威胁类别，即欺骗（Spoofing）、篡改（Tampering）、否认（Repudiation）、信息泄露（Information disclosure）、拒绝服务（Denial of service）和权限提升（Elevation of privilege），这些威胁类别可能对安全目标构成威胁。每种威胁类别至少会对一项安全属性产生负面影响：身份欺骗会破坏实体的真实性；篡改会威胁数据和流程的完整性；否认所承担的责任会干扰不可否认性（如流程交互的不可否认性）；信息泄露会影响数据和流程的机密性；拒绝服务会破坏组件、数据和流程的可用性；权限提升则会使得未授权操作得以执行。STRIDE 的一个重要扩展是 “按元素划分的 STRIDE”（STRIDE-per-Element），该扩展考虑到特定威胁在模型特定元素上出现的概率更高，通过聚焦于最相关的威胁，从整体上为威胁识别提供便利。近年来，有多个网络安全风险分析框架将 STRIDE 与攻击树相结合。

贝叶斯攻击图是评估 IT 网络安全风险和漏洞的一种方法，能够为通用攻击图提供贝叶斯推理过程。而本文所提出方法的核心目标是为概念设计和开发阶段提供支持，在这两个阶段，通常尚未发现已知漏洞，薄弱环节也极为少见。因此，贝叶斯网络所需的百分比数值无法直接确定，在实际操作中，相关负责方对此也往往存在较大分歧。为评估攻击者实施攻击的技术难度，本文转而采用定性方法（如《信息技术安全评估通用方法》）对每个攻击步骤所需的能力进行评级。

采用合适的本体是解决网络安全风险评估中常见不一致问题的一种途径。苏阿格等人对风险评估本体进行了全面概述。作者对比了多种现有本体，并构建了一种新的本体，其中包含更多高层安全概念、公理和属性。他们通常采用网络本体语言（Web Ontology Language）来定义模型，并借助语义查询增强型 Web 规则语言（Semantic Query-enhanced Web Rule Language）通过查询实现一定程度的自动化。但其目标受众是需求工程师，并非聚焦于风险评估。与这种高层级方法不同，本文针对网络安全风险评估中的结构、关系以及评级传播等方面提供了更为详尽的细节。参考文献中采用了一种类似的方法，用于在描述不完整或不一致的系统中自动搜索已知漏洞。参考文献提出了一种从已评估的网络安全风险中推导高层安全措施建议的方法。与本文提出的方案不同，该文献中介绍的风险分析方法和元模型在网络安全风险评估的全面性方面存在局限。这类方法若采用本文提出的元模型和方法，或许能显著提升效果。

计算机辅助需求与信息安全集成（CAIRIS）是一个用于管理安全、可用性和设计工件的框架。参考文献实现了一定程度的自动化和可视化。该框架的目标范围更为广泛，还涵盖了可用性和需求工程活动。在网络安全风险分析方面，作者提出了一个涵盖多种概念的本体。CAIRIS 所表达的信息与本文方法有相似之处，但在其实现过程中，包含了许多用于存储额外信息的概念，这无疑增加了文档编制、维护和保持一致性的工作量（例如环境、漏洞、障碍、用例等概念）。由于该方法涵盖范围广泛，网络安全风险评估核心概念（目标、威胁、控制措施及其相互作用）的细节完整性和简洁性似乎受到了影响。同样，本文认为将安全领域与（功能）开发领域分离，有助于实现针对性的应用。

CySeMol及其扩展版本 P²CySeMoI将基于 UML 的信息系统建模与贝叶斯攻击图相结合，用于评估攻击概率。其关系模型及基于该模型构建的推理引擎能够对 “假设分析” 场景进行评估。由于组件的预定义粒度，由已知组件构成的网络可得到高效评估。尽管该方法允许在分析过程中对模型进行修改，但不支持迭代式细化或损害转换，且难以处理新增组件。参考文献提出了另一种在网络安全风险分析框架中形式化描述安全属性的方法，该方法基于模型检查和马尔可夫决策过程来确定风险概率。

参考文献中提出的 FAIR 方法是一种用于信息风险分析的专有框架。该框架包含分类法、衡量风险驱动因素的方法以及模拟这些因素之间关系的计算引擎。风险确定的关键因素包括基于威胁事件频率和漏洞的损失事件频率，以及反映影响的损失幅度。由于依赖可量化的历史因素，该方法在初始风险评估和非度量环境中应用时，会给用户带来极大困难。与本文提出的关注整体影响的方法不同，FAIR 方法仅局限于信息资产相关的风险。

安全感知危害与风险分析（SAHARA）方法将汽车领域的危害分析与风险评估（Hazard Analysis And Risk Assessment）和 STRIDE 方法相结合，旨在通过对威胁和危害的影响进行直接量化，为功能概念阶段提供支持。同样，故障模式影响分析（Failure Mode Effects Analysis）的扩展方法 FMVEA在其中融入了漏洞因素，重点关注开发的技术概念阶段。尽管这两种面向汽车领域的方法都依赖于待开发系统（SUD）的模型，但它们均采用自上而下的评估方法，即分析特定威胁或安全危害可能由哪些因素引发。此外，在评估过程中，它们并未考虑交互作用或事件序列，也未考虑安全措施的影响及其在模型中的传播情况。

风险树基网络网络安全风险评估方法（RISKEE）融合了 FAIR、SAHARA 和 FMVEA 三种方法。正如其名称所示，该方法将风险计算与攻击树相结合。基于 FAIR 方法，所考虑的风险因素包括漏洞的发生频率、漏洞本身以及漏洞的影响程度。RISKEE 方法的一个特色是通过损失超出曲线，将计算得出的风险与可接受风险进行关联和可视化呈现。

当前主流的商业威胁建模工具包括微软威胁建模工具和 fortisee SecuriCAD，其中 SecuriCAD 还具备概率攻击模拟功能。这两种工具都提供图形界面，用于对当前和抽象的 IT 环境进行建模，并评估潜在的安全问题。微软威胁建模工具采用基于 STRIDE 的风险评估方法，而 SecuriCAD 还支持通过蒙特卡洛模拟对可能的攻击向量进行评估。不过，这两种工具都侧重于粗粒度的攻击路径，主要针对云环境和企业 IT 系统，缺乏攻击可行性因素传播或损害转换功能。目前，也有商业工具正被开发用于支持汽车领域的网络安全风险评估，如 Yakindu Security Analyst和 Ansys Medini Analyze。

3、背景知识

本文采用的风险评估方法以模块化风险评估（MoRA）方法为基础。图 1 展示了该方法框架的四项核心活动，分别是 “为评估目标建模”“确定保护需求”“分析威胁” 和 “分析风险”。第一步是将待开发系统（SUD）分解为相关功能、数据元素、组件和数据流。下一步是将安全目标确定为待开发系统（SUD）中详细说明的资产与其所需安全属性的组合。第三步通过对开发系统（SUD）的元素进行系统性分析，识别针对资产的威胁。此外，还可添加现有的或拟采用的控制措施，以缓解已识别的威胁。最后一步是对安全目标、威胁和控制措施的影响等级和攻击可行性进行评估，并根据这些评估结果推导出风险等级。尽管本文的研究工作以 MoRA 为基础，但文中术语的使用与 ISO/SAE 21434 标准保持一致。

图1.根据MoRA，安全风险评估的主要活动和核心概念。第4节提供了有关表示这些核心概念的元模型的更多详细信息

MoRA 方法依赖评估模型和目录来实现特定应用领域内评估的标准化。因此，评估模型和目录为所有相关方在风险评估核心方面（如评估标准或威胁类别）提供了共同基础。需要注意的是，标准和法规可能会对评估模型的部分内容（如联合国 R-155 法规附件 5 中关于车辆网络安全及网络安全管理系统认证的统一规定所给出的威胁模型）提出建议或做出明确规定。

本文第 4 节中所阐述的、在前期研究基础上拓展而来的基于图的建模方法，对 MoRA 方法的表示方式进行了优化。该方法的实施得益于在工业开发项目中多年的实践经验。模型和计算规则是相关工具（如 Yakindu Security Analyst）开发的基础。尽管本文介绍的通用元模型未采用特定语法，但我们已成功对该元模型和相关工具进行了调整，以满足标准和法规（如 ISO/SAE 21434）或 IEC 62443）中有关风险评估的特定要求。

4、元模型

本节将介绍参考文献中首次提出的网络安全风险评估（SRA）模型的元模型。该元模型不仅包含待开发系统（SUD）的重点呈现，还涵盖了安全目标、损害场景、威胁、控制措施和假设等与风险评估相关的核心概念。将所有这些元素整合到一个模型中，能够推导并验证待开发系统（SUD）相关的网络安全风险评估（SRA）元素之间的关系及属性，从而有助于理解和追溯。下文将结合 MoRA 方法的主要活动，介绍这些核心概念，并辅以建模实例。

4.1 待开发系统建模

待开发系统（SUD）模型是分析工作的基础，其中包含资产。了解资产对于明确保护需求和识别潜在损害场景至关重要。同时，待开发系统（SUD）模型还概述了可能与待开发系统（SUD）发生的交互，这有助于识别针对该系统的潜在威胁。此外，安全分析人员通过与领域专家合作对开发系统（SUD）进行建模，能够深入了解待开发系统（SUD）。而且，由于所有论证都以系统模型为依据，向领域专家解释风险也会更加容易。需要注意的是，任何风险评估都需要对所分析对象进行抽象，即分析人员需在脑海中构建一个模型。根据我们的经验，将该模型形成文档，并与领域专家共同探讨，能够提高模型的准确性。

如图 2 所示，待开发系统（SUD）的图由四组节点（以节点形式呈现）以及节点之间的关系（以边的形式连接节点）构成。风险评估图中的四组节点分别代表待开发系统（SUD）的功能、数据元素、组件和数据流。在每组节点内部，子元素关系（“是子数据”“是子组件” 和 “是子功能”）体现了元素之间的层级结构。例如，一个组件可细分为多个子组件（如 “车辆” 组件包含 “制动电子控制单元”“安全气囊电子控制单元” 等子组件，而 “制动电子控制单元” 又可包含 “软件平台” 这一子组件）。

图2.元模型包括函数：函数是使用数据、组件和数据流实现的

每个数据流都有发送方和接收方，因此从数据流到发送方组件和接收方组件分别存在 “有发送方” 和 “有接收方” 的对应关系。此外，数据流与一个或多个数据元素之间存在 “传输” 关系。需要说明的是，若有必要，元模型允许组件既不接收也不传输数据。组件与本地存储的数据元素之间存在 “存储” 关系，这种关系主要用于表示那些可能从未被传输过的数据（如用于加密操作的私钥）。组件与数据之间的所有关系都是非互斥的，也就是说，不同组件可以发送、存储和接收相同的数据元素。这些关系如图 2 所示。

基于这些明确的关系，可以推导出隐含关系：对于每个发送方，存在与所发送数据元素对应的 “生成” 关系；对于每个接收方，存在与所接收数据元素对应的 “消耗” 关系。因此，组件的接口定义可通过数据流定义推导得出。为避免不一致性，这些隐含关系始终是根据现有的数据流定义计算得出的，而非明确界定的。

如图 2 所示，功能与数据元素、组件和数据流之间存在 “映射到” 关系。这些关系表明，功能通过数据处理和传输来实现，而数据处理和传输又由组件执行。因此，功能依赖于与其映射的元素。

我们选择这种方式来呈现待开发系统（SUD），原因在于它既能充分支持基于 MoRA 方法的网络安全风险评估，又仅包含系统开发过程中通常会生成的信息。例如，以 UML 用例图、带有信息流的组件图以及相应的类图形式呈现的待开发系统（SUD），都可作为建模活动的输入。其中，功能可从用例图中提取，组件和数据流可从组件图中提取，数据元素可从类图中提取。因此，成熟的建模语言可作为 “为评估目标建模” 这一步骤的输入。此外，网络安全风险评估（SRA）模型中所包含的信息也可轻松 “转换” 回 UML 形式，这有助于促进领域专家和安全专家之间的沟通。因此，我们提出的待开发系统（SUD）表示方法，有助于所有相关方相互理解并协作构建网络安全风险评估（SRA）模型，同时为后续风险评估步骤提供清晰明确的参考依据。

4.2 确定保护需求

保护需求通过安全目标和损害场景这两个与风险评估相关的核心概念来体现。

安全目标（SG）为资产定义了安全属性，这里的 “安全属性” 指资产的某种特性，如机密性、可用性或完整性。为简化表述，本文重点关注这三种安全属性，但该方法可扩展至任意一组属性。资产被建模为待开发系统（SUD）的元素，通过 “是…… 的资产” 关系来体现，如图 4 所示。例如，某医疗系统存储了 “患者数据” 这一数据元素，那么 “患者数据的机密性” 就是一个安全目标，其中安全属性为 “机密性”，资产为 “患者数据”。

图3.安全目标的依赖性。左侧显示了仅当未给出源1和源2的可用性时，如何违反数据项的可用性。右侧描述了一种情况，即违反单个依赖关系就足以违反顶部的安全目标

图4：完整的元模型，包括控制和假设：威胁可以通过控制、假设或这些的组合来缓解

需要注意的是，本文中 “安全目标” 的定义与 ISO/SAE 21434标准中定义的类似术语 “网络安全目标” 有所不同。由于该标准未针对 “资产的网络安全属性” 这一概念提供简洁术语，为与本文之前关于该主题的研究成果保持一致，我们仍沿用 “安全目标” 这一表述。

相关安全目标遭到破坏，可能会引发一个或多个损害场景，这通过 “破坏导致” 关系来表示。损害场景由非空的影响标准集来定义。在上述示例中，安全目标 “患者数据的机密性” 遭到破坏，会导致 “未授权访问个人数据” 这一损害场景，该场景包含 “严重违反法律” 这一影响标准属性。影响标准是评估模型的组成部分，评估模型会为每个影响标准分配一个影响等级。影响标准可按照影响类别（如安全、财务、运营或隐私）进行分类。参考文献要求涵盖这四类影响类别，此前的研究也提出了类似分类。包含影响类别和相应影响标准的评估模型可根据组织及其运营领域进行调整。

安全目标之间可能存在依赖关系。例如，某一功能的可用性依赖于执行该功能的组件的可用性：若组件的可用性遭到破坏，那么该功能的可用性也会受到影响。因此，第二个安全目标依赖于第一个安全目标。

这些依赖关系可能是相互独立的，也可能需要多个依赖关系同时遭到破坏才会产生影响。例如，若某一数据项由两个独立来源提供，那么只有当 “第一个来源的可用性” 和 “第二个来源的可用性” 这两个安全目标都遭到破坏时，“数据项的可用性” 这一安全目标才会被破坏。该示例的图形表示如图 3 所示。

为定义这些依赖关系，我们引入了 “组合安全目标” 元素。一个安全目标可依赖于任意数量的相互独立的 “组合安全目标” 节点，而每个 “组合安全目标” 节点又与一个或多个安全目标相关联。

需要说明的是，经典攻击树中常见的包含 “与” 和 “或” 的任意逻辑表达式，都可转换为析取范式，以适配本元模型，其中也包括特定的攻击序列。

4.3 威胁分析

威胁分析通过威胁、控制措施和假设这三个与风险评估相关的核心概念来体现。

如图 4 所示，安全目标受到多种威胁组合的威胁。与安全目标对其他安全目标的依赖类似，威胁既可能独立地对安全目标构成威胁，也可能需要与其他威胁协同作用才能成功威胁安全目标。例如，对某一功能完整性的威胁，可能包括通过窃听消息进行攻击准备，以及随后重放所窃听的消息这两个步骤。为定义这些依赖关系，我们引入了 “组合威胁” 元素。一个安全目标可能受到任意数量的相互独立的 “组合威胁” 节点的威胁，而每个 “组合威胁” 节点又与一个或多个威胁相关联。

威胁具有以下属性：

1. 攻击可行性因素：用于评估实施威胁的攻击可行性等级。攻击可行性因素本身在评估模型中进行定义，因此可根据任意标准或组织需求进行调整。例如，《信息技术安全评估通用方法》（CEM）定义了五个用于评估 “所需攻击潜力” 的攻击可行性因素，即所需时间、专业技能、对评估对象（TOE）的了解程度、攻击机会窗口以及必要设备，并为每个攻击可行性因素设定了一组预定义值（如 “门外汉水平”）及相应的数值。

2. 受威胁的安全属性：明确威胁可能破坏的安全属性。例如，“信息泄露” 威胁会对 “机密性” 这一安全属性构成威胁。

威胁作用于待开发系统（SUD）的物理实体。如 4.1 节所述，待开发系统（SUD）的物理层面被建模为组件和数据流（包括无线传输），而数据和功能则由这些元素处理。“作用于” 关系并非风险评估建模所必需，但有助于人类分析人员理解威胁。此外，结合待开发系统（SUD）模型和受威胁的安全属性，可识别并验证可能被破坏的安全目标。例如，“信息泄露” 威胁作用于某一数据流，对传输数据项的机密性构成威胁，那么可以合理推断，该威胁会影响映射到这些数据项的功能的机密性。元模型中未单独设置漏洞元素。在 MoRA 方法的语境下，若某一威胁会引发相关风险且未得到缓解，则该威胁即为待开发系统（SUD）的漏洞。

（网络安全）控制措施和假设可用于缓解威胁。这些元素的组合通过 “组合缓解措施” 节点类型来表示。在某些情况下，由于技术原因，控制措施和假设可能具有相似性。待开发系统（SUD）所采用的技术措施（如信道加密）通常被建模为控制措施。相比之下，自然规律、责任归属、第三方控制措施、攻击者能力以及分析局限性等，则被记录为假设。与威胁类似，控制措施和假设也具有攻击可行性因素和受保护的安全属性。攻击可行性因素有助于评估控制措施或假设对相关威胁的攻击可行性产生的影响。第 5 节将详细阐述如何在网络安全风险评估（SRA）模型中组合这些攻击可行性因素。

此外，控制措施和假设可能会导致安全目标被破坏所产生的影响发生变化，这种变化通过损害转换来建模。在这种情况下，一个损害场景会被另一个损害场景替代；若未指定转换目标，则该损害场景会被完全消除。

例如，假设某工厂的阀门由网络消息控制，攻击者可能会通过操纵这些消息来破坏 “阀门控制的完整性” 这一安全目标，进而引发 “压力罐爆炸” 这一损害场景。而 “根据本地测量的高压值开启阀门” 这一控制措施虽无法阻止消息被操纵，但能有效将（源）损害场景转换为危害程度较低的目标损害场景 ——“生产中断”。

假设可用于将那些未在待开发系统（SUD）中明确建模但对分析结果有重要影响的信息（如假设的攻击者模型的局限性）纳入模型。与控制措施不同，假设不依赖于安全目标。

MoRA 方法还支持针对威胁类别和控制措施类别的目录。这些类别可包含对攻击可行性因素的预评估，用于估算实施威胁或突破控制措施的攻击可行性。网络安全风险评估（SRA）中的威胁和控制措施可采用这些预评估值，也可根据网络安全风险评估（SRA）的具体场景对其进行调整。除为网络安全风险评估提供共同基础外，这些目录还有助于分析人员 “不遗漏” 已知威胁，并验证是否符合法规规定的威胁和控制措施目录要求。

控制措施由待开发系统（SUD）实施，因此可能依赖于该系统的安全目标。例如，“数字签名” 这一控制措施需要一个组件生成签名，另一个组件验证签名的有效性。因此，攻击者无需破解签名，只需破坏签名生成组件上 “私钥机密性” 这一安全目标，或破坏签名验证组件上 “证书完整性” 这一安全目标，即可绕过 “数字签名” 控制措施。我们通过引入控制措施对安全目标或组合安全目标的依赖关系（同样使用 “组合安全目标” 节点类型）来对这种情况进行建模。因此，无需直接评估加密密钥机密性受损所造成的影响，这些影响可通过针对控制措施的额外攻击路径来体现。这样一来，若受保护功能、数据项或组件的安全目标的影响等级发生变化，那么针对加密密钥的攻击所引发的风险也会相应地、一致地体现出这种变化。

4.4 风险分析

图 4 展示了包含所有节点类型及其相互关系的完整元模型。本文未将风险建模为独立元素，而是如第 5 节所述，可确定每个安全目标、威胁、控制措施或损害场景的风险等级。

风险等级由潜在损害（影响等级）和引发这些损害的攻击可行性等级共同确定。影响等级由与风险相关的损害场景所对应的影响标准确定；攻击可行性等级则由威胁的攻击可行性因素以及缓解这些威胁的控制措施的攻击可行性因素共同确定。

根据我们的实践经验，这种由功能、数据、组件和数据流构成的待开发系统（SUD）模型，既非常适合用于网络安全风险评估（SRA），也易于系统开发人员理解。风险评估核心概念中的所有节点都与该模型相关联：安全目标是待开发系统（SUD）的属性；威胁和控制措施作用于待开发系统（SUD），用于建模与系统的交互。如参考文献所述，可通过追溯至待开发系统（SUD）模型，对风险评估元素之间的关系进行验证。同样，参考文献还提供了一种基于待开发系统（SUD）模型提出新节点和新关系的方法。因此，风险评估元素的创建过程可部分实现自动化，分析人员只需对生成的建议进行检查和修改，并进一步明确所建议元素的细节即可。

4.5 建模实例

图 5 展示了针对某虚拟软件更新功能的元模型实例。需要说明的是，风险评估中的元素及其关系并非必须通过图形方式呈现，也可采用表格等形式。这一点至关重要，因为完整的风险评估全图往往包含大量节点和复杂的关系，复杂度极高，人类分析人员通常难以直接处理这种完整的图形表示。不过，根据我们的经验，将特定部分以图形方式呈现会非常有帮助。因此，我们选择一个小型实例，以简洁明了的方式突出本文方法的关键特性。总体而言，由于不同应用领域和组织环境的需求存在差异，本文并未为元模型实例规定专门的具体语法。图 6 展示了 itemis YAKINDU Security Analyst 工具的截图，该工具为元模型实例提供了多种具体语法。截图上半部分显示了威胁的文本具体语法（在该语法中称为攻击步骤），下半部分则展示了待开发系统（SUD）的图形具体语法。

图5：此示例显示了我们用于虚拟软件更新功能风险评估的图形实例的摘录

图6：YAKINDU Security Analyst 21.1提供的具体语法截图

该实例描述了一个虚拟的软件更新功能：服务器向车辆推送更新。若 “更新功能的完整性” 这一安全目标遭到破坏，可能会引发与安全相关的 “车辆失控” 损害场景，以及与财务损失相关的 “未授权改装” 损害场景。该安全目标面临两条独立的攻击路径的威胁：第一条攻击路径包含 “逆向工程” 威胁和 “（移动网络）中间人攻击” 威胁，其中后者作用于服务器与车辆之间的移动数据流。“AES GCM” 控制措施可保护传输数据的机密性和完整性，从而缓解中间人（MitM）攻击。但该控制措施依赖于 “（AES 密钥的）机密性” 这一数据项的安全目标。在本实例中，所有车辆共享同一个对称密钥，因此 “（AES 密钥的）机密性” 这一安全目标面临针对单一车辆的密钥提取攻击的威胁。

第二条攻击路径在服务器与车辆之间的数据流中间人（MitM）攻击基础上，增加了对车辆内部数据流的攻击，但仍需攻击者实施逆向工程。由于 “AES GCM” 控制措施仅作用于服务器与车辆之间的数据流，无法保护车辆内部的数据流。在本实例中，我们还将攻击者模型限定为需要物理接触的改装相关攻击。因此，“仅允许改装” 这一假设会将 “车辆失控” 损害场景转换为 “未授权改装” 损害场景。需要注意的是，损害转换也可完全消除某个损害场景。

5、传播规则与风险计算

在前面的章节中，我们定义了元模型并提供了图实例的示例。本节将给出计算特定图中风险等级的规则。首先，阐述基本思路；然后，基于图中实例化的元模型元素，对实际计算过程进行形式化定义；最后，通过实例进行说明。

5.1 基本思路

与其他网络安全风险评估（SRA）模型不同，本文旨在分别计算安全目标、威胁、控制措施和损害场景的风险等级。确定所有这些元素的风险等级具有重要意义，因为识别最关键的威胁、风险最高的安全目标和资产、最薄弱的控制措施环节以及最严重的损害场景，都能为风险处理决策提供有价值的信息。

风险计算需要两个输入参数：攻击可行性等级评估（基于攻击可行性因素）和影响等级。这些输入参数在图实例的不同元模型元素中被定义为属性：威胁和控制措施包含攻击可行性因素属性；损害场景包含影响标准属性。而影响标准属性又在评估模型中映射为影响等级，因此损害场景中可获取具体的影响等级。此外，控制措施和假设可能会通过损害转换筛选相关的损害场景。本文利用图中与风险评估相关元素之间的关系，对这些属性进行组合，从而计算风险等级。通过属性组合，可获取风险计算所需的两个输入参数。需要注意的是，从技术角度而言，元模型允许定义循环依赖关系，但为确保本文方法的有效性，元模型实例必须是有向无环图（DAG）。根据我们在实际项目中的经验，这一要求并不会对建模能力造成实质性限制。

基本思路是让属性值在图中流动或传播。图 7 展示了攻击可行性因素和损害转换的传播过程，图 8 则展示了计算得出的风险值沿边反向传播的过程。从控制措施、假设或威胁到另一个节点的节点序列，构成了指向该节点的攻击路径。需要说明的是，本文将任意长度的此类路径均称为攻击路径。我们会计算指向每个安全目标的每条攻击路径的风险。攻击路径上可能包含以下任意类型的节点，这些节点既可以接收属性值，也可以传播属性值：安全目标、组合安全目标、假设、控制措施、组合缓解措施、威胁、组合威胁。未列出的元模型元素（损害场景和损害转换）用于计算风险值，但本身不属于攻击路径的一部分。

图7.通过图形传播攻击可行性因素和损伤转换

图8.风险有选择地传播，遵循攻击路径的起源

多条攻击路径可能指向同一个损害场景（实际上构成了图中的攻击树）。传播规则定义了如何沿攻击路径累积属性值，以及如何组合多条攻击路径的属性值。因此，修改某个节点的属性会导致图中所有相关节点的风险值随之更新。

如前所述，该算法包含两个部分。第一部分（攻击可行性因素和损害转换传播）构建所有最大长度的攻击路径。此步骤从那些没有 “依赖于” 或 “被缓解by” 关系的假设、控制措施和威胁节点（这些节点被称为 “叶节点”）开始。算法首先对所有 “叶节点” 应用下文定义的计算规则，根据这些规则生成包含当前节点的攻击路径集，并将其作为输出，通过边传递给下一个节点作为输入。当某个节点获取到所有入边的输入集后，便会应用传播规则。最终，图中所有可能属于攻击路径的节点都会被处理，算法的第一部分就此完成。

第二部分（风险传播）沿与第一部分相反的方向在图中进行。算法从安全目标开始，计算所有入站攻击路径（在第一步中传播得到）的风险，然后沿这些安全目标的入站攻击路径传播风险。安全目标与损害场景之间存在关联，这是计算影响等级的基础。但入站攻击路径可能会对这些场景产生转换影响。在应用这些影响后，计算每条攻击路径的风险等级。其中，最高风险值即为该安全目标自身的风险等级。随后，每条攻击路径的风险等级会沿攻击路径在图中传播。

因此，这种建模和计算方法能够支持包含复杂依赖关系的风险决策。以下计算说明可用于自动化实现。

5.2 计算过程

本文将计算规则的说明分为两部分。首先，介绍图 7 所示的攻击可行性因素和损害转换的传播过程，相关规则如表 1 所示；然后，介绍图 8 所示的风险等级传播过程（风险等级沿攻击路径反向传播），相关规则如表 2 和表 3 所示。实际计算也按此顺序进行。

5.2.1 攻击可行性因素与损害转换的传播

第一种传播涉及攻击可行性因素。如第 4 节所述，攻击可行性因素用于评估攻击可行性等级。攻击者实施攻击所需的努力至少包括攻击路径初始节点所需的努力，并且随着攻击路径的延伸，由于需要执行不同步骤，所需努力通常会增加。同样，引发损害转换的节点会将这种转换效应沿攻击路径传播。传播过程从假设开始，同时也包括那些没有 “依赖于” 或 “被缓解 by” 关系的控制措施和威胁节点。名称中包含 “组合” 一词的节点类型，会按照下文定义的规则对入站攻击路径进行组合。威胁通过将自身的攻击可行性因素添加到攻击路径中，对入站攻击路径产生影响。缓解措施（控制措施或假设）始终会生成一条或多条新的攻击路径：第一条攻击路径通过其攻击可行性因素来突破缓解措施，在这种情况下，缓解措施的攻击可行性因素会在新的攻击路径中传播；若缓解措施具有损害转换效应，则会生成第二条攻击路径，该路径保留缓解措施的作用，并传播损害转换效应；若缓解措施存在入站攻击路径，则这些路径通过缓解措施的依赖关系来突破缓解措施，因此在传播过程中，攻击可行性因素或损害转换效应不会发生变化。安全目标在传播攻击路径时，不会改变攻击可行性因素或损害转换效应。攻击路径通常终止于安全目标，但也可能终止于其他节点（例如，当某个威胁未对任何安全目标构成威胁时）。

表 1 定义了攻击可行性因素和损害转换效应的传播规则。本文采用以下符号和定义：

表1.攻击可行性因素传播规律与损伤转化效应

表 1 详细规定了计算和传播规则。需要注意的是，每个节点和节点类型的变量都会重新定义（例如，在节点的作用域内，节点的唯一标识符始终为e0。元模型元素的名称以粗体显示。

5.2.2 风险传播

在完成攻击可行性因素值和损害转换效应的全面传播后，便开始进行风险等级的计算和传播。初始计算从没有 “组合安全目标” 节点的 “包含” 入边的安全目标节点（即风险传播中的 “叶节点”）开始。对于每条攻击路径，首先根据该路径的攻击可行性因素值计算攻击可行性等级；接着，将所选攻击路径的所有损害转换效应应用于该安全目标节点相关的损害场景节点（遵循 “破坏导致” 关系）；然后，由得到的损害场景确定影响标准，进而确定影响等级，其中最高影响等级即为所选攻击路径的影响等级；将该影响等级与攻击路径的攻击可行性等级相结合，即可得到该攻击路径的风险等级。某个节点的所有攻击路径中，最高风险值即为该节点自身的风险等级。随后，该节点会将所有风险等级沿其对应的攻击路径在图中传播。本文为这些规则额外采用以下符号：

表2.安全目标节点风险结果传播规则

表3.联合安全目标、联合威胁、威胁、联合缓解、控制或假设节点的风险结果传播规则

表 2 和表 3 详细规定了安全目标节点内部风险等级的计算以及风险等级结果的传播规则。表 2 还阐述了向损害场景节点传播风险等级的过程（参见表中第二个 “输出” 部分）。需要注意的是，风险等级并非沿攻击路径逐跳传播，而是直接从安全目标节点传播。每条攻击路径的推导风险等级结果会传播给该路径上的每个节点。这种方式在保持图 8 语义不变的前提下，简化了传播规则。

5.3 实例分析

本文以 4.5 节介绍的实例为基础，在图 9 中展示了该实例中攻击可行性因素和损害转换效应的传播过程。边框加粗的三个节点为该传播过程中的 “叶节点”，是传播的起始点。需要说明的是，在本实例中，我们为传播的攻击路径分配了唯一标识符，而非对攻击路径集合中的元素进行索引编号。实线边框的圆角矩形表示输出攻击路径集合，虚线边框的圆角矩形表示输入攻击路径集合，圆形表示局部属性。

图9.软件更新示例中显示了攻击因素的传播和损伤转换。粗边框标记“叶子”节点

对于 “更新功能的完整性” 这一安全目标，存在三条攻击路径：

第一条攻击路径：提取私钥、实施逆向工程，并通过移动网络中间人攻击操纵经过加密和签名的软件更新。“密钥提取” 威胁具有攻击可行性因素值r1，该值通过 “密钥的机密性” 安全目标传播至依赖于该安全目标的 “AES GCM” 控制措施，导致该控制措施被突破，因此攻击路径中未包含该控制措施的攻击可行性因素值。随后，攻击路径传播至 “（移动网络）中间人攻击” 威胁，该威胁具有攻击可行性因素值r7。通过 affmax [r1, r7]计算每个攻击可行性因素的最大值，再通过 afr [affmax [r1, r7]] 计算攻击可行性等级。要对目标安全目标 “更新功能的完整性” 构成威胁，需在 “CT1” 节点将具有攻击可行性因素值r8的 “逆向工程” 威胁与中间人威胁相结合，因此该攻击路径的总攻击可行性等级为 afr [affmax [r1, r7, r8]]。在该攻击路径的传播过程中，会累积所经过节点的标识符，且未涉及损害转换效应。

第二条攻击路径：突破 “AES GCM” 控制措施（并非通过提取密钥，例如利用密钥长度较短的缺陷进行暴力破解）、实施逆向工程，并通过移动网络中间人攻击操纵经过加密和签名的软件更新。该攻击路径的总攻击可行性等级为 afr [affmax [r5, r7, r8]]，未涉及损害转换效应，且所经过的节点标识符集合与第一条攻击路径不同。

第三条攻击路径：实施逆向工程，并操纵车辆内部 CAN 总线上的软件更新数据（该总线未采用加密措施）。在该攻击路径中，“仅允许改装” 这一假设会触发标识符为e17的 “DT1” 损害转换节点，将 “车辆失控” 损害场景转换为 “未授权改装” 损害场景。该转换效应传播至 “操纵 CAN 总线数据” 威胁，该威胁具有攻击可行性因素值r11。将其与 “逆向工程” 威胁的攻击可行性因素值相结合，得到总攻击可行性等级为 afr [affmax [r8, r11)]。该攻击路径的损害转换集合为e17。

根据每条攻击路径的攻击可行性等级，以及损害转换后各损害场景对应的损害程度，计算每条攻击路径的风险等级。对于上述三条攻击路径，风险等级计算如下：

此外，每条攻击路径的风险都会传播给该路径上的所有节点。每个节点的风险等级由其所有相关攻击路径中的最高风险值确定。

最后，结合每条攻击路径及其损害转换后的损害场景，计算相应的风险等级，即：

6. 结论

在国际法规的要求下，网络安全风险分析正成为众多领域开发过程中的强制性步骤。在汽车领域，新出台的联合国第 155 号法规已将其列为强制性要求。对于现代汽车等复杂系统，要实施必要的流程以进行系统性评估，是一项极具挑战性的任务。本文旨在通过一种经过验证的、基于模型的方法，解决如何实施此类流程的问题。

本文提出的模型结构与方法学相结合，为系统工程师和安全工程师共同开发和评估实例化模型提供了共同基础。为此，我们融合了系统属性和安全属性这两类表达能力有限但实践证明适用性良好的工件。

本文提出的元模型涵盖了由功能、数据元素、组件和数据流构成的待开发系统（SUD），并通过一组固定的关系将这些元素连接起来。我们对该元模型进行了扩展，纳入了网络安全风险评估（SRA）特有的元素（安全目标、威胁、控制措施和假设）以及额外的关系。由此，实现了待开发系统（SUD）及其安全属性在网络安全风险评估（SRA）语境下的一体化呈现。为充分考虑通常错综复杂的依赖关系和影响，我们引入了一套传播规则。因此，可通过追溯至待开发系统（SUD）的元素，对安全特定元素之间的关系进行验证。采用这种混合工件策略的一个必然结果是，安全建模需要重复或扩展功能建模的多个步骤（如创建用例图和流程图），而这一过程难以实现自动化。

与其他将待开发系统（SUD）元素和关系与安全特定元素和关系分开处理的方法不同，本文提供了一种一体化视角，使用户能够对风险等级以及威胁、控制措施和假设的影响进行合理评估。由于模型采用模块化结构，对模型进行局部或迭代修改时，通常无需对其他元素进行调整。这有助于提高分析的可维护性，减少后续更新或发现新问题时的工作量，并增强模型的可理解性。

为演示本文方法的有效性，我们通过一个小型虚拟实例进行了应用说明。目前，由于缺乏适用于分析质量的评估标准，尚无法对该方法的应用质量进行进一步量化衡量。制定此类评估标准是当前研究的重点课题，为此，我们计划对现有评估进行重新分析，以识别相关属性。然而，在过去 10 年中，我们已在与工业客户合作的项目中开展了数百次实际网络安全风险评估，积累了大量实践经验，为该方法的适用性提供了实证支持。这些网络安全风险评估涵盖车辆功能和电子控制单元（ECU）、工业组件、IT 系统以及物联网（IoT）设备的开发过程，我们根据自身经验和客户反馈，不断对该方法进行完善。

本文方法的局限性在于，生成的模型复杂度会不断增加，这就要求由安全专家来应用该方法。未来，仅依靠具有针对性的、特定场景的网络安全风险评估（SRA）将不再足够。为应对复杂的集成系统，需要能够在不同模型之间进行推理并同时对其进行评估，这就需要额外的方法支持。同样，为了获得最佳效果，还需要专业知识来根据企业需求调整评估模型和目录。此外，要提高模型的精确度，往往需要以增加模型复杂度为代价。

借助 Yakindu Security Analyst 等工具的支持，有助于这些模型的创建和维护。

本文提出的方法最初是为汽车领域的网络安全风险分析而开发的。