IT应急计划过程
本节描述了制定和维护有效的IT应急计划的过程。这里表述的过程对所有的IT系统是普遍适用的。过程有以下七步：
1. 制定应急计划策略条款
2. 进行业务影响分析（BIA）
3. 确定防御性控制
4. 制定恢复策略
5. 制定IT应急计划
6. 计划的测试、培训和演练
7. 计划的维护
这些步骤体现了全面IT应急计划能力的关键因素。本节将讨论七个步骤中的六个。由于计划制定是IT应急计划的核心，所以包含在单独的章节中，也就是在第四节讨论计划的制定。计划过程的职责一般会落在做为“计划协调人”或“应急计划制定人”的身上，他们通常是职能或资源部门的经理。协调人在其他相关系统或业务处理部门的职能经理和资源经理协助下制定应急策略。应急计划协调人通常管理应急计划的制定和执行。所有的主要应用和通用支持系统都应该有应急计划。图3-1
描述了应急计划的过程。
3.1 制定应急计划策略条款
为了确保机构应急计划需求的有效性和能够被相关人员充分理解，应急计划必须建立在清晰定义的策略之上。应急计划策略描述应该定义机构整体的应急目标并建立IT应急计划的整体框架和职责。为了确保成功，高级管理层特别是首席信息官（CIO）必须支持应急项目。这些官员应该参与到制定项目策略、结构、目标、角色和职责的过程中。应急策略至少要遵循1.1节中列出的文档所包含的联邦指导方针；机构应该对其IT系统、操作和需求进行评估以确定是否需要更多的应急计划需求。关键的策略因素如下：
-
角色和职责
-
应急计划所涉及的平台和机构功能的类型范围
-
资源需求
-
培训需求
-
演练和测试进度表
-
计划维护进度表
-
备份和备份介质存储频率
在IT应急策略和项目的制定中，应该与相关的机构活动协调一致，这些活动包括IT安全、物理安全、人力资源、IT操作和紧急事件准备活动。IT应急活动应该和这些领域的项目需求相一致，应急人员应该与来自各领域的代表进行协调以便对策略、项目和能力的更新和发展保持了解。应急计划的编写必须和其它系统相关计划进行协调。其中包括如下计划：
3.2 进行业务影响分析
在应急计划过程中BIA是一个关键步骤。BIA使应急计划协调人可以完全掌握系统需求、过程及其相关性的特点并使用这些信息来确定应急需求和优先顺序。BIA的目的是将特定的系统组件与其提供的关键服务联系起来，并基于这些信息了解系统部件中断所产生的影响的特点。应该将B
IA的结果合理地应用于机构的COOP、BCP和BRP的分析和策略制定工作中。本节概述的BIA过程的例子，见图3-2，帮助应急计划协调人安排和完成其应急计划的制定活动以便制定出更有效的计划
。在附录B中包含了一个BIA过程实例和BIA模板范例。
3.2.1 确定关键IT资源
IT系统有可能非常复杂，包含大量的部件、接口和程序。系统经常要完成多个任务，这些任务关系到系统服务或能力的不同侧重点。这是BIA的第一步，是对IT系统进行评估以确定系统所执行关键功能并确定执行这些功能所需的特定系统资源。完成此步骤通常需要两项活动内容：
-
应急计划协调人应确定和协调与系统有关的内部和外部联系点（POC）以确定它们对相关IT系统的依赖或支持方式的特点。在确定联系时，包含向系统提供信息和从系统接受信息的机构以及任何支持互联系统
的联系是重要的。这种协调应该使系统管理者能够确定系统所提供的所有支持的特点，包括安全的、管理的、技术的和操作的需求。
-
应急计划协调人应该对系统进行评估以便将这些关键服务和系统资源联系起来。此分析通常要确定诸如电源、电信连接和环境控制之类的基础需求。特定的IT设备，诸如路由器、应用服务器和认证服务器等通常被认为是很重要的。此分析还可能要确定某些IT部件，诸如打印机或打印服务器，这类部件并不是关键服务所必须的。
3.2.2 确定中断影响和允许的中断时间
在这一步骤中，应急计划协调人应该分析在上一个步骤中确定的关键资源并确定如果给定的资源被中断或遭到破坏对IT运行所产生的影响。分析应该从两个方面评估中断的影响。
应急计划协调人应该通过对系统无法运行所产生的费用与恢复系统 所需资源的费用进行平衡以确定恢复系统的最佳平衡点。这可以通过使用一个简单的图表，如图3-3中的例子来描述。两条线相交的点将定义机构允许系统被中断所付出的代价。
3.2.3 制定恢复优先级
上一个步骤中确定的中断影响和允许的中断时间使得应急计划协调人可以制定在应急计划被启动 时相关人员所要执行的恢复策略并确定其优先级。例如，如果在中断影响步骤中确定系统必须在4个小时之内恢复，应急计划协调人将需要采取措施满足这一需求。同样的，如果多数系统部件可以容许24小时中断但关键部件只能够停用8个小时，应急计划协调人将为关键部件优先提供所需资源。通过对恢复策略排定优先级，应急计划协调人可以根据应急资源的分配和支出做出更准确、更符合实际的决定，以节约时间、精力和费用。
3.3 确定防御性控制
正如3.2节中指出的那样，BIA可以为应急计划协调人提供关于系统可用性和恢复需求的关键信息。在一些情况下，BIA中确定的中断影响可以通过遏制、探测和／或降低对系统影响的防御性措施予以消减或清除。在可行和比较划算的情况下，防御性方法要比中断后为了恢复系统所采取的活动更好。有很多防御性控制可供选择，它依赖于系统类型和配置；但是一些常用措施如下所列：
防御性控制应该被记录在应急计划中，应该对系统相关的人员进行培训使他们知道如何以及何时使用这些控制手段。这些控制手段应该得到维护使其处于良好的状态以确保它们在紧急情况中的有效性。
3.4 制定恢复策略
3.5 计划的测试、培训和演习
计划的测试是有效的应急能力的关键要素。测试能够确定和解决计划的缺陷。测试还协助评估恢复人员快速有效实施计划的能力。每一个IT应急计划要素都应该得到测试以确保各个恢复规程的正确性和计划整体的有效性。应急测试应该涉及到以下领域：
-
在备用平台上使用备份介质进行系统恢复
-
在恢复团队之间进行协调
-
内部和外部的连接性
-
使用备用设备的系统性能
-
正常操作的恢复
-
通知规程
为了能从测试中得到最大价值，应急计划协调人应制定测试计划，测试计划应设计为对所选择的测试要素有明确的测试目标和成功标准。测试目标和成功标准的使用可以增加每个测试要素的有效性并对整个计划进行评估。测试计划应该包括每个测试的详细的事件表和测试的参与者。测试计划还应该清晰地描述范围、场景和后勤。场景可以选择为最糟糕的事故或最有可能发生的事故。它应尽量模仿真实情况。有两种基本的演练方式：
测试的预演对团队成员来说是有益的，这样可以使他们做好精神准备并有时间对工作负荷进行优化调整。由于缺席或测试与其工作存在冲突，有一些团队成员很可能无法使用。人员的可用性问题有助于计划发现实际响应中可能遇到的情况，这样就为计划的修改提供了重要的参考依据。演练不能打断正常的运行是很重要的。如果在备用设施进行测试，应急计划协调人应该协调测试日期和设施运行的关系
。测试结果和学习到的经验应该记录到文档中并由测试的参与者或其他适当人员进行检查。在测试中和测试后检查中收集到的有助于提高计划效率的信息应该添加到应急计划中。
对于应急计划职责的培训应该是对测试的补充。培训至少每年举办一次；拥有计划规定职责的新雇员应该在被雇用后接受短期培训。和应急计划相关的人员所接受的培训最终应该使得他们能够无需实际文档的协助就能够执行相应的恢复规程。这在由于灾难的影响造成最初几个小时里无法获得书面或电子版本的计划的情况下具有非常重要的意义
。恢复人员应该得到以下计划要素的培训：
-
计划的目的
-
团队之间的协调与沟通
-
汇报规程
-
安全需求
-
团队特有的处理过程（通知／启动、恢复和重建阶段）
- 个人职责（通知／启动、恢复和重建阶段）
3.6 计划的维护
为了更加有效,计划必须被维持在能够正确反映系统需求、规程、机构架构和策略的就绪状态。由于业务需要的转移、技术的更新或新的内外政策会造成IT系统的频繁变化。所以，应急计划的定期检查和更新是至关重要的，应该做为机构变化管理过程的一部分以确保新的信息能够被添加进来，应急措施能够根据需要被修订。计划应该至少每年进行一次针对正确性和完整性的检查，在计划的任何部分发生重大变化时也应该进行，这是一项基本的要求。某些部分应该得到更频繁的检查，如联络清单。根据系统类型和重要程度的不同，对计划内容和规程的评估可能会更加频繁。计划的检查至少要关注以下内容：
- 运行需求
- 安全需求
- 技术规程
- 硬件、软件和其它设备（类型、规格和数量）
- 团队成员的姓名和联络信息
- 供应商，包括备用和离站供应商POC的姓名和联络信息
- 备用和离站设施需求
- 关键记录（电子的或硬拷贝）
由于IT应急计划包含潜在的敏感操作和个人信息，计划的分发应该根据需要进行标记和控制。通常，计划的副本被提供给恢复人员存放于家中和办公室里。副本也可以和备份介质一起存放于备用站点。将计划副本存放于备用站点确保了在发生灾难无法使用计划原件时的可用性和良好状态。。应急计划协调人应对计划副本的分发情况保持记录。其它需要和计划一同存放的信息包括供应商合同（SLA和其它合同）、软件授权证书、系统用户手册、安全手册和操作规程。
计划、策略和政策的变化应该由应急计划协调人进行协调，如果需要，协调人应该与和计划或项目相关的代表就变化情况进行沟通。应急计划协调人应该使用变化记录对计划更改进行记录，变化记录包含页码、变化备注和变化日期。表3-3中描述的变化记录应该被综合到4.1节中论述的计划中。
应急计划协调人应该经常协调相关的内部、外部机构和系统POC之间的关系，确保这些机构中的变化造成的影响能够在应急计划中反映出来。应该执行严格的版本控制，在得到新计划或计划内容时应急计划协调人应该要求相关人员返还老的计划或计划内容。
应急计划协调人还应该对支持信息进行评估以确定信息具有充分的及时性和连续性以满足系统需求。这些信息包括以下内容：
-
备用站点合同，包括测试时间
-
离站存储合同
-
软件授权证书
-
MOU或供应商SLA
-
硬件和软件需求
-
系统互联协议
-
安全需求
-
恢复策略
-
应急政策
-
培训和意识强化资料
-
测试范围
虽然有些变化可能比较明显，另一些则需要额外分析。应该根据新的信息确定新的应急需求或优先级，对BIA进行定期检查和更新。在可以使用新技术的情况下，防御性控制可能会被加强，恢复策略可能会被修改。另外，NIST特别报告书800-26《信息技术系统的安全自我评估》
提供了协助确定应急计划内容有效性的检查列表。
|
