技术开发 频道

软件安全性浅析

【IT168 技术文章】

  现今,软件安全性已成为一个越来越不容忽视的问题,提起它,人们往往会想起一连串专业性名词:“系统安全性参数”、“软件事故率”、“软件安全可靠度”、“软件安全性指标”等等,它们可能出现在强制的规范性文档中的频率比较多,但却不一定能在开发过程中吸引开发者的眼球。几乎每一个程序员都或多或少的在项目维护时遭遇过自己软件的安全性bug,这种经历使我们有幸在一个设计严谨而又性能良好的系统平台上工作时,都会对其大为感叹:“那真是一段很棒的代码!”这是因为,专业的软件设计开发人员会重视软件的安全性,而不仅仅把它当做是书面字眼。在这里本文将通过对软件安全性概念的引入,以及对软件安全性各阶段的任务的介绍和如何通过软件测试来验证是否完成了软件安全性目标,较全面的阐述软件安全性对软件质量起的重要作用。首先,应该从加固对软件安全性的认识开始。


  一、 软件安全性分析的重要性

  “安全性分析”(safety analysis)是一种系统性的分析,应在研发过程的早期开始进行,用于确定产品在每一个使用模式中执行其功能的方式,识别潜在的危险,预计这些危险对人员及(或)设备可能造成的损害,并确定消除危险的方法。其中对于计算机系统来说,安全性分析的一项重要内容是“软件安全性分析”,这是对软件程序进行的一种分析,以保证程序在其设计的运行环境中,不会引起(或可以容忍的小概率引起)或诱发对人员或设备的危害。例如多级火箭一级点火、二级点火指令如果错了,火箭就会失败。但只要对火箭指令及传递机构采取足够的防错设计,错发指令的概率就可以小到能容忍的程度。如果各关键项目的开发单位能从软件安全性这方面重视“安全”这个题目,那么项目的安全性链条就不会轻易地由于诸如小数点错位的原因而断开。

  在软件和信息系统的开发过程中,由于技术难度高,项目复杂,开发周期短而带来的一系列困难,潜伏安全性隐患的几率其实是很大的。现代化的软件本身变得越来越复杂,开发一个软件产品或一个大型系统所需要依靠的技术也越来越多样化,需要考虑的问题也越来越多,例如,开发团队需要在研发开始前就确定好软件系统能够承受的出事概率。很多软件开发的组织由于没有掌握和利用必要的控制软件安全性的技术,无法妥善解决相应的问题,把时间耗费在事后补救上,使得开发的效率大为降低,产品的质量大打折扣,甚至因为某个关键错误的发生,导致产品的信誉度降低,更严重的结果则会导致生命财产安全的损失。如果你发现有关安全性的要求已经出现在安全相关软件项目的合同书或任务书中,并提出软件安全性分析的范围和任务,那么说明已经需要开始进行软件安全性分析的准备了。


  二、 软件安全性分析的指导原则

  如果将软件安全性分析作为一项目标明确的项目去做,从管理的角度分为五个阶段,每个阶段有不同的任务需要完成。

  启动和范围确定:在安全相关软件的合同或任务书中应提出软件安全性分析的范围和要求。实施方明确责任,管理者检查必备的资源(包括人员、技术、基础设施和时间安排),确保软件安全性分析的开展;

  策划:软件安全性分析管理者应制定安全性分析计划,该计划可作为所属软件过程或活动的计划的一部分。

  执行和控制:管理者应监控由软件安全性分析计划规定的任务的执行。管理者应控制安全性分析进展并对发现的问题进行调查、分析和解决(解决方案有可能导致计划变更)。

  评审和评价:管理者应对安全性分析及其输出的软件产品进行评价,以便使软件安全性分析达到目标,完成计划。

  结束(收尾阶段):管理者应根据合同或任务书中的准则,确定软件安全性分析的是否完成,并应核查软件安全性分析中产生的软件产品和记录是否完整。

  上文将软件安全分析在一个典型的项目中各个阶段所要做的工作做了一个总结,每个阶段都有侧重的工作重点。我们在实际工作中,应调动所有有关人员,努力完成各阶段的任务。


  三、 软件安全性分析的任务

  根据上面所总结的各阶段需要做的安全分析重点,可以相应地总结出以下七种需要做的分析工作。在这里为抛砖引玉,再对相应的应用分析技术作一些介绍:

  1. 软件需求安全性分析——对分配给软件的系统级安全性需求进行分析

  做软件需求安全性分析需要对分配给软件的系统级安全性需求进行分析,规定软件的安全性需求,保证规定必要的软件安全功能和软件安全完整性。

  评测人员需要根据软件安全性分析准备的结果和系统的初步结构设计文档,包括系统分配的软件需求、接口需求,完成对系统安全性需求的映射,以安全相关性分析和对软件需求的安全性评价。有了这些积累,评测人员才有把握对软件在系统中的安全性需求作出一个综合性的评价,更好地提交对后续的软件设计和测试的建议。

  2. 软件结构设计安全性分析——评价结构设计的安全性,以保证软件安全功能的完整性

  从安全角度讲,软件结构设计是制定软件基本安全性策略的阶段,因为这一阶段负责定义主要软件部件,以及它们如何交互,如何获得所要求的属性,特别是安全完整性,是软件安全性需求在结构定义中实现的阶段。对结构设计进行安全性分析要做到将全部软件安全性需求综合到软件的体系结构设计中,确定结构中与安全性相关的部分,并评价结构设计的安全性。

  结构设计是开发人员对系统期望功能和功能实现方式的表示方法,但是沟通的一致性,和设计的合理性,通常会影响到安全完整性,这里可以借助一些技术来验证:用动画/仿真技术证实功能的实现状态;借助接口分析技术分析安全相关部件与其他部件的相互依赖关系和独立性。等等。

  3. 软件编程安全性分析——选择合适的编程语言

  所有编程语言无论在其定义还是在其实现中都有其不安全性。这通常汇号称程序员对语言的误用,而对这些误解,一些相对开放的语言又缺乏相应的解释。现举例如下:

  a) 未初始化的变量。除非进行特别的检查,否则单元测试不会发现他们。而这将导致,一个程序在不同的环境下虽然运行成功,但运行结果却不是期望值。

  b) 当要求重新分配存储器的调用时应予以检查,以确保不仅释放指针而且释放该结构所用的存储器。

  c) 运算符优先级的规则,一些语言的要求并不是那么严格,容易是程序员发生误解。

  如果某种语言有精确的定义(也有完备的功能性),从逻辑上说是清晰的,有易管理的规模和复杂度,那么就认为这个语言适用于安全相关性软件。使用编程语言时,也应该针对该语言的特点,努力满足安全性要求。

  如果一种编程经验或编程风格因为能够提高软件安全性而被公认为专用性编码标准,可以选择这样一种编码标准来约束对不安全语言的使用。编码标准对程序员的编程修养和对语言正确使用是有指导意义的。MISRA协会在1994年发布了它的软件开发指南,在其中特别指出了为考虑安全集成度而做出的语言、编译器和语言特性的选择。MISRA要求使用“标准化结构化语言的受限子集”,其对语言检查的严格性已经使该规范应用在一些安全要求很高的系统相关代码上。

软件安全性浅析
发布时间: 2008-9-11 18:07    作者: 未知    来源: 网络转载

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

  4. 软件详细设计安全性分析——设计实现是否符合安全性要求

  软件详细设计进一步细化高层的体系结构设计,将软件结构中的主要部件划分为能独立编码、编译和测试的软件单元,并进行软件单元的设计。

  在这一阶段中,需要依据软件需求、结构设计描述、软件集成测试计划和之前所获得的软件安全性分析的结果,对软件的设计和实现阶段是否符合软件安全性需求进行验证。

  相关软件单元应进一步细化设计以便于编码。所以,我们应该分析:

  a) 软件详细设计是否能追溯到软件需求;

  b) 软件详细设计是否已覆盖了软件安全性需求;

  c) 软件详细设计是否与软件结构设计保持了外部一致性;

  d) 软件详细设计是否满足模块化、可验性、易安全修改的要求。

  软件详细设计是直接关系到编码的关键一环,软件详细设计安全性分析更相关整个软件的安全性。所幸的是,众多前辈们总结了许多可以提高软件安全性的手段和技术,这些经验经过长期验证,多数已经成为标准的参考:

  设计逻辑分析:评价软件设计的方程式、算法和逻辑,可以包括失效检测/诊断、冗余管理、变量报警和禁止命名逻辑的检测。

  设计约束分析:给出一些约束,来评价软件在这些约束下运行的能力。比如:物理时间约束和响应时间对软件性能的检查。

  复杂性度量:高度复杂的数据结构难以彻底测试,可以采用McCabe或Halstead等这样一些复杂性评估技术来标示出需要进一步改进的区域。等等。

0
相关文章