安全生产_中国石油天然气公司开发安全管理通则

中国石油信息安全标准 编号： 中国石油天然气股份有限公司 应用系统开发安全管理通则 中国石油天然股份有限公司 前 言 随着中国石油天然气股份有限公司（以下简称“中国石油” ）信息化建设的稳步推进，信息安全日 益受到中国石油的广泛关注， 本规范是依据中国石油信息安全的现状，参照国际、国内和行业相关技术标准及规范，结合中国 石油自身的应用特点，制定的适合于中国石油信息安全的标准与规范。目标在于通过在中国石油范围 内建立信息安全相关标准与规范，提高中国石油信息安全的技术和管理能力。 信息技术安全总体框架如下： 区区 域域 安安 全全 管管 理理 规规 范范 机机 房房 安安 全全 管管 理理 规规 范范 硬硬 件件 设设 备备 管管 理理 规规 范范 网网络络安安全全 管管理理规规范范 通通用用安安全全管管 理理标标准准 数数 据据 和和 文文 档档 安安 全全 管管 理理 规规 范范 应应 用用 系系 统统 使使 用用 安安 全全 管管 理理 标标 准准 通通 则则 应应 用用 系系 统统 开开 发发 安安 全全 管管 理理 标标 准准 通通 则则 商商 业业 软软 件件 购购 买买 管管 理理 标标 准准 电电 子子 邮邮 件件 安安 全全 管管 理理 规规 范范 W We eb b系系 统统 安安 全全 管管 理理 规规 范范 电电 子子 商商 务务 安安 全全 规规 范范 防防 御御 恶恶 意意 代代 码码 和和 计计 算算 机机 犯犯 罪罪 管管 理理 规规 范范 信信息息安安全全技技术术标标准准 物理环境 安全管理 硬件设备 安全管理 操作系统 安全管理 数据和文档 安全管理 应用系统安 全管理 网 络 安 全 管 理 概 述 通 用 网 络 安 全 管 理 规 范 内 部 网 络 安 全 管 理 规 范 外 部 网 络 安 全 管 理 规 范 认 证 管 理 通 用 标 准 通 用 安 全 管 理 标 准 概 述 授 权 管 理 通 用 标 准 加 固 管 理 通 用 标 准 加 密 管 理 通 用 标 准 日 志 管 理 通 用 标 准 系 统 登 陆 管 理 通 用 标 准 操操 作作 系系 统统 安安 全全 管管 理理 规规 范范 1） 整体信息技术安全架构从逻辑上共分为 7 个部分，分别为：物理环境、硬件设备、网络、操 作系统、数据和文档、应用系统和通用安全管理标准。图中带阴影的方框中带书名号的为单 独成册的部分，共有 13 本规范和 1 本通用标准 。 2） 对于 13 个规范中具有一定共性的内容我们整理出了 7 个标准横向贯穿整个架构，这 7 个标准的组合也依据了信息安全生命周期的理论模型。每个标准都会对所有的 规范中相关涉及到的内容产生指导作用，但每个标准应用在不同的规范中又会 有相应不同的具体的内容。我们在行文上将这 7 个标准组合成一本通用安全管理标准单 独成册。 3） 全文以信息安全生命周期的方法论作为基本指导， 规范和标准的内容基本都根据预防 保护检测跟踪响应恢复的理论基础行文。 本通则讨论了在企业内部自行开发一套应用系统或外包开发所必须考虑到的几个步骤，开发应用 系统的安全性考虑就好像建设楼房一样，拥有越坚固的地基楼房越是稳定，因此应用系统在开发阶段 打好坚实的安全基础，那么以后的日常维护工作就会很轻松。以下我们主要从系统开发的各个阶段入 手，考虑在标准的开发流程的各个阶段中要注意的安全方面的考虑。 本规范由中国石油天然气股份有限公司发布。 本规范由中国石油天然气股份有限公司科技与信息管理部归口管理解释。 起草部门：中国石油制定信息安全政策与标准项目组。 说 明 在中国石油信息安全标准中涉及以下概念： 组织机构 中国石油（PetroChina） 指中国石油天然气股份有限公司有时也称“股份公司” 。 集团公司（CNPC） 指中国石油天然气集团公司有时也称“存续公司” 。为区分中国石油的地区 公司和集团公司下属单位，担提及“存续部分”时指集团公司下属的单位。如：辽河油田分公司存续 部分指集团公司下属的辽河石油管理局。 计算机网络 中国石油信息网（PetroChinaNet） 指中国石油范围内的计算机网络系统。中国石油信息网是 在中国石油天然气集团公司网络的基础上，进行扩充与提高所形成的连接中国石油所属各个单位计算 机局域网和园区网。 集团公司网络（CNPCNet） 指集团公司所属范围内的网络。中国石油的一些地区公司是和集团 公司下属的单位共用一个计算机网络，当提及“存续公司网络”时，指存续公司使用的网络部分。 主干网 是从中国石油总部连接到各个下属各地区公司的网络部分，包括中国石油总部局域网、 各个二级局域网（或园区网）和连接这些网络的专线远程信道。有些单位通过拨号线路连接到中国石 油总部，不是利用专线，这样的单位和所使用的远程信道不属于中国石油专用网主干网组成部分。 地区网 地区公司网络和所属单位网络的总和。这些局域网或园区网互相连接所使用的远程信道 可以是专线，也可以是拨号线路。 局域网与园区网 局域网通常指，在一座建筑中利用局域网技术和设备建设的高速网络。园区网 是在一个园区（例如大学校园、管理局基地等）内多座建筑内的多个局域网，利用高速信道互相连接 起来所构成的网络。园区网所利用的设备、运行的网络协议、网络传输速度基本相同于局域网。局域 网和园区网通常都是用户自己建设的。局域网和园区网与广域网不同，广域网不仅覆盖范围广，所利 用的设备、运行的协议、传送速率都与局域网和园区网不同。传输信息的信道通常都是电信部门建设 的。 二级单位网络 指地区公司下属单位的网络的总和，可能是局域网，也可能是园区网。 专线与拨号线路 从连通性划分的两大类网络远程信道。专线，指数字电路、帧中继、DDN 和 ATM 等经常保持连通状态的信道；拨号线路，指只在传送信息时才建立连接的信道，如电话拨号线路 或 ISDN 拨号线路。这些远程信道可能用来连接不同地区的局域网或园区网，也可能用于连接单台计 算机。 石油专网与公网 石油专业电信网和公共电信网的简称。 最后一公里问题 建设广域网时，用户局域网或园区网连接附近电信部门信道的最后一段距离的 连接问题。这段距离通常小于一公里，但也有大于一公里的情况。为简便，同称为最后一公里问题。 涉及计算机网络的术语和定义请参见中国石油局域网标准 。 目目 录录 1.1概述 .3 1.2目标 .3 1.3规范的使用范围 .4 1.4规范引用的文件或标准 .5 1.5术语和定义 .6 1.6应用系统开发总体原则 .7 1.7系统需求收集和分析阶段安全规范 .8 1.7.1可行性研究分析 .8 1.7.2开发人员安全管理机制 .10 1.7.3建立系统开发安全需求分析报告 .11 1.8系统设计阶段的安全规范 12 1.8.1单点访问控制，无后门。 .12 1.8.2人员职责和权限的定义 .12 1.8.3确保敏感系统的安全性 .12 1.8.4确保访问层的安全性 .12 1.8.5确保日志管理机制健全 .12 1.8.6新系统的容量规划 .13 1.9系统开发阶段安全规范 14 1.9.1系统开发语言安全规范 .14 1.9.2系统开发安全相关工具管理规范 .19 1.9.3控制软件代码程序库 .21 1.9.4在软件开发过程变更管理规范 .23 1.9.5开发版本管理规范 .24 1.9.6开发日志审核管理规范 .25 1.9.7防御后门代码或隐藏通道相关规范25 1.10系统测试阶段安全规范 27 1.10.1应用系统的安全性检测规范 .27 1.10.2控制测试环境 .29 1.10.3为测试使用真实的数据 .29 1.10.4在软件转移至生产环境前进行测试 .29 1.10.5应用系统安全质量鉴定 .30 1.11系统培训及文档阶段安全规范 31 1.11.1新系统的培训 .31 1.11.2撰写新系统和系统改进的文档 .31 1.12应用系统开发外包安全控制 32 附录附录 1参考文献参考文献 .33 应用系统开发安全管理通则应用系统开发安全管理通则应用系统开发安全管理通则 1.1概述 信息系统的许多的安全控制或者是安全性是通过系统的开发设计予以实现的。因此如 果在系统的开发设计阶段没有对系统的安全性给予充分的考虑，那么系统本身一定会 存在许多先天不足，系统就会漏洞百出。为了确保应用系统的安全，在应用系统开发 之前就应当对系统的安全要求有所确认，并作为开发设计的阶段的基础予以落实。 本规范主要规定了在系统开发的各个阶段需要的各种安全规范，从可行性分析需求分 析阶段开始，到设计阶段，再到开发阶段和维护阶段以及最后的文档阶段的系统开发 的各个阶段进行阐述。将不同阶段下需要注意的安全问题和相关的安全规范进一步进 行描述和规定。 1.2目标 本规范的目标为： 保护应用系统开发过程中的安全。具体地说就是保护应用系统开发过程中免受未经授 权的访问和更改，保护系统开发中系统软件和信息的安全，确保开发项目的顺利正确 的实施并对开发环境进行严格的控制。同时确保应用系统开发外包中的各项安全。 从而进一步保障中国石油业务的持续运营，保护中国石油信息资产安全，即保护软件 及信息的完整性，维护信息处理设备及通讯服务的完整性及可用性，确保设备中的信 息及相关基础建设的安全，确保正确、安全操作信息处理设备，降低系统故障风险。 总而言之，要防止对中国石油经营环境及信息的未经授权存取、破坏或干扰；防止中 国信息资产受损及企业运营受影响；防止信息及信息处理设备泄露及被偷窃。 1.3规范的使用范围 该套规范适用的范围包括了整个应用系统开发过程中的安全整个应用系统开发过程中的安全。包括了系统开发可行性 和需求分析阶段的安全，系统设计阶段的安全，系统开发阶段的安全，系统测试阶段 的安全，系统培训和文档阶段的安全以及系统开发外包的安全规范。 主要规定了应用系统开发过程的安全保密，软件的质量的要求，系统和业务需求的符 合性，保证敏感信息的安全，系统本身的稳定性和兼容性问题。 1.4规范引用的文件或标准 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是不注日期的引用文件， 其最新版本适用于本标准。 1.建筑设计防火规范 （GBJ16-87） 2.高层民用建筑设计防火规范 （GB50045-97） 3.建筑内部装修设计防火规范 （GB50222_95） 4.建筑防雷设计规范 （GB50057） 1.5术语和定义 1.6应用系统开发总体原则 应用系统的开发应当遵循一系列的总体原则，以确保开发过程中的安全。其中包括： a)系统开发需得到公司领导层的重视和参与。需要领导层组织开发力量，协调各方系统开发需得到公司领导层的重视和参与。需要领导层组织开发力量，协调各方 关系并在开发的过程中提供决策性的意见和建议。关系并在开发的过程中提供决策性的意见和建议。 b) 系统开发应当从业务需求得角度出发，不得盲目追求系统先进性而忽略了系统的系统开发应当从业务需求得角度出发，不得盲目追求系统先进性而忽略了系统的 实用性。系统的开发是为了更高的满足业务上的需要，而不是技术上的需要。实用性。系统的开发是为了更高的满足业务上的需要，而不是技术上的需要。 c)开发的方法和管理必须规范化、合理化、制度化。只有采用了规范化合理化制度开发的方法和管理必须规范化、合理化、制度化。只有采用了规范化合理化制度 化的开发管理方法，才能确保开发的质量和进度。化的开发管理方法，才能确保开发的质量和进度。 d) 保证开发的进度和按时完成。确保开发工作及时、有效且高质量的完成。保证开发的进度和按时完成。确保开发工作及时、有效且高质量的完成。 e)系统开发必须具有一定的前瞻性，符合主流系统的发展方向。系统开发必须具有一定的前瞻性，符合主流系统的发展方向。 f)开发人员安全意识的提高和加强。确保机密信息和关键技术不会泄漏，特别是泄开发人员安全意识的提高和加强。确保机密信息和关键技术不会泄漏，特别是泄 漏到竞争对手的手中，将会对公司的竞争力产生极大的影响。漏到竞争对手的手中，将会对公司的竞争力产生极大的影响。 g)充分利用现有的资源。充分利用现有的资源。 1.7系统需求收集和分析阶段安全规范 1.7.1可行性研究分析 对于应用系统开发项目需要进行一定的可行性分析，确认在开发工作具备了的相 当资源和条件，并且有能力满足业务上的需求的情况下才能开展，切忌盲目开发。 既浪费了资源，又浪费了时间。 可行性研究可以从技术方面，需求方面，投入方面和影响方面进行考虑： 技术可行性分析 根据业务上提出的需求，从技术开发的角度分析是否现有的技术手段和技术能 力是否可以达到业务上要求的系统功能。通常可以从三个方面进行分析： a)人员技术能力分析，指公司内的系统开发队伍是否有足够的软件开发的 技术能力来完成系统开发的任务，或第三方外包的开发公司是否具有开 发应用系统的技术能力。 b)计算机软件和硬件分析，指公司现有的软件和硬件的性能是否足够满足 开发相应的系统的要求。 c)管理能力分析，指现有的技术开发管理制度和管理流程是否成熟且标准 化，是否足够系统开发的要求。 需求可行性分析 系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断 需求是否明确，是否符合实际而不是天马行空式的空谈，是否是在一定的时间 范围内可实现的。 投资可行性分析 根据业务需求和技术手段的分析，确认根据业务需求和技术手段需要多少的投 资才可以实现，确认投资的数额是不是在可控制和可承受的范围内。 影响可行性分析 所谓的影响是指社会影响，比如系统开发是否符合法律法规上的要求，是否和 相关的管理制度或行业标准相抵触，是否不符合人文或道德上的约束等等。 1.7.2开发人员安全管理机制 系统开发人员职责分配管理规范 在系统开发的过程中，应当明确不同的人员的身份、职责。我们建议在系统开 发过程中具体分以下的三种角色： 项目负责人员：确保在整个系统开发的各个阶段都实施了相关的安全措施， 同时在整个系统开发的过程中负责整个项目的开发安全管理。 系统开发人员：根据业务需求确保开发的系统能够满足业务上的需求和相 应的安全上的需求，同时满足系统质量上和进度上的要求。 系统审核人员：对整个开发的过程进行审核和监督，确保开发的质量和开 发的安全。 开发人员授权管理规范 a)根据该员工在整个开发项目中所负责的开发内容授予其相应的权限和承 担的责任。 b)开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄 漏出去，即使是家人或开发团队中的其他开发人员也不得泄漏。但开发 人员有责任将开发的相关信息告诉项目的负责人员或开发小组的负责人 员。 c)以书面的方式将员工的权限和相应的责任提交给员工本人。必须严格规 定在为企业工作期间的所有和工作相关的开发成果的所属权都归企业所 有。 d)根据员工权限和责任的大小确认是否需要签署相关的保密协议。 e)在日常工作中记录员工的开发相关的日志信息。 f)员工一旦离职或调动岗位应立即收回或调整其相应的权限。 开发人员必须训练开发安全代码的能力 a)开发人员应该有能力防止开发过程中的缓冲器溢出错误“buffer over flow attacks” 。 b)在整个开发的过程中必须完整的持续的进行代码错误处理所规定的流程。 c)错误问题报告应该越通俗越好，不应该在其中包含任何系统细节问题。 d)应该对重要的敏感信息进行加密的保护。 e)应该使用一些相对复杂的加密和密钥生成机制。 f)应该单独编写安全性设计说明概要 分离系统开发和运作维护 管理层必须要确保应用系统开发和应用系统运作管理从组织人事和权限职责上 必须分开。尽管只有大型企业才有独立的系统运行和系统开发部门，但是把这 些功能分开毫无疑问是非常必要的。职责的分开对于大多数信息安全保护来说 至关重要。 a)IT 人员可以现场修复或者更改偶然的或者是恶意的数据和软件的问题。 b)测试代码中往往包含调试或者查错代码，大大加大了主机系统的性能负 担。 c)开发人员常常具有很高的权限，这在运行系统中会产生很大的风险，所 以是不可接收的。 1.7.3建立系统开发安全需求分析报告 a)安全需求计划应该能够达到期望的安全安全水平。其中包括了成本的预估， 完成各个安全相关流程所需的时间。 b) 所有的有关应用系统的更新或改进都必须是基于业务需求的，并且是有业务 事件支持的。这里的业务需求不仅仅包括了系统的功能、性能、开发费用、 开发周期等内容，还要明确系统的安全要求。应用系统的任何一次改进或更 新都和该业务系统的所有者密切相关。 c)一个安全开发需求分析计划应该由开发项目经理和公司内部安全小组共同商 议决定。 d) 确保每一个应用系统的用户都意识到系统的更新或改进都和他们本身密切相 关，所有的更新或改动的建议都必须是由业务需求出发的而不是从所谓的 “信息技术的要求”。 e) 系统的每一次更新或改进都必须认真的对待，必须进行详细的需求定义、需 求分析以及测试评估以保证不会对业务造成任何的影响。 f)业务需求是系统更新和改动的基础，因此必须清晰明确的定义业务的需求， 绝对不允许在业务需求未经过业务部门领导和主要负责人员的认可的情况下， 盲目的进行开发工作。 1.8系统设计阶段的安全规范 1.8.1单点访问控制，无后门。 任何用户如果希望访问应用系统中的某一个部分，则必须通过统一的且唯一的认 证授权方式以及流程。 1.8.2人员职责和权限的定义 由于不是所有的人员对于某一个应用系统都具有同样的访问或使用的权限，因此 系统必须具有基于人员职责的用户授权管理以确保每个用户可以访问到其权利范 围内的应用系统部分。同样的，也要确保每个用户无法访问其权限范围以外的应 用系统部分。 1.8.3确保敏感系统的安全性 通过将应用系统中敏感的信息保存在服务器端以进行集中的加密的安全管理，确 保客户端系统本身并不能存储任何信息敏感的数据。 1.8.4确保访问层的安全性 应用系统不仅仅要确保系统模块本身的安全性，同时也要考虑模块与模块之间的 通讯的安全性。这种模块与模块之间的安全性不仅仅包括了应用系统内部模块之 间的安全，也包括了应用系统内部模块和外部模块之间的安全性，如主机和客户 端之间通讯的安全性。服务器和服务器间通讯的安全性，本地系统和异地系统之 间通讯的安全性。 1.8.5确保日志管理机制健全 要求建立可以根据情况自由设置的日志管理机制，也就是说日志纪录的范围和 详细程度可以根据需求自行定制，且可以实现在应用系统使用过程中进行日志 的定制和记录。保留所有系统开发相关的程序库的更新审核纪录。 1.8.6新系统的容量规划 容量规划是指确定系统的总体规模，性能和系统弹性。容量规划的具体内容可能 有所不同，但一般需要考虑以下方面： a)系统的预期存储容量和在给定的周期里面获取生成和存储的数据量。 b)在线进程的数量和估计可能的占用资料 c)对于系统和网络的相应时间和性能，即端对端系统 d)系统弹性要求和设计使用率-峰值，槽值和平均值等 e)安全措施例如加密解密数据对系统的影响。 f)24x7 运作要求和可接受的系统宕机次数（维护或者设备更新导致的必须 性宕机） 规划容量的时候关于系统使用的信息了解得越多越好。近来，由于互联网站得使 用以指数形式增长，容量规划变动效果不是非常显著，有时甚至毫无用处。原因 在于很难估计实际的负载。在容量估计的时候需要尽量将情况设想得复杂一些。 1.9系统开发阶段安全规范 1.9.1系统开发语言安全规范 程序员可以使用很多指导规范来防止应用程序中的普通的安全问题。其中许多可 以应用于任何一个编程语言，但某些是针对特定的语言的。特定语言的指导规范 主要集中在 Perl，Java 和 C/C+语言。大多数情况下，一般的错误可以通过下功 夫或者对基本的问题有很好的理解来避免。这些本可以避免的错误常常会导致很 多安全漏洞，从而威胁信息的保密性、完整性和可用性。 通用规范 .1输入验证 在客户机/服务器环境下，进行服务端的验证而不是客户端的验证（例如 基于 Javascript 的验证）。通过在客户端和服务器之间放置一个代理服务 器，可以很容易绕过客户端验证。有了代理服务器，攻击者可以在数据被 客户端“验证”后修改数据（与“man-in-the-middle”攻击类似）。 在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后 检查每个数据的字符是否在有效范围内。如果输入中包含无效的字符，应 用程序应该返回错误页面并说明输入中包含无效字符。这样进行验证的原 因是定义无效的字符集比较困难，并且一些不应该有效的字符通常不会被 指出。 另外，边界检查（例如字符串的最大长度）应该在字符有效性检查以前进 行。边界分析可以防止大多数缓冲区溢出漏洞。 必须提到的是从环境变量获得的数据也需要进行验证。同时避免在环境变 量中存放敏感数据（例如密码）。某些 Unix 系统（例如 FreeBSD）包含 ps 命令，可以让用户看到任何当前进程的环境变量，这常常会暴露保密性 信息。 .2SQL语句 如果应用程序需要连接后端数据库，使用存储过程而不要在代码中使用 SQL 语句。使用程序以外的嵌入在代码中的 SQL 语句调用特别危险。难 以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式 的 SQL 攻击。当然，输入验证有助于缓解这种风险。 .3注释代码(commented code) 当应用程序在实际环境中开始应用时，应该删除所有的注释代码。注释代 码是用来调试或者测试的，它们不是最终应用程序的一部分。无论如何应 该在实际的环境中删除它们来避免意外的执行（一般注释标识被删除后就 无法激活休眠的代码，但还是存在可能性的，所以强烈建议执行这项工作） 。 .4错误消息 所有为用户显示的错误信息都不应该暴露任何关于系统、网络或应用程序的 敏感信息。如果可能的话，最好使用包含编号的一般的错误信息，这种信息 只有开发者和/或支持小组才能理解。一般的错误信息的例子是“发生了错误 （代码 1234） ，请您与系统维护部门联系。 ” .5URL内容 对于 web 应用，不要在 URL 上暴露任何重要信息，例如密码、服务器名称、 IP 地址或者文件系统路径（暴露了 web 服务器的目录结构） 。这些信息可以 在攻击时使用。例如下面就是一个不安全的 URL： /index.cgi?username=USER system(buffer); 在以上的例子中，可以通过使用分号利用文件名变量在 sehll 中插入额外的 命令（例如文件名可以是/etc/hosts; rm *，这将在显示/etc/hosts 目录文件的 同时，删除目录中的所有文件。）。 而 exec()函数只保证第一个参数被执行： execl(“usr/bin/emacs“, “usr/bin/emacs“, filename, NULL); 上面的例子保证文件名仅仅作为一个参数输入 Emacs 工具，。同样它在 Emacs 命令中使用完全的路径而不是使用可以被攻击者利用的 PATH 环境 变量。 .4竞争条件（race condition） 进程需要访问资源时（无论是磁盘、内存或是文件）通常需要执行两个步 骤： (1) 首先测试资源是否空闲可用 (2) 如果可用，就访问该资源，否则它等到资源不再使用为止再去访问它 当另一个进程在步骤 1 和 2 之间想要访问同一个资源时就出现问题了。这 会导致不可预测的结果。进程可能会被锁定，或者一个进程籍此获得了另 一个进程的较大的权限而导致安全问题。攻击主要集中在有较大权限的程 序上（称为 setuid 程序）。竞争条件攻击通常利用程序执行时可以访问到 的资源。另外权限低的程序也存在安全风险，因为攻击者可能会等待有较 高权限的用户执行那个程序(例如 root)，然后进行攻击。 下面的建议有助于缓解竞争条件(race condition)攻击： 在进行文件操作时，利用那些使用文件描述符的函数而不要使用那些使用 文件路径的函数（例如使用 fdopen()而不要使用 fopen()）。文件描述符使 得恶意的用户在文件打开时或是在原始的进程对文件进行操作前，无法使 用文件连接（符号式的或是物理的）来改变文件。 在写文件甚至在读文件时使用 fcntl()和 flock()函数来对文件加锁，这样它 们就不能被其他进程访问。它几乎可以建立原子级的操作。 谨慎操纵零时文件，因为它往往会导致竞争条件。 .5检验有效的返回值 检验有效的返回值非常重要。一个例子是旧的/bin/login 的实现中不检验错 误的返回值，导致当它找不到/etc/passwd 文件时返回 root 的访问权限。如 果该文件损坏了，那么这种情况是合理的，但如果该文件存在只是无法访 问，那么这就是一个大问题。 1.9.2系统开发安全相关工具管理规范 有许多方法来确保代码符合一定的安全级别。正如前面指出的，最好的方法之一 是让尽可能多的人来检查代码（而不是在 QA 环境中实际进行白箱或者黑箱测试） 。然而，有时代码在开始实际环境的应用前往往没有足够的时间，并且即使检查 代码也会漏掉一些不容易发现的错误。这些错误可能会对整个系统导致重大的安 全问题。因此（以及其他的原因），使用源码分析工具(Source Code Analysis Tool(SCAT)来自动进行某些检查过程很有帮助。本文介绍了一些这方面的工具。 每个工具都用同样的测试工具来检验，这些测试工具包含 C 和 Java 的代码段， 而这些代码段存在潜在的安全错误。我们比较了每个工具的测试结果，并且仔细 检查了以下的属性： a)灵活性 有多种选项并能扫描多种类型的代码的工具得分会较高 b)正确性 主要目标是发现正确的安全问题，并且不会出现大量的误报 信息，或者更糟的是没有发现真正的错误信息。 c)容易使用 大多数情况下，程序员只需要将工具指定到特定的代码上 然后选择“扫描”。除非特别需要，程序员一般只做抽样检查，而无需 开发复杂的测试机制。 d)报表 扫描结果应该以一种容易理解的格式来显示，并且最好同时提 示修改每个问题的方法，并附加理由。 每个工具在解析代码上的速度可以忽略不计，所以没有进行比较（虽然这并 不包括配置扫描的时间，而 MOPS 在这方面相对于其他工具需要更多的时间） 。另外，这些工具都可以免费获得，甚至可以获得它们的源代码，所以不需 考虑它们的成本。 工具一：PScan Pscan 是一个有针对性的扫描程序，主要用于发现 C 程序中的缓冲区溢出和格 式化字符串攻击。该程序检查所有用到标准 C 程序库中的 printf()函数。 sprintf(buffer, variable); printf(buffer, variable); 关于这些语句在缓冲区溢出和格式化字符串攻击中怎样被利用可以查阅相关的 C 和 C+文档。Pscan 的一个不足是不能发现由于越界检查不充分而引起的常 规性缓冲区溢出。不过 Pscan 对于缓冲区溢出和格式化字符串攻击的定位还是 相当精准和快速的。Pscan 程序相对简单，它只将结果返回都标准输出，当然 也可以将其输出到文件，并且除了说明程序员应该怎样修正错误以外不给出语 句为什么出错等类似的信息。该工具一个显著的特点是可以同时扫描多个文件。 总体而言 Pscan 程序相对简单，易于使用，同时针对性很强，但是由于它能够 适用的范围过于狭窄因此一般不推荐其在大型商业应用中使用，而只是检查一 些相对简单的程序片断。 工具二：Flawfinder Flawfinder 是一个分析 C 程序安全隐患的静态分析工具。和 Pscan 类似，该程 序可以发现很多种类型的错误，除了 printf()和标准的字符串函数，它还可以 发现竞争条件和系统调用。Flawfinder 相比较 Pscan，它返回的错误信息要丰 富很多，并且也更加详细。而这对于程序员来说非常重要。Flawfinder 甚至可 以对程序中的弱点进行分类，例如 buffer 弱点、格式弱点、shell 弱点等。 总之，Flawofinder 是一个相当出色的 C 程序检查工具，速度会，界面友好， 返回信息丰富，安装使用相对简单。该工具是检查不同规模的应用程序的首选， 唯一不足的是它只能用于 C 程序的检查。 1.9.3控制软件代码程序库 管理运作程序库 我们通常将用于系统开发的开发软件工具和开发平台称之为运作程序，因此为 了降低计算机程序被破坏的可能性，应对运作程序库的访问进行严格的控制： a)严格的管理在开发设备上的存放开发运作程序的目录。如果开发运作程 序没有很好的保护，会造成系统及其设置会遭到未经授权的访问并造成 系统的安全性可靠性大大下降。 b)只有指定的人员如程序库管理员经过适当的管理授权后才可以访问运作 程序库，对运作程序库的访问必须结合进行严格的访问控制技术手段和 双重访问控制机制。 .1严格的访问控制可以通过以下规定实现： a)严格管理开发部门所在区域的安全保安管理，防止未经授权的人进入开 发区域。 b)严格管理开发用途的计算机使用，只有指定的人员才可以访问开发用的 计算机设备。 c)严格管理开发运作系统的认证管理，建立严格的基于人员职责的授权等 级制度，用口令或其他身份识别技术确认访问者身份。 .2建立双重访问控制机制 双重访问控制机制就是对运作程序库的管理需要两个人同时进行认证才可 以通过的方式。比如对运作程序库进行更改或删除需要两个人进行口令认 证系统才允许进行以上操作。其总需要进行认证的两个人彼此不知道对方 的认证口令或步骤。因此该认证过程必须两个人同时在场进行操作才可以。 管理源程序库 我们通常将直接由程序设计语言编制而成的程序称之为源程序。源程序的语言 需要通过相应的语言处理程序翻译成机器语言程序后才可以在计算机上运行。 因此源程序包含了系统及其控制如何实现的细节，为未授修改系统提供了很好 的切入点，例如设置逻辑炸弹。且如果缺少源程序代码会使得今后应用系统的 维护工作十分困难甚至无法完成。因此为了降低计算机程序被破坏的可能性， 应对源程序库的访问进行严格的控制： a)严格的管理在开发设备上的存放源程序的目录。如果源程序没有很好的 保护，会造成系统及其设置会遭到未经授权的访问并造成系统的安全性 可靠性大大下降。 b)只有指定的人员如程序库管理员经过适当的管理授权后才可以访问源程 序库，对源程序库的访问必须结合进行严格的访问控制技术手段和双重 访问控制机制。 c)各项应用均应当指定相应的管理员。 d)信息技术支持人员(非开发人员)不应当自由的访问源程序库。 e)源程序库和运作程序库尽量分开存放并且分开管理。 f)源程序库和运行的应用系统尽量分开存放且分开管理。 g)源程序库的更新和向程序员发布的源程序应当由指定的管理员根据一定 的授权进行，不得私自自行更新或发放。 h)应当保存所有对源程序库进行访问读取或修改的日志纪录，以便于日后 审核。 1.9.4在软件开发过程变更管理规范 a)系统容易受到更改的攻击，即使是完全授权的更改也可能存在破坏性的影响， 存在数据完整性的损失、应用系统的不可用以及机密信息的泄漏的风险。为 了使信息系统的损失降至最小，组织应对更改进行严格的控制，就是在系统 开发的每一个阶段（可行性研究、需求分析、设计、编码、测试、培训等） 的每一个更改实施前经过组织的评审与授权。 b)对于敏感的应用系统的更改应由另一人员进行检查，为了有效的进行控制， 组织应当建立更改控制审批程序，对更改的申请、评审、测试、批准、更改 的计划的提出和实施提出明确要求并严格的实施，确保安全性与控制程序不 被损害，程序设计人员只能访问他们工作所必需的部分，确保任何的改动都 是经过审批的。 c)更改的程序建议如下： 清晰确认所有的需要更改的应用系统、信息、数据库和相关的硬件设 备。 清晰的确认更改的原因(业务上的具体流程和具体的需求或开发上的 需求) 由授权的用户提交更改的申请。 保留相关的授权登记记录。 在正式的实施之前，更改的方案必须经过评审并通过正式的批准。评 审的 确保授权的用户在实施之前确认并接受更改的内容。 确保在实施的过程中，尽量的减少对现行的商务运作系统的影响。 确保建立的文件系统在完成各项更改时得到修改，旧文件被很好的归 档或处置。 保证所有的应用系统升级的版本的控制。 确保所有的更改情求的审核跟踪。 确保用户使用手册作相应的必要的更改。 确保更改的实施选择了适当的时机以确保更改的实施不会干扰正常的 商务运作。 1.9.5开发版本管理规范 控制程序清单 a)在任何时候对于程序清单必须进行严格的控制并且及时地进行更新。 b)对应用系统开发源程序的打印的资料、电子版本或者是相关的报告都必 须进行控制，纸质的文件应当保存在一个安全的环境下，如保险柜等。 电子文档则应当进行一定的加密。 c)源程序相关信息可以帮助我们确认系统问题的根源，并且一旦掌握了系 统源程序相关信息可以清楚地了解系统的运行逻辑和可能的薄弱点。对 系统的安全有很大的影响。 版本升级控制规范 a)应用系统软件开发版本升级申请，当软件的版本由于更新，修改等操作 需要升级时必须先向相关负责人员提交申请。 b)应用系统软件版本升级测试，对升级的应用系统进行测试，确认系统的 各种安全特性。 c)应用系统软件版本审批，确认对应用系统的版本的升级，此时需确认当 前的版本为最新的版本，旧的版本需进行归档，不得随意丢弃或删除。 d)应用系统软件版本升级计划，制定相关的升级计划，确保将系统升级对 业务的影响降至最低。 e)应用系统软件版本升级实施。 版本的控制管理规范 a)版本变更需提出申请，详见 1.9.4“在软件开发过程变更管理规范”。 b)使用软件加锁技术防止不同版本的覆盖的情况。 c)当版本变更时需要在更新的版本中记录变更的详细描述。 d)提供版本的合并功能。 e)版本的更改只允许指定的人员进行操作。 f)纪录所有的版本变更的日志，记录包括了更改日期，更改前版本号，更 改后版本号，更改人，审批人等信息。 1.9.6开发日志审核管理规范 开发日志定期的审计和人员权限的定期审核 .1开发日志定期审计 a)系统开发中的相关日志文件根据开发周期定期审核 .2开发人员权限定期审计 b)开发人员权限每 3 个月审核一次； 1.9.7防御后门代码或隐藏通道相关规范 后门代码和隐藏通道介绍 a)后门代码，主要指由攻击者在未经过许可的情况下，植入计算机系统的 程序。利用调用环境的权利进行与其实际用途无关的拷贝、滥用或破坏 数据，主要有三种类型的后门程序： 调试后门为了方便调试而设置的机关，系统调试后未能及时消除。 维护后门为了方便远程维护所设置的后门，被黑客恶意的利用。 恶意后门由设计者故意设置的机关，用来监视用户的秘密甚至与 破坏应用系统。 特洛伊木马也属于后门的一种，它是黑客攻击计算机的重要手段之一。 特洛伊木马可以放置在正常的文件或程序中，当用户打开或执行它的 时候，它就会自动的安装在计算机上，使得某些人通过 Internet 访问 该计算机成为可能，使计算机处于一种非常危险的状态。 b)隐藏通道，主要指在计算机安全技术中，一种允许某个进程在违反安全 规则的状态下传递信息的通道。隐藏通道可以通过某些直接的或间接的 方法暴露信息。现在使用的应用系统中大多数都包含一定程度的隐藏通 道，他们当中许多是无害的，像特殊的组合健可以给出软件制作者的信 息，但也有些是有害的，因此必须进行相应的防范。 防御后门代码和隐藏通道的相关办法 a)从信誉好的软件供应商那里购买相关的软件或程序。 b)检验和验证源程序和源代码。 c)在系统正式投入使用之前进行评估，如一些行业的标准认证评估(产品安 全认证、CMM 认证等) d)在系统正式投入使用后，严格管理源代码的访问、升级和修改。 e)使用可靠的开发人员操作密钥系统。 f)不要随便从一些不知名的网站上下载软件。 g)不要过于相信别人，不能随便安装别人给的软件，特别是不能随便打开 电子邮件中的附件。特别是一些可执行文件必须先进行病毒及恶意代码 的扫描。 h)安装并正确的使用有关的特洛伊木马的监测和查杀程序，现在大多数主 流的杀病毒软件也带有该功能，比较流程的专门用于查杀特洛伊木马的 程序主要有 Lockdown2000、The Cleaner、Trojian Defence Suit 等。 1.10系统测试阶段安全规范 1.10.1应用系统的安全性检测规范 设计详细的测试计划，测试范围，测试方法和测试工具。 对软硬件的测试必须事先有正式的测试计划。测试计划的一个关键点是测试计 划文档不仅要包含测试的内容同时还需要包含测试预期的结果。并且测试计划 还需要覆盖除此之外的测试内容和结果，使之更加全面。测试完成以后，则需 要对测试结果进行评估，确定其结果是否达到了预定的标准。如果不达到标准， 则需要对测试结果划分一个错误严重性等级，因为如果没有该等级，则无法对 结果有一个很客观的结论。 测试种类 测试的过程需要用户的参与以确保系统达到了业务上的需求和用户使用的需求。 因此主要分为系统测试和用户接受测试 .1 系统测试 系统测试有很多种定义。一般而言系统测试可以定义为：在人工环境下， 测试系统是否能够达到预期的要求的测试方法。 从系统开发的角度而言，系统测试是指由系统开发人员（程序员和其它技 术人员）进行的旨在确保系统各个模块能够正常运行（模块测试）以及系 统整体能够正常运行的测试过程。系统测试必须确保系统的每一个功能都 能够正确运行，并对所有的程序错误逐一分析。同时还测试系统的模块和 模块之间，功能和功能之间的接口的正确性。需要注意的是系统测试不对 系统总体的功能负责，而只需要达到特使计划中规定的测试准则即可。 a)系统负载测试，负载表示对系统得要求，一般包括以下因素： 程序和数据的总体存储容量 并发运行的应用程序数量 并发用户的数量，峰值，槽值和平均值 外设数量 并且，确定硬件的规模比较复杂，在确定了上述因素以后，还需要确定 其它类似响应时间等因素。 b)压力测试 压力测试用于确定系统的薄弱环节，确定系统在非正常条件下能够迅速回 复到正常的运行状态的能力，类似的非正常条件可能是在系统宕机、网络 故障或者高峰载荷下的数据处理。 .2 用户接受测试UAT 用户接受测试是用户对新系统或者系统改动正式验收测试的过程，是任何 系统开发项目都需要经历的重要阶段并且它还需要终端用户的大力参与。 在现实中，UAT 需要有周密详尽和准确的测试计划，特别是验收的标准必 须非常详细。UAT 的最后部分往往包括并行运行，以比较开放系统和原有 系统。 a)尽管系统的用户接受测试计划可能随着系统的不同而不同，但是一般而 言，测试必须涵盖所有今后实际运行中可能发生的事件。测试计划一般 可以在系统开发前制定的用户需求说明书的基础上制订。 b)对任何系统而言，对于出现的问题必须要明确要对这些问题做出哪些应 对措施以及谁来做这些应对措施，例如用户，项目团队，供应商或者是 咨询顾问等所有可能的项目参与方。 c)为了更好地应对测试过程中可能出现地问题，最终用户和项目团队必需 要协商制定“错误严重程度”的范围。它的取值范围从 1 到 6，分别表示 从业务/商业影响角度评估在系统测试过程中发现问题。下文是一个成功 应用的例子，“1”表示最严重的错误，而 6 则表示最轻微的影响。 “致命问题致命问题”如果该程度错误发生，则测试不能继续 “重大问题重大问题”测试可以继续，但是系统不能上线 “主要问题主要问题”测试可以继续，但是如果不解决该问题，则系统上线后， 可能对业务流程有严重破坏。 “一般性问题一般性问题”除了这些问题会对既定的业务流程有一些轻微偏离外， 测试可以继续，并且系统也可以上线。 “次要问题次要问题”可以继续测试和上线，但这些问题必须修正，同时这些 问题对业务流程没有或者很少有影响。 “粉饰性问题粉饰性问题” 类似颜色，字体等问题，如果这些问题对于业务需 求而言特别重要，则需要将这些问题提高到较高层次。 系统的用户在征得主办项目的高层领导意见的前提下必须就每类错误 需要采取的行动和各自需要承担的责任等问题取得一致。例如，可以 要求马上解决严重程度为1的问题并停止所有测试计划直到该层次的 问题解决。 注意事项：注意事项：就算错误严重程度确定以后的问题已经万无一失了，但是怎样 确定错误严重程度还是一个头疼的问题。为了避免类似分级问题的风险， 我们建议在测试规划中给出每一类问题的例子，以避免对问题分级出现根 本性的不一致。如果当有不一致的时候有预先的准备。 最后，非常关键的一点是确定用户接受的准则。事实上，没有一个系统是 完美无缺的，因此最终用户和系统开发上必须就每一类错误的数量有一个 上限。 注意：注意：有些情况下用户可能会有条件接受。这些条件可能增加了工作范围。 在这种情况下以及所有对系统的修正都需要非常严格的用户接受测试和必 要的回归测试。 1.10.1