4.4.1、XX代码编写安全规范
- 格式：doc
- 大小：69.00 KB
- 文档页数：10
XXX
代码编写安全规范
制定：
审核：
批准：
版本：
XXX
二〇一四年九月
目录
1、代码编写安全规范 (3)
1.1输入数据验证 (3)
1.2内部处理的控制 (4)
1.2.1风险区域 (4)
1.2.2检查和控制措施 (4)
1.3消息验证 (5)
1.4输出数据验证 (6)
2、开发和支持过程中的安全 (6)
2.1变更控制程序 (7)
2.2操作系统变更的技术评审 (8)
2.3对软件外包变更的限制 (8)
2.4隐蔽通道和特洛伊代码 (9)
2.5外包的软件开发 (9)
XXX
代码编写安全规范
1、代码编写安全规范
目标：防止应用系统中用户数据的丢失、修改或滥用。
应用系统应设计包含适当的控制措施和审计追踪或活动日志记录，包括在用户写入的应用程序中。
这些系统应包括对输入数据、内部处理和输出数据的检验功能。
处理敏感、有价值或重要的组织资产或者对这些资产构成影响的系统还需要补充其他控制措施。
这些控制措施是根据安全要求和风险评估确定的。
1.1输入数据验证
要求对应用系统的数据输入进行验证，保证输入数据正确并合乎要求。
应对业务交易的输入、固定数据（姓名和地址、信用限度、客户参考数字）和参数表（销售价格、货币汇率、税率）进行检查。
要求考虑采用以下控制措施：
a)使用双路输入或其他输入检查来查找以下错误：
1)超范围值；
2)数据字段中的无效字符；
3)遗漏或残缺的数据；
4)超过数据量的上限和下限；
5)非法或不一致的控制数据；
b)定期审查关键字段或数据文件的内容，确认其有效性和完整性；
c)检查硬拷贝输入文档是否有对输入数据进行非法变更（所有对输入文
档的变更应经过授权）；
d)对合法性错误的响应步骤；
e)测试似是而非的输入数据的步骤；
f)规定参与数据输入过程的所有人员的责任。
1.2内部处理的控制
1.2.1风险区域
正确输入的数据可能会因处理错误或故意人为等因素遭到破坏。
系统应包含有效性检查，以便检查这类破坏。
应用程序的设计应确保执行某些约束最大限度地降低处理错误导致完整性破坏的风险。
XXX考虑的特定区域包括：
a)使用添加和删除功能并确定它们在程序中的位置，对数据进行变更；
b)防止程序出现运行顺序错误或在前一个处理故障后运行的规程；
c)使用正确程序从故障中恢复，确保正确处理数据。
1.2.2检查和控制措施
需要什么控制措施取决于应用的性质和任何数据毁损对业务的影响。
XXX综合的检查措施的包括以下：
a)会话或批处理控制措施，在事务更新后协调数据文件的平衡；
b)平衡控制措施，针对上次结束时的平衡，检查当前使用的平衡，即：
1)循环——运行控制措施；
2)文件更新总数；
3)程序到程序控制措施。
c)系统生成的数据的有效性；
d)检查数据完整性或在中央计算机和远程计算机之间下载或上载的软件；
e)记录和文件的散列总数；
f)检查确保在正确的时间运行应用程序；
g)检查确保按正确顺序运行程序并在出现故障时中止，在问题解决前暂停
处理。
1.3消息验证
消息验证是一种检查传输的电子消息的内容是否有非法变更或破坏的技术手段。
它可以在硬件或软件上实施，支持物理消息验证设备或软件运算法则。
应对需要安全要求保护消息内容完整性的应用程序考虑使用消息验证，例如电子资金转移或其他类似电子数据交换。
要求对安全风险进行评估，确定是否需要消息验证并寻找最适合的实施方法。
消息验证不是用来保护消息内容避免非法访问的。
加密技术可以用作实现消息验证的适合手段。
1.4输出数据验证
要求对从一个应用系统输出的数据进行验证，保证对所存储信息的处理正确且合乎实际情况。
一般而言，构建系统的前提条件是已经经过适当的验证，这样检验和测试输出才可以始终保持正确。
但情况并非总是如此。
输出验证包括：
a)正反检查输出数据是否合理；
b)协调控制计数确保处理所有数据；
c)为阅读程序或以后的处理系统提供足够信息，确定信息的准确性，完整
性、准确性和分类；
d)处理输出验证数据的程序步骤；
e)规定参与数据输出过程的所有人员的责任。
2、开发和支持过程中的安全
目标：维护应用系统软件和信息的安全性。
要求严格控制项目和支持环境。
负责应用程序的管理员还要求负责项目或支持环境的安全。
他们要求确保对所有提议的系统变更进行审查，检查它们是否破坏系统或操作环境的安全。
2.1变更控制程序
为最大限度地减少信息系统崩溃，应对变更实行严格控制。
要求强化正式的变更控制过程。
他们应确保不破坏安装和控制的程序，支持只赋予程序员访问他们工作需要的那一部分系统的权限，在进行任何变更前必须获得正式的许可和批准。
改变应用软件会影响操作环境。
在适当的时候，应结合操作步骤和应用更改控制步骤。
这个过程应包括以下内容：
a)维护认可授权级别的记录；
b)确保更改由合法用户提交；
c)检查控制措施和完整性步骤，确保它们没有被这些更改破坏；
d)确定所有需要变更的计算机软件、信息、数据库实体和硬件；
e)在正式开始前应获得对具体提议的正式批准；
f)确保合法用户在实施前接受变更；
g)确保执行实施，最大限度减少业务中断；
h)确保在每次变更完成后系统文档集被更新，所有旧文档被归档或得到处
理；
i)维护所有软件更新的版本控制；
j)维护所有变更请求的审计追踪；
k)确保操作文档和用户过程根据需要进行变更；
l)确保在合适的时间执行变更，不会打段有关业务进程。
许多组织都维护一个用户测试新软件的环境，这个环境将开发环境和生产环境分隔开。
这就提供一个方法，既控制新软件，又可以保护用于测试目的的操作信息。
2.2操作系统变更的技术评审
定期变更操作系统是必要的，例如安装一个新提供的软件发行版或补丁程序。
发生变更时，应对应用系统进行审查和测试，确保对操作和安全性没有负面影响。
这个过程应包括：
a)审查应用程序控制和完整性过程确保它们没有被操作系统变更所破坏；
b)确保每年的支持计划和预算包括操作系统变更引起的审查和系统测试费
用；
c)确保及时提供操作系统变更的通知，以便在实施前进行检查；
d)确保对业务连续性计划做适当的变更。
2.3对软件外包变更的限制
不鼓励对软件外包进行变更。
使用供应商提供的软件外包应尽可能不做变更。
在确实需要修改软件外包的情况下，XXX应考虑以下几点：
a)内置的控制措施和完整性进程被破坏的风险；
b)是否获得供应商的同意；
c)当标准程序更新时从供应商获得所需要变更的可能性；
d)在发生变化时组织是否负责以后的软件维护的影响。
如果变更是不可避免的，那么应保留原始软件，只对确定的副本进行变更。
所有的变更应得到完整的测试并进行记录，这样将来需要对软件进行升级时可以重新应用这些变更。
2.4隐蔽通道和特洛伊代码
隐蔽信道可以通过某些间接和模糊的方法暴露信息。
激活信道的方法有两种：更改计算系统中安全和不安全元素都可访问的参数或者将信息嵌入数据流。
特洛伊代码影响以非法隐蔽的方式影响系统，这些代码是接收者或程序用户不需要的。
隐蔽信道和特洛伊代码偶尔发生。
在出现隐蔽信道或特洛伊代码的地方，XXX考虑以下方法：
a)只从信誉较好的地方购买程序；
b)购买使用源代码的程序，这样可以检测代码；
c)使用经过评估测试的产品；
d)在操作使用前检查所有源代码；
e)安装后控制对源代码的访问和修改；
f)只允许证明值得信赖的人员使用关键系统。
2.5外包的软件开发
当软件开发外包时，XXX考虑以下几点：
a)许可管理、代码所有权和知识产权；
b)质量证明和完成工作的准确性；
c)在出现第三方事故时的第三者义务条款；
d)对审计完成工作的质量和准确性的访问权限；
e)对代码质量的合同要求；
f)在安装前进行测试检查是否有特洛伊式的代码。
