安全管理阶段，软件项目系统安全设计和编码规范

1 概述

软件不安全的因素主要来源于两个方面，一是软件自身存在错误和缺陷引起的安全漏洞，二是来自外部的攻击。良好的软件开发过程管理可以很好地减少软件自身缺陷，并有效抵抗外部的攻击。

本规范主要规定了公司信息化应用系统在系统开发的各个阶段所应遵守的各种安全规范，将在不同阶段中所需要注意的安全问题和相关的安全规范进行进一步的描述和规定，以提高公司信息化应用系统的安全性和抵抗外部攻击的能力。

2 可行性计划

可行性计划是对项目所要解决的问题进行总体定义和描述，包括了解用户的要求及现实环境，从技术、经济和需求3个方面研究并论证项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如硬件、软件、人力等）成本，可取得的效益和开发进度作出估计，制订完成开发任务的实施计划。

2.1 阶段性成果

可行性研究报告重点如下4个方面：

2.1.1 设计方案

可行性研究报告的需对预先设计的方案进行论证，设计研究方案，明确研究对象。

2.1.2 内容真实

可行性研究报告涉及的内容以及反映情况的数据，必须绝对真实可靠，不许有任何偏差及失误。可行性研究报告中所运用资料、数据，都要经过反复核实，以确保内容的真实性。

2.1.3 预测准确

可行性研究是投资决策前的活动，对可能遇到的问题和结果的估计，具有预测性。因此，必须进行深入地调查研究，充分地占有资料，运用切合实际的预测方法，科学地预测未来前景。

2.1.4 论证严密

论证性是可行性研究报告的一个显著特点。要使其有论证性，必须做到运用系统的分析方法，围绕影响项目的各种因素进行全面、系统的分析，既要作宏观的分析，又要作微观的分析。

3 需求分析

软件需求分析就是对开发什么样的软件的一个系统的分析与设想，它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言表达出来的过程。需求分析阶段主要工作是完成需求对业务的表达，这体现在对需求规格说明书中考证书的正规网站，包括业务流程，子系统划分，状态图，数据流图等，最终通过用户用例完成业务分析测试。

需求分析阶段最大的隐患即需求未能准确地描述表达对用户需求的真正正确理解，因此，需求分析阶段的安全工作，应主要在对用户需求真正准确的理解上。

需求分析阶段需深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。

需求分析阶段需形成的文档包括《需求分析说明书》、《业务分析测试报告》、《用户使用手册初稿》。

需求分析可分为需求提出、需求描述及需求评审三个阶段。

3.1 需求提出

需求主要集中于描述系统目的。开发人员和用户确定一个问题领域，并定义一个描述该问题的系统，形成系统规格说明。

需求描述

在需求分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。

分析人员应发现并提出哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。

3.2 需求评审

在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。

需求评审内容需至少包含以下内容：

1. 需求分析进度日程实施计划

进行需求分析时，应注意一切信息与需求都是站在用户的角度上。要避免分析员的主观想象，并将分析进度提交给用户，以确保需求分析过程及时与用户沟通交流，让用户进行检查与评价，从而达到需求分析的准确性。

2. 描述软件的功能和性能

确定软件设计的限制和软件同其它系统元素的接口细节。

3. 需求评审的目的

通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件开发完成后，制定的需求分析说明书还要为评价软件质量提供依据。

3.3 需求分析的基本原则

1. 开发安全需求分析计划应由项目开发单位、信息化主管部门、业务主管部门共同商议决定。

2. 应用系统安全需求应能够达到业务所期望的安全水平。

3. 所有关于应用系统的业务更新或改进原则上都必须基于业务需求，并有业务事件支持。

4. 业务需求是系统更新和改动的基础，因此必须清晰明确地定义业务的需求，禁止在业务需求未经业务部门和主要负责人员认可的情况下，盲目地进行开发工作。

5. 系统的每一次更新或改进都必须重新对安全需求进行定义、分析和测试评估，以保证不会对业务造成影响。

6. 系统设计前，需建立开发安全需求分析报告，并通过信息化主管部门审核。

7. 应用系统开发需符合相关法律法规上的要求，符合相关的行业标准和管理制度。

4 系统设计

软件设计通常分为概要设计和详细设计两个阶段，主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，以及设计数据库。

系统的设计需达到一个从来没有接触过的人一看就能从各个方面都对系统的作用，功能，实现方面有一个大概了解，并为以后的各类详细设计文档提供一个指引和方向。

设计析阶段需形成的文档包括《概要设计说明书》、《详细设计说明书》。

设计阶段的主要安全工作包括：

4.1 功能划分

设计阶段的功能划分不合理，难以发现，且不好处理。因此功能模块设计需详细描述系统有那些主要功能，这些功能应该用何种技术，大致是如何实现的，以便发现问题。

4.2 模块协作

描述模块间如何协同运作的，以便发现问题。

4.3 系统定级

安全设计描述系统应该具有的安全级别，以及达到此安全等级的所采用的技术。

4.4 隐通道

本来受安全策略限制不能进行通信的实体，利用可执行的操作的副作用而实现通信。

4.5 认证不充分

只有分配有足够权限访问的操作进程才可以访问和操作相应的进程，攻击者同城会采取一些攻击获权限而执行一些非法操作，使得系统不可靠。在设计中，需加强访问孔子安全管理阶段，软件项目系统安全设计和编码规范，确保操作都经过相应的授权认证允许。

4.6 缓冲区溢出

缓冲区是分配的一段大小确定的内存空间，是内存中用来存放数据的地方。发生缓冲区溢出时，会覆盖相邻内存块，从而引发程序安全问题。因此在设计阶段，就需做好缓冲区溢出防范工作。

4.7 并发控制策略

并发作为一种提高计算机系统运行效率的重要手段，在得到广泛应用的同时，其机制本身容易引起以下问题

1) 竞争

2) 活锁

3) 死锁

设计阶段需考虑到并发带来的上述问题，并做处理。

4.8 错误

是一种利用公用可写文件，攻击者可以创建同名连接到其访问的文件，来达到非法访问的目的。因此，系统设计时，需有相应的防护策略。

4.9 数据库重要信息的保护

数据库中的重要信息需加密存储，并有相应的防控措施。

4.10 配置管理

对管理界面进行未经授权的访问、具有更新配置数据的能力以及对用户帐户和帐户配置文件进行未经授权的访问。

4.11 身份验证

口令长度不低于8位；口令至少需数字和字符串组合；口令需加密存储；口令验证通信信道需加密，以保护身份验证；使用强密码，支持密码有效期和帐户禁用。

4.12 访问控制

任何用户如果希望访问应用系统中的某一部分，则必须通过唯一的认证授权方式。

4.13 授权

使用最少超级管理帐户，每个系统不得多于2个；不得采用集中授权，凡是授权，均进行单独授权（初始化授权可批量，但初始化权限分配必须经过信息化主管部门审核）；限制用户访问最小权限资源。

4.14 收权

用户离职或其它原因不需再访问系统，需要及时有关系统的权限

4.15 敏感数据

对网络上传输的敏感数据进行加密；确保通信通道的安全；对敏感数据存储提供强访问控制。

4.16 管理

不要在 中永久性存储敏感数据；不要使用 HTTP-GET 协议传递敏感数据；不要通过 HTTP 连接传递身份验证 。在授权 内设置安全的 属性，以便指示浏览器只通过 连接向服务器传回 。

4.17 远程维护管理

在管理界面上使用身份验证后授权；远程管理时要确保通信通道的安全。

4.18 会话管理

限制会话时常，具体时长由业务系统决定，闲置会话原则上不超过15分钟。保护会话状态，以防止未经授权的访问。

4.19 加密

采用我国的算法或我国改造的算法。SM1-SM9算法，算法，祖冲之对称秘钥算法等，密钥最低不得低于32位，定期回收管理密钥。

4.20 异常管理

设计好异常处理机制。

4.21 审核和记录

在所有应用中审核和记录活动，确保日志文件访问的安全，定期备份日志文件。

4.22 后门预防控制

系统须有机制，防止恶意攻击绕过安全性控制而获取对系统资源访问和控制。

4.23 安全设计评审

应用系统设计方案需要由信息化主管部门进行组织安全评审。

4.24 确保日志管理机制健全

建立可根据情况自由设置的日志管理机制，日志记录的范围和详细程度可以根据需求自行定制，且可以实现在应用系统的使用过程中进行日志的定制和记录。保留所有与系统开发相关的程序库的更新审核记录。

日志信息不可删除和修改，日志信息需是自动记录，不允许存在手工参与情况。

4.25 审计安全规范

1. 应包括每个用户的安全审计功能安全管理阶段，对应用系统的重要安全事件进行审计。

2. 应保证无法单独中断审计进程，审计记录无法删除、修改或覆盖。

3. 审计内容应包含事件主要信息：日期、时间、操作人、类型、事件信息和结果等。

4. 应提供审计记录数据统计、查询。

4.26 数据及通信有效性管理规范

1. 应提供校验码技术，保证通信过程的数据完整性。

2. 应具有在请求的情况下为数据原发者或接收者提供数据原发和接收数据的功能。

3. 提供有效性验证功能，保证人机接口或通过通信接口输入的数据格式或长度符合系统设定要求。

4. 提供自动保护功能，当故障发生时自动保护当前状态，保证系统能够恢复。

5. 当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话。

6. 应能够对系统的最大并发会话连接数进行限制。

7. 应能够对单个帐户的多重并发会话进行限制。

8. 应能够对一个时间段内可能的并发会话连接数进行限制。

9. 应能够对一个访问帐户或一个请求进程占用的资源分配最大限额和最小限额。

10. 应能够对系统服务水平降低到预先规定的最小值进行检测和报警。

11. 应提供服务优先级设定功能，并在安装后根据安全策略设定访问帐户或请求进程的优先级，根据优先级分配系统资源。

5 软件编码

软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的“源程序清单”。

5.1 编码阶段的主要工作

1. 基于软件产品开发质量要求，充分了解开发语言、工具的特性和风格，选取合适的编程语言。

2. 编码。

3. 提供源程序清单。

5.2 编码阶段需要考虑的安全问题包括

1、内存安全的实现

编程过程中内存数据出现的常见安全问题，如缓冲区溢出、整数溢出、字符串格式化等。

2、线程/进程安全

如线程同步、线程死锁等

3、科学地处理异常

异常是程序设计中必须处理的，主要解决怎样处理异常能够保证系统的安全性。

4、输入输出的安全保障

如对输入的合法性检测。

5、权限控制的处理

系统中涉及授权和限制访问，需要有完善的权限控制机制。

6、数据的保护

数据篡改和抵赖的防护和检验

除了加密解密外，还需要对对信息来源的鉴别、对信息的完整和不可否认等功能进行保障。

7、代码的优化处理

所有的程序，都需经过代码优化，代码性能的好坏有时候不仅关系到系统的运行效率，也关系到系统的安全。

8、Web编程安全。

Web编程中安全问题多种多样，但至少应有应付跨站脚本、SQL注入、Web认证攻击、URL操作攻击等安全问题。

9、参数变量处理

如果需要设置变量，不能使用缺失的默认值，如需设置PATH为一个已知的值，而不能使用启动时的缺省值。

10、SQL规范

1) 系统须有完善的防止sql注入处理机制。

2) SQL 语句的参数应以变量形式传入。

11、页面请求处理应校验参数的长度

WEB 服务器在接受页面请求时，应校验参数的最大长度，截断超出最大长度的范围。

12、登录失败信息错误提示

WEB 服务器在接受用户登录请求时，不应区分登录失败的提示信息（如：用户名不存在、密码错误、密码已过期等），应采用统一的失败提示信息（如：错误的用户名或密码）。

13、错误提示信息规范

所有对用户显示的错误信息都不应暴露任何关于系统、网络或应用程序的敏感信息。如果需要的话，应使用包含编号的一般的错误信息，这种信息只有开发者或支持小组才能理解。

14、开源软件管理

1) 开源的产品、平台及实现的功能应符合项目的需求。

2) 开源需适用于产品，若无或不友好的，需进行开源产品使用的风险评估。

3) 开源软件的代码需整洁、注释完善。

4) 选取的开源产品的文档说明需齐全。

15、开发版本管理

1) 在应用系统开发过程中使用配置及版本管理工具管理开发过程中的权限控制、源代码和相关文档的版本控制、变更管理。

2) 保证开发、测试、正式运营环境的隔离，控制开发代码的安全传输。

3) 不能使用正式运营环境的数据作为测试数据，如必须使用，需要进行数据处理。

4) 应用系统软件版本审批。对应用系统的版本的升级，应确认当前的版本为最新的版本，旧的版本应进行归档，不得随意丢弃或删除。

16、应用系统版本升级计划

1) 制定相关的升级计划，确保将系统升级对业务的影响降至最低。

2) 应用系统软件版本升级后需进行测试，确认系统的各种安全特性。

3) 应使用软件加锁技术防止不同版本相互覆盖的情况。

4) 当版本变更时应在更新的版本中记录变更的详细描述。

5) 应提供版本的合并功能。

6) 版本的更改应只允许指定的人员进行操作。

7) 应记录所有的版本变更的日志，其中包括更改日期、更改前版本号、更改后版本号、更改人、审批人等信息。

17、开发日志管规范

1) 系统开发中的相关日志文件应根据开发周期定期审核。

2) 开发人员权限定期（3个月）审核一次。

18、外包的管理规范

应对外包开发进行管理，保证软件代码的准确性、控制恶意代码、逻辑炸弹等，可以采用代码抽查、签署合同等模式来实现。

19、开发环境安全管理规范

1) 软件开发环境由开发服务器、开发用户终端、网络控制域与端口、其他配套输入输出和存储设备构成；

2) 软件开发环境应与正式运营环境在物理上隔离；

3) 软件开发环境与测试环境在逻辑上分开；

4) 规定软件开发环境的配置标准和实际配置维护日志；

5) 软件开发环境避免无关软件和数据文件的安装复制，防止有害代码植入和传播；

20、其它

1) 应从正规的软件供应商那里购买相关的软件或程序或中间件。

2) 应检验和验证源程序和源代码。

3) 在系统正式投入使用之前应进行评估，如一些行业的标准认证评估。

4) 在系统正式投入使用后，应严格管理源代码的访问、升级和修改。

5) 应使用有资质的开发人员操作密钥系统。

6) 不得随便安装别人给的软件，特别是不得随便打开电子邮件中的附件，一些可执行文件必须先进行病毒及恶意代码的扫描。

6 测试

软件测试的目的是以较小的代价发现尽可能多的错误，软件测试的关键在于设计一套出色的测试用例（测试数据与功能和预期的输出结果组成了测试用例）。

普通的功能测试的主要目的是：

1) 确保软件不会去完成没有预先设计的功能

2) 确保软件能够完成预先设计的功能

安全测试的主要目的是：要抢在攻击者之前尽可能多地找到软件中的漏洞。以减少软件遭到攻击的可能性。

6.1 安全性测试至少至少应考虑的问题

1) 用户认证安全的测试要考虑问题

2) 明确区分系统中不同用户权限

3) 系统中会不会出现用户冲突

4) 系统会不会因用户的权限的改变造成混乱

5) 用户登陆密码是否是可见、可复制

6) 是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）

7) 用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

6.2 数据库安全考虑问题

1) 系统重要数据是否机密

2) 系统数据的完整性

3) 系统数据可管理性

4) 系统数据的独立性

5) 系统数据可备份和恢复能力

6.3 安全测试的内容案例和参考方法

1、输入验证测试，包括如下方面

1) 数据类型（字符串，整型，实数，等）

2) 允许的字符集的最小和最大的长度

3) 是否允许空输入

4) 参数是否是必须的

5) 重复是否允许

6) 数值范围

7) 特定的值（枚举型）

8) 特定的模式（正则表达式）

2、问题访问控制测试

主要用于需要验证用户身份以及权限的页面，复制该页面的url地址，关闭该页面以后，查看是否可以直接进入该复制好的地址

从一个页面链到另一个页面的间隙可以看到URL地址或直接输入该地址，可以看到自己没有权限的页面信息

3、会话管理测试

系统的某些功能不允许用户浏览，如果必须要一个用户列表，并对列表中和未有在列表中的用户进行权限测试。

4、跨站脚本（XSS）测试

攻击者使用跨站脚本来发送恶意代码给没有发觉的用户，窃取他机器上的任意资料。

测试参考方法：