IT应急计划的制定
本节论述组成应急计划的关键要素。正如第3节描述的那样，IT应急计划的制定是执行全面应急计划项目过程中的关键一步。计划包括与IT系统中断后进行恢复相关的、详细的角色、职责、团队和规程。应急计划应该描述被设计用来支持应急操作的技术能力。应急计划应该适应机构及其需求。应急计划需要在详细程度和灵活程度之间取得平衡；通常是计划越详细，其方法就越缺乏弹性和通用性。这里提供的信息是一种指导性的，本文中计划的格式需要进行修改以更好地满足用户特定的系统、操作和机构需求。机构可以使用附录A中提供的模板制定自己系统的IT应急计划。附录D论述了IT应急计划中制定人员协调计划时需要考虑的事项。如图4-1所示，本指南确定了应急计划的五个主要部分。支持信息和计划附录部分提供了确保计划全面性的重要信息。通知／启动、恢复和重建阶段涉及到在机构遇到系统中断或紧急情况时要采取的特定行动。计划的每一部分都在本节中讨论
计划的格式应该能够为事件中不熟悉计划的人员或被要求进行恢复操作的系统提供快速明确的指导。计划应该明确、简洁、易于在紧急情况下执行。如果可能，应该使用检查列表和详细规程。简明和组织良好的计划可以减少计划变得过于复杂和令人迷惑的可能性。
4.1 支持信息
支持信息部分包括介绍和操作的概念部分，这个部分提供了重要的背景或相关信息，使应急计划更容易被理解、实施和维护。这些细节协助对指南的适用性的理解，协助在使用计划中的决策，协助提供和计划相关或在计划范围之外的信息。
《介绍》部分指导读者辨别计划中所包含信息的类型和位置。通常这部分包括目的、适用性、范围、参考／需求和变化记录 。下面描述这些小节。
-
目的 这个小节介绍制定IT应急计划的原因和定义计划的目标。
-
适用性 这个小节描述了受IT应急计划影响的机构。确定所有支持或被IT应急计划支持的相关计划并描述它们之间的关系。这些相关计划应该包含在应急计划的附录中。
-
范围 范围论述计划中涉及到和不涉及的问题、情形和条件。本节确定在系统分布于多个地点时应急计划所涵盖的目标系统和位置。例如，计划可能不会涉及到预计持续时间小于四个小时的短期中断，或者不会涉及到造成IT设施毁灭的灾变性事件。
范围应该涉及到计划中产生的所有假设，如假设在紧急事件中所有的关键人员都可以使用。但是，假设不能用作整个计划的替代。例如，计划不能假设中断只发生在工作时间；根据这样的假设制定应急计划，如果在中断发生在非工作时间，应急计划协调人可能就无法有效地恢复系统了。
-
参考／需求 这个小节确定应急计划的联邦或部门需求。适用的法律文件将包含本指南1.3节中列出的内容。
-
变化记录 应急计划应该是一个动态的文件，它应该反映系统、操作或机构的变化并随之变化。计划的更改应该记录在计划前部
的变化记录中。
《操作的概念》部分为IT系统、应急计划框架以及响应、恢复和继续活动提供了更多的详细信息。这个部分可以包括以下内容：
-
系统描述 有必要包括涵盖在应急计划中的IT系统的一般描述。描述应包含IT系统架构、位置和任何其它重要的技术考虑事项
。包括安全设备（如防火墙、内部和外部连接）在内的系统架构图是很有用的。系统描述的内容通常可以从系统安全计划中收集。
-
继任序列 继任的顺序在被指定人缺席或无法行为 的事件中确定继续执行应急计划的负责人的人选。
-
职责 职责部分表述应急团队的整体结构，包括各团队的等级划分、协调机制和需求。这个部分也提供应急情况下团队成员角色和职责的概况。团队和团队成员应该被指定在应急计划启动期间所担当的响应和恢复角色。角色应该指定给团队中的职位而不是个人。通过角色而不是姓名列出团队成员不仅可以在成员缺席而无法响应的情况下减少混乱，而且可以帮助减少由于人员调动而造成文件修改的次数。
4.2 通知／启动阶段
通知／启动阶段定义在探测到系统中断或紧急情况发生或即将到来时采取的初步行动。这个阶段包括通知恢复人员、评估系统损害和实施计划的活动。一旦完成了通知／启动阶段的活动，恢复人员将准备在临时基础上执行恢复系统功能的应急措施。
4.2.1 通知规程
事件的发生可能有先兆也可能没有先兆。例如，飓风将影响某个地区或计算机病毒会在某日发作经常会得到事先通知。但是，设备故障或犯罪活动就可能没有先兆。通知规程应该在计划中包含这两种情况。规程应该描述在工作时间和非工作时间通知恢复人员的方法。适当的通知对减少对IT系统的影响是很重要的；在一些情况下，它可以为允许系统人员正常关闭系统避免系统崩溃赢得足够的时间。在灾难发生后，应该通知损害评估小组使其能够确定事态的严重程度和下一步将要采取的行动。损害评估规程在4.2.2节中描述。当损害评估完成后，应该通知相应的恢复和支持小组。
可以通过各种方法完成通知，包括电话、传呼、电子邮件或移动电话 。由于无法确定能否有效回复，所以通过电子邮件发送通知应该谨慎从事。虽然电子邮件具有散发工作通知和个人帐户的潜在有效性，但是无法确定信息是否被查阅。办公邮件帐户经常收到大量的信息造成个人对其帐户的屏蔽；个人邮件账户查阅的频率很低，可能一个星期才查阅一次。如果使用电子邮件做为通知手段，应该要求恢复人员经常和定期查看他们的帐户。在工作时间发送的通知应发送到办公地址，在LAN停顿的事件中可以使用个人电子邮箱传送信息。在影响广泛的灾难中，有效的通知工具是电台、电视广播和Web网站。
通知策略应该定义在事件发生后人员无法联络时的规程。通知规程应该在应急计划中明确描述。一种通用通知方法是呼叫树。这种技术指定特定人员执行通知任务，此人负责通知其它的恢复人员。呼叫树应该包括主要的和备用的联络方法，应该讨论在某个人无法联系上时应该采取的规程。
需要通知的人员应该在计划附录中的联系清单中标明。这个清单确定人员在其团队中的职位、姓名和联络信息（如家庭、工作电话号码及传呼号码、电子邮件地址和家庭地址）。条目可以按照以下格式排列：
系统软件小组
团队负责人－主要
简·琼斯
某路1234号
城市，州，邮政编码
家庭电话：（123）4567890
工作电话：（123）5678901
移动电话：（123）6789012
电子邮件：jones@organization.ext; jones@home.ext
通知还应该发给会因为不知情而受到负面影响的外部机构或互联的伙伴系统。根据中断类型的不同，POC可能具有恢复能力。所以，与外部机构相连的每一个互联系统应互相协助，协助的方式应该根据所提供的系统互联协议确定。这些POC应该被列入计划的附录
中。
通知中所传递的信息类型应该在计划中载明。所传递的信息数量和详细程度可依据被通知的团队而定。根据需要，通知信息可包括以下内容：
-
所发生或将发生的紧急情况的性质
-
死亡或受伤情况
-
任何已知的评估结果
-
响应和恢复的细节
-
何时何地召集会议介绍简况或听取进一步的响应指令
-
在评估期间进行重新部署准备的指令
-
使用呼叫树完成通知的指令（如果需要）
4.2.2 损害评估
要确定应急事件后如何实施应急计划，对系统损害性质和程度的评估是非常重要的。这个损害评估应该在能够确保人员安全这个最优先任务的前提下尽快完成。所以，如果可能，损害评估小组是第一个得到事件通知的小组。损害评估规程对于不同的系统是不同的；但是应该涉及到以下领域：
-
造成紧急情况或中断的原因
-
潜在的附加中断或损失
-
受到紧急情况影响的区域
-
物理构架（如计算机室结构的完整性、电源、电信以及制热、通风和空调［HVAC］的情况）的状况
-
IT设备的总量和功能状态（如具备完整功能、具备部分功能或丧失功能）
-
IT设备及其存货的损失类型（如水害、火灾或热能、物理以及电涌影响）
-
被更换的项目（如硬件、软件、固件或支持材料）
-
估计恢复正常服务所需的时间
在书面计划无法得到的情况下，具有损害评估职责的人员应该了解和能够执行这些规程。一旦系统的影响被确定，就应该将最新信息和对此情况的响应计划通知给适当的团队。通知应该按照4.2.1节中描述的规程执行。
4.2.3 计划的启动
只有当损害评估的结果显示一个或多个系统启动条件被满足时，IT应急计划才应被启动。如果满足启动条件，应急计划协调人或CIO（如果适用）应启动计划
。各机构的启动条件各不相同，应该在应急计划策略条款中予以说明。条件可以基于以下方面：
一旦明确了系统损害，应急计划协调人就可以选择适当的恢复策略 并通知相关的恢复团队。通知应该依据4.2.1节 中叙述的规程。
4.3 恢复阶段
启动应急计划、完成损害评估（如果可能）、通知相关人员和调动相关团队后开始恢复操作。恢复阶段的行动集中于建立临时IT处理能力、修复原系统损害、在原系统或新设施中恢复运行能力的应急措施。在恢复阶段完成时，IT系统将可以运行并执行计划中指定的功能。依据计划中定义的应急策略，这些功能可以包括临时人工处理、在备用系统上恢复和运行或在备用站点重新部署和恢复。具有恢复职责的团队应该在事件初期无法得到书面计划的情况下了解并有能力执行这些恢复策略，并依然能够完成所需的行动。
4.3.1 恢复行动的顺序
当恢复复杂系统如涉及到多个独立部件的WAN时，恢复进程应该反映出BIA中确定的系统优先顺序。行动的顺序应该反映出系统允许的中断时间，以避免对相关系统及其应用的重大影响。规程应该按照逐步和顺序的格式书写以便系统部件能够按照合理的方式恢复。例如，在中断后恢复LAN的过程中，应该首先恢复最关键的服务器，不太关键的设备如打印机可以在其后恢复。同样的，在恢复应用服务器时，规程应该首先涉及到操作系统的恢复和验证然后再恢复应用程序和数据。规程还应该包括如下特定情况发生时各团队之间进行协调的指令：
-
在预期时间段内无法完成行动
-
完成关键步骤
-
必须获得物品
-
其它系统特定的问题
如果情况要求在备用站点恢复系统，就需要运输或获得某些材料。这些事项可能包括从离站存储地点运送数据备份介质、硬件、恢复计划副本和软件程序。规程应该指定适当的团队或团队成员来协调设备、数据和关键记录的运送。需要时应该将适当的参考附录如设备清单或供应商联络信息添加到计划中。规程应该明确描述对恢复系统所需材料的包装、运输和采购需求。
4.3.2 恢复规程
为了进行恢复阶段的操作，应急计划应该提供恢复IT系统或系统部件的详细规程。由于存在大量不同的系统、设置和应用类型，所以本计划指南不提供特定的恢复规程。但是，在第5节中包含各种IT系统类型恢复的详细考虑事项。
规程应该被设定给适当的恢复团队并且通常涉及到以下行动：
-
获得访问受损设施和／或地理区域的授权
-
通知相关系统的内部和外部业务伙伴
-
获得所需的办公用品和工作空间
-
获得和安装所需的硬件部件
-
获得和装载备份介质
-
恢复关键操作系统和应用软件
-
恢复系统数据
-
测试包括安全控制在内的系统功能
-
将系统连接到网络或其它外部系统
-
成功地运行备用设备
恢复规程应该按照直接和逐步的风格书写。为了防止在紧急事件中产生困难或混乱，不能假定或忽略规程的步骤。检查列表的形式有助于撰写顺序的恢复规程和在系统无法正常恢复时解决问题。以下例子提供了LAN恢复小组规程的一部分检查列表。
4.4 重建阶段
在重建阶段，恢复行动终止并将正常操作转回机构设施中。如果原机构设施无法恢复，这个阶段的行动也可以在支持系统处理需求的新设施中进行。当原站点或新站点恢复到可以支持IT系统及其正常处理的水平时，系统就可以转回原站点或新站点。在完成主系统恢复和测试以前，应急系统应该继续运行。重建阶段应该设定负责恢复或替换站点和IT系统的团队。下面是这个阶段进行的主要行动：
-
确保充足的基础设施支持，如电源、供水、电信、安全、环境控制、办公设备和用品
-
安装系统硬件、软件和固件。此行动应该包括与恢复阶段类似的详细恢复规程
-
与网络部件和外部系统建立连接和接口
-
测试系统运行以确保完全的功能性
-
备份应急系统中的运行数据并上载到被恢复系统中
-
关闭应急系统
-
终止应急操作
-
对应急站点的所有敏感材料加以保护、清除和／或重新配置
-
安排恢复人员回到原设施
在这些文档无法得到的事件中，这些团队应该在没有书面计划的情况下了解并且有能力执行所要求的功能。
4.5 计划的附录
应急计划的附录提供了计划主体不包含的关键细节。虽然附录应该反映目标系统在技术、操作和管理上的特殊应急需求；但是一些附录在IT应急计划中经常出现。常见的应急计划附录包括以下几种：
-
应急计划团队成员的联络信息
-
供应商联络信息，包括离站存储和备用站点的POC
-
系统恢复或处理的标准操作规程和检查列表
-
支持系统运行所需的硬件、软件、固件和其它资源的设备和系统需求清单。每个条目应该包含详细内容，包括型号或版本号、规格说明和数量
-
供应商SLA、与其它机构的互惠协议和其它关键记录。
-
备用站点的描述和说明
-
在计划阶段进行的BIA，包含关于系统各部分相互关系、风险、优先级别和影响的有价值的信息。BIA应该做为一个附录包含在计划中以便在启动计划时参考
|
