课件01-软件可靠性与安全性-解决之道

1、软件可靠性与安全性第一部分软件可靠性与安全性解决之道提要软件失效机理与对策软件可靠性与安全性典型失效事件与教训32133软件失效管理34对可靠软件的需求 软件应用广泛, 在许多领域成为产品创新的源泉 软件使系统更加智能、灵活, 越来越多的系统能力由软件实现 系统对软件的需求和依赖, 使得软件既要满足用户的功能要求, 又必须稳定可靠地完成赋予的任务 软件可靠性的重要程度依赖于软件运行的风险成本, 如果软件失效的代价很高, 则软件的可靠性也就非常重要软件的状况 硬件飞速发展, 越来越可靠, 软件成为系统崩溃的主要原因 软件研发水平与应用需求不相适应, 虽然采取了许多办法, 但常在带有许多缺陷的情况

2、下发布和部署 软件自身规模、复杂性的增加, 给获得安全可靠软件带来挑战, 大部分软件不是十分可靠 软件质量的定量评估困难, 往往成为项目要素中最容易被忽略的部分软件可靠性 IEEE的定义a)在规定的条件下，规定的时间内，软件在规定的条件下，规定的时间内，软件不引起系统失效的概率。该概率是系统不引起系统失效的概率。该概率是系统输入和系统使用的函数，也是软件中存输入和系统使用的函数，也是软件中存在的缺陷的函数；系统输入将确定是否在的缺陷的函数；系统输入将确定是否会遇到存在的缺陷会遇到存在的缺陷(如果缺陷存在的话如果缺陷存在的话)。b)在规定的时间周期内，在所述条件下程在规定的时间周期内，在所述条件

3、下程序完成所需功能的能力。序完成所需功能的能力。软件可靠性的相关要素 软件无失效运行的概率(规定的任务和功能) 规定的条件 (系统输入和系统使用) 规定的时间(任务周期)软件可靠性构成ISO/IEC 25010:2011的定义 可靠性(Reliability)v在指定条件下和规定的时间范围内在指定条件下和规定的时间范围内, 系统、系统、产品或组件完成规定功能的能力产品或组件完成规定功能的能力v包括：成熟性包括：成熟性, 可用性可用性, 容错性容错性, 恢复性恢复性软件可靠性构成 成熟性(Maturity)v在正常操作情况下在正常操作情况下, 满足可靠性要求的能满足可靠性要求的能力力 可用性(A

4、vailability)v当需要使用时当需要使用时, 系统、产品或组件可操作系统、产品或组件可操作和可访问的能力和可访问的能力软件可靠性构成 容错性(Fault tolerance)v在硬件或软件出现故障的条件下在硬件或软件出现故障的条件下, 系统、系统、产品或组件仍能按预期运行的能力产品或组件仍能按预期运行的能力 恢复性(Recoverability)v在出现中断事件或发生失效的情况下在出现中断事件或发生失效的情况下, 产产品或系统能够恢复受到直接影响的数据并品或系统能够恢复受到直接影响的数据并重建系统期望状态的能力重建系统期望状态的能力安全关键软件应用场景 航空器控制软件 医疗设备软件 核

5、应用软件 汽车发动机控制软件 轨道/列车控制系统软件 关键基础设施监控系统软件 金融管理系统软件 军事装备/系统软件软件安全危险性 安全危险性(Safety)是使人员或者环境免受风险影响的能力经济风险经济风险健康和安全风险健康和安全风险环境风险环境风险 风险常常是由功能性、可靠性、安全保密性、易用性或维护性中的缺陷所致 安全危险性与系统所处的环境相关, 是使用质量安全相关系统和软件 必须能够实现要求的安全功能, 以达到或保持受控设备的安全状态; 并且, 自身或与其他安全相关系统或外部风险降低设施一道, 能够达到要求的安全功能所需的安全完整性 一般分为安全控制系统和安全防护系统 安全相关软件是在

6、安全相关系统中用于实现安全功能的软件软件安全完整性及等级 软件安全完整性v在所有规定条件下和规定时间内表示软件在所有规定条件下和规定时间内表示软件在系统中执行其安全功能的可能性的量值在系统中执行其安全功能的可能性的量值 软件安全完整性等级(SiL)v一种离散的等级，用于规定在安全相关系一种离散的等级，用于规定在安全相关系统中软件的安全完整性统中软件的安全完整性v4个等级个等级应用方式对质量需求的影响 网络化需求 虚拟化需求 智能化需求 通用化需求 经济性需求 便捷性需求软件安全保密性 ISO/IEC 25010:2011 的定义 安全保密性(Security)v产品或系统保护信息和数据的能力产

7、品或系统保护信息和数据的能力, 以使以使人员或其它产品或其它系统按照其相应的人员或其它产品或其它系统按照其相应的类型和权限访问信息和数据类型和权限访问信息和数据v包括：机密性、完整性、不可抵赖性、可包括：机密性、完整性、不可抵赖性、可核查性、确实性核查性、确实性软件安全保密性 机密性(Confidentiality)v产品或系统确保数据仅被那些具有访问权产品或系统确保数据仅被那些具有访问权限的人或系统访问的能力限的人或系统访问的能力 完整性(Integrity)v系统、产品或组件防止未授权访问或修改系统、产品或组件防止未授权访问或修改计算机程序或数据的能力计算机程序或数据的能力软件安全保密性

8、不可抵赖性(Non-repudiation)v证实活动或事件已发生的能力证实活动或事件已发生的能力, 以使已发以使已发生的活动或事件不可能在随后被否认生的活动或事件不可能在随后被否认 可核查性(Accountability)v保证实体的活动与实体实现唯一性追踪的保证实体的活动与实体实现唯一性追踪的能力能力软件安全保密性 确实性(Authenticity)v确认和识别一个主体或资源就是其所声称确认和识别一个主体或资源就是其所声称的能力的能力软件质量的系统化考虑 可信性v可靠性可靠性 + 可用性可用性 + 安全危险性安全危险性 + 安全安全保密性保密性 + 维护性维护性v没有普遍接受的定义没有普遍

9、接受的定义 专用质量特性与通用质量特性v质量是多维度的质量是多维度的, 客户对质量的追求也客户对质量的追求也是多样的是多样的vRAMS相关标准标准号标准名称IEEE Std 982.1-2005IEEE Standard Dictionary of Measures of the Software Aspects of DependabilityIEEE Std 1633-2008IEEE Recommended Practice on Software ReliabilityGB/T 20438-2006/IEC 61508-1998电器/电子/可编程电子安全相关系统的功能安全ISO/IEC

10、 25010:2011Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models提要软件失效机理与对策软件可靠性与安全性典型失效事件与教训32133软件失效管理34失效(Failure) IEEE Std 1633-2008的定义a)系统或系统部件不能在规定的限制内完系统或系统部件不能在规定的限制内完成所需功能成所需功能b)功能单元完成所需功能的能力被终止功能单元完成所需功能的能力

11、被终止c)程序的运行偏离了其需求程序的运行偏离了其需求 规定的、要求的、期望的失效状态 考虑到相关的操作及环境条件, 由一个或多个失效引起或作用的, 对系统的直接和后继的影响 软件不会脱离环境运行, 在某个环境中是安全的软件, 可能在另一个环境中就不安全了失效分类 随机硬件失效(Random Hardware Failure)v在硬件中由一种或几种机能退化可能产生在硬件中由一种或几种机能退化可能产生的、按随机时间出现的失效的、按随机时间出现的失效 系统性失效(Systematic Failure)v原因确定的失效原因确定的失效, 只有对设计或制造过程、只有对设计或制造过程、操作规程、文档或其他

12、相关因素进行修改操作规程、文档或其他相关因素进行修改后，才有可能排除这些失效后，才有可能排除这些失效v可重现可重现失效分类 危险失效(Unsafe Failure)v使安全相关系统处于潜在危险状态或丧失使安全相关系统处于潜在危险状态或丧失安全功能执行能力的失效安全功能执行能力的失效 安全失效(Safe Failure)v不可能使安全相关系统处于潜在危险状态不可能使安全相关系统处于潜在危险状态或丧失安全功能执行能力的失效或丧失安全功能执行能力的失效失效分类 检测到的失效v被系统诊断功能检测到的失效被系统诊断功能检测到的失效v许多安全相关系统具有自诊断能力许多安全相关系统具有自诊断能力, 诊断诊断

13、功能可降低事故和误停车发生的可能性功能可降低事故和误停车发生的可能性 未检测到的失效v未被自诊断功能检测到的失效未被自诊断功能检测到的失效v系统的自诊断能力影响系统的安全性能系统的自诊断能力影响系统的安全性能软件失效机理 导致软件失效的缺陷主要是设计问题 老化/磨损不会导致软件失效, 软件失效没有预兆 周期性的重启可帮助防止/修复一些软件失效 软件可靠性不是运行时间的函数 除非影响到软件的输入, 否则环境因素不会对软件可靠性产生影响 相同软件的冗余不能改善软件可靠性软件失效机理 软件的接口完全是概念上的、不可见的, 但对软件可靠性有影响 通常不能通过对单条语句的分析来预计软件失效率 标准件可用

14、于改善可靠性和可维护性, 但软件重用还没有形成工程趋势 硬件维修使其恢复到良好状态, 而软件修改使其到达未知状态软件失效根本原因 事件链1v使用错误使用错误 失效失效 事件链2v人为人为错误错误 缺陷缺陷 故障故障 失失效效导致失效的事件链1 导致使用错误的原因v缺少清晰的、良好结构化的用户文档缺少清晰的、良好结构化的用户文档v复杂的用户接口复杂的用户接口v缺乏培训缺乏培训/技术支持技术支持v产品规格说明和用户使用环境不一致产品规格说明和用户使用环境不一致v不适当的硬件配置不适当的硬件配置v用户的教育或系统背景知识不足用户的教育或系统背景知识不足v用户对操作环境或产品用途了解不足用户对操作环境

15、或产品用途了解不足导致失效的事件链2 错误(Error)v在软件开发过程中出现的不符合期望或不在软件开发过程中出现的不符合期望或不可接受的人为差错可接受的人为差错 典型的错误v误解或遗漏了用户需求误解或遗漏了用户需求v设计没有完整的实现软件需求设计没有完整的实现软件需求v程序设计错误程序设计错误导致失效的事件链2 缺陷(Defect)v软件中存在的不期望或不可接受的偏差软件中存在的不期望或不可接受的偏差v在特定的状态下在特定的状态下, 导致软件不能完成所需导致软件不能完成所需的任务的任务v如果缺陷可被利用来违反安全要求如果缺陷可被利用来违反安全要求, 这种这种与安全相关的缺陷一般被称为漏洞与安

16、全相关的缺陷一般被称为漏洞 典型的软件缺陷v数组越界使用数组越界使用v算法实现不正确算法实现不正确v缓冲区溢出缓冲区溢出导致失效的事件链2 故障(Fault)v软件中缺陷的体现。如：软件的计算或软件中缺陷的体现。如：软件的计算或判断与规定的不符合等判断与规定的不符合等v一个故障如果发生一个故障如果发生, 可能引起失效可能引起失效 典型的软件故障v资源泄露资源泄露v执行了多余的循环执行了多余的循环v无限递归调用无限递归调用遭遇失效的原因 软件中存在缺陷 在使用周期内的系统输入/系统使用触发了软件缺陷 对触发的缺陷, 软件中没有相应的措施进行正确的处理缺陷的特性 变异的预期常常产生缺陷 在实际项目

17、中完全消除缺陷是不可能的, 基于软件开发经济学的考虑, 减少缺陷是现实的 缺陷有可能非常简单, 也有可能极其复杂 程序设计语言与缺陷的复杂性和数量的关系是未知的 不论人的能力和背景, 都可能产生缺陷缺陷的影响 缺陷可能导致失效 同样的缺陷在不同的场景下导致的失效状态会有很大的差别, 可能只是使用不便, 也有可能带来灾难 缺陷的复杂度与失效的严重性之间的关系是未知的 最大限度的减少缺陷, 可以提高软件的可靠性缺陷解决策略 缺陷消除策略v避错避错(Defect Avoidance)v排错排错(Defect Removal) 缺陷应对策略v容错容错(Fault Tolerance)v恢复恢复(Fau

18、lt Recovery)软件避错策略 第一次就做正确(Do It Right the First Time)v建立先进的理念建立先进的理念, 避免错误及预防失误避免错误及预防失误v采取适当的实践采取适当的实践, 形成缺陷预防的趋势形成缺陷预防的趋势v利用一切可用的方法及工具利用一切可用的方法及工具, 确保不引入确保不引入缺陷到软件缺陷到软件软件避错策略 典型实践举例v建立组织级别的规范和指南建立组织级别的规范和指南, 全体人员共全体人员共同遵守同遵守v用户的早期参与用户的早期参与v进行专业分工进行专业分工, 使用有能力、经验及进取使用有能力、经验及进取心的人员心的人员v在生命周期各阶段在生命周

19、期各阶段, 使用现代的方法论和使用现代的方法论和自动化工具自动化工具, 促进生产力提升的同时及达促进生产力提升的同时及达到预定质量的目标到预定质量的目标软件排错策略 尽早发现, 一旦可行立即改正(Detect It Early; Fix It as Soon as Practicable)v测试及修复成为计划性和经常性活动测试及修复成为计划性和经常性活动, 对对缺陷进行早期检测及消除缺陷进行早期检测及消除, 使得缺陷一旦使得缺陷一旦产生就立刻解决产生就立刻解决v修正系统缺陷时修正系统缺陷时, 应考虑问题的严重程度、应考虑问题的严重程度、发生频率及完成测试及管理的可能性发生频率及完成测试及管理的

20、可能性v在操作和维护阶段发现的缺陷在操作和维护阶段发现的缺陷, 不一定要不一定要立即修正立即修正软件排错策略 典型实践举例v在生命周期各阶段在生命周期各阶段, 对软件进行原型化、对软件进行原型化、仿真、审查和检查仿真、审查和检查, 验证正确性验证正确性, 改善可改善可靠性靠性v尽早开展多层次的测试工作尽早开展多层次的测试工作, 发现并消除发现并消除缺陷和隐患缺陷和隐患v优先解决最高风险的问题优先解决最高风险的问题, 加强配置管理加强配置管理, 防止变更失控防止变更失控v建立并运行软件故障报告、分析及纠正措建立并运行软件故障报告、分析及纠正措施系统施系统, 做好软件故障管理做好软件故障管理软件避

21、错/排错改进 密切监督(Monitor It)v在整个软件生命周期在整个软件生命周期, 进行原始数据的收进行原始数据的收集和评估集和评估v有效整合测量、验证和确认等活动有效整合测量、验证和确认等活动, 测量测量必须配合适当的验证和确认方法才能提供必须配合适当的验证和确认方法才能提供质量良好的测量数据质量良好的测量数据v根据测量数据根据测量数据, 评估开发过程、验证过程、评估开发过程、验证过程、软件产品软件产品, 持续改进持续改进软件避错/排错改进 典型实践举例v在软件生命周期各阶段在软件生命周期各阶段, 持续开展软件质持续开展软件质量保证工作量保证工作v通过开展测量与分析通过开展测量与分析,

22、收集软件审查、测收集软件审查、测试数据试数据, 对开发过程和验证过程进行分析对开发过程和验证过程进行分析和评价和评价v对软件缺陷、故障、失效进行跟踪管理对软件缺陷、故障、失效进行跟踪管理, 分析根本原因分析根本原因, 建立模式库建立模式库, 指导避错和指导避错和排错排错使用方式对失效的影响 软件缺陷只有被遇到时才会产生故障, 才有可能导致失效 不同使用方式下, 对软件可靠性的感受是不一样的 决定软件使用方式的因素很多v内部参数、历史数据、当前输入、内部参数、历史数据、当前输入、 缺陷在软件中的位置未知 软件执行条件一般不可预知软件使用方式 使用模型是对软件使用的刻画v使用者使用者v使用方式使用

23、方式 使用者v人、硬件、外部软件等人、硬件、外部软件等 使用方式v使用的操作、频度等使用的操作、频度等软件使用方式的刻画 操作剖面v操作及其发生概率组成的集合操作及其发生概率组成的集合 操作模型v使用使用Markov链描述的软件使用模型链描述的软件使用模型软件操作剖面图示(操作i , 0.056)发生概率操作软件操作模型图示未激活未激活终止终止准备准备状态状态1状态状态2状态状态3状态状态4S,1.00G,0.50B,0.30R,0.20G,1.00A,0.50B,0.40R,0.10R,0.30C,0.25D,0.50E,0.25F,0.70失效的时间表述 失效的时间点 失效间的间隔时间 到

24、达给定时间经历的失效数量 在给定时间间隔内发生的失效数可选的时间类型 执行时间 日历时间 时钟时间可选的时间类型程序程序A程序程序B程序程序CT1T2T3T4T5T6程序程序A(执行时间执行时间)=T1+T3+T6程序程序A(时钟时间时钟时间)=T1+T2+T3+T4+T5+T6获得无失效(fail-silent)软件 减少软件中缺陷数量v避错避错v排错排错 减少用户遭遇潜在缺陷的可能性v在正式发布前在正式发布前, 基于使用模型进行测试基于使用模型进行测试, 降低未来用户触发潜在缺陷的概率降低未来用户触发潜在缺陷的概率 对已发生的故障进行正确处理v容错容错v恢复恢复提要软件失效机理与对策软件可

25、靠性与安全性典型失效事件与教训32133软件失效管理34典型失效事件与教训 Therac-25失效事件vTherac-25是是Atomic energy of Canada Ltd开发的一款放射治疗仪开发的一款放射治疗仪v1985.61987.1, 6人治疗过量人治疗过量, 其中其中3人死亡人死亡典型失效事件与教训 Therac-25失效原因v主循环中存在竞争条件主循环中存在竞争条件v寄存器溢出寄存器溢出典型失效事件与教训 Therac-25失效带来的教训v系统安全性分析、风险分析未包含软件系统安全性分析、风险分析未包含软件vTherac-25重用了重用了T-20的软件的软件, 假设和假设和前

26、提发生了改变前提发生了改变, 但未受到关注但未受到关注典型失效事件与教训 Ariane 5失效事件v1996年年6月月4日日, Ariane5 发射发射40秒秒后爆炸后爆炸典型失效事件与教训 Ariane 5失效的直接原因v将一个将一个64位浮点值转换为位浮点值转换为16位有符号整位有符号整数值时数值时, 超出了超出了16位整数的表示范围位整数的表示范围, 而而这个异常未得到正确处理这个异常未得到正确处理典型失效事件与教训 Ariane 5失效带来的经验教训v作了作了Ariane 5和和Ariane 4具有相同环境具有相同环境的假设的假设, 重用重用软件软件在新的环境下完全没有在新的环境下完全

27、没有进行测试进行测试v异常异常处理模块的处理机制不正确处理模块的处理机制不正确典型失效事件与教训 火星探测器失效事件v1999年年, 火星气象卫星火星气象卫星(Mars Climate Orbiter)到达火星之后不久就消失到达火星之后不久就消失v1999年年, 火星极地登陆者火星极地登陆者(Mars Polar Lander)在火星上着陆时坠毁在火星上着陆时坠毁典型失效事件与教训 火星探测器失效原因v地面系统软件和飞行器上软件分别使用公地面系统软件和飞行器上软件分别使用公制和英制两种单位制和英制两种单位典型失效事件与教训 火星探测器失效带来的教训v没有进行充分的测试没有进行充分的测试v发现异

28、常时发现异常时, 没有被恰当的解释没有被恰当的解释典型失效事件与教训 1982年6月: 逻辑炸弹导致苏联西伯利亚天然气管道毁灭性爆炸(CIA)v迄今为止最巨大的非核爆炸迄今为止最巨大的非核爆炸, 甚至从太空甚至从太空可以看到火光可以看到火光v由计算机控制系统中恶意功能导致由计算机控制系统中恶意功能导致, 是最是最早的证实逻辑炸弹威力的案例早的证实逻辑炸弹威力的案例v在系统运行了一定的时间间隔后在系统运行了一定的时间间隔后, 重新设重新设置泵的速度和阀门参数置泵的速度和阀门参数, 产生远远超过管产生远远超过管道连接和焊接处可承受的压力道连接和焊接处可承受的压力典型失效事件与教训 StuxNet事

29、件v20092010年年, StuxNet蠕虫攻击伊蠕虫攻击伊朗的核计划朗的核计划, 成功破坏了伊朗的铀浓缩系成功破坏了伊朗的铀浓缩系统统v定 向 攻 击定 向 攻 击 S C A D A 系 统系 统 , 目 标 针 对目 标 针 对Seimens控制器和特定配置的设备控制器和特定配置的设备vStuxnet使用了两个数字证书、多个未知使用了两个数字证书、多个未知漏洞、多种传播途径漏洞、多种传播途径典型失效事件与教训 GE医疗软件因失效主动召回 银联 出租车计价器 酒店客房智能管理 空调/机顶盒 电子秤/加油机/保险柜(保密柜) 提要软件失效机理与对策软件可靠性与安全性典型失效事件与教训321

30、33软件失效管理34可靠性问题的答案在哪里?你的软件可靠吗?你的测试过程需要改进吗?你的开发过程需要改进吗?不可靠的原因是什么?软件失效管理利用“信息反馈, 闭环控制”的原理, 通过一套规范化的程序, 使发生的产品失效能得到及时的报告和纠正, 从而实现产品可靠性的增长, 达到对产品可靠性和维修性的预期要求, 防止失效再现基于风险水平管理失效建立企业的可靠性经验FRACAS“失效报告、分析及纠正措施系统”, 是“Failure Report Analysis and Corrective Action System”的缩写也称为“失效信息闭环管理系统”一组过程、规则和软件工具, 在产品生存期后端

31、开始使用, 是跟踪系统可靠性的方法建立企业失效信息数据库,提供数据支持v软件可靠性设计和分析软件可靠性设计和分析v维修策略、保障策略和备件策略的制定维修策略、保障策略和备件策略的制定FRACAS过程1.记录事件2.分析失效模式3.开展纠正活动4.检验纠正活动5.识别失效趋势6.确定单个部件对失效产生的作用FRACAS知识积累知识库失效事件失效报告根源分析纠正措施闭环验证可靠性分析产品改进FRACAS信息流失效记录失效报告失效分析纠正措施闭环管理售后服务数据库FRACAS数据库外场失效厂内失效通用质量知识库知识管理FRACAS文档记录失效记录表失效报告表失效分析表纠正措施表闭环管理表FRACAS工作系统组织机构(各方代表)人员职责分工工作的流程资源保障FRACAS信息系统与可靠性信息系统的关系信息准确与完整性及时性、正确性可追踪性利用FRACASFRACAS数据库FMEA设计准则可靠性评估可靠性增长计划失效模式手册关键件判定和失效历史使用、失效、维修信息失效统计分析失效分级管理 失效状态可划分为不同的等级 不同的失效状态对可靠性的影响具有差异 软件失效的分级可