软件安全性研究综述

软件安全性研究综述

第38卷第5期 2011年5月 计算机 Computer 科学 Science Vo1.38No.5 May2011

软件安全性研究综述 樊晓光褚文奎.张凤鸣

(空军工程大学工程学院西安710038)(94795部队芜湖241000).

摘要软件是安全性关键的软件密集型系统(比如综合航电系统)的一个重要安全因子,软件安全性已逐渐成为软

件工程和安全工程交叉领域的研究热点之一.对软件安全性的内涵与外延进行了剖析,给出了软件安全性定义.讨

论了软件安全性的度量模型.着重从软件工程的视角对软件安全性的开发过程,设计方案,评估方法与认证技术等现

状进行了综述,并探讨了软件安全性的研究方向.

关键词安全因子,软件安全性,软件工程,安全工程,系统工程,安全性关键系统,综合航电

中图法分类号TP311.5,N945,V247文献标识码A SurveysofSoftwareSafety

FANXiao—guangCHUWen-kuiZHANGFeng—ruing

(InstituteofEngineering,AirForceEngineeringUniversity,Xi'an710038.China) (No.94795Unit0fPLA,Wuhu241000.China)2

AbstractAssoftwareisoneoftheimportantsafetyfactorsinasoftware-intensiveandsafety-c

riticalsystem,e.g.,an

integratedmodularavionics(IMA)system,softwaresafetyistobeamainstreamresearchdirectioninthecrossingfields

betweensoftwareengineeringandsafetyengineering.Thepaperanalysedfirstlythemeaningsandextensionsofsoft-

waresafety,andthengaveadefinitionofit.Measuringmodelsofsoftwaresafetywerethendiscussed.Thepaperfo-

cusedonthestate-of-the-artofsoftwaresafetyfromasoftwareengineeringperspectiveaboutdevelopmentprocesses,

designedalternatives,assessmenttechniquesandcertificationmethods.Thepotentialresearchdirectionsofsoftware safetywerefinallypointedout.

Keyw~lsSoftwarefactor,Softwaresafety,Softwareengineering,Safetyengineering,Systemsengineering,Safety-eriti—

calsystem,Integratedmodularavionics(IMA)

安全性关键系统(safety-criticalsystem,SCS)[1]泛指具有 潜在破坏力的一类系统.此类系统一旦失效,就能够造成严 重的后果,比如人员伤亡,财产损失或环境破坏等.SCS安全 性的核心研究内容是采用各种管理,组织,技术等措施,减弱 SCS各组成要素导致系统进入不安全状态的概率或减轻SCS 失效后果.

近年来,软件在SCS中的应用越来越广泛.从航空航天 领域到核工业领域,从电力系统到医疗系统,软件承担着安全 性关键的指挥控制功能.同时软件在SCS中的应用规模也 与日俱增.比如,在F-22战机的综合航电系统[2中,软件实 现的航电功能高达8O[,软件代码达到170万余行.而在 F-35战机的先进综合航电系统中,软件代码达到500～800 万行.这表明,越来越多的SCS日益软件密集化,逐渐形成 安全性关键的软件密集型系统.

另一方面,由SCS软件引发的事故或事件却频发不断: 发生在2O世纪9O年代的Ariane5运载火箭,SOHO太空船 等5起航天器事故的罪魁祸首是软件l_4;2004年12月20日, 一

架F-22因飞行控制软件故障而坠毁;2007年2月11日, 12架F-22在穿越国际日期变更线时又因软件缺陷问题造成 导航故障,战机被迫在无导航和通信能力下危险返航_6].由 此,软件已成为决定SCS(包括新型航空航天器)安全与否的 重要因素之一.

1软件安全性内涵与外延 1.1软件安全性内涵

\"软件安全性(softwaresafety)\"一词最早出现在1979年 发布的Mil—Std-1574A[标准中,1986年由美国加州大学的 Leveson教授引入计算机科学领域[引.安全性多用于刻画具 有能量,毒性或能够进行质量运动的物理设备或系统,而软件 作为一种寄生性逻辑实体,不会由于能量辐射,毒性挥发,质 量运动对人造成伤害或对环境造成破坏.因此,\"软件安全 性\"至今备受争议,甚至被认为是一个误用的术语_g].

到稿日期:2010—04—13返修日期:2010—0725本文受总装备部国防预研基金项目(9140A17020307JB3201),空军工程大学工程学院优秀博 士学位论文创新基金(BC07003)资助.

樊晓光(1965一),男,博士,教授,CCF会员,主要研究方向为综合航电技术等;褚文奎(1980),男,博士,工程师,CX;F会员,主要研究方向为综

合航电,软件安全性等,E-mail:*****************(~信作者);张凤鸣(1963一),男,教授,博士生导师,主要研究方向为综合航电,信息系统 工程等.

值得指出的是,尽管\"安全\"本身是一个系统问题,作为系 统重要组成要素的软件不会直接危及生命,财产和环境等安

全,但借助软件实现的人机交互却可能【大1软件失效造成人员 误操作从而形成危险.对于无人机交互的嵌入式SCS而言, 也可能因为软件错误地控制系统而造成灾难性后果.以航电 软件为例,飞机在飞行高度低于预期值时,航电软件应及时发 出近地告警提示飞行员,否则容易造成飞机坠毁.由此,Mc— Demlid认为,软件安全性只是软件在系统上下文中对系统安 全性的贡献的速记形式[=l.j.

目前很多标准\"和学术文章都给出了软件安全性 的定义.比较具有代表性的是:

(1)NASA8719.13At:\"软件安全性是指在软件生命

周期内,应用安全性工程技术,确保软件采取积极的措施提高 系统安全性,确保降低系统安全性的错误已经减少到或控制 在一个风险可接受的水平内.\"

(2)Leveson[:\"软件安全性是指确保软件在系统上下文 中执行不会导致系统发生不可接受的风险.\"

文献[14]指出,软件安全性之所以未能有效付诸实践的 两个主要原冈是\"软件安全性概念的开发人员或用户未能正 确理解哪些要素可以确保系统安全\"和\"未能在更大的或更宽 泛的系统中考虑软件安全性\".

根据对软件安全性的理解,给出软件安全性的下述定义: 定义1(软件安全性) SW'_ .

~fety—ISys—safety(SW,H,Lw,Env)dSW 曲

软件安全性(SvC,afety)是指既定软件对既定系统安全 性(Sys—safety)的贡献,衡量的是在特定环境下和规定时间 内不会因软件功能失效或需求缺陷等诱发系统危险的能力. 其中,系统安全性(Sys—safety)受到操作人员(LW),软件

(S,硬件(H∽和外部环境(Env)的共同作用.外部环境 (Env)泛指与该系统交互作用的外部系统或其他要素.比 如,对于飞行控制软件而言,其安全性研究涉及到飞控软件内 部构件之间的交互,飞控软件与飞控系统底层硬件之间的交 互,飞控软件与飞行员,综合航电系统等其它系统之间的交 互.

1.2软件安全性外延

在可信计算l】领域,与安全性(safety)密切相关的术语 还包括保密IC(security),完整性(integrity),可靠性(reliabili— ty),可生存IC(survivability)和可信性(dependability). 鉴于上述术语之间的易混淆性以及国内对部分术语翻译 的不一致性(比如将safety译为防危性[],保险性[\"],将se— curity译为安全性l1]),此处着重阐明安全性与这些术语之间 的区别和联系,以便更好地理解其内涵(见图1). 图1软件安全性及其联系

软件可靠性是同软件安全性一样与失效密切相关并一直 混为一谈的一种软件属性.它衡量的是,在特定条件下和一 定时问内,软件提供连续正确服务的能力.二者之间的区别 和联系体现在:①软件可靠性关注所有的软件失效,而软件安 全性仅关注能够引起危险后果的软件失效;②如果软件任务 不能完成将影响系统的安全性,那么消除这些软件失效将同 时提高软件的可靠性和安全性;③消除那些能够引起危险后 果的软件需求缺陷可能提高了安全性,却对软件可靠性无益; ④如果软件存在安全性需求方面的缺陷,即使消除所有的软 件失效(尽管提高了软件可靠性)也不一定能提高软件安全 性;⑤可靠的软件可能不安全,安全的软件并不一定可靠.有 关软件可靠性的内容参见文献E182.

软件保密IC:融合了可用性(availability,指某项服务在 某个时刻可以获得的概率),隐私IC(confidentiality,指软件已

存储信息,代码,数据不被访问的能力)和完整性(integrity,指 软件不被意外或未授权修改的能力),着重关注如何保护软件 使其不被恶意攻击.软件安全性和软件保密性之间的联系和 区别主要表现在:①二者都与威胁或风险相关.安全性主要 处理危及人员生命财产安全的威胁,而保密性主要消除危及 数据私有性的危险;②安全性需求和保密性需求可能都会与 某些重要的功能需求或任务需求相冲突;③安全性和保密性 需求都需要在系统层面谋划布局,且这些需求在系统上下文 外是难以处理的;④安全性和保密性都需要一些极其重要的 需求,这些需求决定了系统能否被使用;⑤保密性着重关注的 是对分级信息进行的未授权恶意访问行为,而安全性多关注 的是无意行为.有关软件保密性的综述参见文献[19,2o]. 软件可生存性描述的是当软件系统的一部分遭受攻击陷 入瘫痪时,关键服务仍能够使用的程度.文献[21]认为可生 存性应包含系统,威胁,自适应性,服务可持续性和实时性等 5个关键部分.软件可生存性与软件安全性之间的联系在 于:①确保软件生存的服务可能同时确保软件安全IC;②生存 性丢失的系统可能依然安全;③不安全的系统可能具有生存 性.有关软件可生存性的内容参见文献E21,2el. 软件可信性包括可用性,可靠性,安全性,隐私性,完整 性,可维护性(maintenance)6个属性_].它强调的是软件行 为在任意操作条件下都是可预测的,能够抵御其它软件,病毒 以及一定的物理干扰造成的破坏.有关软件可信性的综述参 见文献E15,23]. 2软件安全性度量模型

SCS的本质是以风险换利益.从辩证的视角看,SCS没 有风险就没有利益.换言之,\"安全\"是一个相对的概念.为 了追求某些利益,在技术,效能,时间,费用等约束下,只要风 险降低到某种程度(称之为安全闭值),即认为SCS是安全可

接受的.SCS安全阈值的界定是定性的,并因各种SCS而 异,由此给SCS软件安全性度量带来了诸多问题]. 当前度量软件安全性的工作主要体现在两个方面,即基 于风险的和基于缺陷的测度方法. 2.1风险测度法

风险测度法是度量安全性广为采用的一种方法.该方法 以风险总值(Risk)作为安全性指标,以每一个危险(hazard) 发生概率p(hazard)和该危险可能导致的后果e(hazard)作 为衡量风险的要素.一种普遍接受的计算模型是: Risk一∑P(hazard)×~(hazard)(1) baird 9

EX)-178BCj要求SCS软件失效率为1O～1O次/d, 时,这就几乎无法借助软件失效的历史统计数据恰当地预测 某项软件功能失效的概率.由此,EricsonE认为式(1)安全 性度量模型不适用于SCS软件.替代地,他提出了一种软件 危险风险系数(softwarehazardriskindex)~r]度方法.该方法 与控制硬件的软件代码类别以及软件失效的后果严重性有 关,通过一系列的查表方法最终可获得软件危险风险系数. Fenton认为,度量软件安全性应当考虑其它控制事件, 触发事件对危险发生的影响以及后果减轻措施对安全性的影 响.如果不考虑上述两点,那么在式(1)中分配危险发生 概率和危险后果就毫无意义.这种观点是十分合理的.对于 失效的飞行控制软件而言,如果不加以及时控制或处理,就可 能会影响飞行安全,比如F-22坠毁事故E.如果允许飞行员 动态重构飞行控制软件或采取其它控制措施,那么就有可能 消除危险.基于这种思想,Fenton等人开发了AgenaRisk安 全性评估系统.不过,该模型同样也需要输入某种软件失效

概率以及控制事件,触发事件等的成功概率,这就不可避免地 引入主观判断.另外,该模型没有给出风险排序或总风险值, 不便于优先决策.

借鉴可靠性的定义模式,文献[16]尝试用平均危险失效 时间度量SCS软件安全性,并给出了安全性评估指标和可靠 性评估指标之间的定量对应关系.由于软件失效率和失效检 测率的不可确定性,实际上该模型并不能发挥效用.此外,鉴 于本文有关软件安全性和可靠性之间关系的讨论,该文献建 立的模型也只有在软件功能失效同时影响安全性和可靠性的 前提下才存在一定的合理性. 2.2残留致险缺陷数测度法

文献E24]试图提出一种多元,多模型,多阶段(3M)的软 件安全性度量框架.该模型希望在开发,使用,变更等阶段分 别采用Holstead模型,模糊模型,经验模型等评估软件功能 复杂性,技术支持,开发水平,测试结果等对软件安全性的影 响,最终分别得到测试前,后的软件残留致险缺陷数.虽然并 未给出相关模型的具体细化方法,也没有说明该指标的具体 用意,但该文献提出了度量软件安全性的一种重要思路,即残 留致险缺陷测度法.

文献E28]分析了缺陷导致危险产生的过程.尽管软件设 计型缺陷是导致危险生成的主要根源,但值得指出的是软件 安全性并不一定与残留致险缺陷数成反比.这是因为取决于 软件运行剖面,只要这些缺陷没有被激活就不会对系统安全 构成威胁.但对于某一款软件而言,我们总可以认为,残留致 险缺陷数越少,软件安全性就越高.

文献E143基于McCall软件质量模型提出了一种SCS软 件安全性的度量框架.在该框架中,软件安全性与系统危险 分析,需求完整性,基于安全性约束条件的设计,运行时管理, 安全性关键的测试等有关.这与文献[24]的工作存在异曲同

工之妙.不过,该模型并没有给出具体的单一或多个度量指 标.实际上该模型关注的是如何提高gigs软件安全性. 3以安全性为中心的软件开发过程

Heimdahl[.认为,开发一个安全的系统无外乎4个步骤: ①识别系统危险,定义安全性需求;②确定系统各组成要素如 何触发上述系统危险;③为系统各组成要素派生相应的安全 10?

性需求;④开发上述组成要素,并使其满足对应的安全性需 求.尽管上述过程看起来颇为简单,但开发满足安全性需求 的软件的过程却要复杂得多,往往需要伴随软件开发过程开 展相应的安全工程活动.目前,以安全性为中心的软件开发 过程可以概括为两类,即传统的基于过程的开发方法和日益 兴起的基于模型的开发(model-baseddevelopment,MBD)方 法.

3.1基于过程的开发

当前基于过程的SCS软件开发多采用\"V\"模型[,其目 的是在软件开发的每一阶段生成相应的验证测试计划,使其 免受低层软件开发细节的影响.文献E3o]认为,采用该模型 开发专业领域的软件,还需要-;3融合了系统工程与软件工 程的交叉学科——软件系统工程——一提供目标系统的领域知 识,以便软件工程师充分理解系统需求,从而在软件设计中减 少需求和设计缺陷,增强系统的安全性.图2是文献E31]给 出的基于过程的SCS软件开发模型,该模型在航电工业中应 用较广. ——

软件安全性开发设计—I———-软件安全性评估论证—— 图2\"V\"型SCS软件开发过程

在\"v,,模型左侧,通过在需求规约,体系结构设计,详细

设计,软件实现等阶段分别开展初步危险识别(preliminary hazardidentification,PHI),初步危险分析(preliminaryhazard analysis,PHA),系统安全性初步评估(preliminarysystem safetyassessment,PSSA),共因分析(commoncauseanalysis, CCA)等安全工程活动,分析,识别,派生软件承担的安全性需 求,确保其正确性,完整性,一致性,并使其在软件设计时充分 考虑这些需求.

在\"V\"模型右侧,通过在软件实现,系统集成,测试/验 证/有效性确认,交付使用等阶段开展共因分析,系统安全性 评估(systemsafetyassessment,SSA)等安全工程活动,评估, 论证软件是否满足安全性需求或是否达到期望的安全性级 别.

值得指出的是,软件的安全性\"素质\"主要取决于前期开 发设计(v模型左侧),而不是在软件实现后(V模型右侧)通 过其它保护措施辅助实现.有关上述安全工程活动的目的和 支撑技术参见ARP-4754[.]和ARP-4761_3胡标准. 3.2基于模型的开发(MBD)

在基于过程的软件开发方法中,SCS软件的有效性确认 和验证活动在\"V\"模型右侧进行,此时如果发现软件无法满 足安全性需求或存在安全性方面的重大设计缺陷,再返工弥 补,势必代价巨大.文献[9]表明在该开发方法中,软件有效 性确认和验证所消耗的资源占到整个软件开发的5O～ 7O.这些弊端促使了MBD方法的出现.在MBD中,软件 开发的重心在于构建能够准确反映系统需求的形式化或半形 式化模型.为了实现该模型,MBD要求在需求规约和体系结 构设计阶段就开展有效性确认和验证活动.在特定的集成开 发环境(比如SpecTRM工具集34)中,反映系统功能行为的 需求模型能够自动转换为代码,甚至还能实现自动测试并产 生可信的测试案例.如此,MBD将\"V\"模型转变成了\"Y\"模

型Lj,如图3所示. ..l现一

图3…Y'型SCS软件开发过程

MBD缩减了\"设计集成～测试\"的工作量,降低了缺陷, 错误引入的可能性,节约了开发代价.但由于自动化技术的 引入,也出现了许多新问题.比如,如果模型集成开发环境曲 解了建模语言的语义,那么在该领域模型内执行的所有测试 都是无效的.如果自动生成的代码不正确,那么最终软件实 现可想而知.如果该领域的分析工具不能捕获错误的模型, 那么该模型就可能被接受.目前,尚无法为模型集成开发环 境,代码生成器,分析工具等提供一定的可信级别. 4软件安全性设计 一

个不容争辩的事实是,不管遵循多么严格的开发过程, 软件总是或多或少地存在残留致险缺陷.比如,文献[36]在 对～段遵循IX)-178B开发过程的软件代码进行静态代码分 析时,发现软件缺陷密度高达23个/kIoC,其中6%是致险缺 陷.而MBD广泛应用形式化技术存在的一个严重问题是泰 坦尼克效应l_8](titaniceffect),即过度信任系统假设和模型, 而未能考虑软件失效情况的应对措施.因此,为了实现或提 高软件安全.性,不仅要遵循某些开发过程,还应该在软件设计 中采取积极的应对策略.

Levesonj认为3个可选方案是(按优先级高低):①阻止 或降低危险发生概率的设计,比如采用lockout,loekin,inter— lock等技术;②运行时危险探测与处理方面的设计,比如采用 看门狗,例外处理,前向恢复,后向恢复等技术;③提供对危险 的告警设备,程序及培训.

目前技术方面的研究基本上围绕前两个方案进行.比如 安全内核(safetykerne1)技术l3]试图将整个系统分为功能和

非功能两个组成部分,然后再分级设计安全性.在操作系统 方面,主要通过提供可预知的调度算法确保系统的安全性,比 如文献[38]提出的最短紧急距离优先的多级关键任务调度算 法以及集成式多级防危机制.

为了提高综合航电系统的安全性,ASAAC提出利用各 种故障探测机制分别监控应用软件层,操作系统层,模块支持 层和硬件层等健康状态的思想.对于发生的软硬件故障, 可以通过运行时蓝图提供的信息进行故障屏蔽,故障定位,故 障隔离或系统重构等.此项技术目前还处于理论研究阶段, 尚未工程实现.

5软件安全性分析与评估

针对软件开发和软件产品(即\"V\"或\"Y\"模型的左侧和右 侧)进行安全性分析与评估的目的不同.后者主要是通过一 定的分析和评估手段,确认软件是否实现了期望的安全性或 是否满足了安全性需求,这通常由第三方开展,实际上就是软 件安全性认证活动.有关软件安全性认证内容参见第6节. 此处着重论述针对软件开发的安全性分析与评估方法. 需求是\"纲\设计是\"目\纲举目张是软件实现安全性的 根本前提.LevesonE.认为,软件设计缺乏远见以及规约错误 是影响软件安全性的最主要原因.文献[35j通过单元测试搜 集的证据以及文献[38]对198O一1996年8大灾难性事故原 因的分析结果共同证实了这一论断.由此,目前针对软件开 发的安全性分析与评估工作主要集中在软件需求规约和体系 结构设计两个阶段.

在软件安全性需求分析方面,Leveson¨8认为可以采用实 时逻辑,时间Petri网,故障树分析以及软件故障树分析等技 术.不过实践证明,上述方法都与软件的复杂度有关,普遍存 在工作量较大的问题.很多学者也探讨了需求规约和分析的 改进方法,比如p-timePetri网方法l3,支持向量机和故障树

相结合的方法[4.由Leveson团队开发的SpecTRM工具集 是目前解决需求分析的有效工具之一.

在软件体系结构的安全性评估方面,文献[41]提出的轻 量级PSSA软件体系结构安全性分析方法能够节省工作量和 费用.文献[42]给出了一种基于体系结构权衡分析法的软件 体系结构安全性评估方法.文献[43]提出了一种利用灾难性 事件覆盖度评估软件安全性的思想,不过未能给出软件危险 分析过程.

从确保软件安全性分析的效果看,文献[44]认为软件安 全性分析方法至少应:①提供基本的形式化模型——避免需 求规约的模糊性;②具有合成性能——通过软件构件组合决 定系统的安全性;③采用系统建模方法——软件,硬件甚至人 的行为都以统一的或综合的模型进行建模;④具有充分的表 达能力——能够以较为直接的方式捕获公共失效场景,比如 顺序失效,单点失效;⑤提供自动化支持——能够以最小的代 价重复安全性分析.

目前开展的很多工作都可归结到这5个方面.比如文献 [45]给出了基于进程代数模型和基于信任逻辑模型的安全性 分析方法,文献[35,46]也通过构建基于模糊集,贝叶斯网络 等的形式化模型开展软件安全性评估项目.英国York大学 开发的失效传播和变换符号(failurepropagationandtrans— formationnotation,FPTN)E47,48]是一项颇具代表性的形式化 安全性分析技术.在系统建模和自动化支持方面,SpecTRM 工具集也是典型工具之一. 6软件安全性认证

认证工作一般由第三方展开,主要通过一系列的验证活 动确保产品遵循了相应的设计标准,能够满足需求并且不违 反相关法律法规.SCS软件的安全性认证一般要求确认SCS 11?

软件是否满足了安全性需求. 6.1基于过程的认证

在航空航天领域,认证SCS软件是否满足安全性需求的 一

种常用方法是,论证该软件开发过程是否遵循了某些面向 过程的标准,比如IX)-178B,IEC61508~等.这些标准一般 根据目标软件的开发确信级别(developmentaSsurenlentle- vel,DAI)或安全性完整级别(safetyintegrity1evel,SII)定义 相应的开发,测试过程.只要软件遵循了相应级别的开发,测 试过程,即认为软件达到了相应的DAI或SII,并不给出安 全性需求得到满足的直接证据.这种认证方法一般称之为基 于过程的认证.

尽管遵循严格的开发过程在某种程度上确实能够减少软 件中的残留致险缺陷数,但这并不能说明软件的DAL或SIL 级别越高,失效率就越低,因为其问未必存在必然联系.此 外,基于过程的认证方法既未能给出安全性级别分配指南,也 未能说么推荐各级别所采用工具的依据. 6.2基于产品证据的认证

与面向过程的认证方法不同的是,英国York大学Mc— Dermid领导的团队致力于开发软件产品安全性案例,挖掘软 件安全性需求得到满足的直接证据,从而论证软件的安全可 接受性.这种基于产品证据的认证思路是:①识别软件在系 统上下文能够触发危险的所有失效模式;②提供证据表明这 些失效模式要么不能发生,要么发生概率极小,是可接受的, 要么能被探测并可以控制其影响.

为了形式化描述基于产品证据的认证方法,McDermid 团队开发了目标结构化构造符号(goalstructuringnotation, GSN)E\"删,通过由上而下的安全性目标结构化分解过程,将 系统,软件的安全性目标和需求派生到各个软件构件上,由其

提供满足安全性需求的证据,进而论证软件或系统的安全性. 值得说明的是,在基于产品证据的认证方法中,不断细化 的安全性目标最终依赖的可直接参考的证据可能是基于某种 过程标准开发实现的解决方案.换言之,除非这些可直接参 考的证据都是客观事实,否则与基于过程的认证方法相比,基 于证据的方法只是将假设安全的对象进行了细粒度划分,并 未从本质上解决安全性认证问题.

尽管基于产品证据的认证方法富有吸引力,但如果用来 替代基于过程的认证,还需要解决下述问题:(1)如何确保安 全性案例中的论证的正确性.Greenwell的工作表明很多安 全性案例中存在推理逻辑方面的谬误l5;(2)当前安全性案 例中可接受的证据类型形态各异,缺乏安全可接受的证据类 型的界定.比如有些安全性案例]认为代码达到MC/DC 覆盖测试即认为满足了规约,或者认为自动编码器生成的源 代码能够满足需求规约;(3)目前安全性案例的接受规则尚不 明确,同时存在主观过程]. 6.3累计认证

随着模块化COTS产品在安全性关键的软件密集型系 统中的应用越来越多,针对因系统变更(比如软硬件升级)而 产生的安全性二次认证问题,传统的认证方法面临着巨大的 经济压力.以综合航电系统为例示之:①传统的认证方法主 要基于系统静态配置生成安全性案例.而综合航电系统具有 配置灵活的特点,动态生成的有效配置多达数百万种.穷举 所有的航电配置并开发相应的安全性案例从经济,时间等代 ]2?

价上而言是不明智的.②在系统局部变更时,传统的安全性 认证方法要求重新认证整个系统的安全性.但对于综合航电 系统而言,往往只是数量有限的COTS产品存在安全性问

题,而绝大数COTS产品都是安全的,无须再次认证.鉴于综 合航电系统软件规模巨大,软件局部变更后重新认证整个系 统的安全性势必代价不菲.

解决上述问题的一种可能途径是采用北约标准STAN— AG4626胡提出的累计认证(incrementalcertification)方法. 其初衷是对于局部变更的综合航电系统,寻求只对变更部分 进行二次安全性认证就能确保整个系统安全的方法.如此, 二次认证的代价将只与系统变更部分的规模和复杂性有关, 而与系统整体无关.较之传统的认证方法,累计认证将能节 约大量二次认证费用.

安全性累计认证从2005年提出至今,尽管其技术和过程 尚不成熟,但其思想却展现了巨大的活力,多个组织都在积极 开拓研究.比如,英国国防技术战略部(defencetechnology strategy)目前将安全.陛累计认证作为一项关键的技术优势项 目正在加紧推进研究.欧洲工业航电工作组(industrialavi— onicsworkgroup,IAWG),欧洲民用航电设备局(EURO— CAE)和美国航空无线电技术委员会(RTCA)也就安全性累 积认证的方法,过程,应用进行了探讨.

实现安全性累积认证的一种可能方法是模块化方法. 2002年NASA发布的模块化认证E报告就飞机中使用的软 件构件的模块化认证工作进行了研究,提出了基于假设一保证 推理(assume-guaranteereasoning)的认证方法.该方法尽管 比较合理,但并不完善,因为其定义的规则并不能用于正确的 系统.IAWG认为需要4步才能实现模块化累计认证L55]:① 识别变更场景;②定义安全性案例结构,并进行优化;③识别 出所有的依赖一保证关系(dependency-guaranteerelation);④ 生成安全性论据依托IAWG开发模块化安全性案例的经验 和教训,文献Is6]就安全性模块化累积认证的原因,方法,时 机,人员等基本问题进行了概述.英国国防部标准Ds00-56

issue3E\"定义了模块化安全性案例的开发环境与管理过程. 基于模块化认证研究,EUROCAE和RTCA联合制订了E1)- 124/DO~297标准\"综合模块化航空电子开发指南与认证考 虑\"_58],提供了一种将综合航电系统集成到飞机上的认证方 法,其中包含了软件安全性模块化认证方面的考虑. 结束语本文试图从原因,定义,度量模型,开发过程,设

计方案,评估方法和认证技术6个方面总结软件安全性2O余 年的发展状态和成果.尽管时隔多年,LevesonE.有关软件安 全性的论述至今仍然成立:\"原因很好理解,定义仍然备受争 议,如何实现悬而未决\".

结合本文有关软件安全性的论述,我们认为进一步值得 研究的方向包括:

(1)建立统一的软件安全性度量模型,用作软件安全性评 估的依据.比如,建立一种与提供满足安全性需求的证据数 量和质量,是否遵循标准化开发和测试过程,软件开发环境的 可信性以及软件是否包含容错,纠错机制等有关的软件安全 性定量测度模型.

(2)制定刚性的安全}生认证标准,加强安全性累计认证的 科学理论研究,包括正交的证据类别,证据的可信性,证据的 获取方法等.

(3)鉴于软件安全性还涉及社会问题嘲,技术手段只能提 供有限的解决方案13,59],建立一套集技术,管理和组织于一 体的软件开发方法将是十分必要的. 参考文献

[1]storeyNR.Safetycriticalcomputersystems[M].Boston:Addi— sonWesleyLongmanpublishingCo.,Inc.,1996

[2]褚文奎,张风鸣,樊晓光.综合模块化航空电子系统软件体系结 构综述EJ].航空,2009,30(10):1912—1917

[3]沈玉龙,崔西宁,马建峰,等.综合化航空电子系统可信软件技术 _J].航空,2009,30(5):938945

r4]ievcs0nN(.Theroleofsoftwareinspacecraftaccidents[J]. JournalofSpacecraftandRockets,2004,41(4):564—575 r5]422ndTestandEvaluationSquadron.Executivesummary:air craftaccidentinvestigation,F/A一22S/N00—4014[EB/OI].ht tp://www.f-22raptor.corn/pdf/aLexsunl—f22crash.pdf.2004— 122O

[6]DefenseIndustryDaily.F22squadronshotdownbytheInter— nationalDateIinerEB/OI].http://www.defensendustrydai— lv.core/f22.squadronshotdownby-thminternational—dateline- 08087/,2007—3～1

r7]USAF.MII,STDI574A1979System~fetyprogramforspa- ceandmissilesystem[s].Arlington:DepartmentofDefence,1979 r8]IevesonNG.Softwaresafety:why,what,andhow[J].Compu— tingSurveys,1986,18(2):125—163

[9]HeimdahlM.Safetyandsoftwareintensivesystems:challenges oldandnew[C],f2007FutureofSoftwareEngineering(FOSE 07).WashingtonIX;:IEEEComputerSociety,2007:137152 r10]McDermidJA.Softwaresafety:where'stheevidence?[C]// Proceedingsofthe6AustralianWorkshoponSafetySystems andSoftware.Brisbane:AustralianComputerSociety,2001,3:1-6 [11]总装备部.GJB/Z1022004军用软件安全性分析指南[S].北 京:总装备部,2004

r12]DepartmentofDefence.M1L-STD882B--1984Softwaresafety programrequirements[S].Arlington:DepartmentofDefence,1984 [131NationalAeronauticsandSpaceAdministration.NASA-STD- 8719.13A一2003SoftwaresafetyNASAtechnicalstandardlS1. WashingtonIX;:NationalAeronauticsandSpaceAdministra— tion,2003

[14]SwarupMB,RamaiahPsAnapproachtomodelingsoftware safetyinsafety—criticalsystems[J].JournalofComputerSci— ence,2009,5(4):311-322

[15]AvizienisA,LaprieJC,RandellBFundamentalconceptsofde— pendability[R].UCIACNDReportNo.010028.LogAngeles: UniversityofCalifornia,2000

[16]杨仕平,桑楠,熊光泽.安全关键软件的防危性测评技术研究 [J].计算机,2004,27(4):442—450

[17]方滨兴,陆天波,李超.软件确保研究进展l-J].通信,2009, 30(2):106—117

[18]LyuMR.Softwarereliabilityengineering:aroadmap[C]//2007 FutureofSoftwareEngineering(FOSE'07).WashingtonDC: IEEEComputerSociety,2007:153—170

[19]DevanbuPT,StubblebinesSoftwareengineeringforsecurity:a roadmap[-C]fProceedingsoftheConferenceontheFutureof SoftwareEngineering.NewYork:ACM,2000:227—239 [2O]ChessB,McgrawG.Softwaresecurity[J].IEEESecurityand Privacy,2004,2(2):53—84

r21]westmarkVR.Adefinitionforinformationsystemsurvivability [c]∥Proceedingsofthe37AnnualHawaiiInternationalCon— ferenceonSystemSciences(HICSS'04).WashingtonIX;IEEE ComputerSociety,2004,9:303312

r22]KnightJC,StrunkEA,SullivanKJ.Towardsarigorousdefini ti0nofinformarionsystemsurvivability[el∥Proceedingsofthe DARPAInformationSurvivabilityConferenceand