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

1. IDENTIFIKATION
   Schwachstellenscanner + CVE-Feeds + Threat Intelligence

2. BEWERTUNG
   CVSS-Score + Asset-Kritikalität + Exploitability

3. PRIORISIERUNG
   SLA-Definition: wer behebt was bis wann?

4. BEHEBUNG
   Patch / Mitigationsmaßnahme / Akzeptanz

5. VERIFIKATION
   Re-Scan nach Behebung: ist Schwachstelle wirklich weg?

6. REPORTING
   Compliance-Nachweise, KPI-Tracking

Schritt 1: Schwachstellen identifizieren

CVE-Feeds überwachen

# NIST NVD API - neue CVEs der letzten 7 Tage abrufen
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?pubStartDate=2026-02-25T00:00:00&pubEndDate=2026-03-04T23:59:59&cvssV3Severity=CRITICAL" \
  | jq '.vulnerabilities[] | {id: .cve.id, score: .cve.metrics.cvssMetricV31[0].cvssData.baseScore, desc: .cve.descriptions[0].value}'

# CISA Known Exploited Vulnerabilities (KEV)
# Diese CVEs werden AKTIV ausgenutzt - höchste Priorität!
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq '.vulnerabilities | sort_by(.dateAdded) | reverse | .[0:10] | .[] | {id: .cveID, vendor: .vendorProject, product: .product, added: .dateAdded}'

# BSI CERT-Bund Warnmeldungen
# https://www.bsi.bund.de/SharedDocs/Warnmeldungen/DE/CB/Warnmeldungen.html

# Vendor-Security-Advisories abonnieren:
# Microsoft: https://msrc.microsoft.com/update-guide/
# Apache: https://httpd.apache.org/security/vulnerabilities_24.html
# VMware: https://www.vmware.com/security/advisories.html
# Cisco: https://tools.cisco.com/security/center/publicationListing.x

Automatisierter Scan mit Nessus

# Nessus REST API - Scan starten
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
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)

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

# Status prüfen
curl -sk "$NESSUS_URL/scans/$SCAN_ID" \
  -H "X-Cookie: token=$TOKEN" | jq .info.status

# Kritische Findings exportieren
curl -sk "$NESSUS_URL/scans/$SCAN_ID?filter.0.filter=severity&filter.0.quality=neq&filter.0.value=0&filter.search_type=and" \
  -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

CVSS (Common Vulnerability Scoring System):
  Bewertet Schwachstelle UNABHÄNGIG vom Kontext.

Beispiel:
  CVE-2024-XXXX: CVSS 9.8 (Critical) - Apache Struts RCE
  Ihr Umfeld: Apache Struts läuft nur im internen Dev-System
              kein Internet-Zugang, nur Entwickler haben Zugriff

  Effektives Risiko: NIEDRIG (hohe CVSS, aber kein Angriffsweg!)

  CVE-2024-YYYY: CVSS 5.3 (Medium) - Auth-Bypass in VPN-Konzentrator
  Ihr Umfeld: VPN-Gateway direkt im Internet, 200 Remote-User täglich

  Effektives Risiko: KRITISCH (niedrige CVSS, aber zentraler Angriffsvektor!)

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

CVSS-Kontextualisierung in der Praxis

Asset-Kritikalitäts-Matrix:

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

Exploitability-Multiplier:
  In CISA KEV: ×2.0 (aktiv ausgenutzt!)
  PoC öffentlich: ×1.5
  Exploit im Metasploit: ×1.3
  Theoretisch: ×1.0

Beispiel-Rechnung:
  CVSS 9.8 × Kritikalität 0.5 (Test-System) × PoC 1.5 = 7.35 → HOCH
  CVSS 5.3 × Kritikalität 1.5 (Internet-GW) × KEV 2.0 = 15.9 → KRITISCH

Schritt 3: SLAs definieren und einhalten

SLA-Definitionen (Empfehlung BSI/ISO 27001):

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

HOCH (Effektives Risiko 10-14):
  SLA: 7 Tage
  Eskalation: 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

Ausnahmen (Accepted Risk):
  Wenn SLA nicht eingehalten werden kann:
  → Kompensationsmaßnahme + Dokumentation
  → Management-Genehmigung
  → Nachverfolgung bis 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

# Python: KEV-Liste vs. Nessus-Findings abgleichen
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)
with open('nessus-findings.json') as f:
    findings = json.load(f)

# KEV-Überschneidungen finden
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)'
        })

# Sofort eskalieren
print(f"\n🚨 AKTIV AUSGENUTZTE SCHWACHSTELLEN: {len(critical_findings)}")
for f in critical_findings:
    print(f"  {f['host']}: {f['cve']} - {f['plugin']}")

Schritt 6: Reporting und KPIs

Schwachstellenmanagement-KPIs (monatlicher Report):

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

Eskalationspfad:
  Offene kritische Findings > 48h → IT-Leitung
  Offene KEV-Findings       → Sofort Geschäftsführung
  Compliance < 90%          → IT-Leitungsrunde

Häufige Schwachstellenmanagement-Fehler

Fehler 1: CVSS-Score = Priorität (kein Kontext)
  → Verpasste reale Risiken, verschwendete Ressourcen

Fehler 2: Scan ohne Credentials
  → Findet 20-30% der Schwachstellen (unauthenticated = oberflächlich)

Fehler 3: Kein Asset-Inventar
  → Systeme werden nicht gescannt ("Shadow IT")

Fehler 4: Keine Verifikation nach Patch
  → "Wir haben gepatcht" → Re-Scan zeigt: Schwachstelle noch da

Fehler 5: Compliance-Reporting ohne Kontextualisierung
  → "95% gepatcht" aber die 5% sind kritische Internet-Server

Fehler 6: False Positives nicht gemanaged
  → Analysten ignorieren alle Alerts (Alert Fatigue)

Fehler 7: Keine Accepted-Risk-Dokumentation
  → Audit-Frage: "Warum ist CVE-XXXX seit 6 Monaten offen?"
  → Keine Antwort = Befund im ISO-27001-Audit

---

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