文章翻译：陈海燕，CISSP（
phrackchen@hotmail.com）
(《计算机安全介绍：NIST手册》第十一章)
英文版PDF
注：以下内容因排版原因有所省略。
计算机安全事件是可能会中断计算机运行从而中断关键任务和业务功能的事件。这样的事件可以是电力中断、硬件故障、火灾或暴雨。如果事件是毁灭性的，经常被称为灾难。
为了避开紧急事件和灾难或者减少它们造成的损害，机构可以预先采取步骤控制事件。这通常被称为应急计划，这个活动与事件处理，也就是处理诸如黑客和病毒这样的恶意技术威胁活动紧密相关。
应急计划不仅涉及到计划在灾难将数据中心摧毁的情况下向离站设施迁移。它还涉及到如何在或大或小的的中断事件中保持机构关键功能的运行。应急计划的这种广泛性建立在对整个机构进行计算机支持的基础之上。
本章介绍应急计划过程的六个步骤：
1. 识别任务或业务关键的功能。
2. 识别支持这些关键功能的资源。
3. 预测潜在的紧急事件或灾难。
4. 选择应急计划策略。
5. 实施应急计划策略。
6. 测试和修订策略。
11.1 步骤1：识别任务或业务关键功能
如果不进行明确识别，保护机构任务或业务的连续性就是非常困难的。管理者通常要将其视野扩展到其控制范围之外来理解机构。机构关键任务或业务功能的定义经常被称为业务计划。
因为业务计划的制定将被用于支持应急计划，所以不仅需要识别关键的任务和业务，还需要排定它们的优先顺序。对于大多数机构来说，为每一项功能建立充分的冗余过于昂贵。在灾难事件中，将不会执行某些功能。如果设定了适当的优先顺序（并得到高级管理层的批准），这可能意味着机构具有幸免于灾难的非凡能力。
11.2 步骤2：识别支持关键功能的资源
识别关键人物和业务功能后，需要识别支持资源，如每种支持资源使用的时间段（如资源是持续需要或是仅在月末需要？），以及缺少资源对任务或业务的影响。在识别资源中，常见的问题是不同管理人会忽视不同的资源。这些资源中的很多不是计算机资源。应急计划应该涉及到执行功能所需的所有资源，无论其是否与计算机直接相关。
所需资源的分析应该由了解所执行功能以及各种资源与其它资源关系和其它关键关系的人进行。这使机构能够设定优先顺序，因为不是所有资源的所有成分都是对关键功能至关重要的。
11.2.1 人力资源
人或许是机构中最明显的资源。一些功能需要特定人员的工作，一些需要专业技术人员，而一些只需要得到一般技能培训的人员。在信息技术领域，人力资源包括操作员（如技术员或系统程序员）和用户（如数据录入员或信息分析员）。
11.2.2 处理能力
传统的应急计划关注处理能力（即数据中心是否停止运作，依赖它的应用怎样才能继续运行？）。虽然数据中心的备份需要仍然很关键，如今其它一些备用措施也很重要。局域网（LAN）、小型机、工作站和个人计算机以各种集中和分布的形式执行着关键任务。
11.2.3 自动化应用和数据
计算机系统运行处理数据的应用程序。没有应用和数据的当前电子版本，计算机化的处理就不可能进行。如果处理在备用硬件上执行，应用必须与备用硬件、操作系统和其它软件（包括版本和配置），以及众多的技术性因素兼容。由于其复杂性，所以通常需要定期验证兼容性（参见步骤6，测试和修订。）
11.2.4 基于计算机的服务
机构使用很多不同类型的基于计算机的服务来执行其功能。两个最重要的服务一般是通讯服务和信息服务。通讯服务可以进一步被分为数据和语音通讯；但是在很多机构这些是由统一的服务部门管理的。信息服务包括机构外部的任何信息来源。这些来源中的很多正在变得自动化，包括在线政府和私营数据库、新闻服务和公告牌。
11.2.5 物理基础设施
为了使人们工作得更有效率，他们需要安全的工作环境和适当的设备和支持功能。这包括办公空间、暖气、冷气、通风、电力、供水、下水、其它支持功能、办公桌、电话、传真机、个人电脑、终端、邮政服务、文件柜和许多其它物品。另外，计算机也需要空间和支持功能，如电力。用于存储应用和数据的电子和纸介质也有物理需求。
11.2.6 文档和文书
许多功能依赖于关键记录和各种文档、文书或表格。这些记录可能因为法律需要（如能够创建贷款签名复件）或者它们是信息的唯一记录而显得重要。可以在纸、缩微胶片、缩微胶卷、磁介质或光盘上维护记录。
11.3 步骤3：预期潜在紧急情况或灾难
虽然想到所有可能出问题的事情是不可能的，但是我们还是应尽可能识别广泛的问题。设定情景将帮助机构制定计划来处理可能出现的广泛问题。
场景应该包括小的和大的紧急事件。有些一般的紧急事件场景是显而易见，而那些不太明显的紧急事件可能就需要想象力和创造力等研究手段来发现。紧急事件场景应该涉及到以上所述的所有资源。以下是紧急情况场景可能涉及的一些问题类型的例子：
人力资源：人们能够去工作吗？关键人员愿意通过纠察线吗？是否由一个人掌握着关键的技能和知识？人们能够容易地抵达备用站点吗？
处理能力：计算机受到伤害了吗？如果某些计算机不能运行会怎样，所有的呢？
自动化应用和数据：数据的完整性受到影响了吗？应用程序受到破坏了吗？应用能够在不同的处理平台上运行吗？
基于计算机的服务：计算机能够通信吗？同哪里通信？人们能够通信吗？信息服务停止了吗？停止多长时间？
基础设施：人们有地方坐吗？他们有设备来进行工作吗？他们可以使用建筑物吗？
文档/文书：可以找到所需的记录吗？它们可读吗？
11.4 步骤4：选择应急计划策略
下一步是计划如何恢复所需的资源。在评估备用手段时，需要考虑设置何种控制手段来防止和减少紧急情况。因为没有任何控制手段能够完全并且经济有效地防止所有紧急情况，所以需要协调预防和恢复工作。
应急计划策略一般包括三个部分：紧急事件响应、恢复和复原。紧急事件响应包括为保护生命和减轻损失所采取的最初行动。恢复是指继续支持关键功能所采取的步骤。复原是回到正常的运行状态。恢复和复原的关系是很重要的。复原正常运行状态所花费的时间越长，机构运行在恢复模式下的时间也就越长。
策略的选择基于实际的考虑因素，包括可行性和费用。不同类别的资源都应得到考虑。风险评估可以被用于协助评价可选措施的费用以确定最佳策略。例如，考虑到在不同时间长度内失去电源可能带来的问题，购买和维护发电机或是将处理移至备用站点显得昂贵吗？失去基于计算机相关资源的后果是否严重到需要付出各种恢复策略的费用？风险评估应该关注那些最佳策略还不是很明显的领域。
在制定应急计划策略中，处理各种支持关键功能的资源时需要考虑很多因素。右侧的图文框中提供了一些例子。
11.4.1 人力资源
为了确保机构能够得到具有足够技能和知识的工作人员，需要知识的培训和文档。在重大紧急事件中，人们将处于巨大的压力或恐慌之中。如果紧急事件是区域性的灾难，他们首先关心的可能是他们的家庭和财产。另外，许多人会不愿意或不能够去工作。可以使用额外的雇员或临时的服务。使用额外的人员可能会引入安全缺陷。应急计划，特别是紧急事件响应通常特别强调保护人的生命。
11.4.2 处理能力
处理能力的策略一般被归为五类：热站、冷站、冗余、互惠协议和混合型。这些术语来源于数据中心的恢复策略但也可以被用于其它平台。
1． 热站 配备有处理能力和其它服务的建筑。
2． 冷站 用于安放处理器并且能够方便地适应使用的建筑。
3． 冗余站点 与主站点的设备和配置完全相同的站点。（一些机构计划在灾难后拥有较弱的处理能力并使用部分冗余。存储备用的个人电脑或局域网服务器也提供某些冗余。）
4． 互惠协议 允许两个机构互相支持的协议。（这种方式经常听起来不错，但是应急计划专家提醒这种备用方式由于存在遵守协议和计划需要随系统和人员变化而更新的问题而很有可能失败。）
5． 混合型 以上方式的任何组合，如在其它紧急情况危害到冗余站点或互惠协议的情况下以热站做为备份。
恢复可能包括多个阶段，可能以处理能力不断增加的可用性为标志。复原计划可以包括更换设备的合同或执行合同的能力。
11.4.3 自动化应用和数据
一般来说，应用和数据的主要应急策略是定期备份和安全的离站存储。相关的重要决策包括执行备份的频率和运输（到备用处理设施或复原到正常运行状态的支持站点）的方法。
11.4.4 基于计算机的服务
服务提供商可以提供应急服务。语音通讯运营商经常可以将呼叫重新路由（对于用户是透明的）到新的位置。数据通讯运营商也可以重新路由数据流。热站通常具有接收语音和数据通讯的能力。如果一个服务提供商无法服务，就有可能使用另一个。但是，无论是本地还是长途，失去通讯运营商的类型是很重要的。本地语音服务可以使用移动电话。本地数据通讯，特别是大容量的一般来说较难替代。另外，复原正常运行状态可能需要再一次重新路由通讯服务。
11.4.5 物理基础设施
热站和冷站除了处理能力支持以外还可以提供办公场所。其它类型的合同安排可以用于紧急事件中的办公场所、安全服务和家具等。如果应急计划需要向离站设施迁移，需要制定规程来确保平稳地转换到主运作设施或新设施。保护物理基础设施通常是紧急事件响应计划的重要部分，如使用灭火器或保护设备免遭水害。
11.4.6 文档和文书
备份到磁、光、缩微胶片、纸或其它介质和离站存储通常是主要的应急策略。文书文件通常比电子的更难备份。表格材料和其它需要的文书通常可以存放在离站设施。
11.5 步骤5：实施应急策略
一旦选择好应急策略，就需要做好适当的准备工作，将策略形成文档并培训员工。这些工作中的很多是持续性的。
11.5.1 实施
实施策略保护关键功能及其资源需要很多准备工作。例如，通常的一项准备工作就是建立备份文件和应用的规程。另一项是在应急策略需要时签订合同和协议。现有的服务合同可能需要重新协商以增加应急服务。另一项准备工作可能是采购设备，尤其是支持冗余能力的设备。
保持准备工作，包括文档的更新状态是很重要的。计算机系统变化迅速，所以备份服务和冗余设备也应该跟上变化。合同和协议可能也需要反映变化。如果需要额外的设备，在其不再可靠或适用于机构体系时必须得到维护和定期更换。
准备工作还应该包括正式指定负责紧急事件中各项任务的人。这些人经常被称为紧急响应团队。这个团队经常由应急计划团队的成员构成。
机构有很多重要的实施问题。两个最重要的是1）应该制定多少计划？以及2)每项计划由谁来制定？这两个问题关系到机构整体的应急计划策略。其答案应该被记录到机构政策和规程的文档中。
多少计划？
一些机构只有一项计划用于整个机构，而另一些对于每个不同的系统、应用或其它资源都有一项计划。另一些方法建议为每一项业务或任务功能制定一项计划，如果需要，为关键资源制定单独的计划。所以问题的答案因每个机构不同的环境而有所不同。但是协调好资源管理人和负责任务或业务的职能管理人的关系是至关重要的。
谁准备计划？
如果机构决定采取集中式的方法制定应急计划，任命应急计划协调人可能是最好不过的了。协调人与各职能和资源管理人配合来准备计划。一些机构将责任直接指定给职能和资源管理人。
11.5.2 制定文档
应急计划需要被书写成文档，随着系统和其它因素的变化保持更新状态并被存放在安全的地方。书写好的计划在紧急事件中是很关键的，在制定计划的人不在的情况下尤其如此。它应该以简洁的语言，按照紧急事件中任务执行的步骤明确地叙述，以便拥有较少知识的人可以立即开始执行计划。将应急计划的最新版本存放在多个地点通常很有帮助，其中包括诸如备用处理站点或备份数据存储设施等任何离站地点。
11.5.3 培训
应该对所有人员进行与其应急任务相关的培训。新的员工也应该在其加入机构时接受培训，进行新内容的培训也可能是需要的，员工还需要实践他们的技能。
培训对于员工在紧急情况时的有效响应尤其重要。如果发生火灾，将没有时间查看手册来决定正确的规程。根据紧急情况的特点，可能有也可能没有保护设备或其它资产的时间。需要实践来确定正确的反应，在关系到人身安全的情况下尤其如此。
11.6 步骤 6：测试和修订
应该定期测试应急计划，因为计划及其实施中无疑会存在缺点。随着时间的推移和支持关键功能所使用的资源的变化计划会过时。应该特别设定保持应急计划更新状态的责任。不同的机构和系统其测试的范围和频率是不同的。有几种类型的测试，包括检查、分析和灾难模拟。
检查可以是核查应急计划文档正确性的简单测试。例如，检查者可以检查所列的人员是否还在机构中以及是否还负有计划中包括的责任。这种测试可以核查家庭和单位电话号码、机构代码和建筑以及房间编号。检查可以确定文件是否可以从备份磁带中恢复和员工是否知道紧急规程。
分析可以针对对整个计划或其一部分如紧急响应规程进行。如果执行分析的人没有参与制定应急计划但是具有关键功能和支持资源的丰富实践知识是有益处的。分析可以根据其内部的逻辑关系逐条分析应急计划，寻找逻辑的或计划制定者所使用过程的缺点。分析员也可能会见职能管理人、资源管理人及其职员来发现计划中遗漏的或无法工作的部分。
机构也可以安排灾难模拟。这些测试提供应急计划中错误的相关信息并且提供实际紧急事件的实践机会。它们可能会比较昂贵，但是这些测试却可以提供用于确保重要功能连续性的关键信息。通常，功能及其应急计划中所涉及的资源越是关键，执行灾难测试越是具有成本效益。
11.7 相互关系
因为所有的控制都帮助防范紧急事件，所以与手册中的所有控制都具有相互关系。
风险管理为分析安全成本和各种应急计划选项提供工具。另外，风险管理工作可以被用于帮助辨别支持机构所需的关键资源以及对那些资源的可能威胁。尽管如此，在应急计划之前并无需执行风险评估，因为在应急计划本身的过程中可以执行关键资源的识别。
物理和环境控制帮助防范紧急事件。虽然其它很多控制如逻辑访问控制也可以防止紧急事件，但是应急计划涉及的重大威胁是物理和环境威胁，如火灾、电力中断、下水道泄漏或自然灾害。
事件处理可以被视为应急计划的一个子项。它是各种技术威胁的紧急响应能力。事件处理还可以帮助机构防止未来的事件。
支持和运作在大多数机构中包括定期备份文件。它还包括防范诸如磁盘故障或数据文件损坏等一般性紧急事件和从这些紧急事件中恢复的工作。
政策是创建和记录机构应急计划方法所必须的。政策应该明确设定责任。
11.8 费用考虑
制定和实施应急计划的费用可能很高，特别是在策略包括备份服务合同或冗余设备时。讨论每种类型费用考虑时有太多选项。测试计划的费用是经常被忽视的应急费用。测试提供许多益处所以应该被执行，尽管一些比较便宜的防范（如检查）对于不太关键的资源可能是足够的。
参考书目
Alexander, M. ed. "Guarding Against Computer Calamity." Infosecurity News. 4(6), 1993. pp. 26-37.
Coleman, R. "Six Steps to Disaster Recovery." Security Management. 37(2), 1993. pp. 61-62.
Dykman, C., and C. Davis, eds. Control Objectives - Controls in an Information Systems Environment: Objectives, Guidelines, and Audit Procedures, fourth edition. Carol Stream, IL: The EDP Auditors Foundation, Inc., 1992 (especially Chapter 3.5).
Fites, P., and M. Kratz, Information Systems Security: A Practitioner's Reference. New York, NY: Van Nostrand Reinhold, 1993 (esp. Chapter 4, pp. 95-112).
FitzGerald, J. "Risk Ranking Contingency Plan Alternatives." Information Executive. 3(4), 1990. pp. 61-63.
Helsing, C. "Business Impact Assessment." ISSA Access. 5(3), 1992, pp. 10-12.
Isaac, I. Guide on Selecting ADP Backup Process Alternatives. Special Publication 500-124. Gaithersburg, MD: National Bureau of Standards, November 1985.
Kabak, I., and T. Beam, "On the Frequency and Scope of Backups." Information Executive, 4(2), 1991. pp. 58-62.
Kay, R. "What's Hot at Hotsites?" Infosecurity News. 4(5), 1993. pp. 48-52.
Lainhart, J., and M. Donahue. Computerized Information Systems (CIS) Audit Manual: A Guideline to CIS Auditing in Governmental Organizations. Carol Stream, IL: The EDP Auditors Foundation Inc., 1992.
National Bureau of Standards. Guidelines for ADP Contingency Planning. Federal Information Processing Standard 87. 1981.
Rhode, R., and J. Haskett. "Disaster Recovery Planning for Academic Computing Centers." Communications of the ACM. 33(6), 1990. pp. 652-657.
