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