Die Oberfläche ist lokalisiert; Skill-Beschreibungen und -Dokumente werden per KI automatisch in Ihre Sprache übersetzt. Code, Befehle, Pfade und Fachbegriffe bleiben im Original, maßgeblich ist das Dokument des Autors.
Skills entdecken
Produktivität · SKILL.md

building-vulnerability-aging-and-sla-tracking

building-vulnerability-aging-and-sla-tracking

实施漏洞老化仪表盘和 SLA 跟踪系统,根据基于严重性的时间线衡量修复绩效,并推动问责制落地。

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill-Dokumentation

GitHub

name: building-vulnerability-aging-and-sla-tracking description: 实施漏洞老化仪表盘和 SLA 跟踪系统,根据基于严重性的时间线衡量修复绩效,并推动问责制落地。 domain: cybersecurity subdomain: vulnerability-management tags: [vulnerability-management, sla-tracking, remediation-metrics, aging-report, kpi, compliance, risk-management] version: "1.0" author: mahipal license: Apache-2.0

构建漏洞老化与 SLA 跟踪

概述

2024 年新发现的漏洞超过 30,000 个(比上年增加 17%),组织必须跟踪漏洞未修复的时间以及修复是否在规定的服务级别协议(SLA)内完成。漏洞老化衡量从发现到修复之间的时间,而 SLA 跟踪则强制执行基于严重性的截止时限。行业基准标准 SLA 为:关键漏洞 14 天、高危漏洞 30 天、中危漏洞 60 天、低危漏洞 90 天,但对于被主动利用的关键 CVE,更激进的时间线(24-48 小时)正越来越普遍。本技能涵盖 SLA 策略设计、老化仪表盘构建、自动化升级实施和合规指标生成。

前置条件

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

核心概念

标准漏洞 SLA 框架

严重性CVSS 范围标准 SLA激进 SLACISA KEV SLA
关键9.0-10.014 天48 小时BOD 22-01 截止日期
高7.0-8.930 天7 天14 天
中4.0-6.960 天30 天不适用
低0.1-3.990 天60 天不适用
信息0.0尽力而为尽力而为不适用

自适应 SLA 调节系数

因素调节系数理由
互联网暴露资产-50% SLA更高的暴露风险
列入 CISA KEV覆盖为 48 小时已确认主动利用
EPSS > 0.7-50% SLA高利用概率
一级(核心)资产-25% SLA最大业务影响
补偿控制已到位+25% SLA风险已部分降低
供应商补丁尚不可用例外处理并设置审查日期暂时无法修复

关键绩效指标(KPI)

KPI计算公式目标
平均修复时间(MTTR)平均值(修复日期 - 发现日期)整体 < 30 天
SLA 合规率(在 SLA 内修复的漏洞数 / 总漏洞数)* 100>= 90%
超期漏洞数量计数(年龄 > SLA)条目持续下降趋势
漏洞老化分布按年龄段计数(0-14 天、15-30 天、31-60 天、60+ 天)大多数在 0-30 天
修复速度每周关闭的漏洞数持续上升趋势
例外率(例外数 / 总漏洞数)* 100< 5%

实施步骤

步骤 1:制定 SLA 策略文件

漏洞修复 SLA 策略 v1.0

1. 范围:所有信息系统和应用程序
2. 严重性分类:基于 CVSS v4.0/v3.1 基础评分
3. SLA 时间线:参见标准 SLA 框架表
4. 自适应调节系数:根据资产背景应用
5. 例外流程:
   - 必须记录业务理由
   - 需要补偿控制描述
   - 最长延期:90 天(可续期一次)
   - 关键/高危例外需要 CISO 批准
6. 升级路径:
   - SLA 已过 50%:向资产负责人发送自动提醒
   - SLA 已过 75%:升级至经理
   - SLA 已过 100%(超期):CISO 通知
   - SLA 已过 120%:VP/CTO 升级
7. 指标报告:每月向安全委员会报告

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

import pandas as pd
from datetime import datetime, timedelta

class VulnerabilityAgingTracker:
    """跟踪漏洞老化和 SLA 合规情况。"""

    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):
        """计算每个漏洞的老化指标。"""
        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):
        """从老化数据生成 KPI 摘要。"""
        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):
        """获取需要升级的漏洞列表。"""
        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 升级"
            elif pct >= 100:
                level = "CISO 通知"
            elif pct >= 75:
                level = "经理升级"
            elif pct >= 50:
                level = "负责人提醒"
            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 漏洞老化查询示例

# 老化分布直方图(Elasticsearch)
age_distribution_query = {
    "aggs": {
        "age_buckets": {
            "range": {
                "field": "age_days",
                "ranges": [
                    {"key": "0-7 天", "to": 8},
                    {"key": "8-14 天", "from": 8, "to": 15},
                    {"key": "15-30 天", "from": 15, "to": 31},
                    {"key": "31-60 天", "from": 31, "to": 61},
                    {"key": "61-90 天", "from": 61, "to": 91},
                    {"key": "90+ 天", "from": 91},
                ]
            }
        }
    }
}

# SLA 合规趋势(按月)
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
Gespeicherte Skills