Lange galt das Einspielen von Sicherheitsupdates als Routine, die irgendwo zwischen Tagesgeschäft und Wartungsfenster stattfindet. Dabei ist die eigentliche Schwierigkeit nicht das Patchen, sondern die Auswahl. Nach Auswertungen von FIRST, der Organisation hinter dem Bewertungsmodell EPSS, wird in einem Zeitraum von 30 Tagen nur ein niedriger einstelliger Prozentsatz der bekannten Schwachstellen tatsächlich ausgenutzt. Wer alle Funde gleich behandelt, verteilt seine Kraft auf viele Lücken, die nie angegriffen werden.

Wir betreiben Plattformen für Kunden mit hohen Sicherheitsanforderungen und erleben dabei jeden Tag, dass nicht die Technik den Unterschied macht, sondern der Prozess dahinter. Seit NIS2 ist dieser Prozess auch eine gesetzliche Pflicht. Welche Anforderungen das Gesetz insgesamt stellt und wer dafür haftet, fassen wir auf unserer Seite zu NIS2 und Cloud-Sicherheit zusammen. Dieser Beitrag zeigt, wie Schwachstellenmanagement in der Praxis funktioniert.

Was ist Vulnerability Management?

Vulnerability Management, auf Deutsch Schwachstellenmanagement, ist der fortlaufende Prozess, Sicherheitslücken in der eigenen IT zu erkennen, nach ihrem Risiko zu bewerten, zu beheben und die Behebung nachzuweisen. Es ist keine einmalige Prüfung, sondern ein Kreislauf, der mit jeder neuen Meldung und jeder Änderung an der Infrastruktur von vorn beginnt. Das Ziel ist nicht, jede Lücke sofort zu schließen, sondern die gefährlichen zuerst.

Dazu gehört mehr als Technik. Schwachstellen entstehen auch durch fehlende Richtlinien, unklare Zuständigkeiten oder Mitarbeitende, die einen manipulierten Anhang öffnen. Ein wirksames Schwachstellenmanagement verbindet deshalb Scans und Updates mit klaren Regeln, Schulungen und einer Kontrolle, ob die Regeln eingehalten werden.

Wo entstehen typische IT-Schwachstellen?

Die meisten Lücken entstehen nicht durch raffinierte Angriffe, sondern durch Versäumnisse im Alltag. In unseren Projekten begegnen uns vor allem diese:

  1. Veraltete Software: Betriebssysteme, Bibliotheken und Plug-ins, die nicht mehr aktualisiert werden, oft weil ihre Entwickler sie längst aufgegeben haben.
  2. Fehlkonfigurationen: offene Ports, zu weit gefasste Berechtigungen oder Testzugänge, die nach dem Projekt niemand entfernt hat.
  3. Schatten-IT: Dienste und Geräte, die Abteilungen an der IT vorbei nutzen und die deshalb in keinem Scan auftauchen.
  4. Standardpasswörter: vor allem bei Netzwerkgeräten und vernetzten Komponenten, die mit ab Werk gesetzten Zugangsdaten in Betrieb gehen.
  5. Der Mensch: Phishing und Social Engineering umgehen jede technische Absicherung, wenn niemand die Täuschung erkennt.

Gemeinsam ist allen fünf, dass sie sich nur finden lassen, wenn bekannt ist, welche Systeme es überhaupt gibt. Am Anfang jedes Schwachstellenmanagements steht deshalb ein vollständiges Inventar.

Warum verlangt NIS2 ein Schwachstellenmanagement?

Weil das Gesetz es ausdrücklich nennt. Das neue BSI-Gesetz verpflichtet besonders wichtige und wichtige Einrichtungen in § 30 BSIG zu Risikomanagementmaßnahmen. Darunter fallen Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von IT-Systemen „einschließlich Management und Offenlegung von Schwachstellen“. Eine weitere Nummer derselben Liste verlangt Verfahren, mit denen sich die Wirksamkeit dieser Maßnahmen bewerten lässt.

Für die Praxis heißt das: Es genügt nicht, Updates einzuspielen. Ein Unternehmen muss zeigen können, wie es Schwachstellen erkennt, nach welchen Kriterien es sie priorisiert und dass die Behebung tatsächlich gewirkt hat. Die Verantwortung dafür liegt bei der Geschäftsleitung. Welche weiteren Gesetze dabei eine Rolle spielen, beschreibt unser Überblick zu den rechtlichen Vorgaben für IT-Sicherheit.

Wie läuft Vulnerability Management ab?

In vier Schritten, die sich ständig wiederholen:

  1. Erkennen: Automatisierte Scans prüfen die Systeme regelmäßig auf bekannte Lücken. Dazu kommen die Meldungen der Hersteller und Warndienste wie der Warn- und Informationsdienst von CERT-Bund beim BSI. Jede bekannte Lücke trägt eine CVE-Kennung, über die sich Meldungen, Scanner-Funde und Patches einander zuordnen lassen.
  2. Bewerten: Nicht jede Lücke ist gleich gefährlich. Der CVSS-Wert beschreibt, wie schwer eine Lücke technisch wiegt. Der EPSS-Wert schätzt, wie wahrscheinlich sie in den nächsten 30 Tagen tatsächlich ausgenutzt wird. Entscheidend ist der eigene Kontext: Eine kritische Lücke in einem System, das aus dem Internet erreichbar ist, hat Vorrang vor derselben Lücke in einem abgeschotteten Testsystem.
  3. Beheben: Das Update wird eingespielt, eine Konfiguration geändert oder, wenn es noch keinen Patch gibt, die Lücke vorübergehend abgeschirmt, etwa durch eine Firewall-Regel. Jede dieser Maßnahmen ist eine Änderung am System und läuft durch den Change-Prozess.
  4. Nachweisen: Ein erneuter Scan bestätigt, dass die Lücke geschlossen ist. Ticket und Änderungsprotokoll dokumentieren, wer wann was getan hat. Genau diese Dokumentation fragt eine Prüfung nach NIS2 ab.

Schritt zwei entscheidet über den Aufwand. Wer nur nach CVSS sortiert, behandelt einen großen Teil der Funde als kritisch und verliert die Übersicht. Erst die Kombination aus Schwere, Ausnutzungswahrscheinlichkeit und eigenem Kontext ergibt eine Reihenfolge, die ein Team auch abarbeiten kann.

Wie schnell muss eine kritische Lücke geschlossen werden?

So schnell, wie es ihr Risiko verlangt: Bei einer Lücke, die bereits aktiv angegriffen wird und ein erreichbares System betrifft, zählen Stunden. Weniger kritische Lücken lassen sich gebündelt im nächsten regulären Wartungsfenster schließen. Wichtig ist, dass die Fristen vorher festgelegt sind und nicht erst im Ernstfall verhandelt werden.

Bei uns laufen auch Sicherheitsupdates durch den regulären Change-Prozess: Jede Änderung bekommt ein Ticket, wird nach dem Vier-Augen-Prinzip geprüft und vom Change Advisory Board freigegeben. Für jede Änderung gibt es einen Rollback-Plan. Wartungsfenster kündigen wir den Kunden vorher an. Wie geplante Arbeiten und Notfälle im Vertrag geregelt werden, beschreibt unser Beitrag zu Wartungsfenstern im SLA.

Was tun, wenn ein Patch nicht sofort möglich ist?

Die Lücke abschirmen und die Entscheidung dokumentieren. Manchmal gibt es noch kein Update, manchmal würde es eine Fachanwendung beschädigen, die erst angepasst werden muss. Dann helfen Übergangsmaßnahmen: den betroffenen Dienst vom Internet trennen, Zugriffe einschränken oder die Überwachung verschärfen, bis der Patch eingespielt werden kann.

Entscheidet sich ein Unternehmen bewusst, eine Lücke vorerst offen zu lassen, ist das eine Risikoentscheidung. Sie gehört begründet und mit Frist in die Dokumentation, damit sie bei der nächsten Prüfung nachvollziehbar ist und nicht in Vergessenheit gerät. Wir raten unseren Kunden trotzdem, auch kleine Lücken zu schließen: Angreifer suchen gezielt nach den Hintertüren, die niemand für wichtig gehalten hat.

Wer ist zuständig, wenn die Systeme bei einem Provider laufen?

Das hängt vom Betriebsmodell ab und muss im Vertrag stehen. Bei reiner Infrastruktur aus der Cloud ist der Kunde für alles verantwortlich, was auf den virtuellen Servern läuft. Bei einem gemanagten Betrieb übernimmt der Provider Betriebssysteme, Datenbanken und Plattformdienste, die Anwendung bleibt meist beim Kunden. Entscheidend ist, dass keine Ebene dazwischen herrenlos bleibt.

NIS2 macht diese Frage dringlicher, weil die Pflicht nicht an der eigenen Infrastruktur endet: Unternehmen müssen auch die Sicherheit ihrer Lieferkette im Blick haben. Ein Provider sollte deshalb beschreiben können, wie er Schwachstellen erkennt, bewertet und schließt, in welchen Fristen er das tut und wie er es nachweist. Was wir dabei übernehmen, zeigt unsere Seite zu Managed Security.

Fazit: Nicht alles sofort, aber das Wichtige zuerst

Vulnerability Management ist kein Werkzeug, sondern ein Kreislauf aus Erkennen, Bewerten, Beheben und Nachweisen. Seine Qualität entscheidet sich bei der Bewertung: Wer Schwere, Ausnutzungswahrscheinlichkeit und eigenen Kontext zusammen betrachtet, schließt die gefährlichen Lücken zuerst und behält trotzdem den Überblick. Seit NIS2 kommt die Nachweispflicht hinzu. Sie gilt auch für das, was ein Provider im Auftrag betreibt. Wie Sie prüfen, wo Ihr Cloud-Setup dabei steht, beschreibt unsere Seite zu NIS2 und Cloud-Sicherheit.