软件安全工程讲解

1、软件安全性工程 姓名： 学号： 第二章 软件与系统安全 ? 安全性是指不发生导致人员伤亡、职业病、设备损坏或财 产损失的意外事件的能力。 ? 1986年，Nancy Leveson 向计算机科学界提出“软件安全 性”的概念。 ? GJB142-2004军用软件安全性分析指南定义的软件安 全性味“软件具有的不导致事故发生的能力。确切的说， 软件安全性是软件的功能安全性。” ? 软件安全性是软件的一个质量属性或一种能力。软件安全 性是软件的一个质量属性或一种能力。要在系统坏境中讨 论软件安全性。 软件安全性的提出及定义 ? 强调要在系统环境中讨论软件安全性： ? 软件安全性离不开系统安全性，特别是

2、在航空航天等大型 复杂嵌入式系统中更是如此。软件安全性需求来源于系统 安全性要求，只有通过对复杂系统逐层的危险分析，才能 确定系统所面临的危险，只有依据对具体系统设计方案的 分析，才能确定软件与相关危险的关联度，在此基础上才 能进一步分析确定软件的安全性需求和软件的关键等级。 ? 软件本身对人员不会产生威胁，但软件中的缺陷有可能 通过硬件、软件的接口使硬件发生误动和失效，造成严重 的安全事故。 危险与风险 ? 危险 ? 可能导致事故的状态。-GJB 900 ? 可能导致或有助于事故或灾难（人员伤亡、或系统毁坏、 或财产损失或环境破坏等）发生的实际条件或潜在条件 （一维） ? 风险 ? 不期望的

3、事件或状态发生的严重度与可能性（二维） 软件怎样会有危险？ ? 软件自身设计没有按照需求正确实现系统要求的功 能或是采用了错误的设计参数、运行数据等。 ? 软件需求或设计遗漏。 ? 软件运行支撑环境出现故障。 ? 与软件输入信号相关的传感器、传输线或硬件输入 接口等发生故障。 安全关键软件 ? 安全关键软件对安全性要求苛刻，它能够控制或 监控危险。 ? 实例 ?监控探测系统：当温度超过阀值时，操作员必须 关闭硬件。这时软件需要将硬件温度传感器测得 的温度转换成适当的数据形式显示在屏幕 上提醒 操作员。 ?通过建模和仿真软件得到的软件反应用来进行设 计优化，不准会导致设计错误。 软件控制危险 ?

4、 当今的系统复杂性单靠硬件控制已经不够，很多控 制利用软件控制的快速反应能力。 ?监控危险硬件或执行纠正措施 ?监控潜在危险条件 ?抑制某些可能导致危险事件的操作 软件与危险控制的关系 ? NASA主要依赖硬件控制危险，同时结合软件防止 危害。 ? 硬件控制：追踪记录更好、作为软件控制的备份 ? 软件控制：软件是第 一道防线、能实时监测不安全 条件并适当回应 ? 在系统开发过程中，要特别关注软件的“控制防止 危险功能”，软件必须经过严格的开发 和测试。 软件控制风险警告 ? 软件控制风险时，必须将控制软件与风险原因隔离开。 ? 在风险或异常可能发生的地方，风险控制软件可驻留在一 个单独的计算机

5、处理器中。 ? 使用防火墙或类似隔离系统风险控制软件。 ? NASA的经验表明，考虑到电脑是唯一的风险监控、监测或 控制手段，当发生故障时，自动关闭程序或计算机可能导 致更严重的危险。采用自我隔离或检测纠正或减轻问题， 这样可能更好。 故障和容错 ? 故障是指软件在运行过程中出现的一种不希望或不可接受 的内部状态，通常是由于软件缺陷在运行时引起并产生的 错误状态。如不正确的数值，数据在传输中产生的偏差。 ? 失效是指程序的运行偏离了需求，是动态运行的结果，软 件执行遇到软件中的缺陷时可能会导致软件的失效。如死 机、错误的输出结果、没有在规定的时间内响应都是失效。 ? 所谓容错是指在故障存在的情

6、况下计算机系统不失效，仍 然能够正常工作的特性。 ? NASA的标准是：灾难性的危险必须能够容忍两种风险控制 失效。关键危险必须能够容忍一个风险控制失效。 系统安全规划计划 ? 系统安全规划计划是安全执行开发 和分析软件的先 决条件 。系统安全规划计划为产品开发提供了了 组织结构、接口和所需的标准分析、报告、评价 和 数据保留。安全计划还描述软件分析模式、为整个 软件开发周期中的系统 和子系统提供一个时间表， 它还标明特定的要求。 ? 在开发软件之前还要进行危害分析（ PHA）, 识别 潜在的危险，做到在设计之初排除错误。 系统安全过程 ? 系统安全分析贯穿系统开发的整个生命周期。系统 的开发

7、整合了硬件、软件 和开发人员，因此应当具 有让各方面人才能发挥优势的接口，通过发挥各工 程学科人员的优点构思、设计系统，从单 一到整体 都进行评估，从而设计出好的系统。 ? 采用并行工程监管，使信息 和通信得到改善，加强 各个学科之间交换想法，减少重复努力。 ? 系统安全过程应当从开始阶段排除潜在的危险，这 样的设计更容易、更简单、更经济。 系统安全性和软件开发 ? 对于NASA,系统安全并不在软件开发周期中，它有自己的 一些任务。 ? NASA的系统安全任务有： ? 创建用来描述设备（硬件、软件、开发人员、操作人员） 属性的数据包，并且提供任何有关安全隐患、控制或者移 植的信息。 ? 在整个

8、系统开发周期中进行安全审查。 ? 进行安全认证活动，包括完成发射前日志跟踪，日志里要 含有所有的安全功能、控制功能记录。 第三章 软件安全计划 软件安全性工作要求 软件安全性工作，在实际开展过程中，应该满足下列各项要 求，这些要求都是实际问题项目中总结出来的宝贵经验。 ? 确保系统/ 子系统进行安全性分析以明确安全性关键软件； ? 确保系统/ 子系统进行安全性分析以明确定义软件需求说明 的重要输入信号，如危险命令、边界值、相互关系的制约 、事件的前后时序、时间的限制、表面逻辑、失效容限、 对危险硬件失效的识别、警告和提示界面等; ? 确保软件需求规格说明的开发包含了软件安全性需求（必 须做什么

9、 、不能做什么）； ? 确保将软件安全性需求融合到软件的设计与实现中； ? 确保建立起合适的验证和确认机制以保障软件安全需求得 到贯彻实 施； ? 确保测试计划和过程符合软件安全性验证需求的内容； ? 确保软件安全性验证工作的结果满足要求； 系统要求分析和软件定义阶段 ? 开展系统初步危险分析 ? 在此阶段开展初步危险分析的目的是标识正在开发的系统 的危险 ，及其概要原因因素，同时要确定软件是否是安全 关键的。此工作可采用方法有功能危险分析、FTA 、FMEC A 等危险分析方法。 ? 制定软件安全性工作计划。 ? 制定软件安全性工作计划的目的是为计划软件安全努力程 度，并 根据软件及其系统的

10、风险等级来对工作进行裁减。 这部分内容的 主要工作内容包括： 确定软件关键性等级。 确定软件开发不同阶段软件安全性工作、方法选取、责任 人。 明确不同等级软件的安全性努力程度。 明确软件安全性跟踪方式。 软件需求分析阶段 该阶段软件安全性的主要工作是确定软件安全性需求，并 验 证其完整性、正确性、一致性。主要工作包括： ? 提取软件安全性需求 ? 裁减通用软件安全性需求 ? GJB/Z102软件可靠性安全性设计准则 ? NSTS 19943, Command Requirements and Guidelines fo r NSTS Customers ? 获取特定软件安全性需求 ? 可综合采

11、用自顶向下分析（如SFTA ）、初步危险分析（ P HA）、自底向上的分析（如SFMEA ）等方法，并特别考虑 故障和失效容限、危险命令、时间、和吞吐量等方面。 ? 软件安全性需求分级 软件安全性需求获取工作要求 ? 软件安全性需求应包含在软件需求规格说明中； ? 软件安全性需求应包括通用需求和特定需求，这些需求应 来源 于相关标准、系统安全性需求、环境需求、程序说明 书、工具 或设施需求、接口需求、系统危险报告和系统危 险分析等； ? 软件安全性需求既应包括有效运行的模式或状态，又应包 括所 有应禁止的模式或状态。（注：这些需求通常被称为 “必须工 作”和“必须不工作”，例如，在机器人的维护

12、 模式下，启动 机器人手臂运动的关键命令必须不能工作。 ）； ? 任何与安全性有关的软、硬件间的约束应纳入软件需求规 格说 明，即，当软、硬件协同完成一项安全关键功能时， 他们的各 自角色、优先级和失效模式应被记录下来并能得 到理解； ? 每一项软件安全性需求在软件需求规格说 明 中的表达方式应明确和规范，以使每一项 需 求都清晰、准确、不含糊、可验证、可 测试 、可维护和可实现； ? 每一项软件安全性需求在软件需求规格说 明 中都应具有一个清晰的唯一标识，并在软 件 开发和运行全过程进行追踪。 验证软件安全性需求 ? 软件安全性需求验证包括评估需求的正确性 与完整性，以确保需求提供了合适的基

13、础以 便继续开展设计码和测试。 ? 验证方法可采取正式审查（检查单）、形 式化方 法（包括Petti网、模型检验等）等 手段进行。 软件安全性需求验证工作要求 ? 软件安全性人员应对软件安全性需求进行验证，验证对象 应既包括技术需求，又包括过程要求。 ? 软件安全性需求验证方法应记录在合适的文档中，并 应至 少包括如下步骤： ? 应验证所有的软件安全性需求满足上文中获取安全性需求 的工作要求中的所有要求； ? 应验证软件安全性需求对潜在失效进行了充分的考虑并提 供了适当的响应，应至少考虑由于如下问题会产生的失效 ：幅 值/ 范围等限制、相互依赖的限制之间的逻辑关系、对 时序错 误的事件的保护、

14、定时问题、传感器或执行器的失 效、表决 逻辑、危险命令的处理需求、故障检测隔离和恢 复（FDIR ）、用于容失效的切换逻辑、以及在需要时达到 并维持在某安全状态的能力； ? 应验证软件安全性需求包括了防止潜在问题的积极措施，这 些措施是用于防止潜在危险发生并实现所要求的“必须工作 ”的功能。 ? 检查软件安全性需求中是否存在二义性、不一致性、遗漏和 未定义的条件； ? 应验证所有的软件安全性需求对相关标准、系统安全性需求 、环境需求、程序 说明书、工具或设施需求、接口需求、 系统危险报告和系统危险分析等是可追溯的； ? 上述的分析验证结果应形成文档并提供给系统安全性人员， 文档中 应包括新发现的危险、危险原因以及没有被适当分 解的需求； ? 应将没有被适当分解的需求形成文档提交给系统设计层以求 解决； ? 在正式的系统设计评审（project review）和系统安全性评 审时， 应由负责相关工作的安全性组织提交并汇报软件安 全性需求分析验证的结果。 设计阶段 ? 软件安全性设计工作要求