联邦信息系统的 NIST 应急计划指南 Rev 1

如果满足该系统的一个或多个激活标准，应启动ISCP。如果满足激活标准，指定的权威机构应启动该计划。系统中断或中断的激活标准因组织而异，应在应急计划政策中说明。标准：您已经确定了启动计划的标准 | 您已经清楚地定义了可能启动计划的角色

停电或中断可能会在有或没有事先通知的情况下发生。例如，通常会提前通知某个地区预计受到飓风影响，或者某个日期预计会出现计算机病毒。然而，设备故障或刑事行为可能不会有任何通知。通知程序应在计划中记录，以应对这两种情况。程序应描述在工作时间和非工作时间通知恢复人员的方法。及时通知对于减少系统中断的影响非常重要；在某些情况下，它可能提供足够的时间，让系统人员优雅地关闭系统，以避免系统硬崩溃。在停电或中断发生后，应向停电评估团队发送通知，以便其确定情况的状态并采取适当的后续措施。标准：您已记录所有通知程序 | 您已描述工作时间内及非工作时间的通知方式 | 通知策略还定义了在特定人员无法联系时应遵循的程序

为了确定在系统中断或故障后如何实施 ISCP，必须评估中断的性质和程度。中断评估应在条件允许的情况下尽快完成，同时人员安全必须始终放在首位。在可能的情况下，中断评估小组是第一个接到中断通知的团队。标准：您已确定停机评估团队 | 您已确定评估中断的标准

本部分应识别任何可用的备用手动或技术处理程序，这些程序允许业务单元继续处理通常由受影响系统完成的信息。备用流程的示例包括手动表单处理、将数据输入工作站以存储直至可以上传和处理，或数据输入排队。标准：您提供可供替代的手工或技术处理程序，以便业务部门能够继续处理原本由受影响系统完成的一些信息处理工作。

本附录提供有关系统的备用存储、备用处理站点和备用电信的信息。根据 NIST SP 800-53 第 3 版，中等影响系统需要提供备用存储、站点和电信信息。有关控制细节，请参阅 NIST SP 800-53 第 3 版。标准：您需列出备用存储、处理和/或电信设施，并提供详细信息

本节的信息应可从系统的系统安全计划（SSP）中获得，可以直接从SSP中复制，或引用SSP中的相关部分，并将SSP的最新版本附加到本应急计划中。应在本附录中标识与该系统互连或支持该系统的其他系统的ISCP。应注明 ISCP 的最新版本、ISCP 的位置以及主要联系人（例如 ISCP 协调员）。标准：你应保持参考架构图和与计划相关的其他文件的链接 | 你应保持详细的恢复程序与计划的链接

业务影响分析的结果应包含在本附录中。除了整体的恢复时间目标（RTO）和恢复点目标（RPO）之外，如果各个应用程序由于其在整体功能中的重要性不同而具有不同的RTO，建议还应包括每个应用程序的RTO。示例如下所示。标准：您已至少包含每个组件的业务影响分析（BIA）中的 RTO、RPO 和 MTD 指标 | 如果系统不可用，您已包含组织影响的后果

本附录包括系统的详细恢复程序，可能包括以下内容：按键级别的恢复步骤；通过磁带、光盘或其他媒介进行系统安装的说明；所需的配置设置或更改；从磁带和审计日志中恢复数据；以及其他适当的系统恢复程序。如果系统完全依赖另一个团体或系统进行恢复和验证（例如大型主机系统），则提供的信息应包括该支持系统的详细恢复和验证程序的联系信息和位置。标准：您提供按键级别的恢复步骤 | 您拥有来自存储库/注册表的系统安装说明 | 您提供所需的配置设置或更改 | 明确描述从备份位置恢复数据

包括可能有助于恢复系统的任何系统架构、输入/输出或其他技术或逻辑图。图表还可以识别与其他系统互连的信息。标准：提供任何可能有助于恢复系统的系统架构、输入/输出或其他技术或逻辑图 | 列出识别与其他系统互连信息的图表

建议在灾难恢复计划中包含一个专门的页面用于跟踪修订情况。这将允许读者查看哪些内容被修改、谁进行了修改以及修改的时间。此外，这还将使解决方案团队能够了解灾难恢复计划是如何随着解决方案的更新而制定/更新的。标准：文档变更日志应易于获取，最好可以在计划本身中查看

本节的信息应可从系统的系统安全计划（SSP）中获取，可以直接从SSP中复制，或引用SSP中的相关部分，并将最新版本的SSP附加到本应急计划中。本附录包括与系统直接互联或交换信息的其他系统的信息。互联信息应包括连接类型、传输的信息以及该系统的联系人。如果系统没有任何直接的互联，则可以移除此附录，或者使用以下声明：信息系统（名称）与任何其他系统没有直接互联。标准：您需提供与该系统直接互连或交换信息的其他系统的信息 | 您需提供详细信息，包括连接类型、传输的信息以及该系统的联系人

库存信息应包括系统运行的服务器或硬件类型、处理器和内存要求、存储要求以及其他相关细节。软件库存应识别操作系统（包括服务包或版本级别，以及运行系统所需的任何其他应用程序，如数据库软件）。标准：您需要提供硬件清单信息，包括系统运行的服务器或硬件类型、处理器和内存需求、存储需求以及任何其他相关细节 | 您需要提供软件清单详情，包括操作系统（含服务包或版本等级）以及运行系统所需的其他应用程序，例如数据库软件。

提供每个在灾难恢复计划（DRP）的启用或实施中拥有角色或责任，或与DRP协调的人员的联系信息。建议为每个列出的人提供至少一个办公电话和一个非办公电话。注意：信息可能包含个人身份信息，应当予以保护。标准：您需提供涉及灾难恢复计划（DRP）的所有人员的电话联络清单 | 您必须为清单上的每个人提供至少一个办公室电话和一个非办公室联系电话

所有信息系统连续性计划（ISCP）应按照组织规定的频率（例如，每年）进行审查和测试，或在系统发生重大变化时进行。提供系统测试的信息和时间表。对于低影响系统，每年的桌面演练就足够。桌面演练应包括所有ISCP联系人，并由外部或公正的观察员进行。在桌面演练之前，会制定正式的测试计划，并设计演练和问题，以涵盖ISCP的关键部分，包括以下内容的演练：通知程序；从备份介质在备用平台上进行系统恢复；内部和外部连接；以及重建程序。测试结果记录在事后行动报告中，并制定经验教训以更新ISCP中的信息。标准：您提供系统测试的信息和计划 | 您定期（例如每年）审查并测试所有灾难恢复计划（DRP） | 您记录测试结果并改进灾难恢复计划（DRP）

本附录包括在系统恢复后、系统投入全面运行并交还给用户之前执行的系统验收程序。系统验证测试计划可能包括在实施系统升级或变更之前进行的回归测试或功能测试。标准：您提供系统恢复后执行的系统验收程序 | 系统验证测试计划可能包括在实施系统升级或变更之前进行的回归或功能测试

本附录应包含所有关键维护或支持供应商的联系信息。应包括联系信息，例如紧急电话号码、联系人姓名、合同号码以及合同规定的响应时间和现场服务时间。标准：您提供所有主要维护或支持供应商的联系清单 | 清单包括紧急联系电话、联系人姓名、合同编号以及合同规定的响应和现场时间

计划中应包括每个阶段的高级概述，以告知恢复团队每个阶段的目的。 标准：计划描述了启动阶段 | 计划描述了恢复阶段 | 计划描述了验证阶段

角色和职责部分介绍了应急小组的整体结构，包括团队之间的层级、协调机制和要求。该部分还概述了在应急情况下团队成员的角色和职责。应在应急计划启动期间为特定的响应和恢复角色指定团队和团队成员。标准：您已经描述了每个负责执行或支持系统恢复和验证的团队及角色 | 您已包含每个团队/角色的职责以及与其他团队的协调（如适用）

描述应包括信息系统架构、位置以及任何其他重要的技术考虑因素。输入/输出（I/O）图和系统架构图，包括安全设备（例如防火墙、内部和外部连接）都是有用的。系统描述的内容通常可以取自系统安全计划。标准：您已提供了系统架构和功能的一般描述 | 您已说明了操作环境、物理位置、用户的一般位置以及与外部组织/系统的合作关系 | 计划包括涉及恢复目的的其他重要技术考虑信息

应包括恢复策略的高级概述，以便灾难恢复协调员或其他指定人员能够了解为恢复将要执行的任务。活动的顺序应反映系统的最大容许停机时间（MTD），以避免对相关系统造成重大影响。程序应以逐步、顺序的格式编写，以便系统组件能够以逻辑的方式恢复。标准：恢复事件的顺序反映了在业务影响分析（BIA）中确定的系统最大可容忍停机时间 | 已包含升级步骤和与其他团队协调的说明 | 已指定适当团队的程序，以在必要时协调设备、数据和重要记录在备用地点的运输

根据业务影响分析（BIA）的识别，系统组件、基础设施及相关设施是支持日常任务/业务流程的关键组成部分。将用户连接到这些系统的系统、应用程序和基础设施可能会受到导致服务中断或故障的事件影响。在恢复阶段包括升级和通知组件有助于确保总体上遵循可重复、结构化、一致且可衡量的恢复流程。有效的升级和通知程序应定义并描述触发额外行动所需的事件、阈值或其他类型的触发条件。行动包括向更多恢复人员发送额外通知、向领导层发送消息和状态更新，以及提供额外资源的通知。应纳入程序以建立一套清晰的事件、行动和结果，并应根据需要为团队或个人进行记录。标准：该计划在恢复工作期间提供了适当的升级通知程序 | 该计划明确了负责每个升级/意识程序的团队或个人

为了促进恢复阶段的操作，信息系统灾难恢复计划（ISCP）应提供详细的程序，以将信息系统或组件恢复到已知状态。恢复程序应以简单、逐步的方式编写。为了防止在紧急情况下出现困难或混淆，任何程序步骤都不应假设或省略。清单格式对于记录顺序恢复程序以及在系统无法正确恢复时进行故障排除非常有用。标准：提供了一份用于恢复程序的简明逐步指导和清单 | 您已经确定了每个程序的负责团队或人员

本节包括在制定 ISCP 时使用的假设清单，以及不适用情况的清单。 标准：您已列出所有基本假设 | 您已包括不适用情况的清单

范围确定了 FIPS 199 的影响级别和相关的恢复时间目标 (RTO)，以及备用站点和数据存储能力（如适用）。标准：您已经制定了一个所有利益相关者都可以轻松访问的计划 | 该计划已确定最大可容忍停机时间、恢复时间目标和恢复点目标 | 您已经明确说明了制定该计划及其目标的原因

验证数据测试是测试和验证数据的过程，以确保数据文件或数据库在永久位置已被完全恢复。 标准：您提供用于测试和验证的程序，以确保数据文件或数据库在永久位置已被完全恢复 | 您已确定负责每个程序的团队或人员

重要的是，所有恢复事件都应有良好的记录，包括在恢复和重建过程中采取的措施、遇到的问题以及总结的经验教训，以便纳入并更新本信息系统持续性计划（ISCP）。每个ISCP团队或个人都有责任记录自己在恢复和重建过程中的行动，并将这些记录提供给ISCP协调员。标准：计划详细说明了每个灾难恢复计划（DRP）团队成员在用所学经验更新DRP时所需提供或收集的信息类型 | 事件文档程序详细说明了开发、收集、审批和维护的职责

验证功能测试是验证功能已被测试且系统已准备好恢复正常操作的过程。 标准：计划提供确保系统功能已被测试且系统准备好恢复正常操作的程序 | 计划确定每个程序负责的团队或人员

在成功完成测试和验证后，系统所有者将正式宣布恢复工作完成，并且该信息系统已恢复正常运行。ISCP协调员将通知信息系统的业务和技术联系人有关该宣布的情况。标准：该计划提供了如何通知相关利益相关者恢复正常运营的指导 | 该计划提供了拆除任何临时恢复地点、补充物资、归还文件以及为下一次事件准备系统的清单 | 该计划提供了重新启动备份的清单

验证安全测试是指在信息系统恢复后，验证安全流程和控制措施是否到位，以保护这些系统的过程。 标准：该计划提供确保安全系统和控制措施正常运行的程序 | 该计划明确了负责每个程序的团队或个人