论文部分内容阅读
【摘 要】 网络信息当前已经变为人们日常工作以及生活之中十分重要的载体，在为人们带来便利的之时，它的安全防护工作也面临着十分严重的挑战。本文主要简要论述了集成安全测试的软件设计方法。
【关键词】 集成安全;软件;设计方法
引言：
网络信息安全问题自Internet诞生之日起，就与之俱来。随着Internet在全世界的广泛应用和网络信息系统的迅猛发展，网络信息已经成为人们日常工作和生活的重要载体。网络信息系统给人们带来便利、大幅提升生产力的同时，也使得网络信息安全这一问题越来越严重。计算机黑客的入侵，网络病毒的泛滥、保密信息的泄露、网络事故等，不仅给单位和个人造成难以弥补的经济损失，而且破坏和扰乱了正常的社会经济秩序和人们的正常工作和生活秩序，严重的甚至威胁着国家政治、经济和军事安全、危及国家主权。因此，进行网络信息安全风险分析与对策研究十分重要。
1、集成测试的概念
1.1、集成测试的一般定义
集成测试主要建构软件体系结构的系统化技术，并且也是进行一些发现同接口有关的错误的测试。其的目标主要是使用通过单元测试的构件建立在设计之中描述程序的结构。
1.2、集成测试遵循的原则
集成测试遵循的原则主要包括：所有公共接口都要被测试到;关键模块应该进行充分的测试;集成测试应该依照特定的层次来进行;集成测试的策略选择应该综合考量到质量、成本以及进度之间的关系;集成测试应该较早开始，并且将总体设计作为基础;在模块同接口的划分之上，测试人员应该和开发人员来进行充分的沟通，如果接口需要修改之时，关系到相关接口必须应该进行第二次的测试;测试执行的结果应该按照具体的情况进行记录;集成测试应该依据集成测试计划以及方案来进行，不可以对其进行随意的测试;项目管理者应该确保测试用例。
1.3、集成测试的主要任务
集成测试作为重要的任务主要包括有：将各个模块之间进行连接，并且检查模块在调用之时，数据经过接口是否会丢失;将各个子功能之间及时组合起来，检查其是否可以实现预期要求的各种功能;一个模块的功能可否会对另外一个模块的功能产生不利的影响;全局数据结构出现问题的话，则将会被异常修改;单个模块的误差积累起来，其是否会被放大，如此的话就会到一种不能接受的程度。
2、集成安全测试的软件开发方法
开发人员在软件设计阶段就要时刻有安全观念，考虑软件安全需求，定义软件安全目标，了解网络常用攻击技术、方法及应对措施，对软件面临的安全威胁进行建模，编写满足安全目标的测试用例，引入安全模式进行软件架构设计并评审，及早发现安全问题。
2.1、需求分析
一般情况下，在软件需求分析阶段，软件设计人员最常见的一种错误就是只注重软件的业务需求，往往忽略了软件的安全需求。“安全的软件开发生命周期（SDL）”描绘了一种结构化的方法，用以贯彻和实现软件的安全开发。遵守SDL，安全问题可以在软件生命周期的早期得以评估和解决。
在软件需求分析阶段，除了功能、性能、操作等需求外，设计者还要考虑几个问题。
2.1.1、安全需求和原则
在需求分析阶段，设计者就必须考虑安全原则及规则，创建一份系统范围的规范，编写系统涉及到的安全需求。安全需求可能是明确的（包含在业务需求内），也可能是模糊的、含混的甚至是没有说明的。OW。SP（开放式Web应用程序安全计划组织）制定了一些安全标准和指南用以指导软件设计者遵循安全设计原则来开发软件。据此，设计者可以对软件的安全性做出概要说明，阐述软件在所设计的运行环境中面临的安全威胁有哪些。
2.1.2、安全目标
安全目标是指为使软件在所设计的运行环境中能够有效运行，防止、缓解外部攻击对系统可能造成的危害而采取的措施和必须达到的要求。安全目标的制定可以减少软件的“特性蔓延”，防止添加不必要的特性而导致软件脆弱性的出现。安全目标与需求相关。对于明确的安全需求。
2.1.3、威胁模型
威胁模型的基本观点是，如果不对系统所面临的威胁进行评估，以及采取措施降低威胁风险，那么就无法建立起安全的系统。威胁模型有助于设计者更好地理解所开发的系统，发现较高层次的设计问题，判断出系统最具风险的“安全关键点”，确定系统的风险区域和采取的技术手段。
2.1.4、安全策略
为了防止、缓解威胁模型所描述的系统威胁，必须制定系统的安全策略，采用必要的安全技术和手段。安全模式描述了在特定场景下重复发生的问题，并为这些问题提供了经过实践被证明是安全的通用解决方案。以安全模式为基础，分析威胁模型所发现的问题，制定安全策略，可以建立安全的、有效地系统解决方案，防止使用临时的、随意的系统解决方案。
2.2、软件设计
2.2.1、软件功能形式化分解
从业务需求的角度出发，软件被划分为多个功能，每个功能的实现都是由单个或多个组件（模块）来完成的。软件功能形式化分解的任务是确定软件中相对独立功能的边界或作用范围。一般来说，软件脆弱性的产生通常是由于对数据不正确的处理造成的，特别是当数据从不可信任区域进入可信任区域时。使用数据流图（DFD，D。t。FlowDi。gr。m）以数据为核心，对软件功能进行形式化分解，根据数据传递的方向和作用范围，设定可信任区域和不可信任区域之间的边界。
2.2.2、威胁建模
软件功能形式化分解把软件功能的内部实现分为可信任区域和不可信任区域。处于不可信任区域的组件（模块）是威胁建模的设定目标，注重分析其运行过程中可能面临的安全威胁有哪些。本文使用STRIDE安全模型进行分类：身份欺骗（Spoofingidentity）、篡改数据（T。mperingwithd。t。）、否认（Repudi。tion）、信息泄露（Inform。tiondisclosure）和拒绝服务（Deni。lofservice）。经分析，模块1的安全威胁主要有身份欺骗（S）、篡改数据（T）和否认（R）3类，模块2无安全威胁。因此，模块1是非可信任的，模块2是可信任的。通过威胁建模，实现软件某个独立功能的内部模块被分为可信模块和非可信模块。
2.2.3、非可信模块的安全测试
UML安全测试扩展标记了非可信模块的安全需求和安全测试用例。对于设计者来说，首先要依据业务需求设计非可信模块的概要类图，确定类与类之间的关系。其次，根据安全需求从安全模式库中检索符合要求的安全模式，在概要类图的上下文环境中选择合适的安全模式应用于模块的实现。再次，把实现安全模式和数据处理的类标记为安全关键类。
安全关键类是实现非可信模块功能、抵御网络攻击、缓解安全威胁的核心，具有十分重要的作用。传统的单元测试侧重于验证类提供的接口及其实现是否正确，缺少对类提供接口的安全测试。通过分解安全测试用例，将安全测试用例转化为对安全关键类的单元安全测试。
只有在安全关键类完成单元安全测试后，才能对非可信模块进行安全测试，验证所采用的安全模式是否可以真正防止或缓解威胁模型中描述的安全威胁。如果采用的安全模式无法通过安全验证，需要重新选择安全模式。
3、结语
集成测试既是一种测试类型也是一个测试阶段，因为集成定义为一组交互，因此组件之间的所有已定义的交互都需要测试，体系结构和设计可以提供系统内部的交互细节，但是测试一个系统与另一个系统之间的交互要求对这些系统一起工作的方式有深刻理解，此时的集成测试是一个阶段。由于集成测试的目标是模块之间的交互，这种测试就像白盒、黑盒及其它类型的测试一样，也有一套技术和方法，因此集成测试也被看作是一种测试类型。
参考文献：
[1]陈峰，李伟华，房鼎益，陈晓江.集成安全分析的模型驱动软件开发方法研究[J].计算机科学，2009，11：165-168.
[2]梁旭，李行善，高占宝.基于测试引擎的自动测试系统软件设计[J].电子测量与仪器学报，2006，05：11-16.
[3]臧运港，梁燕来，李超建.软件开发生命周期中的安全性测试[J].玉林师范学院学报，2008，05：141-144.
【关键词】 集成安全;软件;设计方法
引言：
网络信息安全问题自Internet诞生之日起，就与之俱来。随着Internet在全世界的广泛应用和网络信息系统的迅猛发展，网络信息已经成为人们日常工作和生活的重要载体。网络信息系统给人们带来便利、大幅提升生产力的同时，也使得网络信息安全这一问题越来越严重。计算机黑客的入侵，网络病毒的泛滥、保密信息的泄露、网络事故等，不仅给单位和个人造成难以弥补的经济损失，而且破坏和扰乱了正常的社会经济秩序和人们的正常工作和生活秩序，严重的甚至威胁着国家政治、经济和军事安全、危及国家主权。因此，进行网络信息安全风险分析与对策研究十分重要。
1、集成测试的概念
1.1、集成测试的一般定义
集成测试主要建构软件体系结构的系统化技术，并且也是进行一些发现同接口有关的错误的测试。其的目标主要是使用通过单元测试的构件建立在设计之中描述程序的结构。
1.2、集成测试遵循的原则
集成测试遵循的原则主要包括：所有公共接口都要被测试到;关键模块应该进行充分的测试;集成测试应该依照特定的层次来进行;集成测试的策略选择应该综合考量到质量、成本以及进度之间的关系;集成测试应该较早开始，并且将总体设计作为基础;在模块同接口的划分之上，测试人员应该和开发人员来进行充分的沟通，如果接口需要修改之时，关系到相关接口必须应该进行第二次的测试;测试执行的结果应该按照具体的情况进行记录;集成测试应该依据集成测试计划以及方案来进行，不可以对其进行随意的测试;项目管理者应该确保测试用例。
1.3、集成测试的主要任务
集成测试作为重要的任务主要包括有：将各个模块之间进行连接，并且检查模块在调用之时，数据经过接口是否会丢失;将各个子功能之间及时组合起来，检查其是否可以实现预期要求的各种功能;一个模块的功能可否会对另外一个模块的功能产生不利的影响;全局数据结构出现问题的话，则将会被异常修改;单个模块的误差积累起来，其是否会被放大，如此的话就会到一种不能接受的程度。
2、集成安全测试的软件开发方法
开发人员在软件设计阶段就要时刻有安全观念，考虑软件安全需求，定义软件安全目标，了解网络常用攻击技术、方法及应对措施，对软件面临的安全威胁进行建模，编写满足安全目标的测试用例，引入安全模式进行软件架构设计并评审，及早发现安全问题。
2.1、需求分析
一般情况下，在软件需求分析阶段，软件设计人员最常见的一种错误就是只注重软件的业务需求，往往忽略了软件的安全需求。“安全的软件开发生命周期（SDL）”描绘了一种结构化的方法，用以贯彻和实现软件的安全开发。遵守SDL，安全问题可以在软件生命周期的早期得以评估和解决。
在软件需求分析阶段，除了功能、性能、操作等需求外，设计者还要考虑几个问题。
2.1.1、安全需求和原则
在需求分析阶段，设计者就必须考虑安全原则及规则，创建一份系统范围的规范，编写系统涉及到的安全需求。安全需求可能是明确的（包含在业务需求内），也可能是模糊的、含混的甚至是没有说明的。OW。SP（开放式Web应用程序安全计划组织）制定了一些安全标准和指南用以指导软件设计者遵循安全设计原则来开发软件。据此，设计者可以对软件的安全性做出概要说明，阐述软件在所设计的运行环境中面临的安全威胁有哪些。
2.1.2、安全目标
安全目标是指为使软件在所设计的运行环境中能够有效运行，防止、缓解外部攻击对系统可能造成的危害而采取的措施和必须达到的要求。安全目标的制定可以减少软件的“特性蔓延”，防止添加不必要的特性而导致软件脆弱性的出现。安全目标与需求相关。对于明确的安全需求。
2.1.3、威胁模型
威胁模型的基本观点是，如果不对系统所面临的威胁进行评估，以及采取措施降低威胁风险，那么就无法建立起安全的系统。威胁模型有助于设计者更好地理解所开发的系统，发现较高层次的设计问题，判断出系统最具风险的“安全关键点”，确定系统的风险区域和采取的技术手段。
2.1.4、安全策略
为了防止、缓解威胁模型所描述的系统威胁，必须制定系统的安全策略，采用必要的安全技术和手段。安全模式描述了在特定场景下重复发生的问题，并为这些问题提供了经过实践被证明是安全的通用解决方案。以安全模式为基础，分析威胁模型所发现的问题，制定安全策略，可以建立安全的、有效地系统解决方案，防止使用临时的、随意的系统解决方案。
2.2、软件设计
2.2.1、软件功能形式化分解
从业务需求的角度出发，软件被划分为多个功能，每个功能的实现都是由单个或多个组件（模块）来完成的。软件功能形式化分解的任务是确定软件中相对独立功能的边界或作用范围。一般来说，软件脆弱性的产生通常是由于对数据不正确的处理造成的，特别是当数据从不可信任区域进入可信任区域时。使用数据流图（DFD，D。t。FlowDi。gr。m）以数据为核心，对软件功能进行形式化分解，根据数据传递的方向和作用范围，设定可信任区域和不可信任区域之间的边界。
2.2.2、威胁建模
软件功能形式化分解把软件功能的内部实现分为可信任区域和不可信任区域。处于不可信任区域的组件（模块）是威胁建模的设定目标，注重分析其运行过程中可能面临的安全威胁有哪些。本文使用STRIDE安全模型进行分类：身份欺骗（Spoofingidentity）、篡改数据（T。mperingwithd。t。）、否认（Repudi。tion）、信息泄露（Inform。tiondisclosure）和拒绝服务（Deni。lofservice）。经分析，模块1的安全威胁主要有身份欺骗（S）、篡改数据（T）和否认（R）3类，模块2无安全威胁。因此，模块1是非可信任的，模块2是可信任的。通过威胁建模，实现软件某个独立功能的内部模块被分为可信模块和非可信模块。
2.2.3、非可信模块的安全测试
UML安全测试扩展标记了非可信模块的安全需求和安全测试用例。对于设计者来说，首先要依据业务需求设计非可信模块的概要类图，确定类与类之间的关系。其次，根据安全需求从安全模式库中检索符合要求的安全模式，在概要类图的上下文环境中选择合适的安全模式应用于模块的实现。再次，把实现安全模式和数据处理的类标记为安全关键类。
安全关键类是实现非可信模块功能、抵御网络攻击、缓解安全威胁的核心，具有十分重要的作用。传统的单元测试侧重于验证类提供的接口及其实现是否正确，缺少对类提供接口的安全测试。通过分解安全测试用例，将安全测试用例转化为对安全关键类的单元安全测试。
只有在安全关键类完成单元安全测试后，才能对非可信模块进行安全测试，验证所采用的安全模式是否可以真正防止或缓解威胁模型中描述的安全威胁。如果采用的安全模式无法通过安全验证，需要重新选择安全模式。
3、结语
集成测试既是一种测试类型也是一个测试阶段，因为集成定义为一组交互，因此组件之间的所有已定义的交互都需要测试，体系结构和设计可以提供系统内部的交互细节，但是测试一个系统与另一个系统之间的交互要求对这些系统一起工作的方式有深刻理解，此时的集成测试是一个阶段。由于集成测试的目标是模块之间的交互，这种测试就像白盒、黑盒及其它类型的测试一样，也有一套技术和方法，因此集成测试也被看作是一种测试类型。
参考文献：
[1]陈峰，李伟华，房鼎益，陈晓江.集成安全分析的模型驱动软件开发方法研究[J].计算机科学，2009，11：165-168.
[2]梁旭，李行善，高占宝.基于测试引擎的自动测试系统软件设计[J].电子测量与仪器学报，2006，05：11-16.
[3]臧运港，梁燕来，李超建.软件开发生命周期中的安全性测试[J].玉林师范学院学报，2008，05：141-144.