CN104881606A - 基于形式化建模的软件安全需求获取方法 - Google Patents

Abstract

本发明公开了一种基于形式化建模的软件安全需求获取方法，包括功能需求获取、安全环境分析、安全目的分析、安全要求导出以及最终生成系统安全需求文档，该文档至少包含系统资产、行为序列、缺陷、威胁、安全策略、安全假设、安全目的、安全需求等级、安全保证等级、安全功能组件和安全保证组件的信息。与现有技术相比，实现了软件安全需求的自动获取，同时大大提高了安全需求获取的精确度；解决了自然语言描述的安全知识库存在模糊性和二义性，以及不能交由计算机处理的问题，为软件安全需求的自动导出奠定了基础；是典型的软件安全需求获取方法，适用于不同类型的软件系统，具有较强的普适性。

Description

基于形式化建模的软件安全需求获取方法

技术领域

本发明涉及软件安全技术领域，特别是涉及一种软件安全需求的获取技术。

背景技术

随着计算机的广泛应用，软件和信息系统已经渗透到各行各业，且在信息社会扮演着一个重要的角色。然而在软件的整个生命周期中，软件安全问题却带来高维护成本，这些持续增加的运营成本要求组织仔细考虑他们如何解决软件安全问题。

软件安全需求工程能够极大地提高被开发软件的质量，降低开发和维护的成本，但其还没引起业界的足够重视，也缺乏综合考虑软件资产、软件缺陷、安全目标、威胁分析和风险评估等多个要素的工程框架和自动化方法。国际安全标准ISO/IEC15408(CC标准)的出现，给全世界信息安全产品的开发和评估指引了道路，然而，其规范程度和易用性并不尽如人意，由于其非常庞大，涉及的面非常广，要完全理解其内涵，对于一般用户来说相当困难，只适用于安全专家。因此，开发一个更智能化、自动化、评估难度更低的安全需求获取方法势在必行。

发明内容

基于上述本领域的现有技术，本发明提出了一种基于形式化建模的软件安全需求获取方法，根据安全需求工程理论及相关技术，从安全标准、需求过程以及形式化验证的角度，以安全知识库为基础，建立了一套软件安全需求获取方法，并提出了一种缺陷形式化表述方法以及缺陷自动检测技术，实现了软件安全需求的自动获取。

本发明提出了一种基于形式化建模的软件安全需求获取方法，以国际安全标准ISO/IEC 15408(CC标准)为指导，参照包括CWE、CAPEC在内的多种国际通用漏洞、威胁信息库，采用形式化语言对系统资产、行为和缺陷进行描述，建立了一套完整的安全知识库，然后以此安全知识为基础，建立了一套软件安全需求自动获取方法，该方法包括以下步骤：

首先在资产库中选取所涉及到的资产；

以资产为起点构建系统行为序列，行为序列中的行为从行为库中选取；

进行安全环境分析，包括缺陷匹配、威胁确认、组织安全策略和安全假设；所述缺陷匹配的处理具体包括将构建好的行为串与各缺陷的匹配要求进行匹配，若匹配成功则验证该缺陷的安全约束即是否存在此类缺陷；所述威胁确认的处理具体包括根据缺陷与威胁的映射关系自动获取到系统中存在的威胁，并进一步对这些威胁进行确认；所述组织安全策略的处理具体包括从安全策略库中选取安全策略；所述安全假设的处理具体包括从安全假设库中选取安全假设；

进行安全目的分析，包括导出安全目的、安全需求等级和安全保证等级；所述导出安全目的的处理具体包括根据上一步骤得到的系统中存在的威胁、组织安全策略、安全假设，通过这三者与安全目的的关联关系，获取系统安全目的；所述安全需求等级的处理具体包括根据系统的性质选定系统种类，并根据系统对安全性的要求评定系统安全需求等级，根据第三章的三维安全需求等级规则表，获得该系统在各安全特性下的安全需求等级；所述安全保证等级的处理具体包括确定系统安全保证等级；

进行安全要求导出，包括功能组件确认和保证组件确认；所述功能组件确认的处理具体包括根据安全目的、安全假设和组织安全策略三者与安全功能组件的映射关系获得该系统所需的安全功能组件，再验证这些筛选到的组件是否符合系统各安全特性的等级，将不符合的组件去除，从而得到该系统所需的安全功能组件；所述保证组件确认的处理具体包括根据安全目的与安全保证组件，安全保证等级与安全保证组件的关系，筛选得到该系统所需的安全保证组件；

生成系统安全需求文档，该文档至少包含系统资产、行为序列、缺陷、威胁、安全策略、安全假设、安全目的、安全需求等级、安全保证等级、安全功能组件和安全保证组件的信息。

与现有技术相比，本发明达到了以下预期的有益效果：

1、实现了软件安全需求的自动获取，同时大大提高了安全需求获取的精确度；

2、解决了自然语言描述的知识库存在模糊性和二义性，以及不能交由计算机处理的问题，为软件安全需求的自动导出奠定了基础；

3、是典型的软件安全需求获取方法，适用于不同类型的软件系统，具有较强的普适性。

附图说明

图1为本发明的基于形式化建模的软件安全需求知识库结构示意图；

图2为本发明的基于形式化的安全需求获取方法流程图。

具体实施方式

下面结合附图和具体实施方式对本发明进行详细说明，但本发明的实施范围并不局限于此。

本发明以CWE、CAPEC等多种国际通用漏洞、威胁信息库为基础，采用形式化语言对系统资产、行为和缺陷进行描述，建立了一套综合资产、系统行为、缺陷、威胁、安全目标、安全策略、安全假设、安全需求等级、安全保证等级、安全功能需求和安全保证需求的安全知识库。

本发明主要有三部分，首先是在知识库中增加系统行为子库，构造各子库之间的映射关系，同时对资产、缺陷和系统行为进行形式化，得到基于形式化建模的软件安全需求知识库；然后以形式化建模的软件安全需求知识库为基础，提出了一种缺陷自动检测技术；最后以前两部分工作为基础，建立了一套软件安全需求获取方 法，实现了软件安全需求的自动获取。

下面分别详细描述三部分。

一、构建基于形式化建模的软件安全需求知识库

以CC标准为基准，在实验室前期针对软件需求阶段构建的安全知识库的基础上，继续对其进行扩充和完善，采用形式化语言对系统资产、行为和缺陷进行描述，建立了一套综合资产、系统行为、缺陷、威胁、安全目标、安全策略、安全假设、安全需求等级、安全保证等级、安全功能需求和安全保证需求的安全知识库，解决了自然语言描述的知识库存在模糊性和二义性，以及不能交由计算机进行处理的问题，为软件安全需求的自动获取奠定了基础。

如图1所示，基于形式化建模的软件安全需求知识库的结构示意图，分为五个部分：功能需求、安全环境、安全目的、安全要求和安全等级。下面详细介绍各知识库的定义及对资产、行为和缺陷的形式化表示方式，并构建了各个库之间的映射关系。

1、资产库：资产即软件系统中需要保护的、有价值的各类资源，以及在软件开发过程中所采用的各项技术等。本节根据实验室前期对软件资产的定义，通过对大量软件系统进行分析，在原来的基础上对资产进行扩充，并用形式化语言对各资产进行定义。主要资产分类如表1所示。

表1 软件资产分类表

主体资产：主要指人，是数据、资源的开发者、使用者和管理者，也可按照角色划分为普通用户和特权用户。

客体资产：是指被控制或被管理的对象，包括构成系统的软件、硬件、数据及通信资源等。

软件：软件或信息系统正常运行所需依托的各类软件资源，如操作系统、通信 协议等。

硬件：软件或信息系统运行过程中所用到或产生的各种数据。如输入/输出数据、系统数据、用户数据等。

数据：软件系统运行过程中所需或产生的各种数据。如普通用户数据、敏感数据、秘钥等。

开发技术资产:是软件系统在开发过程中所用到的各种资源和技术，包括：基本架构、数据库系统、编程语言和安全机制等。

运行环境资产：是主体资产和客体资产所处内部和外部环境要素的集合，这些环境要素将对软件或信息系统产生影响。例如：设备内部和外部的电磁泄漏和抗电磁冲击、系统设备完整性和可用性的破坏、以及对各类主体的假冒攻击。

此软件分类仅仅作为一个框架，可根据各类型软件系统的特点，对其继续进行扩充和完善。

2、行为库：系统行为是系统的功能单元，即一个简单的功能操作，如发送信息、加密、存储数据、对数据进行修改等操作。系统的一个功能可由多个资产和多个行为组成。本节对各系统通用功能进行总结和归纳，形成一个可供大部分系统所共用的一个系统行为知识库，并对各个行为用形式化语言进行描述。表2列出了部分行为的定义及其形式化表示。

表2 系统行为表

3、缺陷库：软件缺陷为计算机软件或程序中存在破坏系统正常运行的错误和问题。IEEE729-198对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现 的某种功能的失效或违背。

通用缺陷列表(Common Weakness Enumeration，CWE)是一个国际通用缺陷库，是已经在软件系统中发现的缺陷的在线词典。CWE目前由麦特公司(MITRE Corporation)维护。CWE缺陷库中提供了软件需求、设计、实现阶段的各种缺陷。但是目前，各大知识库对软件需求阶段缺陷的描述，都仅限于文字性，缺乏对缺陷的规范化描述。由于自然语言描述的缺陷存在模糊性和二义性，并且不能交由计算机进行处理等问题，本文通过对CWE中缺陷的引入阶段、产生原因和危害程度等属性的分析，定义缺陷的安全约束和缺陷本身的形式化表示方式，为缺陷的自动化检测提供依据。

通过对CWE中需求阶段缺陷的引入阶段、产生原因、诱发场景等因素的分析，从匹配要求，安全约束和缺陷形式化描述三个方面来构建形式化缺陷库。这三个概念的定义如下：

匹配要求(Matching Requirement,MR)：为进行缺陷匹配的前提条件，只有满足此条件，才会进一步验证系统是否存在此缺陷。

安全约束(Security Constraint,SC)：是指软件系统中避免某一缺陷的出现，所应该有的行为序列，即与安全缺陷的形式化描述相反。

缺陷形式化描述(Software Weakness,SW)：采用形式化的语言，通过分析缺陷的特性，将文字性描述转变成可被计算机处理，验证的形式化缺陷描述，即采用形式化资产库和系统行为库构建违反此缺陷安全约束的行为序列，

下面通过几个实例来表述形式化缺陷的分析过程。

CWE-311:Missing Encryption of Sensitive Data敏感数据未加密

假设s_data为敏感数据 

匹配要求： 

${\mathrm{MR}}_{\mathrm{cwe}311}=\{\∃A\_\mathrm{SENSITIVE}\_\mathrm{DATA}\left(x\right)\}$

安全约束： 

SC_cwe311＝＜A_SENSATIVE_DATA(s_data),ENCRYPT(s_data,level,a lgorithm.A_KEY(y))＞

缺陷形式化表示：

SDF_cwe311＝＜A_SENSATIVE_DATA(s_data),ENCRYPT(s_data,level,algorithm.A_KEY(y))＞

关联威胁： 

T.Sensitive Information Disclosure by Transmit数据交换中敏感信息泄露

T.Sensitive Information Disclosure through Storage存储数据中敏感信息泄露

CWE-311表示系统未对敏感数据进行加密操作。安全约束和缺陷形式化表示均是由形式化资产库和缺陷库组成的。此缺陷的匹配要求为系统中存在敏感数据，即 安全约束为若系统中存在敏感数据，则必须对其进行加密，加密的形式化表示方式为ENCRYPT(s_data,level,algorithm.A_KEY(key))，参照表4-2，其中s_data为需加密的敏感数据，level为加密等级，algorithm为加密算法，key为秘钥，这些变量需在构建系统行为串的时候进行定义；缺陷的形式化描述方式与安全约束相反，表示系统中存在敏感数据，但未对其进行加密操作，则系统存在此CWE-311缺陷。符号的意思是非、没有、不存在；关联威胁即为此缺陷会导致哪些威胁的发生，与威胁库建立了关系。

威胁库、安全假设库、安全策略库、安全目的库、安全功能组件库、安全保证组件库、安全需求等级库、安全保证等级库为已有成果，不在这里赘述。

二、提出缺陷自动检测技术

下面详细说明基于形式化建模与验证的缺陷自动检测方法。该方法包含三步：

1、选取资产 

用户根据被开发系统的功能需求，确定系统资产，如一个网盘系统，它涉及使用该网盘系统的用户，涉及一些用户的私密信息，如用户名密码以及用户不希望其他人看到的文件等，因此选取资产用户A_USER和敏感信息A_SENSITIVE_DATA；

2、构建行为序列

获得了系统资产后，需要根据功能规格说明书确定系统的行为。通过将选取的资产与行为单元进行搭配，构建系统行为序列(一个系统可包含多个行为序列)。系统采取问答的形式与用户进行沟通，辅助用户行为序列的构建。每一条行为序列的起始元素为某些资产(一个或多个)。如网盘系统中涉及用户和敏感信息，这些敏感信息不希望其他未授权用户去访问，因此当系统资产同时存在A_USER和A_SENSITIVE_DATA才会要求用户回答“是否对用户添加访问权限控制？”，来构建用户认证行为的行为序列。以下是一个以问答形式构建行为序列的具体例子：

以资产A_USER和A_SENSITIVE_DATA为行为序列起点通过问答的形式进行构建：

系统是否涉及敏感数据s_data的加密动作？ 

--是，则在资产后加ENCRYPT(s_data,level,algorithm)

对敏感数据s_data加密的加密等级是？

--填写level项

对敏感数据s_data加密的加密算法是？

--填写algorithm项

--否，跳到下一项

系统是否涉及对敏感数据s_data的存储动作？ 

--是，行为串后加STORE(s_data)

--否，跳到下一项

系统是否涉及对系统中存储的敏感数据的认证动作？

--是，行为串后加AUTHEN(s_data,user,authen_level)

对敏感数据的认证等级为？

等级划分如下，请用户根据系统设计情况进行选择：

1：简单的密码认证；

2：秘钥认证； 

3：秘钥认证+数字证书； 

4:秘钥认证+数字证书+认证设备

--用户选取认证等级

系统是否对认证过程中的最大认证次数进行限制？

--是，填写最大认证次数

--否，跳到下一项

--否，跳到下一项

系统是否涉及对敏感数据s_data的传输动作？ 

--是，TRANSMIT(s_data)

--否，跳到下一项

假定通过选择系统的行为序列如下：

<A_SENSATIVE_DATA(s_data)，A_USER(user),ENCRYPT(s_data,level,MD4.A_KEY(y)),STORE(s_data),AUTHEN(s_data,user,2),AUTHEN_ATTEMPT_NUM(3),TRANSMIT(s_data)> 

3、缺陷匹配 

在4.2.1节中构建的形式化缺陷库中，各缺陷的匹配要求和安全约束为缺陷匹配模块的两个关键特性。缺陷匹配主要分为以下三个步骤：

第一步：将构建好的多个行为序列分别与每个缺陷的匹配要求进行匹配，匹配算法采用正则表达式验证方法；

第二步：若匹配成功，则验证该缺陷的安全约束，若违反此安全约束则系统存在此缺陷。若缺陷匹配要求不通过或匹配要求通过且安全约束也通过，则系统不存在此缺陷；

第三步：重复第二步和第三步，直到所有缺陷都验证完毕。

三、提出基于形式化建模的软件安全需求获取方法

本部分以形式化建模的安全知识库及缺陷自动检测技术为基础，建立了一套软件安全需求获取方法，，实现了软件安全需求的自动获取。软件安全需求获取流程具体步骤如下：

1、功能需求获取

资产识别：系统开发者首先在资产库中选取系统中所涉及到的资产；

行为分析：开发者根据系统的功能需求，以资产为起点构建系统行为序列，行为序列中的行为从行为库中选取；

2、安全环境分析

1)缺陷匹配：首先将构建好的行为串与各缺陷的匹配要求进行匹配，若匹配成功则验证该缺陷的安全约束，即该系统是否存在此类缺陷；

2)威胁确认：根据缺陷与威胁的映射关系自动获取到系统中存在的威胁，开发者进一步对这些威胁进行确认；

3)组织安全策略；系统开发者从安全策略库中选取安全策略；

4)安全假设；系统开发者从安全假设库中选取安全假设；

3、安全目的分析

1)导出安全目的：根据上一步得到的系统威胁、组织安全策略、安全假设，通过这三者与安全目的的关联关系，获取系统安全目的；

2)安全需求等级：开发者根据系统的性质选定系统种类，并根据系统对安全性的要求评定系统安全需求等级，根据第三章的三维安全需求等级规则表，获得该系统在各安全特性下的安全需求等级；

3)安全保证等级：确定系统安全保证等级(EAL)；

4、安全要求导出

1)功能组件确认：根据安全目的、安全假设和组织安全策略三者与安全功能组件的映射关系获得该系统所需的安全功能组件，再验证这些筛选到的组件是否符合系统各安全特性的等级，将不符合的组件去除，从而得到该系统所需的安全功能组件；

2)保证组件确认：根据安全目的与安全保证组件，安全保证等级与安全保证组件的关系，筛选得到该系统所需的安全保证组件；

5、文档生成 

根据上述所有内容，生成一套完整的系统安全需求文档，包含系统资产、行为序列、缺陷、威胁、安全策略、安全假设、安全目的、安全需求等级、安全保证等级、安全功能组件和安全保证组件的信息。

Claims (1)

1.一种基于形式化建模的软件安全需求获取方法，其特征在于，以国际安全标准ISO/IEC 15408(CC标准)为指导，参照包括CWE、CAPEC在内的多种国际通用漏洞、威胁信息库，采用形式化语言对系统资产、行为和缺陷进行描述，建立了一套完整的安全知识库，然后以此安全知识为基础，建立了一套软件安全需求自动获取方法，该方法包括以下步骤：

首先在资产库中选取所涉及到的资产；

以资产为起点构建系统行为序列，行为序列中的行为从行为库中选取；

进行安全环境分析，包括缺陷匹配、威胁确认、组织安全策略和安全假设；所述缺陷匹配的处理具体包括将构建好的行为串与各缺陷的匹配要求进行匹配，若匹配成功则验证该缺陷的安全约束即是否存在此类缺陷；所述威胁确认的处理具体包括根据缺陷与威胁的映射关系自动获取到系统中存在的威胁，并进一步对这些威胁进行确认；所述组织安全策略的处理具体包括从安全策略库中选取安全策略；所述安全假设的处理具体包括从安全假设库中选取安全假设；

进行安全目的分析，包括导出安全目的、安全需求等级和安全保证等级；所述导出安全目的的处理具体包括根据上一步骤得到的系统中存在的威胁、组织安全策略、安全假设，通过这三者与安全目的的关联关系，获取系统安全目的；所述安全需求等级的处理具体包括根据系统的性质选定系统种类，并根据系统对安全性的要求评定系统安全需求等级，根据第三章的三维安全需求等级规则表，获得该系统在各安全特性下的安全需求等级；所述安全保证等级的处理具体包括确定系统安全保证等级；

进行安全要求导出，包括功能组件确认和保证组件确认；所述功能组件确认的处理具体包括根据安全目的、安全假设和组织安全策略三者与安全功能组件的映射关系获得该系统所需的安全功能组件，再验证这些筛选到的组件是否符合系统各安全特性的等级，将不符合的组件去除，从而得到该系统所需的安全功能组件；所述保证组件确认的处理具体包括根据安全目的与安全保证组件，安全保证等级与安全保证组件的关系，筛选得到该系统所需的安全保证组件；

生成系统安全需求文档，该文档至少包含系统资产、行为序列、缺陷、威胁、安全策略、安全假设、安全目的、安全需求等级、安全保证等级、安全功能组件和安全保证组件的信息。