软件开发安全管理办法.docx

上传人:聆听****声音 文档编号:738317 上传时间:2023-04-29 格式:DOCX 页数:18 大小:37.31KB
下载 相关 举报
软件开发安全管理办法.docx_第1页
第1页 / 共18页
软件开发安全管理办法.docx_第2页
第2页 / 共18页
软件开发安全管理办法.docx_第3页
第3页 / 共18页
软件开发安全管理办法.docx_第4页
第4页 / 共18页
软件开发安全管理办法.docx_第5页
第5页 / 共18页
软件开发安全管理办法.docx_第6页
第6页 / 共18页
软件开发安全管理办法.docx_第7页
第7页 / 共18页
软件开发安全管理办法.docx_第8页
第8页 / 共18页
软件开发安全管理办法.docx_第9页
第9页 / 共18页
软件开发安全管理办法.docx_第10页
第10页 / 共18页
软件开发安全管理办法.docx_第11页
第11页 / 共18页
软件开发安全管理办法.docx_第12页
第12页 / 共18页
软件开发安全管理办法.docx_第13页
第13页 / 共18页
软件开发安全管理办法.docx_第14页
第14页 / 共18页
软件开发安全管理办法.docx_第15页
第15页 / 共18页
软件开发安全管理办法.docx_第16页
第16页 / 共18页
软件开发安全管理办法.docx_第17页
第17页 / 共18页
软件开发安全管理办法.docx_第18页
第18页 / 共18页
亲,该文档总共18页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

软件开发安全管理办法.docx

《软件开发安全管理办法.docx》由会员分享,可在线阅读,更多相关《软件开发安全管理办法.docx(18页珍藏版)》请在冰点文库上搜索。

软件开发安全管理办法.docx

鄂尔多斯电业局企业规章制度

OEP-IRM.2-103-2011

软件开发安全管理办法

2011-5-27发布 2011-6-1实施

鄂尔多斯电业局 发布

18

软件开发安全管理办法

第一章 总则

第一条目的

为了提高鄂尔多斯电业局软件开发安全管理水平,特制定本管理办法。

第二条适用范围

本管理办法适用于应用系统软件开发从计划、需求、设计、开发、测试、部署过程中的安全管理。

第三条规范性引用文件

内蒙古电力(集团)有限责任公司软件开发安全管理规定(内电生[2009]24号)

第四条术语和定义

(一)CMM认证

CMM是能力成熟度模型的缩写,是一种用于评价软件承包能力并帮助其改善软件质量的方法,侧重于软件开发过程的管理及工程能力的提高与评估。

CMM分为五个等级:

一级为初始级,二级为可重复级,三级为已定义级,四级为已管理级,五级为优化级。

第五条职责

(一)生产技术处的职责如下:

1. 归口负责软件开发安全管理工作的监督、检查和考核;

第二章 开发环境安全

第六条开发环境应设置独立的工作区域,并根据应用系统的开发要求,对该区域进行网络访问控制和物理访问控制,确保开发数据的安全性。

第七条项目文档、代码的存储应进行备份,以确保在发生意外时,可有效恢复。

第八条在开发环境中,应提供对项目文档和代码版本管理和访问控制。

第九条用于开发的服务器、个人电脑必须做好严格的安全防护措施,包括但不仅限于更新系统补丁、安装防病毒软件(防火墙)、设置密码策略。

第三章 文档安全

第十条应用系统开发过程的各阶段都应有开发文档的输出。

第十一条 对文档的安全性方面的内容给予规定。

内容包括对于文档内容的安全和文档自身的安全:

(一)文档内容的安全:

1.开发各阶段输出的文档应对安全性方面的内容进行描述。

2.需求说明书中应明确描述应用系统的安全需求。

3.设计说明书中应有针对安全需求的设计,并进行评审。

4.在测试大纲或者测试方案中应有安全性测试方案,并以此进行安全性测试。

(二)文档自身的安全:

1.文档应设定密级及读者范围,以限定其访问范围。

2.文档的访问控制应有相应的授权机制。

3.文档应有专用的服务器或文件柜进行保存和备份,对于电子文档应有版本控制。

第四章 源代码管理

第十二条当应用系统为第三方开发时,根据协议执行源代码的管理。

第十三条建立专门的源代码管理服务器,用于对程序源代码实施有效管理。

第十四条源代码管理应保存所有的历史版本,以便查阅。

第十五条在开发完成并通过测试后,开发人员必须提出源代码归档申请,并将所有的程序源代码以及设置等支持文件打包,交付档案室,代码在提交前必须通过安全检查。

通过检查后的源代码由档案室进行信息的登记并将源代码上传到管理服务器。

第十六条 对于已有系统(或功能、模块等)的代码文件或设置文件,在需要对其进行修改时,

必须由修改人提出源代码修改申请,并且经过生产技术处批准后,档案室才能将源代码(或设置文件)提取出来,交给修改人进行修改。

修改完毕需通过安全检查才可以提交,防止代码中存在隐蔽通道和木马。

通过检查后的源代码(或设置文件)交还档案室,由其上传到源代码管理服务器。

重新上传后,必须给予新的版本号。

第十七条 定期(每年)对源代码的修改记录进行审计,对所有修改记录进行抽查,检查是否存在未经审批的源代码修改情况以及源代码修改内容是否与申请内容相符。

第五章 需求阶段

第十八条需求阶段是整个应用生命周期的起始点,这个阶段决定了整个应用系统的安全目标和实现方法。

应在需求阶段确定安全功能,对软件需求的安全程度进行识别和区分,对各需求项的安全性进行描述,以便在软件需求中生成各阶段的安全措施。

第十九条 讨论确定的所有安全需求,形成项目安全保障文件,该文件将用于整个项目的设计、实现、测试环节,并保证主要开发人员持有该文件。

第二十条在需求分析阶段应明确以下与安全相关的需求:

(一)用户数、终端数、在线并发数;

(二)用户角色的划分和权限的分配;

(三)应用系统性能要求;

(四)现有网络现状和网络性能要求;

(五)数据量估计、数据存储方式和周期;

(六)系统安全级别和数据保密性要求;

(七)其他对网络、存储、服务器、终端、操作系统、数据库、数据等方面的安全需求。

第二十一条在需求阶段应确定应用系统安全功能需求:

(一)应用系统应包含认证功能,应明确提出用户身份认证体系的强度以及认证失败后的处理方式。

(二)应用系统应包含用户权限的分配和管理功能,应根据系统处理的业务数据的保密性和完整性要求,确定系统采用的用户权限访问控制模型和权限的划分,避免权限的过分集中与分散。

(三)应用系统应包括数据安全和冗余恢复相关功能。

(四)应用系统应包括安全审计功能,应明确对于日志内容的要求,包括但不限于以下内容:

1.应用系统审计的事件应包括:

(1)审计功能的启动和关闭;

(2)变更审计功能的配置信息;

(3)至少应进行审计的事件:

a.进入和退出的时间(登录、退出系统);

b.异常的系统使用行为(登录失败);

c.系统维护行为;

d.敏感的操作行为;

e.其它安全功能要求的审计内容。

(4)每个审计记录中应至少记录如下信息:

a.事件的日期和时间;

b.事件的类型;

c.主题标识;

d.事件的结果(成功、失败)和事件相关信息。

2.应用系统应支持数据查阅、审计等功能

(1)按照主题、事件查阅;

(2)应用系统应控制用户查阅审计数据的权限;

(3)在意外情况(数据丢失、损坏等)出现时,应有措施保证审计数据的可用性及当审计记录溢出时的应急措施。

第二十二条 在需求阶段确定以下应用系统数据的需求:

(一)定义系统中的敏感数据,为这些敏感数据的安全级别进行划定。

(二)定义应用系统的数据的机密性、完整性和可用性要求,根据这个要求检查运行的基础环境

(网络、主机等)是否符合。

(三)规划并划分数据的使用者,明确使用者(权限)的层次和类别,对权限的颗粒度进行划定

(单个用户权限模式还是组用户权限模式等),最终形成权限部署视图。

(四)设计应用系统中数据的类型和分发方式,检查在数据的传输和分发过程中所涉及的基础环境和软件架构是否满足安全性要求。

(帐号数据和实际业务数据的安全性要求的侧重点不一样,前者侧重于机密性,而后者更侧重于完整性)。

(五)当应用系统中的数据进行变更的时候,明确何种类型的数据需要进行审计和追踪,以及所采取的措施的精细程度(完整性检查、错误检测和相应的恢复机制等)。

第六章 应用安全功能设计

第二十三条 身份认证

(一)用户身份认证体系可以采用以下几种:

1.用户名、口令认证;

2.一次性口令、动态口令认证;

3.证书认证;

4.生物特征的认证(签名、声音、指纹、虹膜、视网膜等)

5.应根据应用系统的重要程度合理使用认证方式,如资金管理系统可以采用数字签名认证。

(二)认证失败后的处理应采用以下方式设计:

1.连续失败登录后锁定帐号。

帐号锁定后可以由系统管理员解锁,也可以在一段时间后自动解锁。

2.通知用户认证失败,防止黑客暴力破解。

(三)帐号的创建、修改、变更、删除需要由集中的身份管理平台完成。

(四)将应用系统分割为公共访问区域和受限访问区域,受限区域只接受特定用户的访问,而且用户必须通过身份认证。

当未经认证的用户试图访问受限资源时,应用系统应自动提示用户认证。

(五)内部系统的口令规则应符合口令管理规则,应设置密码强度。

(六)在系统受到威胁时可以使凭证失效或禁用帐户。

(七)支持密码有效期,密码不应固定不变,而应作为常规密码维护的一部分,通过设置密码有效期对密码进行更改。

(八)在网络中禁止以纯文本形式发送密码。

(九)身份验证cookie被窃取意味着登录被窃取,通过加密和安全的通信通道保护验证凭证。

另外,还应限制验证凭证的有效期,以防止因重复攻击导致的欺骗威胁。

(十)在登录时使用随机验证码校验机制,防止恶意用户的暴力破解。

第二十四条 授权

(一)应用系统应包含用户权限分配和管理功能设计

1.系统读、写、执行权限设计;

2.系统查看、配置、修改、删除、登录、运行等权限设计;

3.数据访问范围的权限设计;

4.应用功能模块使用权限的设计;

(二)限制用户对系统级资源的访问,系统级的资源包括:

文件、文件夹、注册表项、Active

Directory对象、数据库对象、事件日志的系统资源。

(三)程序应使用尽可能小的权限

1.应用系统使用的数据库帐号必须是普通权限帐户,只限访问允许的数据库;

2.数据库访问应该使用低权限数据库账号(如选择,删除,更新,插入等)通过参数化的存储过程来访问;

3.应用启动进程的权限尽可能小;

4.应用使用的系统账号(运行环境中的)应该有尽可能低的权限。

应避免“Administrator”,“root”,“sa”,“sysman”,“Supervisor”或其它所有的特权用户被用来运行应用系统或连接到网站服务器,数据库或中间件。

(四)授权颗粒度要尽可能小。

第二十五条 输入输出验证

(一)对所有的输入进行安全验证,无论输入是来自服务、共享。

(二)文件、用户或是数据库,只要来源不在可信任的范围之内,就应对输入进行验证。

(三)采用集中验证方法,输入验证策略作为应用系统设计的核心元素。

考虑集中验证方法。

通过使用共享库中的公共验证和筛选代码。

这可确保验证规则应用的一致性。

(四)为了防止攻击者绕过客户端直接验证,在服务器端进行验证时,必须使用服务器端代码执行验证。

(五)按照已知的有效类型、模式和范围验证数据。

应限制用户输入并验证数据的类型、长度、格式和范围。

(六)进行数据库操作时,对用户提交的数据必须过滤特殊字符或使用中间件调用数据库。

(七)当使用XML文件格式存储数据时,若使用Xpath和XSLT功能,必须过滤用户提交数据中的<>

/'="等字符。

第二十六条 配置管理

(一)配置管理功能应禁止未授权访问。

在管理界面上实施强身份验证,如使用证书,应限制或避免使用远程管理,并要求管理员在本地登录。

如需要支持远程管理,应使用加密通道,如SSL或

VPN技术。

(二)避免在应用系统的 Web 空间使用配置文件,以防止出现的服务器配置漏洞而导致配置文件被非法下载。

(三)应避免以明文的形式存储机密,如数据库连接字符串或帐户凭据。

应通过加密确保这些数据的安全,并限制对包含加密数据的注册表项、文件或表的访问权限。

(四)如应用系统的配置管理功能会因管理员角色而变化,则应使用基于角色的授权策略分别为每个角色授权。

第二十七条 敏感数据

(一)应用系统中应尽量避免存储机密。

(二)禁止在代码中对机密进行硬编码。

即使未将源代码暴露在 Web 服务器上,但从编译过的可执行文件中仍然可以提取字符串常量。

配置漏洞可能会允许攻击者检索可执行文件。

(三)禁止以明文形式存储诸如数据库连接字符串、密码和密钥之类的机密。

应存储经过加密的字

符串。

(四)在网络上向客户端发送敏感数据时,应对数据进行加密或确保通信通道的安全。

(如采用SSL

加密)

(五)禁止使用HTTP-GET协议存储敏感数据,因为该协议使用查询字符串传递数据。

使用查询字符串不能确保敏感数据的安全性,查询字符串会被服务器记录。

第二十八条 会话管理

(一)如应用系统使用SSL加密,应保护会话身份验证Cookie,对cookie内容进行加密,不通过HTTP连接传递身份验证cookie。

在授权cookie内设置安全的cookie属性,以便引导浏览器只通过HTTPS连接向服务器传回cookie。

(二)对于高度保护的应用系统,应将会话超时时间设置为在限定的时间内。

(三)会话状态的存储方式。

应将会话状态存储在Web应用系统的进程地址空间、专用状态服务器上进行进程外状态存储或者在共享数据库中进行永久性状态存储。

对于从Web应用系统到状态存储之间的网络连接,应使用IPSec或SSL确保其安全,以降低被窃听的危险。

(四)不使用Cookie保存敏感信息。

第二十九条加密

(一)不使用不可靠的加密方法,应使用平台提供的经过验证和测试的加密服务。

(二)应避免向算法传递明文数据,并避免修改存储该数据。

(三)应确保所使用的密钥大小能提供足够的安全级别。

以下列表包括了主要算法及其使用的密钥大小:

1.数据加密标准(DES)64位密钥(8个字节)

2.TripleDES128位密钥或192位密钥(16或24个字节)

3.Rijndael128–256位密钥(16–32个字节)

4.RSA384–16,384位密钥(48–2,048个字节)

5.对于关键数据加密,应使用对称的加密。

减慢并加强对大量数据的加密。

应对暂时存储的数据加密,使用较快但较弱的算法,如DES。

对于数字签名,应使用RSA或DSA算法。

对于Hash,应使用SHA1.0算法。

对于用户键入的Hash,应使用基于Hash的消息验证代码

(HMAC)SHA1.0算法。

(四)加密密钥是输入加密及解密进程的秘密数字。

为保证加密数据的安全,必须保护好密钥,定期回收密钥。

第三十条 参数操作

(一)Cookie 中会包含敏感数据,如会话标识符或用作服务器端授权进程一部分的数据,应使用加密方法对cookie的内容加密。

(二)应限制接受用户输入的字段,并对来自客户端的所有值进行修改和验证。

(三)为了防止攻击者操作HTTP 头,应确保Web 应用系统的安全策略不是基于HTTP头中所包含的信息。

第三十一条 异常管理

(一)在发生故障时,应避免泄露应用系统的敏感信息(函数名、系统路径、堆栈跟踪的详细信息)

,只返回一般性的错误消息。

(二)向错误日志发送详细的错误消息。

应该向服务或应用系统的客户发送最少量的信息,如一般性的错误消息和自定义错误日志ID。

(三)为了避免应用系统置于不协调的状态而导致信息泄露,应使用结构化异常处理机制,并捕捉异常现象。

(四)审计日志的格式使用单行的,有规则,有格式的CSV文本格式或采用下列方式中的一种。

(五)Syslog方式:

Syslog方式应给出syslog的组成结构。

(六) Snmp方式:

Snmp方式应同时提供MIB信息

(七)定义审计日志需要包含的内容,必须但不限于如下内容:

用户帐号、日期、时间、资源名、活动结果(访问成功、失败。

系统启动、停止。

配置变更等)

(八)限制对日志数据的访问,并只为高度信任的帐户(如管理员)授予访问权限。

第七章 数据管理

第三十二条 数据传输

(一)应按照数据的类型、数据的重要程度、网络的安全状况等综合因素,对数据的传输采取不同的安全保护,包括但不限于防火墙、IDS、VPN、病毒防护等安全措施。

(二)所有敏感信息和数据,包括用户密码必须进行加密存储,禁止以明文方式存储。

(三)应了解数据传输存在安全隐患的网络或设备,对存在安全隐患的网络采取相应的安全技术,包括使用安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。

(四)应制定数据传输安全的检查方式,包括数据传输安全抗主动攻击能力检查、被动攻击的能力检查。

(五)应保障“数据传输安全”有关的重要配置参数安全,包括但不限于口令、加/解密算法、加/解密密钥等。

(六)应用系统模块中禁止嵌入固定的用户名、密码。

(七)应采用安全通信协议对敏感数据进行安全传输,如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信。

(八)应用系统各模块进行数据传递时,以下私密数据信息在存储和传送时应加密传输:

密码,信用卡号码,银行帐户,CA证书。

(九)应防止对所传输数据进行未经授权的任何形式的修改,即对业务的重要数据或敏感数据,建议使用MD5、SHA等算法对数据完整性进行保护。

(十)对重要的交互信息,建议采取抗抵赖技术,包括但不限于数字签名技术。

第三十三条 数据处理安全

(一)应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。

(二)应对原始数据需要进行检错和校验操作,保证原始数据的正确性和完整性;

(三)数据在转换过程中,应采用通用的标准格式。

(四)数据处理过程应提供处理数据的状态信息和数据处理过程的动态信息;

(五)数据处理过程应具备异常处理功能,在任一环节发现问题时,均应能及时回退,必要时可以人工处理;

(六)数据处理的中间过程和中间结果不应暴露给第三方。

第八章 系统运行日志设计

第三十四条 日志的描述需要准确并且有一定的意义。

第三十五条 日志的内容应尽可能详细,但应平衡性能要求。

第三十六条 应为日志文件设计不同的详细程度供系统管理员或用户选择。

第三十七条 为日志文件设计输出界面,允许以不同的格式

第三十八条 输出日志文件或允许直接输出日志文件到数据库。

第三十九条 日志文件中的每条数据记录应要求有日期和时间(精确到秒)。

第四十条 利用操作系统或相关应用系统的日志文件来提供更详细的内容。

第九章 代码安全

第四十一条 应对函数入口参数的合法性和准确性进行检查。

第四十二条 设计尽量简单清晰,如果设计过于复杂,会给相应的安全设计带来很大的难度,而最终导致安全性的下降。

第四十三条 必须严格遵循Fail-Safe原则,即当发生意外事故时,必须能自动切换到安全的保护模式。

(如当应用系统的登录验证机制不能正常运行时,系统必须自动拒绝所有登录请求,而非接受所有登录请求)

第四十四条 禁止开发人员为普通的应用系统进程分配系统特权帐号(例如系统管理员、ROOT等)。

第四十五条 禁止接受不安全的登录密码,并允许系统管理员强制密码设定规则。

第四十六条 所有缺省安全设置必须能同时满足系统正常运行和系统安全两方面的要求。

第四十七条 在所有警告或提示对话窗口中应使用准确、明了的描述性语言,并提供有关帮助链接。

第四十八条 在接受用户输入时,必须有数据合法性检查,并严格规定输入数据的字符长度。

第四十九条 隐藏所有敏感的信息。

第五十条 在输入密码等敏感信息时,使用特殊符号来代替输入的字符。

第五十一条 在设计基于WEB的应用系统时,必须确保当用户注销会话进程后,包含敏感信息的页面不能通过使用浏览器的回退按钮(BackButton)来显示。

第五十二条 禁止使用未经授权和验证的代码。

第五十三条 使用第三方代码,应对代码安全性进行评估和测试

第五十四条 如密码由应用系统生成,则必须保证有足够的长度和随机性;如密码由用户生成,则应用系统应有密码安全策略来拒绝接受“不安全的”密码。

第五十五条 禁止以明文方式传递用户密码。

第五十六条 测试用的“后门”,应在发布版中去除。

第五十七条 应注释代码中无用的代码。

第五十八条 规范代码的格式:

(一)规范变量、函数的命名;

(二)规范程序的书写格式,确保程序的易读性;

第五十九条 对代码进行版本控制,确保代码的可用性。

第六十条 防止程序员非授权修改代码,对代码的访问权限进行严格的权限控制。

第六十一条 禁止在程序中添加隐藏“恶意”的代码,防止与应用系统相关的程序员对系统的非授权修改。

第十章 测试安全

第六十二条 应明确记录测试目的:

帮助所有测试人员熟悉测试的目的和意图。

第六十三条 应明确测试使用的方式,主要的测试方式有功能测试、压力测试和渗透性测试。

(一)功能测试:

对应用系统的安全功能点进行测试,确保安全功能的有效性、正确性。

(二)压力测试:

对应用系统的安全功能进行压力测试,确保安全功能可以满足设计的需要,包括但不限于以下内容:

1.应用系统服务器端和单个终端进行安全数据传输的最大容量。

2.应用系统服务器端能够与多少终端同时进行安全数据传输。

(三)渗透性测试:

对应用系统抵抗攻击的能力进行测试。

第六十四条 应明确测试的安全要点、测试参与人员、测试流程,并编写测试大纲。

包括对应用系统的帐号、口令的安全测试;数据传输的安全测试。

第六十五条应根据测试大纲制定测试方案(用例)。

(一)测试的环境要求;

(二)测试软件、测试设备要求;

(三)测试人员要求;

(四)测试的时间要求;

(五)测试的输入数据;

(六)测试的预期结果;

(七)测试的详细过程;

(八)测试的风险和风险规避方案。

第六十六条测试环境的物理、硬软件环境应模拟真实环境。

第六十七条测试数据如选择真实数据,应限定测试的人员,并在测试完成后全部删除。

第六十八条系统测试和验收试验通常需要大量接近实际运行数据的测试数据,但应避免使用含有个人信息的业务数据库。

如果要使用其中信息,在使用之前应去除敏感信息。

当把运行数据用于测试目的时,应采取以下措施保护运行数据。

(一)需要工作人员参与。

(二)将运行信息复制到测试应用系统时都应有单独的授权。

(三)测试完成之后,应立即把运行信息从测试应用系统中删除。

(四)应记录运行信息的复制和使用,以便检查和追踪。

第六十九条 在与其他系统的互操作测试中,应充分考虑对其他系统的影响,选择适当的时间、方法。

第七十条测试完成后入网前、割接前应进行安全核查,消除测试用的后门、用户名及口令等。

第七十一条确保测试环境的安全。

应将测试环境与开发环境、生产环境相隔离,避免测试工作对业务的影响。

第七十二条 应详细记录测试过程发生的每一件事情,列出测试过程中发现的问题。

这些信息包括:

发现了什么,在哪里发现的,当时的环境,这些问题是否可重现。

第七十三条应根据测试的过程和测试结果,提出被测试系统、测试过程等方面的改进说明。

第七十四条应确保测试用例、测试内容和测试结果的保密性。

第十一章部署安全

第七十五条应规划应用系统部署需要的资源需求,包括但不限于以下内容:

(一)应用系统部署的软件、硬件的资

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2