综合项目应用系统开发安全管理标准规范

文档编号：项目应用开发等级保护规范密级：项目内部项目应用系统开发安全管理规范（信息系统等级保护三级）DATE\@"EEEE年O月"二〇一二年十一月编号应用开发等级保护规范密级项目内部阶段项目设计阶段页数代号名称建设单位承建单位会签 编写 校对审核标审批准相关本文档说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；

目录第1章概述 11.1 目标 11.2 适用范围 11.3 规范引用文件或标准 21.4 术语和定义 21.5 应用系统开发总体标准 3第2章系统需求搜集和分析阶段 52.1 可行性研究分析 52.1.1 技术可行性分析 52.1.2 需求可行性分析 52.1.3 投资可行性分析 52.1.4 影响可行性分析 52.2 开发人员安全管理 62.2.1 系统开发人员职责分配 62.2.2 开发人员授权 62.2.3 开发人员必需训练开发安全代码能力 62.2.4 分离系统开发和运作维护 72.3 建立系统开发安全需求分析汇报 7第3章系统设计阶段安全规范 83.1 单点访问控制且无后门 83.2 人员职责和权限定义 83.3 确保敏感系统安全性 83.4 确保访问层安全性 83.5 确保日志管理机制健全 83.6 新系统容量计划 9第4章系统开发阶段安全规范 104.1 系统开发语言 104.1.1 通用规范 104.1.2 Perl语言 114.1.3 Java语言 134.1.4 C/C++语言 144.2 系统开发安全相关工具管理 174.2.1 工具一：Pscan 184.2.2 工具二：Flawfinder 184.3 控制软件代码程序库 194.3.1 管理运作程序库 194.3.2 管理源程序库 194.4 在软件开发过程变更管理 204.5 开发版本管理 214.5.1 控制程序清单 214.5.2 版本升级控制 214.5.3 版本变更控制 224.6 开发日志审核管理 224.6.1 开发日志定时审计 224.6.2 开发人员权限定时审计 224.7 防御后门代码或隐藏通道 224.7.1 后门代码和隐藏通道介绍 224.7.2 防御后门代码和隐藏通道相关措施 23第5章系统测试阶段安全规范 245.1 应用系统安全性检测 245.1.1 设计具体测试计划、测试范围、测试方法和测试工具 245.1.2 测试种类 245.1.3 在测试过程中具体描述每个和测试方案相关测试步骤和测试数据 265.2 控制测试环境 265.3 为测试使用真实数据 265.4 在软件转移至生产环境前进行测试 275.5 应用系统安全质量判定 27第6章系统培训及文档阶段安全规范 286.1 新系统培训 286.2 撰写新系统和系统改善文档 28第7章应用系统开发外包安全控制 29第8章附录 308.1 参考文件 308.2 本规范用词说明 328.2.1 为便于在实施本规范条文时区分对待，对要求严格程度不一样用词说明以下： 328.2.2 条文中指定应按其它相关标准、规范实施时，写法为“应符合……要求”或“应按……要求（或要求）实施”。 32概述信息系统很多安全控制或其它安全性确保是经过系统开发设计给予实现。所以假如在系统开发设计阶段没有对系统安全性给充足考虑，那么系统本身一定会存在很多先天不足，系统就会漏洞百出。为确保应用系统安全，在应用系统开发之前就应确定系统安全需求，并以此作为开发设计阶段基础。本规范关键要求了在系统开发各个阶段所应遵守多种安全规范，从需求分析开始，到设计，再到开发和维护和最终文档等系统开发各个阶段分别进行叙述，并将在不一样阶段中所需要注意安全问题和相关安全规范进行深入描述和要求。目标保护应用系统开发过程安全。具体地说就是保护应用系统开发过程免受未经授权访问和更改，保护系统开发中系统软件和信息安全，确保开发项目顺利正确实施并对开发环境进行严格控制。同时确保应用系统开发外包中各项安全。适用范围本套规范适用范围包含了整个应用系统开发过程中安全。包含了系统开发可行性和需求分析阶段安全，系统设计阶段安全，系统开发阶段安全，系统测试阶段安全，系统培训和文档阶段安全和系统开发外包安全规范。关键要求了应用系统开发过程安全保密，软件质量要求，系统和业务需求符合性，确保敏感信息安全，系统本身稳定性和兼容性问题。规范引用文件或标准下列文件中条款经过本标准引用而成为本标准条款。通常不注日期引用文件，其最新版本适适用于本标准。GB17859-1999计算机信息系统安全保护等级划分准则GB/T9387-1995信息处理系统开放系统互连基础参考模型（ISO7498:1989）GA/T391-计算机信息系统安全等级保护管理要求ISO/IECTR13355信息技术安全管理指南NIST信息安全系列——美国国家标准技术院英国国家信息安全标准BS7799信息安全基础保护ITBaselineProtectionManual(Germany)BearingPointConsulting内部信息安全标准RUSecure安全技术标准信息系统安全教授丛书CertificateInformationSystemsSecurityProfessional术语和定义访问控制accesscontrol一个安全确保手段，即信息系统资源只能由被授权实体按授权方法进行访问，预防对资源未授权使用。应用系统applicationsystem认证authenticationa.验证用户、设备和其它实体身份；b.验证数据完整性。授权authorization给权利，包含信息资源访问权授予。可用性availability数据或资源特征，被授权实体按要求能立即访问和使用数据或资源。缓冲器溢出bufferoverflow指经过往程序缓冲区写超出其长度内容，造成缓冲区溢出，从而破坏程序堆栈，使程序转而实施其它指令，以达成攻击目标。保密性confidentiality数据所含有特征，即表示数据所达成未提供或未泄露给未授权个人、过程或其它实体程度。隐藏通道covertchannel可用来根据违反安全策略方法传送!数据传输信道。完整性integrity在预防非授权用户修改或使用资源和预防授权用户不正确地修改或使用资源情况下,信息系统中数据和在原文档中相同，并未遭受偶然或恶意修改或破坏时所具性质。敏感信息sensitiveinformation由权威机构确定必需受保护信息，因为该信息泄露、修改、破坏或丢失全部会对人或事产生可预知损害。系统测试systemtesting用于确定系统安全特征按设计要求实现过程。这一过程包含现场功效测试、渗透测试和验证。后门代码trapdoor通常为测试或查找故障而设置一个隐藏软件或硬件机制，它能避开计算机安全。而且它能在很规时间点或无需常规检验情况下进入程序。特洛伊木马Trojanhorse一个表面无害程序，它包含恶性逻辑程序，造成未授权地搜集、伪造或破坏数据，以此破坏计算机安全和完整性进程。验证verification将某一活动、处理过程或产品和对应要求或规范相比较。例：将某一规范和安全策略模型相比较，或将目标代码和源代码相比较。压力测试于确定系统微弱步骤，确定系统在非正常条件下能够快速恢复到正常运行状态能力。应用系统开发总体标准应用系统开发应遵照一系列总体标准，以确保开发过程中安全。其中包含：系统开发应从业务需求角度出发，不得盲目追求系统优异性而忽略了系统实用性。系统开发是为了愈加好地满足业务上需要，而不是技术上需要。开发方法和管理必需规范化、合理化、制度化，从而确保开发质量和进度。应确保开发进度并按时完成。确保开发工作立即、有效且高质量完成。系统开发必需含有一定前瞻性，符合主流系统发展方向。提升和加强开发人员安全意识。确保机密信息和关键技术不会泄漏，尤其是不可泄漏到竞争对手手中，不然将会对企业竞争力产生极大影响。应充足利用现有资源。系统需求搜集和分析阶段可行性研究分析对于应用系统开发项目应进行一定可行性分析，以确保只有在确定含有了相当资源和条件，而且有能力满足业务上需求情况下才能开展开发工作。切忌盲目开发，不然既浪费资源，又浪费时间。可行性研究宜从技术、需求面、投入和影响四个方面进行考虑：技术可行性分析依据业务上提出需求，从技术开发角度分析现有技术手段和技术能力是否能够实现业务上所要求系统功效。通常可从以下三个方面进行分析：人员技术能力分析，指企业内系统开发队伍或外包第三方开发企业是否含有足够技术和管理能力来完成系统开发任务。计算机软件和硬件分析，指企业现有软件和硬件性能是否足够满足开发对应系统要求。管理能力分析，指现有技术开发管理制度和管理步骤是否成熟且标准化，是否满足系统开发要求。需求可行性分析系统开提议源于业务上需求，所以需要对该需求进行可行性分析，以判定需求是否明确，是否符合实际，是否在一定时间范围内能够实现。投资可行性分析依据业务需求和技术手段分析，确定实现系统开发所需投资，并确定投资数额是否在可控制和可承受范围内。影响可行性分析所谓影响是指社会影响，比如系统开发是否符正当律法规上要求，是否和相关管理制度或行业标准相抵触，是否符合人文或道德上约束等。开发人员安全管理系统开发人员职责分配在系统开发过程中，应明确不一样人员身份和职责。在系统开发过程中具体可分以下三种角色：项目责任人员：确保在整个系统开发各个阶段全部实施了相关安全方法，同时在整个系统开发过程中负责整个项目标开发安全管理。系统开发人员：依据业务需求确保开发系统能够满足业务上需求和对应安全上需求，同时满足系统质量上和进度上要求。系统审核人员：对整个开发过程进行审核和监督，确保开发质量和开发安全。开发人员授权应依据该职员在整个开发项目中所负责开发内容授予其对应权限和所应负担责任。开发人员必需负责其开发内容保密性，不得私自将开发相关信息泄漏出去，即使对家人或开发团体中其它开发人员也不得泄漏。但开发人员有责任将开发相关信息告诉项目标责任人员或开发小组责任人员。以书面方法将职员权限和对应责任提交给职员本人。必需严格要求在为企业工作期间，全部和工作相关开发结果所属权全部归企业全部。应依据职员权限和责任大小确定是否需要签署相关保密协议。应在日常工作中统计职员和开发相关日志信息。职员一旦离职或调动岗位应立即收回或调整其对应权限。开发人员必需训练开发安全代码能力在整个开发过程中必需完整连续地进行代码错误处理所要求步骤。错误问题汇报应努力争取通俗易懂，不应在其中包含任何系统细节问题。应对关键敏感信息进行加密保护。应使用部分相对复杂加密和密钥生成机制。应单独编写安全性设计说明概要分离系统开发和运作维护管理层必需确保应用系统开发和运作管理从组织人事和权限职责上分开。信息技术人员能够现场修复或更改偶然或恶意数据和软件问题。测试代码中往往包含调试或查错代码，大大增加了主机系统性能负担。开发人员不应含有很高权限，不然将在系统运行中产生很大风险。建立系统开发安全需求分析汇报安全需求计划应能够达成期望安全水平。其中包含了成本预估，完成各个安全相关步骤所需时间。全部相关应用系统更新或改善全部必需基于业务需求，并有业务事件支持。这里业务需求不仅仅包含了系统功效、性能、开发费用、开发周期等内容，应明确系统安全要求。应用系统任何一次改善或更新全部应和该业务系统全部者亲密相关。开发安全需求分析计划应由开发项目经理和企业内部安全小组共同商议决定。应确保每一个应用系统用户全部意识到系统更新或改善全部和其本身亲密相关，全部更新或改动提议全部必需基于业务需求，而不是基于所谓“信息技术要求”。系统每一次更新或改善全部必需认真对待，必需进行具体需求定义、需求分析和测试评定，以确保不会对业务造成任何不良影响。业务需求是系统更新和改动基础，所以必需清楚明确地定义业务需求，严禁在业务需求未经业务部门领导和关键责任人员认可情况下，盲目地进行开发工作。系统设计阶段安全规范单点访问控制且无后门任何用户假如期望访问应用系统中某一部分，则必需经过统一且唯一认证授权方法及步骤。人员职责和权限定义因为不是全部人员对于某一个应用系统全部含有一样访问或使用权限，所以系统必需含有基于人员职责用户授权管理，以确保每个用户能够访问到其权限范围内应用系统部分。同时应确保每个用户无法访问其权限范围以外应用系统部分。确保敏感系统安全性将应用系统中敏感信息保留在服务器端以进行集中加密安全管理，确保用户端系统本身并不能存放任何敏感数据。确保访问层安全性应用系统不仅仅要确保系统模块本身安全性，同时还应考虑模块和模块之间通讯安全性。这种模块和模块之间通讯安全性不仅仅包含了应用系统内部模块之间通讯安全，也包含了应用系统内部模块和外部模块之间通讯安全性，如主机和用户端之间通讯安全性、服务器和服务器间通讯安全性，和当地系统和异地系统之间通讯安全性。确保日志管理机制健全应建立可依据情况自由设置日志管理机制，也就是说日志统计范围和具体程度能够依据需求自行定制，且能够实现在应用系统使用过程中进行日志定制和统计。保留全部和系统开发相关程序库更新审核统计。新系统容量计划容量计划是指确定系统总体规模、性能和系统弹性。容量计划具体内容可能有所不一样，但通常应考虑以下方面：系统预期存放容量和在给定周期中获取生成和存放数据量。在线进程数量和估量可能占用资料系统和网络响应时间和性能，即端对端系统系统弹性要求和设计使用率（峰值，槽值和平均值等）安全方法如加密解密数据对系统影响。24x7运作要求和可接收系统宕机次数（维护或设备更新造成必需性宕机）计划容量时候相关系统使用信息了解越多越好。最近，因为互联网站使用以指数形式增加，容量计划变动效果不是很显著，有时甚至毫无用处。原因在于极难估量实际负载。在容量估量时候应尽可能将情况设想得复杂部分。系统开发阶段安全规范系统开发语言程序员可使用很多指导规范来预防应用程序中一般安全问题。其中很多能够应用于任何一个编程语言，但一些是针对特定语言。特定语言指导规范关键集中在Perl，Java和C/C++语言。大多数情况下，通常错误能够避免。而这些本能够避免错误常常会造成很多安全漏洞，从而威胁信息保密性、完整性和可用性。通用规范输入验证在用户机/服务器环境下，进行服务端验证而不是用户端验证（比如基于Javascript验证）。经过在用户端和服务器之间放置一个代理服务器，能够很轻易绕过用户端验证。有了代理服务器，攻击者能够在数据被用户端“验证”后修改数据（和“man-in-the-middle”攻击类似）。在实际校验中，输入校验首先定义一个有效（可接收）字符集，然后检验每个数据字符是否在有效范围内。假如输入中包含无效字符，应用程序应返回错误页面并说明输入中包含无效字符。这么进行验证原因是定义无效字符集比较困难，而且部分不应有效字符通常不会被指出。边界检验（比如字符串最大长度）应在字符有效性检验以前进行。边界分析能够预防大多数缓冲区溢出漏洞。从环境变量取得数据也需要进行验证。同时避免在环境变量中存放敏感数据（比如密码）。一些Unix系统（比如FreeBSD）包含ps命令，能够让用户看到任何目前进程环境变量，这常常会暴露保密性信息。SQL语句假如应用程序需要连接后端数据库，不得在代码中使用SQL语句。使用程序以外嵌入在代码中SQL语句调用尤其危险，难以预防攻击者使用输入域或配置文件（由应用程序载入）来实施嵌入式SQL攻击。而输入验证有利于缓解这种风险。注释代码(commentedcode)当应用程序在实际环境中开始应用时，应删除全部注释代码。注释代码是用来调试或测试，它们不是最终应用程序一部分。不管怎样应在实际环境中删除它们来避免意外实施（通常注释标识被删除后就无法激活休眠代码，但还是存在可能性，所以应实施这项工作）。错误消息全部对用户显示错误信息全部不应暴露任何相关系统、网络或应用程序敏感信息。假如可能话，应使用包含编号通常错误信息，这种信息只有开发者和/或支持小组才能了解。通常错误信息例子是“发生了错误（代码1234），请您和系统维护部门联络。”统一资源定位（URL）内容对于web应用，不要在URL上暴露任何关键信息，比如密码、服务器名称、IP地址或文件系统路径（暴露了web服务器目录结构）。这些信息能够在攻击时使用。例以下面就是一个不安全URL：PASSWORD&file=/home/USER/expenses.txt设置PATH变量设置PATH为一个已知值，而不仅仅是使用开启时缺省值。攻击者能够在攻击应用程序时使用PATH变量，比如试图实施一个任意程序。这些也能够应用于大多数其它语言。Perl语言多年以来，Perl已经成为用于系统管理和WebCGI开发功效最强编程语言之一（几乎能够使用Perl实现任何功效）。但其扩展应用，即作为Internet上CGI开发工具，使得它常常成为web服务器上攻击目标。另外，大多数CGI脚本有着比通常见户更高权限，造成它更轻易受攻击。下面列举了部分开发者（尤其是CGI程序员）能够使用主动预防性方法来增强Perl代码整体安全性（请注意：这不是web服务器CGI脚本安全性指导标准）。Taint验证Perl版本5.x包含一个叫做TaintChecking数据验证方法。假如起用该功效，它就不许可经过用户输入（任何程序外输入）来操纵其它外部程序（比如经过管道将数据导入另一个程序实施））。通常而言，程序员不能信任输入脚本和程序数据（叫做Tainted数据），因为无法确保它不会产生危害（有意或无意）。Taint验证能够经过在命令行参数加入“-T”来开启。比如能够Perl脚本第一行这么加入“-T”：#!usr/bin/perl5-TTainted数据包含命令行参数、环境变量和来自文件数据。引用tainted数据变量也成为tainted数据。假如脚本试图经过不安全方法来使用tainted数据会产生一个致命错误（对这种情况称为“不安全依靠”(Insecuredependency)或其它说法）。启用tainted验证在有些情况下会造成脚本停止运行，常常是因为Perl解释器要求全部脚本引用外部程序完全路径必需在PATH环境变量中列出，同时PATH中包含每个目录除了目录全部者及对应全部者用户组外无法修改。Taint验证对于环境比较敏感，这就可能会造成大多数程序员不愿使用它，不过只要可能就应使用taint验证，尤其是代码实施其它程序功效时（比如在CGI脚本情况下）。安全模块假如不仅输入数据不可信而且实际代码也不可信会产生什么情况？比如用户从网站上下载了一个ActiveX控件，而它实际是一个特洛伊木马(Trojanhorse)。这种情况下taint验证就不起作用。安全模块让程序员能够在Perl脚本中将不一样代码模块和安全对象相联络。每个安全对象对于运行每块代码建立了一个限制环境。这和chroot在一个进程中只能在整体目录结构一个子目录中运行类似。而saft对象限制perl代码只能在perl包结构一些特定包中运行。怎样使用安全模式超出了本文范围，但程序员应在任何时候使用这一功效。警告参数(-w)使用-w参数能够在Perl解释脚本时显示全部警告信息。警告能够对以下情况产生：只使用了一次变量或完全没有使用过变量，未定义文件句柄，未关闭文件句柄，或将非数值变量传输到数据变量。该功效不是针对安全处理，不过有利于调试直接或间接对安全有危害错误。通常推荐总是使用-w参数。可在taint验证时在第一行这么使用-w参数：#!usr/bin/perl5–TwJava语言自从1995年公布以来，Java成为简单或复杂网络应用有效编程语言。它在设计时充足考虑了安全问题，所以它含有限制特征有：搜集不再使用内存碎片垃圾搜集器，严格“sandbox”安全模型，和在特定主机上限制应用程序活动安全管理器。以下为使用中相关规范：不应在标准输出上打印消息在实际Internet系统中避免使用System.out.println()或System.err.println()打印日志和错误消息，原因是当消息打印到标准输出时，无法立即确定消息发生地点，且有可能将敏感信息透露给攻击者。封装Java中，假如没有使用访问标识符(accessmodifier(private、protected或public))来申明类、方法和属性，那么它默认访问范围是包，而且同一包中全部类全部能访问它。必需记住即使包有封装功效，但它只有在每部分加载到包代码全部由授权用户控制时才起作用。恶意用户能够加入她们自己类，从而对于包中全部类、方法和属性全部有完全访问权限。Java政策文件支持两种控制包访问权限前缀。accessClassInPackagedefineClassInPackage全部标准库中类全部默认是能够公共访问（除了由“sun”开头类）。为了确保一个包安全性，必需修改${JAVAHOME}/jre/lib/security文件夹中java.security文件。该文件中关键行是：package.access=sun.即使该方法有作用，但仍存在问题。比如程序员在java.security文件中定义包安全时必需十分小心。在package.access中值是字符型，“sun.”将保护“sun.tools”等包，不过不会对“sun”或“sunshine”等包进行保护。另一个方法是使用JAR密封(sealing)。JAR(JavaARchive)文件是部分类打包压缩格式文件，和常见ZIP格式类似。假如从一个密封(sealing)JAR文件中加载一个类，随即同一个包类只能从该JAR文件加载。为了起用密封(sealing)，必需在建立JAR文件时这么设置密封(seal)参数：Sealed:true使用密封(sealing)JAR文件比权限(permission)设置愈加好，因为它不需要安装安全管理器(securitymanager)。政策文件Java内建安全管理器是对应用程序进行限制一个方便工具。很多情况下需要编制一个定制安全管理器，JDK1.2及以后版本提供了描述设置方法而不是实施它们。这是经过Java政策文件实现。能够用政策文件以相对模块化方法控制文件系统和网络访问。比如能够限制应用程序只能修更名字是foo文件。宜使用Java政策文件和安全管理器而不是重新创建一个类或系统来限制对主机和网络访问。C/C++语言C本质上是不安全编程语言。比如假如不谨慎使用话，其大多数标准字符串库函数有可能被用来进行缓冲区攻击或格式字符串攻击。不过，因为其灵活性、快速和相对轻易掌握，它是一个广泛使用编程语言。下面是针对开发安全C语言程序部分规范。缓冲区溢出避免使用不实施边界检验字符串函数，因为它们可能被用来进行缓冲区溢出攻击。下面是应避免使用函数。同时，也列出了每个函数对应比较安全替换方法。不使用strcpy()，使用strncpy()不使用strcat()，使用strncat()不使用sprintf()，使用snprintf()不使用gets()，使用fgets()在上面前三个中函数中，每个替换函数“n”表示了使用缓冲区大小。最终一个函数“f”，表示格式，它许可用户指定时望输入格式。这些替换方程强制程序员定义使用缓冲区尺寸和确定输入类型。格式化字符串攻击（FormatStringAttack）该类攻击往往和缓冲区溢出相关，因为它们往往关键利用了一些函数假设，比如sprintf()和vsprintf()假设缓冲区长度是无限。然而即使使用snprintf()替换sprintf()也无法完全保护程序不受格式化字符串攻击。这些攻击经过直接将格式说明符（formatspecifiers）(%d，%s，%n等)传输到输出函数接收缓冲区来进行。比如，以下代码就是不安全：snprintf(buffer,sizeof(buffer),string)这种情况下，能够在字符串中插入格式说明符来操纵内存栈，来写入攻击者数据（这些数据中包含小程序代码，并可由处理器接着实施）。更多相关这些攻击具体内容请见资源章节。对以上例子提议使用下面代码。snprintf(buffer,sizeof(buffer),“%s”,string)进行格式字符串攻击不太轻易。首先攻击者必需能取得内存栈内容情况（从应用导出或使用调试器），然后必需知道怎样正确访问特定内存空间来操纵栈中变量。实施外部程序推荐使用exec()函数而不是system()函数来实施外部程序。这是因为system()接收整个命令行随机缓冲区来实施程序。snprintf(buffer,sizeof(buffer),"emacs%s",filename);system(buffer);在以上例子中，能够经过使用分号利用文件名变量在sehll中插入额外命令（比如文件名能够是/etc/hosts;rm*，这将在显示/etc/hosts目录文件同时，删除目录中全部文件）。而exec()函数只确保第一个参数被实施：execl("usr/bin/emacs","usr/bin/emacs",filename,NULL);上面例子确保文件名仅仅作为一个参数输入Emacs工具，一样它在Emacs命令中使用完全路径而不是使用能够被攻击者利用PATH环境变量。竞争条件（racecondition）进程需要访问资源时（不管是磁盘、内存或是文件）通常需要实施两个步骤：首先测试资源是否空闲可用假如可用，就访问该资源，不然它等到资源不再使用为止再去访问它当另一个进程在步骤1和2之间想要访问同一个资源时将出现问题，造成不可估计结果。进程可能会被锁定，或一个进程籍此取得了另一个进程较大权限而造成安全问题。攻击关键集中在有较大权限程序上（称为setuid程序）。竞争条件攻击通常利用程序实施时能够访问到资源。另外权限低程序也存在安全风险，因为攻击者可能会等候有较高权限用户实施那个程序(比如root)，然后进行攻击。下面提议有利于缓解竞争条件(racecondition)攻击：在进行文件操作时，利用那些使用文件描述符函数而不使用那些使用文件路径函数（比如使用fdopen()而不要使用fopen()）。文件描述符使得恶意用户在文件打开时或是在原始进程对文件进行操作前，无法使用文件连接（符号式或是物理）来改变文件。在写文件甚至在读文件时宜使用fcntl()和flock()函数来对文件加锁，这么它们就不能被其它进程访问。它几乎能够建立原子级操作。应谨慎操纵临时文件，因为它往往会造成竞争条件攻击。检验有效返回值检验有效返回值很关键。一个例子是旧/bin/login实现中不检验错误返回值，造成当它找不到/etc/passwd文件时返回root访问权限。假如该文件损坏了则这种情况是合理；但假如该文件存在只是无法访问，那么这就是一个大问题。系统开发安全相关工具管理有很多方法来确保代码符合一定安全等级。正如前面指出，最好方法之一是让尽可能多人来检验代码（而不是在QA环境中实际进行白箱或黑箱测试）。然而，有时代码在开始实际环境应用前往往没有足够时间，而且即使检验代码也会遗漏部分不易发觉错误。这些错误可能会对整个系统造成重大安全问题。所以（和其它原因），使用源码分析工具(SourceCodeAnalysisTool(SCAT))来自动进行一些检验过程很有帮助。本文介绍了部分这方面工具。每个工具全部用一样测试工具来检验，这些测试工具包含C和Java代码段，而这些代码段存在潜在安全错误。我们比较了每个工具测试结果，而且仔细检验了以下属性：灵活性－有多个选项并能扫描多个类型代码工具得分会较高。正确性－关键目标是发觉正确安全问题，而且不会出现大量误报信息，或更糟是没有发觉真正错误信息。轻易使用－大多数情况下，程序员只需将工具指定到特定代码上然后选择“扫描”。除非尤其需要，程序员通常只做抽样检验，而无需开发复杂测试机制。报表－扫描结果应以一个轻易了解格式来显示，而且最好同时提醒修改每个问题方法，并附加理由。每个工具在解析代码上速度能够忽略不计，所以没有进行比较（即使这并不包含配置扫描时间，而MOPS在这方面相对于其它工具需要更多时间）。另外，这些工具全部能够无偿取得，甚至能够取得它们源代码，所以不需考虑它们成本。工具一：PscanPscan是一个有针对性扫描程序，关键用于发觉C程序中缓冲区溢出和格式化字符串攻击。该程序检验全部用到标准C程序库中printf()函数。sprintf(buffer,variable);printf(buffer,variable);相关这些语句在缓冲区溢出和格式化字符串攻击中怎样被利用能够查阅相关C和C++文档。Pscan一个不足是不能发觉因为越界检验不充足而引发常规性缓冲区溢出。但Pscan对于缓冲区溢出和格式化字符串攻击定位还是相当正确和快速。Pscan程序相对简单，它只将结果返回标准输出，当然也能够将其输出到文件，而且除了说明程序员应怎样修正错误以外，不给出语句为何犯错等类似信息。该工具一个显著特点是能够同时扫描多个文件。总体而言Pscan程序相对简单，易于使用，同时针对性很强，不过因为它能够适用范围过于狭窄所以通常不推荐其在大型商业应用中使用，而只是检验部分相对简单程序片断。工具二：FlawfinderFlawfinder是一个分析C程序安全隐患静态分析工具。和Pscan类似，该程序能够发觉很多个类型错误，除了printf()和标准字符串函数，它还能够发觉竞争条件和系统调用。Flawfinder相比较Pscan，它返回错误信息要丰富很多，而且也愈加具体。而这对于程序员来说很关键。Flawfinder甚至能够对程序中弱点进行分类，比如buffer弱点、格式弱点、shell弱点等。Flawofinder是一个相当出色C程序检验工具，速度会，界面友好，返回信息丰富，安装使用相对简单。该工具是检验不一样规模应用程序首选，唯一不足是它只能用于C程序检验。控制软件代码程序库管理运作程序库我们通常将用于系统开发软件工具和开发平台称之为运作程序，所以为了降低计算机程序被破坏可能性，应对运作程序库访问进行严格控制：严格管理在开发设备上存放开发运作程序目录。假如开发运作程序没有很好保护，则系统及其设置可能遭到未经授权访问，并造成系统安全性可靠性大大下降。只有指定人员如程序库管理员经过合适管理授权后，才能够访问运作程序库，对运作程序库访问必需结合严格访问控制技术手段和双重访问控制机制。严格访问控制能够经过以下要求实现严格管理开发部门所在区域保安管理，预防未经授权人进入开发区域。严格管理开发用途计算机使用，只有指定人员才能够访问开发用计算机设备。严格管理开发运作系统认证管理，建立严格基于人员职责授权等级制度，用口令或其它身份识别技术确定访问者身份。建立双重访问控制机制双重访问控制机制就是对运作程序库管理需经两个人同时进行认证后才可经过方法。比如对运作程序库进行更改或删除需要两个人进行口令认证，系统才许可进行以上操作。需要进行认证两个人相互不知道对方认证口令或步骤。所以该认证过程必需两个人同时在场才可进行操作。管理源程序库源程序包含了系统及其控制怎样实现细节，为修改系统提供了很好切入点，比如设置逻辑炸弹。且假如缺乏源程序代码会使得以后应用系统维护工作十分困难甚至无法完成。所以为了降低计算机程序被破坏可能性，应对源程序库访问进行严格控制：严格管理在开发设备上存放源程序目录。假如源程序没有很好保护，则系统及其设置可能会遭到未经授权访问，并造成系统安全性可靠性大大下降。只有指定人员如程序库管理员经过合适管理授权后才能够访问源程序库，对源程序库访问必需结合进行严格访问控制技术手段和双重访问控制机制。各项应用均应指定对应管理员。信息技术支持人员(非开发人员)不应自由访问源程序库。源程序库和运作程序库宜分开存放而且分开管理。源程序库和运行应用系统宜分开存放且分开管理。源程序库更新和向程序员公布源程序应由指定管理员依据一定授权进行，不得私自进行更新或发放。应保留全部对源程序库进行访问读取或修改日志统计，方便以后审核。在软件开发过程变更管理a) 系统轻易受到未经授权变更影响，即使是完全授权更改也可能存在破坏性影响，存在数据完整性损失、应用系统不可用和机密信息泄漏风险。为了使信息系统损失降至最小，组织应对更改善行严格控制，即在系统开发每一个阶段（可行性研究、需求分析、设计、编码、测试、培训等）每一个更改实施前必需经过组织评审和授权。b) 对于敏感应用系统更改应由另一人员进行检验，为了有效进行控制，组织应建立更改控制审批程序，对更改申请、评审、测试、同意、更改计划提出和实施提出明确要求并严格实施，确保安全性和控制程序不被损害，程序设计人员应只能访问她们工作所必需部分，确保任何改动全部应经过审批。c) 更改程序宜以下：清楚确定全部需要更改应用系统、信息、数据库和相关硬件设备。清楚确定更改原因(业务上具体步骤和具体需求或开发上需求)。由授权用户提交更改申请。保留相关授权登记统计。在正式实施之前，更改方案必需经过评审并经过正式同意。确保授权用户在实施之前确定并接收更改内容。确保在实施过程中，尽可能降低对现行业务运作系统影响。确保建立文件系统在完成各项更改时得到修改，旧文件被很好归档或处理。确保全部应用系统升级版本控制。确保对全部更改请求进行审核跟踪。确保用户使用手册作对应必需更改。确保更改实施选择了合适时机，以确保更改实施不会干扰正常业务运作。开发版本管理控制程序清单源程序相关信息能够帮助确定系统问题根源，而且一旦掌握了系统源程序相关信息能够清楚地了解系统运行逻辑和可能微弱点，对系统安全有很大影响。在任何时候对于程序清单必需进行严格控制而且立即地进行更新。对应用系统开起源程序打印资料、电子版本或是相关汇报全部必需进行控制，纸质文件应保留在一个安全环境下，如保险柜等。电子文档则应进行一定加密。版本升级控制应用系统软件开发版本升级申请。当软件版本因为更新、修改等操作需要升级时必需先向相关责任人员提交申请。应用系统软件版本升级测试。对升级应用系统进行测试，确定系统多种安全特征。应用系统软件版本审批。对应用系统版本升级，应确定目前版本为最新版本，旧版本应进行归档，不得随意丢弃或删除。应用系统软件版本升级计划。制订相关升级计划，确保将系统升级对业务影响降至最低。应用系统软件版本升级实施。版本变更控制版本变更应提出申请，详见4.4“软件开发过程变更管理规范”。应使用软件加锁技术预防不一样版本相互覆盖情况。当版本变更时应在更新版本中统计变更具体描述。应提供版本合并功效。版本更改应只许可指定人员进行操作。应统计全部版本变更日志，其中包含更改日期、更改前版本号、更改后版本号、更改人、审批人等信息。开发日志审核管理开发日志定时审计系统开发中相关日志文件应依据开发周期定时审核。开发人员权限定时审计开发人员权限定时（3个月）审核一次。防御后门代码或隐藏通道后门代码和隐藏通道介绍a) 后门代码，关键指由攻击者在未经许可情况下，植入计算机系统程序。利用调用环境权利进行和其实际用途无关拷贝、滥用或破坏数据，关键有三种类型后门程序：调试后门——为了方便调试而设置机关，系统调试后未能立即消除。维护后门——为了方便远程维护所设置后门，被黑客恶意利用。恶意后门——由设计者有意设置机关，用来监视用户秘密甚至和破坏应用系统。特洛伊木马也属于后门一个，它是黑客攻击计算机关键手段之一。特洛伊木马能够放置在正常文件或程序中，当用户打开或实施它时候，它就会自动安装在计算机上，使得一些人经过Internet访问该计算机成为可能，使计算机处于一个很危险状态。b) 隐藏通道，关键指在计算机安全技术中，一个许可某个进程在违反安全规则状态下传输信息通道。隐藏通道能够经过一些直接或间接方法暴露信息。现在使用应用系统中大多数全部包含一定程度隐藏通道，她们当中很多是无害，像特殊组合健能够给出软件制作者信息，但也有些是有害，所以必需进行对应防范。防御后门代码和隐藏通道相关措施应从信誉好软件供给商那里购置相关软件或程序。应检验和验证源程序和源代码。在系统正式投入使用之前应进行评定，如部分行业标准认证评定(产品安全认证、CMM认证等)。在系统正式投入使用后，应严格管理源代码访问、升级和修改。应使用可靠开发人员操作密钥系统。不应随便从部分不著名网站上下载软件。不应过于相信她人，不得随便安装她人给软件，尤其是不得随便打开电子邮件中附件，部分可实施文件必需优异行病毒及恶意代码扫描。安装并正确地使用相关特洛伊木马监测和查杀程序，现在大多数主流杀病毒软件也带有该功效，现在比较流行专门用于查杀特洛伊木马程序关键有Lockdown、TheCleaner、TrojianDefenceSuit等。系统测试阶段安全规范应用系统安全性检测设计具体测试计划、测试范围、测试方法和测试工具对软硬件测试必需事先有正式测试计划。测试计划一个关键点是测试计划文档不仅要包含测试内容同时还需要包含测试预期结果。而且测试计划还需要覆盖除此之外测试内容和结果，使之愈加全方面。测试完成以后，需要对测试结果进行评定，确定其结果是否达成了预定标准。假如达不到标准，则应对测试结果划分一个错误严重性等级，不然无法对结果进行客观评论。测试种类测试过程需要用户参与以确保系统达成了业务上需求和用户使用需求。所以关键分为系统测试和用户接收测试。系统测试系统测试有很多个定义。通常而言系统测试能够定义为：在人工环境下，测试系统是否能够达成预期要求测试方法。从系统开发角度而言，系统测试是指由系统开发人员（程序员和其它技术人员）进行，意在确保系统各个模块能够正常运行（模块测试）和系统整体能够正常运行测试过程。系统测试必需确保系统每一个功效全部能够正确运行，并对全部程序错误逐一分析。同时还测试系统模块和模块之间、功效和功效之间接口正确性。需要注意是系统测试不对系统总体功效负责，而只需要达成测试计划中要求测试准则即可。a)系统负载测试，负载表示对系统要求，通常包含以下原因：程序和数据总体存放容量并发运行应用程序数量并发用户数量，峰值，槽值和平均值外设数量确定硬件规模比较复杂，在确定了上述原因以后，还应确定其它类似响应时间等原因。b)压力测试压力测试用于确定系统微弱步骤，确定系统在非正常条件下能够快速恢复到正常运行状态能力，类似非正常条件可能是在系统宕机、网络故障或高峰载荷下数据处理等。用户接收测试－UAT用户接收测试是用户对新系统或系统改动正式验收测试过程，是任何系统开发项目全部需要经历关键阶段，而且需要终端用户大力参与。在现实中，UAT需要有周密详尽和正确测试计划，尤其是验收标准必需很具体。UAT最终部分往往包含并行运行，以比较开放系统和原有系统。a) 尽管系统用户接收测试计划可能伴随系统不一样而不一样，测试必需涵盖全部以后实际运行中可能发生事件。测试计划通常能够在系统开发前制订用户需求说明书基础上制订。b) 对任何系统而言，对于出现问题必需要明确要对这些问题做出哪些应对方法和谁来做这些应对方法，比如用户、项目团体、供给商或是咨询顾问等全部可能项目参与方。c) 为了愈加好地应对测试过程中可能出现问题，最终用户和项目团体必需协商制订“错误严重程度”范围。它取值范围从1到6，分别表示从业务/商业影响角度评定在系统测试过程中发觉问题。下文是一个成功应用例子，“1”表示最严重错误，而6则表示最轻微影响。“致命问题”——假如该程度错误发生，则测试不能继续。“重大问题”——测试能够继续，不过系统不能上线。“关键问题”——测试能够继续，不过假如不处理该问题，则系统上线后，可能对业务步骤有严重破坏。“通常性问题”——除了这些问题会对既定业务步骤有部分轻微偏离外，测试能够继续，而且系统也能够上线。“次要问题”——能够继续测试和上线，但这些问题必需修正，同时这些问题对业务步骤没有或极少有影响。“粉饰性问题”——类似颜色，字体等问题，假如这些问题对于业务需求而言尤其关键，则需要将这些问题提升到较高层次。系统用户在取得主管项目标高层领导意见前提下，必需就每类错误需要采取行动和各自需要负担责任等问题取得一致。比如，能够要求立即处理严重程度为1问题，并停止全部测试计划直到该层次问题处理。注意事项：为避免类似分级问题风险，在测试计划中宜给出每一类问题例子，以避免对问题分级出现根本性不一致。当有不一致时候应预先准备。d) 最终用户和系统开发上必需就每一类错误数量有一个上限。注意：有些情况下用户可能会有条件接收。这些条件可能增加了工作范围。在这种情况下和全部对系统修正全部需要很严格用户接收测试和必需回归测试。在测试过程中具体描述每个和测试方案相关测试步骤和测试数据将全部测试数据进行整理归档，将犯错统计进行分析，确定问题产生原因并编写问题汇报。控制测试环境控制系统测试环境和实际工作环境应隔离进行控制处理，不然未经确定软件修改会造成出现无法预料问题。工作人员在两个环境里切换，轻易操作失误，引发无须要麻烦。开发和系统测试同时进行轻易造成对系统状态错误估量。为测试使用真实数据测试数据通常情况下是虚构，不过有时候需要使用实际操作或运作数据，当该数据含有企业敏感信息时候，假如不加以控制，会造成数据泄漏。当处于测试目标而使用真实敏感数据时，能够采取以下方法保护测试数据安全：对测试系统进行严格访问控制。只许可小部分测试人员进行测试。且测试人员应签署安全保密协议。每一次将真实运作信息复制到测试系统时均需要一个单独授权过程。测试完成后，应立即将相关数据从测试应用系统中删除。统计下测试数据复制、使用和删除情况，方便于审查追踪。在软件转移至生产环境前进行测试在软件程序上线投入使用之前，必需采取切实方法确保这些软件接收了足够测试和统计。不然就有可能造成很严重问题，甚至造成企业日常运行中止。必需牢靠树立类似见解。应用系统安全质量判定现在国际上公认开发质量验证标准关键有两种，能够依据这两种标正确定系统是否已经达成了这两种标准要求：ISO9000认证体系