信息安全第6章可信软件和恶意软件防范.ppt

《信息安全第6章可信软件和恶意软件防范.ppt》由会员分享，可在线阅读，更多相关《信息安全第6章可信软件和恶意软件防范.ppt（286页珍藏版）》请在三一文库上搜索。

1、第6章 可信软件和恶意软件防范,6.1 程序安全 6.2 软件可靠性模型 6.3 软件系统排错技术 6.4 软件可信运行环境 6.5 软件的完整性认证 6.6 计算机病毒 6.7 计算机蠕虫 6.8 特洛伊木马 6.9 其他恶意代码 6.10 软件系统恢复与重构,6.1 程 序 安 全 程序构成了一个计算机系统的很多部分(操作系统、设备驱动程序、网络基础设施、数据库管理系统和其他应用程序，甚至网页上的可执行命令)，因此多种形式保护程序是计算机安全的核心。程序安全除了包括程序的完整性、可用性、保密性外，还包括了程序的运行安全性。众所周知，来自系统外部的恶意攻击的主要目标是计算机系统，其直接的重点

2、目标是信息和数据，以及包含、记录和存储这些信息数据的程序(软件)。程序的丢失、篡改、窃取、非法复制、滥用等对系统造成的后果是灾难性的，对社会造成的影响是严重的和深远的。,随着计算机网络、通信和信息处理的推广普及，随着各种计算机系统趋于开放式结构，系统连接技术和协议公开化，计算机(尤其是微型计算机)逐步进入社会各个环节，形成一个社会各方与专业领域融合的大环境，计算机恶意程序通过各种途径(直接施放、网络通信、远程访问、电子邮件、电子广告、软件交流等)传播蔓延的机会越来越多，最终必然威胁到系统，进而威胁到系统中的数据和程序的安全。各种大型软件、专用软件(如统计、地理、气象、能源、航空、航天、军事、金

3、融财务等软件)的使用，大型数据库的联网开放，都使得数据和程序的重要性及地位日益重要，使得对程序的依赖性日益严重。程序中一个小的纰漏、一种不完善的功能、一次细微的疏忽，都可能对系统造成极大的影响。,6.1.1 程序安全的概念 当我们说一个程序是安全的，它的含义是指，对程序能实现期望的机密性、完整性和可用性的信任程度。所谓信任问题，是指假设提供一个已完成的程序，例如一个商业软件包，如何来确定它的安全性或者说如何以最安全的方式使用它？答案是采用独立的、第三方的评估。 一般而言，开发者把错误的数量和种类作为产品质量的依据。我们经常谈论软件中的“bug”，根据不同的上下文，所对应的意思也不同。它可以是需

4、求说明时的一个错误，一段代码中的语法错误，或是一个导致系统崩溃的因素。IEEE推荐了一个标准术语来描述软件中的“bug”。,当一个人在从事软件活动的过程中犯错误时，我们称之为过失(error)。过失可能会在计算机程序中导致一个错误(fault)，或者一个不正确的步骤、命令、过程或数据定义。例如，一个设计者可能误解需求，从而创建一个不符合分析员和用户要求的设计。一次失效(failure)就是对系统要求行为的一次违反。在系统发布之前或之后，或在测试过程中，或在运行和维护过程中都能发现失效。,早期的计算机安全工作建立在“查找错误并打补丁”(penetrate and patch)的模式上。分析专家在

5、该模式下寻找错误，并给错误打上补丁。一些顶尖的测试团队尝试各种方法使系统崩溃以测试系统的安全性。这种测试被认为是安全“证明”；如果系统经受住了攻击的考验，就认为是安全的。遗憾的是，这种证明经常成为反面例子，因为系统中隐藏的错误往往不止一个。为了解决这些不断发现的错误，人们迅速开发了许多补丁以修复安全问题，然而，大多数补丁并未起多少作用。相反，它们使系统变得更不安全，因为它们引入了新的错误，其原因有三个：,(1) 修补指定问题的压力使得人们仅仅关注错误本身，而不是与之相关的上下文环境。特别是分析专家仅专心于研究导致失效的直接原因，而忽视设计或需求方面的原因。 (2) 修补一个问题时常导致其他地方

6、的失败，或者说补丁仅仅解决一个地方的问题，而没有解决相关地方的问题。 (3) 打补丁可能会影响系统的功能和性能，所以补丁不能适当地修补系统错误。 由于“查找错误并打补丁”模式的不完善，人们不得不考虑其他方法来保证代码满足安全需求。其中一个方法就是对比系统需求和系统行为。也就是说，为了理解程序的安全性，可以检查程序的行为是否符合设计者或用户的需求。,程序安全缺陷(program security flaw)是指由于程序的脆弱点而引起的不恰当的程序行为。一个缺陷可以是一个错误或是失效，而脆弱点经常用来描述某一类缺陷，诸如缓冲区溢出。脆弱点和缺陷是起因和影响的关系。例如，一个特洛伊木马被注入到一段代

7、码中，就是一个利用了程序脆弱点的缺陷，然而用户可能还没有发现木马的恶意行为。因此，必须从内部和外部两方面处理程序的安全缺陷，不仅要找出失效的原因，也要找出初始的原因。此外，仅仅识别这些问题是不够的，还必须确定怎样避免由其引发的灾难。 可惜的是，我们还没有技术来消除或解决所有的程序安全缺陷。Gasser指出，安全根本上就是困难的，安全时常与有效性和性能相冲突，而且错误的安全解决方案会阻碍安全编程的真实进展。,如今，影响计算机程序安全的因素太多，几乎不可能建立起一个绝对安全保密的信息系统。我们一方面要加强人为因素的控制，如制定相关法律、法规，加强管理；另一方面，加强技术措施的应用，如系统软件安全保

8、密、通信网络安全保密、数据库系统与软件的安全保密等。尽管如此，通过了解什么会出错以及怎样阻止它，我们能够开发出符合要求的、用来保护大多数计算机的应用程序和其他程序。,6.1.2 非恶意的程序漏洞 人都会犯错误，程序员和其他开发者也不例外。其实大部分错误都是无意或非恶意的。大多数错误会造成程序故障，但不会造成特别严重的安全隐患。然而，极少数错误却已困扰了程序员和安全专家几十年之久，并且在短期内无法将其消除。本节将讨论三种典型的错误，并分别解释每种错误，说明它为什么和安全性相关，以及怎样预防或减轻危害。,1. 缓冲区溢出 举个通俗的例子，缓冲区溢出就好比将2升的水倒入1升的水罐中，肯定会有一部分水

9、溢出并产生乱象。在计算中，这些错误将造成极大的混乱。 所谓缓冲区，就是一个用来存储数据的空间。缓冲区位于内存中。由于内存是有限的，所以缓冲区的容量也是有限的。因此，在许多程序设计语言中，程序员必须声明缓冲区的最大容量，以使编译器能留出所需的空间。 通过一段例子来了解缓冲区溢出是怎样发生的。假设在一段C语言程序中包含如下声明： char buffer10;,编译器为缓冲区划分了10个字节大小的空间，从buffer0到buffer9，每个都分别占用一个字节的空间，现在我们执行这条语句: buffer10=a; 数组元素的下标超过了缓冲区的大小，从安全的角度出发，这样出现问题了。最好的结果是，编译器

10、在编译过程中就检查出问题并将错误标记出来。然而，如果语句是： bufferi=a;,那么，直到i在执行过程中被设置成一个大到越界的下标之前，我们都无法检查出这个错误。如果在执行过程中，系统能产生一个下标越界错误的警告，那将是非常有用的。遗憾的是，在一些语言中，缓冲区大小并不需要预先声明，所以也就无法检查出越界错误。更重要的是，在执行过程中，检查每个下标是否超出可能的最大值需要花费时间和空间，宝贵的系统资源就被这些不常发生的问题浪费了。由于没有合理的方法来定义恰当的限制，所以即使编译器小心翼翼地分析缓冲区的声明和使用，指针也可能引发同样的问题。所以，一些编译器并不产生代码来检查是否越界。,我们来

11、更深入地研究这个问题。潜在的缓冲区溢出只是在某种情况下才会造成严重的问题，认识到这一点是非常重要的。问题是否出现取决于邻近buffer数组的内容是什么。假定buffer数组的10个元素的每个字母都用a填充，而错误的引用却使用字母b，如下所示： for(i=0;i=9;i+) bufferi=a; buffer10=b;,执行过程中，所有程序和数据都在内存中，它们与操作系统、其他代码和常驻程序共享内存空间。如果这个额外的字符b溢出到用户的数据空间，则它仅仅会覆盖一个已存在的变量值(也可能会写入到一个还未使用的位置)，可能会影响程序的运行结果，但不会影响其他程序或数据。如果b被送入用户的程序区域：

12、如果它覆盖了一条已执行的指令，并且该指令以后都不会再执行，用户将不会觉察到影响；如果它覆盖的是一条还未执行的指令，由于b的内码是0x62，机器将会尝试着执行操作码为0x62的指令；如果操作码为0x62的指令并不存在，系统将会由于一个非法指令异常而停机；如果该指令存在，机器就会把后续字节当做这条指令的剩余部分来使用，运行成功与否取决于上下文的含义，只有用户才能感受到缓冲区溢出的影响。,综上所述，在带数组的高级语言出现时，缓冲区溢出就随之出现了。最初一段时间，它带给程序员和用户的困扰较小，最多不过出现系统崩溃。而最近，攻击者利用它首先使系统崩溃，然后制造出更多可控制的故障，这就随之导致了严重安全性

13、问题。大量基于缓冲区的溢出漏洞的攻击使人们意识到，开发者不能再像从前那样轻视它，而是必须对缓冲区的溢出给予更多的关注。,2. 不完全验证 不完全验证(incomplete mediation)是另一个长期存在的安全问题。它常常被攻击者利用。 考虑下面的例子： http:/ 其中的两个参数看起来一个是电话号码和一个日期。或者客户端的浏览器输入的两个有特定格式的参数值对服务器来说很容易处理，但如果parm2的值被提交为1700Jan1，或者1800Feb30，或是2050Jane31，或是1Rabbit2Many，,将会产生错误。一种可能是，如同缓冲区溢出一样，系统将由于尝试处理不正确的数据类型，

14、如年份超过正常能处理的范围(如1700)，或者月份超过正常能处理的范围(如Jane)，而发生灾难性的故障。另一种可能是接收到这些错误参数的程序将继续运行而得出错误的结果(例如想得到截止到今天的话费账单总额，如果开始日期是1700年1月1日，结果肯定是错误的)。另外，服务器可能会有自己的一套默认处理方式，如将1Rabbit2Many当做1Jan2010来处理。当然，还有其他可能性。,一种解决的方法是事先就预测出潜在可能发生的问题。例如，在上面的例子中，程序员可以事先编写代码来检查客户端提交数据的正确性，客户端程序可以检查并抛弃不正确的提交数据。为了防止提交无意义的数据，程序可以被设定为只处理有效

15、数据。通过应用这些提交验证技术，程序员就可以避免用户无意或恶意制造错误。,然而，改进后的程序仍然是脆弱的。提交的结果最终是包含在URL中进行传递的，而用户可以操作或更改URL，例如：用户可以编辑URL，改变里面待提交的参数值，并重新发送它们。而服务器没有办法分辨出一条回应是来自客户端的浏览器，还是用户直接编辑修改的URL。这样，不安全的参数验证很容易被利用。虽然它没有缓冲区溢出那么频繁，但仍然是一个可能造成严重危害的漏洞，尤其在一些对提交数据要求非常严格的行业和部门。,举一简例。一家大型跨国网上购物公司sample进行电子产品的在线销售，这样客户可以通过该公司的购物网站来下订单。一位客户想购买

16、20个编号为123A的物品。如果每个物品的售价是50元，网站将计算出总价格为1000元。然后客户选择运输方式(如快递运输)，那么客户端的浏览器会自动按格式填充参数： http:/ 还有其他很多情况，也经常发生类似错误。这对人们敲响了警钟：运行中的代码还隐藏着多少类似的错误？,3. “检查时刻到使用时刻”错误 第三种漏洞与同步操作有关。访问控制是计算机安全的一个基础部分，确保只是具有访问权限的人或进程才能进行相应的访问。访问请求由访问策略所控制，策略指明了哪些请求允许访问哪些资源。然后，访问策略的执行代理对访问请求进行仲裁。但是，若对访问的检查不全面，就会出现不完善仲裁问题。检查时刻到使用时刻(

17、Time-Of-Check To Time-Of-Use，TOCTTOU)的漏洞与仲裁在执行中受到诱骗有关。该漏洞也称为序列化漏洞或同步漏洞。,举一简例。一位顾客正在买价值100元的衬衣。他从口袋里拿出5张20元的人民币，放在柜台上。店主清点完人民币之后，发现没有问题，于是转过身来开发票。就在店主开发票时，该顾客迅速地从5张人民币中抽出1张，而没有被店主察觉。顾客然后接过店主的发票，拿好衬衣，离开商店。在接受安全性检查(类似该例中的清点钞票)之后到访问(类似该例中的交换衬衣和人民币)之前的这段时间内，一些情况发生了改变。同样的问题，也可能出现在计算机系统中。,假定一个文件访问请求的数据结构包括

18、有文件名和访问方式两个。从本质上来说，该数据结构是一个“工作凭证”，还需要一个“授权盖章”。一旦该操作被授权，它将被放入一个操作队列中。通常，访问控制仲裁器接收该数据结构，并决定是否允许该操作。如不允许，则拒绝该访问并停止操作；否则，将该数据结构送至文件处理器进行处理。为了确定授权顺序，访问控制仲裁器必须在表中查看文件名(及用户ID和其他参数)。仲裁器可以比较表中的文件名与结构体中的文件名以决定这次访问是否适宜。但是，数据结构仍然在用户的区域并在用户的控制之下。这时，就可以对不完整仲裁漏洞进行利用。当仲裁器正在检查文件my_file的访问权限时，用户可以将文件名改为your_file，并将访问

19、方式改为“删除”。由于“工作凭证”已经被读过一次，所以就不能指望仲裁器在批准它之前再去阅读“工作凭证”。仲裁器将批准此次访问并将修改后的描述符送给文件处理器。,这个安全问题称为“检查时刻到使用时刻”漏洞。它的安全含义是：检查一个动作而去执行另一个动作，这是一个无效访问控制的例子。我们有两种思路来防止该漏洞被利用。一是确保关键参数在失控时不被暴露，访问检查软件必须拥有请求数据，直到请求完成。另一个方法是确保序列完整性，即在验证期间禁止中断(失控)，或者验证程序可以先从用户空间复制数据到程序空间(用户不可访问)，并基于该复制执行验证检查，最终，验证程序能够用一个校验来封装请求数据，检测修改。,4.

20、 非恶意程序漏洞的结合使用 上述三种漏洞在单独使用时都会造成很坏的后果，但更可怕的是，它们还可以结合起来使用。攻击者可以对仅仅使用了缓冲区溢出不大满意，而代之以三重攻击。先借助缓冲区溢出来破坏机器上运行的任意代码，同时它使用“检查时刻到使用时刻”的漏洞来添加一个新的系统用户。接下来，攻击者以新的用户身份登录系统并利用“不完全验证”漏洞获得一定权限来做其他事情。聪明的攻击者可以将这些漏洞当成常用构件块来构造一个复杂的攻击。虽然非恶意漏洞往往造成的危害有限，但一旦被人利用，就会后患无穷。在下一节中我们将会看到，恶意攻击者可以利用看起来无害的程序漏洞编写有害的代码。,6.1.3 病毒和其他恶意代码

21、就病毒和其他恶意代码本身而言，程序很少对安全性构成威胁。程序对数据进行操作，只有当数据和状态发生改变并满足其触发条件时，才会执行。程序所做的大多数工作对于用户是不可见的，所以不大可能发现它们在进行危险活动。比如：你知道一个游戏程序在与你的交互行为之外进行了什么其他行为吗？你知道文件档案是以什么方式进行存储的？当你正在对一个文档进行编辑时，其他程序会不会也在非法执行？大多数用户不能回答这些问题。由于用户通常不能直接对计算机数据进行观察，攻击者可以编写自己的程序作为工作来访问和修改其他程序的数据。我们来具体分析恶意代码的特点、产生的原因和分类。,1. 恶意代码简介 一般没有人会喜欢出乎意料的行为，

22、特别是在程序里面。由于恶意程序员的某种意图，恶意代码是以意料之外的方式运行的。我们把恶意代码看做是系统的潜伏者，它可能是正在运行的程序的全部或一部分，也可能是一个独立程序的一部分，依附于其他正常程序来运行。 计算机病毒并非是最近才出现的新产物。事实上，早在1949年，距离第一部商用计算机的出现仍有好几年时，计算机的先驱者冯诺依曼(Von Neumann)在他所提出的一篇论文复杂自动装置的理论及组织的运行中，已把病毒软件的蓝图勾勒出来了。当时，绝大多数的计算机专家都无法想象,这种会自我繁殖的软件程序是可能的。可是少数几个科学家默默研究冯诺依曼所提出的概念，直到十年之后，在美国电话电报公司(AT&

23、T)的贝尔(Bell)实验室中，这些概念在一种叫做“磁芯大战(core war)”的电子游戏中成形了。这个游戏的特点是：双方的软件进入计算机之后，玩游戏的人只能看着屏幕上显示的战况，而不能做任何修改，一直到某一方的软件被另一方的软件完全“吃掉”为止。,到了1983年，计算机病毒的存在被科恩汤普逊在他的颁奖典礼上向外界正式公开，同时他还告诉听众怎样编写病毒程序。从此，计算机病毒的广泛流传便一发而不可收拾。特别是随着网络化步伐的加快，病毒借助于网络爆炸式地传播，使得很多毫无防备的信息系统遭到破坏，造成了巨大的损失。 恶意代码极具破坏性。恶意代码在非法获取的用户授权下进行，因此，它以相同的方式访问用

24、户所访问的东西。用户有绝对的权限对他自己的程序代码和数据文件进行控制，如读、写、修改、添加或删除。恶意代码往往也能这么做，而且无需用户授权，甚至不需要用户知道。,恶意代码长期存在。1984年，Thompson在演讲中提到了“赋予信任的反应”(reflections on trusting trust)，用以描述可以通过编译器编译的代码。在那次演讲中，他提到了一份早期的文档全面的安全评估(The muttics security evaluation)。其实，关于病毒行为的文献记录至少可以追溯到1970年。Ware在1970年的研究和Anderson为美国空军所做的计划研究都准确地描述了病毒的威

25、胁、程序的脆弱点和程序安全性漏洞，特别是那些带有恶意性质的。对于病毒代码而言，新出现的东西只不过是不同的实例和变种，以及利用了代码出现的速度。,恶意代码存在于我们的周围，其影响比以前更加深远。研究恶意代码的外在表现和工作原理对我们来说非常重要，可以借此逐步阻止它们进行破坏活动，或者至少能减弱它们的影响。本章后面的内容将会讨论常见恶意代码的工作原理、特性、危害等内容。,2. 恶意代码的种类 恶意代码(malicious code)和欺诈程序(rogue program)是以破坏为目的的一类程序，由一个代理(agent)编制，在软件中造成不期望的结果。该定义将无意的程序错误排除在外，也将程序冲突错

26、误排除在外。所谓代理，是指该类程序的作者或发布人。通过此定义我们得出，大多数在软件检查、评估、测试中发现的错误都不属于恶意代码的范畴，因为这些错误都被认为是无意的。然而，无意错误事实上可以引起与恶意代码相同的后果。一个良性原因仍然可以造成一个灾难。,病毒(virus)是一种将恶意代码传递给正常程序的程序，它通过修改正常程序做到这一点。“病毒”的得名是因为它与生物学中的病毒具有相似特征，被它感染的系统将继续感染其他系统以破坏其他系统或使病毒与其他系统共存。病毒是潜伏的，以至于不能确定昨天还是干净的系统今天是否干净。此外，一个正常程序也可能被修改以包藏病毒程序的副本，这样该程序的行为就与病毒一样，

27、感染其他程序。被感染的主机数量通常以几何级数递增，最后整个系统都被病毒控制，并继续蔓延以感染其他与本系统相连的系统。,特洛伊木马(Trojan horse)是这样一种恶意代码：它除了程序所具有的基本功能之外，还有一些不易被人发掘的破坏作用。 逻辑炸弹(logic bomb)也是恶意代码的一种。它将在特定条件产生时被“引爆”。定时炸弹(time bomb)是逻辑炸弹的一种。它的出发条件是时间或是日期。 陷门(trapdoor)或后门(backdoor)是某些程序所具有的特征，人们可以利用这个特征进入该程序，而不是明显、直接的调用，或其他需要特殊权限的进入方式。,蠕虫(worm)是一种通过网络大量

28、传播自身复制的程序。蠕虫与病毒的基本区别在于蠕虫的操作都是通过网络来进行的，而病毒可以通过任何介质进行传播(但通常利用的是已复制的程序或数据文件)。另外，蠕虫的自身复制都是以独立程序的形式传播的，而病毒的自身复制则必须嵌入到其中程序中来传播。 以上是一些常见的恶意代码种类，如果两种或两种以上的恶意代码结合起来使用，可产生新的后果。例如，一个病毒可以是定时炸弹，该病毒的传播代码在一定时间以后将会激发一些事件。恶意代码的分类摘要如表6-1所示。,表6-1 恶意代码的类型,6.2 软件可靠性模型 20世纪70年代中后期以来，以软件工程的大力发展为契机，借传统可靠性工程技术和方法，软件可靠性工程得以产

29、生并取得了长足的发展，各种软件可靠性模型相继推出并得到不断改进和优化，模型验证和使用一度成为软件可靠性工程的热点，直至今日也依然是热门话题。软件可靠性工程管理技术的开发备受推崇，相应的管理方法被实践所验证，软件业界已充分认识到，绝大多数软件问题是由管理不善和管理机制引起的，所以，以过程改进、组织性能改进、管理模式改进、软件开发人员管理为重点的管理体系和管理机制,日趋成熟。目前，通过软件业界和可靠性工程界的不懈努力，软件可靠性工程得到了广泛的研究并通过不断实践而取得了显著的成绩。但遗憾的是，直到今天，开发足够可靠的软件并测试和验证其可靠性，仍是十分困难的问题。,软件可靠性是软件开发、管理、环境、

30、资源、人员等因素的函数。它不仅依赖于软件开发过程中所使用的方法、技术和工具，还与验证方法有关。一个通过完备测试的软件，其可靠性必然得到保证。软件可靠性领域所使用的程序设计语言、开发与运行环境以及开发人员的素质和工作质量等密切相关。建立软件可靠性模型，旨在根据软件可靠性数据以统计等方法给出软件可靠性的估计值或预测值，从本质上理解软件可靠性行为。可靠性建模是软件可靠性工程的基础，至今依然是研究最活跃、成果最丰富的领域之一。软件可靠性建模用以评估软件所提供的服务以及软件过程之间的依赖关系。一个精确的软件可靠性模型是有效地进行可靠性分析和评估的基础。,6.2.1 软件可靠性模型的发展历程 软件可靠性工

31、程的产生和发展得益于软件可靠性模型。20世纪80年代之初，软件可靠性工作主要侧重于模型的研究和建立。迄今为止，发表了100多种软件可靠性模型，且新模型还在不断推出，从而导致了所谓的“模型战”。最早的软件可靠性模型是由H.K.Weiss于1956年提出的一系列公式，但由于它们太复杂，这些公式对后来软件可靠性模型的建立几乎没有什么影响。,1967年，Hudson观察到软件开发过程是一个生灭过程，提出了生灭过程模型。模型的关键点是：错误的产生是延期的，错误纠正是死亡期，在任一时刻存在于软件的错误个数可用来定义过程的状态，过程的转移概率与生灭函数有关。 对软件可靠性模型发展起着重要或奠基作用的模型分别

32、是M.L.Shooman于1971年发表的Shooman模型以及Z.Jelinski和P.B.Moranda发表的J-M模型。他们都假设： (1) 软件中的初始错误数为N(N0)； (2) 软件故障与软件中的剩余错误个数成正比； (3) 错误一旦被发现，立即排除且不引入新的错误。,另外，J-M模型还假设故障的风险率为分段常数，在首次纠错过程中，它由一个常量来改变，但在两次纠错过程之间保持常数。Jelinski和Moranda应用极大似然估计来估计软件中总的错误数量、剩余错误数量与风险率之间的比例参数。 1972年，B.Littlewood和J.L.Verrall发表了第一个贝叶斯(Bayes)

33、模型。他们假设：故障间隔时间服从含参数i的指数分布，且i服从先验的分布。据此，由标准的Bayes过程获得tn+1 | t1, t2, , tn。同年，G.J.Schick与R.W.Wolverton提出了类似的模型，它与其他模型的主要区别就在于，他们假定连续的故障之间的纠错服从瑞利(Rayleigh)分布。,1973年，W.L.Wagoner发表了类似模型，但假设了风险函数服从Weibull分布，其特例就是Schick-Wolverton模型。 1975年，J.D.Musa发表了执行时间模型，引入了一系列新的显示函数。同年，P.B.Moranda发表了几何泊松(Possion)过程模型，该模型

34、假设故障率随着时间的增加呈几何级数下降，且下降过程出现在每次故障的纠正期间。因此，在第i个时间段内的错误数满足含参数Ki-1的泊松分布。,同年，K.Trividi和M.L.Shooman发表了第一个马尔可夫(Markov)过程模型。他们将系统状态区分为“UP”和“DOWN”两个状态，并假定“UP”状态和“DOWN”状态，并假定“UP”状态和“DOWN”状态之间的转换概率相同。模型输出结果是一个概率集合，集合的每个元素为：P在0，t 内找出k个错误。 1976年，m.l.shooman和S.Natarajan发表了基于错误排查过程中引入新的错误的模型。他们使用查错率、纠错率以及新错误引入率来处理

35、新的错误引入问题。 1979年，A.Goel和K.Okumoto发表了关于连续时间的NHPP模型，该模型对软件可靠性工程的发展产生了持续的影响。,1983年，由Yamada、Ohba和Osaki联合发表的NHPP模型，给出了呈S形的可靠性增长曲线的均值函数。由K.Okumoto和J.D.Musa提出的对数泊松过程模型，具有一个初始错误率，以及对应于的一个递减率。模型的日历时间部分则与执行时间模型的日历时间部分相同。 1989年，Y.Tohma、K.Tokunaga、S.Nagase和Y.Murata提出了超几何分布模型，用户估计软件中的剩余错误数量。,Tsu-Feng Ho、Wah-Chun

36、Chan和Chyan-Goei Chung提出了基于软件模块结构的模型，通过每个模块的可靠性来估计软件系统的可靠性。另外，他们还结合信息论方法，建立了软件可靠性模型。之后，随着软件构件技术的发展，基于构件的软件可靠性模型得到了深入研究和迅速发展。 F.Zehedi和N.Ashafi对确定的系统划分层次结构，应用分析分层过程以推定所需要的模型参数。该模型具有非线性规划的形式，在模块和程序级别上考虑软件可靠性的各种技术和经济上的约束条件，使软件系统的实用性达到最大；求解这一非线性规划问题，则可确定在模块和程序级别上的软件可靠性的分配方案。,现代电子设备系统大多是嵌入式系统，而且大多是实时系统，如何

37、预测和评估它们的可靠性，问题的难度更大。J.C.Laprie和K.Kanoun在这方面作出了杰出的贡献。 G.Pucci应用恢复块结构技术，对软件可靠性等软件质量进行估计，根据错误对软件系统所产生的可观察到的后果进行分类，使得将测试数据应用于模型参数的估计成为可能。T.Downs针对现有大多数软件可靠性模型在测试阶段将软件处理成黑盒子的做法，考虑对测试过程直接建模。 K.W.Miller等人开发出以软件的黑盒子模型为基础的理论分析方法，以解决：,(1) 随机测试过程中，当观察到的故障次数为0时，如何估计当前版本软件的故障率； (2) 使用分布与测试分布不匹配时，对估计的故障概率进行调整； (3

38、) 故障率估计时，将随机测试的结果与其他信息结合起来进行分析。 N.Karunanith、Y.Malaiya和D.Whitley应用神经网络系统理论预测软件可靠性。他们利用前向神经网络对三个数据集合进行软件可靠性估测，结果发现：神经网络方法在软件可靠性估测中显示出良好的一致性，这是一般现有软件可靠性模型所无法做到的，神经网络方法对于提高估测精度具有显著的效果。,目前，软件可靠性模型依然是软件可靠性工程研究的热点，基于构件和体系结构的软件可靠性建模正在掀起软件可靠性模型研究与应用的新一轮高潮。与此同时，模型的比较和选择正在得到较深入的研究，一系列可观标准得以产生，为模型的选择提供了支撑；模型中所

39、使用的统计方法更趋实用，很多经典模型的一致性被提取出来并且得到了有效验证，强有力地推进了软件可靠性工程的发展。,6.2.2 软件可靠性模型的分类 软件可靠性模型数量众多，表达形式变化多样，适用情况千差万别。为了能够系统而深刻地理解软件可靠性模型，对现有模型进行合理分类是必不可少的。通常分为结构模型和预计模型两大类。 结构模型反映系统的逻辑结构，借助这类模型，在掌握软件单元(构件)可靠性特征的基础上，可以对系统的可靠性特征以及变化趋势做出预测和评价。结构模型是软件系统分析的重要工具，它既可用于软件系统的可靠性综合，也可用于软件系统的可靠性分解。结构模型包括串联系统模型、并联系统模型，以及硬软件复

40、合系统模型等。,预计模型在本质上是一些描述软件失效与软件错误的关系、软件失效与运行剖面的关系的数学方程。借助这类模型，可以对软件的可靠性特征做出定量的预计或评估。例如，可以预计开发过程中的可靠性增长，预计或评估软件在预定工作时间的可靠度，预计软件在任意时刻的失效率等。评估和预计是两个有区别又有联系的概念。评估是指对软件现有的可靠性做出评价。预计是指对软件未来的可靠性特征进行预测。这二者难以分开。常见的分类有：面向时间的模型，面向输入的模型和面向错误的模型。需要指出的是，在使用数学模型进行预计时，蕴含的假定是，事物发展规律在未来的一段时间内保持不变。对于短期预测这个假设是合理,但是，随着预测期的

41、延长，其近似性减弱。用可靠性模型进行预计时，为了得到较准确的结果，如果发现软件的失效规律有明显改变，则应该对参数加以修正或重新收集失效数据，重新确定模型参数。 软件可靠性模型的分类如图6-1所示。,图6-1 软件可靠性模型的分类,6.2.3 软件可靠性模型的作用 软件可靠性模型是软件可靠性定量分析技术的基础。以软件可靠性模型为支撑的软件可靠性定量分析技术，在软件开发过程中具有重要的作用。 借助软件可靠性定量分析技术，可以对各种软件开发技术的优劣做出定量的评估。为了提高软件质量，20多年来陆续出现了许多软件开发技术。但是对这些技术使用的实际效果，人们无法定量评定，致使优劣难辨。这种状况造成了部分

42、人对使用新开发技术持观望态度，若干新技术在软件开发中的应用进展迟缓。可靠性定量分析技术的应用，为评估软件开发技术的价值提供了判断依据，增加了新技术实用价值的透明度，有助于提高人们开发和应用新技术的积极性。,软件可靠性定量分析的应用，使项目管理人员能够在软件的测试阶段，进行可靠性增长分析，及时评估软件的开发水平。在软件可靠性定量分析技术出现之前，用来评价测试进程的方法只有直观判断法、完成测试百分比分析法和关键功能测试法，它们没有一个能够真正满足软件开发水平评估的要求。使用可靠性预计模型得出的，以测试数据为基础的软件可靠性参数(例如软件失效率)，为评估开发进程提供了定量的、客观的依据。在测试过程中

43、，伴随测试进展和测试资源投入，软件可靠性将呈现增长的趋势，使用软件可靠性模型，可以对软件可靠性增长趋势进行分析、预计。软件的可靠性增长与项目开发进度和资源消耗有紧密的联系，从可靠性增长分析中得到的信息，将成为项目决策的重要依据。,借助软件可靠性定量分析技术，可以监控软件的运行性能，控制软件的设计变更，控制软件的功能扩充。扩充软件功能和对程序做大幅度的修改，都会降低软件的可靠性。采用可靠性定量分析技术，观察软件可靠性指标的变化，可以确定软件的设计变更和软件的功能扩充是否合理、可行。,6.2.4 软件可靠性预计模型 软件可靠性预计模型的研究始于20实世纪70年代初期。迄今为止，文章书籍中的可靠性预

44、计模型已有几十种，而且新的模型还在不时出现。这些模型大体上可分为三种类型，即面向时间的模型、面向输入的模型和面向错误的模型。 1. 面向时间的模型 面向时间的模型以时间为基准，研究软件的可靠性随时间变化的规律。这种模型建立的基础及其预测结果，符合软件可靠性定义的要求，且与硬件可靠性的概念兼容，可以满足硬、软件的系统综合分析的要求，因此得到了广泛的应用，成为三类模型中最重要的、包含品种最多的一类。根据对数据的要求，这类模型可以分为两类，即失效时间间隔模型(TBF模型)和失效计数模型(FC模型)。,(1) 失效时间间隔模型(TBF模型)所使用的数据是一定的时间间隔中的失效数，分析方法建立在以失效时

45、间间隔服从特定的概率分布的基础上。 (2) 失效计数模型(FC模型)所使用的数据是一定的时间间隔中的失效数，分析方法大多建立在泊松过程理论的基础上。 面向时间的模型最大缺点是其假设的前提条件很高，很难完全满足，因而影响了模型的准确性和人们使用的信心。经过30多年的研究、发展，情况有了很大的改善，再加上模型的数量多，选择余地大，这类模型的应用前景是广阔的。,2. 面向输入的模型 面向输入的模型的目的是建立软件的可靠性与输入数据的联系，用程序运行中的失效次数与成功次数的比例作为软件可靠性的度量。这种模型概念清晰易懂，易于应用，但是其与时间度量没有直接的关系，在实现硬软件系统综合时有一定困难，必须经

46、过附加的数学处理，才能用上时间尺度表示可靠度。 3. 面向错误的模型 面向错误的模型直接使用软件中现存的错误数来反映软件可靠性。这种模型的结果直观，其缺点是不能反映软件可靠性与时间的关系。,6.3 软件系统排错技术 6.3.1 软件系统排错的目的 软件系统的排错在软件开发中占有重要的地位。软件排错又称软件调试，指的是在进行了成功的测试工作之后才开始的工作。与软件测试不同，软件测试的目的是尽可能多地发现软件中存在的错误，即通过测试来发现错误，而软件系统的排错主要目的是进一步诊断和改正程序中潜在的错误。软件测试和软件排错往往是紧密联系在一起的。,软件系统排错是一项具有很强技巧性的工作。软件测试结束

47、后，测试人员在分析结果时，只能看到程序错误的外部表现，而错误的内部原因与错误的外部表现没有明显的关系，要确定发生错误的内在原因和位置是一件很不容易的事情。排错是一个通过外部表现找出原因的思维分析过程。排错工作同人的心理因素和技术因素都有关系，需要很强的脑力劳动和丰富的实战经验。排错相比测试来说，缺乏系统的理论研究。所以本节重点介绍软件系统的排错技术。,6.3.2 软件系统的排错过程 1. 错误定位 软件系统的排错与之前的测试紧密相连。如果测试的结果与期望结果存在差异，则排错过程先要找出错误原因才能对应地修正错误。软件系统排错的前提是准确地实现错误定位。排错人员应从分析错误的征兆入手，查找错误的位置。比如在软件测试中发现文件记录中丢失了最后一个支付，这就是一个错误征兆，排错人员需要利用各种信息和经验，来判断问题发生的真正原因，找到有错误的程序单元或语句。一种常见的做法是在整个程序中设置若干打印语句，打印中间结果并查看。这种方法有相当好的效果，但是不宜作为第一位的方法使用。,正确的做法是遵循以下步骤： (1) 透彻地了解所面临的问题。必须深入地研究程序及其执行结果，分析它在什么情况下得出的结果是正确的，在什么情况下得出的结果是错误的。以这个分析为基础，排错人员应提出关于错误性质及其原因的若干假设