Schwachstellenmanagement in der Praxis: Von der CVE zur Behebung

Schwachstellenmanagement ist mehr als regelmäßiges Patchen. Es ist ein systematischer Prozess: CVEs identifizieren, priorisieren, testen und beheben - und das dokumentiert und wiederholbar. Dieser Guide zeigt, wie mittelständische Unternehmen einen funktionierenden Schwachstellenmanagement-Prozess aufbauen.

Der Schwachstellenmanagement-Zyklus

Ein vollständiger Zyklus umfasst sechs aufeinanderfolgende Phasen:

1. Identifikation - Schwachstellenscanner, CVE-Feeds und Threat Intelligence
2. Bewertung - CVSS-Score kombiniert mit Asset-Kritikalität und Exploitability
3. Priorisierung - SLA-Definition: wer behebt was bis wann?
4. Behebung - Patch, Mitigationsmaßnahme oder dokumentierte Risikoakzeptanz
5. Verifikation - Re-Scan nach Behebung: ist die Schwachstelle wirklich weg?
6. Reporting - Compliance-Nachweise und KPI-Tracking

Schritt 1: Schwachstellen identifizieren

CVE-Feeds überwachen

Für die kontinuierliche Überwachung neuer CVEs stehen mehrere Quellen zur Verfügung. Die NIST NVD API liefert aktuelle Schwachstellen gefiltert nach Schweregrad. Besonders wichtig ist die CISA Known Exploited Vulnerabilities (KEV)-Liste - sie markiert CVEs, die aktiv ausgenutzt werden und daher höchste Priorität haben. Ergänzend sollten die BSI CERT-Bund Warnmeldungen sowie die Vendor Security Advisories der eingesetzten Hersteller (Microsoft MSRC, Fortinet, Cisco, VMware) abonniert werden.

Automatisierter Scan mit Nessus

# Nessus REST API - Scan starten und kritische Findings exportieren
NESSUS_URL="https://localhost:8834"
TOKEN=$(curl -sk -X POST "$NESSUS_URL/session" \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"secret"}' | jq -r .token)

# Neuen Scan erstellen und starten
SCAN_ID=$(curl -sk -X POST "$NESSUS_URL/scans" \
  -H "X-Cookie: token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "uuid": "731a8e52-3ea6-a291-ec0a-d2ff0619c19f4d788d09b24d",
    "settings": {
      "name": "Weekly Internal Scan",
      "text_targets": "192.168.0.0/24",
      "scanner_id": 1
    }
  }' | jq -r .scan.id)

curl -sk -X POST "$NESSUS_URL/scans/$SCAN_ID/launch" \
  -H "X-Cookie: token=$TOKEN"

# Kritische Findings exportieren
curl -sk "$NESSUS_URL/scans/$SCAN_ID?filter.0.filter=severity&filter.0.quality=neq&filter.0.value=0" \
  -H "X-Cookie: token=$TOKEN" \
  | jq '.vulnerabilities[] | select(.severity == 4) | {host: .hostname, plugin: .plugin_name, cvss: .cvss3_base_score}'

Schritt 2: Priorisierung mit CVSS und Kontext

Warum CVSS allein nicht reicht

Der CVSS-Score bewertet eine Schwachstelle unabhängig vom Kontext. Das führt in der Praxis zu irreführenden Prioritäten:

Ein CVE mit CVSS 9.8 (Critical) für Apache Struts RCE klingt alarmierend - läuft Apache Struts aber nur auf einem internen Dev-System ohne Internetanbindung und nur mit Entwicklerzugriff, ist das effektive Risiko gering.

Umgekehrt: Ein CVE mit CVSS 5.3 (Medium) für einen Auth-Bypass in einem VPN-Konzentrator, der direkt im Internet steht und täglich von 200 Remote-Usern genutzt wird, ist faktisch kritisch.

Die Priorisierungsformel lautet: Effektives Risiko = CVSS × Exploitability × Asset-Kritikalität

CVSS-Kontextualisierung in der Praxis

Für die Asset-Kritikalität empfiehlt sich folgende Gewichtung:

Asset-Typ	Kritikalität	Multiplier
Internet-Gateway	Kritisch	×1.5
Produktiv-Server	Hoch	×1.2
Büro-Workstation	Mittel	×1.0
Test-System (intern)	Niedrig	×0.5
Isoliertes System	Minimal	×0.2

Für die Exploitability-Gewichtung:

Exploit-Status	Multiplier
In CISA KEV (aktiv ausgenutzt)	×2.0
PoC öffentlich verfügbar	×1.5
Exploit in Metasploit enthalten	×1.3
Nur theoretisch	×1.0

Beispielrechnung: CVSS 9.8 × Kritikalität 0.5 (Test-System) × PoC 1.5 ergibt 7.35 (Hoch). CVSS 5.3 × Kritikalität 1.5 (Internet-GW) × KEV 2.0 ergibt 15.9 (Kritisch).

Schritt 3: SLAs definieren und einhalten

Die SLA-Empfehlungen orientieren sich an BSI- und ISO-27001-Vorgaben:

KRITISCH (Effektives Risiko > 14): SLA 24 Stunden. Sofortige Eskalation an IT-Leitung. Notfall-Change ohne normales CAB.

HOCH (Effektives Risiko 10–14): SLA 7 Tage. IT-Leiter informiert. Beschleunigtes Change-Management.

MITTEL (Effektives Risiko 5–9): SLA 30 Tage. Regulärer Patch-Zyklus.

NIEDRIG (Effektives Risiko 1–4): SLA 90 Tage. Nächster Wartungszyklus.

Wenn ein SLA nicht eingehalten werden kann, sind drei Dinge zwingend erforderlich: eine dokumentierte Kompensationsmaßnahme, eine Management-Genehmigung sowie eine Nachverfolgung bis zur tatsächlichen Behebung.

Schritt 4: Patch-Compliance messen

# Windows: fehlende Patches pro System (PowerShell)
function Get-PatchCompliance {
    param([string[]]$ComputerNames)

    $results = foreach ($computer in $ComputerNames) {
        try {
            $session = New-Object -ComObject Microsoft.Update.Session
            $searcher = $session.CreateUpdateSearcher()
            $missing = $searcher.Search("IsInstalled=0 and Type='Software' and IsHidden=0")

            $criticalMissing = $missing.Updates | Where-Object {
                $_.MsrcSeverity -eq "Critical"
            }

            [PSCustomObject]@{
                Computer = $computer
                MissingTotal = $missing.Updates.Count
                MissingCritical = $criticalMissing.Count
                OldestPatch = ($missing.Updates | Sort-Object LastDeploymentChangeTime | Select-Object -First 1).Title
            }
        } catch {
            [PSCustomObject]@{Computer = $computer; Error = $_.Exception.Message}
        }
    }
    $results | Sort-Object MissingCritical -Descending
}

# Compliance-Score berechnen
$allSystems = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
$compliance = Get-PatchCompliance -ComputerNames $allSystems

$totalSystems = $compliance.Count
$compliantSystems = ($compliance | Where-Object MissingCritical -eq 0).Count
$complianceRate = [math]::Round(($compliantSystems / $totalSystems) * 100, 1)
Write-Host "Patch Compliance (Kritisch): $complianceRate% ($compliantSystems/$totalSystems)"

Schritt 5: CISA KEV-Integration

Die CISA KEV-Liste enthält CVEs, die nachweislich aktiv ausgenutzt werden. Der Abgleich der eigenen Nessus-Findings mit der KEV-Liste lässt sich mit einem kurzen Python-Skript automatisieren:

import requests
import json

# KEV-Liste laden
kev_response = requests.get(
    "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
)
kev_cves = {v['cveID'] for v in kev_response.json()['vulnerabilities']}

# Nessus-Findings (als JSON exportiert) gegen KEV abgleichen
with open('nessus-findings.json') as f:
    findings = json.load(f)

critical_findings = []
for finding in findings['vulnerabilities']:
    cve_id = finding.get('cve_id', '')
    if cve_id in kev_cves:
        critical_findings.append({
            'host': finding['host'],
            'cve': cve_id,
            'plugin': finding['plugin_name'],
            'priority': 'IMMEDIATE - Actively Exploited (CISA KEV)'
        })

print(f"AKTIV AUSGENUTZTE SCHWACHSTELLEN: {len(critical_findings)}")
for f in critical_findings:
    print(f"  {f['host']}: {f['cve']} - {f['plugin']}")

Jeder Fund in der KEV-Liste erfordert sofortige Eskalation bis zur Geschäftsführungsebene.

Schritt 6: Reporting und KPIs

Für den monatlichen Report empfehlen sich folgende KPIs:

KPI	Ziel
MTTD (Mean Time to Detect)	< 24 Stunden
MTTR Kritisch	< 48 Stunden
MTTR Hoch	< 7 Tage
MTTR Mittel	< 30 Tage
Patch Compliance Kritisch (48h)	> 99 %
Patch Compliance Hoch (7 Tage)	> 95 %
Offene KEV-Findings	= 0
False-Positive-Rate	< 10 %
Scan-Coverage (bekannte Assets)	> 95 %

Eskalationspfad: Offene kritische Findings nach mehr als 48 Stunden gehen an die IT-Leitung. Offene KEV-Findings eskalieren sofort zur Geschäftsführung. Eine Compliance unter 90 % wird in der IT-Leitungsrunde behandelt.

Häufige Schwachstellenmanagement-Fehler

Fehler 1: CVSS-Score = Priorität (kein Kontext) - Führt zu verpassten realen Risiken und verschwendeten Ressourcen.

Fehler 2: Scan ohne Credentials - Unauthentifizierte Scans finden nur 20-30 % der tatsächlichen Schwachstellen.

Fehler 3: Kein Asset-Inventar - Systeme werden nicht gescannt und bleiben als "Shadow IT" im toten Winkel.

Fehler 4: Keine Verifikation nach Patch - "Wir haben gepatcht" genügt nicht. Erst der Re-Scan bestätigt, dass die Schwachstelle tatsächlich behoben wurde.

Fehler 5: Compliance-Reporting ohne Kontextualisierung - "95 % gepatcht" klingt gut, bis klar wird, dass die 5 % die kritischen Internet-Server sind.

Fehler 6: False Positives nicht gemanaged - Analysten ignorieren alle Alerts (Alert Fatigue), weil das Signal-Rausch-Verhältnis zu schlecht ist.

Fehler 7: Keine Accepted-Risk-Dokumentation - Im ISO-27001-Audit lautet die Frage: "Warum ist CVE-XXXX seit 6 Monaten offen?" Ohne dokumentierte Risikoakzeptanz gibt es dafür keine valide Antwort.

---

Schwachstellenmanagement überfordert Ihr Team? AWARE7 unterstützt beim Aufbau eines strukturierten Prozesses: von der Tool-Auswahl über SLA-Definition bis zu wiederkehrenden Penetrationstests zur Verifikation.

Schwachstellenmanagement-Beratung anfragen | Penetrationstest beauftragen | Sicherheitsberatung entdecken