1. 现场恢复
1.1. 传统的恢复机制意味着必须使受影响的系统脱机，安装一些备份文件，然后将系统重新联机
1.2. 涉及一个干净的系统，该系统具有正确的配置和未损坏的备份文件，并且会被安装在故障系统上
- 1.2.1. 最终结果是移除故障系统及其文件，并由新系统接管
1.3. 在仍然在线的系统上使用数据恢复工具
- 1.3.1. 恢复工具可能会对所有现有配置执行一次更新，将它们更改为正确的配置
2. 应急计划
2.1. 组织需要保护其网络和IT基础设施不受全面故障的影响
2.2. 应急计划是制定临时措施的过程，以便从故障中快速恢复，同时限制故障造成的损害程度
- 2.2.1. 计划过程包括确定IT基础设施面临的风险，然后提出补救策略，以显著降低风险的影响
2.3. 无论一个组织的预防措施多么全面，都不可能消除所有风险
2.4. 理解应急计划与其他业务连续性计划之间的集成
2.5. 认真制定应急计划，并注意选择的恢复策略以及恢复时间目标
2.6. 制定应急计划，重点放在演练、培训和更新任务上
2.7. 应急计划必须针对的IT平台
- 2.7.1. 工作站、笔记本电脑和智能手机
- 2.7.2. 服务器
- 2.7.3. 网站
- 2.7.4. 内部网
- 2.7.5. 广域网
- 2.7.6. 分布式系统
- 2.7.7. 服务器机房或公司
3. IT应急计划流程
3.1. IT应急计划可帮助组织为未来的不幸事件做好准备，以确保能够及时有效地应对这些事件
- 3.1.1. 未来的不幸事件可能由硬件故障、网络犯罪、自然灾害和前所未有的人为错误引起
3.2. 步骤
- 3.2.1. 开发应急计划策略
- 3.2.1.1. 一个好的应急计划必须建立在明确的政策基础上，该政策定义了组织的应急目标并确定了负责应急计划的员工
- 3.2.1.2. 所有高级员工必须支持应急计划
- 3.2.1.3. 关键要素
3.2.1.3.1. 应急计划的涵盖范围
3.2.1.3.2. 所需资源
3.2.1.3.3. 组织用户的培训需求
3.2.1.3.4. 测试、演练和维护计划
3.2.1.3.5. 备份计划及其存储位置
3.2.1.3.6. 应急计划中人员角色和职责的定义
- 3.2.2. 进行业务影响分析
- 3.2.2.1. Business Impact Analysis，BIA
- 3.2.2.2. 将帮助应急计划协调人轻松描述组织的系统需求及其相互依赖关系
- 3.2.2.3. 将帮助他们在制定应急计划时确定组织的应急要求和优先事项
- 3.2.2.4. 主要目的是将不同的系统及其提供的关键服务关联起来
- 3.2.2.5. 步骤
3.2.2.5.1. 确定关键IT资源
3.2.2.5.1.1. 尽管IT基础设施有时可能很复杂，并且有许多组件，但只有少数组件是关键的
3.2.2.5.1.2. IT基础设施是支持核心业务流程（例如薪资处理、事务处理或电子商务商店结账）的资源
3.2.2.5.1.3. 关键资源是服务器、网络和通信通道
3.2.2.5.1.4. 不同的企业可能有自己独特的关键资源
3.2.2.5.2. 确定中断影响
3.2.2.5.2.1. 对于每种确定的关键资源，企业应确定其允许的停机时间
3.2.2.5.2.2. 允许的最大停机时间是资源不可用的时间段，且在此期间业务不会受到重大影响
3.2.2.5.2.3. 不同的组织将根据其核心业务流程而具有不同的最大允许停机时间
3.2.2.5.2.4. 最佳停机时间估计应通过平衡中断成本和恢复IT资源的成本来获得
3.2.2.5.3. 制定恢复优先级
3.2.2.5.3.1. 确定首先恢复资源的优先顺序
3.2.2.5.3.2. 最关键的资源，如通信通道和网络，几乎总是第一优先级
- 3.2.3. 确定预防性控制
- 3.2.3.1. 组织将掌握有关其系统及其恢复要求的重要信息
- 3.2.3.2. 可以用来检测、阻止或减少中断对系统的影响
- 3.2.3.3. 有时为可能发生的所有类型的中断制定预防措施的成本可能会很高
- 3.2.3.4. 从防止电力中断到防止火灾，有非常广泛可用的预防性控制措施
- 3.2.4. 制定恢复策略
- 3.2.4.1. 恢复战略是用于在中断发生后快速有效地恢复IT基础设施的策略
- 3.2.4.2. 恢复方法
3.2.4.2.1. 备份
3.2.4.2.1.1. 应定期备份系统中的数据
3.2.4.2.1.2. 备份间隔应该足够短以捕获最新的数据
3.2.4.2.1.3. 在灾难导致系统和其中的数据丢失的情况下，组织可以轻松恢复数据—可以重新安装系统，然后加载最新的备份
3.2.4.2.1.4. 云备份在成本、可靠性、可用性和容量大小方面具有优势
3.2.4.2.1.5. 云备份始终在线，因此它们比外部存储设备上的备份更可靠、更方便
3.2.4.2.1.6. 云计算的两个主要缺点在于隐私和安全
3.2.4.2.2. 备选站点
3.2.4.2.2.1. 应急计划应提供在替代设施中继续业务运营的选项
3.2.4.2.2.2. 类型
3.2.4.2.2.2.1. 组织拥有的站点
3.2.4.2.2.2.2. 通过与内部或外部实体达成协议而获得的站点
3.2.4.2.2.2.3. 通过租赁获得的商业站点3.2.4.2.2.3.1. 冷站
3.2.4.2.2.3.1.1. 指那些拥有所有足够的支持资源来执行IT运营的站点
3.2.4.2.2.3.1.2. 该组织必须安装必要的IT设备和电信服务来重建IT基础设施
3.2.4.2.2.3.2. 温站
3.2.4.2.2.3.2.1. 指部分设备和维护已达到可以继续提供已迁移的IT系统的状态
3.2.4.2.2.3.2.2. 需要一些准备工作才能完全运营
3.2.4.2.2.3.3. 热站
3.2.4.2.2.3.3.1. 有足够的设备和人员可以在主站点遭受灾难时继续进行IT运营
3.2.4.2.2.3.4. 移动站
3.2.4.2.2.3.4.1. 可移动的办公空间，配有托管IT系统所需的所有IT设备
3.2.4.2.2.3.4.2. 主要站点的精确复制
3.2.4.2.2.3.5. 镜像站
3.2.4.2.2.3.5.1. 冗余设施，具有与主站点相同的IT系统和数据，并且可以在主站点面临灾难时无缝地继续运营- > 3.2.4.2.3. 更换设备 > 3.2.4.2.3.1. 一旦发生破坏性灾难，从而损坏了关键硬件和软件，组织将不得不安排更换这些硬件和软件 > 3.2.4.2.3.2. 供应商协议，通知供应商在灾难中进行必要的更 > 3.2.4.2.3.3. 设备清单，即组织预先购买关键IT设备的更换件并安全地存储它们
- > 3.2.4.2.3.4. 组织还可以选择使用现有的兼容设备来替换损坏的设备
- > 3.2.4.2.4. 计划测试、培训和演练 > 3.2.4.2.4.1. 一旦制定了应急计划，就需要对其进行测试，以确定其可能存在的缺陷以及评估员工在灾难发生时执行计划的情况 > 3.2.4.2.4.2. 必须侧重于从备份和备用站点恢复的速度、恢复人员之间的协作、备用站点上恢复的系统的性能以及恢复正常运营的难易程度 > 3.2.4.2.4.3. 测试应在最坏的情况下进行，并应通过课堂演练或功能演练进行 > 3.2.4.2.4.4. 功能演练要求更高，需要模仿灾难，并实际教导员工如何应对 > 3.2.4.2.4.5. 把理论培训作为实践培训的补充，并强化员工在演练中学到的知识 > 3.2.4.2.4.6. 至少应该每年进行一次培训
- 3.2.5. 维护计划
- 3.2.5.1. 维护计划是IT应急计划过程中的最后一步
- 3.2.5.2. 应急计划需要保持适当的状态，以便能够满足组织当前的风险、需求、组织结构和政策要求
- 3.2.5.3. 计划需要定期审查并在必要时更新，更新应记录在案
- 3.2.5.4. 应至少每年进行一次审查，并应在短时间内实施所有注意到的更改
4. 风险管理工具
4.1. 自动化可确保风险管理过程的效率和可靠性
4.2. RiskNAV
- 4.2.1. 由MITRE公司开发，是为帮助组织管理其IT风险而开发的高级工具
- 4.2.2. 该工具允许对风险数据进行协作收集、分析、优先排序、监控和可视化
- 4.2.3. 三个维度：优先级、可能性和缓解状态
- 4.2.4. 详细信息
- 4.2.4.1. 风险ID/描述：风险的唯一标识和描述
- 4.2.4.2. 风险状态：风险是否处于活跃状态
- 4.2.4.3. 风险名称：风险的名称
- 4.2.4.4. 风险类别：受风险影响的系统
- 4.2.4.5. 风险颜色：用于显示风险的颜色
- 4.2.4.6. 风险优先级：风险的优先级是高、中还是低
- 4.2.4.7. 缓解状态：风险是否已缓解
- 4.2.4.8. 影响日期：风险何时发生
- 4.2.4.9. 指定管理者：负责管理风险的人员
- 4.2.5. 该工具就会自动计算每个风险的总得分
4.3. IT and Cyber Risk Management应用程序
- 4.3.1. 由Metric System开发的工具，用于帮助组织采用业务驱动的方法进行风险管理
- 4.3.2. 与其他风险管理解决方案相比，此工具的优势在于它提供了一个可以查看IT资产、威胁和漏洞的集中点
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
