软件系统安全系统测试管理系统要求规范.docx

软件系统安全系统测试管理系统要求规范.docx

《软件系统安全系统测试管理系统要求规范.docx》由会员分享，可在线阅读，更多相关《软件系统安全系统测试管理系统要求规范.docx（9页珍藏版）》请在冰豆网上搜索。

软件系统安全系统测试管理系统要求规范

软件

系统安全测试

管理规范

上海理想信息产业（集团）有限公司

2019年11月20日

版本历史

版本

提案人

批准人

日期

描述

1.0

甘XX

2017.6.16

初建

【目录】

1概述

1.1编写目的

建立和完善-系统安全测试管理制度。

规范软件系统安全测试各环节的要求、规范各岗位人员的工作职责、明确软件系统安全测试实施过程中的管理行为及文档要求。

以规范化的文档指导软件系统安全测试工作，提升管理效率、降低项目风险。

1.2适用范围

本规范适用于智能信息化系统建设项目软件安全测试管理过程。

1.3角色定义

角色简称

角色定义

备注

总集PM

总集方负责业务系统的项目经理

信息中心PM

信息中心负责业务系统的项目经理

信息中心主任

信息中心负责人

厂商接口人

软件厂商负责学校的负责人

安全测试人员

安全测试团队成员

1.4参考资料

参考文件

备注

2

项目背景

校园内信息化软件众多，这些软件不光承载着学校核心业务，同时还生成、处理、存储着学校的核心敏感信息：

账户、隐私、科研、薪资等，一旦软件的安全性不足，将可能造成业务中断、数据泄露等问题的出现。

希望通过规范软件系统安全测试管理，改善和提高学校软件安全测试水准，将学校软件系统可能发生的风险控制在可以接受的范围内，提高系统的安全性能。

3

软件系统安全测试流程

软件系统安全测试流程分为6个阶段：

1）测试准备：

确定测试对象、测试范围、测试相关人员权责；

2）测试方案：

按要求整理撰写《安全测试方案》，并完成方案审批；

3）测试计划：

测试方案通过后，协调确认各相关人员时间，形成测试计划；

4）实施测试：

按计划实施软件安全测试工作，输出《软件安全测试报告》；

5）回归测试：

问题修复，回归测试循环进行，直到没有新的问题出现；

6）测试总结：

测试过程总结，输出文档评审，相关文档归档。

其整体流程见流程图（下图）：

4

测试准备

4.1测试准备

明确本次安全测试的软件系统及其测试范围，并对涉及各方权责做出说明

4.1.1测试对象

软件系统名称，软件厂商信息、软件开发语言等

系统信息

开发商：

体系结构：

编程语言：

操作系统：

WEB服务器：

数据库：

4.1.2测试范围

软件内部程序、软件外部接口、数据库、网络服务器环境等

4.1.3工作权责

序号

涉及各方

权责说明

1

安全测试团队

1、 组织讨论、编写安全测试方案并通过评审

2、 测试人员分工安排

3、 搭建安全测试环境

4、 安全测试实施

2

图信

1、 参与讨论并确认测试方案

2、 进行程序开发或修改等集成相关的实施工作

3

总集

1、 协调安全测试团队

2、审核安全测试团队制定的安全测试方案

3、其他协调配合工作

4

系统厂商

1、 提供测试软件的相关信息

2、 其他协调配合工作

4.2测试方案

安全测试团队根据软件构成、软件环境以及图信安全需求编制《X软件系统安全测试方案》；

此方案要求图信PM、总集PM均审核通过；

若审核未通过，由安全测试团队根据反馈建议，针对未通过的业务内容进行修改或重新调研，完成后进行再提交审核。

软件系统安全测试方案至少要覆盖以下内容：

1）测试准备（对象、范围、分工）

2）测试分析（系统分析、威胁分析）

3）制作测试用例

4）实施测试方法

5）回归测试方法

4.2.1测试准备

明确本次安全测试的软件系统及其测试范围，并对涉及各方权责做出说明

4.2.2测试分析

测试分析主要是熟悉被测系统，通过系统的外部环境分析、物理架构分析和逻辑架构分析，了解系统特性，便于后续的威胁分析以及对应的用例编写。

4.2.2.1系统分析

系统分析包含外部环境分析、物理架构分析和逻辑架构分析的划分。

1）外部环境分析

对系统所在的外部环境，如操作系统、服务器、网络等进行分析

●服务器安全防护（系统补丁、漏洞、木马、外挂、开放端口）

●服务器用户及其权限管理，密码更新机制

●服务器备份机制

2）物理架构分析

按照系统物理架构分析其使用的组件，如底层使用何种数据库，控制层使用何种组件，表示层使用何种前端库等，组件之间使用那些通信协议等，了解系统特性。

数据存储层：

如MySQL、Oracle、Redis、Bigtable等；

控制层：

如spring、Struts2、Tomcat、Weblogic等；

表示层：

如ExtJS、Bootstrap等；

通信协议：

如AMQP等

3）逻辑架构分析

按照系统的业务逻辑划分业务，再根据各业务数据流从身份验证、加密、输入校验、敏感数据、配置管理、授权、异常管理、会话管理、参数操作、审核和日志记录、部署和基础结构等方面入手分析。

4.2.2.2威胁分析

系统分析后需要进行的就是威胁分析，根据系统分析的结果，选择合适的威胁模型，分析系统面临的主要安全威胁。

常用的威胁模型STRIDE，是基于数据流的一种威胁分析模型，它包含六个维度威胁：

威胁模型STRIDE一般应用在二层数据流图上，在外界操作与系统内部模块之间、系统模块与外界存储之间需要画立信任边界。

数据流图元素和STRIDE的对应关系如下：

对于每一种威胁，其对应的消减方式如下表：

4.2.3制作测试用例

系统分析和威胁分析后就需要根据分析结果编写测试用例。

外界环境和物理架构这边，主要是针对系统或组件特点，罗列用例内容；

逻辑架构这边是测试用例重点，分析软件系统数据流图，针对分解的每一个二层数据流图，对每一个数据流图元素，映射对应的威胁，编写测试用例，用例必须按照模板输出。

测试用例具体内容包括：

用例名称：

测试用例必须具有唯一可区分的名称；

用例执行步骤：

用例的详细执行步骤，每一步必须无歧义，具备可执行性；

用例使用的工具：

用例执行过程中使用的工具；

用例的执行条件：

用例执行必须具备的条件，如网络可达、服务必须运行等；

用例的输入和输出：

用例执行过程中涉及的输入，以及对应的输出；

用例的安全属性：

目前规定的安全属性包括管理通道安全、XSS、注入攻击、CSRF、身份认证、会话安全、敏感数据保护、越权、中间件安全、配置安全这10个维度；

用例执行优先级：

用例执行的优先顺序，在用例数量很多的情况下，应按照优先级高低的顺序执行。

4.2.4实施测试方法

测试用例编写完就需要开始用例的执行，具体的测试包括自动化的工具执行以及手动测试。

自动化的工具扫描包括：

Nmap端口扫描、系统漏洞扫描、web安全扫描、协议安全扫描等；

手动测试包括：

XSS、CSRF、SQL注入、XML注入、命令注入、横向/纵向越权、会话安全等等；

安全测试环境原则上使用软件系统测试环境，如必须在生产环境上进行，实施测试方法中必须包含《失败退回方案》，保护生产环境中的数据和应用；

对于每一个用例的测试过程，需要有对应的操作截图，测试执行完成后需要输出对应的《安全测试报告》。

4.2.5回归测试方法

《安全测试报告》中需要给出每个安全问题或漏洞的解决方案或建议。

如果可能，解决方案应当详细到源码级别。

回归测试的目的为了防止问题修复引入新的安全问题，问题修复&回归测试是个循环的过程，测试没有新的问题时循环即终止。

4.3测试计划

待《软件安全测试方案》总集审核、图信审核均通过后，由总集PM协调确认涉及各方的测试时间及地点安排，最终形成《软件安全测试计划》

《软件安全测试计划》主要包含以下内容：

1）测试对象

2）工作权责

3）具体测试分工及测试时间地点安排

4）附《软件安全测试方案》

4.4实施测试

安全实施团队按照《软件安全测试计划》实施测试，涉及各方现场或远程配合测试工作；

实施测试过程中，如多方存在问题或争议，由总集PM协调处理；

实施测试工作结束后，安全团队给出《软件安全测试报告》，说明本次安全测试过程中发现的问题或漏洞，并给出推荐处理意见。

4.5回归测试

待厂商完成《软件安全测试报告》中问题及漏洞的修复工作后，安全实施团队确认修复工作，并确认是否引入了新的问题；

问题修复&回归测试是个循环的过程，测试没有新的问题时循环即终止。

4.6测试总结

测试工作完成后，由安全测试团队总结本次测试过程中出现的问题，并针对这些问题给出改进建议。