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

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

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

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

4、v在正常操作情况下在正常操作情况下, 满足可靠性要求的能满足可靠性要求的能 力力 可用性(Availability) v当需要使用时当需要使用时, 系统、产品或组件可操作系统、产品或组件可操作 和可访问的能力和可访问的能力 软件可靠性构成 容错性(Fault tolerance) v在硬件或软件出现故障的条件下在硬件或软件出现故障的条件下, 系统、系统、 产品或组件仍能按预期运行的能力产品或组件仍能按预期运行的能力 恢复性(Recoverability) v在出现中断事件或发生失效的情况下在出现中断事件或发生失效的情况下, 产产 品或系统能够恢复受到直接影响的数据并品或系统能够恢复受到直接影响

5、的数据并 重建系统期望状态的能力重建系统期望状态的能力 安全关键软件应用场景 航空器控制软件 医疗设备软件 核应用软件 汽车发动机控制软件 轨道/列车控制系统软件 关键基础设施监控系统软件 金融管理系统软件 军事装备/系统软件 软件安全危险性 安全危险性(Safety)是使人员或者环境免受 风险影响的能力 经济风险经济风险 健康和安全风险健康和安全风险 环境风险环境风险 风险常常是由功能性、可靠性、安全保密性、 易用性或维护性中的缺陷所致 安全危险性与系统所处的环境相关, 是使用 质量 安全相关系统和软件 必须能够实现要求的安全功能, 以达到或保 持受控设备的安全状态; 并且, 自身或与其他

6、安全相关系统或外部风险降低设施一道, 能 够达到要求的安全功能所需的安全完整性 一般分为安全控制系统和安全防护系统 安全相关软件是在安全相关系统中用于实现 安全功能的软件 软件安全完整性及等级 软件安全完整性 v在所有规定条件下和规定时间内表示软件在所有规定条件下和规定时间内表示软件 在系统中执行其安全功能的可能性的量值在系统中执行其安全功能的可能性的量值 软件安全完整性等级(SiL) v一种离散的等级，用于规定在安全相关系一种离散的等级，用于规定在安全相关系 统中软件的安全完整性统中软件的安全完整性 v4个等级个等级 应用方式对质量需求的影响 网络化需求 虚拟化需求 智能化需求 通用化需求

7、经济性需求 便捷性需求 软件安全保密性 ISO/IEC 25010:2011 的定义 安全保密性(Security) v产品或系统保护信息和数据的能力产品或系统保护信息和数据的能力, 以使以使 人员或其它产品或其它系统按照其相应的人员或其它产品或其它系统按照其相应的 类型和权限访问信息和数据类型和权限访问信息和数据 v包括：机密性、完整性、不可抵赖性、可包括：机密性、完整性、不可抵赖性、可 核查性、确实性核查性、确实性 软件安全保密性 机密性(Confidentiality) v产品或系统确保数据仅被那些具有访问权产品或系统确保数据仅被那些具有访问权 限的人或系统访问的能力限的人或系统访问的能

8、力 完整性(Integrity) v系统、产品或组件防止未授权访问或修改系统、产品或组件防止未授权访问或修改 计算机程序或数据的能力计算机程序或数据的能力 软件安全保密性 不可抵赖性(Non-repudiation) v证实活动或事件已发生的能力证实活动或事件已发生的能力, 以使已发以使已发 生的活动或事件不可能在随后被否认生的活动或事件不可能在随后被否认 可核查性(Accountability) v保证实体的活动与实体实现唯一性追踪的保证实体的活动与实体实现唯一性追踪的 能力能力 软件安全保密性 确实性(Authenticity) v确认和识别一个主体或资源就是其所声称确认和识别一个主体或资

9、源就是其所声称 的能力的能力 软件质量的系统化考虑 可信性 v可靠性可靠性 + 可用性可用性 + 安全危险性安全危险性 + 安全安全 保密性保密性 + 维护性维护性 v没有普遍接受的定义没有普遍接受的定义 专用质量特性与通用质量特性 v质量是多维度的质量是多维度的, 客户对质量的追求也客户对质量的追求也 是多样的是多样的 vRAMS 相关标准 标准号标准名称 IEEE Std 982.1- 2005 IEEE Standard Dictionary of Measures of the Software Aspects of Dependability IEEE Std 1633- 2008

10、IEEE Recommended Practice on Software Reliability GB/T 20438- 2006/IEC 61508- 1998 电器/电子/可编程电子安全相关系统的 功能安全 ISO/IEC 25010:20 11 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models 提要 软件失效机理与对策 软件可靠性与安全性 典型失效事件与教训 3

11、2 1 3 3 软件失效管理 3 4 失效(Failure) IEEE Std 1633-2008的定义 a)系统或系统部件不能在规定的限制内完系统或系统部件不能在规定的限制内完 成所需功能成所需功能 b)功能单元完成所需功能的能力被终止功能单元完成所需功能的能力被终止 c)程序的运行偏离了其需求程序的运行偏离了其需求 规定的、要求的、期望的 失效状态 考虑到相关的操作及环境条件, 由一个或多 个失效引起或作用的, 对系统的直接和后继 的影响 软件不会脱离环境运行, 在某个环境中是安 全的软件, 可能在另一个环境中就不安全了 失效分类 随机硬件失效(Random Hardware Failur

12、e) v在硬件中由一种或几种机能退化可能产生在硬件中由一种或几种机能退化可能产生 的、按随机时间出现的失效的、按随机时间出现的失效 系统性失效(Systematic Failure) v原因确定的失效原因确定的失效, 只有对设计或制造过程、只有对设计或制造过程、 操作规程、文档或其他相关因素进行修改操作规程、文档或其他相关因素进行修改 后，才有可能排除这些失效后，才有可能排除这些失效 v可重现可重现 失效分类 危险失效(Unsafe Failure) v使安全相关系统处于潜在危险状态或丧失使安全相关系统处于潜在危险状态或丧失 安全功能执行能力的失效安全功能执行能力的失效 安全失效(Safe F

13、ailure) v不可能使安全相关系统处于潜在危险状态不可能使安全相关系统处于潜在危险状态 或丧失安全功能执行能力的失效或丧失安全功能执行能力的失效 失效分类 检测到的失效 v被系统诊断功能检测到的失效被系统诊断功能检测到的失效 v许多安全相关系统具有自诊断能力许多安全相关系统具有自诊断能力, 诊断诊断 功能可降低事故和误停车发生的可能性功能可降低事故和误停车发生的可能性 未检测到的失效 v未被自诊断功能检测到的失效未被自诊断功能检测到的失效 v系统的自诊断能力影响系统的安全性能系统的自诊断能力影响系统的安全性能 软件失效机理 导致软件失效的缺陷主要是设计问题 老化/磨损不会导致软件失效, 软

14、件失效没有 预兆 周期性的重启可帮助防止/修复一些软件失 效 软件可靠性不是运行时间的函数 除非影响到软件的输入, 否则环境因素不会 对软件可靠性产生影响 相同软件的冗余不能改善软件可靠性 软件失效机理 软件的接口完全是概念上的、不可见的, 但 对软件可靠性有影响 通常不能通过对单条语句的分析来预计软件 失效率 标准件可用于改善可靠性和可维护性, 但软 件重用还没有形成工程趋势 硬件维修使其恢复到良好状态, 而软件修改 使其到达未知状态 软件失效根本原因 事件链1 v使用错误使用错误 失效失效 事件链2 v人为人为错误错误 缺陷缺陷 故障故障 失失 效效 导致失效的事件链1 导致使用错误的原因

15、 v缺少清晰的、良好结构化的用户文档缺少清晰的、良好结构化的用户文档 v复杂的用户接口复杂的用户接口 v缺乏培训缺乏培训/技术支持技术支持 v产品规格说明和用户使用环境不一致产品规格说明和用户使用环境不一致 v不适当的硬件配置不适当的硬件配置 v用户的教育或系统背景知识不足用户的教育或系统背景知识不足 v用户对操作环境或产品用途了解不足用户对操作环境或产品用途了解不足 导致失效的事件链2 错误(Error) v在软件开发过程中出现的不符合期望或不在软件开发过程中出现的不符合期望或不 可接受的人为差错可接受的人为差错 典型的错误 v误解或遗漏了用户需求误解或遗漏了用户需求 v设计没有完整的实现软

16、件需求设计没有完整的实现软件需求 v程序设计错误程序设计错误 导致失效的事件链2 缺陷(Defect) v软件中存在的不期望或不可接受的偏差软件中存在的不期望或不可接受的偏差 v在特定的状态下在特定的状态下, 导致软件不能完成所需导致软件不能完成所需 的任务的任务 v如果缺陷可被利用来违反安全要求如果缺陷可被利用来违反安全要求, 这种这种 与安全相关的缺陷一般被称为漏洞与安全相关的缺陷一般被称为漏洞 典型的软件缺陷 v数组越界使用数组越界使用 v算法实现不正确算法实现不正确 v缓冲区溢出缓冲区溢出 导致失效的事件链2 故障(Fault) v软件中缺陷的体现。如：软件的计算或软件中缺陷的体现。如

17、：软件的计算或 判断与规定的不符合等判断与规定的不符合等 v一个故障如果发生一个故障如果发生, 可能引起失效可能引起失效 典型的软件故障 v资源泄露资源泄露 v执行了多余的循环执行了多余的循环 v无限递归调用无限递归调用 遭遇失效的原因 软件中存在缺陷 在使用周期内的系统输入/系统使用触发了 软件缺陷 对触发的缺陷, 软件中没有相应的措施进行 正确的处理 缺陷的特性 变异的预期常常产生缺陷 在实际项目中完全消除缺陷是不可能的, 基 于软件开发经济学的考虑, 减少缺陷是现实 的 缺陷有可能非常简单, 也有可能极其复杂 程序设计语言与缺陷的复杂性和数量的关系 是未知的 不论人的能力和背景, 都可能

18、产生缺陷 缺陷的影响 缺陷可能导致失效 同样的缺陷在不同的场景下导致的失效状态 会有很大的差别, 可能只是使用不便, 也有 可能带来灾难 缺陷的复杂度与失效的严重性之间的关系是 未知的 最大限度的减少缺陷, 可以提高软件的可靠 性 缺陷解决策略 缺陷消除策略 v避错避错(Defect Avoidance) v排错排错(Defect Removal) 缺陷应对策略 v容错容错(Fault Tolerance) v恢复恢复(Fault Recovery) 软件避错策略 第一次就做正确(Do It Right the First Time) v建立先进的理念建立先进的理念, 避免错误及预防失误避免错

19、误及预防失误 v采取适当的实践采取适当的实践, 形成缺陷预防的趋势形成缺陷预防的趋势 v利用一切可用的方法及工具利用一切可用的方法及工具, 确保不引入确保不引入 缺陷到软件缺陷到软件 软件避错策略 典型实践举例 v建立组织级别的规范和指南建立组织级别的规范和指南, 全体人员共全体人员共 同遵守同遵守 v用户的早期参与用户的早期参与 v进行专业分工进行专业分工, 使用有能力、经验及进取使用有能力、经验及进取 心的人员心的人员 v在生命周期各阶段在生命周期各阶段, 使用现代的方法论和使用现代的方法论和 自动化工具自动化工具, 促进生产力提升的同时及达促进生产力提升的同时及达 到预定质量的目标到预定

20、质量的目标 软件排错策略 尽早发现, 一旦可行立即改正(Detect It Early; Fix It as Soon as Practicable) v测试及修复成为计划性和经常性活动测试及修复成为计划性和经常性活动, 对对 缺陷进行早期检测及消除缺陷进行早期检测及消除, 使得缺陷一旦使得缺陷一旦 产生就立刻解决产生就立刻解决 v修正系统缺陷时修正系统缺陷时, 应考虑问题的严重程度、应考虑问题的严重程度、 发生频率及完成测试及管理的可能性发生频率及完成测试及管理的可能性 v在操作和维护阶段发现的缺陷在操作和维护阶段发现的缺陷, 不一定要不一定要 立即修正立即修正 软件排错策略 典型实践举例

21、v在生命周期各阶段在生命周期各阶段, 对软件进行原型化、对软件进行原型化、 仿真、审查和检查仿真、审查和检查, 验证正确性验证正确性, 改善可改善可 靠性靠性 v尽早开展多层次的测试工作尽早开展多层次的测试工作, 发现并消除发现并消除 缺陷和隐患缺陷和隐患 v优先解决最高风险的问题优先解决最高风险的问题, 加强配置管理加强配置管理, 防止变更失控防止变更失控 v建立并运行软件故障报告、分析及纠正措建立并运行软件故障报告、分析及纠正措 施系统施系统, 做好软件故障管理做好软件故障管理 软件避错/排错改进 密切监督(Monitor It) v在整个软件生命周期在整个软件生命周期, 进行原始数据的收

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

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

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

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

26、 提要 软件失效机理与对策 软件可靠性与安全性 典型失效事件与教训 3 2 1 3 3 软件失效管理 3 4 典型失效事件与教训 Therac-25失效事件 vTherac-25是是Atomic energy of Canada Ltd开发的一款放射治疗仪开发的一款放射治疗仪 v1985.61987.1, 6人治疗过量人治疗过量, 其中其中 3人死亡人死亡 典型失效事件与教训 Therac-25失效原因 v主循环中存在竞争条件主循环中存在竞争条件 v寄存器溢出寄存器溢出 典型失效事件与教训 Therac-25失效带来的教训 v系统安全性分析、风险分析未包含软件系统安全性分析、风险分析未包含软件

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

28、具有相同环境具有相同环境 的假设的假设, 重用重用软件软件在新的环境下完全没有在新的环境下完全没有 进行测试进行测试 v异常异常处理模块的处理机制不正确处理模块的处理机制不正确 典型失效事件与教训 火星探测器失效事件 v1999年年, 火星气象卫星火星气象卫星(Mars Climate Orbiter)到达火星之后不久就消失到达火星之后不久就消失 v1999年年, 火星极地登陆者火星极地登陆者(Mars Polar Lander)在火星上着陆时坠毁在火星上着陆时坠毁 典型失效事件与教训 火星探测器失效原因 v地面系统软件和飞行器上软件分别使用公地面系统软件和飞行器上软件分别使用公 制和英制两种

29、单位制和英制两种单位 典型失效事件与教训 火星探测器失效带来的教训 v没有进行充分的测试没有进行充分的测试 v发现异常时发现异常时, 没有被恰当的解释没有被恰当的解释 典型失效事件与教训 1982年6月: 逻辑炸弹导致苏联西伯利亚天 然气管道毁灭性爆炸(CIA) v迄今为止最巨大的非核爆炸迄今为止最巨大的非核爆炸, 甚至从太空甚至从太空 可以看到火光可以看到火光 v由计算机控制系统中恶意功能导致由计算机控制系统中恶意功能导致, 是最是最 早的证实逻辑炸弹威力的案例早的证实逻辑炸弹威力的案例 v在系统运行了一定的时间间隔后在系统运行了一定的时间间隔后, 重新设重新设 置泵的速度和阀门参数置泵的速

30、度和阀门参数, 产生远远超过管产生远远超过管 道连接和焊接处可承受的压力道连接和焊接处可承受的压力 典型失效事件与教训 StuxNet事件 v20092010年年, StuxNet蠕虫攻击伊蠕虫攻击伊 朗的核计划朗的核计划, 成功破坏了伊朗的铀浓缩系成功破坏了伊朗的铀浓缩系 统统 v定 向 攻 击定 向 攻 击 S C A D A 系 统系 统 , 目 标 针 对目 标 针 对 Seimens控制器和特定配置的设备控制器和特定配置的设备 vStuxnet使用了两个数字证书、多个未知使用了两个数字证书、多个未知 漏洞、多种传播途径漏洞、多种传播途径 典型失效事件与教训 GE医疗软件因失效主动召回

31、 银联 出租车计价器 酒店客房智能管理 空调/机顶盒 电子秤/加油机/保险柜(保密柜) 提要 软件失效机理与对策 软件可靠性与安全性 典型失效事件与教训 3 2 1 3 3 软件失效管理 3 4 可靠性问题的答案在哪里? 你的软件可靠吗? 你的测试过程需要改进吗? 你的开发过程需要改进吗? 不可靠的原因是什么? 软件失效管理 利用“信息反馈, 闭环控制”的原理, 通过一 套规范化的程序, 使发生的产品失效能得到 及时的报告和纠正, 从而实现产品可靠性的 增长, 达到对产品可靠性和维修性的预期要 求, 防止失效再现 基于风险水平管理失效 建立企业的可靠性经验 FRACAS “失效报告、分析及纠正

32、措施系统”, 是 “Failure Report Analysis and Corrective Action System”的缩写 也称为“失效信息闭环管理系统” 一组过程、规则和软件工具, 在产品生存期 后端开始使用, 是跟踪系统可靠性的方法 建立企业失效信息数据库,提供数据支持 v软件可靠性设计和分析软件可靠性设计和分析 v维修策略、保障策略和备件策略的制定维修策略、保障策略和备件策略的制定 FRACAS过程 1.记录事件 2.分析失效模式 3.开展纠正活动 4.检验纠正活动 5.识别失效趋势 6.确定单个部件对失效产生的作用 FRACAS知识积累 知识 库 失效 事件 失效 报告 根源

33、 分析 纠正 措施 闭环 验证 可靠性 分析 产品 改进 FRACAS信息流 失效记录 失效报告 失效分析 纠正措施 闭环管理 售后服务 数据库 FRACAS 数据库 外场失效 厂内失效 通用质量 知识库 知识管理 FRACAS文档记录 失效记录表 失效报告表 失效分析表 纠正措施表 闭环管理表 FRACAS工作系统 组织机构(各方代表) 人员职责分工 工作的流程 资源保障 FRACAS信息系统 与可靠性信息系统的关系 信息准确与完整性 及时性、正确性 可追踪性 利用FRACAS FRACAS 数据库 FMEA 设计准则 可靠性评估 可靠性 增长计划 失效模式手册 关键件判定 和失效历史 使用、失效、 维修信息 失效统计分析 失效分级管理 失效状态可划分为不同的等级 不同的失效状态对可靠性的影响具有差异 软件失效的分级可以依据不同的前提 v所带来的安全