软件安全工程.ppt

软件安全性工程,第二章 软件与系统安全,安全性是指不发生导致人员伤亡、职业病、设备损坏或财产损失的意外事件的能力。1986年，Nancy Leveson 向计算机科学界提出“软件安全性”的概念。GJB142-2004军用软件安全性分析指南定义的软件安全性味“软件具有的不导致事故发生的能力。确切的说，软件安全性是软件的功能安全性。”软件安全性是软件的一个质量属性或一种能力。软件安全性是软件的一个质量属性或一种能力。要在系统坏境中讨论软件安全性。,软件安全性的提出及定义,强调要在系统环境中讨论软件安全性：软件安全性离不开系统安全性，特别是在航空航天等大型复杂嵌入式系统中更是如此。软件安全性需求来源于系统安全性要求，只有通过对复杂系统逐层的危险分析，才能确定系统所面临的危险，只有依据对具体系统设计方案的分析，才能确定软件与相关危险的关联度，在此基础上才能进一步分析确定软件的安全性需求和软件的关键等级。软件本身对人员不会产生威胁，但软件中的缺陷有可能通过硬件、软件的接口使硬件发生误动和失效，造成严重的安全事故。,危险与风险,危险可能导致事故的状态。-GJB 900 可能导致或有助于事故或灾难（人员伤亡、或系统毁坏、或财产损失或环境破坏等）发生的实际条件或潜在条件（一维）风险不期望的事件或状态发生的严重度与可能性（二维）,软件怎样会有危险？,软件自身设计没有按照需求正确实现系统要求的功能或是采用了错误的设计参数、运行数据等。软件需求或设计遗漏。软件运行支撑环境出现故障。与软件输入信号相关的传感器、传输线或硬件输入接口等发生故障。,安全关键软件,安全关键软件对安全性要求苛刻，它能够控制或监控危险。实例监控探测系统：当温度超过阀值时，操作员必须关闭硬件。这时软件需要将硬件温度传感器测得的温度转换成适当的数据形式显示在屏幕上提醒操作员。通过建模和仿真软件得到的软件反应用来进行设计优化，不准会导致设计错误。,软件控制危险,当今的系统复杂性单靠硬件控制已经不够，很多控制利用软件控制的快速反应能力。监控危险硬件或执行纠正措施监控潜在危险条件抑制某些可能导致危险事件的操作,软件与危险控制的关系,NASA主要依赖硬件控制危险，同时结合软件防止危害。硬件控制：追踪记录更好、作为软件控制的备份软件控制：软件是第一道防线、能实时监测不安全条件并适当回应在系统开发过程中，要特别关注软件的“控制防止危险功能”，软件必须经过严格的开发和测试。,软件控制风险警告,软件控制风险时，必须将控制软件与风险原因隔离开。在风险或异常可能发生的地方，风险控制软件可驻留在一个单独的计算机处理器中。使用防火墙或类似隔离系统风险控制软件。NASA的经验表明，考虑到电脑是唯一的风险监控、监测或控制手段，当发生故障时，自动关闭程序或计算机可能导致更严重的危险。采用自我隔离或检测纠正或减轻问题，这样可能更好。,故障和容错,故障是指软件在运行过程中出现的一种不希望或不可接受的内部状态，通常是由于软件缺陷在运行时引起并产生的错误状态。如不正确的数值，数据在传输中产生的偏差。失效是指程序的运行偏离了需求，是动态运行的结果，软件执行遇到软件中的缺陷时可能会导致软件的失效。如死机、错误的输出结果、没有在规定的时间内响应都是失效。所谓容错是指在故障存在的情况下计算机系统不失效，仍然能够正常工作的特性。NASA的标准是：灾难性的危险必须能够容忍两种风险控制失效。关键危险必须能够容忍一个风险控制失效。,系统安全规划计划,系统安全规划计划是安全执行开发和分析软件的先决条件。系统安全规划计划为产品开发提供了了组织结构、接口和所需的标准分析、报告、评价和数据保留。安全计划还描述软件分析模式、为整个软件开发周期中的系统和子系统提供一个时间表，它还标明特定的要求。在开发软件之前还要进行危害分析（PHA）,识别潜在的危险，做到在设计之初排除错误。,系统安全过程,系统安全分析贯穿系统开发的整个生命周期。系统的开发整合了硬件、软件和开发人员，因此应当具有让各方面人才能发挥优势的接口，通过发挥各工程学科人员的优点构思、设计系统，从单一到整体都进行评估，从而设计出好的系统。采用并行工程监管，使信息和通信得到改善，加强各个学科之间交换想法，减少重复努力。系统安全过程应当从开始阶段排除潜在的危险，这样的设计更容易、更简单、更经济。,系统安全性和软件开发,对于NASA,系统安全并不在软件开发周期中，它有自己的一些任务。NASA的系统安全任务有：创建用来描述设备（硬件、软件、开发人员、操作人员）属性的数据包，并且提供任何有关安全隐患、控制或者移植的信息。在整个系统开发周期中进行安全审查。进行安全认证活动，包括完成发射前日志跟踪，日志里要含有所有的安全功能、控制功能记录。,第三章 软件安全计划,软件安全性工作要求,软件安全性工作，在实际开展过程中，应该满足下列各项要求，这些要求都是实际问题项目中总结出来的宝贵经验。确保系统/子系统进行安全性分析以明确安全性关键软件；确保系统/子系统进行安全性分析以明确定义软件需求说明的重要输入信号，如危险命令、边界值、相互关系的制约、事件的前后时序、时间的限制、表面逻辑、失效容限、对危险硬件失效的识别、警告和提示界面等;确保软件需求规格说明的开发包含了软件安全性需求（必须做什么、不能做什么）；确保将软件安全性需求融合到软件的设计与实现中；确保建立起合适的验证和确认机制以保障软件安全需求得到贯彻实 施；确保测试计划和过程符合软件安全性验证需求的内容；确保软件安全性验证工作的结果满足要求；,系统要求分析和软件定义阶段,开展系统初步危险分析在此阶段开展初步危险分析的目的是标识正在开发的系统 的危险，及其概要原因因素，同时要确定软件是否是安全关键的。此工作可采用方法有功能危险分析、FTA、FMECA等危险分析方法。制定软件安全性工作计划。制定软件安全性工作计划的目的是为计划软件安全努力程度，并 根据软件及其系统的风险等级来对工作进行裁减。这部分内容的 主要工作内容包括：确定软件关键性等级。确定软件开发不同阶段软件安全性工作、方法选取、责任人。明确不同等级软件的安全性努力程度。明确软件安全性跟踪方式。,软件需求分析阶段,该阶段软件安全性的主要工作是确定软件安全性需求，并 验证其完整性、正确性、一致性。主要工作包括：提取软件安全性需求裁减通用软件安全性需求GJB/Z102软件可靠性安全性设计准则NSTS 19943,Command Requirements and Guidelines for NSTS Customers获取特定软件安全性需求可综合采用自顶向下分析（如SFTA）、初步危险分析（PHA）、自底向上的分析（如SFMEA）等方法，并特别考虑 故障和失效容限、危险命令、时间、和吞吐量等方面。软件安全性需求分级,软件安全性需求获取工作要求,软件安全性需求应包含在软件需求规格说明中；软件安全性需求应包括通用需求和特定需求，这些需求应来源 于相关标准、系统安全性需求、环境需求、程序说明书、工具 或设施需求、接口需求、系统危险报告和系统危险分析等；软件安全性需求既应包括有效运行的模式或状态，又应包括所 有应禁止的模式或状态。（注：这些需求通常被称为“必须工 作”和“必须不工作”，例如，在机器人的维护模式下，启动 机器人手臂运动的关键命令必须不能工作。）；任何与安全性有关的软、硬件间的约束应纳入软件需求规格说 明，即，当软、硬件协同完成一项安全关键功能时，他们的各 自角色、优先级和失效模式应被记录下来并能得到理解；,每一项软件安全性需求在软件需求规格说明 中的表达方式应明确和规范，以使每一项需 求都清晰、准确、不含糊、可验证、可测试、可维护和可实现；每一项软件安全性需求在软件需求规格说明 中都应具有一个清晰的唯一标识，并在软件 开发和运行全过程进行追踪。,验证软件安全性需求,软件安全性需求验证包括评估需求的正确性 与完整性，以确保需求提供了合适的基础以 便继续开展设计码和测试。验证方法可采取正式审查（检查单）、形式化方 法（包括Petti网、模型检验等）等手段进行。,软件安全性需求验证工作要求,软件安全性人员应对软件安全性需求进行验证，验证对象应既包括技术需求，又包括过程要求。软件安全性需求验证方法应记录在合适的文档中，并 应至少包括如下步骤：应验证所有的软件安全性需求满足上文中获取安全性需求的工作要求中的所有要求；应验证软件安全性需求对潜在失效进行了充分的考虑并提供了适当的响应，应至少考虑由于如下问题会产生的失效：幅 值/范围等限制、相互依赖的限制之间的逻辑关系、对时序错 误的事件的保护、定时问题、传感器或执行器的失效、表决 逻辑、危险命令的处理需求、故障检测隔离和恢复（FDIR）、用于容失效的切换逻辑、以及在需要时达到并维持在某安全状态的能力；,应验证软件安全性需求包括了防止潜在问题的积极措施，这些措施是用于防止潜在危险发生并实现所要求的“必须工作”的功能。检查软件安全性需求中是否存在二义性、不一致性、遗漏和未定义的条件；应验证所有的软件安全性需求对相关标准、系统安全性需求、环境需求、程序 说明书、工具或设施需求、接口需求、系统危险报告和系统危险分析等是可追溯的；上述的分析验证结果应形成文档并提供给系统安全性人员，文档中 应包括新发现的危险、危险原因以及没有被适当分解的需求；应将没有被适当分解的需求形成文档提交给系统设计层以求解决；在正式的系统设计评审（project review）和系统安全性评审时，应由负责相关工作的安全性组织提交并汇报软件安全性需求分析验证的结果。,设计阶段,软件安全性设计工作要求所有的软件安全性功能性需求应落实到软件设计中；软件设计应标识用于安全性设计的特征和方法（例如：禁止、故障检测和恢复、自锁、断言和以及划分）；采用的软件设计应能够对软件安全性特征和安全性需求进行彻 底的测试。应将实现安全关键需求或者可通过失效或其他机制影响安全性 元素的设计要素指定为安全关键的；设计文档应明确标识出所有安全关键的设计要素；软件设计应将软件安全性相关的设计进行模块化，以满足实际 应用的需要。,谢谢！,