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 von 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 Patchen, wenn etwas kaputtgeht. Und ebenso wenig wie ein einziger jährlicher Penetrationstest, der nur dazu dient, ein Häkchen zu setzen, und dann in einem Ordner verschwindet. 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 Angriffe 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.

Was ist Schwachstellenmanagement?

Das Schwachstellenmanagement ist ein fortlaufender Prozess, bei dem Sicherheitslücken in der gesamten IT-Umgebung eines Unternehmens identifiziert, bewertet, behoben und gemeldet werden. 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 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.

Dies 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. Man kann nichts schützen, von dem man nichts weiß. Nur eine lückenlose Erfassung aller Ressourcen – einschließlich nicht offiziell registrierter Geräte, Schatten-IT, Cloud-Instanzen und IoT-Geräte – macht das Scannen 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 Bewerten 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 wesentlich umfassendere Ergebnisse. Die meisten seriösen Programme zum Schwachstellenmanagement führen beides durch.

Die Priorisierung bestimmt die Reihenfolge der Behebung. Nicht alle Schwachstellen sind gleich dringlich, und die Anzahl der in einer realen Umgebung festgestellten Schwachstellen ist so groß, dass die Qualität der Priorisierung wichtiger ist als die vollständige Abdeckung des Scans. Die bewährten Rahmenkonzepte 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 Patchen, doch Schwachstellen können auch durch Konfigurationsänderungen, kompensierende Kontrollmaßnahmen oder die Isolierung betroffener Ressourcen behoben werden, wenn ein sofortiges Patchen 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 aktivem Exploit genauso behandelt wie einen Konfigurationsfehler mit geringer Schwere.

Die Überprüfung schließt den Kreis. Nachdem Abhilfemaßnahmen ergriffen wurden, sollte durch eine erneute Überprüfung bestätigt werden, dass die Schwachstellen tatsächlich behoben wurden. Patches, die nicht korrekt installiert wurden, Konfigurationen, die sich zurückgesetzt haben, oder Ausgleichskontrollen, die nicht wie erwartet funktionierten, 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 von Abhilfemaßnahmen 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, schränkt seinen eigenen Nutzen ein.

Schwachstellenscans vs. Penetrationstests

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

Das Schwachstellenscanning erfolgt automatisiert, umfassend und kontinuierlich. Es identifiziert bekannte Schwachstellen in allen erfassten Systemen, erstellt eine nach Priorität geordnete Liste der Ergebnisse und liefert die Betriebsdaten für die Nachverfolgung der Behebung. Es versucht nicht, die Schwachstellen auszunutzen. Es zeigt Ihnen auf, wo Schwachstellen bestehen, nicht aber, 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 beherrschbar erscheinen, in Kombination jedoch einen substanziellen Zugriff ermöglichen, um realistische Angriffspfade aufzuzeigen. Penetrationstests prüfen, ob Ihre Abwehrmaßnahmen gegen einen erfahrenen Angreifer standhalten, und nicht nur, ob Schwachstellen vorhanden sind.

Beide sind wertvoll und geben Aufschluss über unterschiedliche Aspekte. Das Schwachstellenscanning ist ein kontinuierlicher Prozess, der den aktuellen Stand der Sicherheitsrisiken erfasst. Penetrationstests, die in der Regel jährlich oder vor größeren Änderungen an der Systemarchitektur durchgeführt werden, zeigen auf, ob dieser Prozess tatsächlich funktioniert. Penetrationstests als Ersatz für kontinuierliches Scanning einzusetzen, ist ein häufiger Fehler: Da ein Test nur einen bestimmten Zeitpunkt erfasst, werden Schwachstellen übersehen, die nach dem Testdatum entstehen – 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 CVEs. Es geht darum, die Schwachstellen zu reduzieren, die am ehesten ausgenutzt werden, bevor man sie alle beheben kann, denn in einer realen Umgebung ist es nicht möglich, alle Schwachstellen gleichzeitig zu beheben.

Die beiden wichtigsten Faktoren sind die Ausnutzbarkeit und die Kritikalität der betroffene Systeme. Ein CVSS-Wert ist ein nützlicher Ausgangspunkt, für sich genommen jedoch kein vollständiges Indiz. Eine CVSS-9-Schwachstelle, für die es keinen öffentlichen Exploit gibt, ist weniger dringlich als eine CVSS-7-Schwachstelle, die im KEV-Katalog (Known Exploited Vulnerabilities) der CISA als aktiv in der Wildnis 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-Score als Tier-1-Punkt behandelt werden.

Ein praktisches vierstufiges Rahmenkonzept:

Stufe 1, Behebung innerhalb von 24 bis 72 Stunden: Kritische CVSS-Schwachstellen auf mit dem Internet verbundenen oder privilegierten Systemen; jeder Eintrag im CISA-KEV-Katalog; Schwachstellen, deren aktive Ausnutzung anhand von Bedrohungsinformationen bestätigt wurde.

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-Endgeräten.

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 (aufgrund von Kompatibilitätsbeschränkungen bei geschäftskritischen Anwendungen oder Genehmigungsprozessen beim Kunden), sollten formell dokumentiert werden, wobei Ausgleichsmaßnahmen zu ergreifen und Warnmeldungen zur Überwachung der Verweildauer 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 in mehreren Kundenumgebungen verwalten, benötigen dieselben Kernfunktionen wie IT-Teams in Einzelunternehmen, wobei drei zusätzliche Anforderungen hinzukommen: Mandantenfähigkeit, kundenbezogene Berichterstellung und eine Priorisierungsschicht, die die dringendsten Probleme in der gesamten Infrastruktur aufzeigt.

Gerade bei der Priorisierung auf Kundenebene macht die Größe 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 Rahmen ist die Liste für den ersten Tag überschaubar: eine spezifische Auswahl kritischer Befunde, die eine Behebung innerhalb von 24 bis 72 Stunden erfordern, sortiert nach Kunden, während alles andere in wöchentliche und monatliche Warteschlangen eingeteilt wird.

Die praktische Infrastruktur für das Schwachstellenmanagement im MSP-Maßstab umfasst standardisierte Scan-Richtlinien, die einheitlich in allen Kundenumgebungen angewendet werden und eine kundenspezifische Anpassung hinsichtlich Scan-Zeitpunkt, Umfang und Anmeldedaten ermöglichen; kundenspezifische Schwachstellen-Dashboards, die Account-Managern Einblick in die aktuelle Sicherheitslage und die Geschwindigkeit der Behebung bieten; 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 Patch-Installation aufzeigt und belegt, dass vereinbarte Zeitpläne eingehalten werden.

VulScan, das über RapidFire Tools zur Kaseya-Familie gehört, bietet ein speziell für MSPs entwickeltes Tool zum Scannen von Netzwerkschwachstellen mit automatischer Erkennung und CVE-Identifizierung in Kundennetzwerken. Kaseya VSA 10 und Datto RMM übernehmen die Patch-Bereitstellung und wandeln identifizierte Schwachstellen direkt in Behebungsworkflows um. IT Glue den Asset-Kontext und die Dokumentation, wodurch die Priorisierung anhand der Kritikalität der Assets präzise erfolgt und nicht auf Vermutungen beruht.

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

Häufige Fehlerursachen

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 Minderung.

Priorisierung ausschließlich anhand des CVSS-Werts. Ein CVSS-Wert misst das potenzielle Schweregrad, nicht die Wahrscheinlichkeit einer aktiven Ausnutzung. Eine Schwachstelle mit CVSS-Wert 9, für die es keinen öffentlichen Exploit gibt, als dringlicher einzustufen als eine Schwachstelle mit CVSS-Wert 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 in das Modell einfließen.

Nicht erfasste Ressourcen. Ein Schwachstellenmanagement, das zwar das Unternehmensnetzwerk scannt, 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 diese umfassende Scans durchführen. Der Erfassungsbereich 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 gleichbedeutend mit keiner Zuständigkeit.

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

Kaseya Intelligence: Von der Erkennung bis zum autonomen Handeln

Herkömmliche Tools für das 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 mithalten kann, mit der Schwachstellen entdeckt und ausgenutzt werden.

Kaseya Intelligence auf mehr als drei Exabyte aggregierter und anonymisierter Daten sowie über 17 Millionen verwaltete Endgeräte und geht über die bloße Aufdeckung von Schwachstellendaten hinaus, um Korrekturmaßnahmen autonom durchzuführen: Patches installieren, 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. Dank automatisierter Richtlinien zur Patch-Bereitstellung, die nach 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. Entdecken Sie Kaseya Intelligence.

Gut gemachtes Schwachstellenmanagement ist nichts Besonderes. Die Patches werden bereitgestellt. Die Befunde werden durch die verschiedenen Ebenen abgearbeitet. 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 offen 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.