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

1、某某石油管理局企业标准应用系统安全改造监督规范1 适用范围本标准规定了某某石油管理局应用系统安全改造监督规范。本标准适用于某某油田(企业内部)应用系统安全改造管理方的权责、 施工方的权责、施工方资格审查、施工方方案预审、施工方案实施、评估与 审计、管理方应该注意的事项、认证与批准等。2 规范解释权本规定适用于某某油田管理局信息安全管理中心和下属各单位中心机房。3 管理方的权责1) 根据工作量的大小，应成立专门的或者兼职的领导小组督察改造工作。2) 提供信息系统要求达到的安全目标(参见其它规范)，以及评估标准。3) 安全目标，以及改造措施的设定要综合考虑上级和下级相关单位。4) 对系统安全目标，

2、以及拟采用的安全方案应该上报上级机关审批。5) 对重要的应用系统的安全改造，有权利和责任对施工方案做出评审。6) 对施工方的申请，要求有义务做出积极的响应。7) 提供系统安全现状，根据工作量的大小，以书面形式提交。8) 提供系统安全规范。9) 提供系统安全目标。10) 提供系统软、硬件设备的说明书，必要的技术资料。11) 提供系统改造时必要的用户名，口令、密码。12) 提供系统改造时资源设备的保护要求。13) 提供必要的场地以及配合工作人员。14) 提供基础的工作环境，比如电源，网络接口等 。4 施工方的权责1) 提供必要的资格证明。2) 提供详细的施工方案。3) 要求对重要设备的物理安全做出

3、承诺4) 对改造中涉及到的重要系统，数据的访问有义务向管理方申请，并作记 录。5) 对重要系统参数的设置，修改有义务向施工方做出书面说明。6) 改造后要求写出总结文档。5 施工方资格审查1) 根据改造工作的任务量，安全要求级别酌情使用如下规范：2) 施工方要求有合法的身份证明。3) 施工方必须有一定的从事该业务的资质和经济实力。4) 必须有与其业务量相适应的工程技术人员和技术工人。5) 从事安全改造的技术人员要求政治过关，遵纪守法。6) 对涉及财务等重要系统的安全改造，不能由内部人员从事。6 施工方方案预审1) 方案中要对安全的需求，做出分析说明并且提出明确的安全策略。2) 方案要求对方案实施

4、后可达到的安全目标做出说明或解释。3) 要求方案对每一个安全策略， 要求对其安全功能和代价做出详细的说明4) 要求方案对改造中将要采购的软件、硬件设备做出说明。5) 要求方案对改造中将涉及到的设施改动做出说明。6) 要求方案对改造工程做出总体预算。7) 要求方案对改造工期安排，改造对现行业务的影响程度作详细说明。8) 要求方案对改造中要求管理方承诺的服务做出说明。9) 要求方案对改造过程中可能出现的意外情况(例如，系统死锁)，以及 相关的防护、补救措施做出说明。10) 管理方应当根据实际情况评审方案。11) 权衡施工方案的实施对业务造成的影响。12) 权衡安全需求与所付出的资金的代价。13)

5、权衡改造中的风险代价与业务持续性和安全性要求。14) 权衡给施工方提供的服务与可能造成的安全隐患之间的矛盾。15) 权衡新设备的利用率与业务安全需求之间的关系。7 施工方案实施1) 要求监督施工进度，工期原则上不能延期。2) 工程间歇，系统不能停留在不安全状态。3) 对重要的系统，在安全改造之前，应当对信息系统资源和施工方人员进 行登记，备案。4) 对改造中涉及到的重要数据，必须备份。5) 启用新的应用软件，应当交管理方系统维护人员安装到业务系统，并做 好日志记录。6) 对存有重要数据的故障设备修理时，管理方必须安排专人在场监督。7) 对改造过程中出现的意外情况，要求做好日志记录。8 验收与测

6、试评估与审计1) 应用系统安全改造施工之后， 施工方应该归还相关资料， 提交工程报告2) 应用系统安全改造施工之后， 管理局信息中心依据合同对工程进行验收。3) 测试过程必须在管理局技术委员会的监督下进行，由管理局信息中心与 施工方共同参与测试。4) 管理局技术委员会对应用系统的安全性能以及安全等级做出评估，保证 系统安全改造后的安全性能和等级达到合同中所规定的安全目标。5) 考察应用系统是否达到要求的安全要求并作测试纪录。6) 改造施工后，测试操作系统加固以及安装最新的安全补丁情况是否达到 所规定的安全目标。7) 改造施工后，施工方就还可能出现的安全漏洞以及补救措施等向管理局 信息中心进行说

7、明，避免出现不必要的操作错误和安全隐患。8) 应用系统授权人应该考察评估结果，用以决定是否可以接收系统运行的 风险。9 管理方应该注意的事项1) 系统安全改造之后，对分配给施工方人员的权力应当交还系统管理员。2) 系统改造之后，必须对系统日志做出审计。3) 系统管理员对超级用户口令，其它用户名和口令等登录信息的进行重新 设置。4) 系统管理员可以根据需要对其它的网络进出口的口令重新设置。10 认证与批准认证与批准是针对自动信息系统和其他保护措施的技术或非技术安全特 征的一种复杂评估。其目的是确定某一特定设计和实施满足指定的安全需求 集的程度，并由指定的批准授权机构籍此正式宣布某信息系统被获准可

8、在某 一可接受的风险级别上运行。 CA (Cetification Authority )是负责执行对这些 安全特征与其它保护措施(用于支持批准过程)进行评估的官方。它用来确 定特定设计与系统实施对指定安全需求的满足程度。最初的认证任务包括：? 系统体系结构分析；? 软件设计分析；? 网络连接规则一致性分析；? 集成产品的完整性分析；? 生命周期管理分析；? 脆弱性评估。一个经受过认证与批准的系统应该有用于支持每个任务的正式文档、文 档化的安全说明、复杂的测试计划和说明所有网络与其它互连要求均被实现 的书面说明。可以对特定的认证任务进行定制以适合系统的项目战略、生命 周期管理过程以及信息系统在

9、其生命周期中的位置。也可定制满足系统开发 行为的认证任务，确信它与整个系统行为相关，并为确保这些行为与书面的 文档相一致而提供了满足要求的分析。脆弱性评估评估了与保密性、完整性、可用性、可审计性和推荐相关的 安全漏洞。为保护相应的系统价值，授权机构应该决定可承受的风险级别。 脆弱性评估主要关注实现系统安全需求的过程。评估结论被用于判断信息系 统是否已经准备好进行正式的认证评估与测试。最终的认证任务包括：? 安全测试与评估；? 渗透性测试；? 调查、研究、和控制危及到通过电信和自动信息系统装备来发布信息 的安全要求。? 系统管理分析；? 站点批准调查；? 应急计划评估；? 基于风险的管理审查。如

10、果 CA 断定信息系统满足系统安全授权协议的技术要求， 便会发布一 个系统证明。该证明说明了信息系统与协议的安全要求一致。 CA 也可以制 订补充建议以提高系统的安全状况。对于将来的系统升级与改变管理决策而 言，这样的建议还应该提供一个输入接口。CA 的建议、指定的批准授权机构的操作授权、支持文档和系统安全授 权协议共同形成了批准包。 支持文档可根据系统类型不同而不同。 那些文档， 最小而言，应该包括安全调查结果、缺陷和操作风险。批准包必须包括用于 支持所建议的决策的所有信息。如果决策希望得到批准，则它应该包括安全 参数，这些参数决定了信息系统可授权操作的环境。如果系统不满足系统安 全授权协议

11、所陈述的要求，但任务的关键程度要求系统必须投入运行，也可 发布一个临时许可。最后批准应该三年有效， 或在某个重大改变需要产生一个新批准之前一 直有效。或者是通过认证请求通告，或者是系统需要周期性重新评估或系统 表现出有安全问题，均会进行再评估。周期性评估是缺省的选择，而很多再 评估则基于触发事件。应用系统信息技术安全认证和鉴定过程应用系统信息技术安全认证和鉴定过程， 适用于所有在整个生命周期中 需要 C&A 的系统。过程分成逻辑上的阶段序列，它们会引导系统达到其最 终批准。图 (1)给出了这些阶段：? 阶段 1 ：定义；? 阶段 2 ：核实；? 阶段3:确认；? 阶段4:后批准。定义，包括书面

12、的系统安全授权协议一一是在项目管理员、指定的批准授权机构、CA和用户代表之间基于系统任务、目标环境、目标结构和安全 策略的描述之上的一种协定。系统安全授权协议描述了计划制定和认证行 为、资源以及要用于支持认证与批准的文档。在阶段2中验证系统的安全功能和体系是否满足系统关于信息处理和 安全的功能要求。该过程行为需要许多用于指导、控制并管理系统开发、设 计、操作和废除的系统工程文档。这些行为的结果可能改变或者保持最初的 系统安全授权协议、系统功能和系统结构。所以系统安全工程师应该开发测 试计划和过程。这些测试计划和过程应涵盖系统功能、系统完整性与安全一 致性等内容。系统安全工程师还应该评估和描述作为设计结果而保留的残余 风险的级别。第3阶段的行为：确认，将系统设计变成现实，验证系统设计是正确的， 并且确认系统满足要求。这是一个验证的、完整的、有效化的、认证与批准 的系统的最高级段。第4阶段