IT-Sicherheit
Vulnerability Management
Vulnerability Management ist der fortlaufende Prozess, Schwachstellen zu erfassen, zu bewerten, risikobasiert zu priorisieren, zu beheben und zu verifizieren.
- Kontinuierlicher Zyklus
- Asset-Inventar als Basis
- Authenticated Scans
- Risikobasiert: CVSS + EPSS + KEV
- Remediation und Verifikation
Vulnerability Management ist kein einmaliger Scan, sondern ein kontinuierlicher Prozess: Schwachstellen werden erfasst, bewertet, priorisiert, behoben und die Behebung wird verifiziert, immer wieder. Der häufigste Fehler ist, es als gelegentliche Scan-Aktion zu verstehen statt als laufenden Zyklus.
Dieser Artikel erklärt den Zyklus und das Asset-Inventar als Voraussetzung, die Scan-Arten, die Bewertungsstandards CVE, CVSS, EPSS und CISA KEV mit ihrer sauberen Abgrenzung, die risikobasierte Priorisierung, die Remediation-Optionen jenseits des Patchens sowie Metriken und regulatorische Bezüge.
1. Ein Zyklus, kein Scan
Vulnerability Management ist ein wiederkehrender Kreislauf: Asset-Inventar/Scope festlegen, scannen, Funde bewerten und priorisieren, beheben, die Behebung verifizieren und berichten, danach beginnt der Zyklus von neuem. Voraussetzung ist ein vollständiges Asset-Inventar: Was nicht inventarisiert ist, wird nicht gescannt und bleibt ein blinder Fleck. Schatten-IT und vergessene Cloud-Workloads sind genau deshalb gefährlich.
2. Scan-Arten
Zwei Achsen unterscheiden die Scans. Erstens die Authentifizierung: Ein unauthenticated Scan prüft von außen wie ein Angreifer und erzeugt mehr Fehlalarme, weil er den tatsächlichen Patch-Stand nicht ablesen kann; ein authenticated (credentialed) Scan meldet sich am System an und liefert deutlich genauere Ergebnisse mit weniger Fehlalarmen. Zweitens die Methode: netzbasiert (gut für unbekannte Geräte) gegenüber agentbasiert (tiefe Sicht, auch für mobile und zeitweise offline Systeme). In der Praxis kombiniert man beides.
3. CVE, CVSS, EPSS, KEV: vier Dinge
Bei der Bewertung werden vier Begriffe oft vermischt, gehören aber klar getrennt:
| Begriff | Was es ist (und was nicht) |
|---|---|
| CVE | eindeutiger Bezeichner einer Schwachstelle (ID) — kein Bewertungswert |
| CVSS | Bewertung der technischen Schwere (0–10, aktuell v4.0/v3.1) — keine Aussage über reale Ausnutzung |
| EPSS | geschätzte Wahrscheinlichkeit der Ausnutzung (0–1, binnen 30 Tagen) — kein Schweregrad |
| CISA KEV | Liste real aktiv ausgenutzter CVEs — kein Score, sondern belegte Ausnutzung |
4. Risikobasiert priorisieren
Der entscheidende Punkt: Der CVSS-Wert allein reicht zur Priorisierung nicht. Er bewertet die technische Schwere im Worst Case, sagt aber nichts darüber, ob eine Schwachstelle real ausgenutzt wird oder wie wichtig das betroffene System ist. Eine risikobasierte Priorisierung kombiniert die Schwere (CVSS) mit der Ausnutzungs-Wahrscheinlichkeit (EPSS), dem Nachweis realer Ausnutzung (CISA KEV) und dem Asset-Kontext (wie exponiert, wie kritisch). So kann ein mittlerer CVSS-Fund mit hohem EPSS auf einem exponierten Server dringender sein als ein kritischer Fund auf einem isolierten Testsystem.
Wer nur nach CVSS priorisiert, arbeitet die längste Liste ab, nicht die gefährlichste. Reales Risiko entsteht aus Schwere mal Ausnutzbarkeit mal Bedeutung des Assets.
5. Beheben heißt nicht nur patchen
Die Remediation-Phase grenzt das Vulnerability Management vom reinen Patch-Management ab: Patchen ist die häufigste, aber nicht die einzige Antwort. Wo kein Patch verfügbar oder einspielbar ist, kommen Mitigation (etwa Firewall-Regel, Segmentierung, Konfigurationsänderung), ein Workaround oder die dokumentierte Risikoakzeptanz in Frage. Wichtig ist, dass jede Schwachstelle eine bewusste, nachvollziehbare Entscheidung erhält, und dass die Behebung anschließend per Retest verifiziert wird.
6. Metriken und Regulatorik
Messbar wird der Prozess über Kennzahlen wie die Mean Time to Remediate (Zeit von Fund bis verifizierter Behebung), die Zahl offener Funde nach Schwere und die Scan-Abdeckung. Regulatorisch ist Schwachstellenmanagement breit verankert: NIS2 und der BSI-Grundschutz fordern es ebenso wie ISO 27001; ergänzend gehört eine maschinenlesbare Kontaktstelle für Schwachstellenmeldungen (security.txt) zur guten Praxis. Für Software-Abhängigkeiten ergänzt ein SBOM (Software Bill of Materials) den klassischen Scan.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Systematische Risikoreduktion statt Ad-hoc | Daueraufwand, kein einmaliges Projekt |
| Transparenz über den realen Sicherheitszustand | Priorisierung erfordert Tool-Unterstützung und Kompetenz |
| Risikobasiert (EPSS/KEV) fokussiert den Aufwand | aggressive Scans können Produktivsysteme belasten |
| Unterstützt Compliance-Anforderungen (NIS2, ISO 27001) | unbekannte Assets bleiben unerfasst (Inventar nötig) |
| Authenticated Scans senken Fehlalarme | unauthenticated Scans erzeugen Fehlalarme (Alarm-Müdigkeit) |
Häufige Fragen zu Vulnerability Management
Nein. Der CVSS-Wert misst die technische Schwere im Worst Case, nicht das tatsächliche Risiko. Eine sinnvolle Priorisierung kombiniert CVSS mit der Ausnutzungs-Wahrscheinlichkeit (EPSS), dem Nachweis realer Ausnutzung (CISA KEV) und dem Kontext des betroffenen Assets (Exposition, Kritikalität). Andernfalls arbeitet man die längste Liste ab statt der gefährlichsten Funde, und übersieht mittelschwere Lücken, die real aktiv ausgenutzt werden.
Ein unauthenticated Scan prüft ein System von außen, ohne Anmeldung, wie ein Angreifer es sähe. Er erkennt erreichbare Dienste, kann aber den tatsächlichen Patch-Stand nicht ablesen und erzeugt deshalb mehr Fehlalarme. Ein authenticated (credentialed) Scan meldet sich mit gültigen Zugangsdaten an und prüft lokal installierte Versionen, Patches und Konfigurationen, das liefert deutlich genauere Ergebnisse mit weniger Fehlalarmen. Für belastbare Resultate sind authenticated Scans vorzuziehen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Vulnerability Management im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.