Cybersecurity

CISP学习指南：信息安全事件管理与业务连续性

Created   Updated
CISP
  1. 一、安全事件概述
  2. 二、事件响应流程
  3. 三、事件通知机制
  4. 四、应急响应团队
  5. 五、应急响应计划
  6. 六、病毒感染响应
  7. 七、我国信息安全事件分级
  8. 八、业务连续性管理与灾难恢复
  9. 九、事件后总结
  10. 九、总结

信息安全事件管理和业务连续性管理是组织应对安全威胁和灾难的关键能力，有效的事件响应和灾难恢复可以最大限度地减少损失，快速恢复业务运营。

一、安全事件概述

1.1 什么是安全事件

安全事件定义：

信息安全事件是指可能对组织的信息资产、业务运营或声誉造成不利影响的事件，包括：

  • 🔓 未授权访问
  • 🦠 恶意软件感染
  • 📧 钓鱼攻击
  • 💥 拒绝服务攻击
  • 📤 数据泄露
  • 🔧 系统故障
  • 👤 内部威胁

1.2 事件分类

按严重程度分类：

graph TB A["安全事件分类"] B["低级事件"] C["中级事件"] D["高级事件"] E["严重事件"] A --> B A --> C A --> D A --> E B --> B1["影响范围小
无数据泄露
快速恢复"] C --> C1["影响部分系统
可能有数据泄露
需要协调响应"] D --> D1["影响核心系统
确认数据泄露
需要高层介入"] E --> E1["业务严重中断
大规模数据泄露
可能触犯法律"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#fff3e0,stroke:#f57c00 style D fill:#ffccbc,stroke:#d84315 style E fill:#ffcdd2,stroke:#b71c1c

二、事件响应流程

2.1 事件响应六个阶段

事件响应六个阶段定义了安全事件处理的流程，这个流程的顺序是：

准备 → 确认 → 遏制 → 根除 → 恢复 → 跟踪

graph LR A["准备"] --> B["确认"] B --> C["遏制"] C --> D["根除"] D --> E["恢复"] E --> F["跟踪"] A --> A1["建立应急能力
准备工具和资源"] B --> B1["确认事件
评估影响"] C --> C1["隔离系统
阻止扩散"] D --> D1["清除威胁
修复漏洞"] E --> E1["恢复服务
验证安全"] F --> F1["总结经验
持续改进"] style A fill:#e3f2fd,stroke:#1976d2 style B fill:#f3e5f5,stroke:#7b1fa2 style C fill:#fff3e0,stroke:#f57c00 style D fill:#ffebee,stroke:#c62828 style E fill:#e8f5e9,stroke:#388e3d style F fill:#fce4ec,stroke:#c2185b

💡 事件响应六阶段顺序

正确的顺序：准备→确认→遏制→根除→恢复→跟踪

1️⃣ 准备阶段

  • 建立应急响应能力
  • 准备工具和资源
  • 制定应急计划
  • 培训应急团队

2️⃣ 确认阶段

  • 确认安全事件
  • 评估事件影响
  • 分类事件类型
  • 确定响应等级

3️⃣ 遏制阶段

  • 隔离受影响系统
  • 阻止威胁扩散
  • 保护关键资产

4️⃣ 根除阶段

  • 清除威胁根源
  • 修复安全漏洞
  • 加固系统安全

5️⃣ 恢复阶段

  • 恢复系统服务
  • 验证系统安全
  • 恢复业务运营

6️⃣ 跟踪阶段

  • 总结经验教训
  • 持续改进措施
  • 更新应急计划

❌ 错误的顺序：

  • 准备→遏制→确认→根除→恢复→跟踪 ❌
  • 准备→确认→遏制→恢复→根除→跟踪 ❌
  • 准备→遏制→根除→确认→恢复→跟踪 ❌

六阶段详细对比：

阶段 主要活动 关键输出 负责人
准备 建立能力、准备资源 应急计划、工具 安全团队
确认 确认、分类、评估 事件严重程度 安全分析师
遏制 隔离、阻断、保护 威胁被控制 响应团队
根除 清除、修复、加固 威胁被消除 技术团队
恢复 还原、测试、监控 服务恢复正常 运维团队
跟踪 分析、报告、改进 降低再发风险 安全经理

2.2 标准响应流程

graph LR A["检测"] --> B["分析"] B --> C["遏制"] C --> D["根除"] D --> E["恢复"] E --> F["跟踪"] A --> A1["监控告警
用户报告"] B --> B1["确认事件
评估影响"] C --> C1["隔离系统
阻止扩散"] D --> D1["清除威胁
修复漏洞"] E --> E1["恢复服务
验证安全"] F --> F1["降低风险
防止再发"] style A fill:#e3f2fd,stroke:#1976d2 style B fill:#f3e5f5,stroke:#7b1fa2 style C fill:#fff3e0,stroke:#f57c00 style D fill:#ffebee,stroke:#c62828 style E fill:#e8f5e9,stroke:#388e3d style F fill:#fce4ec,stroke:#c2185b

各阶段详解：

阶段 主要活动 关键输出 负责人
检测 监控、告警、报告 事件初步信息 监控团队
分析 确认、分类、评估 事件严重程度 安全分析师
遏制 隔离、阻断、保护 威胁被控制 响应团队
根除 清除、修复、加固 威胁被消除 技术团队
恢复 还原、测试、监控 服务恢复正常 运维团队
跟踪 分析、报告、改进 降低再发风险 安全经理

2.2 各阶段目标详解

应急响应各阶段的核心目标：

graph TB A["应急响应阶段"] B["遏制阶段"] C["根除阶段"] D["恢复阶段"] E["跟踪阶段"] A --> B A --> C A --> D A --> E B --> B1["制止事态扩大"] B --> B2["隔离受影响系统"] B --> B3["防止进一步损失"] C --> C1["实施补救措施"] C --> C2["清除威胁根源"] C --> C3["修复安全漏洞"] D --> D1["恢复系统运营"] D --> D2["验证系统安全"] D --> D3["恢复业务服务"] E --> E1["降低风险再发"] E --> E2["总结经验教训"] E --> E3["改进安全措施"] style B fill:#fff3e0,stroke:#f57c00 style C fill:#ffebee,stroke:#c62828 style D fill:#e8f5e9,stroke:#388e3d style E fill:#e3f2fd,stroke:#1976d2

2.3 恢复阶段的行动

恢复阶段的主要工作内容：

graph TB A["恢复阶段行动"] B["✅ 建立临时业务处理能力"] C["✅ 修复原系统损害"] D["✅ 在原系统或新设施中恢复运行"] E["❌ 避免造成更大损失"] A --> B A --> C A --> D A --> E B --> B1["临时环境搭建"] B --> B2["关键业务优先"] B --> B3["确保业务连续性"] C --> C1["系统修复"] C --> C2["数据恢复"] C --> C3["配置还原"] D --> D1["系统测试"] D --> D2["业务验证"] D --> D3["正式上线"] E --> E1["这是遏制阶段的工作"] E --> E2["不属于恢复阶段"] style B fill:#e8f5e9,stroke:#388e3d style C fill:#e8f5e9,stroke:#388e3d style D fill:#e8f5e9,stroke:#388e3d style E fill:#ffcdd2,stroke:#b71c1c

💡 恢复阶段 vs 遏制阶段

恢复阶段的主要工作：

✅ 建立临时业务处理能力

  • 在原系统无法使用时提供临时方案
  • 确保关键业务不中断
  • 可能使用备用系统或手工流程

✅ 修复原系统损害

  • 修复被破坏的系统组件
  • 恢复被删除或损坏的数据
  • 重新配置系统参数

✅ 在原系统或新设施中恢复运行

  • 将业务迁移回修复后的原系统
  • 或在新设施中重建系统
  • 确保系统正常运行

❌ 避免造成更大损失 - 这是遏制阶段的工作

  • 遏制阶段：制止事态扩大，防止进一步损失
  • 恢复阶段：系统已被控制，重点是恢复运营
  • 两个阶段的目标不同

恢复阶段与遏制阶段的区别：

方面 遏制阶段 恢复阶段
主要目标 制止事态扩大 恢复系统运营
关键行动 隔离、阻断、防止损失 修复、测试、恢复业务
时间要求 立即执行 遏制后按计划执行
成功标准 威胁被控制 业务恢复正常

💡 跟踪阶段的重要性

跟踪阶段用来降低事件再次发生的风险：

📊 根本原因分析

  • 深入分析事件发生原因
  • 识别安全控制缺陷
  • 找出流程漏洞

🔄 持续改进

  • 制定改进措施
  • 更新安全策略
  • 加强防护能力

📚 知识积累

  • 记录事件处理经验
  • 更新应急预案
  • 培训团队成员

与其他阶段的区别：

  • 遏制 - 制止事态扩大
  • 根除 - 实施补救措施
  • 恢复 - 使系统或业务恢复运营
  • 跟踪 - 降低风险再次发生的可能性 ✅

阶段目标对比：

阶段 主要目标 时间要求 成功标准
遏制 制止事态扩大 立即 威胁被隔离
根除 清除威胁根源 尽快 威胁被消除
恢复 恢复系统运营 按计划 服务正常
跟踪 降低再发风险 持续 改进措施落实

2.4 响应时间要求

不同级别事件的响应时间：

三、事件通知机制

3.1 通知优先级

在计算机安全事故发生时，需要按照优先级通知相关人员。

通知顺序和优先级：

graph TB A["安全事件发生"] B["第一时间通知"] C["及时通知"] D["适时通知"] E["最后通知"] A --> B A --> C A --> D A --> E B --> B1["系统管理员
立即响应"] B --> B2["恢复协调员
协调资源"] C --> C1["硬件和软件厂商
技术支持"] C --> C2["安全团队
分析处理"] D --> D1["管理层
决策支持"] D --> D2["相关业务部门
业务影响评估"] E --> E1["律师
法律咨询"] E --> E2["公关部门
对外沟通"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#fff3e0,stroke:#f57c00 style D fill:#ffccbc,stroke:#d84315 style E fill:#ffcdd2,stroke:#b71c1c

💡 为什么律师最后通知

律师不被通知或最后才被通知的原因：

⏱️ 时间敏感性

  • 技术响应需要立即进行
  • 律师介入可能延缓技术处理
  • 法律咨询不是紧急技术响应的前提

🔧 技术优先

  • 首要任务是遏制和恢复
  • 技术团队需要快速决策
  • 法律问题可以事后处理

📋 证据保全

  • 技术团队会保留必要证据
  • 律师介入时机应在事件稳定后
  • 避免法律程序影响技术响应

💼 业务连续性

  • 优先恢复业务运营
  • 法律问题通常不影响技术恢复
  • 律师咨询可以并行进行

通知人员及其职责：

角色 通知优先级 主要职责 通知时机
系统管理员 🔴 最高 技术响应、系统恢复 立即
恢复协调员 🔴 最高 协调资源、统筹响应 立即
硬件/软件厂商 🟡 高 技术支持、补丁提供 确认需要后
安全团队 🟡 高 威胁分析、安全加固 初步分析后
管理层 🟠 中 决策支持、资源批准 评估影响后
业务部门 🟠 中 业务影响评估、用户沟通 影响明确后
律师 🟢 低 法律咨询、合规建议 事件稳定后
公关部门 🟢 低 对外沟通、声誉管理 需要对外时

3.2 组织内应急通知方式

组织内应急通知应主要采用电话方式：

graph TB A["应急通知方式"] B["电话通知"] C["其他方式"] A --> B A --> C B --> B1["✅ 快速有效"] B --> B2["✅ 实时沟通"] B --> B3["✅ 确认接收"] B --> B4["✅ 紧急情况首选"] C --> C1["电子邮件"] C --> C2["人员传达"] C --> C3["公司OA"] C1 --> C1A["❌ 效率较低"] C2 --> C2A["❌ 效率较低"] C3 --> C3A["❌ 效率较低"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#ffcdd2,stroke:#b71c1c

📞 为什么电话是首选通知方式

电话通知的优势：

⚡ 快速有效

  • 立即送达，无延迟
  • 实时双向沟通
  • 可以立即确认接收

🎯 适合紧急情况

  • 安全事件需要快速响应
  • 时间就是损失
  • 不能等待邮件查收

✅ 确保送达

  • 直接联系到人
  • 可以确认对方理解
  • 避免信息遗漏

❌ 其他方式的局限：

  • 电子邮件 - 可能不及时查看，效率较低
  • 人员传达 - 传递速度慢，可能失真
  • 公司OA - 需要登录查看，效率较低

通知方式对比：

通知方式 速度 确认性 适用场景 推荐度
电话 ⚡ 最快 ✅ 高 紧急事件 🔴 首选
短信 ⚡ 快 ⚠️ 中 简短通知 🟡 备选
电子邮件 🐌 慢 ❌ 低 详细信息 🟢 补充
OA系统 🐌 慢 ❌ 低 正式通知 🟢 补充
人员传达 🐌 很慢 ❌ 低 非紧急 ⚪ 不推荐

3.3 应急响应小组通知顺序

如果可能，最应该得到第一个应急事件通知的小组是应急响应日常运行小组：

graph TB A["安全事件发生"] B["第一通知"] C["后续通知"] A --> B B --> C B --> B1["应急响应日常运行小组"] B1 --> B1A["评估损害性质和程度"] B1A --> B1B["确定如何实施应急响应计划"] C --> C1["应急响应技术保障小组"] C --> C2["应急响应实施小组"] C --> C3["应急响应领导小组"] style B fill:#c8e6c9,stroke:#2e7d32 style B1 fill:#e3f2fd,stroke:#1976d2

💡 为什么日常运行小组应该第一个得到通知

日常运行小组的关键作用：

🔍 损害评估

  • 对系统损害性质和程度的评估非常重要
  • 需要在确保人员安全的前提下尽快完成
  • 评估结果决定如何实施应急响应计划

⚡ 快速决策

  • 确定信息安全事件后如何实施应急响应计划
  • 评估是否需要激活完整的应急响应
  • 决定需要调动哪些资源

👥 人员安全优先

  • 最优先任务是确保人员安全
  • 在此前提下尽快完成损害评估
  • 避免盲目响应造成更大损失

❌ 为什么不是领导小组：

  • 领导小组负责决策和资源调配
  • 但需要先有损害评估信息
  • 日常运行小组提供决策依据

应急响应小组通知顺序和职责：

通知顺序 小组名称 主要职责 通知时机
1️⃣ 第一 应急响应日常运行小组 损害评估、确定响应方案 事件发生后立即
2️⃣ 第二 应急响应技术保障小组 提供技术支持和资源 评估完成后
3️⃣ 第三 应急响应实施小组 执行具体响应措施 方案确定后
4️⃣ 第四 应急响应领导小组 重大决策、资源调配 需要高层决策时

3.4 通知内容

事件通知应包含的信息：

事件通知模板：
├── 基本信息
│   ├── 事件编号
│   ├── 发现时间
│   ├── 报告人
│   └── 事件类型
├── 事件描述
│   ├── 受影响系统
│   ├── 攻击方式
│   ├── 当前状态
│   └── 初步影响
├── 响应措施
│   ├── 已采取的行动
│   ├── 计划的措施
│   ├── 需要的支持
│   └── 预计恢复时间
└── 后续安排
    ├── 下次更新时间
    ├── 联系人信息
    └── 升级机制

四、应急响应团队

4.1 团队组成

计算机安全事件响应团队（CSIRT）：

graph TB A["CSIRT团队"] B["核心成员"] C["扩展成员"] D["外部支持"] A --> B A --> C A --> D B --> B1["事件响应经理"] B --> B2["安全分析师"] B --> B3["系统管理员"] B --> B4["网络工程师"] C --> C1["业务代表"] C --> C2["法务顾问"] C --> C3["公关人员"] C --> C4["人力资源"] D --> D1["厂商技术支持"] D --> D2["外部安全专家"] D --> D3["执法机构"] D --> D4["监管机构"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#fff3e0,stroke:#f57c00 style D fill:#f3e5f5,stroke:#7b1fa2

团队成员职责：

角色 主要职责 所需技能
事件响应经理 统筹协调、决策指挥 管理、沟通、技术
安全分析师 威胁分析、取证调查 安全技术、分析能力
系统管理员 系统恢复、配置修复 系统管理、故障排除
网络工程师 网络隔离、流量分析 网络技术、协议分析

4.2 团队准备

日常准备工作：

✅ 培训演练

  • 定期进行桌面演练
  • 模拟真实事件场景
  • 测试响应流程
  • 评估响应能力

✅ 工具准备

  • 取证工具包
  • 备份恢复系统
  • 通信工具
  • 文档模板

✅ 知识库建设

  • 事件处理手册
  • 联系人清单
  • 系统配置文档
  • 历史事件记录

五、应急响应计划

5.1 应急响应计划与应急响应的关系

应急响应计划与应急响应的相互关系：

应急响应计划与应急响应这两个方面是相互补充与促进的关系。

graph LR A["应急响应计划"] --> B["指导策略"] B --> C["应急响应"] C --> D["发现不足"] D --> E["改进计划"] E --> A style A fill:#e3f2fd,stroke:#1976d2 style B fill:#fff3e0,stroke:#f57c00 style C fill:#e8f5e9,stroke:#388e3d style D fill:#ffebee,stroke:#c62828 style E fill:#f3e5f5,stroke:#7b1fa2

💡 应急响应计划与应急响应的关系

正确的理解：

✅ 相互补充与促进

  • 应急响应计划为应急响应提供指导
  • 应急响应实践验证计划的有效性
  • 两者相互促进、持续改进

✅ 计划提供指导

  • 应急响应计划为信息安全事件发生后的应急响应提供了指导策略和规范
  • 明确响应流程和职责分工
  • 提供处置措施和资源保障

✅ 响应发现不足

  • 应急响应可能发现事前应急响应计划的不足
  • 实践中暴露计划的缺陷
  • 为计划改进提供依据

❌ 错误的理解：

  • 应急响应必须完全依照应急响应计划执行 ❌
  • 应急响应计划不一定跟现实情况完全匹配
  • 可以根据实际情况灵活调整
  • 计划是指导而非僵化的规定

应急响应的灵活性：

方面 说明
计划作用 提供指导框架和基本规范
执行灵活性 可根据实际情况调整
调整原则 在保证目标的前提下灵活应对
改进机制 从实践中发现问题并改进计划

5.2 应急响应计划测试

应急响应计划测试频率：

应急响应计划应该在以下情况进行测试：

  • ✅ 当基础环境或设施发生变化时
  • ✅ 当组织内业务发生重大的变更时
  • ✅ 至少每年进行一次

💡 应急响应计划测试时机

何时需要测试应急响应计划：

🏢 业务重大变更

  • 公司业务发生重大改变
  • 组织架构调整
  • 新业务系统上线

🔧 环境设施变化

  • 基础环境发生变化
  • 设施更新或迁移
  • 技术架构调整

📅 定期测试

  • 至少每年进行一次
  • 确保计划的有效性
  • 保持团队响应能力

❌ 不合理的测试频率：

  • 10年测试一次 - 太长，计划可能过时
  • 2年测试一次 - 不够频繁

测试类型：

测试类型 说明 频率
桌面演练 讨论式演练，模拟场景 每季度
功能测试 测试特定功能或流程 每半年
全面演练 完整的实战演练 每年
触发测试 环境或业务变更后 按需

5.3 应急响应计划建立步骤

建立应急响应计划的正确步骤：

graph TB A["1. 获得管理层支持"] --> B["2. 实施业务影响分析"] B --> C["3. 确定应急人员"] C --> D["4. 建立业务恢复计划"] D --> E["5. 建立备份解决方案"] E --> F["6. 测试和演练"] A --> A1["最重要的第一步"] B --> B1["识别关键系统和业务"] C --> C1["组建应急响应团队"] D --> D1["制定恢复策略"] E --> E1["确保数据可恢复"] F --> F1["验证计划有效性"] style A fill:#c8e6c9,stroke:#2e7d32 style B fill:#e3f2fd,stroke:#1976d2 style C fill:#fff3e0,stroke:#f57c00 style D fill:#f3e5f5,stroke:#7b1fa2 style E fill:#e8f5e9,stroke:#388e3d style F fill:#fce4ec,stroke:#c2185b

💡 建立应急响应计划的关键步骤

第一步：获得管理层支持（最重要）

👔 为什么管理层支持最重要：

  • 落实应有的关注和重视
  • 提供必要的资源和资金
  • 确保各部门配合
  • 赋予计划权威性

📊 第二步：实施业务影响分析

  • 识别关键系统和业务
  • 确定应急与恢复优先级
  • 评估业务中断影响
  • 为后续工作提供依据

步骤顺序的重要性：

  • 没有管理层支持，计划难以推进
  • 没有业务影响分析，无法确定优先级
  • 步骤顺序不能颠倒

各步骤详解：

步骤 主要工作 关键输出 负责人
1. 管理层支持 获得承诺、资源、授权 项目批准、预算 高层管理
2. 业务影响分析 识别关键业务、评估影响 BIA报告 业务部门+安全团队
3. 确定应急人员 组建团队、明确职责 团队名单、职责表 安全经理
4. 业务恢复计划 制定恢复策略和流程 恢复计划 应急团队
5. 备份解决方案 建立备份和恢复机制 备份方案 技术团队
6. 测试和演练 验证计划有效性 测试报告 全体成员

5.4 业务影响分析（BIA）

业务影响分析的工作内容：

业务影响分析（BIA）包括以下工作内容：

  • ✅ 确定应急响应的恢复目标
  • ✅ 确定公司的关键系统和业务
  • ✅ 确定支持公司运行的关键系统
  • ❌ 确定业务面临风险时的潜在损失和影响（属于风险评估）
graph TB A["业务影响分析 BIA"] B["识别关键业务"] C["确定恢复目标"] D["识别关键系统"] E["评估业务依赖"] A --> B A --> C A --> D A --> E B --> B1["核心业务流程"] B --> B2["业务优先级"] C --> C1["RTO恢复时间目标"] C --> C2["RPO恢复点目标"] D --> D1["关键IT系统"] D --> D2["支持系统"] E --> E1["系统依赖关系"] E --> E2["资源需求"] style A fill:#e3f2fd,stroke:#1976d2 style B fill:#e8f5e9,stroke:#388e3d style C fill:#fff3e0,stroke:#f57c00 style D fill:#f3e5f5,stroke:#7b1fa2 style E fill:#fce4ec,stroke:#c2185b

💡 BIA与风险评估的区别

业务影响分析（BIA）的工作：

✅ 确定关键业务和系统

  • 识别对组织最重要的业务
  • 确定支持业务的关键系统
  • 分析业务和系统的依赖关系

✅ 确定恢复目标

  • RTO（Recovery Time Objective）恢复时间目标
  • RPO（Recovery Point Objective）恢复点目标
  • 最大可容忍中断时间

❌ 不属于BIA的工作：

  • 确定业务面临风险时的潜在损失和影响
  • 这是风险评估（Risk Assessment）的工作
  • BIA关注"影响"，风险评估关注"损失"

BIA与风险评估对比：

方面 业务影响分析（BIA） 风险评估（RA）
关注点 业务中断的影响 威胁和脆弱性
目标 确定恢复优先级 识别和评估风险
输出 关键业务、RTO/RPO 风险清单、损失评估
时机 应急计划制定前 安全规划阶段

5.5 应急响应策略制定

制定应急响应策略的考虑因素：

制定应急响应策略主要需要考虑以下三个因素：

  1. ✅ 系统恢复能力等级划分
  2. ✅ 系统恢复资源的要求
  3. ✅ 费用考虑
  4. ❌ 人员考虑（不是主要因素）

💡 应急响应策略制定的三大因素

主要考虑因素：

📊 系统恢复能力等级划分

  • 参考GB/T 20988-2007《信息安全技术 信息系统灾难恢复规范》
  • 附录A 灾难恢复能力等级划分
  • 从第0级到第6级

🔧 系统恢复资源的要求

  • 参考GB/T 20988-2007 第6.3节
  • 灾难恢复资源要求
  • 包括场地、设备、网络、数据等

💰 费用考虑

  • 投资成本与业务价值平衡
  • 不同等级的成本差异
  • ROI（投资回报率）分析

❌ 人员不是主要考虑因素

  • 人员是实施层面的问题
  • 不是策略制定的主要因素

灾难恢复能力等级：

等级 名称 恢复能力 适用场景
第0级 无备份 无恢复能力 非关键系统
第1级 数据备份 数据可恢复 一般系统
第2级 热备份 快速恢复 重要系统
第3级 活动备份 小时级恢复 关键系统
第4级 实时备份 分钟级恢复 核心系统
第5级 双活中心 秒级切换 极关键系统
第6级 零数据丢失 无数据丢失 最高要求

5.6 应急响应领导小组

应急响应领导小组的组成和职责：

应急响应领导小组是信息安全应急响应工作的组织领导机构。

graph TB A["应急响应领导小组"] B["组长
最高管理层"] C["副组长
IT部门领导"] D["成员
各部门代表"] A --> B A --> C A --> D B --> B1["总体领导"] B --> B2["重大决策"] B --> B3["资源调配"] C --> C1["协助组长"] C --> C2["技术指导"] C --> C3["日常管理"] D --> D1["部门协调"] D --> D2["执行任务"] D --> D3["信息反馈"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#e3f2fd,stroke:#1976d2 style D fill:#fff3e0,stroke:#f57c00

💡 应急响应领导小组组长

组长应由最高管理层担任：

👔 为什么必须是最高管理层：

  • 具有足够的权威性
  • 能够调动全组织资源
  • 可以做出重大决策
  • 体现组织对安全的重视

❌ 不适合担任组长的角色：

  • 信息技术部门领导 - 权限不够
  • 业务部门领导 - 视角局限
  • 外部专家 - 非组织成员

应急响应领导小组主要职责：

领导小组的职责是领导和决策信息安全应急响应的重大事宜，主要包括：

  1. ✅ 对应急响应工作的承诺和支持，包括发布正式文件、提供必要资源（人财物）等
  2. ✅ 审核并批准应急响应策略
  3. ✅ 审核并批准应急响应计划
  4. ✅ 批准和监督应急响应计划的执行
  5. ✅ 启动定期评审、修订应急响应计划
  6. ❌ 组织应急响应计划演练（不是领导小组的职责，是工作小组的职责）

职责对比：

职责 领导小组 工作小组
承诺和支持 ✅ 是 ❌ 否
审批策略和计划 ✅ 是 ❌ 否
监督执行 ✅ 是 ❌ 否
组织演练 ❌ 否 ✅ 是
具体实施 ❌ 否 ✅ 是
技术处理 ❌ 否 ✅ 是

批准权限：

应急响应计划的批准权在管理层。

角色 是否有批准权 说明
管理层 ✅ 是 拥有公司内所有事件的批准权
应急委员会 ❌ 否 负责执行，无批准权
各部门 ❌ 否 参与制定，无批准权
外部专家 ❌ 否 提供建议，无批准权

5.7 应急响应流程顺序

应急响应流程的正确顺序：

应急响应流程一般顺序是：信息安全事件通告 → 信息安全事件评估 → 应急启动 → 应急处置 → 后期处置

graph LR A["1. 信息安全
事件通告"] --> B["2. 信息安全
事件评估"] B --> C["3. 应急启动"] C --> D["4. 应急处置"] D --> E["5. 后期处置"] A --> A1["发现并报告事件"] B --> B1["评估严重程度"] C --> C1["启动应急预案"] D --> D1["遏制、根除、恢复"] E --> E1["总结、改进"] style A fill:#e3f2fd,stroke:#1976d2 style B fill:#fff3e0,stroke:#f57c00 style C fill:#ffebee,stroke:#c62828 style D fill:#e8f5e9,stroke:#388e3d style E fill:#f3e5f5,stroke:#7b1fa2

💡 应急响应流程顺序的重要性

为什么必须按这个顺序：

1️⃣ 信息安全事件通告（第一步）

  • 发现事件后立即通告
  • 启动应急响应机制
  • 通知相关人员

2️⃣ 信息安全事件评估（第二步）

  • 评估事件严重程度
  • 确定影响范围
  • 决定响应级别

3️⃣ 应急启动（第三步）

  • 根据评估结果启动预案
  • 调动应急资源
  • 明确响应策略

4️⃣ 应急处置（第四步）

  • 遏制事态发展
  • 根除威胁
  • 恢复系统

5️⃣ 后期处置（第五步）

  • 事后总结分析
  • 改进措施
  • 更新预案

流程阶段对比：

阶段 主要活动 时间要求 关键输出
事件通告 发现、报告、通知 立即 事件报告
事件评估 分析、评估、分级 快速 评估报告
应急启动 启动预案、调动资源 及时 启动决定
应急处置 遏制、根除、恢复 持续 处置记录
后期处置 总结、改进、更新 事后 改进计划

5.8 应急响应计划培训

应急响应计划培训频率：

在正常情况下，应急响应计划培训应该至少每年举办一次。

💡 应急响应计划培训要求

培训频率：

📅 至少每年一次

  • 对于应急响应计划的培训是对测试的补充
  • 培训至少每年举办一次
  • 确保团队成员熟悉应急流程

🎯 培训目的

  • 确保团队成员了解应急响应计划
  • 熟悉各自的角色和职责
  • 掌握应急响应技能
  • 提高应急响应能力

✅ 培训内容

  • 应急响应计划内容
  • 角色职责和流程
  • 工具和技术使用
  • 案例分析和经验分享

培训与测试的关系：

活动 频率 目的 形式
培训 至少每年一次 提升知识和技能 课堂、演示、讨论
测试 至少每年一次 验证计划有效性 演练、模拟
桌面演练 每季度 熟悉流程 讨论式
全面演练 每年 实战检验 实战式

5.9 应急响应计划检查

应急响应计划检查频率：

在正常情况下，应急计划应该至少每年进行一次针对正确性和完整性的检查。

💡 应急响应计划检查要求

检查频率：

📋 至少每年一次

  • 及时更新对于成功执行应急响应计划是很重要的
  • 作为一般的原则，至少应一年对计划的正确性和完整性进行一次检查

🔄 触发检查的情况

  • 计划发生变化时
  • 系统发生变化时
  • 系统所支持的业务处理发生变化时
  • 恢复规程所需的资源发生重大变化时

✅ 检查内容

  • 计划的正确性
  • 计划的完整性
  • 联系信息的准确性
  • 流程的有效性
  • 资源的可用性

检查时机：

检查时机 说明 是否必须
定期检查 至少每年一次 ✅ 是
计划变化 计划内容更新时 ✅ 是
系统变化 系统架构调整时 ✅ 是
业务变化 业务流程改变时 ✅ 是
资源变化 恢复资源变更时 ✅ 是

5.10 应急响应计划文档分发

应急响应计划文档的分发原则：

应急响应计划文档应该分发给参与应急响应工作的所有人员。

graph TB A["应急响应计划文档"] B["✅ 正确的分发方式"] C["❌ 错误的分发方式"] A --> B A --> C B --> B1["分发给参与应急响应工作的所有人员"] B --> B2["具有多份拷贝在不同的地点保存"] B --> B3["由专人负责保存与分发"] C --> C1["分发给公司所有人员"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#ffcdd2,stroke:#b71c1c

💡 应急响应计划文档分发原则

正确的分发方式：

✅ 分发给参与应急响应工作的所有人员

  • 确保相关人员能够及时获取计划
  • 每个参与者都了解自己的职责
  • 便于应急时快速响应

✅ 具有多份拷贝在不同的地点保存

  • 避免单点故障
  • 确保灾难时仍能获取计划
  • 提高计划的可用性

✅ 由专人负责保存与分发

  • 确保文档的安全性
  • 控制文档的版本
  • 管理文档的更新

❌ 不应该分发给公司所有人员

  • 应急计划有敏感性内容
  • 可能包含系统架构信息
  • 可能包含联系方式等敏感信息
  • 只应分发给需要的人员

文档管理要求：

方面 要求 原因
分发范围 仅限参与应急响应的人员 保护敏感信息
存储位置 多个不同地点 提高可用性
版本控制 专人负责管理 确保一致性
访问控制 限制访问权限 保护机密性
更新机制 及时更新分发 保持有效性

5.11 应急响应计划总则

应急响应计划总则包含的内容：

信息安全应急响应计划总则中，包括以下内容：

  • ✅ 编制目的
  • ✅ 编制依据
  • ✅ 适用范围
  • ✅ 工作原则
  • ❌ 角色职责（不属于总则）
graph TB A["应急响应计划结构"] B["总则"] C["组织体系"] D["响应流程"] E["保障措施"] A --> B A --> C A --> D A --> E B --> B1["编制目的"] B --> B2["编制依据"] B --> B3["适用范围"] B --> B4["工作原则"] C --> C1["角色职责"] C --> C2["团队组成"] C --> C3["汇报机制"] D --> D1["响应流程"] D --> D2["处置措施"] D --> D3["升级机制"] E --> E1["资源保障"] E --> E2["培训演练"] E --> E3["持续改进"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#fff3e0,stroke:#f57c00 style D fill:#e8f5e9,stroke:#388e3d style E fill:#f3e5f5,stroke:#7b1fa2

💡 应急响应计划总则内容

总则包含的四个部分：

🎯 编制目的

  • 说明制定应急响应计划的目的
  • 明确计划的作用和意义
  • 阐述预期达到的目标

📋 编制依据

  • 相关法律法规
  • 行业标准规范
  • 组织安全策略

🔍 适用范围

  • 适用的组织范围
  • 覆盖的系统和业务
  • 事件类型和级别

⚖️ 工作原则

  • 统一领导、分级负责
  • 快速响应、科学处置
  • 预防为主、平战结合

❌ 不属于总则：

  • 角色职责 - 属于组织体系部分
  • 响应流程 - 属于响应流程部分
  • 保障措施 - 属于保障措施部分

应急响应计划结构：

应急响应计划：
├── 总则
│   ├── 编制目的
│   ├── 编制依据
│   ├── 适用范围
│   └── 工作原则
├── 组织体系
│   ├── 领导机构
│   ├── 工作机构
│   ├── 角色职责
│   └── 专家组
├── 响应流程
│   ├── 事件分类
│   ├── 响应流程
│   ├── 处置措施
│   └── 升级机制
├── 保障措施
│   ├── 资源保障
│   ├── 技术保障
│   ├── 培训演练
│   └── 经费保障
└── 附则
    ├── 术语定义
    ├── 预案管理
    └── 实施时间

六、病毒感染响应

6.1 病毒感染的应急处理

发现病毒感染终端后的正确处理步骤：

发现一台被病毒感染的终端后，首先应该：拔掉网线

graph TB A["发现病毒感染终端"] B["1️⃣ 第一步
拔掉网线"] C["2️⃣ 第二步
判断病毒性质"] D["3️⃣ 第三步
寻找解决方法"] E["4️⃣ 第四步
清除病毒"] A --> B B --> C C --> D D --> E B --> B1["隔离病毒源"] B --> B2["防止扩散"] B --> B3["保护其他系统"] C --> C1["分析病毒类型"] C --> C2["确定采用的端口"] C --> C3["评估影响范围"] D --> D1["搜索解决方案"] D --> D2["联系技术人员"] D --> D3["获取杀毒工具"] E --> E1["清除病毒"] E --> E2["修复系统"] E --> E3["验证安全"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#e3f2fd,stroke:#1976d2 style D fill:#fff3e0,stroke:#f57c00 style E fill:#e8f5e9,stroke:#388e3d

💡 为什么首先要拔掉网线

第一时间隔离病毒源的重要性：

🚨 防止病毒扩散

  • 发现病毒后，第一时间应该隔离病毒源
  • 拔掉网线可以立即切断病毒传播途径
  • 防止病毒通过网络感染其他系统

⚡ 时间就是损失

  • 病毒可能在几秒内传播到整个网络
  • 立即隔离可以最大限度减少损失
  • 其他操作都可以在隔离后进行

🎯 正确的处理顺序

  1. 拔掉网线（隔离）✅ 第一步
  2. 判断病毒的性质、采用的端口
  3. 在网上搜寻病毒解决方法
  4. 呼叫公司技术人员

❌ 错误的做法：

  • 先判断病毒性质 - 浪费时间，病毒可能已扩散
  • 先搜索解决方法 - 病毒继续传播
  • 先呼叫技术人员 - 等待期间病毒扩散

病毒响应步骤详解：

步骤 操作 目的 时间要求
1 拔掉网线 隔离病毒源，防止扩散 立即
2 判断病毒性质 了解病毒类型和传播方式 尽快
3 寻找解决方法 获取清除方案 及时
4 清除病毒 恢复系统正常 按计划
5 验证安全 确认病毒已清除 清除后
6 恢复网络 重新连接网络 验证后

七、我国信息安全事件分级

7.1 事件分级标准

我国信息安全事件分级分为以下级别：

特别重大事件 - 重大事件 - 较大事件 - 一般事件

graph TB A["我国信息安全事件分级"] B["特别重大事件"] C["重大事件"] D["较大事件"] E["一般事件"] A --> B A --> C A --> D A --> E B --> B1["影响特别严重"] B --> B2["涉及国家安全"] B --> B3["造成重大损失"] C --> C1["影响严重"] C --> C2["涉及重要系统"] C --> C3["造成较大损失"] D --> D1["影响较大"] D --> D2["涉及一般系统"] D --> D3["造成一定损失"] E --> E1["影响有限"] E --> E2["局部范围"] E --> E3["损失较小"] style B fill:#ffcdd2,stroke:#b71c1c style C fill:#ffccbc,stroke:#d84315 style D fill:#fff3e0,stroke:#f57c00 style E fill:#c8e6c9,stroke:#2e7d32

💡 我国信息安全事件分级

四级分类标准：

🔴 特别重大事件（I级）

  • 造成特别严重影响
  • 涉及国家安全和社会稳定
  • 需要国家层面协调处置

🟠 重大事件（II级）

  • 造成严重影响
  • 涉及重要信息系统
  • 需要省级层面协调处置

🟡 较大事件（III级）

  • 造成较大影响
  • 涉及一般信息系统
  • 需要市级层面协调处置

🟢 一般事件（IV级）

  • 造成一定影响
  • 局部范围内
  • 单位内部可以处置

❌ 不存在的分级：

  • 严重事件 - 不是标准分级
  • 特别严重事件 - 不是标准分级

7.2 信息系统重要程度划分

依据信息系统的重要程度对信息系统进行划分：

我国信息安全事件分级参考三个要素：信息系统的重要程度、系统损失和社会影响。其中，依据信息系统的重要程度对信息系统进行划分的正确级别包括：

graph TB A["信息系统重要程度划分"] B["✅ 特别重要信息系统"] C["✅ 重要信息系统"] D["✅ 一般信息系统"] E["❌ 关键信息系统"] A --> B A --> C A --> D A --> E B --> B1["国家关键基础设施"] B --> B2["涉及国家安全"] B --> B3["影响社会稳定"] C --> C1["重要业务系统"] C --> C2["影响较大范围"] C --> C3["重要数据处理"] D --> D1["一般业务系统"] D --> D2["影响有限"] D --> D3["常规数据处理"] E --> E1["不是标准划分"] E --> E2["虽然常用但非官方分类"] style B fill:#ffcdd2,stroke:#b71c1c style C fill:#ffccbc,stroke:#d84315 style D fill:#fff3e0,stroke:#f57c00 style E fill:#e0e0e0,stroke:#757575

💡 信息系统重要程度划分

正确的划分级别：

✅ 特别重要信息系统

  • 国家关键基础设施信息系统
  • 涉及国家安全的信息系统
  • 影响社会稳定的信息系统
  • 一旦遭到破坏会严重危害国家安全、社会秩序和公共利益

✅ 重要信息系统

  • 重要业务系统
  • 处理重要数据的系统
  • 影响较大范围的系统
  • 一旦遭到破坏会严重影响组织运营

✅ 一般信息系统

  • 一般业务系统
  • 处理常规数据的系统
  • 影响范围有限的系统
  • 遭到破坏影响相对较小

❌ 关键信息系统（不是标准划分）

  • 虽然"关键信息系统"在实践中常用
  • 但不是官方标准的划分级别
  • 标准划分是：特别重要、重要、一般

信息系统重要程度划分依据：

划分级别 业务重要性 数据敏感性 影响范围 示例
特别重要信息系统 极高 极高 国家级 金融核心系统、电力调度系统
重要信息系统 高 高 行业/区域级 企业核心业务系统
一般信息系统 中 中 组织级 办公自动化系统

7.3 事件分级考虑要素

我国信息安全事件分级考虑三个要素：

  1. ✅ 信息系统的重要程度
  2. ✅ 系统损失
  3. ✅ 社会影响
  4. ❌ 业务损失（不是主要考虑要素）
graph TB A["信息安全事件分级要素"] B["信息系统的重要程度"] C["系统损失"] D["社会影响"] A --> B A --> C A --> D B --> B1["系统等级保护级别"] B --> B2["系统承载业务重要性"] B --> B3["系统覆盖范围"] C --> C1["系统受损程度"] C --> C2["数据丢失情况"] C --> C3["恢复难度"] D --> D1["影响人数"] D --> D2["影响范围"] D --> D3["社会关注度"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#fff3e0,stroke:#f57c00 style D fill:#f3e5f5,stroke:#7b1fa2

💡 事件分级考虑要素

三大考虑要素：

🏢 信息系统的重要程度

  • 系统的等级保护级别
  • 系统承载业务的重要性
  • 系统的覆盖范围和用户数
  • 系统在组织中的地位

💥 系统损失

  • 系统受损的程度
  • 数据丢失或泄露情况
  • 系统恢复的难度
  • 直接经济损失

🌐 社会影响

  • 影响的人数和范围
  • 社会关注程度
  • 对公共利益的影响
  • 对社会稳定的影响

❌ 业务损失不是主要考虑要素

  • 业务损失是结果，不是分级依据
  • 分级主要看系统重要性、损失程度和社会影响
  • 业务损失包含在系统损失中

分级要素对比：

要素 说明 评估指标
信息系统重要程度 系统在组织和社会中的地位 等级保护级别、业务重要性
系统损失 系统和数据受损情况 受损程度、数据丢失、恢复难度
社会影响 对社会和公众的影响 影响范围、关注度、公共利益

7.3 事件分级实际应用

事件分级的三个考虑要素：

我国信息安全事件分级主要考虑以下三个要素：

  1. ✅ 信息系统的重要程度
  2. ✅ 系统损失
  3. ✅ 社会影响

这三个要素共同决定了事件的严重程度和响应级别。

7.4 校园网事件分级示例

校园网安全事件分级详细示例：

根据病毒攻击、非法入侵等原因造成的不同影响程度，校园网安全事件分为四个级别：

graph TB A["校园网安全事件分级"] B["一般事件
IV级"] C["较大事件
III级"] D["重大事件
II级"] E["特别重大事件
I级"] A --> B A --> C A --> D A --> E B --> B1["200台以内主机
不能正常工作"] B --> B2["在校内造成一定影响"] B --> B3["尚未在社会上造成影响"] C --> C1["部分楼宇网络瘫痪"] C --> C2["FTP及部分网站服务器
不能响应"] C --> C3["在校内造成广泛影响"] C --> C4["在社会上造成一定影响"] D --> D1["部分园区瘫痪"] D --> D2["邮件、计费服务器
不能正常工作"] D --> D3["在校内造成实质性影响"] D --> D4["在社会上造成严重影响"] E --> E1["校园网整体瘫痪"] E --> E2["全部DNS、主WEB服务器
不能正常工作"] E --> E3["校园网出口中断"] E --> E4["在校内外造成重大实质性影响"] E --> E5["严重危害国家和社会"] style B fill:#c8e6c9,stroke:#2e7d32 style C fill:#fff3e0,stroke:#f57c00 style D fill:#ffccbc,stroke:#d84315 style E fill:#ffcdd2,stroke:#b71c1c

7.4.1 一般事件（IV级）

示例：
校园网内由于病毒攻击、非法入侵等原因，200台以内的用户主机不能正常工作。

💡 一般事件特征

影响范围评估：

📊 影响程度

  • 200台以内用户主机受影响
  • 在校内造成一定影响
  • 尚未在社会上造成影响

🎯 分级判断依据

  • 影响范围：局部（校园内）
  • 影响程度：有限（200台以内）
  • 社会影响：无
  • 符合一般事件的特征

✅ 处置方式

  • 在组织内部可以处置
  • 不需要上级部门协调
  • 损失可控

7.4.2 较大事件（III级）

示例：
由于病毒攻击、非法入侵等原因：

  • 校园网部分楼宇出现网络瘫痪
  • FTP及部分网站服务器不能响应用户请求

💡 较大事件特征

影响范围评估：

📊 影响程度

  • 部分楼宇网络瘫痪
  • 部分服务器不能响应
  • 在校内造成广泛影响
  • 在社会上造成一定的影响

🎯 分级判断依据

  • 影响范围：较大（多个楼宇）
  • 影响程度：较严重（服务中断）
  • 社会影响：一定影响
  • 符合较大事件的特征

⚠️ 处置方式

  • 需要市级层面协调处置
  • 可能需要外部技术支持
  • 需要及时通报

7.4.3 重大事件（II级）

示例：
由于病毒攻击、非法入侵等原因：

  • 校园网部分园区瘫痪
  • 邮件、计费服务器不能正常工作

💡 重大事件特征

影响范围评估：

📊 影响程度

  • 部分园区网络瘫痪
  • 关键服务器（邮件、计费）不能工作
  • 在校内造成实质性影响
  • 在社会上造成严重影响

🎯 分级判断依据

  • 影响范围：重大（整个园区）
  • 影响程度：严重（关键服务中断）
  • 社会影响：严重影响
  • 符合重大事件的特征

🚨 处置方式

  • 需要省级层面协调处置
  • 必须启动应急预案
  • 需要向上级报告
  • 可能需要外部专家支持

7.4.4 特别重大事件（I级）

示例：
由于病毒攻击、非法入侵、人为破坏或不可抗力等原因：

  • 校园网整体瘫痪
  • 校园网络中心全部DNS、主WEB服务器不能正常工作
  • 校园网出口中断

💡 特别重大事件特征

影响范围评估：

📊 影响程度

  • 校园网整体瘫痪
  • 核心服务全部中断
  • 网络出口完全中断
  • 在校内外造成重大实质性影响
  • 严重危害国家和社会

🎯 分级判断依据

  • 影响范围：全局（整个校园网）
  • 影响程度：特别严重（全部中断）
  • 社会影响：严重危害国家和社会
  • 符合特别重大事件的特征

🔴 处置方式

  • 需要国家层面协调处置
  • 必须立即启动最高级别应急预案
  • 需要向国家主管部门报告
  • 需要多方协调和支持

校园网事件分级对比表：

事件级别 受影响范围 服务中断情况 校内影响 社会影响 处置层级
一般事件（IV级） 200台以内主机 局部用户 一定影响 无 单位内部
较大事件（III级） 部分楼宇 FTP、部分网站 广泛影响 一定影响 市级协调
重大事件（II级） 部分园区 邮件、计费服务器 实质性影响 严重影响 省级协调
特别重大事件（I级） 整体瘫痪/出口中断 全部DNS、主WEB 重大实质性影响 危害国家和社会 国家协调

八、业务连续性管理与灾难恢复

8.1 IT服务连续性管理

确保重大故障后IT服务连续性：

由于独立的信息系统增加，一个国有房产公司要求在发生重大故障后，必须保证能够继续提供IT服务。需要实施哪个流程才能提供这种保证性？

答案：IT服务连续性管理

💡 IT服务连续性管理

IT服务连续性管理的目标：

🎯 主要目标

  • IT服务连续性管理的目标之一是保障灾难性故障发生后，能尽快恢复业务或仍能提供服务
  • 确保业务运营在灾难期间也能继续
  • 最大限度减少业务中断时间

为什么其他选项不正确：

  • 可用性管理 - 关注系统正常运行时间，不是灾难恢复
  • 服务级别管理 - 管理服务协议，不是连续性
  • 服务管理 - 通用术语，不专指连续性

8.2 业务持续性计划中的危机宣布

未定义危机宣布的风险：

在一家企业的业务持续性计划中，什么情况被宣布为一个危机没有被定义。这一点关系到的主要风险是：

答案：灾难恢复计划的执行可能会被影响

💡 危机宣布定义的重要性

为什么未定义危机宣布有问题：

🚨 影响计划执行

  • 如果组织不知道什么时候应该宣告灾难发生，将会影响业务持续性计划的执行
  • 延迟宣告意味着延迟响应
  • 响应团队的作用将被削弱

其他选项是危机评估的步骤：

  • 对这种情况的评估可能会延迟
  • 团队通知可能不会发生
  • 对潜在危机的识别可能会无效

这些都是判定灾难是否产生的步骤，但核心问题是没有明确的宣告标准，整个灾难恢复计划执行都会受到影响。

8.3 硬件更换后的活动

信息处理设施（IPF）硬件更换后的首要活动：

在信息处理设施（IPF）的硬件更换之后，业务连续性流程经理首先应该实施下列哪项活动？

答案：更新信息资产清单

💡 为什么首先更新资产清单

信息资产清单的重要性：

📋 BCP/DR的基础

  • 信息资产清单是业务连续性和灾难恢复计划的基础
  • 灾备计划必须反映最新的信息系统架构
  • 计划必须基于当前系统配置

为什么其他选项在后：

  • 验证与热门站点的兼容性 - 在清单更新后进行
  • 检查实施报告 - 管理任务，不是技术优先级
  • 进行灾难恢复计划的演练 - 在计划更新后进行

正确顺序：

  1. 更新信息资产清单 ✅
  2. 基于新清单更新灾难恢复计划
  3. 验证兼容性并进行演练

8.4 灾难恢复计划目标

组织灾难恢复计划的目标：

组织的灾难恢复计划应该：

答案：减少恢复时间，降低恢复费用

💡 灾难恢复计划目标

主要目标：

⏱️ 减少恢复时间

  • 最大限度缩短恢复正常运营的时间
  • 快速响应和恢复程序
  • 预先规划的恢复策略

💰 降低恢复费用

  • 成本效益的恢复解决方案
  • 高效的资源利用
  • 最大限度减少整体灾难影响成本

为什么其他选项不正确：

  • 增加恢复时间，提高恢复费用 - 与目标相反
  • 减少恢复的持续时间，提高恢复费用 - 部分正确但不是最优
  • 对恢复时间和费用都不影响 - 计划专门旨在优化两者

8.5 地理分布组织的成本效益测试

具有大量分支机构且分布地理区域较广的组织的测试方法：

一个组织具有的大量分支机构且分布地理区域较广。以确保各方面的灾难恢复计划的评估，具有成本效益的方式，应建议使用：

答案：预案测试

💡 为什么预案测试最具成本效益

预案测试的优势：

💰 成本效益

  • 可以在每一个当地办事处/地区进行
  • 不需要昂贵的全面演练
  • 资源需求最少
  • 可以持续在该计划的不同方面执行

🌍 适合分布式组织

  • 每个分支机构可以进行本地预案测试
  • 测试本地业务连续性的不同方面
  • 是一个能获得该计划足够证据的具有成本效益的方式
  • 可在地理位置间扩展

为什么其他选项不太适合：

  • 数据恢复测试 - 范围有限，不能确保各方面的评价
  • 充分的业务测试 - 对地理上分散的分支机构不是最符合成本效益的测试
  • 前后测试 - 是一个阶段的测试执行过程，不够全面

8.6 恢复时间目标（RTO）影响

较低的恢复时间目标（RTO）的结果：

较低的恢复时间目标（恢复时间目标）的会有如下结果：

答案：更高的容灾成本

💡 RTO与成本关系

理解RTO：

⏱️ 什么是RTO

  • 恢复时间目标（RTO）是基于可以接受的停机时间的
  • 较低的RTO意味着更少的可接受停机时间
  • 需要更快的恢复能力

💰 成本影响

  • 较低的恢复时间目标，就会有更高的成本回收的策略
  • 需要更昂贵的基础设施和解决方案
  • 在冗余和自动化方面需要更大投资

为什么其他选项不正确：

  • 更高的成本 ✅ 正确
  • 更长的中断时间 ❌ 较低的RTO意味着更短的中断
  • 更多许可的数据丢失 ❌ 那是RPO，不是RTO

8.7 实施灾难恢复计划后的下一步

实施灾难恢复计划后的下一步：

组织实施了灾难恢复计划。下列哪些步骤应下一步执行？

答案：进行纸面测试

💡 为什么纸面测试排在第一

最佳实践顺序：

📋 纸面测试优先

  • 最好的做法是进行纸面测试
  • 低成本验证计划逻辑的方式
  • 识别明显的差距和问题
  • 为更复杂的测试做准备

为什么其他选项在前或在后：

  • 取得高级管理人员认可 - 应该在计划实施之前完成
  • 确定的业务需求 - 在计划开发之前完成
  • 进行系统还原测试 - 在纸面测试验证计划后进行

正确测试顺序：

  1. 纸面测试（验证计划逻辑）
  2. 系统/技术测试（验证技术程序）
  3. 全面演练（验证完整响应）

8.8 灾难性恢复计划（DRP）基础

灾难性恢复计划（DRP）基于：

答案：技术方面的业务连续性计划

💡 DRP与BCP关系

理解关系：

🔧 DRP是技术组件

  • 灾难恢复计划（DRP）是技术方面的业务连续性计划
  • 专注于IT系统和技术恢复
  • 实施系统恢复的技术程序

🏢 BCP更广泛

  • 业务恢复计划是业务持续性计划的运作部分
  • 涵盖业务流程和操作程序
  • 包括连续性的非技术方面

组件分解：

  • 业务连续性计划（BCP） - 整体框架
    • 技术方面 → 灾难恢复计划（DRP）✅
    • 操作方面 → 业务恢复计划（BRP）
    • 功能方面 → 各种功能计划

8.9 非关键系统的恢复方案

恢复非关键系统的最合理方案：

答案：冷站

💡 恢复站点选项

冷站特征：

💰 成本效益

  • 通常成本比较低的选项
  • 只提供最基本的环境
  • 适合非临界应用

⏱️ 较长恢复时间

  • 投入使用需要更多时间
  • 对非关键系统可以接受
  • 成本节省证明较长恢复时间合理

其他站点类型：

  • 热站 - 最高成本，最短恢复时间，用于关键系统
  • 温站 - 中等成本，中等恢复时间，适合敏感的行动
  • 移动站点 - 特别设计的拖车式计算设备，用于特定需求

8.10 业务连续性计划的适当测试方法

适用于业务连续性计划（BCP）的适当测试方法：

答案：纸面测试

💡 BCP测试方法

为什么纸面测试适当：

📋 适合BCP

  • 纸面测试适用与对业务连续性计划的测试
  • 基于讨论的演练格式
  • 测试计划逻辑和程序
  • 识别差距和改进领域

其他选项：

  • 试运行 - 更多用于系统测试
  • 单元测试 - 用于软件开发
  • 系统测试 - 用于技术系统

8.11 中断和灾难中持续运营的技术手段

在中断和灾难事件中提供持续运营的技术手段：

答案：硬件冗余

💡 持续运营技术

硬件冗余优势：

🔄 真正的连续性

  • 硬件冗余是目前支持持续、不间断服务的唯一的技术手段
  • 提供无缝故障转移能力
  • 消除单点故障

为什么其他选项不提供连续性：

  • 负载平衡 - 通过分配工作量提高性能，不是连续性
  • 高可用性（HA） - 提供快速但不是持续的恢复
  • 分布式备份 - 需要很长的恢复时间，不是持续的

8.12 业务持续计划中最重要的发现

业务持续计划中最重要的发现：

答案：骨干网备份的缺失

💡 关键基础设施依赖

为什么骨干网最关键：

🌐 网络依赖性

  • 骨干网的失效将导致全部网络的瘫痪
  • 影响网络中用户对信息的访问
  • 整个基础设施的单点故障

影响对比：

  • 骨干网故障 ✅ 影响整个网络
  • 不可用的交互PBX系统 - 用户可以利用移动电话或email
  • 用户PC机缺乏备份机制 - 仅影响特定的用户
  • 门禁系统的失效 - 可以通过手工的监控措施来降低风险

8.13 热站、温站或冷站协议考虑事项

热站、温站或冷站协议中的重要考虑事项：

答案：同时允许使用设施的订户数量

💡 站点协议考虑

为什么同时使用限制很重要：

📊 容量规划

  • 合同应详细说明在同一时间允许使用站点的订户数
  • 对确保灾难期间可用性至关重要
  • 多个组织可能同时需要站点

为什么其他选项不太关键：

  • 具体的保证设施 - 重要但不是合同细节
  • 订户的总数 - 不如同时使用重要
  • 涉及的其他用户 - 应在签署前考虑，不是合同条款

8.14 业务持续计划基础

企业业务持续计划的基础：

企业的业务持续性计划中应该以记录以下内容的预定规则为基础：

答案：损耗的持续时间

💡 业务持续计划基础

为什么持续时间是关键：

⏱️ 最大可容忍期间

  • 企业的业务持续性计划实施应首先建立在业务职能被中断前的最大期间内
  • 这应是在企业目标被成功中断之前
  • 决定恢复优先级和策略

基础要素：

  • 损耗的持续时间 ✅ 主要考虑
  • 损耗的类型 - 次要考虑
  • 损耗的可能性 - 风险评估输入
  • 损耗的原因 - 分析输入，不是基础

8.15 备份驱动器故障后的文件恢复

备份过程中备份驱动器故障后的文件恢复：

当更新一个正在运行的在线订购系统时，更新都记录在一个交易磁带和交易日志副本。在一天业务结束后，订单文件备份在磁带上。在备份过程中，驱动器故障和订单文件丢失。以下哪项对于恢复文件是必需的？

答案：前一天的备份文件和当前的交易磁带

💡 文件恢复策略

恢复组件：

📼 前一天的备份

  • 前一天的备份文件将是该系统最当前活动的历史备份
  • 提供恢复的基线
  • 包含到前一个备份点的所有数据

📝 当前交易磁带

  • 当前的交易文件将包含所有的当天的活动
  • 包含自上次备份以来的所有交易
  • 能够完全恢复到故障点

为什么这个组合有效：

  • 前一天备份 + 当前交易 = 完全恢复
  • 将系统恢复到故障前的确切状态
  • 如果正确实施，无数据丢失

8.16 业务影响分析的主要目的

业务影响分析的主要目的：

答案：识别能够影响组织运营持续性的事件

💡 BIA主要目的

业务影响分析（BIA）目标：

🎯 识别影响事件

  • 业务影响分析（BIA）是业务持续性计划中的一个关键环节
  • BIA将识别影响组织运营的持续性的灾难事件
  • 专注于理解什么可能中断业务

为什么其他选项是次要的：

  • 在灾难之后提供一个恢复行动的计划 - 那是灾难恢复计划
  • 公布组织对物理和逻辑安全的义务 - 那是安全策略
  • 提供一个有效灾难恢复计划的框架 - BIA提供输入，不是框架

8.17 理解组织业务流程的工具

建立业务持续性计划时理解业务流程的工具：

当建立一个业务持续性计划时，使用哪个工具用来理解组织业务流程？

答案：风险评估和业务影响评估

💡 理解业务流程的工具

风险评估和业务影响评估的作用：

🔍 理解业务的关键工具

  • 风险评估和业务影响评估是理解业务持续性计划的工具
  • 帮助识别关键业务流程
  • 评估业务中断的影响
  • 确定恢复优先级

其他选项的作用：

  • 业务持续性自我评估 - 评价BCP的频率的工具，不是理解业务的工具
  • 资源的恢复分析 - 识别业务恢复策略的工作，不是理解业务流程
  • 差异分析 - 在业务持续性计划中识别不足，不是用于获取对业务的理解

工具对比：

工具 主要用途 适用阶段
风险评估和BIA 理解业务流程和影响 计划制定前
业务持续性自我评估 评价BCP频率 计划评估阶段
资源恢复分析 识别恢复策略 策略制定阶段
差异分析 识别计划不足 计划审查阶段

8.18 支持24/7可用性的最佳方案

最好地支持24/7可用性的技术：

答案：镜像

💡 24/7可用性支持

镜像的优势：

🔄 快速恢复

  • 关键组件的镜像是促进快速恢复的工具
  • 提供实时数据复制
  • 支持即时故障转移
  • 实现真正的24/7可用性

其他选项的局限：

  • 日常备份 - 使合理的恢复在数小时内发生而不是立即发生
  • 离线存储 - 不支持持续可用性
  • 定期测试 - 验证计划有效性，但不支持持续可用性

可用性方案对比：

方案 恢复时间 数据丢失 成本 适用场景
镜像 即时 无/极少 高 24/7关键系统
日常备份 数小时 一天数据 低 一般系统
离线存储 数天 较多 很低 归档数据
定期测试 N/A N/A 中 验证用途

8.19 评估BCP时的最关注事项

评估BCP时应当最被关注的事项：

答案：宣布灾难的职责没有被识别

💡 为什么灾难宣布职责最关键

灾难宣布的重要性：

🚨 激活计划的前提

  • 如果没有人宣布灾难，反应和恢复计划将不会被激活
  • 使所有其他关注都保持沉默
  • 这是启动整个应急响应的关键

其他关注的相对重要性：

  • 灾难等级基于受损功能的范围，而不是持续时间 - 虽然考虑持续时间不足可能是个问题，但它不象范围那般意义重大，并且它们都不如需要某人激活计划这般紧要
  • 低级别灾难和软件事件之间的区别不清晰 - 事件和低等级灾害的区别总是模糊不清并且经常地围绕着纠正损害所需的时间总量
  • 总体BCP被文档化，但详细恢复步骤没有规定 - 详细步骤的不足应该纪录在案，但是，如果在事实上有人激活了该计划，那么详细步骤的缺失并不意味着恢复的不足

BCP评估优先级：

关注事项 严重程度 影响 优先级
宣布灾难职责未识别 🔴 最高 计划无法激活 1
灾难等级定义不当 🟡 中 响应可能不匹配 2
事件区别不清晰 🟡 中 可能误判级别 3
详细步骤缺失 🟢 低 执行可能困难 4

8.20 模拟演练中报警系统破坏的建议

报警系统严重受到设施破坏时的最佳建议：

在一个业务继续计划的模拟演练中，发现报警系统严重受到设施破坏。

答案：建立冗余的报警系统

💡 为什么冗余是最佳控制

冗余系统的优势：

🔄 最佳控制措施

  • 如果报警系统受到严重破坏，冗余将是最好的控制
  • 提供备用系统
  • 确保在主系统失效时仍能报警
  • 消除单点故障

其他选项为什么不可行：

  • 培训救护组如何使用报警系统 - 救护组将不能使用严重破坏的报警系统，甚至即使他们被培训去使用它
  • 报警系统为备份提供恢复 - 备份的恢复对报警系统无关
  • 把报警系统存放地窖里 - 将也没有什么价值，如果建筑遭到破坏

报警系统保护措施对比：

措施 有效性 成本 适用场景
建立冗余系统 ✅ 高 高 关键设施
培训使用 ❌ 低 低 系统破坏时无效
备份恢复 ❌ 不适用 N/A 与报警系统无关
地窖存放 ❌ 低 低 建筑破坏时无效

8.21 评估业务连续计划效果的最好方法

评估业务连续计划效果最好的方法：

答案：比较之前的测试结果

💡 为什么之前的测试结果最有效

测试结果的价值：

📊 有效证明

  • 之前的测试结果将提供业务持续性计划的有效证明
  • 显示计划的实际执行效果
  • 可以追踪改进趋势
  • 提供客观的评估依据

其他方法的局限：

  • 使用适当的标准进行规划 - 与标准做比较，对该计划涉及的关键方面的业务连续性计划将给予一些保证，但对其有效性不会有任何揭示
  • 紧急预案和员工培训 - 评审紧急预案将提供深入了解计划的某些方面，但可能不能提供该计划的整体成效的保证
  • 环境控制和存储站点 - 存储站点和环境控制将提供深入了解计划的某些方面，但可能不能提供该计划的整体成效的保证

评估方法对比：

评估方法 有效性 全面性 客观性
比较之前测试结果 ✅ 高 ✅ 高 ✅ 高
与标准比较 🟡 中 🟡 中 ✅ 高
评审紧急预案 🟡 中 ❌ 低 🟡 中
检查环境控制 🟡 中 ❌ 低 ✅ 高

8.22 废旧磁带丢弃前的最佳处理方式

丢弃废旧磁带前的最佳处理方式：

答案：对磁带进行消磁

💡 为什么消磁是最佳方法

消磁的优势：

🧲 彻底清除数据

  • 处理废弃磁带的最佳方法是进行消磁
  • 使用强磁场彻底清除磁性记录
  • 确保数据无法恢复
  • 符合数据安全处置要求

其他方法的局限：

  • 删除磁带 - 删除磁带上的数据还留下比少量磁信息
  • 复写磁带 - 复写或删除磁带可以使磁记录改变，但不能完全清除数据
  • 初始化磁带卷标 - 初始化磁带不能清除磁带卷标后的数据

数据清除方法对比：

方法 安全性 彻底性 成本 推荐度
消磁 ✅ 最高 ✅ 完全清除 中 🔴 强烈推荐
复写 🟡 中 🟡 部分残留 低 🟡 一般
删除 ❌ 低 ❌ 可恢复 很低 ⚪ 不推荐
初始化 ❌ 很低 ❌ 大量残留 很低 ⚪ 不推荐

数据销毁最佳实践：

磁带数据销毁流程：
├── 第一步：分类
│   ├── 识别包含敏感数据的磁带
│   ├── 确定数据敏感级别
│   └── 记录磁带信息
├── 第二步：消磁
│   ├── 使用专业消磁设备
│   ├── 确保消磁彻底
│   └── 记录消磁过程
├── 第三步：验证
│   ├── 验证数据无法读取
│   ├── 确认消磁效果
│   └── 记录验证结果
└── 第四步：物理销毁（可选）
    ├── 对高敏感数据磁带
    ├── 进行物理破坏
    └── 记录销毁过程

8.23 多个BCP计划的协调

组织中存在多个独立流程的BCP但缺乏全面计划时的行动：

组织中对于每个独立流程都有对应的业务连续性计划，但缺乏全面的业务连续性计划。

答案：确认所有的业务连续性计划是否相容

💡 为什么需要确认计划相容性

计划协调的重要性：

🔄 相容性优先于整合

  • 对于复杂的组织应该有各方面的业务连续性和灾难恢复计划
  • 并不需要整合成一个单独的计划
  • 但是每个计划应该与其他的业务连续性计划策略保持相容
  • 确保计划之间不冲突

为什么不需要全面整合：

  • 建议建立全面的业务连续性计划 - 对复杂组织不现实
  • 接受已有业务连续性计划 - 忽略了相容性问题
  • 建议建立单独的业务连续性计划 - 已经有独立计划了

多计划管理原则：

方面 要求 原因
相容性 各计划策略一致 避免冲突
独立性 可以保持独立 适应复杂组织
协调性 互相协调配合 整体有效性
灵活性 根据需要调整 适应变化

8.24 年度风险评估后的BCP工作

完成年度风险评估后关于业务持续计划应执行的工作：

组织已经完成了年度风险评估，关于业务持续计划组织应执行哪项工作？

答案：回顾并评价业务持续计划是否恰当

💡 风险评估后的BCP回顾

为什么需要回顾BCP：

🔍 评估计划适用性

  • 组织每次的风险评估应回顾其业务持续计划
  • 确认计划是否仍然适合当前风险环境
  • 识别需要更新的地方
  • 确保计划与风险评估结果一致

其他活动的时机：

  • 对业务持续计划进行完整的演练 - 应该在计划被认为适合组织之后
  • 对职员进行商业持续计划的培训 - 应该在计划被认为适合组织之后
  • 将商业持续计划通报关键联络人 - 没有原因要通报业务持续计划联络人

风险评估与BCP的关系：

风险评估后的BCP管理流程：
├── 第一步：回顾BCP
│   ├── 评估计划是否恰当
│   ├── 识别需要更新的内容
│   └── 确认与风险评估一致
├── 第二步：更新BCP（如需要）
│   ├── 根据新风险调整策略
│   ├── 更新恢复优先级
│   └── 修订应急程序
├── 第三步：培训和演练
│   ├── 培训相关人员
│   ├── 进行桌面演练
│   └── 进行全面演练
└── 第四步：持续监控
    ├── 跟踪风险变化
    ├── 定期评估
    └── 及时调整

8.25 灾难恢复计划的回顾频率

组织回顾信息系统灾难恢复计划的方式：

答案：周期性回顾并更新

💡 DRP回顾的最佳实践

周期性回顾的重要性：

📅 适当的时间间隔

  • 根据业务种类、系统和职员的变化情况，应在适当的时间间隔对计划进行回顾
  • 否则，计划将会过期或不再适用
  • 不同的环境适当的时间间隔是三个月或一年
  • 计划应该得到正规的测试，但下次测试期间应根据组织的种类和信息系统的相对重要性来决定

其他选项的问题：

  • 每半年演练一次 - 太具体，不够灵活
  • 经首席执行官(CEO)认可 - 虽然灾难恢复计划应该得到高级管理层的批准，但不必要由CEO批准，可以由具有相等的或更恰当的其他执行官批准
  • 与组织的所有部门负责人沟通 - 和整个组织的业务连续性计划一样，信息系统灾难恢复计划是技术文档且仅与相关人员沟通

DRP回顾触发因素：

触发因素 回顾频率 说明
业务变化 发生时 业务种类改变
系统变化 发生时 信息系统更新
人员变化 发生时 关键职员变动
定期回顾 3个月-1年 根据组织类型

8.26 灾难恢复计划的成本影响

相对于不存在灾难恢复计划，当前灾难恢复计划的成本对比：

答案：增加

💡 DRP的成本影响

为什么成本会增加：

💰 额外费用

  • 因为灾难恢复计划措施的额外费用，组织的正常运行费用在执行灾难恢复计划后将增加
  • 比如，没有灾难期间的正常运行费用将高于没有灾难恢复计划的运行费用
  • 这是为了获得灾难恢复能力而必须付出的代价

成本增加的来源：

  • 备份设施和设备
  • 冗余系统
  • 定期测试和演练
  • 人员培训
  • 计划维护和更新
  • 备份数据存储

DRP成本效益分析：

方面 无DRP 有DRP 差异
日常运营成本 低 高 增加
灾难发生时损失 极高 低 大幅减少
恢复时间 很长 短 大幅缩短
业务中断影响 严重 可控 显著改善
总体风险 高 低 降低

8.27 多个BCP计划的协调要求

根据组织BCP复杂程度建立多个计划时的必要要求：

根据组织业务连续性计划（BCP）的复杂程度，可以建立多个计划来满足业务连续和灾难恢复的各方面。

答案：每个计划和其它计划保持协调一致

💡 多计划协调的必要性

协调一致的重要性：

🔗 互相协调而非整合

  • 根据组织规模的大小、业务复杂性，可以建立多个计划来满足灾难恢复和业务连续运行的需要
  • 这些计划并不一定要集成到一个计划中
  • 但是计划之间要互相协调，为一个总的业务连续性策略服务
  • 确定计划实施的顺序不太可行，因为计划的实施依赖于灾难的性质、重要性和恢复时间等

为什么其他选项不正确：

  • 所有的计划要整合到一个计划中 - 对复杂组织不现实且不必要
  • 每个计划和其他计划相互依赖 - 过度依赖会降低灵活性
  • 指定所有计划实施的顺序 - 不可行，需根据灾难性质决定

多计划协调原则：

多个BCP计划的协调框架：
├── 总体策略层
│   ├── 统一的业务连续性策略
│   ├── 一致的恢复目标
│   └── 协调的资源分配
├── 计划层
│   ├── 计划A（业务部门1）
│   ├── 计划B（业务部门2）
│   ├── 计划C（IT系统）
│   └── 计划D（关键设施）
├── 协调机制
│   ├── 定期协调会议
│   ├── 统一的指挥结构
│   ├── 共享的资源池
│   └── 一致的通信协议
└── 灵活执行
    ├── 根据灾难性质选择
    ├── 根据影响范围调整
    └── 根据恢复优先级排序

8.28 热站作为备份的优点

使用热站作为备份的优点：

答案：热站在短时间内可运作

💡 热站的特点

热站的主要优势：

⚡ 快速恢复

  • 热站通常在几小时就可运行
  • 提供最快的恢复时间
  • 适合关键业务系统

热站的局限：

  • 费用高 - 使用热站是昂贵的
  • 不适合长期 - 不可作为一个长远的解决办法
  • 需要兼容 - 热站要求设备和系统软件与主站兼容，用来备份

备份站点对比：

站点类型 恢复时间 成本 兼容性要求 适用场景
热站 几小时 很高 必须兼容 关键系统
温站 几天 中等 需要兼容 重要系统
冷站 几周 低 基本环境 非关键系统

8.29 完成BIA后的下一步

完成业务影响分析（BIA）后的下一步业务持续性计划：

答案：制定恢复策略

💡 BCP制定的正确顺序

为什么恢复策略是下一步：

📋 逻辑顺序

  • 制定恢复策略是下一步的业务持续性计划的最佳选择
  • 只有制定了这个策略之后，特色的计划才能被发展、测试和执行
  • BIA提供了基础信息，恢复策略将这些信息转化为行动方案

BCP制定的完整顺序：

  1. 业务影响分析（BIA）✅ 已完成
  2. 制定恢复策略 ✅ 下一步
  3. 制定针对性计划
  4. 实施业务持续性计划
  5. 测试和维护业务持续性计划

BCP制定流程：

BCP制定完整流程：
├── 第一阶段：分析
│   ├── 风险评估
│   ├── 业务影响分析（BIA）✅
│   └── 确定关键业务和RTO/RPO
├── 第二阶段：策略
│   ├── 制定恢复策略 ⬅️ 当前步骤
│   ├── 选择恢复方案
│   └── 确定资源需求
├── 第三阶段：计划
│   ├── 制定详细计划
│   ├── 分配角色职责
│   └── 建立程序文档
├── 第四阶段：实施
│   ├── 获得批准
│   ├── 配置资源
│   └── 培训人员
└── 第五阶段：测试维护
    ├── 进行测试演练
    ├── 评估效果
    └── 持续更新

8.30 信息处理设施硬件更换后的首要任务

硬件更换后业务连续性流程经理的首要活动：

在信息处理设施（IPF）的硬件更换之后，业务连续性流程经理首先应该实施的活动是：

答案：更新信息资产清单

💡 为什么首先更新信息资产清单

信息资产清单的关键作用：

📋 业务连续性和灾难恢复计划的基础

  • 信息资产清单是业务连续性和灾难恢复计划的基础
  • 灾备计划必须反映最新的信息系统架构
  • 硬件更换后，系统配置已经改变
  • 必须先更新清单，才能更新相关计划

正确的处理顺序：

  1. 更新信息资产清单 ✅ 第一步
  2. 基于新清单更新灾难恢复计划
  3. 验证与热门站点的兼容性
  4. 检查实施报告
  5. 进行灾难恢复计划的演练

其他选项为什么在后：

  • 验证与热门站点的兼容性 - 需要基于更新后的清单
  • 检查实施报告 - 管理任务，不是技术优先级
  • 进行灾难恢复计划的演练 - 在更新计划后进行

硬件更换后的活动顺序：

顺序 活动 原因 负责人
1 更新信息资产清单 反映最新系统架构 业务连续性经理
2 更新灾难恢复计划 基于新的资产清单 应急团队
3 验证兼容性 确保备份站点可用 技术团队
4 检查实施报告 管理和文档 项目经理
5 进行演练 验证更新后的计划 全体成员

九、事件后总结

6.1 事后分析

事后分析的关键问题：

事后分析清单：
├── 事件回顾
│   ├── 事件是如何发生的？
│   ├── 为什么没有及时发现？
│   ├── 响应是否及时有效？
│   └── 造成了哪些影响？
├── 根本原因
│   ├── 技术层面的原因
│   ├── 管理层面的原因
│   ├── 人员层面的原因
│   └── 流程层面的原因
├── 改进措施
│   ├── 技术控制加强
│   ├── 流程优化
│   ├── 人员培训
│   └── 监控改进
└── 经验教训
    ├── 成功的做法
    ├── 需要改进的地方
    ├── 最佳实践总结
    └── 知识库更新

6.2 持续改进

改进循环：

graph LR A["事件发生"] --> B["响应处理"] B --> C["事后分析"] C --> D["改进措施"] D --> E["实施改进"] E --> F["监控效果"] F --> A style A fill:#ffebee,stroke:#c62828 style B fill:#fff3e0,stroke:#f57c00 style C fill:#e3f2fd,stroke:#1976d2 style D fill:#f3e5f5,stroke:#7b1fa2 style E fill:#e8f5e9,stroke:#388e3d style F fill:#fce4ec,stroke:#c2185b

九、总结

信息安全事件管理的核心在于：

  1. 快速响应：建立高效的检测和响应机制
  2. 优先级明确：按照正确的顺序通知相关人员
  3. 团队协作：建立专业的事件响应团队
  4. 阶段明确：遵循标准的响应流程
  5. 计划完善：制定完整的应急响应计划
  6. 灵活执行：计划是指导而非僵化规定
  7. 持续改进：从每次事件中学习和改进

🎯 关键要点

事件响应流程：

  • 事件响应六阶段：准备→确认→遏制→根除→恢复→跟踪
  • 遏制阶段：制止事态扩大
  • 根除阶段：实施补救措施
  • 恢复阶段：使系统或业务恢复运营（建立临时业务处理能力、修复原系统损害、恢复运行）
  • 跟踪阶段：降低风险再次发生的可能性
  • 避免造成更大损失是遏制阶段的工作，不是恢复阶段

通知机制：

  • 组织内应急通知应主要采用电话方式（快速有效）
  • 电子邮件、人员传达、公司OA效率较低
  • 应急响应日常运行小组应该第一个得到通知（负责损害评估）
  • 系统管理员和恢复协调员应第一时间通知
  • 律师不被通知或最后才被通知

应急响应计划：

  • 应急响应计划与应急响应相互补充与促进
  • 应急响应不必完全依照计划执行，可根据情况调整
  • 应急响应可能发现计划的不足
  • 计划总则包括：编制目的、编制依据、适用范围、工作原则
  • 角色职责不属于总则，属于组织体系部分

计划建立：

  • 建立应急响应计划最重要的是获得管理层支持
  • 第一步应该实施业务影响分析（BIA）
  • 管理层拥有应急响应计划的批准权

业务影响分析：

  • BIA的主要目的：识别影响组织运营持续性的事件
  • BIA确定关键系统和业务、恢复目标
  • 确定潜在损失和影响是风险评估的工作，不是BIA

应急响应策略：

  • 主要考虑：系统恢复能力等级、资源要求、费用
  • 人员考虑不是主要因素

领导小组：

  • 组长应由最高管理层担任
  • 主要职责包括承诺支持、审批计划、监督执行
  • 组织演练不是领导小组职责

应急响应流程顺序：

  • 事件通告→事件评估→应急启动→应急处置→后期处置

测试、演练和培训：

  • 业务或环境重大变更时应测试
  • 至少每年测试一次
  • 应急响应计划培训至少每年举办一次
  • 应急计划至少每年进行一次正确性和完整性检查
  • 建立专业的CSIRT团队
  • 定期进行演练和培训
  • 重视事后分析和持续改进

文档管理：

  • 应急响应计划文档应分发给参与应急响应工作的所有人员
  • 不应该分发给公司所有人员（有敏感性内容）
  • 具有多份拷贝在不同的地点保存
  • 由专人负责保存与分发

病毒响应：

  • 发现病毒感染终端后，首先应该拔掉网线（隔离病毒源）
  • 第一时间隔离可以防止病毒扩散
  • 其他操作（判断性质、搜索方法、呼叫人员）都在隔离后进行

我国事件分级：

  • 分为四级：特别重大事件、重大事件、较大事件、一般事件
  • 考虑三个要素：信息系统的重要程度、系统损失、社会影响
  • 业务损失不是主要考虑要素
  • 校园网200台以内主机受影响属于一般事件
  • 部分楼宇网络瘫痪、FTP及部分网站服务器不能响应属于较大事件
  • 部分园区瘫痪、邮件计费服务器不能工作属于重大事件
  • 整体瘫痪、全部DNS主WEB服务器不能工作、出口中断属于特别重大事件

业务连续性管理与灾难恢复：

  • IT服务连续性管理目标是保障灾难性故障后能尽快恢复业务或仍能提供服务
  • 未定义危机宣布会影响灾难恢复计划的执行
  • 硬件更换后首先应更新信息资产清单（是BCP/DR的基础）
  • 灾难恢复计划目标是减少恢复时间、降低恢复费用
  • 地理分布组织最具成本效益的测试方式是预案测试
  • 较低的RTO会导致更高的容灾成本
  • 实施灾难恢复计划后下一步应进行纸面测试
  • DRP是技术方面的业务连续性计划
  • 非关键系统最合理的恢复方案是冷站
  • 业务连续性计划适当的测试方法是纸面测试
  • 硬件冗余是提供持续运营的唯一技术手段
  • 业务持续计划中最重要的发现是骨干网备份的缺失
  • 站点协议中最重要的考虑是同时允许使用设施的订户数量
  • 业务持续计划应以损耗的持续时间为基础
  • 文件恢复需要前一天的备份文件和当前的交易磁带
  • BIA的主要目的是识别能够影响组织运营持续性的事件

💡 实践建议

  • 制定详细的事件响应计划
  • 建立24/7的监控和响应能力
  • 定期进行应急演练
  • 保持与外部支持机构的联系
  • 建立完善的事件知识库
  • 定期评估和更新响应流程

系列文章：

分享到