应用系统安全改造监督规范.pdf

某某石油管理局公司标准某某石油管理局公司标准应用系统安全改造监督规范应用系统安全改造监督规范1 1 合用范围合用范围本标准规定了某某石油管理局应用系统安全改造监督规范。本标准合用于某某油田（公司内部）应用系统安全改造管理方的权责、施工方的权责、施工方资格审查、施工方方案预审、施工方案实行、评估与审计、管理方应当注意的事项、认证与批准等。2 2 规范解释权规范解释权本规定合用于某某油田管理局信息安全管理中心和下属各单位中心机房。3 3 管理方的权责管理方的权责1)根据工作量的大小，应成立专门的或者兼职的领导小组督察改造工作。2)提供信息系统规定达成的安全目的（参见其它规范），以及评估标准。3)安全目的，以及改造措施的设定要综合考虑上级和下级相关单位。4)对系统安全目的，以及拟采用的安全方案应当上报上级机关审批。5)对重要的应用系统的安全改造，有权利和责任对施工方案做出评审。6)对施工方的申请，规定有义务做出积极的响应。7)提供系统安全现状，根据工作量的大小，以书面形式提交。8)提供系统安全规范。9)提供系统安全目的。10)提供系统软、硬件设备的说明书，必要的技术资料。11)提供系统改造时必要的用户名，口令、密码。12)提供系统改造时资源设备的保护规定。13)提供必要的场地以及配合工作人员。14)提供基础的工作环境，比如电源，网络接口等。4 4 施工方的权责施工方的权责1)提供必要的资格证明。2)提供具体的施工方案。3)规定对重要设备的物理安全做出承诺。4)对改造中涉及到的重要系统，数据的访问有义务向管理方申请，并作记录。5)对重要系统参数的设立，修改有义务向施工方做出书面说明。6)改造后规定写出总结文档。5 5 施工方资格审查施工方资格审查1)根据改造工作的任务量，安全规定级别酌情使用如下规范：2)施工方规定有合法的身份证明。3)施工方必须有一定的从事该业务的资质和经济实力。4)必须有与其业务量相适应的工程技术人员和技术工人。5)从事安全改造的技术人员规定政治过关，遵纪守法。6)对涉及财务等重要系统的安全改造，不能由内部人员从事。6 6 施工方方案预审施工方方案预审1)方案中要对安全的需求，做出分析说明并且提出明确的安全策略。2)方案规定对方案实行后可达成的安全目的做出说明或解释。3)规定方案对每一个安全策略，规定对其安全功能和代价做出具体的说明。4)规定方案对改造中将要采购的软件、硬件设备做出说明。5)规定方案对改造中将涉及到的设施改动做出说明。6)规定方案对改造工程做出总体预算。7)规定方案对改造工期安排，改造对现行业务的影响限度作具体说明。8)规定方案对改造中规定管理方承诺的服务做出说明。9)规定方案对改造过程中也许出现的意外情况（例如，系统死锁），以及相关的防护、补救措施做出说明。10)管理方应当根据实际情况评审方案。11)权衡施工方案的实行对业务导致的影响。12)权衡安全需求与所付出的资金的代价。13)权衡改造中的风险代价与业务连续性和安全性规定。14)权衡给施工方提供的服务与也许导致的安全隐患之间的矛盾。15)权衡新设备的运用率与业务安全需求之间的关系。7 7 施工方案实行施工方案实行1)规定监督施工进度，工期原则上不能延期。2)工程间歇，系统不能停留在不安全状态。3)对重要的系统，在安全改造之前，应当对信息系统资源和施工方人员进行登记，备案。4)对改造中涉及到的重要数据，必须备份。5)启用新的应用软件，应当交管理方系统维护人员安装到业务系统，并做好日记记录。6)对存有重要数据的故障设备修理时，管理方必须安排专人在场监督。7)对改造过程中出现的意外情况，规定做好日记记录。8 8 验收与测试评估与审计验收与测试评估与审计1)应用系统安全改造施工之后，施工方应当归还相关资料，提交工程报告。2)应用系统安全改造施工之后，管理局信息中心依据协议对工程进行验收。3)测试过程必须在管理局技术委员会的监督下进行，由管理局信息中心与施工方共同参与测试。4)管理局技术委员会相应用系统的安全性能以及安全等级做出评估，保证系统安全改造后的安全性能和等级达成协议中所规定的安全目的。5)考察应用系统是否达成规定的安全规定并作测试纪录。6)改造施工后，测试操作系统加固以及安装最新的安全补丁情况是否达成所规定的安全目的。7)改造施工后，施工方就还也许出现的安全漏洞以及补救措施等向管理局信息中心进行说明，避免出现不必要的操作错误和安全隐患。8)应用系统授权人应当考察评估结果，用以决定是否可以接受系统运营的风险。9 9 管理方应当注意的事项管理方应当注意的事项1)系统安全改造之后，对分派给施工方人员的权力应当交还系统管理员。2)系统改造之后，必须对系统日记做出审计。3)系统管理员对超级用户口令，其它用户名和口令等登录信息的进行重新设立。4)系统管理员可以根据需要对其它的网络进出口的口令重新设立。1010 认证与批准认证与批准认证与批准是针对自动信息系统和其他保护措施的技术或非技术安全特性的一种复杂评估。其目的是拟定某一特定设计和实行满足指定的安全需求集的限度，并由指定的批准授权机构籍此正式宣布某信息系统被获准可在某一可接受的风险级别上运营。CA（Cetification Authority）是负责执行对这些安全特性与其它保护措施（用于支持批准过程）进行评估的官方。它用来拟定特定设计与系统实行对指定安全需求的满足限度。最初的认证任务涉及：系统体系结构分析；软件设计分析；网络连接规则一致性分析；集成产品的完整性分析；生命周期管理分析；脆弱性评估。一个经受过认证与批准的系统应当有用于支持每个任务的正式文档、文档化的安全说明、复杂的测试计划和说明所有网络与其它互连规定均被实现的书面说明。可以对特定的认证任务进行定制以适合系统的项目战略、生命周期管理过程以及信息系统在其生命周期中的位置。也可定制满足系统开发行为的认证任务，确信它与整个系统行为相关，并为保证这些行为与书面的文档相一致而提供了满足规定的分析。脆弱性评估评估了与保密性、完整性、可用性、可审计性和推荐相关的安全漏洞。为保护相应的系统价值，授权机构应当决定可承受的风险级别。脆弱性评估重要关注实现系统安全需求的过程。评估结论被用于判断信息系统是否已经准备好进行正式的认证评估与测试。最终的认证任务涉及：安全测试与评估；渗透性测试；调查、研究、和控制危及到通过电信和自动信息系统装备来发布信息的安全规定。系统管理分析；站点批准调查；应急计划评估；基于风险的管理审查。假如 CA 断定信息系统满足系统安全授权协议的技术规定，便会发布一个系统证明。该证明说明了信息系统与协议的安全规定一致。CA 也可以制订补充建议以提高系统的安全状况。对于将来的系统升级与改变管理决策而言，这样的建议还应当提供一个输入接口。CA 的建议、指定的批准授权机构的操作授权、支持文档和系统安全授权协议共同形成了批准包。支持文档可根据系统类型不同而不同。那些文档，最小而言，应当涉及安全调查结果、缺陷和操作风险。批准包必须涉及用于支持所建议的决策的所有信息。假如决策希望得到批准，则它应当涉及安全参数，这些参数决定了信息系统可授权操作的环境。假如系统不满足系统安全授权协议所陈述的规定，但任务的关键限度规定系统必须投入运营，也可发布一个临时许可。最后批准应当三年有效，或在某个重大改变需要产生一个新批准之前一直有效。或者是通过认证请求通告，或者是系统需要周期性重新评估或系统表现出有安全问题，均会进行再评估。周期性评估是缺省的选择，而很多再评估则基于触发事件。应用系统信息技术安全认证和鉴定过程应用系统信息技术安全认证和鉴定过程应用系统信息技术安全认证和鉴定过程，合用于所有在整个生命周期中需要 C&A 的系统。过程提成逻辑上的阶段序列，它们会引导系统达成其最终批准。图(1)给出了这些阶段：阶段 1：定义；阶段 2：核算；阶段 3：确认；阶段 4：后批准。定义，涉及书面的系统安全授权协议是在项目管理员、指定的批准授权机构、CA 和用户代表之间基于系统任务、目的环境、目的结构和安全策略的描述之上的一种协定。系统安全授权协议描述了计划制定和认证行为、资源以及要用于支持认证与批准的文档。在阶段 2 中验证系统的安全功能和体系是否满足系统关于信息解决和安全的功能规定。该过程行为需要许多用于指导、控制并管理系统开发、设计、操作和废除的系统工程文档。这些行为的结果也许改变或者保持最初的系统安全授权协议、系统功能和系统结构。所以系统安全工程师应当开发测试计划和过程。这些测试计划和过程应涵盖系统功能、系统完整性与安全一致性等内容。系统安全工程师还应当评估和描述作为设计结果而保存的残余风险的级别。第 3 阶段的行为：确认，将系统设计变成现实，验证系统设计是对的的，并且确认系统满足规定。这是一个验证的、完整的、有效化的、认证与批准的系统的最高级段。第 4 阶段的行为：重要解决一致性确认过程。一致性确认检查过程着重于系统周期性重批准的管理和在已部署的系统中结合能对风险做出反映的不同方法。可以使用传统的检测手段。但是，以“行为文档”可用性为基础的方法和第 3 阶段中对系统的检测都是很重要的可选方法。此外，假如发现一个系统有更多的基于非重大改变的有限的风险，则可以适当的简化相应的检测过程。1111 生效日期生效日期应用系统信息技术安全认证和鉴定过程流程图应用系统信息技术安全认证和鉴定过程流程图任务需要注册协商YesYes协议No系统安全