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

软件系统安全测试管理
规范精编W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】
软件系统安全测试
管理规范
上海理想信息产业（集团）有限公司
2020年11月15日
版本历史
【目录】
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角色定义
校园内信息化软件众多，这些软件不光承载着学校核心业务，同时还生成、处理、存储着学校的核心敏感信息：账户、隐私、科研、薪资等，一旦软件的安全性不足，将可能造成业务中断、数据泄露等问题的出现。

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

3软件系统安全测试流程
软件系统安全测试流程分为6个阶段：
1）测试准备：确定测试对象、测试范围、测试相关人员权责；
2）测试方案：按要求整理撰写《安全测试方案》，并完成方案审批；
3）测试计划：测试方案通过后，协调确认各相关人员时间，形成测试计划；
4）实施测试：按计划实施软件安全测试工作，输出《软件安全测试报告》；
5）回归测试：问题修复，回归测试循环进行，直到没有新的问题出现；
6）测试总结：测试过程总结，输出文档评审，相关文档归档。

其整体流程见流程图（下图）：
4.1测试准备
明确本次安全测试的软件系统及其测试范围，并对涉及各方权责做出说明
4.1.1测试对象
软件系统名称，软件厂商信息、软件开发语言等
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测试总结
测试工作完成后，由安全测试团队总结本次测试过程中出现的问题，并针对这些问题给出改进建议。