软件安全性综述、林建国、1407142119

“计算机导论”小论文论文题目软件安全性综述所在院系计算机与信息工程学院

专业班级 2014级软件工程（工程技术）

姓名学号林建国（17407142119）

任课教师翁伟

软件安全性综述

专业：软件工程（工程技术）姓名：林建国学号：1407142119

摘要：软件安全性已逐渐成为软件工程和安全工程交叉领域的研究热点之一。对软件安全性的内涵与外延进行了剖析，给出了软件安全性定义。讨论了软件安全性的度量模型。通过分析软件安全领域存在的问题，以软件工程思想为基础，运用系统安全工程的原则，提出一个软件安全性保障框架。在软件开发生命周期过程中，将软件安全保障集成到需求分析，设计编码，测试，维护四个环节中，详细阐述了每个环节要进行的安全性处理的任务，采用一系列安全预测和分析技术，确保软件开发的安全性和可靠性。

关键字：软件工程；软件测试；系统安全工程；软件安全性保障框架。

一引言自从互联网普及后，软件安全问题愈加突显。由互联网上的病毒和攻击者引起的身份窃取、数据丢失以及一般性的混乱已经随处可见。单单2008年第一季度，就有1474个不同的软件脆弱点报告上来，只有64个发布了相应的解决方案。也就是说解决率大约只有4%[1]。不少安全专家都认为应用软件安全将成为信息系统安全的下一个热点。软件安全一般分为应用程序级别的安全性和操作系统级别的安全性。应用程序级别的安全性，包括对数据或业务功能的访问，在预期的安全性情况下，操作者只能访问应用程序的特定功能、有限的数据等。操作系统级别的安全性是确保只有具备系统平台访问权限的用户才能访问，包括对系统的登录或远程访问。

同时软件在ＳＣＳ中的应用规模也与日俱增。比如，在Ｆ－２２战机的综合航电系统中，软件实现的航电功能高达８０％，软件代码达到１７０万余行。而在Ｆ－３５战机的先进综合航电系统中，软件代码达到５００～８００万行。这表明，越来越多的ＳＣＳ日益软件密集化，逐渐形成安全性关键的软件密集型系统。另一方面，由ＳＣＳ软件引发的事故或事件却频发不断：发生在２０世纪９０年代的Ａｒｉａｎｅ５运载火箭、ＳＯＨＯ太空船等５起航天器事故的罪魁祸首是软件；２００４年１２月２０日，一架Ｆ－２２因飞行控制软件故障而坠毁；２００７年２月１１日，１２架Ｆ－２２在穿越国际日期变更线时又因软件缺陷问题造成导航故障，战机被迫在无导航和通信能力下危险返航。

由此可知，软件安全已经是社会稳定不可或缺的重要因素之一。

图1软件图解

软件危机：

1.软件需求的增长得不到满足；

2.软件开发的成本和进度无法控制；

3.软件质量难以保证；

4.软件不可维护或维护成度非常低；

5.软件成本不断提高；

6.软件开发生产率的提高赶不上硬件的发展和应用需求的增长。

为了消除软件危机，形成了软件工程的概念，开辟了工程学的新兴领域——软件工程学。软件工程就是试图用工程、科学和数学的原理与方法研制、维护计算机软件的有关技术及管理方法。

三、什么是软件安全性？

“软件安全性（ｓｏｆｔｗａｒｅｓａｆｅｔｙ）”一词最早出现在１９７９年发布的Ｍｉｌ－Ｓｔｄ－１５７４Ａ标准中，１９８６年由美国加州大学的Ｌｅｖｅｓｏｎ教授引入计算机科学领域。安全性多用于刻画具有能量、毒性或能够进行质量运动的物理设备或系统，而软件作为一种寄生性逻辑实体，不会由于能量辐射、毒性挥发、质量运动对人造成伤害或对环境造成破坏。因此，“软件安全性”至今备受争议，甚至被认为是一个误用的术语。

软件安全性是指既定软件对既定系统安全性的贡献，衡量的是在特定环境下和规定时间内不会因软件功能失效或需求缺陷等诱发系统危险的能力。其中，系统安全性受到操作人员、软件、硬件和外部环境的共同作用。外部环境泛指与该系统交互作用的外部系统或其他要素。

值得指出的是，尽管“安全”本身是一个系统问题，作为系统重要组成要素的软件不会直接危及生命、财产和环境等安全，但借助软件实现的人机交互却可能因软件失效造成人员误操作从而形成危险。

与安全性密切相关的术语还包括保密性、完整性、可靠性、可生存性和可信性。鉴于上述术语之间的易混淆性以及国内对部分术语翻译的不一致性（比如将ｓａｆｅｔｙ译为防危性、保险性,译为安全性，此处着重阐明安全性与这些术语之间的区别和联系，以便更好地理解其内涵（见图2）

图2

软件可靠性是同软件安全性一样与失效密切相关并一直混为一谈的一种软件属性。它衡量的是，在特定条件下和一定时间内，软件提供连续正确服务的能力。二者之间的区别和联系体现在：①软件可靠性关注所有的软件失效，而软件安全性仅关注能够引起危险后果的软件失效；②如果软件任务不能完成将影响系

统的安全性，那么消除这些软件失效将同时提高软件的可靠性和安全性；③消除那些能够引起危险后果的软件需求缺陷可能提高了安全性，却对软件可靠性无益；④如果软件存在安全性需求方面的缺陷，即使消除所有的软件失效（尽管提高了软件可靠性）也不一定能提高软件安全性；⑤可靠的软件可能不安全，安全的软件并不一定可靠。

软件保密性融合了可用性（指某项服务在某个时刻可以获得的概率）、隐私性（指软件已存储信息、代码、数据不被访问的能力）和完整性（指软件不被意外或未授权修改的能力），着重关注如何保护软件使其不被恶意攻击。软件安全性和软件保密性之间的联系和区别主要表现在：①二者都与威胁或风险相关。安全性主要处理危及人员生命财产安全的威胁，而保密性主要消除危及数据私有性的危险；②安全性需求和保密性需求可能都会与某些重要的功能需求或任务需求相冲突；③安全性和保密性需求都需要在系统层面谋划布局，且这些需求在系统上下文外是难以处理的；④安全性和保密性都需要一些极其重要的需求，这些需求决定了系统能否被使用；⑤保密性着重关注的是对分级信息进行的未授权恶意访问行为，而安全性多关注的是无意行为。

软件可生存性描述的是当软件系统的一部分遭受攻击陷入瘫痪时，关键服务仍能够使用的程度。认为可生存性应包含系统、威胁、自适应性、服务可持续性和实时性等５个关键部分。软件可生存性与软件安全性之间的联系在于：①确保软件生存的服务可能同时确保软件安全性；②生存性丢失的系统可能依然安全；③不安全的系统可能具有生存性。

软件可信性包括可用性、可靠性、安全性、隐私性、完整性、可维护性６个属性。它强调的是软件行为在任意操作条件下都是可预测的，能够抵御其它软件、病毒以及一定的物理干扰造成的破坏。

四、基于软件工程的软件安全性保障框架

1、传统开发方法在安全方面的不足在传统面向对象项目开发过程中，在安全性方面存在以下不足[3]：

1)设计阶段，由于以类为单位组织建模，因此它不能全面地反映软件系统的安全需求。

2)编码阶段，将数据和方法封装到类中的思想增强了数据的安全性和软件的模块化，但是有一些数据和方法是特定于应用的，对于系统安全方面的考虑比较少。

3)维护阶段，一般是系统在使用过程中发现了漏洞再去修补，不仅效率低而且工作量大。

2、基于软件工程原理的软件安全性保障框架本文依据系统安全工程的原理，将软件安全引入到软件开发生命周期之中。为了开发出安全的应用软件，提出一个软件安全性保障框架，将软件安全保障实施到软件开发的各个模块当中。该框架具体分为：软件安全需求分析、软件安全设计与编码、软件安全检测与评估、漏洞响应和维护阶段。首先分析软件开发中可能出现的安全问题，了解项目的安全需求，之后再要保证程序设计和编码过程中的安全性，开发完成后对软件进行安全性检测和评估，最后进行产品的维护，对产品中存在的漏洞问题进行响应和处理。设计出该框架的示意图如图3。