软件系统安全测试管理规范样本.doc

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

上海理想信息产业( 集团) 有限公司
2024年7月6日

版本历史

版本
提案人
批准人
日期
描述
1.0
甘XX

.6.16
初建

【目录】
1 概述 5
1.1 编写目的 5
1.2 适用范围 5
1.3 角色定义 5
1.4 参考资料 5
2 项目背景 6
3 软件系统安全测试流程 7
4 测试准备 9
4.1 测试准备 9
4.1.1 测试对象 9
4.1.2 测试范围 9
4.1.3 工作权责 9
4.2 测试方案 10
4.2.1 测试准备 10
4.2.2 测试分析 11
4.2.3 制作测试用例 12
4.2.4 实施测试方法 13
4.2.5 回归测试方法 14
4.3 测试计划 14
4.4 实施测试 15
4.5 回归测试 15
4.6 测试总结 15

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） 外部环境分析
对系统所在的外部环境, 如操作系统、 服务器、 网络等进行分析
l 服务器安全防护( 系统补丁、 漏洞、 木马、 外挂、 开放端口)
l 服务器用户及其权限管理, 密码更新机制
l 服务器备份机制
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 测试总结
测试工作完成后, 由安全测试团队总结本次测试过程中出现的问题, 并针对这些问题给出改进建议。