Improved Security Requirements Engineering using Knowledge Representation

使用知识表示的改进的安全需求工程

摘要

在本文中，我们为SysML-Sec框架引入了一个安全元模型，该模型是通过使用知识表示技术来显式表示安全问题而开发的，旨在改善安全需求工程流程。这种元模型可以指定本体概念，这些本体概念定义了通过SysML-Sec图引入的安全工件的语义。该元模型还可以表示将几个这样的概念联系在一起的关系。然后，使用此表示法来推理系统设计师和安全专家通过SysML-Secframework的图形环境引入的知识。除了其文档方面，这种元模型还可以引入不同类型的安全要求和威胁验证，尤其是有关所有图内容的一致性检查。我们最后提出了一个原型，该原型将元模型描述集成到SysML-Sec框架中，并使用语义Web技术对其进行了实现。

SysML，安全性，模型驱动的工程，知识表示。

1 介绍

围绕模型驱动工程（MDE）的大多数贡献现在都适用于设计安全，复杂，分布式和实时嵌入式系统的方法和建模环境。然而，长期以来，人们仅在回顾时才考虑过安全性，特别是在发现严重漏洞之后。我们设计了SysML-Sec框架[AR13]，该环境用于开发具有嵌入式系统组件的嵌入式系统或分布式IT系统，并特别关注其生命周期的长期工程设计。像大多数安全需求工程方法一样，SysML-Sec中的需求过程部分考虑（i）识别可能损害资产的威胁，以及（ii）引发源自应用程序或缓解这些威胁的需求。尽管如此，这两个阶段仍在概念和术语上受到混淆，这可能导致设计不充分的安全机制。同样，通常在需求工程流程中手动解决同一系统的多个视图之间的一致性。

为了解决这些问题，我们建议引入知识表示和管理技术，其他需求，工程方法。 这些技术与SysML-Sec [AR13]模型结合在一起，因此可以将它们集成到需求工程流程中。

2 基于知识的安全需求工程方法

本节描述了在安全性需求工程流程中使用本体概念的统一方法。 我们的目标是设计一种方法，通过利用其他活动中获得的知识来指导流程中的每个活动，从而扩展基于工具的工程流程。

2.1 元模型和安全需求工程方法

在过去的15年中，安全要求工程领域有明显的进步。 调查[NNY10，FGH + 10，MBSFM10]讨论了许多建议的方法。 Nhlabatsietal。 实例将宏按照四个维度进行分类，即：（1）基于目标的方法，（2）基于模型的方法，（3）面向问题的方法和（4）面向过程的方法。 我们认为，尽管这种分类是有用的，但它主要代表了同一安全需求工程过程的不同观点。 虽然从业人员采用单一观点较为简单，但将几种方法结合起来会有好处。

但是，大多数（如果不是全部）这些方法都受支持它们的特定建模语言和工具的约束。 这些语言和工具同时构成了实现这种努力的主要障碍。 使用元模型可以帮助提高安全性要求的工程设计能力，同时保留现有语言和工具作为需求输入和可视化的主要媒介。 元模型的可用性还使得可以通过引入元级推理功能来自动进行验证。 我们将在本文的其余部分中说明如何引入一个以知识为中心的元模型，并通过安全本体的定义来支持该模型，并将其集成到SysML-Sec平台中。 下一节将更详细地描述此元模型的目标。

2.2 元建模的目标

我们认为引入元模型是提高[AR13]中描述的安全性需求工程过程的完整性和正确性的重要贡献。 为了达到这些目标，请充分利用以下知识中心元模型的功能：

定义协议。 不同的利益相关者（系统工程师，风险专家，安全专家，验证和测试团队等）参与了系统设计和开发生命周期。 在给定的需求工程流程中，在一个公共知识库中指定IT安全性的术语和原理对安全性非常有益[ISO09a]。 安全性术语和对安全性标准的定义（例如，ISO / IEC 17799：2005，ISO / IEC 27002：2005等）可以帮助建立公共知识库，以弥合潜在的沟通障碍。

需求的启发。 除了定义安全概念外，元模型还描述了这些概念之间的关系。 这种关系可以用来改善需求的引发。 例如，IEEE 830标准建议照看八个特征，以实现良好的软件需求规范，其中四个（明确，正确，一致和完整）与需求规范的语义和文档有关。 概念之间的专业化/泛化关系以及专家精心设计的领域本体的使用，明显减少了歧义，提高了规范的正确性。 它还可以通过激发从业人员编写语义上更丰富的模型来为用例的形式化提供一些帮助。

一致性检查。 覆盖关系解决了完整性问题：例如，将目标与攻击（反目标）相关联，以按照KAOS的要求确定需求，从而确定所有威胁都已解决，或者相反，所有需求都解决了问题。 最后，概念和关系的语义网络的可用性使得可以检查概念的实例是否没有引入矛盾的语义，从而通过更复杂的推理来确保一致性。 这种推理也可能有助于解决安全性与安全性之间的矛盾[PCB13]。

需求优先级。 最初的一组需求可以组织为利益相关者定义的类别（例如，基本，非必要等）。 可以使用安全标准和规范来确定需求并将其与功能需求一起进行分类。 尽管如此，我们承认一个事实，即在对安全要求进行优先级排序时，某些要求可能被认为是不可行的。 安全需求通常会与其他系统需求（功能与否）发生冲突并相互作用。 例如，强制性安全要求可能与在合理的时间范围或预算范围内无法解决的问题相抵触。 在这种情况下，安全工程师可以选择明确记录需求的消除，或为将来的需求标记需求。

2.3 以知识为中心的元建模

尽管遵循不同的工作流程，但我们的元模型是由构成所有安全需求工程方法基础的核心概念组成的。 我们确定的主要伪像是：安全目标，安全攻击，系统模型（行为和结构）以及面向用例的模型。 因此，我们将这些工件以安全类的形式进行组织，以便可以轻松地共享和重用在安全需求工程流程的不同阶段生成的安全元数据。 每个类均以领域为中心的知识以知识为中心进行描述。 例如，与安全目标有关的元数据应可用于识别系统资产。 同样，此类元数据也应可用于分析安全攻击和漏洞。 图1总结了本体驱动的安全需求工程方法。

3 安全本体

我们在本节中定义上面讨论的安全本体。 他们使用OWL类与本体网络语言[DevH + 03]进行了建模。 核心概念是（1）安全目标，（2）系统体系结构，（3）安全攻击，（4）安全要求和（5）安全机制1。 每个安全本体构成一个知识库，用于捕获，分类和共享与安全相关的信息。 关于我们的目标，首先通过引入受控词汇来使用本体来组织和组织SysML-Sec工件。 我们安全本体的结构灵活且易于扩展，这使得无缝添加新概念成为可能。

3.1 攻击的本体

图2总结了我们对可以从知名安全标准（ISO / IEC 18045，ISO / IEC 27000：2012，ISO / IEC 17799：2005，NIST SP-800：30等）中摘录的概念的分析。 CVE，CAPEC，OWASP，CLASP等）以构建安全攻击本体。攻击类型表示尝试破坏，暴露，更改，禁用，窃取或获得未经授权的访问以未经授权使用系统资产[ISO09b]。攻击类型定义的抽象级别来自于例如NIST SP 800-30（[NIS12]，第3.2节）。然后，将攻击类型分类为“威胁和漏洞”子类：威胁是“意外事件的潜在原因，可能导致对系统或组织的伤害”；漏洞是“软件中的错误，黑客可以直接使用该错误来访问系统或网络” [CVE]。攻击后果是指安全漏洞的影响或结果，不是有目的的系统操作所预期的结果。攻击的后果分为篡夺，破坏，欺骗，泄露等。对手是根据ISO / IEC 21827：2008标准（[ISO08]，第3.35节）的威胁代理，它试图攻击具有以下内容的系统资产：对利益相关者的价值。对手的范围可能从非常熟练的个人到专家组。为了预测和阻止预期的攻击类型，必须对敌人的观点，其能力和对攻击潜力的专门知识有深刻的了解。可以考虑不同的攻击目标和相应的对手配置文件。攻击方法与攻击模式类有关。攻击方法可以分为逻辑方法或物理方法。攻击分类类的定义是为了对攻击及其目的的描述进行精确分类和系统地汇总。可以使用包括安全词典（即CVE，CAPEC，OWASP，CLAP）在内的一系列标准来确定和聚类安全攻击和漏洞。但是，从最抽象的层面上讲，我们可以将安全攻击分为针对语言和执行环境的通用攻击，以及针对特定领域的攻击。

3.2 安全需求的本体

安全需求的本体论集中于在安全要求规范（例如KAOS，UMLsec或TTool）和安全标准中定义的不同结构和概念。 该本体论旨在检测缺少的安全性，以构造安全性需求框架并丰富其语义。 为安全需求本体确定的核心类和概念是功能安全需求，非功能安全需求，分类（例如，通用的，与域相关的），规范（正式的，半正式的，非正式的），假设（例如，相关的）。 贸易和角色（涉及需求的定义的个人和/或团队）。 我们还包括Relationship类，该类描述SysML-Sec关系，如定义，派生，复制，包含，验证和跟踪。 安全要求的本体论也使得将传统的安全目标（例如机密性或完整性）描述为重要概念成为可能。

4 将知识库和推理集成到SysML-Sec中

从语法上讲，SysML和本体语言（即OWL，OIL等）有很多相似之处。 SysML使用图形形式主义时，其目的还在于使用诸如块，关联，零件属性以及模型元素与模型元素之间的关系之类的结构来定义系统的语义。 本体语言使用类，属性，关系和个人作为基础知识的构造。 例如，OWL通过对子类和概念的属性进行适当和隐式的逻辑约束来定义类。 两种方法的集成使工程师能够将推理参数添加到系统模型的显式文档中，并在典型的基于模型的开发过程中定义更精确的关系。 下面我们讨论如何使用本体论和本体论推断来丰富SysML-Sec框架。

4.1 SysML图和本体概念

我们将从本体中引入安全概念的原型原型化为SysML-Sec模型。 SysML-Sec图首先用本体论概念注释，从而在SysML原型或关系与OWL类和关系之间建立映射。 其次，通过使用由本体定义的受控词汇表代替自由文本，还扩展了许多属性。 例如，安全需求和安全攻击本体可以分别用于精确化安全需求和攻击树图的语义。

例如，图3描述了这两种方法对SysML-Sec建模功能的扩展。 我们已经定义了<< Attack >>刻板印象，以在“ part”元素中表示本体的安全攻击概念。 （a）中所示的“ part”元素的属性是（b）中所示的安全攻击本体中定义的概念和术语。 安全攻击的本体中定义的不同类被映射到相应的属性名称。 与一个这样的类的实例相关联的本体类的实例可以用于进一步标记SysML-Sec图，特别是通过SysML-Sec块的属性。 例如，在这里，我们使用受控词汇表，将对手描述为外行，专家或专业攻击者。

4.2 SysMLsec模型的推理

本体可用于推理SysML-Sec模型中定义的安全性概念。 特别是，我们的目标是使安全工程师能够访问各种本体论概念及其关系，并能够根据此类语义图进行推理。 因此，这些功能的集成依赖于引入转换引擎来桥接这两种方法，如图4所示。我们对这种系统进行了原型设计，以便对攻击范围和安全目标进行一致性检查，如SysML中所定义。 -分别为参数图和需求图。 一旦翻译引擎从SysML-Sec图的内容中创建了类实例，这些检查就可以写为SPARQL查询。

5 相关工作

已经在各种安全工程环境中开发了本体，特别是：用于解释威胁和安全机制[ALRL04]，用于风险评估[EFKW07]，安全管理[TG06]，安全协议设计[KLK05]，策略配置[BSL + 11]以及安全性要求[KBD + 06] [HLMN08]等。它们也已用于发现安全标准[VFZL10]中的差异和不完整性。长时间以来，一直在研究使用本体来精确表达需求[LFB96]。建立规范或文档似乎是最常评估的本体应用程序[GKM09]。 [SBO07]指出，本体还为概念和不同安全工件之间的关系带来了清晰的语义。迄今为止，使用本体检查需求一致性及其可追溯性可能是最受关注的领域之一[STZ + 11] [LFB96]。 Siegemund等。例如，[STZ + 11]描述了如何通过结合本体一致性检查和规则驱动的完整性检查来检查面向目标的需求规范的一致性和完整性。同样，林等。 [LFB96]描述了一种本体驱动的解决方案，用于生成明确，准确的需求规范，该规范可以轻松扩展并支持需求之间的依存关系。 Cranefield [Cra01]描述了使用本体论推理从UML模型中提取知识。本体还可以用于与其他与需求相关的模型共享和重用与需求相关的知识[DRR + 05]。最近，将推理和本体论概念集成到SysML中已成为需求工程领域[Gra09，WBK + 12]的热门话题。

6 总结和未来工作

将知识表示技术（特别是本体）集成到模型驱动的工程工具中，可能会提高我们捕获的规范的准确性和细节，尤其是在安全需求工程领域。集成这些技术的重要结果将是能够捕获关于本体概念和关系的推论的能力，即推理知识的能力。这项功能打开了自动检查规范的一致性和完整性的大门，直到今天。我们基于OWL语言实现了这种系统的概念验证原型。我们还预见了通过实施元模型知识推断规则最终表达安全系统设计最佳实践规范的可能性。尽管我们的工具和方法论[AR13]专用于嵌入式系统，并专注于硬件/软件映射问题，但我们提出的将知识表示技术与需求工程流程集成在一起的建议很可能适用于更通用的系统体系结构，例如面向服务的体系结构。我们目前正在开发原型，以更有效地将其集成到SysML-Sec框架中，以便进一步试验其功能。