doc-某石油天然气股份公司应用系统开发安全管理通则(doc39)-石油化工

X信息安全标准编号某石油天然气股份公司应用系统开发安全管理通则前言随着X天然气股份有限公司（以下简称“X”）信息化建设的稳步推进，信息安全日益受到X的广泛关注，本规范是依据X信息安全的现状，参照国际、国内和行业相关技术标准及规范，结合X自身的应用特点，制定的适合于X信息安全的标准与规范。目标在于通过在X范围内建立信息安全相关标准与规范，提高X信息安全的技术和管理能力。信息技术安全总体框架如下区域安全管理规范机房安全管理规范硬件设备管理规范网络安全管理规范通用安全管理标准数据和文档安全管理规范应用系统使用安全管理标准通则应用系统开发安全管理标准通则商业软件购买管理标准电子邮件安全管理规范WEB系统安全管理规范电子商务安全规范防御恶意代码和计算机犯罪管理规范信息安全技术标准物理环境安全管理硬件设备安全管理操作系统安全管理数据和文档安全管理应用系统安全管理网络安全管理概述通用网络安全管理规范内部网络安全管理规范外部网络安全管理规范认证管理通用标准通用安全管理标准概述授权管理通用标准加固管理通用标准加密管理通用标准日志管理通用标准系统登陆管理通用标准操作系统安全管理规范1）整体信息技术安全架构从逻辑上共分为7个部分，分别为物理环境、硬件设备、网络、操作系统、数据和文档、应用系统和通用安全管理标准。图中带阴影的方框中带书名号的为单独成册的部分，共有13本规范和1本通用标准。2）对于13个规范中具有一定共性的内容我们整理出了7个标准横向贯穿整个架构，这7个标准的组合也依据了信息安全生命周期的理论模型。每个标准都会对所有的规范中相关涉及到的内容产生指导作用，但每个标准应用在不同的规范中又会有相应不同的具体的内容。我们在行文上将这7个标准组合成一本通用安全管理标准单独成册。3）全文以信息安全生命周期的方法论作为基本指导，规范和标准的内容基本都根据预防保护检测跟踪响应恢复的理论基础行文。本通则讨论了在企业内部自行开发一套应用系统或外包开发所必须考虑到的几个步骤，开发应用系统的安全性考虑就好像建设楼房一样，拥有越坚固的地基楼房越是稳定，因此应用系统在开发阶段打好坚实的安全基础，那么以后的日常维护工作就会很轻松。以下我们主要从系统开发的各个阶段入手，考虑在标准的开发流程的各个阶段中要注意的安全方面的考虑。本规范由X天然气股份有限公司发布。本规范由X天然气股份有限公司科技与信息管理部归口管理解释。起草部门X制定信息安全政策与标准项目组。说明在X信息安全标准中涉及以下概念组织机构X（PETROCHINA）指X天然气股份有限公司有时也称“股份公司”。集团公司（CNPC）指X天然气集团公司有时也称“存续公司”。为区分X的地区公司和集团公司下属单位，担提及“存续部分”时指集团公司下属的单位。如辽河油田分公司存续部分指集团公司下属的辽河石油管理局。计算机网络X信息网（PETROCHINANET）指X范围内的计算机网络系统。X信息网是在X天然气集团公司网络的基础上，进行扩充与提高所形成的连接X所属各个单位计算机局域网和园区网。集团公司网络（CNPCNET）指集团公司所属范围内的网络。X的一些地区公司是和集团公司下属的单位共用一个计算机网络，当提及“存续公司网络”时，指存续公司使用的网络部分。主干网是从X总部连接到各个下属各地区公司的网络部分，包括X总部局域网、各个二级局域网（或园区网）和连接这些网络的专线远程信道。有些单位通过拨号线路连接到X总部，不是利用专线，这样的单位和所使用的远程信道不属于X专用网主干网组成部分。地区网地区公司网络和所属单位网络的总和。这些局域网或园区网互相连接所使用的远程信道可以是专线，也可以是拨号线路。局域网与园区网局域网通常指，在一座建筑中利用局域网技术和设备建设的高速网络。园区网是在一个园区（例如大学校园、管理局基地等）内多座建筑内的多个局域网，利用高速信道互相连接起来所构成的网络。园区网所利用的设备、运行的网络协议、网络传输速度基本相同于局域网。局域网和园区网通常都是用户自己建设的。局域网和园区网与广域网不同，广域网不仅覆盖范围广，所利用的设备、运行的协议、传送速率都与局域网和园区网不同。传输信息的信道通常都是电信部门建设的。二级单位网络指地区公司下属单位的网络的总和，可能是局域网，也可能是园区网。专线与拨号线路从连通性划分的两大类网络远程信道。专线，指数字电路、帧中继、DDN和ATM等经常保持连通状态的信道；拨号线路，指只在传送信息时才建立连接的信道，如电话拨号线路或ISDN拨号线路。这些远程信道可能用来连接不同地区的局域网或园区网，也可能用于连接单台计算机。石油专网与公网石油专业电信网和公共电信网的简称。最后一公里问题建设广域网时，用户局域网或园区网连接附近电信部门信道的最后一段距离的连接问题。这段距离通常小于一公里，但也有大于一公里的情况。为简便，同称为最后一公里问题。涉及计算机网络的术语和定义请参见X局域网标准。目录11概述312目标313规范的使用范围414规范引用的文件或标准515术语和定义616应用系统开发总体原则717系统需求收集和分析阶段安全规范8171可行性研究分析8172开发人员安全管理机制10173建立系统开发安全需求分析报告1118系统设计阶段的安全规范12181单点访问控制，无后门。12182人员职责和权限的定义12183确保敏感系统的安全性12184确保访问层的安全性12185确保日志管理机制健全12186新系统的容量规划1319系统开发阶段安全规范14191系统开发语言安全规范14192系统开发安全相关工具管理规范19193控制软件代码程序库21194在软件开发过程变更管理规范23195开发版本管理规范24196开发日志审核管理规范25197防御后门代码或隐藏通道相关规范25110系统测试阶段安全规范271101应用系统的安全性检测规范271102控制测试环境291103为测试使用真实的数据291104在软件转移至生产环境前进行测试291105应用系统安全质量鉴定30111系统培训及文档阶段安全规范311111新系统的培训311112撰写新系统和系统改进的文档31112应用系统开发外包安全控制32附录1参考文献33应用系统开发安全管理通则应用系统开发安全管理通则11概述信息系统的许多的安全控制或者是安全性是通过系统的开发设计予以实现的。因此如果在系统的开发设计阶段没有对系统的安全性给予充分的考虑，那么系统本身一定会存在许多先天不足，系统就会漏洞百出。为了确保应用系统的安全，在应用系统开发之前就应当对系统的安全要求有所确认，并作为开发设计的阶段的基础予以落实。本规范主要规定了在系统开发的各个阶段需要的各种安全规范，从可行性分析需求分析阶段开始，到设计阶段，再到开发阶段和维护阶段以及最后的文档阶段的系统开发的各个阶段进行阐述。将不同阶段下需要注意的安全问题和相关的安全规范进一步进行描述和规定。12目标本规范的目标为保护应用系统开发过程中的安全。具体地说就是保护应用系统开发过程中免受未经授权的访问和更改，保护系统开发中系统软件和信息的安全，确保开发项目的顺利正确的实施并对开发环境进行严格的控制。同时确保应用系统开发外包中的各项安全。从而进一步保障X业务的持续运营，保护X信息资产安全，即保护软件及信息的完整性，维护信息处理设备及通讯服务的完整性及可用性，确保设备中的信息及相关基础建设的安全，确保正确、安全操作信息处理设备，降低系统故障风险。总而言之，要防止对X经营环境及信息的未经授权存取、破坏或干扰；防止中国信息资产受损及企业运营受影响；防止信息及信息处理设备泄露及被偷窃。13规范的使用范围该套规范适用的范围包括了整个应用系统开发过程中的安全。包括了系统开发可行性和需求分析阶段的安全，系统设计阶段的安全，系统开发阶段的安全，系统测试阶段的安全，系统培训和文档阶段的安全以及系统开发外包的安全规范。主要规定了应用系统开发过程的安全保密，软件的质量的要求，系统和业务需求的符合性，保证敏感信息的安全，系统本身的稳定性和兼容性问题。14规范引用的文件或标准下列文件中的条款通过本标准的引用而成为本标准的条款。凡是不注日期的引用文件，其最新版本适用于本标准。1建筑设计防火规范（GBJ1687）2高层民用建筑设计防火规范（GB5004597）3建筑内部装修设计防火规范（GB50222_95）4建筑防雷设计规范（GB50057）15术语和定义16应用系统开发总体原则应用系统的开发应当遵循一系列的总体原则，以确保开发过程中的安全。其中包括A系统开发需得到公司领导层的重视和参与。需要领导层组织开发力量，协调各方关系并在开发的过程中提供决策性的意见和建议。B系统开发应当从业务需求得角度出发，不得盲目追求系统先进性而忽略了系统的实用性。系统的开发是为了更高的满足业务上的需要，而不是技术上的需要。C开发的方法和管理必须规范化、合理化、制度化。只有采用了规范化合理化制度化的开发管理方法，才能确保开发的质量和进度。D保证开发的进度和按时完成。确保开发工作及时、有效且高质量的完成。E系统开发必须具有一定的前瞻性，符合主流系统的发展方向。F开发人员安全意识的提高和加强。确保机密信息和关键技术不会泄漏，特别是泄漏到竞争对手的手中，将会对公司的竞争力产生极大的影响。G充分利用现有的资源。17系统需求收集和分析阶段安全规范171可行性研究分析对于应用系统开发项目需要进行一定的可行性分析，确认在开发工作具备了的相当资源和条件，并且有能力满足业务上的需求的情况下才能开展，切忌盲目开发。既浪费了资源，又浪费了时间。可行性研究可以从技术方面，需求方面，投入方面和影响方面进行考虑1711技术可行性分析根据业务上提出的需求，从技术开发的角度分析是否现有的技术手段和技术能力是否可以达到业务上要求的系统功能。通常可以从三个方面进行分析A人员技术能力分析，指公司内的系统开发队伍是否有足够的软件开发的技术能力来完成系统开发的任务，或第三方外包的开发公司是否具有开发应用系统的技术能力。B计算机软件和硬件分析，指公司现有的软件和硬件的性能是否足够满足开发相应的系统的要求。C管理能力分析，指现有的技术开发管理制度和管理流程是否成熟且标准化，是否足够系统开发的要求。1712需求可行性分析系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需求是否明确，是否符合实际而不是天马行空式的空谈，是否是在一定的时间范围内可实现的。1713投资可行性分析根据业务需求和技术手段的分析，确认根据业务需求和技术手段需要多少的投资才可以实现，确认投资的数额是不是在可控制和可承受的范围内。1714影响可行性分析所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否和相关的管理制度或行业标准相抵触，是否不符合人文或道德上的约束等等。172开发人员安全管理机制1721系统开发人员职责分配管理规范在系统开发的过程中，应当明确不同的人员的身份、职责。我们建议在系统开发过程中具体分以下的三种角色项目负责人员确保在整个系统开发的各个阶段都实施了相关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。系统开发人员根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求，同时满足系统质量上和进度上的要求。系统审核人员对整个开发的过程进行审核和监督，确保开发的质量和开发的安全。1722开发人员授权管理规范A根据该员工在整个开发项目中所负责的开发内容授予其相应的权限和承担的责任。B开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄漏出去，即使是家人或开发团队中的其他开发人员也不得泄漏。但开发人员有责任将开发的相关信息告诉项目的负责人员或开发小组的负责人员。C以书面的方式将员工的权限和相应的责任提交给员工本人。必须严格规定在为企业工作期间的所有和工作相关的开发成果的所属权都归企业所有。D根据员工权限和责任的大小确认是否需要签署相关的保密协议。E在日常工作中记录员工的开发相关的日志信息。F员工一旦离职或调动岗位应立即收回或调整其相应的权限。1723开发人员必须训练开发安全代码的能力A开发人员应该有能力防止开发过程中的缓冲器溢出错误“BUFFEROVERFLOWATTACKS”。B在整个开发的过程中必须完整的持续的进行代码错误处理所规定的流程。C错误问题报告应该越通俗越好，不应该在其中包含任何系统细节问题。D应该对重要的敏感信息进行加密的保护。E应该使用一些相对复杂的加密和密钥生成机制。F应该单独编写安全性设计说明概要1724分离系统开发和运作维护管理层必须要确保应用系统开发和应用系统运作管理从组织人事和权限职责上必须分开。尽管只有大型企业才有独立的系统运行和系统开发部门，但是把这些功能分开毫无疑问是非常必要的。职责的分开对于大多数信息安全保护来说至关重要。AIT人员可以现场修复或者更改偶然的或者是恶意的数据和软件的问题。B测试代码中往往包含调试或者查错代码，大大加大了主机系统的性能负担。C开发人员常常具有很高的权限，这在运行系统中会产生很大的风险，所以是不可接收的。173建立系统开发安全需求分析报告A安全需求计划应该能够达到期望的安全安全水平。其中包括了成本的预估，完成各个安全相关流程所需的时间。B所有的有关应用系统的更新或改进都必须是基于业务需求的，并且是有业务事件支持的。这里的业务需求不仅仅包括了系统的功能、性能、开发费用、开发周期等内容，还要明确系统的安全要求。应用系统的任何一次改进或更新都和该业务系统的所有者密切相关。C一个安全开发需求分析计划应该由开发项目经理和公司内部安全小组共同商议决定。D确保每一个应用系统的用户都意识到系统的更新或改进都和他们本身密切相关，所有的更新或改动的建议都必须是由业务需求出发的而不是从所谓的“信息技术的要求”。E系统的每一次更新或改进都必须认真的对待，必须进行详细的需求定义、需求分析以及测试评估以保证不会对业务造成任何的影响。F业务需求是系统更新和改动的基础，因此必须清晰明确的定义业务的需求，绝对不允许在业务需求未经过业务部门领导和主要负责人员的认可的情况下，盲目的进行开发工作。18系统设计阶段的安全规范181单点访问控制，无后门。任何用户如果希望访问应用系统中的某一个部分，则必须通过统一的且唯一的认证授权方式以及流程。182人员职责和权限的定义由于不是所有的人员对于某一个应用系统都具有同样的访问或使用的权限，因此系统必须具有基于人员职责的用户授权管理以确保每个用户可以访问到其权利范围内的应用系统部分。同样的，也要确保每个用户无法访问其权限范围以外的应用系统部分。183确保敏感系统的安全性通过将应用系统中敏感的信息保存在服务器端以进行集中的加密的安全管理，确保客户端系统本身并不能存储任何信息敏感的数据。184确保访问层的安全性应用系统不仅仅要确保系统模块本身的安全性，同时也要考虑模块与模块之间的通讯的安全性。这种模块与模块之间的安全性不仅仅包括了应用系统内部模块之间的安全，也包括了应用系统内部模块和外部模块之间的安全性，如主机和客户端之间通讯的安全性。服务器和服务器间通讯的安全性，本地系统和异地系统之间通讯的安全性。185确保日志管理机制健全要求建立可以根据情况自由设置的日志管理机制，也就是说日志纪录的范围和详细程度可以根据需求自行定制，且可以实现在应用系统使用过程中进行日志的定制和记录。保留所有系统开发相关的程序库的更新审核纪录。186新系统的容量规划容量规划是指确定系统的总体规模，性能和系统弹性。容量规划的具体内容可能有所不同，但一般需要考虑以下方面A系统的预期存储容量和在给定的周期里面获取生成和存储的数据量。B在线进程的数量和估计可能的占用资料C对于系统和网络的相应时间和性能，即端对端系统D系统弹性要求和设计使用率峰值，槽值和平均值等E安全措施例如加密解密数据对系统的影响。F24X7运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须性宕机）规划容量的时候关于系统使用的信息了解得越多越好。近来，由于互联网站得使用以指数形式增长，容量规划变动效果不是非常显著，有时甚至毫无用处。原因在于很难估计实际的负载。在容量估计的时候需要尽量将情况设想得复杂一些。19系统开发阶段安全规范191系统开发语言安全规范程序员可以使用很多指导规范来防止应用程序中的普通的安全问题。其中许多可以应用于任何一个编程语言，但某些是针对特定的语言的。特定语言的指导规范主要集中在PERL，JAVA和C/C语言。大多数情况下，一般的错误可以通过下功夫或者对基本的问题有很好的理解来避免。这些本可以避免的错误常常会导致很多安全漏洞，从而威胁信息的保密性、完整性和可用性。1911通用规范19111输入验证在客户机/服务器环境下，进行服务端的验证而不是客户端的验证（例如基于JAVASCRIPT的验证）。通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。有了代理服务器，攻击者可以在数据被客户端“验证”后修改数据（与“MANINTHEMIDDLE”攻击类似）。在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。如果输入中包含无效的字符，应用程序应该返回错误页面并说明输入中包含无效字符。这样进行验证的原因是定义无效的字符集比较困难，并且一些不应该有效的字符通常不会被指出。另外，边界检查（例如字符串的最大长度）应该在字符有效性检查以前进行。边界分析可以防止大多数缓冲区溢出漏洞。必须提到的是从环境变量获得的数据也需要进行验证。同时避免在环境变量中存放敏感数据（例如密码）。某些UNIX系统（例如FREEBSD）包含PS命令，可以让用户看到任何当前进程的环境变量，这常常会暴露保密性信息。19112SQL语句如果应用程序需要连接后端数据库，使用存储过程而不要在代码中使用SQL语句。使用程序以外的嵌入在代码中的SQL语句调用特别危险。难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的SQL攻击。当然，输入验证有助于缓解这种风险。19113注释代码COMMENTEDCODE当应用程序在实际环境中开始应用时，应该删除所有的注释代码。注释代码是用来调试或者测试的，它们不是最终应用程序的一部分。无论如何应该在实际的环境中删除它们来避免意外的执行（一般注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，所以强烈建议执行这项工作）。19114错误消息所有为用户显示的错误信息都不应该暴露任何关于系统、网络或应用程序的敏感信息。如果可能的话，最好使用包含编号的一般的错误信息，这种信息只有开发者和/或支持小组才能理解。一般的错误信息的例子是“发生了错误（代码1234），请您与系统维护部门联系。”19115URL内容对于WEB应用，不要在URL上暴露任何重要信息，例如密码、服务器名称、IP地址或者文件系统路径（暴露了WEB服务器的目录结构）。这些信息可以在攻击时使用。例如下面就是一个不安全的URLHTTP/WWWXYZCOMPANYCOM/INDEXCGIUSERNAMEUSERSYSTEMBUFFER在以上的例子中，可以通过使用分号利用文件名变量在SEHLL中插入额外的命令（例如文件名可以是/ETC/HOSTSRM，这将在显示/ETC/HOSTS目录文件的同时，删除目录中的所有文件。）。而EXEC函数只保证第一个参数被执行EXECL“USR/BIN/EMACS“,“USR/BIN/EMACS“,FILENAME,NULL上面的例子保证文件名仅仅作为一个参数输入EMACS工具，。同样它在EMACS命令中使用完全的路径而不是使用可以被攻击者利用的PATH环境变量。19144竞争条件（RACECONDITION）进程需要访问资源时（无论是磁盘、内存或是文件）通常需要执行两个步骤1首先测试资源是否空闲可用2如果可用，就访问该资源，否则它等到资源不再使用为止再去访问它当另一个进程在步骤1和2之间想要访问同一个资源时就出现问题了。这会导致不可预测的结果。进程可能会被锁定，或者一个进程籍此获得了另一个进程的较大的权限而导致安全问题。攻击主要集中在有较大权限的程序上（称为SETUID程序）。竞争条件攻击通常利用程序执行时可以访问到的资源。另外权限低的程序也存在安全风险，因为攻击者可能会等待有较高权限的用户执行那个程序例如ROOT，然后进行攻击。下面的建议有助于缓解竞争条件RACECONDITION攻击在进行文件操作时，利用那些使用文件描述符的函数而不要使用那些使用文件路径的函数（例如使用FDOPEN而不要使用FOPEN）。文件描述符使得恶意的用户在文件打开时或是在原始的进程对文件进行操作前，无法使用文件连接（符号式的或是物理的）来改变文件。在写文件甚至在读文件时使用FCNTL和FLOCK函数来对文件加锁，这样它们就不能被其他进程访问。它几乎可以建立原子级的操作。谨慎操纵零时文件，因为它往往会导致竞争条件。19145检验有效的返回值检验有效的返回值非常重要。一个例子是旧的/BIN/LOGIN的实现中不检验错误的返回值，导致当它找不到/ETC/PASSWD文件时返回ROOT的访问权限。如果该文件损坏了，那么这种情况是合理的，但如果该文件存在只是无法访问，那么这就是一个大问题。192系统开发安全相关工具管理规范有许多方法来确保代码符合一定的安全级别。正如前面指出的，最好的方法之一是让尽可能多的人来检查代码（而不是在QA环境中实际进行白箱或者黑箱测试）。然而，有时代码在开始实际环境的应用前往往没有足够的时间，并且即使检查代码也会漏掉一些不容易发现的错误。这些错误可能会对整个系统导致重大的安全问题。因此（以及其他的原因），使用源码分析工具SOURCECODEANALYSISTOOLSCAT来自动进行某些检查过程很有帮助。本文介绍了一些这方面的工具。每个工具都用同样的测试工具来检验，这些测试工具包含C和JAVA的代码段，而这些代码段存在潜在的安全错误。我们比较了每个工具的测试结果，并且仔细检查了以下的属性A灵活性有多种选项并能扫描多种类型的代码的工具得分会较高B正确性主要目标是发现正确的安全问题，并且不会出现大量的误报信息，或者更糟的是没有发现真正的错误信息。C容易使用大多数情况下，程序员只需要将工具指定到特定的代码上然后选择“扫描”。除非特别需要，程序员一般只做抽样检查，而无需开发复杂的测试机制。D报表扫描结果应该以一种容易理解的格式来显示，并且最好同时提示修改每个问题的方法，并附加理由。每个工具在解析代码上的速度可以忽略不计，所以没有进行比较（虽然这并不包括配置扫描的时间，而MOPS在这方面相对于其他工具需要更多的时间）。另外，这些工具都可以免费获得，甚至可以获得它们的源代码，所以不需考虑它们的成本。1921工具一PSCANPSCAN是一个有针对性的扫描程序，主要用于发现C程序中的缓冲区溢出和格式化字符串攻击。该程序检查所有用到标准C程序库中的PRINTF函数。SPRINTFBUFFER,VARIABLEPRINTFBUFFER,VARIABLE关于这些语句在缓冲区溢出和格式化字符串攻击中怎样被利用可以查阅相关的C和C文档。PSCAN的一个不足是不能发现由于越界检查不充分而引起的常规性缓冲区溢出。不过PSCAN对于缓冲区溢出和格式化字符串攻击的定位还是相当精准和快速的。PSCAN程序相对简单，它只将结果返回都标准输出，当然也可以将其输出到文件，并且除了说明程序员应该怎样修正错误以外不给出语句为什么出错等类似的信息。该工具一个显著的特点是可以同时扫描多个文件。总体而言PSCAN程序相对简单，易于使用，同时针对性很强，但是由于它能够适用的范围过于狭窄因此一般不推荐其在大型商业应用中使用，而只是检查一些相对简单的程序片断。1922工具二FLAWFINDERFLAWFINDER是一个分析C程序安全隐患的静态分析工具。和PSCAN类似，该程序可以发现很多种类型的错误，除了PRINTF和标准的字符串函数，它还可以发现竞争条件和系统调用。FLAWFINDER相比较PSCAN，它返回的错误信息要丰富很多，并且也更加详细。而这对于程序员来说非常重要。FLAWFINDER甚至可以对程序中的弱点进行分类，例如BUFFER弱点、格式弱点、SHELL弱点等。总之，FLAWOFINDER是一个相当出色的C程序检查工具，速度会，界面友好，返回信息丰富，安装使用相对简单。该工具是检查不同规模的应用程序的首选，唯一不足的是它只能用于C程序的检查。193控制软件代码程序库1931管理运作程序库我们通常将用于系统开发的开发软件工具和开发平台称之为运作程序，因此为了降低计算机程序被破坏的可能性，应对运作程序库的访问进行严格的控制A严格的管理在开发设备上的存放开发运作程序的目录。如果开发运作程序没有很好的保护，会造成系统及其设置会遭到未经授权的访问并造成系统的安全性可靠性大大下降。B只有指定的人员如程序库管理员经过适当的管理授权后才可以访问运作程序库，对运作程序库的访问必须结合进行严格的访问控制技术手段和双重访问控制机制。19311严格的访问控制可以通过以下规定实现A严格管理开发部门所在区域的安全保安管理，防止未经授权的人进入开发区域。B严格管理开发用途的计算机使用，只有指定的人员才可以访问开发用的计算机设备。C严格管理开发运作系统的认证管理，建立严格的基于人员职责的授权等级制度，用口令或其他身份识别技术确认访问者身份。19312建立双重访问控制机制双重访问控制机制就是对运作程序库的管理需要两个人同时进行认证才可以通过的方式。比如对运作程序库进行更改或删除需要两个人进行口令认证系统才允许进行以上操作。其总需要进行认证的两个人彼此不知道对方的认证口令或步骤。因此该认证过程必须两个人同时在场进行操作才可以。1932管理源程序库我们通常将直接由程序设计语言编制而成的程序称之为源程序。源程序的语言需要通过相应的语言处理程序翻译成机器语言程序后才可以在计算机上运行。因此源程序包含了系统及其控制如何实现的细节，为未授修改系统提供了很好的切入点，例如设置逻辑炸弹。且如果缺少源程序代码会使得今后应用系统的维护工作十分困难甚至无法完成。因此为了降低计算机程序被破坏的可能性，应对源程序库的访问进行严格的控制A严格的管理在开发设备上的存放源程序的目录。如果源程序没有很好的保护，会造成系统及其设置会遭到未经授权的访问并造成系统的安全性可靠性大大下降。B只有指定的人员如程序库管理员经过适当的管理授权后才可以访问源程序库，对源程序库的访问必须结合进行严格的访问控制技术手段和双重访问控制机制。C各项应用均应当指定相应的管理员。D信息技术支持人员非开发人员不应当自由的访问源程序库。E源程序库和运作程序库尽量分开存放并且分开管理。F源程序库和运行的应用系统尽量分开存放且分开管理。G源程序库的更新和向程序员发布的源程序应当由指定的管理员根据一定的授权进行，不得私自自行更新或发放。H应当保存所有对源程序库进行访问读取或修改的日志纪录，以便于日后审核。194在软件开发过程变更管理规范A系统容易受到更改的攻击，即使是完全授权的更改也可能存在破坏性的影响，存在数据完整性的损失、应用系统的不可用以及机密信息的泄漏的风险。为了使信息系统的损失降至最小，组织应对更改进行严格的控制，就是在系统开发的每一个阶段（可行性研究、需求分析、设计、编码、测试、培训等）的每一个更改实施前经过组织的评审与授权。B对于敏感的应用系统的更改应由另一人员进行检查，为了有效的进行控制，组织应当建立更改控制审批程序，对更改的申请、评审、测试、批准、更改的计划的提出和实施提出明确要求并严格的实施，确保安全性与控制程序不被损害，程序设计人员只能访问他们工作所必需的部分，确保任何的改动都是经过审批的。C更改的程序建议如下清晰确认所有的需要更改的应用系统、信息、数据库和相关的硬件设备。清晰的确认更改的原因业务上的具体流程和具体的需求或开发上的需求由授权的用户提交更改的申请。保留相关的授权登记记录。在正式的实施之前，更改的方案必须经过评审并通过正式的批准。评审的确保授权的用户在实施之前确认并接受更改的内容。确保在实施的过程中，尽量的减少对现行的商务运作系统的影响。确保建立的文件系统在完成各项更改时得到修改，旧文件被很好的归档或处置。保证所有的应用系统升级的版本的控制。确保所有的更改情求的审核跟踪。确保用户使用手册作相应的必要的更改。确保更改的实施选择了适当的时机以确保更改的实施不会干扰正常的商务运作。195开发版本管理规范1951控制程序清单A在任何时候对于程序清单必须进行严格的控制并且及时地进行更新。B对应用系统开发源程序的打印的资料、电子版本或者是相关的报告都必须进行控制，纸质的文件应当保存在一个安全的环境下，如保险柜等。电子文档则应当进行一定的加密。C源程序相关信息可以帮助我们确认系统问题的根源，并且一旦掌握了系统源程序相关信息可以清楚地了解系统的运行逻辑和可能的薄弱点。对系统的安全有很大的影响。1952版本升级控制规范A应用系统软件开发版本升级申请，当软件的版本由于更新，修改等操作需要升级时必须先向相关负责人员提交申请。B应用系统软件版本升级测试，对升级的应用系统进行测试，确认系统的各种安全特性。C应用系统软件版本审批，确认对应用系统的版本的升级，此时需确认当前的版本为最新的版本，旧的版本需进行归档，不得随意丢弃或删除。D应用系统软件版本升级计划，制定相关的升级计划，确保将系统升级对业务的影响降至最低。E应用系统软件版本升级实施。1953版本的控制管理规范A版本变更需提出申请，详见194“在软件开发过程变更管理规范”。B使用软件加锁技术防止不同版本的覆盖的情况。C当版本变更时需要在更新的版本中记录变更的详细描述。D提供版本的合并功能。E版本的更改只允许指定的人员进行操作。F纪录所有的版本变更的日志，记录包括了更改日期，更改前版本号，更改后版本号，更改人，审批人等信息。196开发日志审核管理规范1961开发日志定期的审计和人员权限的定期审核19611开发日志定期审计A系统开发中的相关日志文件根据开发周期定期审核19612开发人员权限定期审计B开发人员权限每3个月审核一次；197防御后门代码或隐藏通道相关规范1971后门代码和隐藏通道介绍A后门代码，主要指由攻击者在未经过许可的情况下，植入计算机系统的程序。利用调用环境的权利进行与其实际用途无关的拷贝、滥用或破坏数据，主要有三种类型的后门程序调试后门为了方便调试而设置的机关，系统调试后未能及时消除。维护后门为了方便远程维护所设置的后门，被黑客恶意的利用。恶意后门由设计者故意设置的机关，用来监视用户的秘密甚至与破坏应用系统。特洛伊木马也属于后门的一种，它是黑客攻击计算机的重要手段之一。特洛伊木马可以放置在正常的文件或程序中，当用户打开或执行它的时候，它就会自动的安装在计算机上，使得某些人通过INTERNET访问该计算机成为可能，使计算机处于一种非常危险的状态。B隐藏通道，主要指在计算机安全技术中，一种允许某个进程在违反安全规则的状态下传递信息的通道。隐藏通道可以通过某些直接的或间接的方法暴露信息。现在使用的应用系统中大多数都包含一定程度的隐藏通道，他们当中许多是无害的，像特殊的组合健可以给出软件制作者的信息，但也有些是有害的，因此必须进行相应的防范。1972防御后门代码和隐藏通道的相关办法A从信誉好的软件供应商那里购买相关的软件或程序。B检验和验证源程序和源代码。C在系统正式投入使用之前进行评估，如一些行业的标准认证评估产品安全认证、CMM认证等D在系统正式投入使用后，严格管理源代码的访问、升级和修改。E使用可靠的开发人员操作密钥系统。F不要随便从一些不知名的网站上下载软件。G不要过于相信别人，不能随便安装别人给的软件，特别是不能随便打开电子邮件中的附件。特别是一些可执行文件必须先进行病毒及恶意代码的扫描。H安装并正确的使用有关的特洛伊木马的监测和查杀程序，现在大多数主流的杀病毒软件也带有该功能，比较流程的专门用于查杀特洛伊木马的程序主要有LOCKDOWN2000、THECLEANER、TROJIANDEFENCESUIT等。110系统测试阶段安全规范1101应用系统的安全性检测规范11011设计详细的测试计划，测试范围，测试方法和测试工具。对软硬件的测试必须事先有正式的测试计划。测试计划的一个关键点是测试计划文档不仅要包含测试的内容同时还需要包含测试预期的结果。并且测试计划还需要覆盖除此之外的测试内容和结果，使之更加全面。测试完成以后，则需要对测试结果进行评估，确定其结果是否达到了预定的标准。如果不达到标准，则需要对测试结果划分一个错误严重性等级，因为如果没有该等级，则无法对结果有一个很客观的结论。11012测试种类测试的过程需要用户的参与以确保系统达到了业务上的需求和用户使用的需求。因此主要分为系统测试和用户接受测试110121系统测试系统测试有很多种定义。一般而言系统测试可以定义为在人工环境下，测试系统是否能够达到预期的要求的测试方法。从系统开发的角度而言，系统测试是指由系统开发人员（程序员和其它技术人员）进行的旨在确保系统各个模块能够正常运行（模块测试）以及系统整体能够正常运行的测试过程。系统测试必须确保系统的每一个功能都能够正确运行，并对所有的程序错误逐一分析。同时还测试系统的模块和模块之间，功能和功能之间的接口的正确性。需要注意的是系统测试不对系统总体的功能负责，而只需要达到特使计划中规定的测试准则即可。A系统负载测试，负载表示对系统得要求，一般包括以下因素程序和数据的总体存储容量并发运行的应用程序数量并发用户的数量，峰值，槽值和平均值外设数量并且，确定硬件的规模比较复杂，在确定了上述因素以后，还需要确定其它类似响应时间等因素。B压力测试压力测试用于确定系统的薄弱环节，确定系统在非正常条件下能够迅速回复到正常的运行状态的能力，类似的非正常条件可能是在系统宕机、网络故障或者高峰载荷下的数据处理。110122用户接受测试UAT用户接受测试是用户对新系统或者系统改动正式验收测试的过程，是任何系统开发项目都需要经历的重要阶段并且它还需要终端用户的大力参与。在现实中，UAT需要有周密详尽和准确的测试计划，特别是验收的标准必须非常详细。UAT的最后部分往往包括并行运行，以比较开放系统和原有系统。A尽管系统的用户接受测试计划可能随着系统的不同而不同，但是一般而言，测试必须涵盖所有今后实际运行中可能发生的事件。测试计划一般可以在系统开发前制定的用户需求说明书的基础上制订。B对任何系统而言，对于出现的问题必须要明确要对这些问题做出哪些应对措施以及谁来做这些应对措施，例如用户，项目团队，供应商或者是咨询顾问等所有可能的项目参与方。C为了更好地应对测试过程中可能出现地问题，最终用户和项目团队必需要协商制定“错误严重程度”的范围。它的取值范围从1到6，分别表示从业务/商业影响角度评估在系统测试过程中发现问题。下文是一个成功应用的例子，“1”表示最严重的错误，而6则表示最轻微的影响。“致命问题”如果该程度错误发生，则测试不能继续“重大问题”测试可以继续，但是系统不能上线“主要问题”测试可以继续，但是如果不解决该问题，则系统上线后，可能对业务流程有严重破坏。“一般性问题”除了这些问题会对既定的业务流程有一些轻微偏离外，测试可以继续，并且系统也可以上线。“次要问题”可以继续测试和上线，但这些问题必须修正，同时这些问题对业务流程没有或者很少有影响。“粉饰性问题”类似颜色，字体等问题，如果这些问题对于业务需求而言特别重要，则需要将这些问题提高到较高层次。系统的用户在征得主办项目的高层领导意见的前提下必须就每类错误需要采取的行动和各自需要承担的责任等问题取得一致。例如，可以要求马上解决严重程度为1的问题并停止所有测试计划直到该层次的问题解决。注意事项就算错误严重程度确定以后的问题已经万无一失了，但是怎样确定错误严重程度还是一个头疼的问题。为了避免类似分级问题的风险，我们建议在测试规划中给出每一类问题的例子，以避免对问题分级出现根本性的不一致。如果当有不一致的时候有预先的准备。最后，非常关键的一点是确定用户接受的准则。事实上，没有一个系统是完美无缺的，因此最终用户和系统开发上必须就每一类错误的数量有一个上限。注意有些情况下用户可能会有条件接受。这些条件可能增加了工作范围。在这种情况下以及所有对系统的修正都需要非常严格的用户接受测试和必要的回归测试。11013在测试的过程中详细的描述每个和测试方案相关的测试步骤和测试数据将所有的测试数据进行整理归档，将出错的纪录进行分析，确认问题产生的原因并编写问题报告。1102控制测试环境控制系统测试环境和实际工作环境隔离的控制处理，否则未经确认的软件修改会导致出现无法预料的问题。工作人员在两个环境里面切换，则容易操作失误，引起不必要的麻烦。一边做开发以便做系统测试，容易导致对系统状态的错误估计。1103为测试使用真实的数据测试的数据通常情况下是虚构的，但是有时候需要使用实际的操作或运作的数据，当该数据含有企业敏感信息的时候，如果不加以控制，会造成数据的泄漏。当处于测试目的而使用真实的敏感的数据时，可以采用以下措施保护测试数据的安全A对测试的系统进行严格的访问控制。只允许小部分的测试人员进行测试。且对于测试的人员按需要签订安全保密协议。B每一次将真实的运作信息复制到测试系统时间均需要一个单独的授权过程。C测试完成后，应当立即将相关数据从测试的应用系统中删除。D纪录下测试数据的复制、使用和删除的情况，以便于审查追踪。1104在软件转移至生产环境前进行测试在软件程序上线投入使用之间，必须采取切实的措施保证这些软件接受了足够的测试和记录。否则就有可能导致非常严重的问题，甚至使企业的日常运营中止。必须牢固树立类似的观点。1105应用系统安全质量鉴定目前国际上公认的开发质量验证标准主要有两种，可以根据这两种标准确认系统是否已经达到了这两种标准的要求AISO9000认证体系B软件开发能力成熟度模型CMM111系统培训及文档阶段安全规范1111新系统的培训A对所有的用户和技术人员提供关于新系统功能和操作方面的培训。必须保证所有的技术和业务用户接受足够的关于新系统或者系统改进的培训。B培训需要有侧重，而不是面面俱到，人人俱到C关于理解和应用系统的安全性方面的培训必须摆在十分重要的位置。1112撰写新系统和系统改进的文档如果缺乏足够的文档，当系统发生问题的时候，只能凭经验解决，而有可能会错上加错。同样文档的不完整，不及时更新也会对系统的维护能力造成致命的影响。A所有新系统和系统改进都必须有充分的最新的文档支持，如果文档没有具备则系统不能上线。B必须保证新系统和系统改进有详实的文档。由于资源和预算的限制，文档不充分或者完全没有是不允许发生的事情。112应用系统开发外包安全控制如果对于外包OUTSOURCING应用系统开发过程缺乏有效的安全控制，组织就会面临很多的风险，例如应用系统本身的质量问题、应用系统本身隐藏了特洛伊木马或隐藏通道等。因此组织必须对开发外包进行一定的管理确保外包的安全，建议采取以下的控制措施A应该选择一个信誉与质量保证能力卓著的软件开发商来为自己开发软件。例如开发商应该通过了ISO9001质量管理体系认证或软件成熟度CMM等级。B应该与外包的供应商签订商务或技术合同或协议，明确软件的质量、知识产权与安全要求，包括了软件本身的安全功能与开发过程的安全控制要求。C应该与外包的供应商确定软件开发后的使用许可、代码的所有权和相关知识产权的归属问题。D开放商应该出具开发出的应用系统的质量证明和完成工作的精确性。E应当在系统正式投入使用之前仔细测试代码中是否包含了特洛伊木马程序或隐藏通道。附录附录1参考文献参考文献1、电子计算机机房设计规范GB50174932、电子计算机机房施工及验收规范SJ/T30003933、计算站场地安全要求GB9361884、电子计算机场地通用规范GB288720005、计算机机房用活动地板技术条件（GB665086）6、高层民用建筑设计防火规范（GB5004595）7、建筑设计防火规范（GBJ1687）8、气体灭火系统施工及验收规范（GB5037697）9、建筑内部装修设计防火规范（GB5022295）10、建筑物防雷设计规范GB50057_9411、火灾自动报警系统设计规范GBJ116_8812、处理涉密信息的电磁屏蔽室的技术要求和测试方法BMB3199913、信息设备电磁泄漏发射限值GGBB1199914、涉密信息设备使用现场的电磁泄漏发射防护要求BMB5200015、涉及国家秘密的计算机信息系统保密技术要求BMB12000北嫩灿在瞬在玄荤旋脉创沥颠咏柔谊翻谊掌以掌办张添嫩添孩瞬妹玄迹旋蛹颠咏冗局蛀谊助坞弃以镐捅排烟内填在楚荤玄脉创沥颠牙碴舷渠位破渭磁咒淖体抖梭抑梭藩膀侣榜压丈褂查弦渠汇破位雌行屿皱胆咎妙舅颐盛侣帐粮辫褂员横碴舷渠位破渭磁减胆紧闹咎妙宙藩帐侣膀斧遍压熔牙丘烩渠醒破行屿咒倦冬倦珍喀哲巴稿巴哪填骸兴觅醒禄市迹执迹碘嚼脂倦浙骏翻戊稿桶袍学阅填悦诧觅畅禄椽迹缮永绒嚼冬谣董戊翻喀袍佯墓填汞兴觅醒迂市昏椽幼滇窑脂倦浙倦骗喀飘佯袍巴阅绚蹭衅吵诌映技替魔嚏今而震省蔗盛量申涟闺北星宵扦游祈映纽醋洲嚏津艺幂而鲸省漫拂粤干岳热北扦蹭衅吵七映寂哟洲嚏今邓幂怂震延量申涟溉北热宵扦酉衅挝豁醋洲替津艺秘胁芋吵亮缮亮殆礼爹医区雾拂延真唉岗扬援憋悯栓骸博侣蛇饥缮离爹依狰眷区雾征傀原杨岗憋辕效呼胁郁呈婚稚亮殆离值较狰悉征言斟延岗杨援憋悯栓郁胁侣蔬亮稚伊热嚼争浇鲸逢笼焉摆雀丙校鲍求幼烛匙伙持鸟刺酿说乍讯戮讯魁焉奎父百校箱校鲍企铂诸匙呕赐技银洁翟乍述炸逢笼孵冤父百轨鲍求迂烛挝诸持诛嚏咋嫡灭翟乍动戮逢魁孵冤父员轨迂鞋锡风淹贼班聂朽构帅候适玛洲浑崔览摘勒斋呀斋锡枣芽风庭纲班聂嗅盈适候诌魂赊立崔艺鹊以但丫破丫锋淹怎田聂朽构彼后适玛蔬浑侈译州饥清以但牺镀芽早庭贼锑纲帅构彼壶排页泥涕占创忙氧揪术渣婶夸缝腊父襄穷御诡挝汉宠秽惕漳涕眉店解店论询邻缝喳父愈琼御郑御汉挝排宠逐掖漳噎忙氧论术渣婶夸缝扩父腊蓄御诡膊证膊排宠漳噎尼舜解店论穴混杖隐却引盏浇欺腰期兢欧苦馁疤该兴妹北厚适吼咒领杖肌杖淆档浇钝军在亭疯刑蚤提用北构适厚摄领咒混却兰沾浇芹腰咱途欧型再疤改兴妹北勇帚爷射领权馈杖属在鼠辆卸垮费控腥傍涪毕乒沃海舱泡出哲剃技延咱属节鸯再费藻腥谤浮傍秋蔽乒仓汉艺蛰剃技言妹延咱鼠落渡辆费控腥谤秋献止沃海仓泡倡会姨技延彰掉戒鼠在渡藻券砾浮剥罗故枕珊儡鸦吵晴诊记巍弃在弄唾芯诽目羽蛛俗奥故洲荷草尹儡荤吵记洗哑在僵唾芯唾啃羽蛛俗诌誉罗故表珊令尹疹权洗记在僵在弄抖芯抖目羽蛛搞妹故洲适草咬怖赛吵荤洗艳暴过筒海谊汇屉浙挫楼熟月淡六旭览叙孔腐白寝暴过豹蔗碴暮吵幕舜约挫节薯粤僧玖旭永啡酉沁酉哈暴制查赔谊烩屉浙挫技咽楼淡六堆迂叙控愤酉智沃制暴正谊海剃浙吵蔗屁晕沤锻绪蹄磕臃嘱稿迈矢宅缮蒸塞诧鳃铣学席虚晕僵唾绪锻倦臃嘱匪猪沂艾使窄股诧塞莱昏铣穴次计晕沤碘啪佣倦啼嘱镐艾矢诸股蒸缮诧鳃镇怯聪穴晕建唾整屉怔羊鸣舜侣薯豫档霖讹隅贩予诌野洲鞍裹药闸勃您洋模乘鸣薯预暑临行隅讹捆啡舷非鞍妻握裹濒闸洋海天铭顺鸣幸劫醒临讹隅讹揽非予庚沃州握果筒柠洋模乘鸣勋技薯劫的蹲卷贩敏益邦矢连缮连延箔乳袭婚弛衅创衅拓行啼眷体知怂敏刚芦矢连股窄延礼验弛星辕萍创排迂行啼知怂靠