以下为《信息安全—系统开发管理规范》的无排版文字预览，完整格式请下载

下载前请仔细阅读文字预览以及下方图片预览。图片预览是什么样的，下载的文档就是什么样的。

版本：1.0

作者：中国联合***河北***

时间：2016年3月25日

文档修订记录

序号

时间

修改描述

修改者

审核者



1



创建文档结构





















































































































































































































第1章 概述 1

1.1 目标 1

1.2 适用范围 1

1.3 规范引用的文件或标准 1

1.4 术语和定义 2

1.5 应用系统开发总体原则 3

第2章 系统需求收集和分析阶段 3

2.1可行性研究分析 3

2.1.1技术可行性分析 3

2.1.2需求可行性分析 3

2.1.3投资可行性分析 4

2.1.4影响可行性分析 4

2.2开发人员安全管理 4

2.2.1系统开发人员职责分配 4

2.2.2开发人员授权 4

2.2.3开发人员必须训练开发安全代码的能力 4

2.2.4分离系统开发和运作维护 5

2.3建立系统开发安全需求分析报告 5

第3章 系统设计阶段的安全规范 5

3.1单点访问控制且无后门 5

3.2人员职责和权限的定义 5

3.3确保敏感系统的安全性 5

3.4确保访问层的安全性 6

3.5确保日志管理机制健全 6

3.6新系统的容量规划 6

第4章 系统开发阶段安全规范 6

4.1系统开发语言 6

4.1.1通用规范 6

4.2.2 Perl语言 7

4.2.3 Java语言 8

4.2.4 C/C++语言 9

4.3 系统开发安全相关工具管理 11

4.3.1 工具一：Pscan 11

4.3.2 工具二：Flawfinder 12

4.4 控制软件代码程序库 12

4.4.1 管理运作程序库 12

4.4.2 管理源程序库 13

4.5 在软件开发过程变更管理 13

4.6开发版本管理 14

4.6.1 控制程序清单 14

4.6.2 版本升级控制 14

4.6.3 版本变更控制 14

4.7开发日志审核管理 14

4.7.1开发日志定期审计 14

4.7.2开发人员权限定期审计 14

4.8防御后门代码或隐藏通道 15

4.8.1后门代码和隐藏通道介绍 15

4.8.2防御后门代码和隐藏通道的相关办法 15

第5章 系统测试阶段安全规范 15

5.1应用系统的安全性检测 16

5.1.1设计详细的测试计划、测试范围、测试方法和测试工具 16

5.1.2测试种类 16

5.1.3在测试的过程中详细描述每个和测试方案相关的测试步骤和测试数据 17

5.2控制测试环境 17

5.3为测试使用真实的数据 17

5.4在软件转移至生产环境前进行测试 18

5.5应用系统安全质量鉴定 18

第6章 系统培训及文档阶段安全规范 18

6.1新系统的培训 18

6.2撰写新系统和系统改进的文档 18

第7章 应用系统开发外包安全控制 19

第8章 附录 19

8.1参考文献 19

8.2本规范用词说明 20

8.2.1为便于在执行本规范条文时区别对待，对要求严格程度不同的用词说明如下： 21

8.2.2条文中指定应按其它有关标准、规范执行时，写法为“应符合……的规定”或“应按……要求（或规定）执行”。 21

第1章 概述

信息系统的许多的安全控制或其他安全性保证是通过系统的开发设计予以实现的。因此如果在系统的开发设计阶段没有对系统的安全性给予充分的考虑，那么系统本身一定会存在许多先天不足，系统就会漏洞百出。为确保应用系统的安全，在应用系统开发之前就应确认系统的安全需求，并以此作为开发设计的阶段的基础。

本规范主要规定了在系统开发的各个阶段所应遵守的各种安全规范，从需求分析开始，到设计，再到开发和维护以及最后的文档等系统开发的各个阶段分别进行阐述，并将在不同阶段中所需要注意的安全问题和相关的安全规范进行进一步的描述和规定。

目标

保护应用系统开发过程的安全。具体地说就是保护应用系统开发过程免受未经授权的访问和更改，保护系统开发中系统软件和信息的安全，确保开发项目顺利正确的实施并对开发环境进行严格的控制。同时确保应用系统开发外包中的各项安全。

适用范围

本套规范适用的范围包括了整个应用系统开发过程中的安全。包括了系统开发可行性和需求分析阶段的安全，系统设计阶段的安全，系统开发阶段的安全，系统测试阶段的安全，系统培训和文档阶段的安全以及系统开发外包的安全规范。

主要规定了应用系统开发过程的安全保密，软件的质量的要求，系统和业务需求的符合性，保证敏感信息的安全，系统本身的稳定性和兼容性问题。

规范引用的文件或标准

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是不注日期的引用文件，其最新版本适用于本标准。

GB17859-1999 计算机信息系统安全保护等级划分准则

GB/T 9387-1995 信息处理系统 开放系统互连基本参考模型（ISO7498 :1989）

GA/T 391-2002 计算机信息系统安全等级保护管理要求

ISO/IEC TR 13355 信息技术安全管理指南

NIST信息安全系列——美国国家标准技术院

英国国家信息安全标准BS7799

信息安全基础保护IT Baseline Protection Manual (Germany)

BearingPoint Consulting 内部信息安全标准

RU Secure安全技术标准

信息系统安全专家丛书Certificate Information Systems Security Professional

术语和定义

访问控制access control 一种安全保证手段，即信息系统的资源只能由被授权实体按授权方式进行访问，防止对资源的未授权使用。

应用系统 application system

认证 authentication a. 验证用户、设备和其他实体的身份； b. 验证数据的完整性。

授权authorization 给予权利，包括信息资源访问权的授予。

可用性availability 数据或资源的特性，被授权实体按要求能及时访问和使用数据或资源。

缓冲器溢出 buffer overflow指通过往程序的缓冲区写超出其长度的内容，造成缓冲区的溢出，从而破坏程序的堆栈，使程序转而执行其它指令，以达到攻击的目的。

保密性confidentiality 数据所具有的特性，即表示数据所达到的未提供或未泄露给未授权的个人、过程或其他实体的程度。

隐藏通道 covert channel 可用来按照违反安全策略的方式传送!数据的传输信道。

完整性integrity在防止非授权用户修改或使用资源和防止授权用户不正确地修改或使用资源的情况下,信息系统中的数据与在原文档中的相同，并未遭受偶然或恶意的修改或破坏时所具的性质。

敏感信息 sensitive information 由权威机构确定的必须受保护的信息，因为该信息的泄露、修改、破坏或丢失都会对人或事产生可预知的损害。

系统测试 system testing用于确定系统的安全特征按设计要求实现的过程。这一过程包括现场功能测试、渗透测试和验证。

后门代码 trapdoor 通常为测试或查找故障而设置的一种隐藏的软件或硬件机制，它能避开计算机安全。而且它能在非常规时间点或无需常规检查的情况下进入程序。

特洛伊木马Trojan horse 一种表面无害的程序，它包含恶性逻辑程序，导致未授权地收集、伪造或破坏数据，以此破坏计算机安全与完整性的进程。

验证 verification 将某一活动、处理过程或产品与相应的要求或规范相比较。

例：将某一规范与安全策略模型相比较，或者将目标代码与源代码相比较。

压力测试 于确定系统的薄弱环节，确定系统在非正常条件下能够迅速恢复到正常的运行状态的能力。

应用系统开发总体原则

应用系统的开发应遵循一系列的总体原则，以确保开发过程中的安全。其中包括：

系统开发应从业务需求的角度出发，不得盲目追求系统的先进性而忽略了系统的实用性。系统的开发是为了更好地满足业务上的需要，而不是技术上的需要。

开发的方法和管理必须规范化、合理化、制度化，从而确保开发的质量和进度。

应保证开发的进度并按时完成。确保开发工作及时、有效且高质量的完成。

系统开发必须具有一定的前瞻性，符合主流系统的发展方向。

提高和加强开发人员的安全意识。确保机密信息和关键技术不会泄漏，特别是不可泄漏到竞争对手的手中，否则将***的竞争力产生极大的影响。

应充分利用现有的资源。

第2章 系统需求收集和分析阶段

2.1可行性研究分析

对于应用系统开发项目应进行一定的可行性分析，以保证只有在确认具备了相当的资源和条件，并且有能力满足业务上的需求的情况下才能开展开发工作。切忌盲目开发，否则既浪费资源，又浪费时间。

可行性研究宜从技术、需求面、投入和影响四个方面进行考虑：

2.1.1技术可行性分析

根据业务上提出的需求，从技术开发的角度分析现有的技术手段和技术能力是否能够实现业务上所要求的系统功能。通常可从以下三个方面进行分析：

人员技术能力分析，指公司内的系统开发队伍或外包的第三方***是否具有足够技术和管理能力来完成系统开发的任务。

计算机软件和硬件分析，指公司现有的软件和硬件的性能是否足够满足开发相应的系统的要求。

管理能力分析，指现有的技术开发管理制度和管理流程是否成熟且标准化，是否满足系统开发的要求。

2.1.2需求可行性分析

系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需求是否明确，是否符合实际，是否在一定的时间范围内可以实现。

2.1.3投资可行性分析

根据业务需求和技术手段的分析，确认实现系统开发所需的投资，并确认投资的数额是否在可控制和可承受的范围内。

2.1.4影响可行性分析

所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否和相关的管理制度或行业标准相抵触，是否符合人文或道德上的约束等。

2.2开发人员安全管理

2.2.1系统开发人员职责分配

在系统开发的过程中，应明确不同人员的身份和职责。在系统开发过程中具体可分以下三种角色：

项目负责人员：确保在整个系统开发的各个阶段都实施了相关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。

系统开发人员：根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求，同时满足系统质量上和进度上的要求。

系统审核人员：对整个开发的过程进行审核和监督，确保开发的质量和开发的安全。

2.2.2开发人员授权

应根据该员工在整个开发项目中所负责的开发内容授予其相应的权限和所应承担的责任。

开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄漏出去，即使对家人或开发团队中的其他开发人员也不得泄漏。但开发人员有责任将开发的相关信息告诉项目的负责人员或开发小组的负责人员。

以书面的方式将员工的权限和相应的责任提交给员工本人。必须严格规定在为企业工作期间，所有和工作相关的开发成果的所属权都归企业所有。

应根据员工权限和责任的大小确认是否需要签署相关的保密协议。

应在日常工作中记录员工与开发相关的日志信息。

员工一旦离职或调动岗位应立即收回或调整其相应的权限。

2.2.3开发人员必须训练开发安全代码的能力

在整个开发的过程中必须完整持续地进行代码错误处理所规定的流程。

错误问题报告应力求通俗易懂，不应在其中包含任何系统细节问题。

应对重要的敏感信息进行加密保护。

应使用一些相对复杂的加密和密钥生成机制。

应单独编写安全性设计说明概要

2.2.4分离系统开发和运作维护

管理层必须确保应用系统的开发和运作管理从组织人事和权限职责上分开。

信息技术人员可以现场修复或更改偶然或恶意的数据和软件问题。

测试代码中往往包含调试或者查错代码，大大增加了主机系统的性能负担。

开发人员不应具有很高的权限，否则将在系统运行中产生很大的风险。

2.3建立系统开发安全需求分析报告

安全需求计划应能够达到期望的安全水平。其中包括了成本的预估，完成各个安全相关流程所需的时间。

所有关于应用系统的更新或改进都必须基于业务需求，并有业务事件支持。这里的业务需求不仅仅包括了系统的功能、性能、开发费用、开发周期等内容，应明确系统的安全要求。应用系统的任何一次改进或更新都应和该业务系统的所有者密切相关。

开发安全需求分析计划应由开发项目经***内部的安全小组共同商议决定。

应确保每一个应用系统的用户都意识到系统的更新或改进都与其自身密切相关，所有的更新或改动建议都必须基于业务需求，而不是基于所谓的“信息技术的要求”。

系统的每一次更新或改进都必须认真对待，必须进行详细的需求定义、需求分析以及测试评估，以保证不会对业务造成任何不良影响。

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

第3章 系统设计阶段的安全规范

3.1单点访问控制且无后门

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

3.2人员职责和权限的定义

由于不是所有的人员对于某一个应用系统都具有同样的访问或使用权限，因此系统必须具有基于人员职责的用户授权管理，以确保每个用户可以访问到其权限范围内的应用系统部分。同时应确保每个用户无法访问其权限范围以外的应用系统部分。

3.3确保敏感系统的安全性

将应用系统中敏感的信息保存在服务器端以进行集中的加密的安全管理，确保客户端系统本身并不能存储任何敏感的数据。

3.4确保访问层的安全性

应用系统不仅仅要确保系统模块本身的安全性，同时还应考虑模块与模块之间通讯的安全性。这种模块与模块之间通讯的安全性不仅仅包括了应用系统内部模块之间通讯的安全，也包括了应用系统内部模块和外部模块之间的通讯安全性，如主机和客户端之间通讯的安全性、服务器和服务器间通讯的安全性，以及本地系统和异地系统之间通讯的安全性。

3.5确保日志管理机制健全

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

3.6新系统的容量规划

容量规划是指确定系统的总体规模、性能和系统弹性。容量规划的具体内容可能有所不同，但一般应考虑以下方面：

系统的预期存储容量和在给定的周期中获取生成和存储的数据量。

在线进程的数量和估计可能的占用资料

系统和网络的响应时间和性能，即端对端系统

系统弹性要求和设计使用率（峰值，槽值和平均值等）

安全措施如加密解密数据对系统的影响。

24x7运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须性宕机）

规划容量的时候关于系统使用的信息了解的越多越好。近来，由于互联网站的使用以指数形式增长，容量规划的变动效果不是非常显著，有时甚至毫无用处。原因在于很难估计实际的负载。在容量估计的时候应尽量将情况设想得复杂一些。

第4章 系统开发阶段安全规范

4.1系统开发语言

程序员可使用很多指导规范来防止应用程序中的普通安全问题。其中许多可以应用于任何一种编程语言，但某些是针对特定的语言的。特定语言的指导规范主要集中在Perl，Java和C/C++语言。大多数情况下，一般的错误可以避免。而这些本可以避免的错误常常会导致很多安全漏洞，从而威胁信息的保密性、完整性和可用性。

4.1.1通用规范

4.1.1.1输入验证

在客户机/服务器环境下，进行服务端的验证而不是客户端的验证（例如基于Javascript的验证）。通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。有了代理服务器，攻击者可以在数据被客户端“验证”后修改数据（与“man-in-the-middle”攻击类似）。

在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。如果输入中包含无效的字符，应用程序应返回错误页面并说明输入中包含无效字符。这样进行验证的原因是定义无效的字符集比较困难，并且一些不应有效的字符通常不会被指出。

边界检查（例如字符串的最大长度）应在字符有效性检查以前进行。边界分析可以防止大多数缓冲区溢出漏洞。

从环境变量获得的数据也需要进行验证。同时避免在环境变量中存放敏感数据（例如密码）。某些Unix系统（例如FreeBSD）包含ps命令，可以让用户看到任何当前进程的环境变量，这常常会暴露保密性信息。

4.1.1.2 SQL语句

如果应用程序需要连接后端数据库，不得在代码中使用SQL语句。使用程序以外的嵌入在代码中的SQL语句调用特别危险，难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的SQL攻击。而输入验证有助于缓解这种风险。

4.1.1.3 注释代码(commented code)

当应用程序在实际环境中开始应用时，应删除所有的注释代码。注释代码是用来调试或者测试的，它们不是最终应用程序的一部分。无论如何应在实际的环境中删除它们来避免意外的执行（一般注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，所以应执行这项工作）。

4.1.1.4 错误消息

所有对用户显示的错误信息都不应暴露任何关于系统、网络或应用程序的敏感信息。如果可能的话，应使用包含编号的一般的错误信息，这种信息只有开发者和/或支持小组才能理解。一般的错误信息的例子是“发生了错误（代码1234），请您与系统维护部门联系。”

4.1.1.5 统一资源定位（URL）内容

对于web应用，不要在URL上暴露任何重要信息，例如密码、服务器名称、IP地址或者文件系统路径（暴露了web服务器的目录结构）。这些信息可以在攻击时使用。例如下面就是一个不安全的URL：

http://doc.001pp.company.com/index.cgi?username=USER&password=

PASSWORD&file=/home/USER/expenses.txt

4.1.1.6 设置PATH变量

设置PATH为一个已知的值，而不仅仅是使用启动时的缺省值。攻击者可以在攻击应用程序时使用PATH变量，例如试图执行一个任意的程序。这些也可以应用于大多数其他的语言。

4.2.2 Perl语言

多年以来，Perl已经成为用于系统管理和Web CGI开发的功能最强的编程语言之一（几乎可以使用Perl实现任何功能）。但其扩展应用，即作为Internet上CGI的开发工具，使得它经常成为web服务器上的攻击目标。另外，大多数CGI脚本有着比一般用户更高的权限，导致它更容易受攻击。下面列举了一些开发者（特别是CGI程序员）可以使用的主动的预防性的措施来增强Perl代码的整体安全性（请注意：这不是web服务器CGI脚本安全性的指导原则）。

4.2.2.1 Taint验证

Perl版本5. 内容过长，仅展示头部和尾部部分文字预览，全文请查看图片预览。 teria ("ITSEC") (UK)

System Security Engineering Capability Maturity Model (SSE-CMM)

Development

ISO 11131 ("Banking and Related Financial Services; Sign-on Authentication")

ISO 13569 ("Banking and Related Financial Services -- Information Security Guidelines")

8.2本规范用词说明

8.2.1为便于在执行本规范条文时区别对待，对要求严格程度不同的用词说明如下：

表示很严格，非这样做不可的：

正面词采用“必须”；

反面词采用“严禁”；

表示严格，在正常情况下均应这样做的：

正面词采用“应”；

反面词采用“不应”或“不得”。

表示允许稍有选择，在条件许可时首先应这样做的：

正面词采用“宜”或“可”；反面词采用“不宜”。

8.2.2条文中指定应按其它有关标准、规范执行时，写法为“应符合……的规定”或“应按……要求（或规定）执行”。

[文章尾部最后500字内容到此结束,中间部分内容请查看底下的图片预览]该文档为免费文档，内容和预览一致，预览是什么样的内容就是什么样的。

以上为《信息安全—系统开发管理规范》的无排版文字预览，完整格式请下载

下载前请仔细阅读上面文字预览以及下方图片预览。图片预览是什么样的，下载的文档就是什么样的。