IBM安全团队此前发布《2022勒索软件终极指南》就应急恢复（当勒索攻击已经发生之后）环节总结指出，如果企业依靠其内部备份基础设施来恢复受影响的文件，就需要确保受影响数据的备份流程已经存在，且过程应包括对备份的频率和完整性的分析，以确保数据的完全恢复。
也就是说，企业需要为灾难事件发生后的“业务连续性计划”匹配相应的流程，其流程对于不同企业，不同业务与生产环境都存在差异，但基本条件是相同的，以业务生产为前提的恢复有效性问题。
从勒索场景谈灾难恢复需注意以下五个方面
Gartner高级分析师Jerry Rozeman近日从“业务连续性计划”和“灾难恢复”角度分析了对于勒索软件攻击场景下的应对关系，并指出以下五点注意事项：
1、异同
传统的灾难恢复和勒索软件恢复有许多相似之处，包括需要与业务连续性管理协调、通过恢复层确定优先级以及了解依赖关系。两者都需要评估影响、声明和激活恢复计划、执行计划以及明确访问和维护方面的过程。
但是，勒索软件恢复涉及更大的复杂性和不可预测性，因此考虑过程中不同恢复步骤的业务需求非常重要，这自然会涉及不同的利益相关者。其中包括各种恢复方法、位置、数据丢失、恢复时间和恢复正常业务的速度。
2、灾难恢复可防止“可预测”的灾难
传统的灾难恢复规划假定整个位置或应用程序出现故障，这些事件的范围各不相同，从区域停电到IT设备故障，甚至自然灾害，如地震，龙卷风和洪水，这些自然灾害摧毁了所有IT基础设施。
规划这些事件需要跨数据中心的活动或热备用应用程序基础结构，这使得故障转移能够在合理的时间内发生，并且数据丢失最少或没有。
3、灾难恢复并不总是适合勒索软件攻击
截至今天，勒索软件攻击大多是精心策划的，攻击可以在最终勒索软件攻击前几周或几个月开始。通常，勒索软件仅在这种精心准备的网络攻击的最后一步被激活，攻击者在攻击期间仍然可以访问。
传统的灾难恢复通常依赖于主站点和灾难恢复位置之间的应用程序、数据和基础网络服务的复制和同步。因此，攻击者为危害生产站点所做的所有工作都将复制到恢复站点上。考虑到灾难恢复站点的污染将使网络攻击后无法使用标准恢复过程。
考虑到在最坏的情况下，您可能必须从头开始构建，这将需要计划从替代基础架构（例如隔离的恢复环境、云基础架构、搬迁站点和服务）中恢复。
4、灾难恢复和勒索软件恢复遵循不同的流程
传统的灾难恢复激活遵循一个简单的过程，在检测到灾难事件后，将进行评估以确定是否需要故障转移。之后，执行并验证故障转移，业务继续。恢复主环境时，可以执行计划周密的故障恢复（如果适用）。
另一方面，从勒索软件中恢复需要多个更复杂的阶段。
在第一阶段，重点是阻止攻击的执行和传播；
在第二阶段，需要进行取证分析，以找出发生了什么，执行了哪些勒索软件，手头的安全问题以及它如何渗透到基础设施中；
在第三阶段，需要分析以找出受影响的网络工件、应用程序、数据和备份；
在第四阶段，重点是恢复基础设施，通过恢复或重建网络中的所有工件以及存储和计算基础设施，然后重建或恢复DNS和AD等网络服务；
在第五个阶段，利用专用的隔离恢复环境 （IRE） 来扫描、修复和验证操作和应用程序/数据系统，为恢复到主环境做好准备；
最后，在第六阶段，系统从隔离恢复环境迁移回生产环境。
这种对整个基础架构的影响程度使勒索软件恢复变得如此复杂和不可预测，因为您需要首先恢复并重新保护基础架构环境中每个受影响的元素，然后才能恢复系统、应用程序及其数据。检查不同流程带来的复杂性以及这可能对您的组织提出的要求。
5、勒索软件恢复是“团队努力”
灾难恢复通常由灾难恢复团队领导，该团队由服务器团队、网络团队、存储团队、备份团队组成。灾难恢复是更广泛的业务连续性管理流程的一部分，其中灾难恢复负责在灾难情况下恢复 IT 系统。
另一方面，勒索软件恢复最初由网络安全事件响应团队领导，该团队向首席信息安全官报告，并得到其他基础设施和运营团队（包括灾难恢复团队）的支持。因此，从勒索软件攻击中恢复更多的是全企业的努力，并考虑您是否有资源来适当地解决这个问题。
提前准备，并时常演练
此前行业厂商CloudWonder嘉云在接受安全419采访时曾聊起过这样一个故事，一家具有强合规性的企业为其数据中心部署建设了全套容灾系统，其IT运维人员为了时刻保障系统的有效性，曾在一年之间做了上百次灾备切换演练。
实际上在基于不断变化的真实业务场景当中，这种高频次的演练主要为自于危机意识的自我管理，并以保障生产为核心的价值展现。
提前准备“业务连续性计划”和“灾难恢复”至关重要，其中提前计划是一部分，对计划进行演练测试则是另一部分。演练测试是保障计划顺利实施的前提，一方面他能进一步明确执行者所必备且要熟练掌握的技术技能，以及以业务和生产为中心的恢复流程，以保障流程和应对灾难事件的有效性。
京公网安备 11010802033237号
