implementing-vulnerability-remediation-sla

实施漏洞修复 SLA

概述

漏洞修复 SLA 定义了根据严重性、资产关键性和利用可用性对已识别漏洞进行修补或缓解的强制时间范围。有效的 SLA 计划可推动问责制，确保一致的修复时间线，并为漏洞管理成熟度提供可衡量的 KPI。

何时使用

• 在环境中部署或配置实施漏洞修复 sla 能力时
• 在建立符合合规要求的安全控制时
• 在为该领域构建或改进安全架构时
• 在进行需要此实施的安全评估时

前提条件

• 生成定期发现的漏洞扫描计划
• 带有关键性分类的资产清单
• 用于修复跟踪的工单系统（Jira、ServiceNow 等）
• 对 SLA 执行的高管支持
• 来自 IT 运营、开发和安全的跨职能协议

核心概念

SLA 框架组件

1. 严重性分类：CVSS 基础分数 + 威胁上下文（EPSS、KEV）
2. 资产分层：业务关键性和暴露级别
3. 修复时间范围：按类别划分的最长修复天数
4. 例外流程：SLA 延期的书面批准
5. 升级程序：SLA 被违反时的行动
6. 指标和报告：用于合规跟踪的 KPI

推荐的 SLA 矩阵

严重性	第 1 层（关键）	第 2 层（重要）	第 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 (Critical Assets):
- Customer-facing production systems
- Payment processing infrastructure
- Domain controllers and identity systems
- Core network infrastructure (firewalls, routers)
- Databases containing PII/PHI/PCI data

Tier 2 (Important Assets):
- Internal production applications
- Email and collaboration systems
- Development/staging environments with production data
- Backup and recovery infrastructure
- VPN and remote access gateways

Tier 3 (Standard Assets):
- End-user workstations
- Development/test environments
- Print servers and peripheral management
- Non-critical internal tools

步骤 2：建立 SLA 政策文档

需要包含的关键部分：

• 目的和范围
• 角色和职责（RACI 矩阵）
• 严重性定义和计算方法
• 按严重性和资产层级划分的修复时间范围
• 例外请求流程和批准权限
• SLA 违反的升级程序
• 指标、报告频率和治理
• 政策审查和更新计划

步骤 3：与工单系统集成

# ServiceNow / Jira integration for automatic ticket creation
# See process.py for full implementation

# Key fields for remediation tickets:
# - Vulnerability ID (CVE/Plugin ID)
# - Affected host(s)
# - Severity (CVSS + contextual factors)
# - Asset tier
# - SLA deadline (calculated from discovery date)
# - Assignment group
# - Remediation instructions
# - Verification criteria

步骤 4：配置升级链

SLA Status          Action                          Notify
───────────────────────────────────────────────────────────
75% elapsed         Warning email                   Asset owner
100% elapsed        SLA breach notification          Manager + CISO
100% + 7 days       Executive escalation             VP/CTO
100% + 30 days      Risk acceptance required          CISO approval
100% + 90 days      Compensating controls mandatory   Board report

步骤 5：建立例外流程

有效的例外原因：

• 系统无法在没有重大停机的情况下修补（计划维护窗口）
• 没有可用的供应商补丁（应用补偿控制）
• 补丁破坏关键功能（需要测试结果作为证据）
• 生命周期结束系统待退役（记录风险接受）

例外要求：

• 带有业务影响的书面理由
• 记录并实施补偿控制
• 由资产所有者 AND 安全领导批准
• 最大例外持续时间：90 天（重新批准可续期）
• 在漏洞管理平台中跟踪

关键绩效指标（KPI）

主要指标

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

趋势指标

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

最佳实践

• 从可实现的 SLA 开始，随着成熟度提高逐步收紧
• 使用工单系统消除手动 SLA
• 为修复团队提供清晰的修复说明，而不是 CVE 编号
• 在团队/部门层面跟踪 SLA 合规情况
• 每月向高层领导汇报 SLA 指标
• 将补偿性控制措施作为临时修复方案纳入
• 使 SLA 与法规要求保持一致（DSL、HIPAA、PCI）
• 每年根据威胁态势变化审查并调整 SLA

常见陷阱

• 设定团队无法满足的不切实际 SLA（导致 SLA 疲劳）
• 没有高层对 SLA 违规的强制执行
• 对所有资产一视同仁，不进行分级
• 在 SLA 计算中未考虑漏洞背景信息（EPSS、KEV）
• 缺少例外处理流程（导致风险未被跟踪）
• 仅衡量合规率，不分析违规的根本原因

相关技能

• prioritizing-vulnerabilities-with-cvss-scoring
• implementing-patch-management-workflow
• implementing-vulnerability-metrics-reporting
• implementing-exception-management-process