项目应用系统开发安全管理规范Word下载.docx
- 文档编号:22476423
- 上传时间:2023-02-04
- 格式:DOCX
- 页数:35
- 大小:40.06KB
项目应用系统开发安全管理规范Word下载.docx
《项目应用系统开发安全管理规范Word下载.docx》由会员分享,可在线阅读,更多相关《项目应用系统开发安全管理规范Word下载.docx(35页珍藏版)》请在冰豆网上搜索。
3.2人员职责和权限的定义8
3.3确保敏感系统的安全性8
3.4确保访问层的安全性8
3.5确保日志管理机制健全8
3.6新系统的容量规划9
第4章系统开发阶段安全规范10
4.1系统开发语言10
4.1.1通用规范10
4.1.2Perli吾言11
4.1.3JaVai吾言13
4.1.4C/C++语言14
4.2系统开发安全相尖工具管理17
421工具一:
PSCan18
4.2.2工具二:
FlaWfinder18
4.3控制软件代码程序库19
43■!
管理运作程序库19
4.3.2管理源程序库19
4.4在软件开发过程变更管理20
4.5开发版本管理21
4.5.1控制程序清单21
4.5.2版本升级控制21
4.5.3版本变更控制22
4.6开发日志审核管理22
461开发日志定期审计22
462开发人员权限定期审计22
4.7防御后门代码或隐藏通道22
4.7.1后门代码和隐藏通道介绍22
4.7.2防御后门代码和隐藏通道的相尖办法23
第5章系统测试阶段安全规范24
5.1应用系统的安全性检测24
5.1.1设计详细的测试计划、测试范围、测试方法和测试工具24
5.1.2测试种类24
5.1.3在测试的过程中详细描述每个和测试方案相尖的测试步骤和测试数据26
5.2控制测试环境26
5.3为测试使用真实的数据26
5.4在软件转移至生产环境前进行测试27
5.5应用系统安全质量鉴定27
第6章系统培训及文档阶段安全规范28
6.1新系统的培训28
6.2撰写新系统和系统改进的文档28
第7章应用系统开发外包安全控制29
第8章附录30
8.1参考文献30
8.2本规范用词说明32
821为便于在执行本规范条文时区别对待,对要求严格程度不同的用词说明如下:
.•…32
应符合的规定”或应
822条文中指定应按其它有尖标准、规范执行时,写法为
32
要求(或规定)执行”
第1章概述
信息系统的许多的安全控制或其他安全性保证是通过系统的开发设计予以实现的。
因此如果在系统的开发设计阶段没有对系统的安全性给予充分的考虑,那么系统本身一定会存在许多先天不足,系统就会漏洞百出。
为确保应用系统的安全,在应用系统开发之前就应确认系统的安全需求,并以此作为开发设计的阶
段的基础。
本规范主要规定了在系统开发的各个阶段所应遵守的各种安全规范,从需求分析开始,到设计,再到开发和维护以及最后的文档等系统开发的各个阶段分别进行阐述,并将在不同阶段中所需要注意的安全问题和相尖的安全规范进行进一步的描述和规定。
1.1目标
保护应用系统开发过程的安全。
具体地说就是保护应用系统开发过程免受未经授权的访问和更改,保护系统开发中系统软件和信息的安全,确保开发项目顺利正确的实施并对开发环境进行严格的控制。
同时确保应用系统开发外包中的各项安全。
1∙2适用范围
本套规范适用的范围包括了整个应用系统开发过程中的安全。
包括了系统开发可行性和需求分析阶段的安全,系统设计阶段的安全,系统开发阶段的安全,系统测试阶段的安全,系统培训和文档阶段的安全以及系统开发外包的安全规范。
主要规定了应用系统开发过程的安全保密,软件的质量的要求,系统和业务需求的符合性,保证敏感信息的安全,系统本身的稳定性和兼容性问题。
1.3规范引用的文件或标准
下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是不注日期的引用文件,其最新版本适用于本标准。
GBl7859-1999计算机信息系统安全保护等级划分准则
GB/T9387-1995信息处理系统幵放系统互连基本参考模型
(ISO7498:
1989)
G/4/T391-2002计算机信息系统安全等级保护管理要求
∣SO∕IECTR13355信息技术安全管理指南
NIST信息安全系列一一美国国家标准技术院
英国国家信息安全标准BS7799
信息安全基础保护ITBaSeIinePrOteCtiOnManUal(Germany)
BearingPointCOnSUIting内部信息安全标准
RUSeCUre安全技术标准
信息系统安全专家丛书CertifiCateInformationSyStemSSeCUrityPrOfeSSi
Onal
1.4术语和定义
访问控制accessCOntrOl—种安全保证手段,即信息系统的资源只能由被授权实体按授权方式进行访问,防止对资源的未授权使用。
应用系统applicationSyStem
认证authenticationa.验证用户、设备和其他实体的身份;
b.验证数据的完整性。
授权authorization给予权利,包括信息资源访问权的授予。
可用性availability数据或资源的特性,被授权实体按要求能及时访问和使用数据或资源。
缓冲器溢出bufferOVerflOW指通过往程序的缓冲区写超出其长度的内容,造成缓冲区的溢出,从而破坏程序的堆栈,使程序转而执行其它指令,以达到攻击的目的。
保密性COnfidentiality数据所具有的特性,即表示数据所达到的未提供或未泄露给未授权的个人、过程或其他实体的程度。
隐藏通道COVertChannel可用来按照违反安全策略的方式传送!
数据的传输信道。
完整性integrity在防止非授权用户修改或使用资源和防止授权用户不正确地修改或使用资源的情况下,信息系统中的数据与在原文档中的相同,并未遭受偶然或恶意的修改或破坏时所具的性质。
敏感信息Sensitiveinformation由权威机构确定的必须受保护的信息,因为该信息的泄露、修改、破坏或丢失都会对人或事产生可预知的损害。
系统测试SyStemtesting用于确定系统的安全特征按设计要求实现的过程。
这一过程包括现场功能测试、渗透测试和验证。
后门代码trapdoor通常为测试或查找故障而设置的一种隐藏的软件或硬件机制,它能避开计算机安全。
而且它能在非常规时间点或无需常规检查的情况下进入程序。
特洛伊木马TrOjanhorse一种表面无害的程序,它包含恶性逻辑程序5导致未授权地收集、伪造或破坏数据,以此破坏计算机安全与完整性的进程。
验证VerifiCatiOn将某一活动、处理过程或产品与相应的要求或规范相比较。
例:
将某一规范与安全策略模型相比较,或者将目标代码与源代码相比
较。
压力测试于确定系统的薄弱环节,确定系统在非正常条件下能够迅速恢复到正常的运行状态的能力。
1∙5应用系统开发总体原则
应用系统的开发应遵循一系列的总体原则,以确保开发过程中的安全。
其中包括:
系统开发应从业务需求的角度出发,不得盲目追求系统的先进性而忽略了系统的实用性。
系统的开发是为了更好地满足业务上的需要,而不是技术上的
需要。
开发的方法和管理必须规范化、合理化、制度化,从而确保开发的质量和进度。
应保证开发的进度并按时完成。
确保开发工作及时、有效且高质量的完
成。
系统开发必须具有一定的前瞻性,符合主流系统的发展方向。
提高和加强开发人员的安全意识。
确保机密信息和尖键技术不会泄漏,特别是不可泄漏到竞争对手的手中,否则将会对公司的竞争力产生极大的影响。
应充分利用现有的资源。
第2章系统需求收集和分析阶段
2.1可行性研究分析
对于应用系统开发项目应进行一定的可行性分析,以保证只有在确认具备了相当的资源和条件,并且有能力满足业务上的需求的情况下才能开展开发工作。
切忌盲目开发,否则既浪费资源,又浪费时间。
可行性研究宜从技术、需求面、投入和影响四个方面进行考虑:
2.1.1技术可行f生分析
根据业务上提出的需求,从技术开发的角度分析现有的技术手段和技术能力是否能够实现业务上所要求的系统功能。
通常可从以下三个方面进行分析:
人员技术能力分析,指公司内的系统开发队伍或外包的第三方开发公司是否具有足够技术和管理能力来完成系统开发的任务。
计算机软件和硬件分析,指公司现有的软件和硬件的性能是否足够满足开发相应的系统的要求。
管理能力分析,指现有的技术开发管理制度和管理流程是否成熟且标准
化,是否满足系统开发的要求。
2.1.2需求可行性分析
系统的开发来源于业务上的需求,因此需要对该需求进行可行性分析,以判断需求是否明确,是否符合实际,是否在一定的时间范围内可以实现。
21.3投资可行性分析
根据业务需求和技术手段的分析,确认实现系统开发所需的投资,并确认投资的数额是否在可控制和可承受的范围内。
21.4影响可行性分析
所谓的影响是指社会影响,比如系统幵发是否符合法律法规上的要求,是否和相尖的管理制度或行业标准相抵触,是否符合人文或道德上的约束等。
2.2开发人员安全管理
221系统开发人员职责分配
在系统开发的过程中,应明确不同人员的身份和职责。
在系统开发过程中具体可分以下三种角色:
项目负责人员:
确保在整个系统开发的各个阶段都实施了相尖的安全措
施,同时在整个系统开发的过程中负责整个项目的开发安全管理。
系统开发人员:
根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求,同时满足系统质量上和进度上的要求。
系统审核人员:
对整个开发的过程进行审核和监督,确保开发的质量和开发的安全。
2.2.2开发人员授权
应根据该员工在整个幵发项目中所负责的开发内容授予其相应的权限和所应承担的责任。
幵发人员必须负责其开发内容的保密性,不得私自将幵发的相尖信息泄漏出去,即使对家人或开发团队中的其他开发人员也不得泄漏。
但开发人员有责任将开发的相尖信息告诉项目的负责人员或开发小组的负责人员。
以书面的方式将员工的权限和相应的责任提交给员工本人。
必须严格规定在为企业工作期间,所有和工作相尖的开发成果的所属权都归企业所有。
应根据员工权限和责任的大小确认是否需要签署相尖的保密协议。
应在日常工作中记录员工与开发相尖的日志信息。
员工一旦离职或调动岗位应立即收回或调整其相应的权限。
2.2.3开发人员必须训练开发安全代码的能力
在整个开发的过程中必须完整持续地进行代码错误处理所规定的流程。
错误问题报告应力求通俗易懂,不应在其中包含任何系统细节问题。
应对重要的敏感信息进行加密保护。
应使用一些相对复杂的加密和密钥生成机制。
应单独编写安全性设计说明概要
224分离系统开发和运作维护
管理层必须确保应用系统的开发和运作管理从组织人事和权限职责上分开。
信息技术人员可以现场修复或更改偶然或恶意的数据和软件问题。
测试代码中往往包含调试或者查错代码,大大增加了主机系统的性能负担。
开发人员不应具有很高的权限,否则将在系统运行中产生很大的风险。
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的验证)。
通过在客户端和服务器之间放置一个代理服务器,可以很容易绕过客户端验证。
有了代理服务器,攻击者可以在数据被客户端“验证”后修改数据(与“manJrvthamiddle"
攻击类似)。
在实际的校验中,输入校验首先定义一个有效(可接受)的字符集,然后检查每个数据的字符是否在有效范围内。
如果输入中包含无效的字符,应用程序应返回错误页面并说明输入中包含无效字符。
这样进行验证的原因是定义无效的字符集比较困难,并且一些不应有效的字符通常不会被指出。
边界检查(例如字符串的最大长度)应在字符有效性检查以前进行。
边界分析可以防止大多数缓冲区溢出漏洞。
从环境变量获得的数据也需要进行验证。
同时避免在环境变量中存放敏感数据(例如密码)。
某些UniX系统(例如FreeBSD包含PS命令,可以让用户看至[J任何当前进程的环境变量,这常常会暴露保密性信息。
4.1.1.2SQL语句
如果应用程序需要连接后端数据库,不得在代码中使用SQL语句。
使用程序以外的嵌入在代码中的SQL语句调用特别危险,难以防止攻击者使用输入域或者配置文件(由应用程序载入)来执行嵌入式的SQL攻击。
而输入验证有助于缓解这种风险。
4.1.1.3注释代码(Con)mentedCOde)
当应用程序在实际环境中开始应用时,应删除所有的注释代码。
注释代码是用来调试或者测试的,它们不是最终应用程序的一部分。
无论如何应在实际的环境中删除它们来避免意外的执行(一般注释标识被删除后就无法激活休眠的代码,但还是存在可能性的,所以应执行这项工作)。
4.bl.4错误消息
所有对用户显示的错误信息都不应暴露任何尖于系统、网络或应用程序的敏感信息。
如果可能的话,应使用包含编号的一般的错误信息,这种信息只有开发者和/或支持小组才能理解。
一般的错误信息的例子是“发生了错误(代码1234),请您与系统维护部门联系。
n
4.1.1.5统一资源定位(URL内容
对于Web应用,不要在URL上暴露任何重要信息,例如密码、服务器名称、IP地址或者文件系统路径(暴露了Web服务器的目录结构)。
这些信息可以在攻击时使用。
例如下面就是一个不安全的URL
http:
//www.xyzcompany.eom/index.cgi?
USername=IJSER&
password=PASSWORD&
file=/home/USER∕expenses.txt
4.1.1.6设置PATH变量
设置PATH为一个已知的值,而不仅仅是使用启动时的缺省值。
攻击者可以在攻击应用程序时使用PATH变量,例如试图执行一个任意的程序。
这些也可以应用于大多数其他的语言。
4.1.2Perl语言
多年以来,Perl已经成为用于系统管理和WebCGl开发的功能最强的编程语言之一(几乎可以使用Perl实现任何功能)。
但其扩展应用,即作为Internet上CGl的开发工具,使得它经常成为Web服务器上的攻击目标。
另外,大多数
CGl脚本有着比一般用户更高的权限,导致它更容易受攻击。
下面列举了一些开发者
(特别是CGl程序员)可以使用的主动的预防性的措施来增强Perl代码的整
体安全性(请注意:
这不是Web服务器CGI脚本安全性的指导原则)。
4.1.2.ITaint验证
Perl版本5.x包含一个叫做TaintCheCking的数据验证措施。
如果起用该功能,它就不允许通过用户输入(任何程序外的输入)来操纵其他的外部程序(例如通过管道将数据导入另一个程序执行))。
一般而言,程序员不能信任输入脚本和程序的数据(叫做Tainteel数据),因为无法保证它不会产生危害(有意或者无意的)。
TairIt验证可以通过在命令行参数加入“来开启。
例如可以Perl脚本的第一行这样加入“T:
#!
usr/bin∕perl5・T
Tainted数据包括命令行参数、环境变量和来自文件的数据。
引用tainted数
据的变量也成为tainted数据。
如果脚本试图通过不安全的方式来使用tainted数据会产生一个致命错误(对这种情况称为“不安全的依赖”(InSeCUredependency)或
者其他的说法)。
启用tainted验证在有些情况下会导致脚本停止运行,常常是由于Perl解释器要求所有脚本引用的外部程序的完全路径必须在PATH环境变
量中列出,同时PATH中包含的每个目录除了目录的所有者及相应的所有者用户组外无法修改。
Taint验证对于环境比较敏感,这就可能会导致大多数程序员不愿使用它,但是只要可能就应使用taint验证,特别是代码执行其他程序功能时
(例如在CGl脚本的情况下)。
4.1.2.2安全模块
如果不但输入数据不可信而且实际的代码也不可信会产生什么情况?
例如用户从网站上下载了一个ACtiVeX控件,而它实际是一个特洛伊木马(TrOjanhorse)。
这种情况下taint验证就不起作用。
安全模块让程序员可以在Perl脚本中将不同的代码模块与安全对象相联系。
每个安全对象对于运行的每块代码建立了一个限制的环境。
这与ChrOOt在一个进程中只能在整体目录结构的一个子目录中运行类似。
而Saft对象限制Perl代码只能在Perl包结构的某些特定包中运行。
如何使用安全模式超出了本文的范围,但程序员应在任何时候使用这一功能。
4.1.2.3警告参数(-w)
使用-W参数可以在Perl解释脚本时显示所有的警告信息。
警告可以对以下情况
产生:
只使用了一次的变量或者完全没有使用过的变量,未定义的文件句柄,
未尖闭的文件句柄,或将非数值变量传递到数据变量。
该功能不是针对安全处理的,但是有助于调试直接或者间接对安全有危害的错误。
一般推荐总是使用-W
参数。
可在taint验证时在第一行这样使用・w参数:
usr/bin∕perl5・Tw
4.1.3JaVa语言
自从1995年发布以来,Java成为简单或者复杂网络应用的有效编程语言。
它在设计时充分考虑了安全问题,因此它具有的限制特征有:
收集不再使用的内存碎片的垃圾收集器,严格的“sandbox”安全模型,以及在特定主机上限制应用程序的活动的安全管理器。
以下为使用中的相尖的规范:
4.1.3.1不应在标准输出上打印消息
在实际的Internet系统中避免使用SyStem.out.println()或者
SyStem.err.println()打印日志和错误消息,原因是当消息打印到标准输出时,无法
立即确定消息发生的地点,且有可能将敏感信息透露给攻击者。
4.1.3.2封装
JaVa中,如果没有使用访问标识符(accessmodifier(private、PrOteCted或
PUbIiC))来声明类、方法和属性,那么它的默认访问范围是包,并且同一包中的所有类都能访问它。
必须记住虽然包有封装功能,但它只有在每部
分加载到包的代码都由授权用户控制时才起作用。
恶意的用户可以加入他们自己的类,从而对于包中的所有类、方法和属性都有完全的访问权限。
JaVa的政策文件支持两种控制包访问权限的前缀。
accessClassInPaCkage
defineClassInPaCkage
所有标准库中的类都默认是可以公共访问的(除了由“suF开头的类)。
为
了保证一个包的安全性,必须修改${JAVAHOME}∕jre∕lib∕SeCUrity文件夹中的java.security文件。
该文件中的重要行是:
PaCkage.access=sUrL
虽然该方法有作用,但仍存在问题。
例如程序员在java.sec
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 应用 系统 开发 安全管理 规范