ISO27001信息系统获取开发与维护管理制度.docx

ISO27001信息系统获取开发与维护管理制度.docx

《ISO27001信息系统获取开发与维护管理制度.docx》由会员分享，可在线阅读，更多相关《ISO27001信息系统获取开发与维护管理制度.docx（9页珍藏版）》请在冰豆网上搜索。

ISO27001信息系统获取开发与维护管理制度

信息系统获取、开发与维护管理制度

1.目的和范围

为确保安全成为所开发的信息系统一个有机组成部分，保证开发过程安全，特制定本程序。

适用于本公司所有信息系统的开发活动，信息系统内在安全性的管理。

本制度作为软件开发项目管理规定的补充，而不是作为软件开发项目管理的整体规范。

2.引用文件

1）下列文件中的条款通过本规定的引用而成为本规定的条款。

凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励各部门研究是否可使用这些文件的最新版本。

凡是不注日期的引用文件，其最新版本适用于本标准。

2）GB/T22080-2016/ISO/IEC27001:

2013信息技术-安全技术-信息安全管理体系要求

3）GB/T22081-2016/ISO/IEC27002:

2013信息技术-安全技术-信息安全管理实施细则

3.职责和权限

开发部门：

负责信息系统开发过程中的安全管理,负责保证开发过程安全。

测试部门：

负责信息系统测试过程中的安全管理，负责测试过程安全。

源代码管理人员负责源代码的安全管理。

4.确定信息系统安全需求

1）控制描述

在新的信息系统或增强已有信息系统的业务要求陈述中，应规定对安全控制措施的要求。

2）安全要求在软件开发生命周期中的分布如下图所示：

3）安全需求分析内容可包括以下项：

●确认需要保护的资产；

●评估这些资产需要采取什么安全控制措施；

●考虑是否在系统中加入自动安全控制措施还是建立人工安全控制措施。

4）需求开发与需求管理过程

参见《软件开发安全管理办法》的需求开发与需求管理过程的管理部分。

5.密码控制

5.1.使用密码控制的策略

1）控制描述

应开发和实施使用密码控制措施来保护信息的策略。

2）实施指南

制定密码策略时，应考虑下列（但不仅限于）内容：

●组织间使用密码控制的管理方法，包括保护业务信息的一般原则；

●使用加密技术保护通过可移动介质、设备或者通过通信线路传输的敏感信息；

●基于风险评估，应确定需要的保护级别，并考虑需要的加密算法的类型、强度和质量；

●加密可能带来不利影响。

由于某些控制措施依赖于内容检查，要求数据处于未加密状态（应确认加密前的病毒检测）。

5.2.密钥管理

1）控制描述

应有密钥管理以支持组织使用密码技术。

2）实施指南

应保护所有的密码密钥免遭修改、丢失和毁坏。

另外，秘密和私有密钥需要防范非授权的泄露。

用来生成、存储和归档密钥的设备应进行物理保护。

对于一些部门所使用的USBKEY密钥必须做到专人保管、专人使用，不用时必须防止在保险柜内或带锁的铁柜中妥善保管。

（按一级数据资产和硬件资产实施保护）

6.系统文件的安全

6.1.运行软件的控制

1）控制措施

应有制度来控制在运行系统上安装软件。

2）实施指南

●应仅由受过培训的管理员，在取得管理授权之后，进行软件、应用和程序库的更新；

●操作系统应仅安装经过批准的可执行代码，不安装开发代码和编译程序，如特殊情况下，在不影响系统运行调试时需安装开发代码和编译程序，应在调试完成后，立即卸载并删除所有代码和程序目录。

●在系统安装前，应有完整的安装步骤。

6.2.系统测试数据的保护

1）控制措施

测试数据应认真地加以选择、保护和控制。

2）实施指南

应避免使用包含敏感数据的运行数据库用于测试。

如果测试使用了个人或其他敏感信息，那么在完成测试之后应去除或修改所有的敏感细节和内容。

当用于测试时，应使用下列（但不仅限于）指南保护运行数据：

●正式系统上的访问控制措施也要应用到测试系统上；

●在测试中使用敏感数据应取得适当的授权；

●在测试完成之后，应从测试系统清除主要的敏感数据；

6.3.对程序源代码的访问控制

1）控制措施

应限制访问程序源代码。

2）实施指南

对程序源代码和相关事项（诸如设计、说明书、确认计划和验证计划）的访问应严格控制，以防引入非授权功能和避免无意识的变更。

对于程序源代码的保存，通过代码集中存储控制来实现，放在公司指定的配置管理库中。

应考虑下列（但不仅限于）指南：

●若有可能，在运行系统中不应保留源程序库；

●应限制客服和技术支持人员访问配置管理库；

●更新配置项或向程序员发布程序源码应获得适当的授权；

●应维护配置库的访问日志；

6.4.测试和运行设施分离

为防止运行问题，需识别运行与测试环境之间的分离级别：

●测试环境与运行环境要严格分离，不允许在运行环境中进行测试工作；

●测试系统要尽可能的仿效运行系统的环境；

●敏感数据不要拷贝到测试系统环境中。

6.5.系统安全性测试

●系统安全性测试需要开发人员测试，开发人员相互测试，测试小组测试；

●测试完成后，应该消除测试用的后门、用户名及口令等。

7.开发和支持过程中的安全

7.1.变更控制制度

1）控制措施

严格控制软件包的变更，只限于必要的变更。

关键应用的操作系统的变更，需要进行评审和测试。

应使用正式的变更控制制度控制变更的实施。

2）实施指南

应按照《变更管理规定》执行相应的变更操作，以将信息系统的损坏减到最小。

7.2.操作系统变更后应用的技术评审

1）控制措施

当操作系统发生变更后，应对业务的关键应用进行评审和测试，以确保对组织的运行和安全没有负面影响。

2）实施指南

这一过程应涵盖：

●检查应用系统的控制措施，以确保它们不因操作系统变更而损坏；

●确保及时提供操作系统变更的通知，以便于在实施之前进行合适的测试和评审；

●应对业务连续性计划进行适当的调整或变更。

7.3.软件包变更的限制

1）控制措施

应对软件包的修改进行劝阻，限制必要的变更，且对所有的变更加以严格控制。

2）实施指南

如果可能且可行，应使用厂商提供的软件包，而无需修改。

在必须修改软件包时，应考虑下列各点：

●内置控制措施和完整性过程被损坏的风险；

●是否应获得厂商的同意；

●当标准程序更新时，从厂商获得所需要变更的可能性；

7.4.信息泄露

1）控制措施

应防止信息泄露的可能性。

2）实施指南

应考虑下列事项以限制信息泄露的风险，如通过利用隐蔽通道泄露敏感数据：

●扫描可能隐藏信息的外发介质和通信；

●调整应用系统和通信的行为，以减少第三方从这些行为中推断信息的可能性；

●监视计算机系统的资源使用。

7.5.系统验收

应确保验收新系统的要求和准则被明确定义。

新信息系统升级和新版本只有在获得正式验收后，才能进入生产环节。

8.技术脆弱性的控制

1）控制措施

应及时得到现用信息系统技术脆弱性的信息，从供应商的官方网站或者相关的权威安全网站，获得现用系统的技术脆弱性，评价组织对这些脆弱性的暴露程度，并采取适当的措施来处理相关的风险。

2）实施指南

应采取适当的、及时的措施以响应潜在的技术脆弱性。

建立有效的技术脆弱性管理过程，应遵循下面的指南：

●组织应定义和建立与技术脆弱性管理相关的角色和职责，包括脆弱性监视、脆弱性风险评估、打补丁、资产追踪和协调责任；

●一旦潜在的技术脆弱性被确定，组织应识别相关的风险并采取措施；这些措施可能包括对脆弱的系统打补丁，或者应用其它控制措施；

●如果有可用的补丁，则应评估安装该补丁的风险；

●在安装补丁之前，应进行测试与评估，以确保它们是有效的，且不会导致不能容忍的负面影响；

●处于高风险中的系统应首先解决。

9.公共网络应用服务的安全

1）控制措施

应保护公共网络中的应用服务信息，以防止欺骗行为、合同纠纷、未授权泄露和修改。

2）实施指南

●确保在与合作伙伴的沟通中，完整地告知了他们有关服务供给或使用的授权；

●合作伙伴间的应用服务协议宜形成文件，该协议列出了双方达成一致的服务条款

●对于业务数据的保护依据《信息资产分级分类表》进行管理；

●确保订单交易、支付信息、交付地址细节和接收确认的保密性和完整性；

●针对各产品线的风险评估活动依据《风险评估管理制度》定期开展。

10.应用服务事务的保护

1）控制措施

保护应用服务事务中的信息，以防止不完整的传输、错误路由、未授权的消息变更、未授权的泄露、未授权的消息复制或重放

●通过APP登陆系统进行双向认证。

●Web站点通过https方式进行加密传输；

●语音和信令是通过aes加密传输。

2）实施指南

●对于业务数据、管理信息的保护依据严格的权限控制进行管理；

●事务的所有方面，即确保：

1）各方的用户秘密鉴别信息是有效的并经过验证的；

2）事务保持保密性；

3）保持各方相关联的隐私；

●加密涉及的各方间的通信路径；

●在涉及的各方之间通信的协议是安全的；

●确保事务细节存储于任何公开可访问环境之外，如存储于组织内部互联网的存储平台，不留在或暴露于互联网可直接访问的存储介质上；

11.安全的开发环境

1）控制措施

组织宜针对覆盖系统开发全生命周期的系统开发和集成活动，建立安全开发环境，并予以适当保护。

2）实施指南

安全的开发环境包括与系统开发和集成相关的人员、过程和技术。

组织宜评估与单个系统开发工作相关的风险，并为特定系统的开发工作建立安全的开发环境，考虑：

●系统所处理、存储和传输的数据的敏感性；

●适用的外部和内部要求，如法律法规或策略的要求；

●组织已实现的支持系统开发的安全控制；

●工作环境中人员的可信度；

●分离不同开发环境的需求；

●访问开发环境的控制；

●监视环境及其所存储代码的变更；

●在安全的异地存储备份；

●控制数据移入移出环境的活动。

一旦特定开发环境的保护级别被确定，组织宜将相应的过程形成安全开发规程文件并提供给有需要的人员。

12.项目管理中的信息安全

1）控制措施

宜关注项目管理中的信息安全问题，无论何种类型的项目。

。

2）实施指南

项目启动前对人员和技术风险评估及合同评估。

根据客户要求签订保密协议。

使用的项目管理方法宜要求：

●信息安全目的被纳入项目目的；

●为识别必要的控制，在项目的早期阶段宜进行信息安全风险评估；

●信息安全作为所采用的项目管理方法各个阶段的一部分。

在所有项目中宜解决和定期评审信息安全问题。

宜定义信息安全责任，并分配给在项目管理方法中定义的特定角色。

13.支持文件

《软件开发安全管理办法》

《源代码安全管理制度》

《讯鸟软件测试规范》

《详细设计说明书》

《概要设计说明书》

本制度相关修改及解释权属于研发服务体系

文档编号（由总经办填写）

F4-B-研发服务体系-009-V1.0

密级

内部公开

文档发布级别

公司级

文档发布及实行范围

全员

制度试行日期（可选）

制度执行日期

2017/07/01

文档起草人

签字：

日期：

2017/07/01

文档修订人：

签字：

日期：

修订说明：

备注：

文档负责人：

签字：

日期：

2017/07/01

文档审批

信息安全管理者代表

签字：

日期：

2017/07/01

文档审批人

签字：

日期：

2017/07/01