Ihr Schwachstellen-Backlog wächst seit 18 Monaten. So räumen Sie ihn auf

Edouard Jacques

Managing Director, Cyber Culture

Der Scanner läuft seit anderthalb Jahren, und die Zahl der offenen Findings steigt jeden Monat. Im Bericht an die Geschäftsführung ist die Kurve längst ein Dauerthema, im IT-Betrieb schaut niemand mehr in die Liste. Mancherorts wird der Scanner dann pausiert, damit die Zahl nicht weiter wächst. Sicherer wird dadurch nichts. Dieser Artikel zeigt, wie Sie einen solchen Rückstand in einem überschaubaren Projekt zerlegen, die großen Hebel zuerst ziehen und anschließend verhindern, dass er erneut anwächst.

Woraus ein alter Rückstand meistens besteht

Ein Backlog, der über Monate unbeachtet gewachsen ist, ist keine homogene Liste. Wenn wir ihn mit Kunden auseinandernehmen, finden sich in der Regel vier Gruppen.

Die erste ist Datenmüll: Systeme, die es nicht mehr gibt, aber noch im Scanner stehen. Doppelte Einträge, weil derselbe Server einmal über den Agenten und einmal über den Netzwerkscan erfasst wurde. Geräte, die über DHCP ihre IP-Adresse gewechselt haben und deshalb zweimal gezählt werden.

Die zweite Gruppe sind Massenfunde aus wenigen Ursachen. Eine alte Java-Laufzeit, ein nicht aktualisierter PDF-Reader oder veraltete Laufzeitbibliotheken auf vielen Arbeitsplätzen erzeugen schnell Tausende Zeilen. Behoben werden sie mit einer Handvoll Softwareverteilungen.

Die dritte sind Systeme ohne Lösung: Betriebssysteme ohne Herstellersupport, Appliances, für die es kein Update gibt, oder Rechner, die an eine Maschine gekoppelt sind und nicht verändert werden dürfen. Hier hilft kein Patch, hier braucht es eine Entscheidung.

Erst die vierte Gruppe ist echte Einzelarbeit. Sie ist kleiner, als die Gesamtzahl vermuten lässt, und sie lässt sich nur sinnvoll bearbeiten, wenn die anderen drei Gruppen aus dem Weg sind.

Schritt 1: Daten bereinigen, bevor jemand patcht

Exportieren Sie den gesamten Bestand und gleichen Sie die Systeme mit Active Directory oder Entra ID, mit dem Inventar der Virtualisierung und mit Ihren Cloud-Konten ab. Was dort nicht mehr existiert, wird im Scanner außer Betrieb genommen, mit kurzer Begründung. Legen Sie eine feste Regel fest, nach wie vielen Tagen ohne Kontakt ein System als inaktiv gilt, und prüfen Sie, wie Ihr Werkzeug diese Regel umsetzt. Defender zum Beispiel zeigt im Schwachstellenmanagement nur Geräte, die in den letzten 30 Tagen aktiv waren.

Danach kommen die Dubletten und die Qualität der Funde. Findings aus Scans ohne Anmeldung beruhen häufig nur auf Versionsangaben, die ein Dienst nach außen meldet. Sie sind deshalb unsicherer als Funde aus authentifizierten Scans oder vom Agenten. Markieren Sie diese Herkunft, damit niemand Tage mit einem Fund verbringt, der sich bei genauerem Hinsehen als falsch herausstellt.

Dieser Schritt fühlt sich nicht nach Sicherheitsarbeit an. Er ist aber die Voraussetzung dafür, dass der IT-Betrieb den Zahlen wieder glaubt.

Schritt 2: Sammelmaßnahmen statt Einzeltickets

Gruppieren Sie die verbleibenden Funde nicht nach CVE, sondern nach Maßnahme. Die meisten Werkzeuge bieten dafür eine Sicht nach Lösung oder Empfehlung. Sortieren Sie nach der Zahl der Findings, die eine Maßnahme schließt. Die obersten zehn Einträge dieser Liste sind Ihr erstes Arbeitspaket.

Prüfen Sie bei jedem Eintrag zuerst, ob die Software überhaupt gebraucht wird. Eine nicht benötigte Java-Version zu entfernen ist schneller und dauerhafter als jedes Update. Für Browser und gängige Standardsoftware lohnt es sich, automatische Updates über Intune, Configuration Manager oder Ihre Softwareverteilung einzuschalten, damit dieselben Funde nicht im nächsten Quartal zurückkommen.

Konfigurationsfunde wie veraltete TLS-Versionen, fehlende SMB-Signierung oder schwache SSH-Einstellungen lösen Sie über Gruppenrichtlinien oder Härtungsvorgaben. Rollen Sie solche Änderungen in Wellen aus, zuerst auf eine Testgruppe, dann breit. Eine Härtung, die ein Altsystem in der Buchhaltung aussperrt, kostet Sie mehr Vertrauen, als sie Sicherheit bringt.

Schritt 3: Entscheidungen für das, was sich nicht beheben lässt

Für jedes System ohne Lösung gibt es drei Wege: ersetzen, abschotten oder das Risiko befristet tragen. Ersetzen ist eine Budgetfrage und gehört damit auf den Tisch der Geschäftsführung. Abschotten heißt konkret: eigenes Netzsegment, Zugriff nur von definierten Systemen, kein Internetzugang, Fernwartung nur über einen kontrollierten Weg.

Bleibt ein Restrisiko, wird es formal akzeptiert. Unterschreiben muss der fachlich Verantwortliche für das System, nicht der Administrator. ISO 27001 verlangt in Abschnitt 6.1.3, dass die Risikoeigentümer den Behandlungsplan und die verbleibenden Risiken genehmigen. Jede Akzeptanz bekommt eine Kompensationsmaßnahme und ein Ablaufdatum, in der Regel sechs bis zwölf Monate. Danach wird neu entschieden.

Verlockend ist an dieser Stelle die Pauschallösung: alles, was älter als ein Jahr ist, wird als akzeptiert markiert. Das verkleinert die Zahl, aber nicht das Risiko, und spätestens im nächsten Audit fällt es auf. Akzeptieren Sie pro System oder pro klar abgegrenzter Systemklasse, nie pro Altersgruppe.

Schritt 4: Den Rest nach Risiko abarbeiten

Was jetzt noch übrig ist, sind echte Einzelfälle. Bewerten Sie sie mit dem heutigen Stand: Steht die Lücke inzwischen im KEV-Katalog der CISA, der Liste nachweislich ausgenutzter Schwachstellen? Wie hoch ist der aktuelle EPSS-Wert? Ist das System aus dem Internet erreichbar? Ein Fund, der vor einem Jahr unauffällig war, kann heute ganz oben stehen. Wie Sie daraus eine feste Reihenfolge machen, beschreibt CVSS reicht nicht.

Jeder Fall bekommt einen Verantwortlichen nach Systemklasse: Server-Team, Client-Team, Netzwerk, Cloud, Fachanwendung. Reservieren Sie im Betrieb feste Kapazität, etwa einen Tag pro Woche und Team. Ohne diese Reservierung verliert die Abarbeitung gegen jedes dringende Tagesgeschäft.

Aufwand und Zeitplan

Für die Schritte eins bis drei sollten Sie in einer mittelständischen Umgebung mit acht bis zwölf Wochen rechnen. Realistisch sind ein bis zwei Tage pro Woche aus der IT-Sicherheit, dazu Zeit der Administratoren für die Sammelmaßnahmen und einige Termine mit Fachbereichen und Geschäftsführung für die Entscheidungen in Schritt drei. Den größten Zeitbedarf haben erfahrungsgemäß nicht die Patches, sondern die Abstimmungen zu Altsystemen.

Sinnvoll ist eine klare Rollenverteilung. Die Projektleitung liegt beim Informationssicherheitsbeauftragten oder der IT-Leitung, ein Mitglied der Geschäftsführung trifft die Entscheidungen zu Ersatz und Risikoakzeptanz, und der IT-Betrieb setzt um.

Damit der Berg nicht wieder wächst

Ein Rückstand wächst, wenn jeden Monat mehr Funde hinzukommen als geschlossen werden. Das klingt banal, wird aber selten gemessen. Berichten Sie deshalb monatlich zwei Zahlen nebeneinander: neue Findings und geschlossene Findings, jeweils für die dringenden Klassen. Dazu kommt die Zahl der dringenden Funde, die ihre Frist überschritten haben.

Die Ursachen für das ursprüngliche Wachstum sind meist dieselben: kein Verantwortlicher je Systemklasse, keine Fristen, keine festen Wartungsfenster und eine Priorisierung, in der alles „High“ ist. Ein fester monatlicher Patchtermin, der sich am Patchday von Microsoft am zweiten Dienstag des Monats orientiert, löst davon schon einen großen Teil. Warum regelmäßiges Patchen allein trotzdem kein Schwachstellenmanagement ist, erklärt Patch-Management und Vulnerability Management.

Für den dauerhaften Betrieb mit Eingangsprozess, Fristen, Rollen und Berichtswesen beschreibt Vom Vulnerability Backlog zum Remediation-Programm die Bausteine.

Der erste Schritt in Ihrem Unternehmen

Nehmen Sie sich einen Nachmittag und den Gesamtexport Ihres Scanners. Ergänzen Sie drei Spalten: wann das System zuletzt gesehen wurde, welche Maßnahme den Fund behebt und zu welcher Systemklasse es gehört. Danach sehen Sie, wie groß die vier Gruppen bei Ihnen sind, und haben die Grundlage für einen realistischen Plan. Wenn Sie das Aufräumen gleich in einen dauerhaften Prozess überführen wollen, zeigt Vulnerability Management in 90 Tagen aufbauen, wie wir dabei vorgehen.