Schwachstellenmanagement aufbauen: Scanner, Priorisierung und Patch-Workflow

Warum Schwachstellenmanagement mehr ist als ein Scanner

Jede Woche veröffentlicht die NIST National Vulnerability Database (NVD) Hunderte neuer CVEs (Common Vulnerabilities and Exposures). Allein im Jahr 2025 wurden über 30.000 Schwachstellen registriert. Für ein mittelständisches Unternehmen mit einigen hundert Systemen bedeutet das: Die Wahrscheinlichkeit, dass irgendwo in der Infrastruktur eine bekannte Schwachstelle existiert, liegt nicht bei vielleicht, sondern bei garantiert.

Das allein ist noch kein Drama. Schwachstellen sind ein normaler Bestandteil von Software, und nicht jede Schwachstelle stellt ein akutes Risiko dar. Das Drama beginnt, wenn du nicht weißt, welche Schwachstellen du hast, welche davon kritisch sind und ob sie behoben wurden. Genau diese drei Fragen beantwortet ein strukturiertes Schwachstellenmanagement.

Abgrenzung: Schwachstellenmanagement vs. Patch-Management

Die beiden Begriffe werden häufig synonym verwendet, beschreiben aber unterschiedliche Disziplinen, die eng zusammenarbeiten.

Schwachstellenmanagement ist der übergeordnete Prozess. Er umfasst das Erkennen, Bewerten und Priorisieren von Schwachstellen in der gesamten IT-Infrastruktur. Dazu gehören nicht nur fehlende Patches, sondern auch Fehlkonfigurationen, unsichere Standardeinstellungen, veraltete Protokolle oder architekturelle Schwächen. Schwachstellenmanagement beantwortet die Frage: Wo sind wir verwundbar und wie groß ist das Risiko?

Patch-Management ist eine spezifische Maßnahme innerhalb des Schwachstellenmanagements. Es befasst sich mit der technischen Umsetzung von Software-Updates und Sicherheitspatches. Patch-Management beantwortet die Frage: Wie bringen wir die Korrektur auf die betroffenen Systeme?

Der Unterschied wird bei nicht-patchbaren Schwachstellen besonders deutlich. Wenn ein Hersteller keinen Patch bereitstellt, wenn ein System End-of-Life erreicht hat oder wenn ein Patch aus Kompatibilitätsgründen nicht installiert werden kann, endet das Patch-Management. Das Schwachstellenmanagement geht weiter: Es muss kompensierende Maßnahmen definieren, die das Risiko auf ein akzeptables Niveau senken.

In deinem ISMS sollten beide Prozesse dokumentiert sein, wobei das Schwachstellenmanagement den Rahmen vorgibt und das Patch-Management als operativer Teilprozess eingebettet ist.

Vulnerability-Scanner: Die richtigen Werkzeuge auswählen

Ein Vulnerability-Scanner ist das zentrale Werkzeug im Schwachstellenmanagement. Er durchsucht Systeme automatisiert nach bekannten Schwachstellen, Fehlkonfigurationen und veralteter Software. Die Ergebnisse bilden die Grundlage für alle weiteren Schritte.

Nessus (Tenable)

Nessus ist der Marktführer im Bereich Vulnerability-Scanning und wird von vielen Auditoren als Referenz betrachtet. Die Professional-Variante kostet rund 3.500 Euro pro Jahr und deckt eine unbegrenzte Anzahl von IPs ab. Die Stärken liegen in der breiten Plugin-Datenbank (über 200.000 Checks), der zuverlässigen Erkennung und den detaillierten Berichten. Die Schwächen: Die Lizenzkosten steigen erheblich, sobald du die Tenable.io-Plattform mit Agent-basiertem Scanning und Dashboard nutzen willst.

Für mittelständische Unternehmen mit bis zu 500 Systemen ist Nessus Professional ein solides Werkzeug, das den Job zuverlässig erledigt und bei Audits anerkannt wird.

OpenVAS / Greenbone

OpenVAS ist die Open-Source-Alternative und als Greenbone Community Edition kostenlos verfügbar. Die Scan-Engine nutzt den Greenbone Vulnerability Feed mit über 100.000 Checks. Die Stärke liegt in den fehlenden Lizenzkosten und der Möglichkeit, die Lösung vollständig self-hosted zu betreiben, was für Unternehmen mit hohen Datenschutzanforderungen relevant ist.

Die Schwächen: Die Einrichtung und Pflege erfordert mehr technisches Know-how als bei kommerziellen Lösungen. Die Scan-Geschwindigkeit ist typischerweise geringer als bei Nessus, und die Berichtsfunktionen sind weniger ausgereift. Für Unternehmen mit begrenztem Budget und vorhandenem Linux-Know-how ist OpenVAS dennoch eine ernst zu nehmende Option.

Qualys VMDR

Qualys ist eine Cloud-basierte Plattform, die Vulnerability Management, Detection and Response (VMDR) als Service anbietet. Die Stärke liegt in der Kombination aus Vulnerability-Scanning, Asset-Inventarisierung und automatisierter Priorisierung. Der Qualys-Agent kann auf Endgeräten installiert werden und scannt auch Systeme, die nicht im Netzwerk erreichbar sind, etwa Notebooks im Homeoffice.

Die Kosten bewegen sich je nach Umfang zwischen 5.000 und 30.000 Euro pro Jahr, was Qualys eher für Unternehmen ab 200 Mitarbeitern wirtschaftlich macht. Dafür bekommst du eine Plattform, die Schwachstellenmanagement, Patch-Management und Compliance-Reporting in einem Tool vereint.

Weitere Optionen

Neben den drei Genannten gibt es weitere relevante Scanner. Rapid7 InsightVM bietet ähnliche Funktionen wie Qualys mit einem Fokus auf Risiko-basierter Priorisierung. Microsoft Defender Vulnerability Management ist für Unternehmen mit Microsoft-365-E5-Lizenz interessant, weil es ohne zusätzliche Kosten verfügbar ist und sich nahtlos in die Microsoft-Security-Landschaft integriert. Nuclei ist ein Open-Source-Scanner, der sich besonders für Webanwendungen und API-Schwachstellen eignet.

Welchen Scanner für welches Szenario?

Für ein Unternehmen mit 50 bis 200 Mitarbeitern und begrenztem Security-Budget empfiehlt sich der Einstieg mit OpenVAS oder Nessus Professional. Sobald die Infrastruktur komplexer wird, viele Remote-Mitarbeiter vorhanden sind oder die Integration in ein SIEM gewünscht ist, lohnt sich der Blick auf Qualys oder Rapid7.

Wichtiger als die Wahl des Scanners ist, dass du überhaupt regelmäßig scannst. Ein wöchentlicher Scan mit OpenVAS ist besser als ein jährlicher Scan mit dem teuersten Produkt am Markt.

CVSS, EPSS und Asset-Kritikalität: Richtig priorisieren

Der Scanner liefert typischerweise Hunderte bis Tausende von Findings pro Scan-Durchlauf. Ohne eine durchdachte Priorisierung ertrinkt dein Team in Schwachstellen und weiß nicht, wo es anfangen soll.

CVSS: Der Industriestandard

Das Common Vulnerability Scoring System (CVSS) bewertet jede Schwachstelle auf einer Skala von 0.0 bis 10.0. Die aktuelle Version ist CVSS v4.0. Der Score setzt sich aus mehreren Metriken zusammen: Wie leicht lässt sich die Schwachstelle ausnutzen? Über das Netzwerk oder nur lokal? Braucht der Angreifer Authentifizierung? Welche Auswirkungen hat ein erfolgreicher Angriff auf Vertraulichkeit, Integrität und Verfügbarkeit?

Die gängige Einteilung: 0.0 ist keine Schwachstelle, 0.1 bis 3.9 ist niedrig, 4.0 bis 6.9 ist mittel, 7.0 bis 8.9 ist hoch und 9.0 bis 10.0 ist kritisch.

CVSS ist nützlich als gemeinsame Sprache und als erste Einordnung, hat aber eine fundamentale Schwäche: Der Score beschreibt die theoretische Schwere einer Schwachstelle, nicht die praktische Gefahr. Ein CVSS-9.8 in einem System, das vom Internet isoliert ist und nur Testdaten enthält, ist weniger dringend als ein CVSS-6.5 in einem öffentlich erreichbaren System mit Kundendaten.

EPSS: Wie wahrscheinlich ist ein Exploit?

Das Exploit Prediction Scoring System (EPSS) ergänzt CVSS um eine entscheidende Information: Wie wahrscheinlich ist es, dass diese Schwachstelle in den nächsten 30 Tagen tatsächlich ausgenutzt wird? EPSS nutzt Machine Learning und wertet Daten aus Exploit-Datenbanken, Darknet-Foren und realen Angriffsdaten aus.

Der EPSS-Score liegt zwischen 0 und 1 (0% bis 100% Wahrscheinlichkeit). Erfahrungsgemäß haben nur etwa 5% aller CVEs einen EPSS-Score über 0.1 (10%), und weniger als 2% einen Score über 0.5 (50%). Das bedeutet: Die meisten Schwachstellen werden in der Praxis nie ausgenutzt.

Diese Information ist Gold wert für die Priorisierung. Eine Schwachstelle mit CVSS 7.5 und EPSS 0.95 ist deutlich dringender als eine mit CVSS 9.0 und EPSS 0.01, weil die erste aktiv ausgenutzt wird und die zweite bisher nur theoretisch gefährlich ist.

Asset-Kritikalität: Der Kontext macht den Unterschied

Der dritte Faktor in der Priorisierung ist die Kritikalität des betroffenen Systems. Nicht alle Systeme sind gleich wichtig. Dein ERP-System mit Kundendaten hat eine andere Kritikalität als der Drucker im Flur.

Um Asset-Kritikalität systematisch zu bewerten, brauchst du ein IT-Asset-Inventar, in dem jedes System mit einer Kritikalitätsstufe versehen ist. Eine einfache Abstufung in drei Stufen reicht für den Anfang: Hoch sind geschäftskritische Systeme mit sensiblen Daten oder externem Zugang, Mittel sind interne Systeme mit Geschäftsdaten und Niedrig sind isolierte Systeme ohne sensible Daten.

Die Priorisierungsformel

Aus diesen drei Faktoren lässt sich eine praktikable Priorisierung ableiten. Ein einfacher Ansatz: Bilde das Produkt aus CVSS-Score (normiert auf 0-1), EPSS-Score und Asset-Kritikalitätsfaktor (z.B. 3 für hoch, 2 für mittel, 1 für niedrig). Das Ergebnis ist ein kontextbezogener Risikowert, der deutlich aussagekräftiger ist als der CVSS-Score allein.

Alternativ kannst du eine Entscheidungsmatrix verwenden: Alles mit CVSS 9.0+ und EPSS über 0.1 auf geschäftskritischen Systemen wird sofort behoben (innerhalb von 24-48 Stunden). CVSS 7.0+ mit nachgewiesenem Exploit bekommt eine Frist von einer Woche. CVSS 4.0+ ohne bekannten Exploit wird im nächsten regulären Patch-Zyklus adressiert. Alles unter CVSS 4.0 wird im Quartalszyklus bewertet.

Wie auch immer du priorisierst: Dokumentiere die Methodik in deiner Richtlinie zum Schwachstellenmanagement, damit die Entscheidungen nachvollziehbar und konsistent sind.

Der Workflow: Von der Entdeckung bis zur Verifikation

Ein funktionierendes Schwachstellenmanagement folgt einem klar definierten Workflow mit fünf Schritten. Jeder Schritt hat definierte Eingaben, Ausgaben, Verantwortlichkeiten und Fristen.

Schritt 1: Scannen

Regelmäßige Scans bilden die Grundlage. Die Häufigkeit hängt von der Kritikalität der Systeme ab. Externe Systeme (Webserver, VPN-Gateways, Mail-Server) sollten mindestens wöchentlich gescannt werden. Interne Server und Netzwerkkomponenten mindestens alle zwei Wochen. Endgeräte (Clients) mindestens monatlich. Nach jeder wesentlichen Infrastrukturänderung ist ein anlassbezogener Scan Pflicht.

Neben den automatisierten Scans sollten für kritische Anwendungen jährlich manuelle Penetrationstests durchgeführt werden. Automatisierte Scanner finden bekannte Schwachstellen zuverlässig, aber logische Fehler, Berechtigungsprobleme und komplexe Angriffsketten erkennen sie nicht.

Der Scan-Zeitpunkt sollte so gewählt werden, dass der Produktionsbetrieb möglichst wenig beeinträchtigt wird. Authentifizierte Scans (credentialed scans) liefern deutlich mehr Ergebnisse als unauthentifizierte, weil sie auch installierte Software-Versionen und lokale Konfigurationen prüfen können.

Schritt 2: Bewerten

Die Scan-Ergebnisse werden gesichtet und bereinigt. Dieser Schritt dient dazu, False Positives zu identifizieren und zu markieren, Duplikate zusammenzufassen und den Kontext zu ergänzen, etwa ob das betroffene System von außen erreichbar ist, welche Daten es verarbeitet und ob kompensierende Maßnahmen existieren.

Die Bewertung sollte von jemandem durchgeführt werden, der sowohl die technischen Details versteht als auch den geschäftlichen Kontext kennt. In vielen Unternehmen ist das der ISB in Zusammenarbeit mit dem zuständigen Systemadministrator.

Schritt 3: Priorisieren

Basierend auf der Bewertung wird jeder Schwachstelle eine Priorität und eine Behebungsfrist zugewiesen. Die Kriterien dafür hast du in der Priorisierungsmethodik festgelegt. Das Ergebnis ist eine geordnete Liste: Was muss sofort passieren, was kann bis nächste Woche warten und was kommt in den regulären Patch-Zyklus?

Für die Priorisierung ist es hilfreich, die CISA KEV-Datenbank (Known Exploited Vulnerabilities) zu konsultieren. Wenn eine Schwachstelle dort gelistet ist, wird sie aktiv von Angreifern ausgenutzt und sollte unabhängig vom CVSS-Score mit höchster Priorität behandelt werden.

Schritt 4: Beheben

Die eigentliche Behebung kann verschiedene Formen annehmen. Am häufigsten ist die Installation eines Sicherheitspatches. Daneben gibt es Konfigurationsänderungen, wenn die Schwachstelle durch eine unsichere Einstellung verursacht wird, Workarounds, wenn kein Patch verfügbar ist, etwa das Deaktivieren eines betroffenen Features, und kompensierende Maßnahmen, wenn die Schwachstelle nicht direkt behoben werden kann.

Jede Maßnahme muss dokumentiert werden: Was wurde getan, von wem, wann und auf welchen Systemen. Diese Dokumentation ist nicht nur für den Audit wichtig, sondern auch für die Nachvollziehbarkeit, falls die Maßnahme unerwünschte Nebenwirkungen hat.

Schritt 5: Verifizieren

Nach der Behebung wird ein erneuter Scan durchgeführt, um zu verifizieren, dass die Schwachstelle tatsächlich geschlossen wurde. Dieser Schritt wird in der Praxis häufig vergessen, ist aber entscheidend. Ein Patch, der nicht richtig installiert wurde, eine Konfigurationsänderung, die beim nächsten Neustart überschrieben wird, oder ein Workaround, der nicht alle Angriffsvektoren abdeckt, all das lässt sich nur durch Verifikation erkennen.

Der Verifikationsscan sollte innerhalb von einer Woche nach der Behebung stattfinden. Wenn die Schwachstelle weiterhin erkannt wird, geht der Vorgang zurück in Schritt 4.

Umgang mit nicht-patchbaren Schwachstellen

Nicht jede Schwachstelle lässt sich durch einen Patch beheben. Die häufigsten Gründe: Der Hersteller hat den Support eingestellt (End-of-Life), der Patch ist nicht kompatibel mit einer geschäftskritischen Anwendung, der Hersteller hat noch keinen Patch veröffentlicht (Zero-Day oder verzögerte Bereitstellung), oder die Schwachstelle liegt in der Architektur und lässt sich nicht ohne grundlegenden Umbau beheben.

Für solche Fälle muss die Richtlinie kompensierende Maßnahmen vorsehen. Das Ziel ist, das Risiko auf ein akzeptables Niveau zu senken, auch wenn die Schwachstelle selbst bestehen bleibt.

Typische kompensierende Maßnahmen sind Netzwerksegmentierung, also das betroffene System in ein separates Netzwerksegment isolieren und den Zugriff auf das Minimum beschränken. Dann gibt es Web Application Firewalls (WAF), die bei Webanwendungen spezifische Angriffsversuche auf die Schwachstelle blockieren können. Erhöhtes Monitoring bedeutet, das betroffene System intensiver zu überwachen und Alarme für verdächtige Aktivitäten einzurichten. Zugriffsbeschränkung meint, die Anzahl der Benutzer und Systeme zu reduzieren, die mit dem verwundbaren System kommunizieren dürfen. Und schließlich die Planung eines Systemwechsels: Wenn ein System End-of-Life ist und kritische Schwachstellen hat, muss mittelfristig ein Ersatz geplant werden.

Jede kompensierende Maßnahme muss dokumentiert und regelmäßig auf ihre Wirksamkeit überprüft werden. Im ISMS wird das als akzeptiertes Restrisiko mit Maßnahmenplan behandelt.

Reporting und KPIs: Den Fortschritt messen

Ohne Kennzahlen weißt du nicht, ob dein Schwachstellenmanagement funktioniert. Die folgenden KPIs haben sich in der Praxis bewährt und werden auch von Auditoren regelmäßig abgefragt.

Mean Time to Remediate (MTTR): Die durchschnittliche Zeit von der Entdeckung einer Schwachstelle bis zur Behebung, aufgeschlüsselt nach Kritikalität. Zielwerte: Kritisch unter 48 Stunden, Hoch unter 7 Tage, Mittel unter 30 Tage, Niedrig unter 90 Tage.

Scan-Abdeckung: Anteil der IT-Assets, die regelmäßig gescannt werden. Zielwert: über 95%. Lücken in der Scan-Abdeckung sind ein häufiger Audit-Befund.

Anzahl offener Schwachstellen nach Kritikalität: Zeigt den aktuellen Zustand und den Trend über die Zeit. Steigt die Zahl kritischer offener Schwachstellen, stimmt etwas im Prozess nicht.

Überalterungsquote: Anteil der Schwachstellen, die ihre Behebungsfrist überschritten haben. Diese Kennzahl zeigt, ob die definierten SLAs eingehalten werden.

Wiederkehrrate: Anteil der Schwachstellen, die nach der Behebung erneut auftreten. Eine hohe Wiederkehrrate deutet auf Probleme im Patch-Management oder in der Konfigurationsverwaltung hin.

False-Positive-Rate: Anteil der Findings, die sich als Fehlalarme herausstellen. Eine hohe Rate verschwendet die Zeit des Teams und untergräbt das Vertrauen in den Scanner.

Das Reporting sollte monatlich an die IT-Leitung und quartalsweise an die Geschäftsführung gehen. Für die Geschäftsführung reicht ein Management-Summary mit den wichtigsten KPIs, dem Trend und einer Einschätzung der Risikolage. Die Details braucht nur das operative Team.

Audit-Nachweis: Was Prüfer sehen wollen

Bei einem ISMS-Audit oder einer NIS2-Prüfung wird das Schwachstellenmanagement regelmäßig unter die Lupe genommen. Auditoren schauen dabei auf bestimmte Aspekte, die du vorbereitet haben solltest.

Die Richtlinie selbst: Ein dokumentierter Prozess für das Schwachstellenmanagement mit definierten Rollen, Scan-Frequenzen, Priorisierungskriterien und Behebungsfristen.

Scan-Protokolle: Nachweise, dass regelmäßig gescannt wird. Auditoren prüfen gerne die letzten sechs Monate und schauen, ob die definierten Frequenzen eingehalten wurden.

Schwachstellen-Tracking: Eine nachvollziehbare Dokumentation jeder relevanten Schwachstelle: wann entdeckt, wie bewertet, welche Maßnahme ergriffen, wann behoben, wann verifiziert. Ob du das in einem Ticketsystem, einer Tabelle oder einem spezialisierten Tool machst, ist sekundär, solange die Nachvollziehbarkeit gegeben ist.

Umgang mit kritischen Schwachstellen: Auditoren schauen besonders genau auf Schwachstellen mit hohem CVSS-Score. Wie schnell wurde reagiert? Wurde die Frist eingehalten? Wenn nicht, warum nicht und welche kompensierenden Maßnahmen wurden ergriffen?

Nicht-patchbare Schwachstellen: Für jede Schwachstelle, die bewusst nicht behoben wird, muss eine dokumentierte Risikoakzeptanz mit Begründung und kompensierenden Maßnahmen vorliegen.

KPIs und Trend: Ein monatliches oder quartalsweises Reporting, das zeigt, wie sich die Schwachstellenlage entwickelt. Auditoren wollen sehen, dass du den Überblick hast und Verbesserungen erkennbar sind.

Integration in das ISMS

Schwachstellenmanagement existiert nicht isoliert, sondern ist mit mehreren anderen ISMS-Prozessen verknüpft. Das Asset-Management liefert das Inventar der zu scannenden Systeme und ihre Kritikalitätseinstufung. Das Risikomanagement übernimmt nicht-patchbare Schwachstellen als identifizierte Risiken. Das Incident Management wird aktiv, wenn eine aktiv ausgenutzte Schwachstelle entdeckt wird, bei der eine Kompromittierung nicht ausgeschlossen werden kann. Das Change Management stellt sicher, dass Patches und Konfigurationsänderungen kontrolliert durchgeführt werden. Und die Lieferantenbewertung fragt bei Drittanbietern nach, wie sie mit Schwachstellen in ihren Produkten umgehen.

Diese Verknüpfungen sollten in der Richtlinie beschrieben sein, damit klar ist, an welchen Stellen das Schwachstellenmanagement Informationen liefert und von welchen Prozessen es Informationen empfängt.

Erste Schritte: Pragmatisch starten

Wenn du noch kein formales Schwachstellenmanagement hast, kann der Aufbau überwältigend wirken. Die gute Nachricht: Du musst nicht alles gleichzeitig machen. Ein pragmatischer Einstieg in drei Phasen kann so aussehen.

Phase 1 (Monat 1-2): Installiere einen Scanner (OpenVAS reicht für den Anfang), führe einen ersten Scan der kritischsten Systeme durch und behebe die Findings mit CVSS 9.0+. Dokumentiere, was du tust.

Phase 2 (Monat 3-4): Erweitere den Scan auf die gesamte Infrastruktur, definiere die Priorisierungskriterien und Behebungsfristen, richte einen regelmäßigen Scan-Zeitplan ein und beginne mit dem KPI-Tracking.

Phase 3 (Monat 5-6): Formalisiere die Richtlinie, integriere den Prozess in dein ISMS, etabliere das Reporting an die Geschäftsführung und führe den ersten Verifikationszyklus durch.

Nach sechs Monaten hast du einen funktionierenden Prozess, den du kontinuierlich verbessern kannst. In ISMS Lite lassen sich Schwachstellen-Findings direkt als Risiken erfassen, mit Maßnahmen verknüpfen und bis zur Verifikation nachverfolgen. Das Tool kostet 500 Euro pro Jahr für alle Module, ohne Seat-Lizenzen. Das ist der Kern eines ISMS: nicht perfekt starten, sondern starten und verbessern.

Weiterführende Artikel

• Patch-Management im Mittelstand: Updates planen, testen, ausrollen
• IT-Asset-Management im ISMS: Wissen, was du schützen musst
• Schutzbedarfsfeststellung: Systematisch bewerten, was schützenswert ist
• Netzwerksegmentierung für KMU: Einfach, wirkungsvoll, bezahlbar
• NIS2-Checkliste: Alle Anforderungen auf einen Blick