软件确保研究进展.doc

第2期方滨兴等：软件确保研究进展117软件确保研究进展方滨兴1，陆天波2，李超1,3（1. 中国科学院 计算技术研究所，北京 100190；2. 国家计算机网络应急技术处理协调中心，北京 100029；3.中国科学院 研究生院，北京 100049）摘 要：对软件确保的概念进行了介绍，指出软件确保主要聚焦于软件的安全性（security）、保险性（safety）、可靠性（reliability）和生存性（survivability），并以此为基础，提出了S3R软件确保模型，然后在战略层面上讨论了软件确保的发展过程，重点阐述了美国国土安全部、美国国防部、美国宇航局的软件确保计划；在技术层面上探讨了确保软件S3R性质的相关技术进展，阐述了正在制定中的软件确保标准。最后指出了软件确保的发展趋势。关键词：软件确保；脆弱性；安全中图分类号：TP393 文献标识码：A 文章编号：1000-436X(2009)02-0106-12Survey of software assuranceFANG Bin-xing1, LU Tian-bo2, LI Chao1,3(1. Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100019, China;2. National Computer Network Emergency Response Technical Team/Coordination Center of China, Beijing 100029, China;3. Graduate University of Chinese Academy of Sciences , Beijing 100049, China)Abstract: Firstly, various definitions of software assurance were discussed, the key properties of software assurance were summarized, and the software assurance model S3R (security, safety, reliability, survivability) was proposed to describe the discipline of software assurance. Then, the software assurance programs of DHS, DOD and NASA were highly introduced as well as S3R development. Finally, the software assurance standards-setting was specified and the development trends of software assurance research were pointed.Key words: software assurance; vulnerability; security1 引言收稿日期：2008-07-28；修回日期：2008-12-20基金项目：国家重点基础研究发展计划（“973”计划）基金资助项目（2007CB311100）；国家高技术研究发展计划（“863”计划）基金资助项目（2007AA01Z446）Foundation Items: The National Basic Research Program of China (973 Program) (2007CB311100); The National High Technology Research and Development Program of China (863 Program) (2007AA01Z446)随着信息技术的飞速发展，尤其是互联网广泛应用，软件日益成为现代产品和服务的核心构件，是关键基础设施建设和运用的重要依赖。由于软件的脆弱性和运行时功能的非预期性，这种高度依赖性对国家关键基础设施形成了巨大风险，使国家经济和国防安全变得十分脆弱，一旦软件发生故障而不能正常运行甚至瘫痪，整个社会就会陷入危机，造成巨大的政治影响和经济损失。2003年2月14日，美国公布了确保网络空间安全的国家战略1，指出构成网络信息空间的基础设施软件和硬件在其设计和开发过程中是全球化的。因为网络信息空间的全球化本质，故现有的脆弱性对全世界是开放的，任何有能力的人在任何地点都可以利用这些脆弱性，而这些脆弱性一旦被利用，其损失是超乎想象的。软件确保（SwA, software assurance）的任务就是把这些风险降到最低甚至消除风险的存在。据调查，软件确保的概念是由Marilyn S. Fujii在1978年软件质量保障会议上首次提出2。作者认为所有用于提高软件质量的方法都称为软件确保方法，更广泛地说，软件确保方法是用于提高软件质量的任何实践、技术和工具。此时的软件确保实质上仅仅局限于软件质量确保，这种观点在相当长的一段时间内得到了人们的普遍认同。在世纪之交，软件确保的概念开始被用来表示软件的可确保的安全性（类似于用信息确保来表示信息的可确保的安全性一样）。软件确保可从不同的角度，用不同的方式进行定义。CNSS把软件确保定义为：软件确保是对软件无漏洞和软件功能预期化的确信程度，无论漏洞是有意设计的，还是在软件生命周期的任意时刻无意插入的3。美国国土安全部(DHS)对软件确保的定义4强调了具有可确保性的软件必须具备的性质：1) 可信赖性不存在可被利用的漏洞，不管是恶意的还是无意插入的（与CNSS的定义类似）；2) 可预见性有理由确信软件在执行时功能是所预期的；3) 可符合性这种有计划的、系统的、多学科的有效方法能够使得软件加工和产品符合相应的要求、标准和过程（与NASA的定义类似）。NASA把软件确保定义为：软件确保是有计划的、系统的一整套活动，目的是确保软件生命周期过程和产品符合要求、标准和程序5。OMG (object management group)把软件确保定义为：软件确保是对满足于已建立的商业和安全目标的可证明的信任6。IATAC和DACS则认为软件确保是确信软件可信赖性的基础，它要求软件持续地呈现出所有需要的性质（即使出现了有意的故障）以确保软件在运行中的可信赖性。从实践上说，这种软件必须能抵抗绝大多数攻击；对于不能抵抗的攻击，必须尽可能地容忍；在遭受到任何不能抵抗或容忍的攻击后，能够包容攻击所带来的危害，并尽可能快地恢复到一种正常的状态79。可以看出软件确保的多种定义之间是互为补充的，并且就软件可确保的安全性这一问题来说，各种定义之间差别甚小。所有定义都包含了这样一种思想，即软件确保必须提供一种合理的确信级别，也就是确信根据软件需求，软件执行了正确的、可预期的功能。另外，软件功能不能被直接攻击或植入恶意代码所破坏。这正是软件确保目前的主要立足点。与软件质量确保相比，软件确保主要聚焦于软件的安全性（security）、保险性（safety）、可靠性（reliability）和生存性（survivability）。当前，软件确保已成为安全的核心10，是多门学科的交叉，如图1所示。图1 软件确保所涉及学科2 软件确保模型经过详尽搜索，目前国际上还没有提出任何软件确保模型。借鉴文献11, 12中信息确保模型的思想，提出了S3R(security, safety, reliability, survivability)软件确保模型，如图2所示。S3R软件确保模型包括软件状态、软件确保服务、软件确保措施及时间4个维度。图2 S3R软件确保模型软件状态是指软件开发生命周期中的各个阶段。生命周期通常包括概念、需求、设计、编码、测试、集成、运行、维护以及采购等阶段，在每个阶段中可以进行粒度更细的划分。在不同的开发阶段，所关注的服务以及所采取的相应措施应有所不同。2004年美国第二届国家软件峰会所确定的国家软件战略中认为软件确保目前需要提供4个方面的核心服务，即安全性、保险性、可靠性、生存性13。软件确保措施包括战略、技术、人员3个方面。时间维表示软件确保的概念、技术、服务等会随着时间向前推进。3 软件确保战略1991年，美国国家科学院发布了至今被广为引用的书籍14，该文第4节讨论了构建安全软件系统的编程方法，同时试图回答安全软件开发与其他软件开发的差异。GAO/AIMD-99-107报告建议国防部在关键领域加强安全软件标准的研究，以实现安全软件的开发15。GAO-04-706报告建议通过好的软件工程减少软件漏洞16。1998年5月克林顿总统在第63号总统令(PDD-63)中提出了美国国家信息安全目标，并为该目标制定了长达200页、跨度10余年的执行计划17。为了达到此目标，2000年1月克林顿政府发布了信息系统保护国家计划18，将信息安全保护分为10项内容，涉及到脆弱性评估、人才培养、隐私保护等。布什政府认为，美国计算机网络的脆弱性可能使美国的关键基础设施和信息系统的安全面临严重威胁。因此，美国在确保网络空间安全的国家战略报告中确定了在网络安全方面的3项总体战略目标和5项具体的优先目标1。其中的3项总体战略目标是：1）阻止针对美国至关重要的基础设施的网络攻击；2）减少美国对网络攻击的脆弱性；3）在确实发生网络攻击时，使损害程度最小化及恢复时间最短化。5项优先目标是：1）建立国家网络安全反应系统；2）建立一项减少网络安全威胁和脆弱性的国家项目；3）建立一项网络安全预警和培训的国家项目；4）确保政府各部门的网络安全；5）加强国家安全与国际网络空间安全的合作。就第二项优先目标来说，报告在其214条行动与建议中指出：国土安全部将推动国家公共与私营部门共同努力推广最好的实践与方法，目的是提高软件代码开发过程的完整性、安全性和可靠性，减少开发过程中引入错误代码、恶意代码和陷门的可能。报告显示，网络的便捷使美国社会越来越依赖于信息技术，信息技术的发展已使之成为21世纪美国发展的支柱，而网络成为美国发展的神经中枢。确保网络安全已经被提升为美国国家安全战略的一个重要组成部分，其关键在于美国公共与私营部门的共同参与，以便有效地完成网络预警、培训、技术改进、脆弱性补救等工作。2005年4月14日，美国政府公布了美国总统信息化咨询委员会（PITAC）向总统布什提交的紧急报告网络空间安全：迫在眉睫的危机19，指出软件是美国网络和计算系统漏洞的一个主要来源，认为过去10年中美国保护国家信息技术基础建设工作是失败的。短期弥补修复不解决根本问题。国防部的GIG（global information grid）工程耗资上千亿美元，而安全漏洞并没有减少。为改变无穷无尽打补丁的封堵防御策略，从整体体系上解决问题，报告提出了10个优先研究项目，其中第3个即是软件确保。2005年4月美国在第二届国家软件峰会上形成了美国国家软件战略报告13，该报告详细描述了未来10年美国为了确保安全和竞争而制定的国家软件战略，核心就是发展可信软件（trustworthy software）,即确保软件是可靠和安全的。美国总统办公室在2006年4月发布的网络空间安全和信息确保研究及发展联邦计划报告中阐述了49个研究方向，并指出了其中13个需要优先资助的方向，软件确保即在其中20。近年来，软件确保已成为学术界研究和讨论的热点问题。美国国防部资助的期刊CrossTalk: The Journal of Defense Software Engineering从2005年到2007年，每年出版一期软件确保专刊。IEEE Security and Privacy杂志对软件确保的讨论也逐渐活跃起来。美国国土安全部和国防部（DOD）联合发起了软件确保论坛（software assurance forum），目的是聚集来自政府、业界和学术界对软件确保感兴趣的人们一起讨论和传播最好的实践和方法，以提高软件的完整性、安全性和可靠性。2007年3月，在美国维吉尼亚州召开了第一届OMG软件确保研讨会。2007年12月，在美国迈阿密召开的第23届国际计算机安全应用年会（ACSAC）上首次举办了软件确保研讨会。2007年9月，第26届国际计算机保险性、可靠性和安全性会议（SAFECOMP）在德国纽伦堡举行，会上首次举办了一个关于软件可信赖性的研讨会。2001年9月，NASA首次举办了SAS（software assurance symposium ） 年会。截至2008年9月，NASA已经举办了8届SAS年会。除此之外，一些著名的信息安全会议，如USENIX SEC、IEEE DSN等也开始关注软件确保。美国国土安全部资助了US-CERT BSI项目，该项目的目的是建立好的软件确保标准，从软件内部确保软件的安全性。项目网站上21汇聚了关于软件确保的理论和实践方面的详尽资料。3.1 美国国土安全部软件确保计划美国国土安全部于2003年6月成立了NCSD (the national cyber security division)，其主要工作是与公有部门、私营部门和国际实体协作，确保网络空间安全及美国的网络空间资产，并协助实施确保网络空间安全的国家战略1。NCSD的战略目标是保护网络空间基础设施，具体就是：1）建立和维护一个有效的国家网络空间响应系统；2）实现一个网络空间风险管理计划以保护关键基础设施。软件确保是NCSD实现其战略目标的一种措施。确切地说，软件确保是美国国土安全部的一项旨在提高软件完整性、安全性和可靠性的主动战略。国土安全部软件确保计划是基于确保网络空间安全的国家战略1中第214条行动建议的。软件确保计划主要解决软件的可信赖性、可预见性和可符合性3个方面的问题。作为国土安全部努力降低风险计划的一部分，软件确保计划努力减少软件脆弱性、最小化漏洞可被利用性，并且努力提出增强可信赖软件开发过程和产品的方法。所提出的软件确保框架鼓励生产、评估和获取高质量的安全软件。国土安全部软件确保计划为整个软件生命周期中如何解决人员、过程、技术和获取提供了一种框架性的综合策略。处理安全缺陷和漏洞的传统方法是补丁管理，该计划寻求从传统方法转变到在整个软件生命周期中对软件产品的开发和应用进行例行检查监督，以确保软件的可信赖性、高质量和安全性。国土安全部软件确保计划目前成立了7个软件确保工作组，分别对软件确保的相关问题进行研究。截至目前，国土安全部已发布了一些关于软件确保的指导文档。CBK(common body of knowledge)草案22为大学、研究所等科研机构的教师设计安全软件工程课程提供了一个基础。为了对软件开发人员进行培训，国土安全部对CBK草案进行了补充，并发布了一份补充文档EBK(essential body of knowledge)23。文献24描述了软件生命周期中的安全保护问题，目的是生产出安全的软件产品。为了定性和定量地评估软件所提供的确保程度，DHS软件确保计划于2008年5月发布了软件确保度量指导文档25，该文档为定量评估软件确保技术被集成到软件生命周期过程中的程度，以及从这些过程所生产出来的软件的可信赖性提供了一种方法。为了解决安全软件的获取问题，DHS软件确保计划于2007年9月10日发布了一份由科研界、业界和政府联合制定的指导文档26，以解决不同部门在软件获取过程中所关注的问题，该文档的目的是就如何在软件获取过程（包括计划、合同、实现、接收和维护等阶段）中融入软件确保提供指导。2007年9月30日，DACS(data and analysis center for software)针对软件项目管理发布了报告27，目的是收集和展示软件确保是如何影响软件项目管理的，并为量化软件确保对软件开发的影响提供了工具和资源。国土安全部软件确保计划还资助了SAMATE28、CWE29等软件确保项目。3.2 美国国防部软件确保计划美国国防部软件确保计划的成立源于DSB（the defense science board task force）1999年12月的全球化与安全年度报告30。报告建议国防部建立软件确保计划，以增强国防部处理因对国外生产的商业软件的依赖所导致的潜在风险，这些建议在2003年7月得到了回应。同年，ASD/NII（the assistant secretary of defense for networks and information integration）建立了软件确保计划，以便在把商业软件应用于政府环境之前对其风险进行检查。紧随着软件确保计划的成立，ASD/NII在2004年12月联合OUSD/AT&L(the office of the undersecretary of defense for acquisitions, technology and logistics)成立了国防部软件确保老虎队，目的是研究减少联邦政府遭受这些风险的整体战略。借助于政府和业界的支持，软件确保老虎队提出了减少软件确保风险的指导策略和需要重点解决的问题。3.3 美国宇航局软件确保美国宇航局（NASA）是较早从事软件确保研究的机构。早在1989年9月就发布了软件确保指导书31，对软件确保的概念、目的和整个过程进行了详细的描述。NASA软件确保是一项总的风险识别和安全减轻战略，目的是确保软件产品是高质量和运行安全的。1992年11月NASA发布了软件确保标准32，详细阐述了软件确保活动及其研究内容。2004年7月，NASA发布了新的软件确保标准5，对软件确保进行了更为详细的阐述。新标准指出，对于NASA来说，软件确保由以下5门学科构成：软件质量（包括软件质量工程、软件质量确保、软件质量控制）、软件保险性、软件可靠性、软件核查和验证（V&V, software verification and validation），以及独立软件核查和验证(IV&V, independent verification and validation)。NASA GSFC软件确保网站上33给出了软件确保5个学科的详细介绍。在新标准发布不久，NASA在其网站上34公布了新的软件确保指导，该指导从10个方面对软件确保进行了非常详细的阐述。由NASA资助的NASA RSSR(reducing software security risk)计划旨在定义一套形式化分析方法，以便把安全性融入到现存的或正在形成的研发高质量软件和系统的实践中。美国国家安全局（NSA）软件确保中心、NRL(naval research laboratory)、NIST、OMG等机构也在积极从事软件确保的研究。值得一提的是为了促进软件确保的研究，OMG成立了软件确保特别兴趣组（OMG SwA SIG，/），任务是建立软件可信赖性信息分析和交换通用框架。SwA SIG的一项值得提及的项目是软件确保生态系统（the software assurance ecosystem），它是软件确保需求、论证和证据等相关信息交换的通用框架。4 软件确保技术虽然各机构对软件确保的概念定义略有不同，但多种定义之间却相互补充，并主要聚焦于软件的安全性、保险性、可靠性和生存性方面。关于这4个性质，已分别有众多学者在不同学科或领域中进行了研究，并发表了大量高质量的文章，也有不少学者分别对以上性质进行了很好的综述3540。下面分别对以上性质进行简要阐述，旨在帮助读者整体性地了解软件确保中的安全性、保险性、可靠性和生存性。4.1 软件安全性软件安全性是指软件在被恶意攻击时，其功能能够正确执行36。安全性要求开发人员尽量保证软件在执行过程中只执行预期的操作，避免非预期行为的出现。大量研究表明，在软件开发周期的早期阶段考虑安全性，学习和理解常见威胁、安全的设计方法、风险分析及测试对于软件的安全性至关重要。在软件安全工程中，微软公司41及McGraw36曾分别提出2种安全开发生命周期模型（SDL, security development lifecycle），用于指导开发人员在软件开发过程中保证软件的安全性，这2种模型在工业及学术界产生了重要影响。在需求阶段，开发人员必须明确软件可能遭受的攻击及相应的缓解措施。为描述安全性的需求，常见的方法有Misuse cases42、Abuse case43、Security use cases44等。其中，Sindre和Opdahl提出的Misuse case提供了一种系统的方法，用于刻画系统非预期行为。它对Use cases的表示方法进行了扩展，使得Misuse cases与Use cases可以在同一用例图中，以刻画安全性需求与其他需求的联系。此方法可以描述Misuse对Use产生的影响及Use对Misuse提供的反制措施；McDermott和Fox提出的Abuse case允许开发人员从攻击者的视角，刻画可能对系统产生危害的交互，与Misuse cases不同，Abuse case与Use case不能在同一个用例图中，因此Abuse与Use不存在联系，它针对的主要是安全性需求及其与设计、测试的联系。文献45对安全性相关的需求进行了分类，以指导开发人员理解需求阶段的安全性。文献46对常见的安全需求工程方法进行了总结，对各方法的步骤进行了阐述，并进行了对比。在分析设计阶段，UML是一种常见建模方法，不少学者基于此对安全性进行了研究。文献47对UML进行了扩展，提出了UMLSec用于安全性软件的建模，它加入了新的标示用于描述安全性。文献48用SPIN模型检验工具对UMLSec模型进行验证。文献49开发了一系列工具用于分析UMLSec模型。文献50提出SecureUML对基于角色的访问控制策略进行建模。在编码阶段，常见的与安全相关的缺陷是应当注意的。文献51对C、C+中字符串类型及整型变量所引起的安全性问题进行了阐述并给出了建议。文献52提出了一种编码约定的方法用于安全软件的编码，微软和McGraw推荐使用安全编程实践指导代码编写。当代码完成后，静态分析是一种常见的检测程序中错误的方法。静态分析方法对程序代码进行扫描，通过控制流分析、数据流分析、信息流分析、语法检查、范围检查等方法检测程序中可能引起安全问题的漏洞。文献53提出了MC方法，使开发人员可以针对特定系统及安全规则对编译器进行扩展以检查代码中的错误。文献54提出MOPS模型检验器，用于检查C程序中的时态属性。文献55利用整数范围分析法，查找C程序中的缓冲区溢出问题。文献56提出类型分析方法，描述及分析C语言中的安全属性。文献57提出一种流敏感的类型分析方法用于检测类型转换错误和内存错误，微软公司的PREfix、PREfast等静态分析工具已成熟地用于其产品的开发。文献58对主要的静态分析技术及方法进行了总结。软件安全性的测试与传统软件测试不同，安全性软件的测试关键之处在于如何测试软件的非预期行为。一种方法是基于已知的漏洞攻击程序构造测试用例。虽然这一方法基于已知的攻击模式，对尚未发现的漏洞无能为力，但这种方法可以避免大量通过已知漏洞攻击模式进行的攻击59。为了能对未知的漏洞进行测试，McGraw建议对测试人员进行漏洞及攻击模式方面的培训，使其尽可能多地拥有攻击者的知识，从攻击者的思维模式进行安全测试，并做了尝试60。4.2 软件保险性保险性是指“软件的运行不会导致系统发生重大事故”。国内有学者也将其翻译为安全性、可靠安全性或防危性。软件保险性的概念最早是在Mil-Std-1574A61中被提及，它要求通过对软件的分析，确定和消除空间及军事系统中由关键保险性软件（safety critical software）引发的错误。而后Leveson及一些学者逐渐意识到软件保险性应是一个系统级的概念，而不仅仅是软件的范畴62。因为即使软件正确，不当的环境和操作失误也都会导致事故的发生。因此对保险性而言，软件应看作是系统的一个或多个组成部分，软件保险与否只能将其作为整个系统的一部分来进行评价。保险性在很大程度上与人为因素相关，如操作人员理解系统的反馈信息不当、操作失误从而引发重大事故，因此仅仅以系统为主线进行考虑是不够的。对设计者和分析者而言，不仅要关注系统行为还需要关注操作者与环境的交互，这为保险性软件的设计带来了挑战。有学者认为应当设计一种整合的方法以能够对系统、操作人员和环境之间交互进行建模63, 64。从软件开发生命周期考虑，需求阶段的错误是造成事故的主要原因。文献65对保险性相关的需求进行了总结，将保险性相关的需求分为四类：保险性需求（safety requirement）、重大保险性需求（safety-significant requirement）、系统保险性需求（safety-system requirement）及保险性约束（safety constraint），用以指导开发人员理解和分析保险性相关的需求。危险性分析（hazard analysis）起始于软件开发的需求阶段，其任务是查找系统中潜在的危险因素，分析系统中故障发生的可能性，它在软件保险性开发中起着重要作用。危险性分析的经典分析方法有：故障树分析法（fault tree analysis）、事件树分析法（event tree analysis）、失效模式与影响分析法（failure modes and effects analysis）、危险与可操作性分析法（hazard and operability analysis）等。对保险性需求的规格分析技术除了危险性分析方法外，众多学者还对形式化方法进行了研究。MOD00-55等标准中也明确指出，保险性需求的规格说明须用形式化的方法进行描述。通过形式化方法对需求进行规格说明的方法很多，方法的选择取决于系统的不同特点、应用领域及开发人员的知识储备。主要的方法有模型检验、定理证明、Petri网等，这些方法还在不断改进和发展。文献66将CPN及PVS相结合的方法对保险性需求进行分析。由于时间属性对安全关键系统的重要性，为描述与时间相关的保险性需求，文献67提出了一种用p-time Petri网对需求进行规格及分析的方法。文献68将故障树与Petri网结合，使其能对动态行为及多状态组件进行建模。文献69将SMV与故障树结合，分析保险性需求。文献70提出了状态/事件语义与故障树结合的方法，以综合确定状态机适合描述软件行为、Markov链适合描述模型失效概率及故障树适合描述因果链的优点。需要指出的是，在保险性软件测试的充分性评估方面，与传统软件考虑有所不同。主要是由于软件保险性所关注的是导致系统发生灾难性事故的小概率事件，因此采用传统基于软件运行剖面的统计测评方法难以有效地发现这些设计缺陷以提高其保险性。针对这一问题文献71曾基于重要性取样原理，利用故障注入方法对该部分软件进行压力测试，使其在有限的时间内暴露出更多的缺陷。4.3 软件可靠性软件可靠性的研究起源于20世纪60年代，1967年Hudson提出的“故障生灭论”被视为是软件可靠性研究方面的第一篇论文72。IEEE对软件可靠性的定义为：在特定条件和特定时间内，软件不引起系统失效的概率，称为软件可靠性。该概率是关于系统输入和系统使用的函数，也是软件中存在错误的函数。软件可靠性模型是软件可靠性研究领域中最早进行研究的一个方面，软件可靠性模型是指为预计或估算软件的可靠性所建立的数学模型。自1972年Jelinski和Moranda提出首个可靠性模型Jelinski-Moranda模型至今，已有上百种可靠性模型，并且每年都不断有新的模型被提出。其中比较经典的模型除了Jelinski-Moranda模型73外，还有Musa执行时间模型74、Goel-Okumoto模型75、Bev Littlewood贝叶斯模型76等。文献77对早期的模型进行了总结，将模型分为两大类：预测模型和评估模型。预测模型针对开发周期的早期阶段，如：需求阶段或初步设计阶段，在开发前对软件开发过程中的风险进行估计。评估模型是在测试和运行阶段对失效数据进行收集，以此为基础对软件进行可靠性评估。由于评估模型在软件开发的测试阶段，不断地检测并排除软件故障，使软件可靠性得以提高，因此这类模型也称为可靠性增长模型。文献78从强度衰减曲线的角度将可靠性增长模型分为指数、帕勒多、威布尔、伽马、集合衰减等几类。文献79将可靠性模型分为确定性模型和概率性模型，并将概率性模型分为了错误散播模型、失效率模型、曲线拟合模型、可靠性增长模型、马尔科夫结构模型、时间序列模型、非齐次泊松过程模型。Pham在文献79中指出，软件可靠性模型在过去30多年的研究中，许多模型都没有将软件开发过程中的信息考虑其中，即软件可靠性的评估仅仅基于失效数据，而未考虑软件的开发环境，他对软件开发环境中的五类共32个因素进行了总结，并将其引入软件可靠性评估中。目前还没有一个通用的模型能适用于所有的案例。所以在众多的模型中面临着模型选择问题。Schick和Wolverton尝试使用模型对比的方法80来选择最优模型。但是这一方法在当时遇到了2个困难：一是缺乏好的失效数据；二是缺乏公认的对比准则。之后文献81发布了50个高质量的失效数据集，在一定程度上解决了第一个困难；文献82综合该领域众多专家的建议，提出了一个公认的对比准则，解决了第二个困难，使得模型对比方法选择最优模型变得可行77。虽然如此，模型对比方法对选择特定的模型仍然非常困难。许多学者开始趋向于在相同的失效数据集上使用不同的模型，再根据其最终效果选择最佳的模型83,84。文献85将可靠性模型按软件开发周期的不同阶段进行分类，并定义了一系列模型选择准则，以此为基础提出了软件可靠性模型选择的算法，利用该算法在不同的开发阶段应用不同的可靠性模型。4.4 软件生存性虽然生存性的相关研究早已出现在军事、电信等领域，但目前为止尚未有统一的定义。关于生存性的定义最早由Deutsch提出：当系统的一部分遭受攻击已经瘫痪时，关键服务仍能够使用的程度86。此后以Ellison等人为代表的CMU/SEI研究小组，给出了针对信息系统的生存性定义：生存性是系统在遭受攻击、故障等事件下还能实时提供关键服务的能力87。基于Ellison的定义，不少学者提出了类似的生存性定义。然而上述的定义只是给出了信息系统生存性的定性描述，都未给出其量化标准。Knight认为生存性应是一个可度量的系统特征，使开发人员能够有指标参照，并通过一系列的生存性规范来判断系统的生存性88。针对众多的生存性定义，Westmark对其进行了总结，并给出了进行生存性定义的建议，认为生存性的定义应包含系统、威胁、自适应性、服务可持续性和实时性等5个关键部分89。虽然生存性的定义尚未得到学术界的统一，但众多学者基于自身对生存性定义的理解，为提高系统生存性做了大量工作。提高生存性的方法主要分为两类：一类是将生存性需求贯穿到系统设计的整个周期中；另一类是在已有系统中利用相关技术来提高生存性。文献90对第一类方法进行了很好的整体性阐述，分别从需求、设计、开发、测试几个阶段对生存系统的开发进行了研究，指出了生存系统的需求及生存性的关键属性，以此为基础对体系结构及组件的设计及分析进行了阐述，介绍了开发过程中须遵循的原则及生存系统的测试方法。文献91对软件开发生命周期中的生存性进行了研究，对生命周期中每一阶段行为所对应的生存性要素进行了阐述，列举了可用于生存性目标的若干技术。文献92从体系结构的设计方面进行了研究，指出了在体系结构设计及开发过程中所遇到的问题及解决方案。第二类方法是在原有系统的基础上增强系统的可生存性，这类方法通常是在系统中加入自动入侵响应的技术、冗余异构技术、自适应技术、入侵容忍技术等，该方法基于现有系统，可操作性强，已有不少成功的案例。生存性的分析评估是提高生存性过程中不可或缺的。学术界提出了不少生存性分析方法及模型。在现有的方法中，SNA方法93曾成功地对一些商业和政府系统进行了生存性分析。文献94通过图论的方法来分析系统的生存性。文献95将系统中的节点用有限状态机进行表示，通过模型检验、贝叶斯分析等方法对系统的生存性进行了定性和定量分析。文献96定义了一个故障过程模型，通过故障在各种状态之间的迁移概率来分析系统的生存性。文献97利用CSL逻辑对生存性进行描述，用CTMC模型对系统建模，使用模型检验的方法对生存性进行了定量分析。4.5 软件确保标准就软件确保标准的研究而言，NASA在1992年发布了软件确保标准及指导，并在2004年7月对1992年的软件确保标准进行了修订，发布了新的软件确保标准及指导。此外并没有专门的软件确保标准，而主要是关于软件保险性、安全性、可信赖性以及软件质量方面的标准，如ISO/IEC 16085, ISO/IEC 15408, ISO/IEC 17799, ISO/IEC 12207, ISO/IEC 21827, ISO/IEC 15026, ISO/IEC 15288, ISO/IEC 15939，SSE-CMM等。图3 ISO/IEC 15026软件确保框架由于软件确保跨越了不同的学科，目前的众多标准针对不同的应用领域和属性使用不同的术语表达及方法，这使得用户必须同时关注多个标准，无疑增加了使用者的负担。目前ISO/IEC JTC1/SC7正在制定系统和软件确保国际标准15026。该标准旨在基于以上各特定领域的标准，提供一个通用的框架，并为后续标准的修订打下基础。该标准将软件确保定义为“系统和软件确保聚焦于在系统和软件生命周期中进行风险管理和保险性、安全性、可信赖性确保”。图3给出了正在制定的ISO/IEC 15026中的软件确保框架。该标准草案包含4个部分，其中草案的第3和第4部分尚在制定当中。草案的第1部分对软件确保中涉及的基本概念进行了介绍，以统一不同学科及众多标准中与软件确保相关的概念，并对该标准与其他标准的关系进行了说明，指出该标准可独立或与其他标准配合使用，对草案4个部分的结构进行了说明。第2部分详细阐述了确保案例（assurance case），包括对使用确保案例后产品应该产生的结果进行了说明，给出了确保案例的组成要素及相互关系，并对一般性需求（general requirement）中确保案例的要求做了规定，对确保案例中如何描述断言（claim）进行了要求，指出了断言中使用条件和限制时应注意的问题，对确保案例论证（assurance case argument）的形式、方法及特点进行了介绍，给出了确保案例证据（assurance case evidence）及假设（assumption）的使用要求，对确保案例的生命周期进行了阐述。草案的第3和第4部分目前只有一个方向性的介绍，具体细节尚在制定之中。第3部分将对系统完整性等级（system integrated level）进行阐述，给出建立系统完整性等级的方法。第4部分将阐述如何将确保案例集成到软件开发生命周期之中。该标准草案不但将对学习、指导、训练、讨论、查阅软件保障中的相关问题起到重要作用，同时将有助于希望融入该标准的相关标准的发展与修订。5 结束语软件确保的研究从21世纪初开始在美国受到了高度重视，美国国土安全部、国防部、国家安全局、NIST、US-CERT等部门都对软件确保展开了研究，并取得了一些初步成果。目前，很少见到其他国家在软件确保研究方面的报道，我国有少部分学者开始从事这方面的研究，但尚未见到公开发表的成果。但随着软件确保对安全软件生产乃至网络信息安全影响的不断扩大，越来越多的研究人员已经开始注意将信息安全向系统和软件开发过程这一源头推进。作者认为当前软件确保的研究需要着重从以下几个方面展开：1）S3R软件开发过程模型和方法；2）S3R需求与策略；3）S3R结构与设计；4）S3R测量与分析；5）软件代码分析技术；6）软件确保案例研究。参考文献：1National strategy to secure cyberspace, the white houseEB/OL. /pcipb, 2003.2FUJII M S. A comparison of software assurance methodsA. Proceedings of the 1st Annual Software Quality Assurance Workshop on Functional and Performance IssuesC. New York, USA, 1978. 27-32.3Committee on national security systems, national information assurance (IA) glossary, CNSS instruction No. 4009EB/OL. ss. gov/Assets/pdf/cnssi_4009.pdf, 2006.4/EB/OL.5National aeronautics and space administration, software assurance standard, NASA-STD-8739.8 w/change 1EB/OL. http:/www.hq. / office/codeq/doctree/87398.pdf, 2004.6/SoftwareAssurance.pdfEB/OL.7IATAC (information assurance technology analysis center)EB/OL. /iatac/.8DACS (data and analysis center for software) EB/OL. http:/www. /.9SOAR on software security assuranceEB/OL. / iatac/download/security.pdf, 2007.10ROBERT A M. Software assurance programs overviewEB/OL. /docs/swa_washington_2006/SwA_Programs_Ovrvw.pdf, 2006.11MACONACHY W V, SCHOU C D, RAGSDALE D, et al. A model for information assurance: an integrated approachA. Proceedings of the 2001 IEEE Workshop on Information Assurance and SecurityC.New York, USA, 2001.306-310.12MCCUMBER J. Information systems security: a comprehensive modelA. Proceedings 14th National Computer Security Conference. BaltimoreC. USA, 1991. 124-129.13Software 2015: a national software strategy to ensure U.SEB/OL. /nss2report/NSS2FinalReport04-29-05PDF.pdf, 2005.14National Research Council (NRC). Computers at Risk: Safe Computing in the Information AgeM. Washington, DC , National Academy Press, 1991.15Government Accountability Office (GAO), DoD Information Security: Serious Weaknesses Continue to Place Defense Operations at RiskR. Report GAO/AIMD-99-107. GAO, Washington, DC, 1999.16Government Accountability Office(GAO), Information Security Continued Action Needed to Improve Patch ManagementR. Report GAO-04-706. GAO, Washington, DC ,2004.17The white house washington, presidential decision directive/ NSC-63EB/OL. /irp/offdocs/pdd/pdd-63.htm, 1998.18National plan for information systems protection, the white houseEB/OL. /cybersec-plan.htm, 2000.19CYSEC05Cyber security: a crisis of prioritizationEB/OL. /pitac/