软件安全性设计的分析验证要求研究

李雪飞 李海峰

（中国航空综合技术研究所，北京 100028）

软件安全性设计的分析验证要求研究

李雪飞 李海峰

（中国航空综合技术研究所，北京 100028）

立足软件设计阶段，对关键软件进行安全性分析验证，提出了软件安全性设计的分析验证模型，并依据模型明确安全性设计的分析验证要求，最终给出了安全性检查单。为后续的综合分析验证提供验证目标，从而提高软件和系统的整体安全性。

软件安全性；安全性设计；分析验证要求；检查单

计算机应用范围的快速扩展导致研制系统复杂度激增，软硬件密切耦合，软件的规模、复杂度及其在整个系统中的功能比重急剧上升，导致软件安全性问题日益突出[1]。

引起系统安全的软件问题的原因可分为如下4种：1）软件自身设计/编码没有按照需求正确实现系统要求的功能或是采用了错误的设计参数、运行数据等；2）软件需求错误/遗漏；3）软件运行支撑环境出现故障；4）与软件输入信号相关的传感器、传输线路或硬件输入接口等发生故障[1]。其中1）的一个重要因素就是软件的设计错误。目前针对软件需求阶段有很多方法和技术保证其安全性需求的完整和准确[2～7]，如何将获取到的安全性需求完整、一致并准确的在设计阶段得到实现，是我们面临的又一重要难题。

本文从软件分析验证的模型入手，明确软件安全性设计分析验证的整体范围，全面、系统的阐述了软件安全性设计的验证要求，为后续针对安全性设计的综合验证打下基础。

1 基本概念

1.1 软件安全性

1986年美国软件安全性领域著名学者Nancy G.Leveson给出了软件安全性的定义：“软件安全性涉及确保软件在系统环境中运行而不产生不可接受的风险，软件安全性是软件运行不引起危险和灾难的能力”[8]。这是业内公认的经典定义。

除此之外，GJB/Z 102A-2012《军用软件安全性设计指南》中对软件安全性定义为：“软件运行不引起系统事故的能力”[9]。

1.2 软件安全性分析验证

NASA-STD-8719.13B《软件安全性标准》[10]认为软件安全性分析是指在整个软件生存周期中应用系统安全性工程技术，以确保那些可能降低系统安全性的错误得到消除或者控制到某个可接受的风险级别。

GJB/Z 142-2004《军用软件安全性分析指南》认为软件安全性分析是对和软件安全性相关的特定信息进行的系统而有序的获取和评价过程[11]。在此，软件安全性分析验证主要针对的是评价。

1.3 软件安全性设计分析验证

软件安全性设计分析验证实际就是在软件的设计阶段进行安全性分析验证。

GJB/Z 142-2004《军用软件安全性分析指南》[11]将设计分为结构设计和详细设计。并指出软件结构设计安全性分析是将全部软件安全性需求综合到软件的结构设计中，确定结构中与安全性相关的部分，并评价结构设计的安全性，以保证软件安全功能的安全完整性的过程；软件详细设计安全性分析则是分析软件的设计和实现是否能以相应的软件安全性级别满足软件安全性需求，并保证设计和实现是可分析、可验证，同时能够安全修改的一个过程。

2 验证模型的建立

如同测试验证实施前首先要明确测试需求一样，对航空关键软件进行安全性分析验证，首先应明确分析验证的要求，也可称之为安全性分析验证的任务。

2.1 软件安全性设计分析验证建模理论基础

IEEE Std 1012-2004《IEEE软件验证与确认标准》（IEEE Standard for Software Verification and Validation）[12]是由软件工程标准化协会发布的隶属系统工程学科的一个技术标准，作为一个过程标准，它贯穿了整个软件寿命周期（获取、供应、开发、运行和维护），并且能够与所有的生命周期模型相兼容。通过IEEE Std 1012-2004，可以明确以下内容：

● 建立起验证与确认（Verif ic ation and Validation，V&V）过程、活动和任务的一个通用框架，来支持包括获取、供应、开发、运行和维护在内的软件全寿命周期过程；

● 定义V&V任务，所需的输入和输出；

● 识别与软件完整性级别（共4级）相匹配的最小V&V任务集；

● 定义一个软件V&V计划的应有的内容。

忙的目的往往是：享受生活、回报父母、满足爱人，想无私；忙的结果往往是：享受不了生活、远离了父母、冷落了爱人，成自私。——到底为何而忙

在IEEE Std 1012-2004中，V&V模型（或者V&V框架）包含3个维度，即过程维、活动维以及任务维。过程维是指软件生存周期的各个过程，包括获取、供应、开发、运行与维护。每个过程维都有相对应的活动维，即相应的V&V活动。不同的V&V活动又有相对应的V&V任务，不同的V&V任务构成了任务维。

其中，过程维中的开发过程包含与软件产品有关的需求分析、设计、编码等活动。V&V活动被划分为概念V&V、需求V&V、设计V&V、实现V&V等。不同的V&V活动又包含各自的V&V任务。

图1是对标准中设计V&V模型的总结，从图1中可以看出，设计V&V活动包含的V&V任务有可追踪性分析、关键性分析、接口分析、软件设计评价等。设计V&V的目标是要表明设计是软件需求的正确、准确和完整的转化，并且在这过程中没有引入非预期的特征。为了保证这些目标的实现，IEEE Std 1012-2004对每个V&V任务都提出了相应的正确性、完备性、一致性、准确性、可测试性等任务要求。由此可以发现，在确定设计V&V的任务维后，通过目标分解（如正确性、一致性、完备性等，为了简化图形未对所有任务及目标展开）可以提出不同目标下的验证要求。参照图1软件设计验证模型中的任务框架及验证要求分解思路，可以制定适合软件安全性设计的任务维，并根据目标分解获得软件安全性设计的分析验证要求。

2.2 基于软件验证模型的软件安全性设计的分析验证模型

通过对软件验证模型（图1）进行分析可知，构建软件安全性设计的分析验证模型应首先明确其任务维。由于安全性设计分析验证属于软件验证的范畴，其任务维的制定必须覆盖软件验证任务维中对安全性的考虑，因此可以根据安全关键软件开发过程的特点从软件验证任务维中确定安全性相关的任务维，从而保证设计阶段安全性验证任务维的完整性与独特性。

根据IEEE Std 1012-2004，软件设计可以分为软件结构（概要）设计和软件详细设计，表1分别对两个设计阶段的安全性分析从所需输入、输出以及各自任务维3个方面进行了比较。

表1 结构设计与详细设计安全性分析对比

参照设计V&V验证模型中验证要求的分解过程，对以上2个阶段的每类任务都从正确性、一致性、完整性、准确性、可测试性等任务目标出发进行分解，进而可以获得软件安全性设计分析验证的要求。最终，本文提出了软件安全性设计分析验证模型，如图2所示。

模型明确了安全关键软件开发过程（过程维）中软件安全性设计验证（活动维）的任务维、任务目标以及分析要求。本文后续会描述依据图2所示模型建立起来的分析验证总体要求与详细要求。

3 基于软件安全性设计分析验证模型的分析验证要求

在软件安全性分析验证模型中，对2个设计阶段中每类安全性设计分析验证任务分别从正确性、一致性、完整性、准确性、可测试性、可读性6个目标角度提出分析验证要求，即形成了软件安全性设计分析验证要求。由于任务特点各异，不同的分析任务具有不同的验证目标，本文参照IEEE Std 1012-2004，结合各个安全性设计分析验证任务的特点，确立了如表2和表3所示的软件结构设计和软件详细设计2个阶段的安全性分析验证要求。

表2 软件结构设计安全性分析验证要求

表3 软件详细设计安全性分析验证要求

在软件结构（概要）设计阶段，考虑安全性应重点进行的分析验证包括但不限于[10]：

定时、吞吐量和规模的余量设计的分析验证。确保有关软件模块的存储量、输入输出通道的吞吐能力以及处理时间要求，并保证满足系统规定的余量要求；要结合具体的被控对象确定各种周期，当各种周期在时间轴上安排不下时，应采用更高性能的CPU或多CPU并行处理来解决，以保证软件的工作时序之间留有余量。

硬件失效引起的软件失效的分析验证。应充分分析接口的各种可能故障，包括软硬件之间的接口，并确保有相应的应对措施。例如，软件应能识别合法的及非法的外部中断，对于非法的外部中断，软件应能自动切换到安全状态。

在软件详细设计阶段，考虑安全性应重点进行的分析验证包括但不限于[10]：

对容错和容失效设计的分析验证。应验证安全关键的部件完全独立于非安全关键的部件，还应能够既检测出自身内部的错误，又不允许将错误传递下去。

除此之外，还应该验证软件必须有对异常保护的设计。应确保设计中有相应的保护措施来应对软件运行过程中各种可能的异常情况；并保证异常处理措施可以使软件和系统转入安全状态，保存异常出现的现场信息。

4 基于软件安全性设计分析要求的安全性检查单

本文的研究目的不仅在于构建软件安全性设计验证模型与明确分析要求，也希望通过制定合理的、可操作的分析流程来验证分析要求，从而在实际工程中真正推动安全性分析验证工作。为了能够表述分析要求，同时借助分析要求确定分析流程以及引导安全性分析，本文建立了基于分析验证要求的安全性检查单，如图3所示。

安全性检查单不仅描述了本文提出的分析验证要求，同时，为后续安全性分析验证流程的制定以及分析工作的实施提供了指导思路。最终，依据分析验证要求，设计了6份安全性检查单。表4给出了其中一份安全性分析验证检查单。

使用如表4所示的安全性分析验证检查单来引导分析可以保证分析过程能够覆盖本文提出的所有分析要求，可见，安全性检查单在分析要求与分析流程间构建起一座桥梁。分析要求、安全性检查单与分析流程的关系可以表示如图4所示。

表4 安全性分析验证检查单

5 总结与展望

软件安全性设计的分析验证是整个安全性分析验证过程中不可或缺的一步，而明确其分析要求又是进行安全性分析验证的提前条件。本文首先介绍了软件设计安全性分析验证的相关概念，并以软件验证模型为基础，建立了软件安全性设计的分析验证模型，从而明确了安全性设计分析验证的整体范围；依据此模型，进一步明确安全性设计分析验证的要求；最后，给出了分析验证要求的一种表现形式，即安全性检查单。检查单的建立，不仅使得分析验证更加容易操作，而且还可以引导后续分析工作的实施流程。

明确软件安全性设计的分析验证要求只是一个开始，后面还要依据这份要求对不同的分析验证方法和技术进行分类、整理和选取，最终得到一套完整的软件安全性设计的分析验证方法，从而保证软件在设计阶段的安全性，提高软件和系统的整体安全性。

[1] 周新蕾，宋星，林佳等. 软件安全性分析在运载火箭上的应用[C]. 第7届国际可靠性、维修性、安全性学术会议论文集. 北京：中国宇航出版社，2007.

[2] D G Firesmith. A Taxonomy of safety-related requirements [J]. Requirements Engineering，2004，23（4）：327～331.

[3] 李震. 软件安全性需求形式化建模和验证[D].北京：北京航空航天大学，2011.

[4] D Firesmith. Engineering safety requirements,safety constraints, and safety-critical requirements[J]. Journal of Object Technology， 2004，3（3）：27～42.

[5] S R Koo，P H Seong，J Yoo，et al. An effective technique for the software requirements analysisof NPP safety-critical systems, based on software inspection, requirements traceability, and formal specification [J]. Reliability Engineering & System Safety，2005，89（3）：248～260.

[6] 李震，刘斌，苗虹等. 基于划分软件安全Petri网的需求形式化验证[J]. 系统工程与电子技术，2012，34（9）：1966～1972.

[7] J Hill，S Tilley. Creating Safety Requirements Traceability for Assuring and Recertifying Legacy Safety-Critical Systems [M]. IEEE，2010. 297～302.

[8] N G Leveson. Safeware：System Safety and Computers [M]. Boston：Addison-Wesley，1995. 395～485.

[9] GJB/Z 102A-2012 军用软件安全性设计指南[S].2012.

[10] NASA-STD-8719.13B NASA Software Safety Standard[S].

[11] GJB/Z 142-2004 军用软件安全性分析指南[S].2004.

[12] IEEE Std 1012-2004，IEEE Standard for Software Verification and Validation[S].

T-65

C

1003-6660（2017）03-0041-06

10.13237/j.cnki.asq.2017.03.010

[收修订稿日期] 2017-03-23

（编辑：劳边）