您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
安全性需求追踪模型
 
84 次浏览     评价:  
 2018-10-31 
 
编辑推荐:

本文来自于CSDN,文章介绍了安全性分析过程的相关实体以及追踪模型的相关知识,并配以实例进行讲解。

1. 实体

由上图我们可以分析出各个阶段存在的实体

关于假设和决策基本原理不容易理解

假设:在分析的任一步骤,对任一数据或关联,都可能会做出假设,即其前提条件。例如,某两个潜在失效的发生会导致一个系统失效,那么在对该系统失效执行故障树定量分析时,常常会做这样的失效假设:这两个组件在任务之初均未失效。再例如,某软件的数据在两个显示器上显示,这两个显示器显示的数据是相同的,那么对于产生错误数据的软件失效,可能做如下最坏情况假设:该软件失效同时影响两个显示器

决策:在分析的任一步骤,任一数据或关联的创建都有其原因(rationale),特别是一些设计决策。

[6] BASHIR M F,QADIR M A.Traceability Techniques:A CriticalStudy[C]∥Multitopic Conference,2006(INMIC’06).IEEE,2006:23-24.

2. 关联

(1)建立自上而下的追踪

每个危害存在影响(即损害)、发生概率、严重程度等属性。危害的这些属性决定了它的风险,而风险威胁系统的安全性。为了控制风险,保证安全性,提出安全性需求来处理危害。系统开发初期提出的安全性需求主要确立了系统安全性目标,如完整性或可靠性的一些需求和设计约束。而每个安全性功能需求必然与某个安全性目标相关联。

基于初期功能危害分析确定的危害和安全性目标做出设计决策,以最终满足系统的安全性需求。系统设计阶段,从危害出发,识别造成危害的系统失效和故障。为处理这些失效和故障,安全性需求被提出。至此,自上而下的追踪关系建立完成。

(2)建立自下而上的追踪

Menon和Kelly[5]指出,系统到软件的安全性分析建立从系统危害到软件安全性需求的正向追踪。而在复杂系统的开发中,软件安全性分析的结果也会影响系统的开发,因此还应开展软件到系统的安全性分析,建立从软件安全性故障到系统危害的逆向追踪,而这恰恰是很多研究所忽略的。

自下而上建立追踪主要是关注软件到系统的安全性分析,目的是建立从新识别的软件失效到系统危害的逆向追踪,即如果该软件失效是原来已识别的系统故障,建立逆向追踪即可;否则,将软件失效作为新的系统故障,评估其影响,即系统失效,向上继续评估系统失效影响,追踪到危害。至此,自下而上的追踪关系建立完成。

3. 追踪模型

图3中的所有实体定义为Object类的子类,关联定义为Link类的子类。那么,

1)在分析的任一步骤,对任一数据或关联,都可能会做出假设,即其前提条件。假设应当被验证。假设可分为功能上下文假设(functionalContet)和安全性分析假设(analysisAssumption)。功能上下文假设括运行阶段(phase)、环境配置和状态(environmentalConiguration)等。

2)在分析的任一步骤,任一数据或关联的创建都有其原因(rationale),特别是一些设计决策。

3)任一数据或关联均由某个人创建。用户角色(actor)活动的记录和追踪有利于任务的分配和管理。

4) 追踪约束关系

建立双向追踪链时,应遵循的约束包括:

1)每个危害都被处理。危害的处理可能是直接的,即该危害直接被某个或某些安全性需求所处理;也可能是间接的,即导致该危害的所有失效或故障都被某个或某些安全性需求所处理,最终使得该危害被处理。

2)每个失效/故障,或者被处理,或者由于某种理由放弃处理。失效/故障的处理可能是直接的,即该失效/故障直接被某个或某些安全性需求所处理;也可能是间接的,即导致该失效/故障的所有失效或故障都被某个或某些安全性需求所处理,最终使得该失效被处理。

3)每个被间接处理的危害/失效/故障,都要求提供证据(assumption类)来证明导致该危害/失效/故障的所有失效或故障已识别完备。

4)每个放弃处理的失效/故障都要求指明理由(rationale类)。

5)每个安全性目标(safetyGoal)都关联到某个或某些安全性功能需求(safetyFunctionalReq)。

6)每个假设(assumption)都最终被某个或某些人(actors)确认。

7)对于每个危害、失效和故障,都应分析其影响、发生概率、严重程度。

4.实例

电系统的某机载操作系统为例进行说明。该操作系统支持FC通信系统、综合显示系统、导航系统、航向姿态系统等的软件运行。其中FC通信任务由FC通信子卡驱动软件与FC接口硬件协同完成。FC通信子卡驱动软件运行于操作系统之上,主要提供设备管理、通信管理、时统管理、网络管理、中断管理和配置加载的功能,完成FC网络数据的收发,为应用系统提供FC网络通信能力。FC通信系统的软件架构图如图4所示。

第1部分构建自上而下的追踪关系,对应初步功能危害分析和系统安全性分析,建立了危害、失效、功能、假设的追踪关联。初期识别到的危害H1“飞机通信数据接收异常”是“通信”功能的一种失效情况。由于通信子卡驱动软件的通信管理功能与数据接收有关,因此该软件的失效F1“接收缓冲区获取失败”可能导致上述危害H1。

第2部分构建自下而上的追踪关系,对应软件安全性分析。“进程调度”功能在运行时可能出现故障FT1“进程在队列中等待过久未被执行”,该故障可能导致系统失效F2“数据接收超时”,并进一步导致危害H1。失效F2是软件安全性分析过程新识别到的系统失效,也是导致危险H1的原因。

第3部分构建安全性需求和决策基本原理的关联,对应决策基本原理等数据的追踪(见图3)。这是利用历史经验数据直接获取操作系统高层安全性需求的特例,着重捕获提出该需求的决策基本原理。

   
84 次浏览  评价: 差  订阅 捐助
 
相关文章

锻造软件需求人员的六大要素
开发需求路线图:重要的是规划
需求用例模板
如何做好需求变更管理?流程规范
 
相关文档

需求分析方法
需求分析与建模(两个周期)
如何将客户需求转化为技术需求
产品生命周期管理
 
相关课程

面向产品的需求分析与管理
面向产品的需求分析与管理
非功能需求分析与管理
用户体验 & 界面设计
软件需求分析与管理
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号