Zentrales Schwachstellenmanagement: Warum es jedes Unternehmen braucht

Stellen Sie sich einmal folgendes Szenario vor

Sie haben 500 Server. Auf 30 davon läuft eine veraltete OpenSSL-Version mit einer bekannten Remote Code Execution-Schwachstelle. Sie wissen es nur nicht. Niemand in Ihrem Team weiß es. Bis ein Angreifer es herausfindet. Und der sucht nicht manuell – der lässt automatisierte Scanner laufen, genau wie Sie es auch tun sollten.

Das ist kein hypothetisches Szenario. Das passiert jeden Tag. Nicht weil IT-Teams inkompetent sind, sondern weil die Menge an Schwachstellen einfach zu groß geworden ist. 2023 wurden über 29.000 neue CVEs veröffentlicht. 2024 waren es noch mehr. Kein Mensch kann das manuell tracken.

Und genau hier kommt Schwachstellenmanagement ins Spiel. Nicht als Buzzword für die nächste Compliance-Präsentation, sondern als konkreter Prozess, der dafür sorgt, dass Sie wissen, wo Ihre Systeme verwundbar sind – und was Sie dagegen tun.

Was ist zentrales Schwachstellenmanagement?

Im Kern ist es ein fortlaufender Prozess. Sie identifizieren Schwachstellen in Ihrer IT-Infrastruktur, bewerten sie nach Risiko, beheben die kritischen zuerst und überprüfen, ob die Fixes greifen. Klingt simpel. Ist es in der Praxis aber nicht.

„Zentral“ bedeutet: Sie machen das nicht pro Team, pro Abteilung oder pro Server einzeln. Sie haben eine zentrale Stelle – ein Tool, ein Team, einen Prozess – die den Überblick über alle Assets und deren Schwachstellen hat. Ohne das verlieren Sie schnell den Überblick, vor allem wenn Ihr Netzwerk wächst.

Schwachstellenmanagement ist kein Projekt mit Anfang und Ende. Es ist ein Kreislauf. Wenn Sie aufhören zu scannen, hören Sie auf zu sehen.

Der Prozess im Detail

1. Asset-Inventar: Sie können nur schützen, was Sie kennen

Bevor Sie irgendetwas scannen, müssen Sie wissen, was Sie überhaupt haben. Das klingt trivial, ist aber einer der häufigsten Schwachpunkte. Viele Unternehmen haben keine vollständige Liste ihrer IT-Assets. Shadow IT, vergessene Testserver, alte VMs die noch laufen – all das sind blinde Flecken.

Ein gutes Asset-Inventar enthält:

Alle Server, Workstations, Netzwerkgeräte
Cloud-Ressourcen (EC2-Instanzen, Container, Kubernetes-Cluster)
Installierte Software und deren Versionen
Verantwortliche Teams oder Personen pro Asset
Kritikalität des Assets (ein Domain Controller ist wichtiger als ein Print-Server)

Ohne Asset-Inventar ist alles, was danach kommt, Stochern im Nebel. Fangen Sie also hier an.

2. Schwachstellen-Scanning

Jetzt wird gescannt. Ein Vulnerability Scanner prüft Ihre Systeme auf bekannte Schwachstellen. Er vergleicht installierte Softwareversionen mit Datenbanken wie der CVE-Datenbank (Common Vulnerabilities and Exposures) und meldet Ihnen, wo Lücken sind.

Die gängigsten Tools:

Nessus – Kommerziell, weit verbreitet, gute Plugin-Bibliothek. Standard in vielen Unternehmen.
OpenVAS (jetzt Greenbone) – Open Source. Guter Einstieg, vor allem wenn das Budget knapp ist. Braucht aber mehr Pflege als kommerzielle Lösungen.
Qualys – Cloud-basiert, skaliert gut, beliebt bei größeren Unternehmen.

Wichtig: Scannen Sie regelmäßig. Nicht einmal im Quartal, sondern mindestens wöchentlich. Neue Schwachstellen tauchen täglich auf. Wenn Sie nur alle drei Monate scannen, haben Sie ein drei Monate großes Fenster, in dem Angreifer Schwachstellen ausnutzen können, die Sie noch gar nicht kennen.

Und denken Sie an authentifizierte Scans. Ein Scan von außen sieht nur, was das Netzwerk sieht. Ein authentifizierter Scan loggt sich auf dem System ein und prüft installierte Pakete, Konfigurationen und lokale Schwachstellen. Der Unterschied in der Erkennungsrate ist enorm.

3. Bewertung und Priorisierung

Hier ist das Problem: Nach einem Scan haben Sie hunderte, manchmal tausende Findings. Nicht alle sind gleich wichtig. Wenn Sie versuchen, alles gleichzeitig zu fixen, fixen Sie am Ende gar nichts.

Der CVSS-Score (Common Vulnerability Scoring System) gibt jeder Schwachstelle einen Wert von 0.0 bis 10.0. Die Skala:

0.0 – 3.9: Low
4.0 – 6.9: Medium
7.0 – 8.9: High
9.0 – 10.0: Critical

Aber – und das ist wichtig – der CVSS-Score allein reicht nicht. Eine Critical-Schwachstelle auf einem isolierten Testsystem ohne Internetanbindung ist weniger dringend als eine High-Schwachstelle auf Ihrem öffentlich erreichbaren Webserver. Kontext ist alles.

Faktoren, die Sie bei der Priorisierung berücksichtigen sollten:

Ist die Schwachstelle aus dem Internet erreichbar?
Gibt es bereits einen öffentlichen Exploit?
Wird die Schwachstelle aktiv ausgenutzt? (Schauen Sie in die CISA KEV-Liste)
Wie kritisch ist das betroffene System für den Geschäftsbetrieb?
Welche Daten liegen auf dem System?

Ein CVSS-Score von 9.8 klingt dramatisch. Aber wenn das betroffene System in einem abgeschotteten Netzwerksegment steht und der Exploit physischen Zugang erfordert, können Sie das weiter hinten in der Queue einreihen. Umgekehrt: Eine Schwachstelle mit CVSS 7.5, für die seit zwei Wochen ein Exploit-Kit im Darknet kursiert und die Ihren extern erreichbaren Mail-Server betrifft – die patchen Sie sofort.

4. Behebung und Patching

Priorisierung gemacht, jetzt wird gefixt. In den meisten Fällen heißt das: Patches einspielen. Aber nicht immer. Manchmal gibt es keinen Patch. Dann brauchen Sie Workarounds:

Konfigurationsänderungen (z.B. unsichere Protokolle deaktivieren)
Netzwerksegmentierung (betroffenes System isolieren)
Firewall-Regeln (Zugriff einschränken)
WAF-Regeln (bei Web-Schwachstellen)
Im Extremfall: System offline nehmen

Beim Patching gilt: Nicht blind drauflos patchen. Testen Sie Patches in einer Staging-Umgebung, bevor sie auf Produktionssysteme kommen. Ein Patch, der eine Schwachstelle behebt, aber Ihre Applikation kaputt macht, hilft niemandem. Definieren Sie Maintenance Windows und kommunizieren Sie sie.

Für den Patch-Prozess sollten Sie klare SLAs haben. Zum Beispiel:

Critical (aktiv ausgenutzt): Innerhalb von 24–48 Stunden
Critical (kein bekannter Exploit): Innerhalb von 7 Tagen
High: Innerhalb von 14 Tagen
Medium: Innerhalb von 30 Tagen
Low: Nächster regulärer Patch-Zyklus

Das sind Richtwerte. Passen Sie sie an Ihr Unternehmen und Ihre Risikobereitschaft an.

5. Verifizierung und Reporting

Patch eingespielt? Gut. Aber woher wissen Sie, dass er wirkt? Scannen Sie erneut. Verifizieren Sie, dass die Schwachstelle tatsächlich geschlossen ist. Das klingt offensichtlich, wird aber oft vergessen. Manchmal schlägt ein Patch fehl, manchmal braucht es einen Reboot, manchmal hat jemand die Konfiguration wieder überschrieben.

Reporting ist der Teil, den viele IT-Teams als lästig empfinden. Aber er ist wichtig – nicht nur für Compliance, sondern auch für Sie selbst. Gute Reports zeigen Ihnen:

Wie viele offene Schwachstellen haben Sie?
Wie schnell werden sie im Schnitt behoben? (Mean Time to Remediate)
Welche Systeme oder Teams haben die meisten offenen Findings?
Wird es besser oder schlechter über die Zeit?

Mit diesen Zahlen können Sie auch gegenüber dem Management argumentieren, wenn Sie mehr Ressourcen brauchen. „Wir haben 340 offene Critical-Schwachstellen und eine durchschnittliche Behebungszeit von 45 Tagen“ ist eine klare Aussage.

Die größten Fehler im Schwachstellenmanagement

Alles scannen, nichts priorisieren

Sie haben den Scanner aufgesetzt, scannen Ihr gesamtes Netzwerk, bekommen 12.000 Findings – und dann passiert nichts. Weil niemand weiß, wo man anfangen soll. Ohne Priorisierung ist ein Scan-Report nur eine sehr lange Liste, die Angst macht.

Kein Asset-Inventar

Wenn Sie nicht wissen, was Sie haben, scannen Sie nicht alles. Und was Sie nicht scannen, sehen Sie nicht. Und was Sie nicht sehen, sieht trotzdem ein Angreifer. Shadow IT ist real und ein ernstes Problem.

Nur automatische Scans, keine manuelle Bewertung

Scanner sind gut, aber nicht perfekt. Sie produzieren False Positives. Sie verpassen Kontext. Ein Scanner weiß nicht, dass der Server mit dem CVSS-9.8-Finding morgen sowieso abgeschaltet wird. Oder dass das Finding ein False Positive ist, weil ein Backport-Patch installiert wurde, den der Scanner nicht erkennt. Manuelle Bewertung durch jemanden, der die Umgebung kennt, ist unverzichtbar.

Patchen ohne Testen

Freitag Nachmittag, Critical-Patch kommt raus, schnell auf alle Produktionssysteme ausgerollt – und Montag früh funktioniert die ERP-Software nicht mehr. Das ist kein Sicherheitsgewinn, das ist ein Verfügbarkeitsproblem. Testen Sie Patches. Immer. Ja, auch wenn es länger dauert.

Tools und Frameworks

CVSS – Common Vulnerability Scoring System

Der Industriestandard zur Bewertung von Schwachstellen. Aktuell in Version 4.0. Der Score setzt sich aus mehreren Metriken zusammen: Angriffskomplexität, benötigte Privilegien, Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. CVSS ist ein guter Startpunkt, aber wie gesagt – nicht das einzige Kriterium für die Priorisierung.

CVE-Datenbank

CVE steht für Common Vulnerabilities and Exposures. Jede bekannte Schwachstelle bekommt eine eindeutige Nummer, z.B. CVE-2024-3094 (die XZ-Utils-Backdoor). Die CVE-Datenbank unter cve.org ist die zentrale Referenz. Ihr Scanner nutzt diese Daten im Hintergrund, aber es lohnt sich, bei kritischen Findings die CVE-Details selbst nachzulesen.

Scanner im Vergleich

Nessus (Tenable): Marktführer im kommerziellen Bereich. Große Plugin-Datenbank, schnelle Updates bei neuen Schwachstellen, gute Reporting-Funktionen. Kostet Geld, aber das Investment lohnt sich für die meisten Unternehmen.

OpenVAS / Greenbone: Die Open-Source-Alternative. Funktioniert, braucht aber mehr manuellen Aufwand bei Setup und Pflege. Gut für den Einstieg oder wenn Sie kein Budget für kommerzielle Tools haben. Die Community Edition ist kostenlos.

Qualys VMDR: Cloud-native Lösung. Stärken bei großen, verteilten Umgebungen. Kombiniert Vulnerability Management mit Asset Discovery und Patch Management in einer Plattform.

NIST Cybersecurity Framework

Das NIST Framework gibt Ihnen eine Struktur für Ihr gesamtes Sicherheitsprogramm. Schwachstellenmanagement fällt dort unter „Identify“ und „Protect“. Es ist kein Tool, sondern ein Rahmenwerk, an dem Sie sich orientieren können. Besonders hilfreich, wenn Sie gerade erst anfangen und nicht wissen, wo Sie ansetzen sollen.

Tipps für den Einstieg

Sie müssen nicht mit einem Enterprise-Tool und einem 10-Personen-Security-Team starten. Auch kleine Unternehmen können und sollten Schwachstellenmanagement betreiben. Hier ein paar konkrete Schritte:

Erstellen Sie ein Asset-Inventar. Auch wenn es am Anfang nur eine Excel-Tabelle ist. Hauptsache, Sie haben eine Liste aller Systeme mit Verantwortlichen.
Installieren Sie OpenVAS. Es ist kostenlos und reicht für den Anfang. Richten Sie einen wöchentlichen Scan ein.
Konzentrieren Sie sich zuerst auf die extern erreichbaren Systeme. Webserver, Mail-Server, VPN-Gateways – das sind die Systeme, die Angreifer als erstes sehen.
Definieren Sie einfache SLAs. Critical innerhalb einer Woche, High innerhalb von zwei Wochen. Mehr brauchen Sie am Anfang nicht.
Automatisieren Sie, was geht. Automatische Scans, automatische Reports, wenn möglich automatisches Patching für unkritische Systeme.
Fangen Sie klein an, aber fangen Sie an. Ein unperfekter Prozess ist besser als keiner. Sie können ihn später verbessern.

Tipp: Wenn Sie nicht wissen, welche Systeme extern erreichbar sind, machen Sie einen Port-Scan von außen auf Ihre öffentlichen IP-Adressen. Tools wie nmap oder Dienste wie Shodan zeigen Ihnen, was das Internet von Ihrer Infrastruktur sieht. Das ist oft überraschend.

Fazit

Schwachstellenmanagement ist keine Raketenwissenschaft. Es ist ein strukturierter Prozess: Wissen, was Sie haben, scannen, bewerten, patchen, verifizieren. Wiederholen. Immer wieder.

Der schwierigste Teil ist nicht die Technik. Die Tools sind da, die Datenbanken sind da, die Frameworks sind da. Der schwierigste Teil ist die Disziplin, den Prozess dauerhaft aufrechtzuerhalten. Scans müssen laufen, Findings müssen bearbeitet werden, Reports müssen gelesen werden. Jede Woche.

Aber die Alternative ist schlimmer. Ohne Schwachstellenmanagement fliegen Sie blind. Sie hoffen, dass nichts passiert. Und Hoffen ist keine Sicherheitsstrategie.

Also: Fangen Sie an. Bauen Sie ein Asset-Inventar auf, setzen Sie einen Scanner auf, definieren Sie einen Prozess. Besser heute unperfekt als morgen gar nicht.