Schwachstellenmanagement: Ein praktischer Leitfaden für IT-Teams und MSPs

Die meisten Unternehmen verfügen über irgendeine Form des Schwachstellenmanagements. Ein vierteljährlicher Scan, ein Patching-Prozess irgendeiner Art, ein jährlicher Penetrationstest zur Einhaltung der Vorschriften. Was den meisten Unternehmen jedoch fehlt, ist ein Programm, das streng genug ist, um ihre Sicherheitsrisiken tatsächlich zu verringern.

Ein vierteljährlicher Scan mit einem Bericht, auf den niemand reagiert, ist kein Schwachstellenmanagement. Ebenso wenig wie das Installieren von Patches, wenn Probleme auftreten. Und ebenso wenig wie ein einziger jährlicher Penetrationstest, der nur dazu dient, ein Häkchen zu setzen, und dann in einem Ordner verstaubt. Effektives Schwachstellenmanagement ist ein kontinuierlicher, datengestützter Prozess, bei dem Schwachstellen in einer IT-Umgebung aufgedeckt, priorisiert und behoben werden, bevor Angreifer sie ausnutzen können – und zwar so schnell, dass das Zeitfenster für einen Angriff möglichst klein bleibt.

Laut dem „Kaseya State of the MSP Report 2026“ nennen 53 % der MSPs Cybersicherheitsprobleme als eines ihrer größten geschäftlichen Anliegen. Nicht behobene Sicherheitslücken sind der häufigste Grund dafür, dass diese Bedenken zu Vorfällen eskalieren. Laden Sie den vollständigen Bericht herunter.

Finden und beheben Sie Sicherheitslücken, bevor Angreifer dies tun.

Kaseya VSA 10 sucht kontinuierlich auf allen verwalteten Endgeräten nach fehlenden Patches und Software-Schwachstellen und speist die Ergebnisse direkt in automatisierte Behebungsworkflows ein.

Entdecken Sie Kaseya VSA 10

Was ist Schwachstellenmanagement?

Das Schwachstellenmanagement ist ein fortlaufender Prozess zur Identifizierung, Bewertung, Behebung und Meldung von Sicherheitslücken in der gesamten IT-Umgebung eines Unternehmens. Es umfasst Software-Schwachstellen (fehlende Patches, nicht gepatchte CVEs), Konfigurationsschwächen (Standard-Anmeldedaten, unnötig offene Ports, unsichere Dienstkonfigurationen) sowie Lücken in der Bestandsübersicht (Geräte in der Umgebung, die nicht überwacht oder verwaltet werden).

Der Prozess ist kontinuierlich, da sich die Schwachstellenlandschaft ständig verändert. Täglich werden neue CVEs veröffentlicht. Die Systemressourcen ändern sich. Software wird installiert, aktualisiert und deinstalliert. Die Umgebung am Ende dieses Monats unterscheidet sich erheblich von der Umgebung zu Beginn des Monats, und ein Schwachstellenmanagementprogramm muss dieser Realität Rechnung tragen, anstatt eine Momentaufnahme zu liefern, die bereits veraltet ist, bevor der Bericht verteilt wird.

Das ist der Unterschied zwischen einem Schwachstellenmanagementprogramm und einer Schwachstellenanalyse. Eine Analyse ermittelt, welche Schwachstellen zu einem bestimmten Zeitpunkt vorhanden sind. Ein Programm hingegen identifiziert, priorisiert, behebt und überprüft Schwachstellen kontinuierlich in einer sich ständig verändernden Umgebung.

Der Lebenszyklus des Schwachstellenmanagements

Jedes Programm zum Schwachstellenmanagement folgt – unabhängig von den eingesetzten Tools oder dem Umfang – demselben Betriebszyklus.

Die Erfassung und Bestandsaufnahme bilden die Grundlage. Was man nicht kennt, kann man nicht schützen. Nur eine lückenlose Erfassung aller Ressourcen – einschließlich nicht offiziell registrierter Geräte, Schatten-IT, Cloud-Instanzen und IoT-Geräte – macht einen Scan sinnvoll. Eine kontinuierliche statt einer periodischen Erfassung ist effektiver, da zwischen den Scan-Zyklen neue Ressourcen und neue Schwachstellen auftreten und ein Scan eines unvollständigen Bestands ein unvollständiges Bild liefert.

Beim Scannen und der Bewertung werden Systeme anhand von Datenbanken bekannter Sicherheitslücken (CVEs) und Konfigurationsstandards überprüft. Die Unterscheidung zwischen authentifiziertem und nicht authentifiziertem Scannen ist von entscheidender Bedeutung. Beim nicht authentifizierten Scannen vom Netzwerkrand aus wird das erfasst, was auch ein externer Angreifer sehen würde. Das authentifizierte Scannen, bei dem sich der Scanner in die Systeme einloggt, um deren internen Zustand zu bewerten, liefert deutlich umfassendere Ergebnisse. Die meisten seriösen Programme zum Schwachstellenmanagement setzen beide Verfahren ein.

Die Priorisierung bestimmt die Reihenfolge der Behebung. Nicht alle Schwachstellen sind gleich dringlich, und die Anzahl der Befunde in einer realen Umgebung ist so groß, dass die Qualität der Priorisierung wichtiger ist als die Gesamtabdeckung des Scans. Die Rahmenwerke, die sich bewährt haben, werden im Folgenden ausführlich behandelt.

Die Behebung ist der Bereich, in dem das Programm seinen Mehrwert entfaltet. Die gängigste Behebungsmaßnahme ist das Installieren von Patches, doch Schwachstellen können auch durch Konfigurationsänderungen, kompensierende Kontrollmaßnahmen oder die Isolierung betroffener Ressourcen behoben werden, wenn eine sofortige Patch-Installation nicht möglich ist. Für die Behebung sollten je nach Risikostufe festgelegte SLA-Fenster gelten und nicht ein einheitlicher Zeitplan, der eine kritische CVE mit einem aktiven Exploit genauso behandelt wie einen Konfigurationsfehler mit geringem Schweregrad.

Die Überprüfung schließt den Kreislauf. Nachdem Abhilfemaßnahmen ergriffen wurden, sollte durch eine erneute Überprüfung bestätigt werden, dass die Schwachstellen wirksam behoben wurden. Patches, die nicht korrekt installiert wurden, Konfigurationen, die sich zurückgesetzt haben, oder Ausgleichskontrollen, die nicht wie erwartet funktioniert haben, führen dazu, dass Unternehmen glauben, sie hätten etwas behoben, was in Wirklichkeit nicht der Fall ist. Erst durch die Überprüfung werden Abhilfemaßnahmen zu einer bestätigten Risikominderung.

Berichte richten sich an verschiedene Zielgruppen. Technische Teams, die den Fortschritt bei der Behebung von Schwachstellen verfolgen, benötigen detaillierte, umsetzbare Daten. Das Management benötigt für Berichte zur Sicherheitslage Trenddaten, die die Gefährdung im Zeitverlauf aufzeigen. Compliance-Verantwortliche benötigen Nachweise für ein kontinuierliches Schwachstellenmanagement. Ein Programm, das nur eine dieser Berichtsarten erstellt, schmälert damit seinen eigenen Nutzen.

Schwachstellenscans vs. Penetrationstests

Diese beiden Vorgehensweisen ergänzen sich gegenseitig und werden häufig verwechselt; die Verwendung der einen als Ersatz für die andere ist ein häufiger Fehler bei der Programmgestaltung.

Das Schwachstellen-Scanning erfolgt automatisiert, umfassend und kontinuierlich. Es identifiziert bekannte Schwachstellen in allen erfassten Systemen, erstellt eine nach Priorität geordnete Liste der Befunde und liefert die Betriebsdaten für die Nachverfolgung der Behebung. Es versucht nicht, die Schwachstellen auszunutzen. Es zeigt Ihnen, wo Schwachstellen bestehen, nicht jedoch, ob diese Schwachstellen von einem erfahrenen Angreifer in Ihrer spezifischen Umgebung tatsächlich ausgenutzt werden können.

Penetrationstests werden manuell oder halbautomatisch durchgeführt, sind eng gefasst und finden in regelmäßigen Abständen statt. Ein erfahrener Tester versucht, Schwachstellen auszunutzen – darunter auch Ketten von Problemen mit geringerem Schweregrad, die für sich genommen überschaubar erscheinen, in Kombination jedoch einen substanziellen Zugriff ermöglichen –, um realistische Angriffspfade aufzuzeigen. Penetrationstests überprüfen, ob Ihre Abwehrmaßnahmen gegen einen erfahrenen Angreifer standhalten, und nicht nur, ob Schwachstellen vorhanden sind.

Beides ist wertvoll und beantwortet unterschiedliche Fragen. Das Schwachstellenscanning ist das kontinuierliche Betriebsprogramm, das den Überblick über die Sicherheitslücken auf dem neuesten Stand hält. Penetrationstests, die in der Regel jährlich oder vor wesentlichen Änderungen an der Architektur durchgeführt werden, geben Aufschluss darüber, ob das Betriebsprogramm tatsächlich funktioniert. Die Verwendung eines Penetrationstests als Ersatz für kontinuierliches Scanning ist ein häufiger Substitutionsfehler, da ein Test aufgrund seines zeitlichen Charakters Schwachstellen übersieht, die nach dem Testdatum entstanden sind – in einer typischen Umgebung sind dies die meisten innerhalb von 90 Tagen.

Priorisierung: Wie entscheidet man, was zuerst behoben wird?

Das Ziel der Priorisierung ist nicht die niedrigste Gesamtzahl an CVE-Einträgen. Vielmehr geht es darum, die Schwachstellen zu reduzieren, die am ehesten ausgenutzt werden, bevor man alle Patches installieren kann, denn in einer realen Umgebung ist es nicht möglich, alle Patches gleichzeitig zu installieren.

Die beiden wichtigsten Variablen sind die Ausnutzbarkeit und die Kritikalität der Ressource. Ein CVSS-Wert ist ein nützlicher Ausgangspunkt, für sich genommen jedoch kein vollständiges Indiz. Eine Schwachstelle mit einem CVSS-Wert von 9, für die es keinen öffentlichen Exploit gibt, ist weniger dringlich als eine Schwachstelle mit einem CVSS-Wert von 7, die im KEV-Katalog (Known Exploited Vulnerabilities) der CISA als aktiv in der Praxis ausgenutzt aufgeführt ist. Der KEV-Katalog ist die maßgeblichste öffentliche Referenz für den Status der aktiven Ausnutzung, und jede darin aufgeführte Schwachstelle sollte unabhängig von ihrem CVSS-Wert als Tier-1-Posten behandelt werden.

Ein praktisches vierstufiges Rahmenkonzept:

Stufe 1, Behebung innerhalb von 24 bis 72 Stunden: Kritische CVSS-Schwachstellen auf mit dem Internet verbundenen oder mit hohen Berechtigungen ausgestatteten Systemen; alle Einträge im CISA-KEV-Katalog; Schwachstellen, bei denen anhand von Bedrohungsinformationen bestätigt wurde, dass sie aktiv ausgenutzt werden.

Stufe 2, Behebung innerhalb von 7 Tagen: Schwachstellen mit hohem CVSS-Wert; Schwachstellen, für die Proof-of-Concept-Exploits veröffentlicht wurden; alle Schwachstellen auf Systemen, die sensible Daten enthalten oder privilegierten Zugriff ermöglichen.

Stufe 3, Behebung innerhalb von 30 Tagen: Sicherheitslücken mittlerer Schweregrad auf Standard-Endpunkten.

Stufe 4, Behandlung im Wartungszyklus: Schwachstellen mit geringem Schweregrad, für die keine Hinweise auf eine aktive Ausnutzung vorliegen.

Sicherheitslücken, die nicht innerhalb der vorgegebenen Fristen behoben werden können (geschäftskritische Kompatibilitätsbeschränkungen bei Anwendungen, Genehmigungsverfahren für Änderungen beim Kunden), sollten formell dokumentiert werden, wobei Ausgleichsmaßnahmen zu ergreifen und Warnmeldungen zur Verjährung einzurichten sind. Ein undokumentiertes „Wir kümmern uns darum“ ist ein Sicherheitsrisiko, das wächst, ohne dass es jemand im Blick behält.

Schwachstellenmanagement für MSPs

MSPs, die Schwachstellenprogramme über mehrere Kundenumgebungen hinweg verwalten, benötigen dieselben Kernfunktionen wie IT-Teams einzelner Unternehmen, wobei drei zusätzliche Anforderungen hinzukommen: Mandantenfähigkeit, kundenbezogene Berichterstellung und eine Priorisierungsschicht, die die dringendsten Probleme in der gesamten kombinierten Infrastruktur aufzeigt.

Gerade bei der Priorisierung auf Kundenebene macht die Skalierbarkeit einen entscheidenden Unterschied. Ein MSP, der 40 Kundenumgebungen betreut und vierteljährlich einen Schwachstellenscan durchführt, kann im gesamten Bestand mehrere hundert CVEs mit hohem Schweregrad aufdecken. Ohne ein Framework, das sofort erkennt, welche Befunde CISA-KEV-Einträge sind und welche Assets die höchste Kritikalität aufweisen, ist der Bericht überwältigend, und das Programm greift standardmäßig auf den Ansatz „das zu patchen, was am einfachsten ist“ zurück. Mit einem solchen Rahmenwerk ist die „First-Day“-Liste überschaubar: eine spezifische Liste kritischer Befunde, die eine Behebung innerhalb von 24 bis 72 Stunden erfordern, sortiert nach Kunden, während alle anderen Befunde in wöchentliche und monatliche Warteschlangen eingeteilt werden.

Die praktische Infrastruktur für das Schwachstellenmanagement im MSP-Maßstab umfasst standardisierte Scan-Richtlinien, die einheitlich in allen Kundenumgebungen angewendet werden und je nach Kunde hinsichtlich Zeitpunkt, Umfang und Anmeldedaten angepasst werden können; kundenspezifische Schwachstellen-Dashboards, die den Kundenbetreuern Einblick in die aktuelle Risikoexposition und die Geschwindigkeit der Behebung geben; kundenorientierte Berichte, die sich für QBR-Gespräche eignen und CVE-Listen in eine im geschäftlichen Kontext verständliche Risikosprache übersetzen; sowie eine an SLAs gekoppelte Nachverfolgung der Behebung, die die Geschwindigkeit der Patching-Maßnahmen aufzeigt und belegt, dass die vereinbarten Zeitpläne eingehalten werden.

VulScan, das über RapidFire Tools zur Kaseya-Familie gehört, bietet speziell für MSPs entwickelte Lösungen zum Scannen von Netzwerkschwachstellen mit automatischer Erkennung und CVE-Identifizierung in Kundennetzwerken. Kaseya VSA 10 und Datto RMM übernehmen die Bereitstellung von Patches und wandeln identifizierte Schwachstellen direkt in Workflows zur Behebung um. IT Glue enthält die Asset-Kontextdaten und die Dokumentation, die eine genaue Priorisierung anhand der Kritikalität der Assets ermöglichen, anstatt sich auf Vermutungen zu stützen.

Erfahren Sie, wie sich das Patch-Management von Kaseya VSA 10 in die Schwachstellenerkennung integrieren lässt.

Häufige Fehlerarten

Programme zum Schwachstellenmanagement scheitern auf vorhersehbare Weise. Wenn man die Muster kennt, lässt sich dies leichter vermeiden.

Scannen ohne Maßnahmen. Schwachstellenberichte, die zwar Ergebnisse liefern, aber nicht in einen Behebungsworkflow einfließen, haben keinen Sicherheitswert. Eine lange Liste von CVEs ohne zugewiesene Verantwortliche und ohne Fristen für die Behebung ist eine Dokumentation des Risikos, nicht dessen Reduzierung.

Priorisierung ausschließlich anhand des CVSS-Werts. Ein CVSS-Wert misst den potenziellen Schweregrad, nicht die Wahrscheinlichkeit einer aktiven Ausnutzung. Eine Schwachstelle mit einem CVSS-Wert von 9, für die es noch keinen öffentlichen Exploit gibt, als dringlicher einzustufen als eine Schwachstelle mit einem CVSS-Wert von 7, die im CISA-KEV-Katalog aufgeführt ist, ist verkehrt. Daten zur Ausnutzbarkeit aus dem KEV-Katalog und aus Threat-Intelligence-Feeds müssen Teil des Modells sein.

Nicht erfasste Ressourcen. Ein Schwachstellenmanagement, das zwar das Unternehmensnetzwerk überprüft, dabei jedoch Cloud-Instanzen, Remote-Geräte oder OT- und IoT-Infrastruktur außer Acht lässt, weist Lücken auf, die Angreifer aufdecken werden, da sie umfassende Scans durchführen. Der Erfassungsumfang muss die tatsächliche Umgebung widerspiegeln und nicht die Umgebung, wie sie vor zwei Jahren dokumentiert wurde.

Keine Zuständigkeit für die Behebung. Sicherheitslücken ohne zugewiesene Verantwortliche werden nicht behoben. Jede identifizierte Sicherheitslücke benötigt einen namentlich benannten Verantwortlichen, eine SLA entsprechend der Risikostufe und einen Mechanismus zur Nachverfolgung. Eine Zuständigkeit ohne Frist ist dasselbe wie gar keine Zuständigkeit.

Keine Überprüfung. Die Bestätigung, dass ein Patch bereitgestellt wurde, ist nicht gleichbedeutend mit der Bestätigung, dass eine Sicherheitslücke behoben wurde. Erst durch einen Überprüfungsscan nach der Behebung wird aus einer Maßnahme eine bestätigte Risikominderung.

Kaseya Intelligence: Von der Erkennung bis zum autonomen Handeln

Herkömmliche Tools zum Schwachstellenmanagement identifizieren Lücken und geben Empfehlungen. Der operative Engpass ist immer derselbe: Ein Techniker muss den Befund prüfen, ihn im Vergleich zu allen anderen Aufgaben in der Warteschlange priorisieren und Maßnahmen ergreifen – und das in einem Tempo, das nicht mit der Geschwindigkeit Schritt halten kann, mit der Schwachstellen entdeckt und ausgenutzt werden.

Kaseya Intelligence stützt sich auf mehr als drei Exabyte aggregierter und anonymisierter Daten sowie über 17 Millionen verwaltete Endpunkte und geht über die bloße Aufdeckung von Schwachstellendaten hinaus, um autonom Abhilfemaßnahmen durchzuführen: Patches installieren, Systeme isolieren und Ergebnisse validieren – ohne dass bei jedem Schritt ein manueller Eingriff erforderlich ist.

Für MSPs, die Schwachstellenprogramme in Dutzenden von Kundenumgebungen verwalten, ist der Übergang von Empfehlungen zu autonomen Maßnahmen entscheidend für die Skalierbarkeit des Programms. Ein Team, das 40 Kunden betreut, kann während einer „Patch Tuesday“-Woche nicht jeden Befund der Stufe 1 innerhalb von 72 Stunden manuell priorisieren und bearbeiten. Mit automatisierten Richtlinien zur Patch-Bereitstellung, die anhand von stufenbasierten Kriterien ausgeführt werden, ohne dass bei jedem Schritt die Genehmigung eines einzelnen Technikers erforderlich ist, wird das 72-Stunden-Fenster vom System eingehalten, anstatt vom Team verpasst zu werden. Erfahren Sie mehr unter Kaseya Intelligence.

Gut umgesetztes Schwachstellenmanagement ist nichts Besonderes. Die Patches werden bereitgestellt. Die Befunde durchlaufen die verschiedenen Ebenen. Die Verifizierungsscans bestätigen die Behebung. Die Quartalsberichte zeigen eine Trendlinie, die sich in die richtige Richtung bewegt. Bei Kunden, deren Umgebungen auf diese Weise verwaltet werden, treten keine Vorfälle auf, die dadurch verursacht werden, dass bekannte, durch Patches behebbare Schwachstellen monatelang ungeschlossen bleiben. Diejenigen, die nicht auf diese Weise verwaltet werden, stellen durch Vorfälle fest, genau welche der oben genannten Fehlermodi in ihrem Programm aufgetreten sind.

Die wichtigsten Erkenntnisse

• Das Schwachstellenmanagement ist ein kontinuierlicher Prozess und nicht nur ein vierteljährlicher Scan oder ein jährlicher Penetrationstest. Die Umgebung verändert sich zu schnell, als dass punktuelle Ansätze mit der Schwachstellenlandschaft Schritt halten könnten.
• Eine Priorisierung, bei der der CVSS-Wert, der Status der aktiven Ausnutzung gemäß CISA KEV und die Kritikalität der betroffenen Ressourcen kombiniert werden, ist deutlich effektiver als die Gleichbehandlung aller Schwachstellen hinsichtlich ihrer Dringlichkeit. Jede Schwachstelle im CISA-KEV-Katalog gilt unabhängig von ihrem CVSS-Wert als Tier-1-Eintrag.
• Scans und Penetrationstests dienen der Beantwortung unterschiedlicher Fragen. Scans gewährleisten eine kontinuierliche Überwachung des Betriebs. Penetrationstests überprüfen, ob die Sicherheitsmaßnahmen und das Abhilfeprogramm tatsächlich gegen einen erfahrenen Angreifer Bestand haben.
• Für MSPs sind Rahmenkonzepte zur Priorisierung nach Kunden, standardisierte Scan-Richtlinien und eine an SLAs gekoppelte Nachverfolgung von Korrekturmaßnahmen entscheidend dafür, dass das Schwachstellenmanagement über eine Umgebung mit mehreren Kunden hinweg skalierbar ist, ohne dass die Mitarbeiterzahl entsprechend erhöht werden muss.