本发明涉及可信计算领域,特别是涉及一种软件安全需求获取系统及方法。
背景技术:
近年来,软件安全问题已经得到业界人士的足够重视,经济有效地开发安全软件成为当前的核心目标。在软件生命周期的需求分析阶段考虑软件安全性是开发安全软件最为经济有效的方法。
软件安全需求工程是软件安全工程的子过程,它的目标是收集对软件系统资产安全进行保护的需求。iso/iec15408(commoncriteria,简称cc)给出软件安全需求的定义是:安全功能应该明确的按照某种规则拒绝某些对象的访问。软件安全需求是由软件系统的安全属性决定,它能保证软件的安全开发,而且能帮助软件开发者以最小的开发和维护成本来实现系统必要的安全保护需求。一般来说,软件安全需求的获取包括如下步骤:识别风险资产、识别威胁,评估威胁对资产的影响、确立安全目标、提出安全需求、安全需求的检查和迭代精化。
目前,国内外学者对安全需求获取的研究主要集中在软件安全需求分析方法上,典型的安全需求分析方法主要包括:基于uml的安全需求分析方法;基于用例的安全需求分析方法;面向对象的安全需求分析方法;面向目标的安全需求分析方法;基于cc标准的安全需求分析方法等。
uml具有稳定且良好的扩展性,因此被很多学者应用到软件安全需求分析模型中。secureuml是一种典型的基于uml的安全需求分析方法,它对uml进行扩展来支持授权约束。该方法在分布式系统的安全开发中应用的较多。另外一种常见的基于uml的安全需求分析方法是j.jurjens等人提出的umlsec方法,该方法扩展了uml并将扩展后的uml与安全需求工程项结合,实现了通过uml模型的可视化辅助用户清楚地理解系统的安全规约。j.jurjens演示了在软件开发中使用umlsec表达软件安全需求的过程,并验证了方法的可行性。
误用例是一种基于用例的安全需求分析方法,该方法根据标识潜在的软件威胁来提取软件安全需求。用例能够准确地描述软件系统的功能性需求,但却不能较好地描述非功能性需求。但误用例恰好与用例相反,它主要描述有害用户的恶意行为。guttormsindre等人给出了误用例的组织形式和内容,并使用误用例图来定义系统的安全需求。pauli等人将误用例应用到软件架构设计中,用它标识并分析组件和连接器中的可能的安全关系。
面向对象的安全需求分析方法是将面向对象编程的概念和方法应用到软件需求建模中,它包括面向对象的图形语言机制和方法学。在面向方面编程的基础上,dianxiangxu等人从威胁和应对措施两方面入手,提出了一种基于用例驱动的获取功能需求和非功能性需求的面向对象方法。该方法提供了一种区分功能需求和非功能需求的方法。charles等人将信任作为安全需求分析过程中的前提,以此构建了信任模型来保障软件的安全开发。
anti-models、kaos、securityi*/tropos等方法是面向目标的安全需求分析方法。r.darimon等人提出的kaos方法是从why,who和when三个角度对目标进行安全需求抽取。axelvanlamsweerde通过分析系统安全问题及解决办法来确定系统安全目标,进而构建系统的安全需求模型。mylopoulos等人提出了tropos方法,该方法贯穿了软件开发生命周期的各阶段,它给出了安全需求在不同阶段的定义、设计及实现方法。
基于cc标准的安全需求分析方法是一种基于重用的安全需求分析方法,该方法借助于安全知识库来实现重用和需求抽取。安全知识库主要包括安全威胁、安全假设、组织安全策略和安全需求四类安全知识。danielmellado等人基于cc标准提出了统一软件安全需求开发流程(srep:securityrequirementsengineeringprocess),并构建了对应的安全知识库来辅助整个安全需求开发过程。
但由于软件安全需求自身的复杂性、多变性和不确定性,这些研究成果较难应用于实际的软件开发中。并且通过对目前安全需求工程的研究工作进行分析和总结,发现这些安全需求分析方法都能够有效地解决或避免安全需求分析中的一些问题,但它们的需求分析效果都存在不同程度地依赖安全专家经验问题,且灵活性较低,仍有许多可改进之处。安全需求工程能够极大的降低软件产品的安全开发和维护成本并提高软件的质量,但其还没引起业界的足够重视,也缺乏一个普适化、自动化和可复用性高的安全需求获取方法和工具。
技术实现要素:
鉴于目前已有的软件安全需求分析方法中存在的问题,本发明提出了一套基于安全需求模板的软件安全需求获取方法。针对软件安全需求多样化造成需求难以收集的问题,在已完成构建具有普适性的安全需求模板的基础上,构建了相应的安全需求知识库,实现了软件安全需求的获取。
本发明的一种基于安全需求模板的安全需求获取系统,该系统包括软件安全需求知识库和基于安全需求模板的安全需求获取框架;所述软件安全需求知识库包括七个子数据库,即:构建成安全功能组件问题的安全功能组件库、安全功能组件问题库、安全功能组件重分类库;构建成软件安全保护范围的软件安全保护范围库、系统操作库;构建成安全需求保护模板的需求条目库和安全需求条目模板库;所述基于安全需求模板的安全需求获取框架包含五层,分别是安全需求文档创建层、安全需求模板选择层、安全功能组件问题回答层、安全功能需求获取层和安全需求文档导出层;其中:
所述安全需求文档创建层创建一个空的安全需求文档,所属安全需求模板层根据软件系统的需求规格说明书为安全需求文档选择相应的安全需求模板;所述安全功能组件问题回答层根据软件系统的需求规格说明书回答每个安全需求模板中的安全功能组件问题并填写功能性描述部分;所述安全功能需求获取层根据安全功能组件问题的验证结果得到为保证该软件系统安全需要满足的安全功能组件及功能性需求;所述安全需求文档导出层导出包含软件系统功能性需求描述和相关安全功能组件的安全需求文档。
本发明的一种基于安全需求模板的安全需求获取方法,该方法包括以下步骤:
步骤1、创建一个空白的安全需求说明文档;
步骤2、根据系统的需求规格说明书中的条目,从安全需求模板库中选择相对应的安全需求模板;
步骤3、实现模板问题回答,该步骤具体包括:
根据系统的需求规格说明书中功能性需求的描述,填写安全需求文档中每个安全需求模板中的功能描述;根据系统的需求规格说明书中功能性需求描述,回答已创建安全需求文档中每个安全需求模板的问题;
步骤4、安全功能需求获取,该步骤具体包括:
以系统操作和保护范围为基础,根据用户在上一步回答的模板问题来构造安全操作序列;将构造的安全操作序列与安全功能组件的安全要求进行匹配验证,最终得到为保证系统安全所需的安全功能组件;;
步骤5、文档生成,该步骤具体包括:
根据上述所有内容,生成一套完整的系统安全需求文档,包含系统的功能性需求和为了保证系统安全所必需的安全功能组件。
所述安全功能组件匹配验证的步骤,进一步包括以下处理:
a、将构建好的多个安全操作序列分别与该安全功能组件对应的安全要求进行匹配,匹配算法采用正则表达式验证方法;
b、若匹配成功,则说明为保证该系统的安全不需要此安全功能组件,并继续验证下一条安全操作序列,直到所有的安全要求序列验证结束;若缺陷匹配不通过,则说明为保证该系统的安全需要此安全功能组件;
c、重复a和b,直到所有安全操作序列都验证完毕。
与现有技术相比,本发明达成如下预期的有益效果:
1、将安全功能组件验证技术引入到软件安全需求获取中,提高需求获取方法的自动化程度;
2、构建了一个较完整的安全需求知识库,实现了基于模板的软件安全需求获取。提高了cc标准的可用性,能够辅助用户自动生成安全需求说明文档;
3、通过这种安全需求获取方法,在软件需求分析阶段,软件工程师可在安全需求模板的基础上,及时获取到软件的安全需求,为软件后续阶段的安全性提供安全保障,并且提高软件开发的质量和效率,在保证软件安全性的同时,降低开发维护成本。
附图说明
图1为本发明的软件安全需求知识库总体结构图;
图2为本发明的基于软件安全需求模板的安全需求获取系统框架示意图;
图3为本发明的基于安全需求模板的安全需求获取方法流程示意图;
图4为本发明的安全功能组件验证流程。
具体实施方式
本发明的技术方案主要基于软件安全需求知识库和软件安全需求获取系统。
一、软件安全需求知识库的构建以cc标准为基准:
根据安全需求获取流程,软件安全需求知识库包括七个子数据库:构建成安全功能组件问题的安全功能组件库、安全功能组件问题库、安全功能组件重分类库;构建成软件安全保护范围的软件安全保护范围库、系统操作库;构建成安全需求保护模板的需求条目库和安全需求条目模板库。其中软件安全保护范围连接了安全功能组件重分类库、需求条目库。如图1所示,为本发明的软件安全需求知识库的总体结构。下面分别介绍七个子数据库的构建方式。
(一)、安全功能组件重分类库构建
安全功能组件重分类后打破了安全功能组件的“类-族-组件”的组织方式,变成了“类-组件”的树状结构组织方式。因此,安全功能组件重分类库是按“类-组件”的树状结构组织方式存储安全功能组件重分类的。部分安全功能组件重分类如表1所示。
表-1、安全功能组件重分类表
(二)、软件安全保护范围库
通过对安全功能组件的安全要求分析,本文整理出了一般软件系统涉及的安全保护范围。软件安全保护范围是按照“类-族-组件”的树状结构组织的,为了便于交由计算机处理,本文定义了软件安全保护范围的符号描述。部分软件安全保护范围如表2所示。
表2、软件安全保护范围表
主体保护范围,指开发者、使用者和管理者,或者其他特权用户。
客体保护范围,指除了主体保护范围以外的保护范围,包括构成系统的软件、硬件和数据等。
开发技术保护范围,指系统开发过程中所用到的资源和技术,包括系统架构、安全机制、数据库和编程语言等。
这些软件保护范围只作为一个框架,可根据不同类型系统的特点,对其继续进行扩充和完善。
(三)、系统操作库
系统操作是指一个简单的功能动作,如传输信息、审计、分发等操作。一个系统功能可由多个资产和多个行为组成。本文对安全功能组件的安全要求进行分析归纳,整理了一个多数系统通用的系统操作库,并定义了每个操作的符号表示。表3列出了部分系统操作表示。
(四)、安全功能组件库
cc标准第二部分提供了136个安全功能组件的安全要求,这些安全要求描述了安全功能组件的目标,即对系统中的保护范围的操作。所以,采用安全要求来安全功能组件,即一个或多个软件全保护范围及相应的系统操作。
为了便于安全功能组件的验证,定义了安全要求的逻辑表示。逻辑表达形式如下:
(1≤i≤m,1≤j≤n,1≤p≤p,1≤q≤q)
上表达式中,sfcm表示第m个安全功能组件的安全要求。a_termi表示第i个软件安全保护范围,m表示当前软件安全保护范围的总个数,attributej表示软件安全保护范围的第j个属性,n表示某个软件安全保护范围的属性的总个数。operationp表示第p个系统操作,p表示当前系统操作的总个数,parameterq表示系统操作的第q个属性,q表示某个系统操作的参数的总个数。所以,此逻辑表达式表示某个安全功能组件的安全要求是存在一个或多个软件安全保护范围及与其相关的一个或多个系统操作。
例如:安全功能组件fau_sar.3(可选审计查阅)的安全要求是tsf应根据具有逻辑关系的标准提供对审计数据进行搜索、分类和排序的能力]。从fau_sar.3的安全要求中可以看出,该安全功能组件涉及两个保护范围是审计数据a_audit_data和具有逻辑关系的标准a_logic_rule,对保护范围的操作有classify(x)、sort(x)和search(x),所以改安全功能组件可以表示为存在一个a_audit_data(x)和一个a_logic_rule(y),而且对a_audit_data(x)有三个操作:classify(x,y)、sort(x,y)和search(x,y)。逻辑表达式如下:
表4列出了部分安全功能组件及其安全要求。
表4、部分安全功能组件表
(五)、安全功能组件问题库
安全功能组件问题是针对是否满足安全功能组件的安全要求而提出的问题。通过对cc标准提供的136个安全功能组件的安全要求描述进行分析,得到了每个安全功能组件的组件问题。用户通过回答这些问题来确定系统是否满足该安全功能组件的安全要求,进而确定是否缺少该安全功能组件。如:安全功能组件fau_arp.1(安全告警)的安全要求是:当检测到潜在的安全侵害时,tsf应采取动作。从fau_arp.1的安全要求可知,tsf需要做两件事,首先要检测出潜在安全侵害,然后针对这个安全侵害采取相应的措施。所以,与fau_arp.1关联的安全功能组件问题是两个。即:
a、tsf是否能够检测到潜在的安全侵害?
b、tsf检测到潜在的安全侵害后是否能采取相应的防护动作?
属于同一个安全功能组件的多个安全功能组件问题是有顺序的,排在前面的组件问题是排在后面的组件问题发生的前提条件,因此,只有排在前面的组件问题被回答后才能够回答后面的组件问题。如:“tsf是否能够检测到潜在的安全侵害”是“tsf检测到潜在的安全侵害后是否能采取相应的防护动作”的前提条件,用户必须完成第一个组件问题的回答才能继续回答第二个组件问题。表5列出了部分安全功能组件问题及其关联安全功能组件。
表5、部分安全功能组件问题表
(六)、需求条目库
根据ieeestd830-1998和一些目前已经结束开发的系统的需求规格说明书,我们分析整理并细化了软件开发中一些普遍需要的需求条目。由于细化粒度不同,需求条目是按照“一级条目-二级条目-三级条目”的树状结构组织的,
表6、需求条目表
叶子结点条目的细化粒度最高,表示的需求条目内容最具体,所以本文中的需求条目指的是每棵需求条目树的叶子节点。为了便于交由计算机处理,本文定义了需求条目的符号表示。部分需求条目如表6所示。
(七)、安全需求条目模板库
为每条需求条目构建一个安全需求条目模板。安全需求条目模板由一系列安全功能组件问题和需求描述组成。
二、基于安全需求模板的安全需求获取系统
如图2所示,为本发明的基于安全需求模板的安全需求获取系统框架示意图,该系统包含五层,分别是安全需求文档创建层、安全需求模板选择层、安全功能组件问题回答层、安全功能需求获取层和安全需求文档导出层。
首先,创建一个空的安全需求文档;接着,根据软件系统的需求规格说明书为这个安全需求文档选择相应的安全需求模板;再次,根据软件系统的需求规格说明书回答每个安全需求模板中的安全功能组件问题并填写功能性描述部分;然后,根据安全功能组件问题的验证结果得到为保证该软件系统安全需要满足的安全功能组件及功能性需求;最后导出包含软件系统功能性需求描述和相关安全功能组件的安全需求文档。
三、基于安全需求模板的安全需求获取流程
如图3所示,以软件安全需求框架为依据,基于安全需求模板的安全需求获取最佳流程主要包含五步:
安全需求获取的主要流程为:
步骤1、文档创建:创建安全需求文档:系统开发者首先创建一个空白的安全需求说明文档;
步骤2、选择安全需求模板:开发者根据系统的需求规格说明书中的条目,从安全需求模板库中选择相对应的安全需求模板;
步骤3、模板问题回答,具体包括:
3-1、填写功能需求:根据系统的需求规格说明书中功能性需求的描述,填写安全需求文档中每个安全需求模板中的功能描述;
3-2、回答模板问题:根据系统的需求规格说明书中功能性需求描述,回答已创建安全需求文档中每个安全需求模板的问题;
步骤4、安全功能需求获取,具体包括:
4-1、构建安全操作序列:以系统操作和保护范围为基础,根据用户在上一步回答的模板问题来构造安全操作序列;
4-1、验证安全功能组件:将构造的安全操作序列与安全功能组件的安全要求进行匹配验证,最终得到为保证系统安全所需的安全功能组件;
步骤5、文档生成,具体包括:
根据上述所有内容,生成一套完整的系统安全需求文档,包含系统的功能性需求和为了保证系统安全所必需的安全功能组件。
如图3所示,为安全功能组件验证的流程示意图。在安全需求模板问题的回答结果以及安全需求知识库的支持下,验证得出为保证系统安全所必需的安全功能组件。
安全功能组件验证流程主要包括两步:
步骤11、构建安全操作序列:根据用户回答的每一个安全功能组件问题,安全需求获取方法会自动为其创建一个安全要求序列。同属于一个安全功能组件的安全功能组件问题的安全要求序列会被归为一类,以备接下来进行安全功能组件匹配;
下面以fau_sar.3(可选审计查阅)的两个安全问题的问答过程为基础给出安全操作序列的具体构造过程:
问题(1)、系统是否涉及待审计数据a_audit_data(x)?
答案----是,继续回答下面的问题
问题(2)、系统是否存在具有逻辑关系的标准a_logic_rule(y)?
答案----是,继续回答下面的问题
问题(3)、系统是否对审计数据a_audit_data(x)有根据a_logic_rule(y)的分类操作classify(x,y)?
答案----是,则在保护范围后加^classify(x,y)
答案----否,跳到下一项
问题(4)、系统是否对审计数据a_audit_data(x)有根据a_logic_rule(y)的排序操作sort(x,y)?
答案----是,则在保护范围后加^sort(x,y)
答案----否,跳到下一项
问题(5)、系统是否对审计数据a_audit_data(x)有根据a_logic_rule(y)的查询操作search(x,y)?
答案----是,则在保护范围后加^serch(x,y)
答案----否,跳到下一项
答案----否,结束此组安全功能组件问题
答案----否,结束此组安全功能组件问题
假定通过回答得知该系统中的某个功能涉及审计数据a_audit_data(x),针对审计数据有排序操作sort(x)和查询操作search(x)。那么构造的安全操作行为序列的逻辑表达式如下:
步骤12、安全功能组件匹配验证流程描述如下:
在构建的安全功能组件库中,每个组件的所有安全要求是安全功能组件匹配验证的关键特性。如图3所示,为安全功能组件匹配验证流程,主要分为以下三个步骤:
第一步:将构建好的多个安全操作序列分别与该安全功能组件对应的安全要求进行匹配,匹配算法采用正则表达式验证方法;
第二步:若匹配成功,则说明为保证该系统的安全不需要此安全功能组件,并继续验证下一条安全操作序列,直到所有的安全要求序列验证结束。若缺陷匹配不通过,则说明为保证该系统的安全需要此安全功能组件;
第三步:重复第二步和第三步,直到所有安全操作序列都验证完毕。
例如,将构建好的fau_sar.3的两条安全操作序列f1、f2分别与fau_sar.3的安全要求序列sfc1和sfc2进行安全功能组件匹配验证,结果如表7所示。
表7、安全功能组件验证结果
如:
安全功能组件fau_sar.3的第二条安全要求序列不满足,证明为保证此系统的安全需要fau_sar.3这个安全功能组件。