> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blevinsholdings.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 事件响应标准操作程序

> 发生安全、系统或运营事件时的应对措施。

<div id="overview">
  ## 概述
</div>

本标准操作程序定义了 Blevins Holdings 识别、遏制、解决安全、系统和运营事件并从中恢复的流程。所有员工都有责任报告疑似事件。

<Warning>
  如果您发现正在进行的安全漏洞，请立即联系安全团队——不要等待走正式流程。
</Warning>

<div id="severity-levels">
  ## 严重性级别
</div>

| 级别 | 名称 | 描述           | 响应时间    | 示例               |
| -- | -- | ------------ | ------- | ---------------- |
| P1 | 严重 | 全面的业务中断或数据泄露 | 15 分钟内  | 生产系统宕机、已确认的数据泄露  |
| P2 | 高  | 重大服务降级或安全威胁  | 1 小时内   | 关键服务部分不可用、疑似入侵   |
| P3 | 中  | 有限影响、存在变通方案  | 4 小时内   | 非关键系统故障、单用户账户被盗  |
| P4 | 低  | 最小影响、仅信息通报   | 1 个工作日内 | 可疑但未确认的活动、轻微策略违规 |

<div id="step-1-identify-and-report">
  ## 步骤 1：识别与报告
</div>

1. 发现疑似事件的人员应立即报告。
2. 通过以下任一方式报告：
   * Slack 频道 `#incidents`
   * 电子邮件发送至安全团队
   * 事件管理系统提交工单
3. 报告应包括：事件时间、受影响的系统/人员、已知影响范围和严重性初步评估。
4. 安全团队或值班人员确认事件并分配严重性级别。

<div id="step-2-contain">
  ## 步骤 2：遏制
</div>

1. 事件负责人评估需要立即遏制的范围。
2. 短期遏制措施可能包括：
   * 隔离受影响的系统或网段
   * 停用受影响的用户账号
   * 阻止可疑的 IP 地址或域名
   * 暂停受影响的服务
3. 记录所有遏制行动及其时间。
4. 确保保留证据用于后续分析。

<Info>
  在遏制阶段，业务连续性优先于取证。先止血，再调查。
</Info>

<div id="step-3-assess">
  ## 步骤 3：评估
</div>

1. 确定事件的根本原因和完整影响范围。
2. 评估数据泄露的程度（如适用）。
3. 记录受影响的系统、数据和人员清单。
4. 根据评估结果更新严重性级别。
5. 确定是否需要调用外部资源（安全顾问、法律顾问等）。

<div id="step-4-notify">
  ## 步骤 4：通知
</div>

根据严重性级别通知相应的利益相关方：

| 严重性 | 通知对象                     |
| --- | ------------------------ |
| P1  | 高管团队、法务、受影响的客户、监管机构（如需要） |
| P2  | 部门负责人、法务、受影响的团队          |
| P3  | 直接受影响的团队和人员              |
| P4  | 相关团队负责人                  |

<Warning>
  P1 和 P2 事件必须在确认后 1 小时内通知法务团队。涉及客户数据的事件可能需要根据法律要求通知监管机构。
</Warning>

<div id="step-5-eradicate-and-recover">
  ## 步骤 5：消除与恢复
</div>

1. 消除事件的根本原因（修补漏洞、移除恶意软件、修复配置等）。
2. 从已知良好的备份或镜像恢复受影响的系统。
3. 验证系统完整性和安全状态。
4. 逐步恢复服务并监控异常情况。
5. 确认所有受影响的系统已恢复正常运行。

<div id="step-6-post-incident-review">
  ## 步骤 6：事后复盘
</div>

所有 P1 和 P2 事件必须在事件解决后 5 个工作日内进行事后复盘。P3 事件由事件负责人决定是否进行复盘。

复盘应包括：

1. **时间线**：从发现到解决的完整事件时间线。
2. **根本原因分析**：识别导致事件的根本原因。
3. **影响评估**：量化业务影响（停机时间、数据损失、财务影响等）。
4. **响应评估**：评估响应的有效性和及时性。
5. **改进措施**：制定具体的改进行动项，分配负责人和截止日期。
6. **经验教训**：总结可供团队和组织借鉴的经验。

<Info>
  事后复盘采用"无责文化"——重点是改进流程和系统，而非追究个人责任。
</Info>

<div id="communication-guidelines">
  ## 沟通指南
</div>

* **内部沟通**：使用专用的 Slack 频道 `#incidents` 进行实时沟通。P1 事件应建立专用的作战频道。
* **外部沟通**：所有对外沟通必须经过法务和公关团队的审核。
* **状态更新**：P1 事件每 30 分钟发布一次状态更新，P2 事件每 2 小时更新一次。
* **事后沟通**：事后复盘报告摘要应分享给所有相关利益相关方。

<div id="related-documents">
  ## 相关文档
</div>

* [变更管理标准操作程序](/zh/sops/change-management)
* [供应商管理标准操作程序](/zh/sops/vendor-management)