implementing-vulnerability-remediation-sla

# 实施漏洞修复 SLA

## 概述
漏洞修复 SLA（服务级别协议，Service Level Agreement）根据严重程度、资产重要性和漏洞利用可用性，定义修补或缓解已识别漏洞的强制时限。有效的 SLA 计划推动责任落实、确保一致的修复时间线，并为漏洞管理成熟度提供可衡量的 KPI（关键绩效指标）。

## 前置条件
- 定期产出发现结果的漏洞扫描计划
- 包含重要性分类的资产清单
- 用于修复跟踪的工单系统（Jira、ServiceNow 等）
- SLA 执行的高管支持
- IT 运营、开发和安全团队的跨职能协议

## 核心概念

### SLA 框架组件
1. **严重程度分类**：CVSS 基础分数 + 威胁上下文（EPSS、KEV）
2. **资产分层**：业务重要性和暴露程度
3. **修复时间框架**：按类别的最大修复天数
4. **例外流程**：SLA 延期的书面审批
5. **升级程序**：违反 SLA 时的行动
6. **指标和报告**：合规性跟踪的 KPI

### 推荐的 SLA 矩阵
| 严重程度 | Tier 1（关键） | Tier 2（重要） | Tier 3（标准） |
|----------|-------------------|--------------------|--------------------|
| 关键（CVSS 9.0-10.0） | 24-48 小时 | 72 小时 | 7 天 |
| 高（CVSS 7.0-8.9） | 7 天 | 14 天 | 30 天 |
| 中（CVSS 4.0-6.9） | 30 天 | 45 天 | 60 天 |
| 低（CVSS 0.1-3.9） | 90 天 | 90 天 | 90 天 |
| CISA KEV 列表 | 24 小时 | 48 小时 | 7 天 |

### SLA 加速因素（SLA 缩短 50%）
- 公开可用的漏洞利用代码
- 在野外观察到的主动利用（CISA KEV）
- 受影响的互联网可访问资产
- EPSS 分数 > 0.5（50% 利用概率）
- 之前曾通过类似漏洞类型发生过违规

## 实施步骤

### 步骤 1：定义资产分层
```
Tier 1（关键资产）：
- 面向客户的生产系统
- 支付处理基础设施
- 域控制器和身份系统
- 核心网络基础设施（防火墙、路由器）
- 包含 PII/PHI/PCI 数据的数据库

Tier 2（重要资产）：
- 内部生产应用程序
- 电子邮件和协作系统
- 含有生产数据的开发/预发布环境
- 备份和恢复基础设施
- VPN 和远程访问网关

Tier 3（标准资产）：
- 终端用户工作站
- 开发/测试环境
- 打印服务器和外设管理
- 非关键内部工具
```

### 步骤 2：建立 SLA 策略文档
需要包含的关键部分：
- 目的和范围
- 角色和职责（RACI 矩阵）
- 严重程度定义和计算方法
- 按严重程度和资产分层的修复时间框架
- 例外请求流程和批准权限
- SLA 违规的升级程序
- 指标、报告频率和治理
- 策略审查和更新计划

### 步骤 3：与工单系统集成
```python
# ServiceNow/Jira 集成，自动创建工单
# 修复工单的关键字段：
# - 漏洞 ID（CVE/插件 ID）
# - 受影响主机
# - 严重程度（CVSS + 上下文因素）
# - 资产分层
# - SLA 截止日期（从发现日期计算）
# - 负责团队
# - 修复说明
# - 验证标准
```

### 步骤 4：配置升级链
```
SLA 状态            动作                        通知对象
──────────────────────────────────────────────────────────────
75% 已用时         警告邮件                     资产负责人
100% 已用时        SLA 违规通知                 管理者 + CISO
100% + 7 天        高管升级                     VP/CTO
100% + 30 天       需要风险接受                  CISO 批准
100% + 90 天       强制补偿控制                  董事会报告
```

### 步骤 5：建立例外流程
有效的例外原因：
- 系统无法在不造成重大停机的情况下打补丁（安排维护窗口）
- 无供应商补丁可用（应用补偿控制）
- 补丁破坏关键功能（需要测试结果作为证据）
- 生命周期结束的系统待退役（记录风险接受）

例外要求：
- 书面理由及业务影响说明
- 补偿控制已记录并实施
- 由资产负责人和安全领导层批准
- 最长例外期限：90 天（可重新批准续期）
- 在漏洞管理平台中跟踪

## 关键绩效指标（KPI）

### 主要指标
| KPI | 定义 | 目标 |
|-----|-----------|--------|
| SLA 合规率 | 在 SLA 内修复的漏洞百分比 | >90% |
| 平均修复时间（MTTR） | 从发现到修复的平均天数 | 关键：<3 天，高：<10 天 |
| 漏洞积压 | 超过 SLA 的开放漏洞 | <5% 总数 |
| 例外率 | 有活跃例外的发现百分比 | <10% |
| 复发率 | 修复后重新出现的漏洞百分比 | <5% |

### 趋势指标
- 按月 SLA 合规趋势
- 按严重程度的 MTTR 趋势
- 每资产漏洞密度（漏洞数/主机）
- 补丁覆盖率（已扫描且合规的资产百分比）
- 首次响应时间（发现确认）

## 最佳实践
1. 从可实现的 SLA 开始，随着成熟度提高逐步收紧
2. 使用自动化工单消除手动 SLA 跟踪
3. 为修复团队提供清晰的修复说明，而不仅仅是 CVE 编号
4. 在团队/部门级别跟踪 SLA 合规性以落实责任
5. 每月向高管层报告 SLA 指标
6. 将补偿控制纳入有效的临时修复措施
7. 使 SLA 与法规要求对齐（PCI DSS、HIPAA、SOX）
8. 根据威胁态势变化每年审查和调整 SLA

## 常见陷阱
- 设置团队无法满足的不切实际 SLA（造成 SLA 疲劳）
- 高管不执行 SLA 违规处理
- 未按分层差异化处理所有资产
- 未在 SLA 计算中考虑漏洞上下文（EPSS、KEV）
- 缺少例外管理流程（导致未跟踪的风险）
- 仅衡量合规率而不分析违规根本原因

## 相关技能
- prioritizing-vulnerabilities-with-cvss-scoring
- implementing-patch-management-workflow
- implementing-vulnerability-metrics-and-reporting
- implementing-exception-management-process