Vulnerability Management: Von der Schwachstelle zum geschlossenen Risiko

Vulnerability Management ist der kontinuierliche Prozess des Findens, Priorisierens und Behebens von Schwachstellen - bevor Angreifer sie ausnutzen. Der Unterschied zwischen einem Scan-Report und einem funktionierenden VM-Programm liegt in der Priorisierung und im Tracking.

Der Vulnerability-Management-Lifecycle

Der VM-Lifecycle besteht aus fünf aufeinanderfolgenden Phasen, die kontinuierlich wiederholt werden.

Phase 1: Asset Discovery

Vollständiges Inventar ist die Voraussetzung für alles Weitere: Was ist überhaupt im Netzwerk? Unbekannte Assets sind Blind Spots und damit direkte Angriffsfläche. Die Discovery sollte wöchentlich automatisiert laufen, um neue Geräte zu erfassen.

Netzwerk-Discovery mit Nmap:

nmap -sn 192.168.0.0/16 -oX network-hosts.xml

Externe Sicht auf die eigenen IPs mit Shodan:

shodan search org:"Company GmbH" port:22
shodan search org:"Company GmbH" port:3389  # RDP öffentlich erreichbar?!

Phase 2: Schwachstellen-Scanning

Es gibt zwei grundlegende Scan-Ansätze. Unauthenticated Scans zeigen, was ein externer Angreifer sieht. Authenticated Scans (mit Agent oder Credentials) liefern vollständige Schwachstellenabdeckung. Die empfohlene Frequenz: wöchentlich für kritische Systeme, monatlich für alle anderen.

Phase 3: Priorisierung und Risikobewertung

CVSS allein reicht für eine aussagekräftige Priorisierung nicht aus. Die Kritikalität des betroffenen Assets und die tatsächliche Ausnutzbarkeit in der freien Wildbahn müssen in die Bewertung einfließen (siehe Abschnitt “Beyond CVSS”).

Phase 4: Remediation

Der Patch wird eingespielt oder ein Workaround angewendet. Dabei sind SLAs einzuhalten und der Change-Management-Prozess zu durchlaufen.

Phase 5: Verification

Nach dem Patch folgt ein erneuter Scan zur Bestätigung des Erfolgs. Das Ticket wird mit Nachweis geschlossen. Ausnahmen (Risk Acceptance) werden schriftlich begründet und zeitlich befristet dokumentiert.

CVSS-Scoring verstehen

Das Common Vulnerability Scoring System (CVSS v3.1) klassifiziert Schwachstellen nach Schweregrad.

Score-Bereiche

Score	Schweregrad
0.0	None
0.1 - 3.9	Low
4.0 - 6.9	Medium
7.0 - 8.9	High
9.0 - 10.0	Critical

Base Score - Die wichtigsten Metriken

Attack Vector (AV) beschreibt, wie eine Schwachstelle ausgenutzt werden kann:

• Network (N): über das Netz ausnutzbar - am gefährlichsten
• Adjacent (A): nur im gleichen Netzwerksegment
• Local (L): lokaler Zugriff erforderlich
• Physical (P): physischer Zugriff erforderlich

Attack Complexity (AC):

• Low (L): keine besonderen Bedingungen - gefährlicher
• High (H): spezielle Bedingungen erforderlich

Privileges Required (PR):

• None (N): kein Login nötig - gefährlichste Variante
• Low (L): normaler Benutzer ausreichend
• High (H): Admin-Rechte erforderlich

User Interaction (UI):

• None (N): kein Nutzer muss handeln - gefährlicher
• Required (R): Nutzer muss auf etwas klicken

Scope (S):

• Unchanged (U): Angreifer bleibt in seiner Komponente
• Changed (C): Angreifer verlässt die Komponente (z. B. Host-Escape aus VM)

CIA-Impact bewertet Vertraulichkeit, Integrität und Verfügbarkeit jeweils mit High / Low / None.

Praxisbeispiel: Log4Shell (CVE-2021-44228)

AV:N / AC:L / PR:N / UI:N / S:C / C:H / I:H / A:H = CVSS 10.0 (Critical)

Ausnutzbar über das Netzwerk, ohne Angreifer-Login, mit vollständigem CIA-Impact - der theoretisch schlechtestmögliche Wert.

Temporal Score und Environmental Score

Der Temporal Score berücksichtigt die Exploit-Reife (von “Unproven” bis “High”) und den aktuellen Remediation-Stand (von “Unavailable” bis “Official Fix”).

Der Environmental Score bezieht die Asset-Kritikalität ein. Das ist entscheidend: Ein CVSS 7.0 auf einem Testsystem ist nicht gleichbedeutend mit einem CVSS 7.0 auf dem ERP-System.

Priorisierung: Beyond CVSS

Das Problem mit CVSS allein

In einer typischen Enterprise-Umgebung erscheinen wöchentlich über 100 neue CVEs. Alle High/Critical-Findings sofort zu patchen ist in der Praxis unmöglich. Ein CVSS 9.8 auf einem isolierten Testsystem ist faktisch kein Risiko. Ein CVSS 7.0 auf dem öffentlichen Web-Server hingegen ist ein hohes Risiko.

Risk-Based Vulnerability Management (RBVM)

Faktor 1: EPSS (Exploit Prediction Scoring System)

EPSS gibt die Wahrscheinlichkeit an, dass eine CVE in den nächsten 30 Tagen aktiv ausgenutzt wird (0-100 %, täglich aktualisiert von FIRST.org).

• CVSS 9.8 + EPSS 0,1 % = niedriges echtes Risiko
• CVSS 7.0 + EPSS 85 % = sofort patchen!

Faktor 2: CISA KEV (Known Exploited Vulnerabilities)

Die CISA-Liste enthält CVEs, die aktiv in freier Wildbahn ausgenutzt werden. Unabhängig vom CVSS-Score gilt: KEV = sofort patchen. Für US-Behörden gilt eine 2-Wochen-Pflicht (cisa.gov/known-exploited-vulnerabilities-catalog).

Faktor 3: Asset-Kritikalität

Tier	Beispiele
Kritisch (A)	ERP, Active Directory, Backupsystem, KRITIS
Hoch (B)	Web-Server, E-Mail, Videokonferenz
Mittel (C)	Entwicklungsserver, Test-Systeme
Niedrig (D)	Drucker, einzelne Workstations

Priorisierungs-Matrix und SLAs

Schweregrad	Asset-Tier	SLA
Critical + KEV	Tier A	24 Stunden (Emergency!)
Critical + High EPSS	Tier A	72 Stunden
High + KEV	beliebig	7 Tage
High + moderate EPSS	Tier A oder B	14 Tage
High + Low EPSS	Tier C oder D	30 Tage
Medium (keine KEV, Low EPSS)	beliebig	90 Tage
Low	beliebig	Nächstes Quartal oder Risk Acceptance

Wichtige Erkenntnis: Nur etwa 2-5 % aller CVEs werden jemals aktiv ausgenutzt. EPSS und CISA KEV helfen dabei, genau diese 2-5 % zu identifizieren und Ressourcen gezielt einzusetzen.

Scanning-Tools im Vergleich

Tool	Typ	Stärken	Preis
Tenable Nessus / Tenable.io	On-Prem / Cloud	Marktführer, 150.000+ Plugins, Authenticated Scan	ab ~3.000 EUR/Jahr
Qualys VMDR	Cloud	VM + Detection & Response, gute Ticketing-Integration	auf Anfrage
OpenVAS / Greenbone Community	Open Source	Kostenlos, Docker-basiert	kostenfrei
Rapid7 InsightVM	On-Prem / Cloud	Live Dashboard, Asset-Risiko-Score, Container-Scanning	auf Anfrage
Microsoft Defender VM	Cloud (M365 E5)	Kein eigener Scanner, nutzt Defender-Sensor	in M365 E5 enthalten

Greenbone Community Edition per Docker:

docker run -d -p 9392:9392 greenbone/community-edition

Patch-Management-Prozess

Workflow von der Schwachstelle zum geschlossenen Ticket

1. Scan-Ergebnis fließt in die Vulnerability-Datenbank
2. Automatisches CVSS-Rating + Asset-Mapping
3. Priorisierung nach RBVM-Framework
4. Ticket-Erstellung (Jira/ServiceNow) mit CVE-ID, CVSS, Asset und SLA-Datum sowie zugewiesenem System-Owner
5. Patch-Deployment: immer zuerst in der Testumgebung, dann mit Change-Request in die Produktion, Deployment-Protokoll führen
6. Verification-Scan: erneut scannen, Ticket mit Nachweis schließen
7. Ausnahmen (Risk Acceptance): schriftliche Begründung, kompensatorische Maßnahmen, zeitlich begrenzt - kein dauerhaftes “ignore”

Patch-SLA-Überwachung

• Automatische Eskalation bei SLA-Verletzung
• Monatliches SLA-Compliance-Reporting
• KPI: Anteil Patches innerhalb SLA (Ziel: > 95 %)

Wichtig: Patch ≠ Reboot durchgeführt! Viele Patches werden eingespielt, aber nie aktiviert. Unter Linux prüft needs-restarting, ob ein Neustart aussteht. Unter Windows sind ausstehende Reboots im Update-Status sichtbar.

VM-Programm und Compliance

ISO 27001:2022

Anhang A-8.8 fordert das Management technischer Schwachstellen: ein Schwachstellen-Inventar, SLA-gesteuertes Patching und einen Prozess für Ausnahmen (Risk Acceptance). Der häufigste Non-Conformity-Befund lautet: “Schwachstellen sind bekannt, werden aber nicht systematisch behandelt.”

NIS2 (Art. 21)

Patch-Management wird als technische Maßnahme explizit genannt. Als Nachweis gegenüber Aufsichtsbehörden dienen Scan-Reports und Patch-Protokolle.

Metriken für Auditoren

Metrik	Beschreibung
MTTM	Mean Time to Mitigate - Zeit von Fund bis Behebung
Patch-Rate	Anteil Assets mit aktueller Software
Scan-Coverage	Anteil Assets, die regelmäßig gescannt werden
Open Criticals	Anzahl offener Critical-Findings

VM-Reife-Assessment

Stufe	Beschreibung
1	Ad-hoc-Scans (wann jemand Zeit hat)
2	Regelmäßige Scans, manuelles Tracking
3	Automatisiert + SLAs + Ticket-Integration
4	RBVM + EPSS + Business-Context + KPIs
5	Continuous VM + DevSecOps-Integration + Threat Intelligence