【AutoCS】在MBSE中使用SysML进行功能安全和网络安全联合评估

为了解决现代汽车系统日益复杂的问题，开发公司使用基于模型的系统工程(MBSE)。在MBSE过程中，需要选择和组合合适的建模方法。建模和仿真方法包括半形式化建模、软件生成、工程仿真和软件仿真。如今，即使是建模方法的选择、定制和接口也可以在框架方法中得到支持。在这种数字化开发流程背景下，本文讨论了如何使用SysML建模在MBSE早期阶段有效地支持开发人员开展功能安全和网络安全评估。并通过在软件平台嵌入式系统(SPES)框架内开发功能安全和网络安全分析概念，证明了该方法的可行性。该概念用元模型记录，并由SysML配置文件支持，后者在IBM Rational Rhapsody环境中扩展了SPES配置文件。网络安全分析配置文件支持在系统级别对开发人员进行评估，并遵守基于Microsoft STRIDE的漏洞修复以增强软件功能安全和网络安全(HEAVENS)模型的指导方针，该模型专门针对汽车开发。开发了基于SysML模型的原型，即SysML系统设计（包括其功能安全和网络安全评估），以在汽车MBSE试点项目中验证该方法。示例原型应用程序展示了该方法的可行性，并允许在符合SPES的环境中估计SysML支持的功能安全和网络安全评估对开发人员的工作量。主要结果包括重用和进一步开发面向SPES的SysML模型（例如上下文、场景、目标、功能）的可行性，这些模型旨在用于系统设计。在这些系统模型中实现了功能安全和网络安全相关模型的扩展和细化。细化和扩展产生了支持项目定义、危害和风险分析、功能安全概念和技术安全概念的功能安全相关模型。同样，网络安全相关的SysML模型有助于根据HEAVENS方法进行评估目标(TOE)描述、威胁分析和风险评估以及网络安全需求推导。通过使用帮助赋予这些扩展SysML模型的自动化功能增强了可用性。例如，帮助在模型中提供自动功能安全和网络安全参数确定（例如ASIL确定、安全级别推导）以及基于开发人员输入的过滤图形视图。它们与模型检查器一起帮助快速执行分析、一致性检查和评估工件的生成，例如风险及其控制的表格化概述。

系统工程方法在汽车领域的部署是由日益增长的复杂性、集成需求、复杂的供应链和日益增长的（功能）安全和网路安全需求推动的。基于模型的系统工程(MBSE)将系统建模作为系统工程流程的一部分，以支持正在开发的系统的分析、规范、设计、测试、验证和确认，例如V模型所要求的。这种方法的重要成果是开发一个连贯的共享系统数字模型。与基于（数字）文档的方法相比，这具有许多优势，包括改进规范、提高设计质量和一致性、设计和规范工件的可重用性以及开发团队之间更好的沟通。因此，一致性、可理解性和格式正确性等质量方面得到了增强。

系统建模语言(SysML)是一种通用的半形式化图形语言，用于在物理工程环境中对由硬件、软件、数据和其他元素组成的系统进行建模。它用于对需求、结构和行为以及相关参数进行建模，以提供对系统、其组件及其周围环境的描述。因此，SysML是实现MBSE方法的良好候选者。只有遵循结构良好的方法，才能有效使用SysML。此外，其应用方式需要适用于MBSE开发流程。特别是，要超越原理证明应用，例如功能安全。

当前基于模型的开发方法在实践中经常失效，主要是由于缺乏建模理论以及缺乏理论、方法和工具的整合。另一个问题是，工具链是根据现有的开发流程量身定制的，而不是根据最佳实践可用工具采用和更新的开发流程，尤其是在大公司中。从一个模型到另一个模型的过渡容易出错。这是因为应用的模型通常基于分离且不相关的建模理论。

嵌入式系统市场的竞争压力非常大，因此上市时间和开发成本是主要驱动因素。无法提供高质量的嵌入式系统可能会造成直接的财务后果或对人员的威胁。例如，福特和丰田的著名汽车召回事件。此外，物联网(IOT)方法、联网信息娱乐、无线网络中的汽车通信、远程更新和维护等为网络安全措施铺平了道路。

在功能安全和网络安全流程之间发现了许多相似之处。这种重叠可用于定义两个可靠性主题之间的可比流程和评估技术。然而，与(功能)安全流程相比，网络安全评估和生成流程不太成熟，特别是在(汽车)嵌入式领域，针对联合或类似建模方法的甚至更少。

汽车供应链中的一个典型场景是工程服务提供商，为原始设备制造商(OEM)工作，并提供动力系统、安全、车辆动态和信息娱乐系统以及这些系统的电气和电子集成的系统、功能和软件开发服务，这些系统的复杂性要求采用MBSE方法。此外，项目中的功能安全和网络安全需求至关重要。最相关的标准是用于汽车功能安全的ISO 26262、用于流程管理的ASPICE、ISO/IEC 33004、用于自动驾驶的预期功能安全(SOTIF) ISO/PAS 21448，以及网络安全标准ISO/PAS 21434等。然而，这些流程现在仍然严重依赖基于数字文档的方法，而且通常不是联合进行的。

在这种情况下，本文的目的是帮助功能安全和网络安全工程师在系统设计早期阶段在复杂的项目环境中进行评估工作。特别是，支持他们准备SysML工件，涵盖功能安全和网络安全风险评估、功能安全和网络安全需求确定，以及在分配开发严格程度方面选择相关方法。这是在设计概念层面实现的，用于以后的验证和确认。因此，本文解决了以下最佳实践研究空白：(i)如何将功能安全和网络安全分析集成到SPES等MBSE方法中？(ii)如何减少手动方法在可追溯性、完整性、部分自动化方面的系统开发工作量？(iii)与基于文档的方法相比，基于模型的方法如何帮助更有效地管理复杂的开发生命周期？(iv)如何使用半形式模型实质性地支持MBSE方法中功能安全和网络安全标准的实施的最佳实践？(v)如何验证该方法？

本文的结构如下。第2节展示了使用半形式化模型在汽车领域进行功能安全评估和网络安全评估的MBSE的主要差距。第3节描述了将汽车领域功能安全和网络安全评估中的不同流程映射到基于模型的方法和半形式化语言范式的分析工作。这些概念被记录为元模型。它还分别使用SysML元模型解释了进一步的方法规范并提示了基于标准的概念验证。第4节涉及该方法的实施及其原型验证。针对开发人员的功能安全和网络安全评估支持，测试了各种SysML图中使用的原型、标签、使用这些模型实现的自动化以及帮助程序和模型检查器应用程序。最后，在实施层面进行了讨论和评估。第5节提出了结论和展望。

如果不关注问题中心，即与实施相关的文档，则很难转向以需求驱动和以架构为中心的更有效的流程。为此，国际系统工程理事会(INCOSE)提出了基于ISO/IEC/IEEE 15288标准的MBSE方法。沿着这些思路，嵌入式系统软件平台(SPES)是一种基于模型的方法，旨在无缝集成不同的相关流程和模型。它专注于安全相关方面的建模，通过使用根据整体基于模型的开发(MBD)原则开发的分析模型将安全方面集成到开发流程及其模型中，旨在提高不同安全分析方法和技术之间的一致性和可追溯性。它有助于利用不同模型集成之间的协同作用。SPES中使用的主要概念是使用抽象层、视图和视点。正在开发的系统可以根据其结构重要性在不同的抽象级别上进行设计。视图和视点用于处理复杂工程流程中不同利益相关者的关注点。视图从一组相关的关注点和视点的角度表示整个系统，这些关注点和视点定义了如何使用视图。

在比较IBM Telelogic Harmony-SE、INCOSE面向对象系统工程方法(OOSEM)、IBM Rational统一系统工程流程(RUP SE)、Vitech MBSE及其扩展时，SPES是与Vitech MBSE一起涵盖属性框架、功能安全、SysML、模型仿真和集成的唯一方法。这表明了SPES方法的重要性。然而，列出的MBSE框架中没有一个涉及网络安全。其他维度可能是方法或工具的成本以及提及该方法的出版物数量，即科学接受度、用户接受度、形式校对水平等。

SPES 2020中尚未解决的研究差距包括质量方面，即可变性、早期工件验证等，这些是开发流程能够应用SPES框架的先决条件。SPES 2020方法的扩展版本称为SPES XT，专注于解决SPES 2020中的一些问题和挑战。SPES XT改进了软件和系统工程之间的集成、软件到硬件的最佳部署、早期验证和模块化安全保障。模块化安全保障基于开放安全模型。同样，SPES XT中也没有讨论网络安全方面。

已经使用SysML模型在不同抽象级别上评估了功能安全性。然而，通常不在MBSE上下文中，即不受(汽车)嵌入式领域的整体建模环境(如SPES)的框架限制。此外，很少有应用程序像目前的方法一样关注ISO 26262关于危害和风险分析(HARA)的概念阶段，而是关注使用SysML进行形式化可视化。

一般来说，与安全性相比，用于识别汽车E/E系统中安全漏洞的网络安全评估方法尚未完善。汽车领域的专用网络安全标准是相当新的标准ISO/PAS 21434。HEAVENS（修复漏洞以增强软件功能安全和网络安全）安全模型旨在提供一个框架来识别汽车领域复杂嵌入式系统中的安全需求。该模型主要基于其他非汽车行业（如电信、IT、国防和Web应用程序）使用的威胁分析和风险评估方法的最新进展而开发。

为了做出明智的选择，考虑应用领域、威胁覆盖范围、漏洞和风险评估，比较了不同的网络安全方法和与HEAVENS的依赖关系：通用标准(CC)、关键运行威胁、资产和漏洞评估(OCTAVE)、欧洲电信标准协会(ETSI)、开放式Web应用程序安全项目(OWASP)、Microsoft STRIDE、电子安全车辆入侵保护应用程序(EVITA)、SECTRA模型、通用漏洞评分系统(CVSS)和通用漏洞评分系统(CVSS)。对于威胁分析，选择STRIDE是因为它以通用的方式对威胁进行分类，并且适用于嵌入式汽车领域。

例如，EVITA中描述的特定威胁是STRIDE中威胁类别的子集。此外，STRIDE以威胁为中心，这意味着攻击的最终输出会得到突出显示，而不是关注特定攻击。攻击者利用这些漏洞进行威胁。这会给资产带来风险。威胁到漏洞的注入映射是不可行的，因为一个漏洞可能导致许多威胁，而一个威胁可以利用许多漏洞。通用标准(CC)和WIFF仅提供通用映射。HEAVENS的风险评估部分从威胁级别（代表攻击潜力）和影响级别（与风险的影响成分有关）得出安全级别。

对于刚刚列出的安全评估框架，可以比较不同方法中用于计算属性中威胁级别的参数。威胁级别参数主要与CC一致。在HAEVENS中，与CC相比，不考虑经过的时间，因为它使用了以下参数（类别）：专业知识、评估目标(TOE)知识、机会窗口和设备。也可以比较不同方法中用于计算影响级别的参数。成功攻击TOE的可能后果是考虑影响级别因素来确定的。HEAVENS使用的因素与OWASP和EVITA的业务影响因素类似，包括安全、财务、运营、隐私和立法。

总之，进一步审查的工作也暗示了SysML/UML扩展对于开发人员的系统网络安全评估的可行性和实用性，以及与功能安全相结合，以及作为汽车（嵌入式）系统开发概念阶段部分自动化评估的起点。然而，到目前为止，它们通常仅应用于网络、组织级别、物联网应用、工业控制系统(ICS)等其他领域，并专注于特定方法的应用，并且也没有嵌入MBSE框架中。

为了简洁的介绍和明确的说明，从现在开始，重点是根据SPES MBSE框架内的HEAVENS方法进行的SysML支持的网络安全评估，有关功能安全的类似方法。HEAVENS的网络安全评估可分为三个步骤，需要由系统开发人员覆盖和记录，见图1：

1. 威胁分析：TOE是分析的特征或主题。它针对STRIDE威胁进行分析。TOE或其依赖的功能用例以数据流图(DFD)表示。已识别的安全威胁被映射到资产。资产是数据流图中的实体，被分类为流程、数据流、数据存储或外部实体。映射是在威胁和安全属性之间完成的。

2. 风险评估：STRIDE威胁与资产、影响级别和威胁级别之间的映射用于确定安全级别。

3. 网络安全需求推导：考虑STRIDE威胁与资产与安全级别之间的映射，制定安全需求。

表1展示了STRIDE威胁与安全属性映射，同时也解释了首字母缩略词本身。

在STRIDE-per-element变体中，DFD中的每个元素都会针对STRIDE威胁进行评估。在STRIDE-per-interaction变体中，DFD中每个元素的交互都是威胁评估的基础。对于汽车领域应用，STRIDE-per-element变体优于STRIDE-per-interaction。表2列出了STRIDE-per-element与DFD元素的映射。

MBSE方法覆盖的HEAVENS的三个分析步骤（参见图1）可以用表1和表2来总结：

• 根据HEAVENS模型进行的网络安全评估使用Microsoft的STRIDE威胁模型。TOE的概念是评估的起点。它类似于ISO 26262中使用的项目。STRIDE中使用的威胁是网络安全中的安全对应物，类似于ISO 26262中使用的危害。

• HEAVENS方法执行威胁分析和风险评估(TARA)以得出安全级别，这些级别与汽车安全完整性等级(ASIL)相当。威胁分析是基于与TOE相关的功能用例的数据流图进行的。STRIDE威胁被分配给每个TOE的资产。威胁被映射到安全属性，这些属性也分配给资产。

• 影响级别和威胁是风险评估中用于得出安全级别的两个参数。网络安全需求被分配给资产。资产将映射到其相关的威胁和安全属性以及安全级别。被分配威胁、安全属性和安全级别的资产是与HEAVENS的网络安全需求相关的主要属性。

在当前的应用环境中，系统和软件开发由3层模型组成。较高层与上下文相关。这里的上下文代表项目和技术水平。下一级定义系统，第三层侧重于硬件(HW)和软件(SW)。这些级别映射到SPES中的抽象层，即上下文层、系统层和HW/SW层。在这三个抽象层中，开发了视点，即需求视点、功能视点、逻辑视点和技术视点。

除了将抽象层和视点与功能安全和网络安全属性相关的不同模型进行映射外，概念开发还结合了自动化。自动化是使用独立于抽象层和视点的帮助实现的。帮助是附加到模型以增强其功能的自定义程序。使用自定义检查实现的模型检查器是该方法的附加组件，该方法基于系统模型和系统开发人员的评估输入生成附加工件。一般来说，这种映射结构可用于所有项目。但每个层的功能安全或网络安全评估可能不需要所有四个视点。此类流程中的SysML支持提高了网络安全评估的工作效率。表3列出了SPES与HEAVENS阶段的映射。

接下来，SysML元模型用于表示SPES方法，也用于表示SPES目前向IT安全的扩展，允许开发人员在IBM Rhapsody等MBSE环境中使用它。图形/半形式化元建模使步骤和依赖关系更加透明。

图2和图3显示了系统开发人员应用的网络安全评估块定义图(BDD)元模型。图2显示了TOE 描述。TOE显示与SysML模型类型的类似关联，可用于项目的情况。同样，在网络安全评估的情况下，根据ISO 26262的目标模型被数据流模型取代。数据流模型具有聚合，包括SysML活动图(AD)、SysML块定义图(BDD)等。箭头和线条显示了开发人员可以使用的不同实体之间的关系。SysML元建模也有类似的图表类型用法。

图3显示了威胁分析和风险评估元模型。每个TOE都有资产的组成（即强聚合）。每个资产都有多个STRIDE类型的STRIDEThreat标签。资产通过应用构造型<<Process>>、<<DataFlow>>、<<DataFlowBlock>>、<<DataStore>>和<<ExternalEntity>>来概括。这些构造型在资产内创建了一个STRIDE威胁列表。<<CyberSecurityRequirement>>是SysML需求的概括。它分配给资产。

可以评估SysML元模型对HEAVENS网络安全方法的覆盖范围及其与系统模型的相关SysML图关联的能力，表明TOE描述已使用BDD、用例图(UCD)、AD和内部块定义图(IBD)和相关关联进行覆盖。威胁分析由构造型覆盖，这些构造型会在相应的模型元素（如块、对象流、参与者等）中生成标签。使用辅助程序进行风险评估，可以使用SysML需求图(RD)对网络安全需求进行建模，也可以通过以表格形式提取其信息。因此，确保了方法的完整性、可追溯性和可自动化性。

基于元模型的方法的实施和验证是通过原型设计完成的。本节包含与概念相关的SPES封装、相关模型、与原型模型相结合的自动化以及模型检查的讨论。它阐述了在试点系统工程项目中借助原型对概念的验证。它还讨论了对实施的定量评估。

SPES抽象层和视点（参见第2节）在图4中的SysML包图(PD)结构中可视化，以显示SysML模型在不同包中的组织。请注意，视图和视点是一起查看的模型的集合。这些模型或单个模型可以分布在多个抽象层中。

如第3节所述，集成SPES、HEAVENS、ISO 26262和SysML所需的各种模型包括上下文模型、场景模型、目标模型、需求模型、功能模型、结构模型、行为模型和数据流模型。请注意，前五个是SPES中的标准建模名称，而后三个是专门介绍的。每个模型都由第3节中介绍的SysML图表类型的适当组合组成。

在表4中，与SPES、ISO 26262和HEAVENS相关的模型元素的映射分布在不同的SPES抽象层和视点之间。

对于自动化和模型检查，IBM Rational Rhapsody以编程语言C++和Java提供应用程序外围接口(API)。第3节中介绍的帮助程序调用支持SysML模型的编程自动化脚本。在当前方法中，使用Rhapsody模型接口的Java API和模型检查器的Java接口在Eclipse IDE环境中使用Rhapsody软件开发工具包(SDK)实现自动化。

使用以下自动化概念：

1. 安全级别由开发人员为每个STRIDE威胁分配的影响级别和威胁级别自动确定。威胁级别和影响级别也根据其参数自动计算。与威胁相关的安全属性也映射到威胁。

2. 为了实现该方法，第三方模型检查器已扩展，自定义检查正在使用Java插件。第三方模型检查器包括一个自定义用户界面，用于显示检查及其结果。

3. 实施图表视图以图形方式隔离某些建模元素，以提高可读性并降低复杂性。

例如，将颜色变化应用于活动图中的图形元素，该活动图基于评估输入并可视化评估输入来显示技术安全概念。这有助于以图形方式区分正常功能和安全相关功能。请注意，此功能与图表视图不同。

使用并扩展博世工程有限公司开展的试点项目的基于SysML模型的原型来验证该方法。选择了系统故障指示灯(MIL)异质性及其功能，并在IBM Rhapsody环境中使用SysML进行开发和分析。它通过车辆的仪表盘指示感兴趣的发动机管理系统(SOI)中的故障。使用异质性一词是因为MIL系统指示由于外部或外部因素影响发动机而导致的发动机系统故障。例如，ESP（电子稳定程序）故障会导致更高的发动机排放量。MIL异质性通过集群指示此问题。

网络安全评估方法基于TOE描述，见图2。开发人员根据HEAVENS基于以下构造型对资产进行分类：<<Process>>适用于SysML块和泳道，<<DataStore>>适用于SysML块和泳道，<<DataFlow>>适用于活动图和泳道中的对象流，<<ExternalEntity>>应用于用例图中的参与者，<<DataFlowBlock>>是一个额外的构造型，与<<DataFlow>>具有相同的用途，但应用于块而不是对象流。

与刻板资产相关的STRIDE威胁被列为标签。威胁分析阶段由开发人员将构造型应用于图表元素启动，如图5所示。构造型使图表组件与网络安全相关，因此需要开发人员进一步评估。例如，在图5中，将构造型<< Process>>应用于块ESP。这是因为ESP象征着一个逻辑电子控制单元(ECU)系统，并且根据基于HEAVENS的数据流模型，这是一个流程元素。同样考虑网关：它与HEAVENS中数据流模型中的数据流元素相关。因此使用构造型<<DataFlowBlock>>。此类图表还可用于为网络安全相关元素着色。

这些图元素是与HEAVENS模型中的TOE关联的资产。这些构造型在Assets中以SysML标签的形式产生威胁。在图6（a）中，作为流程实体的资产ESP被映射到STRIDE威胁列表，见表1。映射到每个威胁的网络安全属性在threat中作为标签生成。同样，所有具有网络安全相关构造型的元素Process、DataFlow、ExternalEntity、DataStore和DataFlowBlock都会产生威胁。

更多说明见图6（b）。Threat1欺骗具有内部标签SecurityAttribute，其值设置为真实性和新鲜度，见表1。风险评估步骤涉及开发人员根据相关参数为威胁分配影响级别和威胁级别。风险评估的结果是得出威胁的安全级别。帮助“计算安全级别”根据开发人员的输入计算影响级别、威胁级别、安全级别，并将值分配给相应的标签，见图6（b）。

最后，图7的示例表视图屏幕截图给出了开发人员确定的网络安全需求、分配的资产、相关威胁、安全属性和安全级别的示例展望。

图8给出了模型检查应用的示例。网络安全评估相关检查如下。由于评估尚未完成，因此 Asset、SecurityLevel、SecurityAttribute、ThreatType为空的网络安全需求列在“Errors”下。SecurityLevel值为“Critical”的网络安全需求列在“Warnings”下。可以使用所示的类似程序和编程方法在功能安全和网络安全下实施任意数量的检查。这确保了第1节和第2节要求的完整性和文档。

大约使用30个图表来执行联合功能安全和网络安全评估。一些模型元素（如块、标签、需求等）不属于列出的图表的一部分，也参与实施：3个BDD、3个IBD、1个UCD、12个AD、2个RD、2个图表视图、8个表格视图、32个构造型和4个查询。SysML是在单个Rhapsody项目中建模的，该项目处理从系统开发、功能安全评估和网络安全评估开始的所有事项。请注意，通常以文档形式（通常在结构化表格中）提供的描述性信息（例如功能安全/网络安全档案）也可以在模型中使用描述字段、标签、属性和注释直接在图表中管理。另一方面，当然可以从使用功能安全和网络安全SysML扩展的原型模型生成此类汇总表，如上所述。因此，满足第1节中要求的MBSE需求。

检查表5中的工作量估计表明，对于现实世界的应用，可以假设根据SPES的MBSE SysML系统模型已经存在，开发人员对SysML支持的联合功能安全和网络安全评估的额外努力相当有限。

表5：各阶段实施工作量及应用估算（以小时为单位）

实施网络安全的优势如下：提出并实现了无缝工作流程，使用扩展的SysML模型、标签、原型和帮助，支持开发人员进行网络安全评估以及基于输入的自动化和模型检查器。系统开发人员在完成HEAVENS流程方面以形式化方式实现了对网络威胁的完整性评估。该方法使用SPES MBSE框架确保了系统开发所有层面的可追溯性。模型检查器和使用帮助的自动化增强了扩展SysML模型的可用性，并提高了其记录系统开发人员进行的HEAVENS评估过程的效率。功能安全方法已经形式化并以与网络安全评估流程类似的方式实施。该方法实施只需进行一次，因此具有可重用性。系统开发、功能安全和网络安全评估使用单一模型源并行进行。

该方法的缺点包括：存在通过单击威胁并输入评估来形式化进行功能安全和安全评估的危险。构造型会带来许多潜在威胁，用户需要小心消除不重要的威胁并识别相关威胁，更普遍的是，可能完全缺乏较新的威胁类型。该方法要求功能安全和网络安全专家至少具备中级SysML知识。实际系统SysML建模所需的所有有用SysML模型可能并未被考虑用来完全描述系统。

这项工作的主要实施成果包括支持SPES配置文件并与其一致的功能安全和网络安全配置文件，包括构造型、标签、模型元素、帮助、模型检查器等。使用这些成果的原型SysML图（原型的扩展SysML模型）也是最终产品。它们由不同层次和视点的基于SPES的模型组成。视觉范例用于表示项目中的功能安全和网络安全相关工件。例如，项目、TOE、资产、功能安全概念、网络安全需求等。

总之，与基于文档的方法相比，该方法在可追溯性、部分自动化和复杂项目场景管理方面，可以帮助功能安全、网络安全和系统工程师以更好的方式进行人工评估。此外，还研究了如何有效地使用SysML模型来支持汽车行业中的国际标准。

列出了一些未来范围和可行的扩展。直接的扩展包括：HEAVENS方法中的项目和威胁类别可以根据新的IT架构和不断变化的威胁形势（例如无线传感器网络）进行（适度）更新。在HEAVENS方法中的网络安全评估中，可以实施源自该方法中提出的高级需求的技术网络安全概念创建和应用。从SysML模型自动生成文档是可行的（例如，借助Rhapsody发布引擎接口）。可以允许额外的输入和网络威胁分类，包括对策。更复杂的扩展包括：确定使该方法成为一个学习系统的选项，包括向开发人员提出额外的潜在输入以及挑战人类的输入决策，例如通过要求其他使用该系统的专家的评估论点，或集成基于模型的攻击树（半自动生成）进行网络安全分析。