building-vulnerability-aging-and-sla-tracking

构建漏洞老化与 SLA 跟踪

概述

2024 年新发现的漏洞超过 30,000 个（较上一年增长 17%），组织必须跟踪漏洞在多长时间内未被修补，以及修复是否在定义的服务级别协议（SLA）内完成。漏洞老化衡量从发现到修复之间的时间，而 SLA 跟踪则强制执行基于严重程度的截止期限。行业基准表明，标准 SLA 为：严重漏洞 14 天、高危漏洞 30 天、中危漏洞 60 天、低危漏洞 90 天，不过更激进的时间线（针对正在被利用的严重 CVE 为 24-48 小时）正变得越来越常见。本技能涵盖设计 SLA 策略、构建老化仪表板、实施自动化升级以及生成合规指标。

何时使用

• 在环境中部署或配置构建漏洞老化与 SLA 跟踪能力时
• 在建立与合规要求一致的安全控制时
• 在为该领域构建或改进安全架构时
• 在开展需要此实施的安全评估时

前提条件

• 具备历史扫描数据的漏洞管理平台
• 带关键性评级的资产清单
• 用于修复跟踪的 ITSM/工单系统
• 报告平台（Splunk、Elastic、Power BI、Grafana）
• 利益相关方就 SLA 时间线和升级流程达成一致

核心概念

标准漏洞 SLA 框架

严重程度	CVSS 范围	标准 SLA	激进 SLA	CISA KEV SLA
严重	9.0-10.0	14 天	48 小时	BOD 22-01 截止日期
高危	7.0-8.9	30 天	7 天	14 天
中危	4.0-6.9	60 天	30 天	不适用
低危	0.1-3.9	90 天	60 天	不适用
信息性	0.0	尽力而为	尽力而为	不适用

自适应 SLA 修正因子

因素	修正	理由
面向互联网的资产	-50% SLA	暴露风险更高
列入 CISA KEV	覆盖为 48 小时	已确认正在被利用
EPSS > 0.7	-50% SLA	利用概率高
第 1 层（皇冠明珠）资产	-25% SLA	业务影响最大
已部署补偿性控制	+25% SLA	风险已部分缓解
厂商补丁不可用	例外并设定复核日期	暂时无法修复

关键绩效指标（KPI）

KPI	公式	目标
平均修复时间（MTTR）	Avg(remediation_date - discovery_date)	总体 < 30 天
SLA 合规率	(Vulns remediated within SLA / Total vulns) * 100	>= 90%
逾期漏洞数量	Count where age > SLA	呈下降趋势
漏洞老化分布	Count by age bucket (0-14d, 15-30d, 31-60d, 60+d)	大多数位于 0-30d
修复速度	Vulns closed per week	呈上升趋势
例外率	(Exceptions / Total vulns) * 100	< 5%

工作流

步骤 1：定义 SLA 策略文档

Vulnerability Remediation SLA Policy v1.0

1. Scope: All information systems and applications
2. Severity Classification: Based on CVSS v4.0/v3.1 base score
3. SLA Timelines: See Standard SLA Framework table
4. Adaptive Modifiers: Applied based on asset context
5. Exception Process:
   - Must be documented with business justification
   - Requires compensating control description
   - Maximum extension: 90 days (one renewal)
   - CISO approval required for Critical/High exceptions
6. Escalation Path:
   - 50% SLA elapsed: Automated reminder to asset owner
   - 75% SLA elapsed: Escalation to manager
   - 100% SLA elapsed (overdue): CISO notification
   - 120% SLA elapsed: VP/CTO escalation
7. Metrics Reporting: Monthly to security committee

步骤 2：构建老化计算引擎

import pandas as pd
from datetime import datetime, timedelta

class VulnerabilityAgingTracker:
    """Track vulnerability aging and SLA compliance."""

    SLA_DAYS = {
        "Critical": 14,
        "High": 30,
        "Medium": 60,
        "Low": 90,
    }

    def __init__(self, sla_overrides=None):
        if sla_overrides:
            self.SLA_DAYS.update(sla_overrides)

    def calculate_aging(self, vulns_df):
        """Calculate aging metrics for each vulnerability."""
        today = datetime.now()

        vulns_df["discovery_date"] = pd.to_datetime(vulns_df["discovery_date"])
        vulns_df["remediation_date"] = pd.to_datetime(
            vulns_df["remediation_date"], errors="coerce"
        )

        vulns_df["age_days"] = vulns_df.apply(
            lambda row: (row["remediation_date"] - row["discovery_date"]).days
            if pd.notna(row["remediation_date"])
            else (today - row["discovery_date"]).days,
            axis=1
        )

        vulns_df["sla_days"] = vulns_df["severity"].map(self.SLA_DAYS)
        vulns_df["sla_deadline"] = vulns_df["discovery_date"] + \
            pd.to_timedelta(vulns_df["sla_days"], unit="D")

        vulns_df["is_overdue"] = vulns_df.apply(
            lambda row: row["age_days"] > row["sla_days"]
            if pd.isna(row["remediation_date"]) else False,
            axis=1
        )

        vulns_df["sla_compliance"] = vulns_df.apply(
            lambda row: row["age_days"] <= row["sla_days"]
            if pd.notna(row["remediation_date"]) else None,
            axis=1
        )

        vulns_df["days_overdue"] = vulns_df.apply(
            lambda row: max(0, row["age_days"] - row["sla_days"])
            if row["is_overdue"] else 0,
            axis=1
        )

        vulns_df["sla_pct_elapsed"] = (
            vulns_df["age_days"] / vulns_df["sla_days"] * 100
        ).round(1)

        return vulns_df

    def generate_kpis(self, vulns_df):
        """Generate KPI summary from aging data."""
        open_vulns = vulns_df[vulns_df["remediation_date"].isna()]
        closed_vulns = vulns_df[vulns_df["remediation_date"].notna()]

        kpis = {
            "total_vulnerabilities": len(vulns_df),
            "open_vulnerabilities": len(open_vulns),
            "closed_vulnerabilities": len(closed_vulns),
            "overdue_count": open_vulns["is_overdue"].sum(),
            "mttr_days": closed_vulns["age_days"].mean() if len(closed_vulns) > 0 else 0,
            "sla_compliance_rate": (
                closed_vulns["sla_compliance"].mean() * 100
                if len(closed_vulns) > 0 else 0
            ),
        }

        kpis["overdue_by_severity"] = (
            open_vulns[open_vulns["is_overdue"]]
            .groupby("severity")
            .size()
            .to_dict()
        )

        return kpis

    def get_escalation_list(self, vulns_df):
        """Get vulnerabilities requiring escalation."""
        open_vulns = vulns_df[vulns_df["remediation_date"].isna()].copy()

        escalations = []
        for _, vuln in open_vulns.iterrows():
            pct = vuln["sla_pct_elapsed"]
            if pct >= 120:
                level = "VP/CTO Escalation"
            elif pct >= 100:
                level = "CISO Notification"
            elif pct >= 75:
                level = "Manager Escalation"
            elif pct >= 50:
                level = "Owner Reminder"
            else:
                continue

            escalations.append({
                "cve_id": vuln.get("cve_id", ""),
                "severity": vuln["severity"],
                "age_days": vuln["age_days"],
                "sla_days": vuln["sla_days"],
                "days_overdue": vuln["days_overdue"],
                "sla_pct": pct,
                "escalation_level": level,
                "asset": vuln.get("asset", ""),
                "owner": vuln.get("owner", ""),
            })

        return pd.DataFrame(escalations)

步骤 3：仪表板可视化

# Grafana/Kibana query examples for vulnerability aging

# Age distribution histogram (Elasticsearch)
age_distribution_query = {
    "aggs": {
        "age_buckets": {
            "range": {
                "field": "age_days",
                "ranges": [
                    {"key": "0-7 days", "to": 8},
                    {"key": "8-14 days", "from": 8, "to": 15},
                    {"key": "15-30 days", "from": 15, "to": 31},
                    {"key": "31-60 days", "from": 31, "to": 61},
                    {"key": "61-90 days", "from": 61, "to": 91},
                    {"key": "90+ days", "from": 91},
                ]
            }
        }
    }
}

# SLA compliance trend (monthly)
sla_trend_query = {
    "aggs": {
        "monthly": {
            "date_histogram": {"field": "remediation_date", "interval": "month"},
            "aggs": {
                "within_sla": {
                    "filter": {"script": {
                        "source": "doc['age_days'].value <= doc['sla_days'].value"
                    }}
                }
            }
        }
    }
}

最佳实践

1. 从可实现的 SLA 目标开始，并随着流程成熟逐步收紧
2. 根据资产关键性和威胁背景调整 SLA，而不仅仅依据 CVSS 评分
3. 自动化升级通知，以减少人工跟踪开销
4. 逐月跟踪 MTTR 趋势，以展示改进
5. 构建例外工作流，要求记录补偿性控制
6. 每月向高管层报告 SLA 合规情况，以落实责任
7. 将老化指标纳入安全委员会和董事会层面的报告
8. 将 SLA 跟踪与 ITSM 工单集成，实现端到端修复可见性

常见陷阱

• 设定团队无法达到的不切实际的 SLA 目标，导致 SLA 疲劳
• 未根据资产关键性调整 SLA，对所有系统一视同仁
• 缺乏例外流程，迫使团队要么忽视 SLA，要么申请一刀切的豁免
• 仅衡量未修复漏洞数量，而不考虑存在时长和 SLA 合规情况
• 未从发现日期开始计算 SLA 时钟（而是使用报告日期）
• 未随团队成熟度提升重新设定 SLA 基线

相关技能

• implementing-vulnerability-remediation-sla
• building-executive-vulnerability-risk-report
• implementing-security-metrics-and-kpis
• performing-remediation-validation-scanning