Schwachstellenmanagement: Der vollständige Leitfaden

Jedes Unternehmen hat Schwachstellen in seiner IT-Infrastruktur - die Frage ist nicht ob, sondern welche und wie viele. Schwachstellenmanagement ist der systematische Prozess, diese Lücken zu finden, zu bewerten und zu schließen, bevor Angreifer sie ausnutzen können.

Was ist Schwachstellenmanagement?

Schwachstellenmanagement (englisch: Vulnerability Management) ist ein kontinuierlicher Sicherheitsprozess, der Schwachstellen in IT-Systemen, Anwendungen und Netzwerken identifiziert, bewertet, priorisiert und behebt. Es ist kein einmaliges Projekt, sondern ein dauerhafter Betriebsprozess.

Eine Schwachstelle (Vulnerability) ist ein Fehler in Software, Hardware oder Konfigurationen, der von Angreifern ausgenutzt werden kann. Die bekannteste Datenbank ist das CVE-System (Common Vulnerabilities and Exposures) der MITRE Corporation, das Schwachstellen mit einer eindeutigen ID (z.B. CVE-2021-44228 für Log4Shell) catalogisiert.

Abgrenzung: Schwachstellenmanagement vs. Penetrationstest

	Schwachstellenmanagement	Penetrationstest
Frequenz	Kontinuierlich (wöchentlich/monatlich)	Einmalig oder jährlich
Methode	Automatisiertes Scanning	Manuelle Exploitation
Tiefe	Breite Abdeckung	Tiefe Analyse einzelner Angriffspfade
Ziel	Gesamtüberblick über Angriffsfläche	Beweis der Ausnutzbarkeit
Ergebnis	Schwachstellenliste mit CVSS-Scores	Detaillierter Angriffsbericht mit Business Impact

Beide Verfahren ergänzen sich: Das Schwachstellenmanagement schafft die Datenbasis, der Penetrationstest validiert die kritischsten Risiken.

Der Vulnerability Management Lifecycle

Phase 1: Asset-Inventar aufbauen

Sie können nur schützen, was Sie kennen. Ein vollständiges Asset-Inventar umfasst:

Server (On-Premises, Cloud, VMs)
Endgeräte (Workstations, Laptops, Mobile)
Netzwerkgeräte (Router, Switches, Firewalls)
Anwendungen (Web-Apps, APIs, SaaS)
OT/IoT-Geräte in Produktion und Gebäudetechnik

Werkzeuge für die Asset-Erkennung: Nessus, Qualys, Tenable.io, Microsoft Defender for Endpoint, OpenVAS

Phase 2: Schwachstellen-Scanning

Authenticated vs. Unauthenticated Scans:

Unauthenticated: Scanner sieht das System aus Angreifersicht (extern). Schneller, aber weniger gründlich - viele Schwachstellen sind nur von innen sichtbar.
Authenticated: Scanner erhält Zugangsdaten und kann das System von innen analysieren. Deckt bis zu 10× mehr Schwachstellen auf.

Scan-Typen nach Umgebung:

Netzwerk-Scan:    Alle Hosts, offene Ports, Dienst-Versionen, Betriebssystem
Web-App-Scan:     SQL-Injection, XSS, IDOR, CSRF, Auth-Schwächen (OWASP Top 10)
Container-Scan:   Docker Images, Kubernetes-Konfigurationen, Registry-Schwachstellen
Cloud-Scan:       Fehlkonfigurationen in AWS/Azure/GCP (S3-Berechtigungen, IAM, etc.)
Code-Scan (SAST): Statische Analyse von Quellcode auf Sicherheitsmuster

Scan-Frequenz empfehlung:

Kritische Systeme: wöchentlich
Produktive Server: monatlich
Endgeräte: mindestens quartalsweise
Nach großen Änderungen: ad-hoc

Phase 3: Schwachstellen bewerten

Die Herausforderung: Ein typischer Scan produziert tausende von Befunden. Nicht alles ist gleich kritisch. Hier kommen Bewertungssysteme ins Spiel.

CVSS - Common Vulnerability Scoring System

CVSS (aktuell Version 4.0) bewertet Schwachstellen auf einer Skala von 0 bis 10 anhand von:

Bereich	Faktoren
Base Metrics	Angriffs-Vektor, Komplexität, erforderliche Rechte, Nutzerinteraktion, Auswirkung auf CIA
Temporal Metrics	Exploit-Verfügbarkeit, Patch-Status
Environmental Metrics	Schutzbedarf im eigenen Kontext

CVSS-Schweregrade:

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

Wichtig: Ein CVSS-Score allein ist keine Priorisierung. Log4Shell hatte CVSS 10.0 - aber nicht alle Systeme nutzen Log4j.

EPSS - Exploit Prediction Scoring System

EPSS (entwickelt von FIRST) ergänzt CVSS mit einer Wahrscheinlichkeit in %, dass eine Schwachstelle innerhalb der nächsten 30 Tage aktiv in freier Wildbahn ausgenutzt wird. Datengrundlage: echte Exploit-Beobachtungen aus weltweitem Threat Intelligence.

Beispiel: CVE-2022-30190 (Follina, Microsoft MSDT)
CVSS Base Score:  7.8 (High)
EPSS Score:       95.7% Wahrscheinlichkeit der Ausnutzung

→ Sofortige Priorisierung trotz "nur" High-Rating

CISA KEV - Known Exploited Vulnerabilities

Die US-Behörde CISA führt eine bindende Katalogliste von Schwachstellen, die aktiv ausgenutzt werden. Für US-Bundesbehörden verpflichtend, für alle anderen Organisationen ein exzellentes Priorisierungssignal. Aktuell über 1.100 Einträge.

Priorisierungs-Matrix:

                          EPSS hoch          EPSS niedrig
                     ┌─────────────────┬──────────────────┐
CVSS Critical/High   │   SOFORT patchen │  Zeitnah patchen │
                     │   (24-72h)       │  (7-14 Tage)     │
                     ├─────────────────┼──────────────────┤
CVSS Medium/Low      │   Bald patchen   │  Normaler Zyklus │
                     │   (30 Tage)      │  (90+ Tage)      │
                     └─────────────────┴──────────────────┘

Phase 4: Priorisierung und Risikobewertung

Über reine Scores hinaus müssen Sie den geschäftlichen Kontext einbeziehen:

Ist das System nach außen erreichbar? (Erhöht Priorität massiv)
Welche Daten verarbeitet das System? (DSGVO-Relevanz, Schutzbedarf)
Gibt es Kompensationsmaßnahmen? (WAF, Network Segmentation, EDR)
Ist ein Exploit öffentlich verfügbar? (Metasploit-Modul, PoC-Code auf GitHub)
Ist das System in einer Prod/Dev/Test-Umgebung?

Ein Vulnerability Risk Rating kombiniert diese Faktoren zu einer praktischen Ampelskala (Rot/Orange/Gelb/Grün) für das Reporting an das Management.

Phase 5: Behebung und Remediation

Remediation-Typen:

Typ	Beschreibung	Wann sinnvoll
Patch	Offizieller Hersteller-Patch einspielen	Immer wenn verfügbar
Upgrade	Auf neuere Version migrieren	Bei End-of-Life-Software
Workaround	Mitigationsmaßnahme ohne Patch	Wenn Patch (noch) nicht verfügbar
Compensating Control	Zusätzliche Absicherung (z.B. WAF-Regel)	Wenn Patch sofortige Verfügbarkeit unmöglich
Accept	Risiko akzeptieren (dokumentiert)	Bei sehr niedrigem Risiko oder Aufwand >> Nutzen

SLA-Definitionen empfehlen:

Critical:  Patch innerhalb 24 Stunden
High:      Patch innerhalb 7 Tage
Medium:    Patch innerhalb 30 Tage
Low:       Patch innerhalb 90 Tage

Phase 6: Verifizierung

Nach dem Patchen muss die Behebung verifiziert werden:

Re-Scan des betroffenen Systems
Confirmation, dass der CVE nicht mehr detektiert wird
Dokumentation im Ticketsystem (JIRA, ServiceNow)

Phase 7: Reporting und Kennzahlen

Wichtige KPIs für das Schwachstellenmanagement:

KPI	Beschreibung	Zielwert
MTTD (Mean Time to Detect)	Ø Zeit bis zur Entdeckung	< 7 Tage
MTTR (Mean Time to Remediate)	Ø Zeit bis zur Behebung	SLA-abhängig
Offene Critical Vulns	Anzahl unbehandelter kritischer Schwachstellen	0
Patch Compliance Rate	% Systeme mit aktuellem Patch-Stand	> 95%
Vulnerability Debt	Trend der offenen Schwachstellen über Zeit	Sinkend

Schwachstellenmanagement und Compliance

NIS2-Anforderungen

Art. 21 NIS2 fordert explizit Maßnahmen zur Behandlung von Schwachstellen als Teil des Sicherheitskonzepts. Dazu gehören:

Regelmäßige Risikoanalysen und Sicherheitsprüfungen
Patch- und Änderungsmanagement-Prozesse
Vulnerability Disclosure Policies

BSI IT-Grundschutz OPS.1.1.3

Der BSI-Baustein OPS.1.1.3 Patch- und Änderungsmanagement definiert:

Anforderung an Softwareinventarisierung
Prozess zur Schwachstellenbewertung
Testumgebungen für Patches vor Produktiv-Einsatz
Notfall-Patch-Prozeduren für kritische Schwachstellen

ISO 27001 Annex A

A.12.6.1 Management technischer Schwachstellen verlangt:

Zeitnahe Identifikation von Schwachstellen
Bewertung der Gefährdung
Angemessene Maßnahmen zur Behandlung

Tooling-Landschaft

Kommerzielle Scanner

Tenable Nessus / Tenable.io - Marktführer, umfangreiche Plugin-Datenbank
Qualys VMDR - Cloud-native, gute Asset-Management-Integration
Rapid7 InsightVM - Starke Remediation-Workflows
Microsoft Defender Vulnerability Management - Gut integriert in Windows-Umgebungen

Open Source

OpenVAS / Greenbone - Kostenlose Alternative für kleinere Umgebungen
Trivy - Container und IaC Scanning
OWASP ZAP - Web Application Scanning

DevSecOps-Integration (Shift Left)

Developer-Pipeline:
  Code schreiben → SAST (z.B. SonarQube, Semgrep)
  Commit → Secret-Scan (Gitleaks, TruffleHog)
  Build → SCA (Dependency-Check, Snyk, Dependabot)
  Deploy → DAST (OWASP ZAP, Burp Suite Scan)
  Betrieb → VM-Scanner (Nessus, Qualys)

Häufige Fehler im Schwachstellenmanagement

Scanning ohne Authentifizierung - Es werden nur ~20% der Schwachstellen gefunden
Keine Asset-Vollständigkeit - Shadow IT und vergessene Systeme bleiben ungeschützt
Priorisierung nur nach CVSS - Ohne Exploit-Daten (EPSS) viele Fehlpriorisierungen
Patchen ohne Testen - Patches können Produktionssysteme destabilisieren
Keine Verifizierung - Patches werden eingespielt, aber nicht geprüft
Reporting an falsche Zielgruppe - IT braucht Tickets, Management braucht Risikotrends
Isolation der Ergebnisse - Schwachstellen werden nicht mit Incident-Response verknüpft

Fazit

Schwachstellenmanagement ist das Fundament jedes ernsthaften Sicherheitsprogramms. Es kombiniert technisches Scanning mit strategischer Priorisierung und klaren Prozessen - von der Entdeckung bis zur Verifizierung der Behebung. Ohne diesen kontinuierlichen Prozess bleibt jede andere Sicherheitsinvestition wirkungslos, weil die Eintrittspunkte für Angreifer offen bleiben.