概述
严重性级别
| 级别 | 名称 | 描述 | 响应时间 | 示例 |
|---|---|---|---|---|
| P1 | 严重 | 全面的业务中断或数据泄露 | 15 分钟内 | 生产系统宕机、已确认的数据泄露 |
| P2 | 高 | 重大服务降级或安全威胁 | 1 小时内 | 关键服务部分不可用、疑似入侵 |
| P3 | 中 | 有限影响、存在变通方案 | 4 小时内 | 非关键系统故障、单用户账户被盗 |
| P4 | 低 | 最小影响、仅信息通报 | 1 个工作日内 | 可疑但未确认的活动、轻微策略违规 |
步骤 1：识别与报告
- 发现疑似事件的人员应立即报告。
- 通过以下任一方式报告：
- Slack 频道
#incidents - 电子邮件发送至安全团队
- 事件管理系统提交工单
- Slack 频道
- 报告应包括：事件时间、受影响的系统/人员、已知影响范围和严重性初步评估。
- 安全团队或值班人员确认事件并分配严重性级别。
步骤 2：遏制
- 事件负责人评估需要立即遏制的范围。
- 短期遏制措施可能包括：
- 隔离受影响的系统或网段
- 停用受影响的用户账号
- 阻止可疑的 IP 地址或域名
- 暂停受影响的服务
- 记录所有遏制行动及其时间。
- 确保保留证据用于后续分析。
在遏制阶段，业务连续性优先于取证。先止血，再调查。
步骤 3：评估
- 确定事件的根本原因和完整影响范围。
- 评估数据泄露的程度（如适用）。
- 记录受影响的系统、数据和人员清单。
- 根据评估结果更新严重性级别。
- 确定是否需要调用外部资源（安全顾问、法律顾问等）。
步骤 4：通知
| 严重性 | 通知对象 |
|---|---|
| P1 | 高管团队、法务、受影响的客户、监管机构（如需要） |
| P2 | 部门负责人、法务、受影响的团队 |
| P3 | 直接受影响的团队和人员 |
| P4 | 相关团队负责人 |
步骤 5：消除与恢复
- 消除事件的根本原因（修补漏洞、移除恶意软件、修复配置等）。
- 从已知良好的备份或镜像恢复受影响的系统。
- 验证系统完整性和安全状态。
- 逐步恢复服务并监控异常情况。
- 确认所有受影响的系统已恢复正常运行。
步骤 6：事后复盘
- 时间线：从发现到解决的完整事件时间线。
- 根本原因分析：识别导致事件的根本原因。
- 影响评估：量化业务影响（停机时间、数据损失、财务影响等）。
- 响应评估：评估响应的有效性和及时性。
- 改进措施：制定具体的改进行动项，分配负责人和截止日期。
- 经验教训：总结可供团队和组织借鉴的经验。
事后复盘采用”无责文化”——重点是改进流程和系统，而非追究个人责任。
沟通指南
- 内部沟通：使用专用的 Slack 频道
#incidents进行实时沟通。P1 事件应建立专用的作战频道。 - 外部沟通：所有对外沟通必须经过法务和公关团队的审核。
- 状态更新：P1 事件每 30 分钟发布一次状态更新，P2 事件每 2 小时更新一次。
- 事后沟通：事后复盘报告摘要应分享给所有相关利益相关方。