9软件开发管理制度管理流程制度.docx
《9软件开发管理制度管理流程制度.docx》由会员分享，可在线阅读，更多相关《9软件开发管理制度管理流程制度.docx（11页珍藏版）》请在冰豆网上搜索。
9软件开发管理制度管理流程制度
文
附录8
软件开发管理制度
1.系统的安全要求3
1.1需求分析和说明3
2.应用系统中的安全3
2.1输入数据验证4
2.2内部处理的控制5
2.2.1风险区域5
2.2.2检查和控制措施5
2.3消息验证6
2.4输出数据验证6
3.加密控制措施7
3.1加密控制措施的使用策略7
3.2加密8
3.3数字签名8
3.4不否认服务9
3.5密钥管理9
3.5.1加密密钥的保护9
3.5.2标准、程序和方法10
4.系统文件的安全11
4.1操作软件的控制12
4.2系统测试数据的保护13
4.3对程序源代码库的访问控制13
5.开发和支持过程中的安全14
5.1变更控制程序14
5.2操作系统变更的技术评审15
5.3对软件外包变更的限制16
5.4隐蔽通道和特洛伊代码16
5.5外包的软件开发17
软件开发管理制度
1.系统的安全要求
目标：
保证信息系统内建有安全机制。
其中包括基础设施、业务应用程序和用户开发的应用程序。
设计和实施支持应用或服务的业务进程是安全的关键。
在开发信息系统前要求确定安全要求，并形成统一认识。
所有安全要求，包括后退安排，都要求在项目的需求阶段确定并进行合理说明，然后达成一致意见并将意见备案作为信息系统整个业务的组成部分。
1.1需求分析和说明
新系统和改进系统的业务要求陈述应指明控制措施方面的要求。
这些说明公司考虑系统包含自动控制措施时，还需要辅助性的人工控制措施。
在评估业务应用程序的软件外包时，也应做与此相似的考虑。
如果认为合适，管理层可能希望使用经过独立评估和鉴定的产品。
安全要求和控制措施应体现出有关信息资产的商业价值，同时反映由于故障或缺少安全保护造成的潜在商业损失。
分析安全要求并确定达到要求的控制措施的指导方针是风险评估和风险管理。
在设计阶段引入控制措施，它的实施和维护的代价要远远小于在实施过程中或之后引入的控制措施。
2.应用系统中的安全
目标：
防止应用系统中用户数据的丢失、修改或滥用。
应用系统应设计包含适当的控制措施和审计追踪或活动日志记录，包括在用户写入的应用程序中。
这些系统应包括对输入数据、内部处理和输出数据的检验功能。
处理敏感、有价值或重要的组织资产或者对这些资产构成影响的系统还需要补充其他控制措施。
这些控制措施是根据安全要求和风险评估确定的。
2.1输入数据验证
要求对应用系统的数据输入进行验证，保证输入数据正确并合乎要求。
应对业务交易的输入、固定数据（姓名和地址、信用限度、客户参考数字）和参数表（销售价格、货币汇率、税率）进行检查。
要求考虑采用以下控制措施：
a）使用双路输入或其他输入检查来查找以下错误：
1）超范围值；
2）数据字段中的无效字符；
3）遗漏或残缺的数据；
4）超过数据量的上限和下限；
5）非法或不一致的控制数据；
b）定期审查关键字段或数据文件的内容，确认其有效性和完整性；
c）检查硬拷贝输入文档是否有对输入数据进行非法变更（所有对输入文档的变更应经过授权）；
d）对合法性错误的响应步骤；
e）测试似是而非的输入数据的步骤；
f）规定参与数据输入过程的所有人员的责任。
2.2内部处理的控制
2.2.1风险区域
正确输入的数据可能会因处理错误或故意人为等因素遭到破坏。
系统应包含有效性检查，以便检查这类破坏。
应用程序的设计应确保执行某些约束最大限度地降低处理错误导致完整性破坏的风险。
公司考虑的特定区域包括：
a）使用添加和删除功能并确定它们在程序中的位置，对数据进行变更；
b）防止程序出现运行顺序错误或在前一个处理故障后运行的规程
c）使用正确程序从故障中恢复，确保正确处理数据。
2.2.2检查和控制措施
需要什么控制措施取决于应用的性质和任何数据毁损对业务的影响。
公司综合的检查措施的包括以下：
a）会话或批处理控制措施，在事务更新后协调数据文件的平衡；
b）平衡控制措施，针对上次结束时的平衡检查当前使用的平衡，即：
1）循环-运行控制措施；
2）文件更新总数；
3）程序到程序控制措施；
c）系统生成的数据的有效性
d）检查数据完整性或在中央计算机和远程计算机之间下载或上载的软件。
e）记录和文件的散列总数；
f）检查确保在正确的时间运行应用程序；
g）检查确保按正确顺序运行程序并在出现故障时中止，在问题解决前暂停处理。
2.3消息验证
消息验证是一种检查传输的电子消息的内容是否有非法变更或破坏的技术手段。
它可以在硬件或软件上实施，支持物理消息验证设备或软件运算法则。
应对需要安全要求保护消息内容完整性的应用程序考虑使用消息验证，例如电子资金转移或其他类似电子数据交换。
要求对安全风险进行评估，确定是否需要消息验证并寻找最适合的实施方法。
消息验证不是用来保护消息内容避免非法访问的。
加密技术可以用作实现消息验证的适合手段。
2.4输出数据验证
要求对从一个应用系统输出的数据进行验证，保证对所存储信息的处理正确且合乎实际情况。
一般而言，构建系统的前提条件是已经经过适当的验证，这样检验和测试输出才可以始终保持正确。
但情况并非总是如此。
输出验证包括：
a）正反检查输出数据是否合理；
b）协调控制计数确保处理所有数据；
c）为阅读程序或以后的处理系统提供足够信息，确定信息的准确性，完整性、准确性和分类。
d）处理输出验证数据的程序步骤；
e）规定参与数据输出过程的所有人员的责任。
3.加密控制措施
目标：
保护信息的安全性、真实性或完整性。
加密系统和技术要求用于保护具有风险的信息和那些控制措施没有提供足够保护的信息。
3.1加密控制措施的使用策略
决定加密解决方案是否合适,应看作是评估风险和选择控制措施的过程的一个部分。
应进行风险评估确定给予信息保护的水平。
评估结果还可以用来确定加密控制是否合适，要求应用什么类型的控制措施以及用于什么目的和业务进程。
为保护自己的信息，组织要求制定使用加密控制的策略。
这些策略是最大化使用加密技术的利益和最小化使用风险必不可少的，并避免不恰当或不正确的使用。
制定策略时，公司考虑以下因素：
a）在组织范围内使用加密控制措施的管理手段，包括保护业务信息的一般原则；
b）核心管理的方法，包括在密钥丢失、破坏的情况下恢复加密信息的方法；
c）作用和责任。
例如谁来负责：
1）实施策略；
2）密钥管理；
d）如何确定适当的加密保护级别；
e）在组织内为有效实施采用的标准（什么解决方案用于什么样的业务进程）。
3.2加密
加密是用于保护信息机密性的口令技术。
在保护敏感或关键信息时公司考虑使用它。
根据风险评估，在考虑使用的加密算法类型和质量以及加密密钥的长度基础上，确定需要的保护级别。
在实施组织的加密策略时，要求考虑法律和国内的限制是否适用于在其他国家和地区使用加密技术，是否会造成加密信息跨国界的问题。
另外，要求考虑控制措施是否适用于出口和进口加密技术.
要求征求专家意见确定适当的保护级别，选择合适的产品，为安全系统提供必要的保护，并执行密钥管理。
另外，有关适用组织计划使用的加密手段的法律规定，需要征求法律方面的意见。
3.3数字签名
数字签字是一种保护电子文档的真实性和完整性的方法。
例如，电子病历中可以使用它，因为需要验证谁签署电子文档并检查已签署文档的内容是否被更改。
数字签字可以应用于各种形式的电子处理文档，例如它们可以用于资金转移、病历签署等。
可以使用加密技术实现数字签字，方法是利用一对唯一相关的密钥，其中一个密钥用于创建签字（个人密钥），另一个用于检查签字（公开密钥）。
应注意保护个人密钥的保密性。
该密钥应秘密保管，因为得到该密钥的任何人都可以签署文档，例如支付、合同等，然后伪造该密钥主人的签名。
另外，保护公开密钥的完整性也很重要。
使用公开密钥证明来进行保护。
需公司考虑所使用的签名算法的类型和质量以及要使用的密钥长度。
用于数字签名的加密密钥应与用于加密操作的密钥不同。
使用数字签名时，公司应考虑所有的相关立法，这些法规说明合法使用数字签名的条件。
例如，在电子商务中，理解数字签名的合法性十分重要。
在法律不完善的地方，需要结合合约或其他协议来支持数字签名的使用。
另外，有关适用组织计划使用的数字签名的法律规定，需要征求法律方面的意见。
3.4不否认服务
在需要解决某个事件或行为是否发生的纠纷（例如，在电子合约或支付中使用数字签名的纠纷）时，要求使用不否认服务。
它们可以帮助确定验证某个事件或行为是否发生的证据，例如否认使用电子邮件发送数字签名的指令。
这些服务以加密技术和数字签名技术的使用为基础。
3.5密钥管理
3.5.1加密密钥的保护
加密密钥管理是有效使用加密技术的关键。
加密密钥的破坏或丢失可能导致信息的保密性、真实性和完整性被破坏。
管理系统要求支持组织使用两种类型的加密密钥，它们是：
a）秘密密钥技术，几个当事方共同使用一个密钥，这个密钥用于加密和解密信息。
这个密钥必须秘密保管，因为获得该密钥的任何人都可以用密钥解密加密的信息，或者带入非法信息。
b）公开密钥技术，其中，每个用户都有一对密钥：
一个公开密钥（向所有人公开）和一个个人密钥（必须秘密保管）。
公开密钥可以用于加密和生成数字签名。
所有密钥都要求保护不被修改和破坏，秘密密钥和公开密钥需要保护不被非法暴露。
加密技术可以用来实现这一目的。
应使用物理保护来保护用于生成、储存和归档密钥的设备。
3.5.2标准、程序和方法
密钥管理系统应基于一组认可的标准、程序和安全方法：
a）为不同的加密系统和应用程序生成密钥；
b）生成并获得公开密钥的证书；
c）将密钥分配给目标用户，包括在收到密钥时应如何激活它；
d）储存密钥，包括授权用户如何获得密钥使用权；
e）更改或更新密钥，包括何时以及如何更改密钥的规则。
f）处理被破坏的密钥；
g）调用密钥，包括如何回收或失活密钥，例如密钥已经被破坏或用户已经离开组织（此时，密钥要求归档）。
h）恢复丢失或破坏的密钥是业务连续性管理的一个部分，例如恢复加密信息。
i）归档密钥，例如归档或备份信息；
j）销毁密钥；
k）记录和审查密钥管理的相关活动。
为降低破坏的可能性，应确定密钥激活和失活的日期，这样密钥只能在限制的时期内使用。
这个时期取决于正在使用密钥控制措施的环境和预期的风险。
需公司考虑处理使用密钥的法律请求，例如，在法庭上需要提供解密的加密信息来作为证据。
除考虑安全管理秘密密钥和个人密钥的问题外，还要求考虑保护公开密钥。
在用自己的公开密钥替换某个用户的公开密钥，就会产生伪造数字签名的威胁。
这个问题通过使用公开密钥证书来解决。
这些证书应通过以下方式制作：
唯一地将与公开/个人密钥对的所有人相关的信息与公开密钥绑定。
因此信赖产生证书的管理流程是很重要的。
这个过程通常由一个证明权威来执行，它是一个得到承认的掌握合适控制措施和方法的组织，具有所需要的信任度。
与提供加密服务的外部供应商（例如，某个证明权威机构）制定的服务水平协议或合约应包含责任、服务的可靠性和提供服务的响应时间等问题。
4.系统文件的安全
目标：
确保安全地进行IT项目和支持活动。
应控制对系统文件的访问。
保护系统完整性应是应用系统或软件所属的用户部门或开发小组的责任。
4.1操作软件的控制
要求对操作系统软件的实施进行控制。
为最大限度降低操作系统崩溃的风险，公司考虑以下控制措施。
a）更新操作系统程序库应由获得适当管理授权的指定保管员来执行。
b）如有可能，操作系统应只保留可执行代码。
c）在获得测试成功和用户接受的证据以及相关的程序源库被更新前，不应在操作系统上执行可执行代码。
d）应维护操作程序库更新的审计日志记录。
e）保留前一版本的软件作为应急方法。
用于操作系统的由供应商提供的软件应保留供应商的支持。
决定升级到新发行版时公司考虑该版本的安全性，即引入新的安全功能或影响该版本的安全问题的数量和严重程度。
如果软件补丁程序可以帮助克服或减少安全漏洞，那么要求应用这些程序。
在需要的时候经过管理层批准，应只给供应商物理或逻辑的访问权限以便提供支持服务。
应监视供应商的活动。
4.2系统测试数据的保护
要求保护和控制测试数据。
系统和验收测试通常需要大量的尽可能与操作数据接近的测试数据。
要求避免使用包含个人信息的操作数据库。
如果使用这类信息，那么在使用前要求做非个性化处理。
在操作数据用于测试目的时，应应用以下控制措施来保护操作数据。
a）适用于操作应用系统的访问控制规程也要求适用于测试应用系统。
b）每次要求使用不同的授权，将操作信息复制到测试应用系统。
c）在测试完成后应立即将操作信息从测试应用系统中清除。
d）要求记录操作信息的复制和使用情况，以便提供审计追踪。
4.3对程序源代码库的访问控制
为减少可能出现的计算机程序崩溃，应按以下方法维护对访问程序源库的严格限制。
a）程序源库应尽可能不要保存在操作系统上。
b）应为每一个应用程序指定一个库保管员。
c）IT支持人员应不受限制地访问程序源库。
d）正在开发或维护的程序不应保留在操作程序源库中。
e）更新程序源库和向程序员提供程序源应通过指定的库保管员来执行，并且获得IT支持管理员的授权。
f）程序清单应保存在安全的环境中。
g）应维护访问程序程序库的审计日志记录。
h）应对旧版本的源程序进行归档，明确指明使用它们操作的准确日期和时间以及所有支持软件、作业控制、数据定义和过程。
i）维护和复制程序源库应受严格的变更控制程序的约束。
5.开发和支持过程中的安全
目标：
维护应用系统软件和信息的安全性。
要求严格控制项目和支持环境。
负责应用程序的管理员还要求负责项目或支持环境的安全。
他们要求确保对所有提议的系统变更进行审查，检查它们是否破坏系统或操作环境的安全。
5.1变更控制程序
为最大限度地减少信息系统崩溃，应对变更实行严格控制。
要求强化正式的变更控制过程。
他们应确保不破坏安装和控制的程序，支持只赋予程序员访问他们工作需要的那一部分系统的权限，在进行任何变更前必须获得正式的许可和批准。
改变应用软件会影响操作环境。
在适当的时候，应结合操作步骤和应用更改控制步骤。
这个过程应包括以下内容：
a）维护认可授权级别的记录；
b）确保更改由合法用户提交；
c）检查控制措施和完整性步骤，确保它们没有被这些更改破坏；
d）确定所有需要变更的计算机软件、信息、数据库实体和硬件。
e）在正式开始前应获得对具体提议的正式批准；
f）确保合法用户在实施前接受变更；
g）确保执行实施，最大限度减少业务中断；
h）确保在每次变更完成后系统文档集被更新，所有旧文档被归档或得到处理；
i）维护所有软件更新的版本控制；
j）维护所有变更请求的审计追踪；
k）确保操作文档和用户过程根据需要进行变更；
l）确保在合适的时间执行变更，不会打段有关业务进程。
许多组织都维护一个用户测试新软件的环境，这个环境将开发环境和生产环境分隔开。
这就提供一个方法，既控制新软件，又可以保护用于测试目的的操作信息。
5.2操作系统变更的技术评审
定期变更操作系统是必要的，例如安装一个新提供的软件发行版或补丁程序。
发生变更时，应对应用系统进行审查和测试，确保对操作和安全性没有负面影响。
这个过程应包括：
a）审查应用程序控制和完整性过程确保它们没有被操作系统变更所破坏；
b）确保每年的支持计划和预算包括操作系统变更引起的审查和系统测试费用；
c）确保及时提供操作系统变更的通知，以便在实施前进行检查。
d）确保对业务连续性计划做适当的变更（参见条款11）。
5.3对软件外包变更的限制
不鼓励对软件外包进行变更。
使用供应商提供的软件外包应尽可能不做变更。
在确实需要修改软件外包的情况下，公司考虑以下几点：
a）内置的控制措施和完整性进程被破坏的风险；
b）是否获得供应商的同意；
c）当标准程序更新时从供应商获得所需要变更的可能性；
d）在发生变化时组织是否负责以后的软件维护的影响。
如果变更是不可避免的，那么应保留原始软件，只对确定的副本进行变更。
所有的变更应得到完整的测试并进行记录，这样将来需要对软件进行升级时可以重新应用这些变更。
5.4隐蔽通道和特洛伊代码
隐蔽信道可以通过某些间接和模糊的方法暴露信息。
激活信道的方法有两种：
更改计算系统中安全和不安全元素都可访问的参数或者将信息嵌入数据流。
特洛伊代码影响以非法隐蔽的方式影响系统，这些代码是接收者或程序用户不需要的。
隐蔽信道和特洛伊代码偶尔发生。
在出现隐蔽信道或特洛伊代码的地方，公司考虑以下方法：
a）只从信誉较好的地方购买程序；
b）购买使用源代码的程序，这样可以检测代码；
c）使用经过评估测试的产品；
d）在操作使用前检查所有源代码；
e）安装后控制对源代码的访问和修改；
f）只允许证明值得信赖的人员使用关键系统。
5.5外包的软件开发
当软件开发外包时，公司考虑以下几点：
a）许可管理、代码所有权和知识产权
b）质量证明和完成工作的准确性
c）在出现第三方事故时的第三者义务条款；
d）对审计完成工作的质量和准确性的访问权限；
e）对代码质量的合同要求；
f）在安装前进行测试检查是否有特洛伊式的代码。
升级会员 