软件安全工程-精.pptVIP

软件安全性工程 姓名： 学号： 第二章 软件与系统安全 安全性是指不发生导致人员伤亡、职业病、设备损坏或财产损失的意外事件的能力。 1986年，Nancy Leveson 向计算机科学界提出“软件安全性”的概念。 GJB142-2004《军用软件安全性分析指南》定义的软件安全性味“软件具有的不导致事故发生的能力。确切的说，软件安全性是软件的功能安全性。” 软件安全性是软件的一个质量属性或一种能力。软件安全性是软件的一个质量属性或一种能力。要在系统坏境中讨论软件安全性。 软件安全性的提出及定义 强调要在系统环境中讨论软件安全性： 软件安全性离不开系统安全性，特别是在航空航天等大型复杂嵌入式系统中更是如此。软件安全性需求来源于系统安全性要求，只有通过对复杂系统逐层的危险分析，才能确定系统所面临的危险，只有依据对具体系统设计方案的分析，才能确定软件与相关危险的关联度，在此基础上才能进一步分析确定软件的安全性需求和软件的关键等级。 软件本身对人员不会产生威胁，但软件中的缺陷有可能通过硬件、软件的接口使硬件发生误动和失效，造成严重的安全事故。 危险与风险 危险 可能导致事故的状态。-GJB 900 可能导致或有助于事故或灾难（人员伤亡、或系统毁坏、或财产损失或环境破坏等）发生的实际条件或潜在条件（一维） 风险 不期望的事件或状态发生的严重度与可能性（二维） 软件怎样会有危险？ 软件自身设计没有按照需求正确实现系统要求的功能或是采用了错误的设计参数、运行数据等。 软件需求或设计遗漏。 软件运行支撑环境出现故障。 与软件输入信号相关的传感器、传输线或硬件输入接口等发生故障。 安全关键软件 安全关键软件对安全性要求苛刻，它能够控制或监控危险。 实例 监控探测系统：当温度超过阀值时，操作员必须关闭硬件。这时软件需要将硬件温度传感器测得的温度转换成适当的数据形式显示在屏幕上提醒操作员。 通过建模和仿真软件得到的软件反应用来进行设计优化，不准会导致设计错误。 软件控制危险 当今的系统复杂性单靠硬件控制已经不够，很多控制利用软件控制的快速反应能力。 监控危险硬件或执行纠正措施 监控潜在危险条件 抑制某些可能导致危险事件的操作 软件与危险控制的关系 NASA主要依赖硬件控制危险，同时结合软件防止危害。 硬件控制：追踪记录更好、作为软件控制的备份 软件控制：软件是第一道防线、能实时监测不安全条件并适当回应 在系统开发过程中，要特别关注软件的“控制防止危险功能”，软件必须经过严格的开发和测试。 软件控制风险警告 软件控制风险时，必须将控制软件与风险原因隔离开。 在风险或异常可能发生的地方，风险控制软件可驻留在一个单独的计算机处理器中。 使用防火墙或类似隔离系统风险控制软件。 NASA的经验表明，考虑到电脑是唯一的风险监控、监测或控制手段，当发生故障时，自动关闭程序或计算机可能导致更严重的危险。采用自我隔离或检测纠正或减轻问题，这样可能更好。 故障和容错 故障是指软件在运行过程中出现的一种不希望或不可接受的内部状态，通常是由于软件缺陷在运行时引起并产生的错误状态。如不正确的数值，数据在传输中产生的偏差。 失效是指程序的运行偏离了需求，是动态运行的结果，软件执行遇到软件中的缺陷时可能会导致软件的失效。如死机、错误的输出结果、没有在规定的时间内响应都是失效。 所谓容错是指在故障存在的情况下计算机系统不失效，仍然能够正常工作的特性。 NASA的标准是：灾难性的危险必须能够容忍两种风险控制失效。关键危险必须能够容忍一个风险控制失效。 系统安全规划计划 系统安全规划计划是安全执行开发和分析软件的先决条件 。系统安全规划计划为产品开发提供了了组织结构、接口和所需的标准分析、报告、评价和数据保留。安全计划还描述软件分析模式、为整个软件开发周期中的系统和子系统提供一个时间表，它还标明特定的要求。 在开发软件之前还要进行危害分析（PHA）,识别潜在的危险，做到在设计之初排除错误。 系统安全过程 系统安全分析贯穿系统开发的整个生命周期。系统的开发整合了硬件、软件和开发人员，因此应当具有让各方面人才能发挥优势的接口，通过发挥各工程学科人员的优点构思、设计系统，从单一到整体都进行评估，从而设计出好的系统。 采用并行工程监管，使信息和通信得到改善，加强各个学科之间交换想法，减少重复努力。 系统安全过程应当从开始阶段排除潜在的危险，这样的设计更容易、更简单、更经济。 系统安全性和软件开发 对于NASA,系统安全并不在软件开发周期中，它有自己的一些任务。 NASA的系统安全任务有： 创建用来描述设备（硬件、软件、开发人员、操作人员）属性的数据包，并且提供任何有关安全隐患、控制或者移植的信息。 在整个系统开发周期中进行安全审查。 进行安全认证活动，包括完成发射前日志