Security-Updates: Warum jeder Tag ohne Patch zählt

"Wir spielen Updates ein, wenn wir Zeit haben." Dieser Satz ist in vielen Unternehmen Alltag. Solange nichts passiert, kostet er nichts. Wenn etwas passiert, kostet er viel.

Bei Security-Updates geht es nicht um neue Funktionen. Es geht um Lücken, die bereits bekannt sind, öffentlich dokumentiert und oft bereits mit fertigen Werkzeugen ausnutzbar. Wer hier zögert, lässt eine bekannte Tür offen.

Dieser Artikel erklärt, warum die Zeit zwischen Veröffentlichung einer Lücke und den ersten Angriffen so kurz ist, was bei Verschleppung passiert und wie ein verlässlicher Patch-Prozess aussieht.

Was ein Security-Update überhaupt ist

Ein Security-Patch ist eine Korrektur, die eine bekannte Sicherheitslücke schließt. Sie wird vom Hersteller oder vom Open-Source-Projekt veröffentlicht, sobald die Lücke verstanden und behoben ist.

Anders als Funktions-Updates bringen Security-Patches selten neue Möglichkeiten. Sie schließen Türen. Mehr nicht. Genau deshalb sind sie einfacher einzuspielen als grosse Versionssprünge.

Begleitet werden sie oft von einer öffentlichen Beschreibung, der CVE-Sicherheitslücke. Diese Beschreibung ist für Verteidiger wie für Angreifer einsehbar.

Die Zeitachse: Veröffentlichung, Exploit, Welle

Die Theorie ist: Hersteller veröffentlicht Patch, Unternehmen spielen ihn ein, Risiko ist weg. Die Praxis sieht anders aus.

Tag 0: Veröffentlichung. Der Hersteller veröffentlicht den Patch und meist auch eine CVE-Nummer mit Beschreibung. Damit ist die Lücke öffentlich.

Tag 0 bis 2: Reverse Engineering. Sicherheitsforscher und Angreifer vergleichen den alten und neuen Code. Aus dem Patch lässt sich oft die Lücke selbst rekonstruieren.

Tag 1 bis 7: Erste Exploits. Für viele kritische Lücken erscheinen kurz nach Veröffentlichung fertige Exploits. Manchmal als Forschungs-Tool, manchmal in Hacker-Foren.

Tag 7 bis 30: Welle. Automatisierte Scanner durchforsten das Internet nach verwundbaren Systemen. Jede ungepatchte Installation ist ein potenzielles Ziel.

Das ist kein dramatisches Worst-Case-Szenario. Das ist das übliche Muster bei kritischen Lücken in verbreiteten Komponenten der letzten Jahre. Bekannt aus Log4Shell, aus diversen Drupal-, WordPress- und Exchange-Lücken.

Warum Verschleppung so teuer wird

Bekannte Lücken sind leichte Beute

Angreifer arbeiten meistens nicht zielgerichtet. Sie scannen das Internet automatisiert nach Systemen, die bekannte Lücken haben. Wer ungepatcht im Netz steht, ist ein Treffer im Massenscan. Größe und Branche sind dabei egal.

Versicherungen reagieren empfindlich

Cyber-Versicherungen prüfen im Schadensfall, wie aktuell die Systeme waren. Wer eine Lücke ungepatcht ließ, obwohl der Patch seit Wochen verfügbar war, riskiert den Versicherungsschutz.

DSGVO und Stand der Technik

Artikel 32 DSGVO verlangt angemessene technische Maßnahmen. Aufsichtsbehörden lesen das so, dass bekannte Sicherheitslücken zeitnah geschlossen werden. Wer das nicht tut, hat im Vorfallsfall ein schlechtes Argument.

Folgekosten eines Vorfalls

Ein Sicherheitsvorfall kostet selten nur die Wiederherstellung. Es kommen forensische Analyse, Information der Betroffenen, mögliche Bußgelder, Reputationsschaden und unterbrochener Betrieb dazu. Patch einspielen ist um Größenordnungen günstiger.

Was ein guter Patch-Prozess leistet

Geschwindigkeit ohne Struktur ist riskant. Ein verlässlicher Patch-Prozess kombiniert beides.

Schritt 1: Übersicht der Systeme

Sie können nur patchen, was Sie kennen. Welche Systeme stehen wo, mit welchen Bibliotheken in welcher Version? Eine aktuelle Bestandsliste, idealerweise als Software-Bill-of-Materials, ist Voraussetzung für alles Weitere.

Schritt 2: Monitoring der CVE-Quellen

Sicherheitsmeldungen erscheinen täglich. Jemand muss sie lesen und einordnen. Quellen sind CVE-Datenbanken, Hersteller-Bulletins, Mailing-Listen wie die der Distributionen, Tools wie Dependabot oder Snyk.

Schritt 3: Bewertung nach Risiko

Nicht jeder Patch ist gleich dringend. Eine kritische Lücke in einem nach außen erreichbaren System muss in 24 bis 48 Stunden eingespielt sein. Eine mittlere Lücke in einer internen Komponente verträgt mehrere Wochen.

Schritt 4: Testen vor Produktion

Patches können Nebenwirkungen haben. Eine Staging-Umgebung, in der der Patch erst einmal läuft, fängt böse Überraschungen ab. Automatisierte Tests prüfen, ob die Anwendung weiterhin funktioniert.

Schritt 5: Auslieferung mit Rollback

Wenn ein Patch in Produktion geht, muss klar sein, wie er sich zurücknehmen lässt, falls Probleme auftauchen. Ein Datenbank-Backup vor dem Patch, ein zweiter Server, der den alten Stand hält: einfache Mittel, die viel retten.

Schritt 6: Dokumentation

Welcher Patch wurde wann eingespielt? Wer hat ihn freigegeben? Diese Information ist Gold wert, wenn später ein Audit ansteht oder wenn ein Vorfall analysiert werden muss.

Realistische Service-Level

Drei Stufen haben sich in der Praxis bewährt.

Kritische Lücken. Patch binnen 24 bis 48 Stunden. Dazu zählen Lücken, die Angreifern Code-Ausführung erlauben, oder Lücken, für die bereits Exploits im Umlauf sind.

Hohe Lücken. Patch binnen einer Woche. Lücken, die unter bestimmten Bedingungen ausnutzbar sind oder Daten preisgeben.

Mittlere und niedrige Lücken. Patch binnen eines Monats, gebündelt mit anderen Updates. Häufig im Rahmen eines monatlichen Wartungsfensters.

Diese Werte sind keine Erfindung. Sie orientieren sich an dem, was viele Sicherheits-Frameworks und Versicherungen heute erwarten.

Was passiert bei Verschleppung

Ein paar Muster aus dem Alltag.

Patch wird "auf später" verschoben. Erst ist Hochbetrieb. Dann Urlaubszeit. Dann steht ein anderes Projekt im Weg. Aus einer Woche werden Monate. Inzwischen ist die Lücke seit langem ausnutzbar.

Patch wird teilweise eingespielt. Server A ist aktualisiert, Server B vergessen. Angreifer brauchen nur einen Einstiegspunkt.

Anwendung bricht beim Patch. Weil sie zu lange nicht gepflegt wurde, verträgt sie den Sprung auf eine neue Bibliotheksversion nicht. Aus dem Patch wird ein Migrationsprojekt. Während dieser Zeit bleibt das System verwundbar.

Diese Muster sind keine Ausnahmen. Sie sind die Hauptursache für vermeidbare Vorfälle.

Wer das nicht selbst leisten kann

Nicht jedes Unternehmen hat eine eigene Sicherheits-Mannschaft. Für viele ist es realistischer, das Patch-Management auszulagern oder mit einem Dienstleister zu kombinieren.

Wir betreiben Patch-Prozesse für Unternehmen, deren Systeme zu kritisch sind, um sie nebenbei zu pflegen. Mehr dazu unter Sicherheit & Härtung und im Rahmen der laufenden Software-Wartung.

Fazit

Security-Updates sind keine Komfort-Funktion. Sie sind die einfachste und wirksamste Maßnahme gegen die häufigste Angriffsart: das automatisierte Ausnutzen bekannter Lücken.

Wer einen verlässlichen Patch-Prozess hat, hat den größten Teil seines Sicherheits-Risikos im Griff. Wer keinen hat, lebt mit offenen Türen.

Sprechen Sie uns an, wenn Sie wissen wollen, wie schnell Ihr System heute reagieren könnte. Kontakt aufnehmen.