第十讲软件的安全性分析

第十讲软件的安全性分析第1页，共46页，2023年，2月20日，星期二内容概述软件系统的安全性分析软件失效效应模式分析软件故障树分析方法其它分析方法第2页，共46页，2023年，2月20日，星期二1概述美国的反射治疗机软件错误，五名患者受超剂量辐射死亡美国血液数据库程序出错，致使被AIDS污染的血液被用于治疗军用设备和核反应堆…………第3页，共46页，2023年，2月20日，星期二软件的安全问题主要起源于软件设计对实际工作情况缺乏了解对系统工作状况所作的错误假设需求说明不清楚……软件安全性是一种特殊的可靠性软件可靠性的避错，查错和容错设计技术同样适用第4页，共46页，2023年，2月20日，星期二美国军标MIL-STD-882B将软件系统的安全性工作归结为如下的九项：确定系统及系统中软件的安全性要求将系统安全性说明中的要求准确转化为系统或分系统说明的要求，转化为软件需求说明的要求，并将这些要求在软件设计和编码中实现在系统，分系统说明及软件需求说明中确定当可能发生安全事故时的系统决策，这些决策包括失效安全，失效降级使用，失效容错使用等确定软件系统中的安全关键单元，安全关键单元是指那些对系统安全性有关键性影响的程序、分程序和模块对软件的安全关键单元进行分析第5页，共46页，2023年，2月20日，星期二通过分析、验证、确保软件系统安全性要求的实现，验证不存在有损于安全性的单个或多个失效事件，保证系统的安全性要求不致引起新的危险确保编制出的程序不会因为触发危险功能，或阻碍正常的功能的执行而使系统处于危险状态保证对系统进行充分的安全性测试，包括失效事件发生的测试第6页，共46页，2023年，2月20日，星期二2.软件系统安全性分析MIL-STD-882B规定软件的安全性分析包括软件需求危险分析概要设计危险分析详细设计危险分析软件编程危险分析软件安全性测试软件与用户接口危险分析软件更改危险分析第7页，共46页，2023年，2月20日，星期二2.1软件需求危险分析利用系统初步危险分析的结果，初步确定软件的安全关键单元。要点为：建立软件安全性需求的跟踪系统，记录每个需求的实现情况从安全性的角度评审系统说明和分系统说明，评审软件需求说明，接口说明，以及其它有关系统方案和要求等文件将系统安全性的要求分配到软件由系统的初步危险表导出软件的危险表分析功能流程图、编程语言、数据流图、存储和时序分配图表以及其它的程序文档第8页，共46页，2023年，2月20日，星期二2.2概要设计危险分析分析的结果将交给初步设计评审从软件的危险表出发，分析其中的危险事件与软件的组成单元之间的关系，并将这些危险事件有关的软件单元确定为软件安全关键单元检查软件。确定软件的各个单元、模块、表、变量之间是否相关，确定相关的程度，凡是对软件安全性单元有直接和间接影响的其它单元，也要确定为软件安全关键单元，并且分析它们对安全的影响分析软件安全关键单元的概要设计是否符合安全性的要求，分析的结果应送交给软件设计人员和项目主管第9页，共46页，2023年，2月20日，星期二2.3详细设计危险分析安排在初步评审之后，软件编码之前，分析的结果交给关键设计评审依据需求危险分析，概要设计危险分析确定的危险事件，分析这些事件与低层次的软件单元的关系，将对危险事件有影响的单元确定为软件安全关键单元，分析这些单元对危险事件影响的方式和途径在低结构层次上考察软件的各个单元、模块、表和变量之间的相关程度，将直接和间接影响软件安全关键单元的其它单元确定为安全关键单元，分析它们对安全的影响第10页，共46页，2023年，2月20日，星期二分析软件安全关键单元的详细设计是否符合安全性设计的要求，分析的结果应该送给软件设计人员和项目主管确定在测试计划、说明和规程中需要包含的安全性要求确定在系统操作员手册、软件用户手册、系统诊断手册及其它手册中需要包含的安全性要求确保编程人员了解安全关键单元，向编程人员提供有关安全性的编程建议和要求第11页，共46页，2023年，2月20日，星期二2.4软件编程危险分析考察软件的安全关键单元以及其它单元的源程序和目标程序是否实现了安全性设计的要求，该工作与编程同时进行考察软件安全关键单元的正确性，考察它们对输入或输出时序，多重事件，错误事件，失序事件，恶劣事件，死锁及输入数据错误的反映和敏感性考察程序、模块或单元中是否存在影响安全性的编程错误考察安全关键单元是否符合系统说明、分系统说明和软件需求说明中提出的安全性对策，这种考察必须在源程序和目标程序中进行第12页，共46页，2023年，2月20日，星期二考察软件安全关键单元的安全性设计要求的实现情况，确保达到所要求的目标，确保硬件和其它模块的失效不致影响软件的安全性特征使系统在危险状态下运行，并考察硬件或软件失效、单个或多重事件，失序事件，程序的非正常转移对安全性的影响考察超界、过载输入对安全性的影响评审正在制订的软件文档、确保这些文档包含了软件的安全性要求第13页，共46页，2023年，2月20日，星期二2.5软件安全性测试对安全关键单元进行安全性测试，保证使危险事件发生的可能性降低到可以接受的水平向测试人员提供软件安全关键单元的安全性测试案例确保所有的软件安全关键单元按预定的测试方案进行安全性测试，准确地记录测试的结果除了在正常状态下进行的测试外，还要在异常的环境和异常的输入状态下测试软件，确保软件在这些状态下仍能安全运行进行软件强度测试，确保软件安全运行确保外购软件安全运行订购方所提供的软件，不管是否进行了修改，都需要进行测试，以保证这些软件在系统中安全运行确保在系统综合测试和系统验收测试中所发现的危险事件得到了纠正，确保对这些事件进行了重新测试，没有遗留问题第14页，共46页，2023年，2月20日，星期二2.6软件与用户接口危险性分析提供检测危险征兆或潜在危险状态的方法，预防安全事故的发生控制危险事件，使其只有在特殊的情况下和操作员特定的命令下才可能发生向操作员、用户和其它人员提供报警功能，指示可能出现或正在出现的潜在危险当危险事件发生后，确保系统能够生存当预防和控制危险的规程失败后，或危险事件发生时，能提供控制损害程度的规程和恢复到安全状态的规程提供在严重危险状态下使系统生存和恢复功能的规程具有安全终止某个事件和安全终止程序运行的能力具有向操作员提供系统或软件失效的报警功能具有向操作员提供安全性决策所需的信息，确保危险数据能够明确显示第15页，共46页，2023年，2月20日，星期二2.7软件更改危险分析分析系统，分系统接口，逻辑和其它设计更改对安全性的影响，确保这些更改不会产生新的危险，不会触发已经消除的危险，不会使现存的危险变得更严重，不会对有关的设计和程序产生任何有害的危害对更改进行测试，确保更改后的软件不包含危险事件确保软件的更改已经在编程中准确的实现评审和修改有关文档，以反映这些更改将执行软件更改危险分析的方法和程序纳入软件配置管理计划第16页，共46页，2023年，2月20日，星期二3软件失效模式效应分析失效模式效应分析FMEA传统的系统可靠性，安全性分析方法增加危害度分析的内容，称为失效模式，效应及危害度分析，简称为FMECA第17页，共46页，2023年，2月20日，星期二3.1FMEA的例子:速度传感器gearboxcontrollersensorsignalprocessingunit仪表盘gearboxtoothedwheel第18页，共46页，2023年，2月20日，星期二FMEA报告:速度传感器组件失效模式局部效果系统效果危害SpeedsensorBreaksSpeedcalculatedaszero1.

Speedometershowszero2.

Odometer(里程表)notupdated3.

Wronggearselected1.

Drivermislead,...2.

Maintenance

delayed,...3.

Engineseizes

athighspeed,...第19页，共46页，2023年，2月20日，星期二3.2FMEA特点失效模式和影响分析方法:从组件的已知的或者预测的失效模式，确定对系统可能的效果比较有利于在开发早期识别系统的危险:lossoffunction(omissionfailure)functionperformedincorrectlyfunctionperformedwhennotrequired

(commissionfailure)第20页，共46页，2023年，2月20日，星期二3.3软件FMEA方法软件与硬件具有相似性，但是又存在若干重要差别，例如软件的执行是串行的软件FMEA中的失效模式、影响和严重性分类方法，可参考相关的资料，例如IEEE失效模式分类方法第21页，共46页，2023年，2月20日，星期二1.系统定义在系统定义中应说明系统的主要功能和次要功能，用途，系统的约束条件和失效判据等2.危险分析在危险分析中，主要任务是找出对系统功能和安全性影响较大的危险事件，确定软件的不安全模式。对这些危险事件的出现有直接或间接关系的单元称为安全关键单元。第22页，共46页，2023年，2月20日，星期二建立危险事件及其发生原因联系

安全关键单元分原因1分原因2分原因3……分原因n

危险事件1原因1

原因2

……

危险事件n原因1

原因2

……

第23页，共46页，2023年，2月20日，星期二3.结构分解及分层次定义按功能分解按软件系统结构特征分解按软件工作模式分解4.失效模式分析填写失效模式分析表格并进行危害度分析及提出改进、纠正措施第24页，共46页，2023年，2月20日，星期二3.4嵌入式软件的FMEA分析方法嵌入式计算机控制系统特征系统的软硬件配置与通用系统不同系统设计：硬件与软件必须同步进行使用的语言嵌入式计算机软件的可靠性特征与安全关键任务有关的嵌入式软件，对系统的可靠性与安全性构成严重威胁嵌入式计算机硬件和软件的可靠性是相互联系、相互制约的必须将系统反应时间是否符合规定的要求作为嵌入式实时计算机控制系统的失效判据由于开发环境相对不够完善，软件的可靠性较难保证第25页，共46页，2023年，2月20日，星期二软硬件综合FMEA分析方法的步骤根据系统的功能和软件的需求说明，绘制出软件或软件单元的控制功能的流程图将控制功能流程图中的每一个单元，等同于硬件系统中的一个元件按照常规FMEA分析方法的原则，分析各个单元的各种失效模式。但是与硬件的失效模式分析的区别是，分析时必须详细研究软件的各种可能的失效模式分析每一个失效模式的影响，分析失效模式影响的严重程度将分析的结果，填写入FMEA分析表格区分各种失效模式的严重程度，有针对性地提出纠正措施第26页，共46页，2023年，2月20日，星期二软硬件综合FMEA分析方法的特点软硬件综合FMEA分析方法的特点是以计算机软件的控制流程图为线索，对系统进行功能和结构分解，进行更深层次的分析常规FMEA分析方法通常是在硬件（例如电路）的详细设计完成后，利用归纳法从底向上，逐级上推，跟踪分析底层元器件失效模式对系统的最终影响。软硬件综合FMEA分析方法的一个基本依据是软件的需求说明由于软硬件综合FMEA分析是将软件和受控的硬件作为一个整体进行分析，所以容易考察硬件和软件的相互作用。第27页，共46页，2023年，2月20日，星期二例子嵌入式发动机测速软件控制流程图检查发动机的速度检查速度允许范围软件单元1软件单元2在维修记录中写入并报警输出至发动机模块软件单元3软件单元4IF否是软件读入错误的速度输入数据；没有输入数据供软件读入；软件不能正确读取或处理输入的数据；速度在容限内被判为超限；速度在容限外被判为正常在速度正常时被作为不正常值写到维护记录中；在速度不正常时没有作出记录。在速度正常时没有数据输入发动机监控装置在速度不正常时被误认为正确的输入发动机监控装置第28页，共46页，2023年，2月20日，星期二失效原因分析检查发动机的速度检查速度允许范围软件单元1软件单元2在维修记录中写入并报警输出至发动机模块软件单元3软件单元4IF否是测速器和传感器故障；微处理器存储器故障；程序设计上的错误；功能和逻辑都很简单，因此本单元的失效都是来自于软件单元1的从属失效来自软件单元1的从属失效；本单元软件设计的接收数据等待时间短于测速器数据测量和传输时间功能和结构简单，失效原因不可能出自软件单元内部，而是单元1、单元2导致的从属失效第29页，共46页，2023年，2月20日，星期二失效纠正措施关键作用的原因：测速器和传感器故障微处理器存储器故障软件单元1设计错误软件单元3设计接收数据等待时间短于测速器和传感器数据的测量和传输时间硬件故障，解决方法：提高测速器和传感器及微处理器的可靠性软件设计错误第30页，共46页，2023年，2月20日，星期二例子2粮食自动装载运输系统任务101开始从传感器上读入小车到达的信号，停止传输线的运行任务102使装料桶倾斜，向小车倾倒粮食任务201小车停留n秒，然后继续运行任务103读取到达编码器的信息，小车停止运行任务202小车停止打码任务104读取到达派送器的信息任务203移动小车到达预订的生产线第31页，共46页，2023年，2月20日，星期二软件单元系统失效模式失效原因影响严重程度建议的软件硬件改正措施101软件误认为小车已经到达，实际上小车没有到达传感器功能不正常或微处理器数据位发生错误粮食大量倾倒，造成严重损失十分严重除正常的控制系统外，建议增加一个附加的电子观察装置

软件误认为小车没有到达，实际上小车已经叨叨传感器功能不正常或微处理器数据位发生错误，程序功能错误小车空载，正常生产过程被打乱严重增加一个传感器，程序应检查二者是否一致，并从打码处获取反馈信息，软件应该经过严格的测试和验证102装料桶对程度的命令没有反应控制开关失效生产过程中断严重程序的命令应换接到另一备用的控制电路

装料桶装料之后没有返回正常状态控制开关失效粮食大量的倾倒到厂房地面，可能造成粮食的严重污染十分严重设计一个等待时间达N+2分钟后使装料桶复位的程序，载开关失效时装料桶应处于失效、安全状态201小车等待时间过长时钟错误粮食大量倾倒十分严重程序应用一个主时钟，检查控制器时钟的误差是否在允许范围内，如果时间误差达到N+2分钟，则打印输出并报警………………………………

第32页，共46页，2023年，2月20日，星期二分析结果软件系统的需求规格说明存在缺陷，例如最初的需求说明没有考虑到如果装料桶的计时器在使用过程中逐渐发生误差，使装载时间延长，结果可能出现每次装载的粮食太多，由小车舱中溢出一些通用的失效模式纠正措施从设计方案中，消除导致关键性的硬件失效原因采用容错设计技术采用失效安全设计技术在软件执行关键性功能时，应使程序具有自检查的功能对用户进行专门的培训第33页，共46页，2023年，2月20日，星期二4软件故障树分析法故障树分析法（SFTA)是硬件可靠性和安全性分析的重要技术工具在软件开发的早期，可以用故障树分析来确定软件的安全要求，当进入设计后期或在编码完成后，可以对故障树加以扩充，继续进行更输入的分析第34页，共46页，2023年，2月20日，星期二4.1故障树的逻辑关系逻辑“或”逻辑“与”逻辑否定第35页，共46页，2023年，2月20日，星期二图形符表示基本事件，或元件的初始失效，对于故障树中的基本事件没有必要作更深入的分析矩形符表示需进一步分析的事件，当它用于故障树的顶端时，表示顶端事件，即系统的某种不可靠或不安全的事件第36页，共46页，2023年，2月20日，星期二菱形符表示非基本事件，但是由于缺乏必要的信息，无法作更深沉的分析，这种事件又称准基本事件双菱形符表示一个重要事件，其原因尚未穷尽，需要更深入的分析展开第37页，共46页，2023年，2月20日，星期二三角形转入符表示某事件的转入，用于简化故障树三角形转出符用来表示某事件的输出，用于简化故障树第38页，共46页，2023年，2月20日，星期二房型符表示系统中正常发生的事件，例如用来表示元件的连续运行椭圆型符用来表示某种条件，可以是这个符号来定义系统的可以导致某种失效事件的系统状态或条件第39页，共46页，2023年，2月20日，星期二4.2危险分析危险分析的目的是确定系统可能出现的各种不安全状态，从安全的角度确定哪些失效是可以允许的，确定哪些失效是不允许的，确定在危及安全的失效发生或可能发生时，如何使系统处于失效－安全状态在对系统的软件进行危险分析时，不仅应考虑软件的控制失误，而且必须研究软件和系统其它单元的接口对系统的软件进行危险分析时，还必须把操作者的因素考虑在内，要仔细地考虑控制系统中的人机接口第40页，共46页，2023年，2月20日，星期二4.3构造故障树与硬件故障树的构造方法一样123496587火轮自旋过快