Die Behebung von Schwachstellen, Patches und Updates kann oft lange dauern und das Problem stellt sowohl Anbieter als auch betroffene Unternehmen vor technische, organisatorische und wirtschaftliche Herausforderungen.
Neben der reinen Bearbeitungszeit spielen auch Kosten, Marktanforderungen und betriebliche Risiken eine große Rolle. Und wenn Sicherheitslücken publik werden, kann ein zu langsames Reagieren Reputationsschäden verursachen oder sogar rechtliche Konsequenzen haben (z. B. DSGVO-Strafen bei Datenschutzverstößen).
Daher wollen wir eine kurze Betrachtung mit einigen Aspekten anstellen, die eine Perspektive aus Sicht der Anbieter und Anwender aufzeigt.
Was ist die durchschnittliche Dauer für Patch-Implementierung?
Die Zeitspanne zwischen der Entdeckung einer Schwachstelle und ihrer vollständigen Behebung durch einen Patch kann stark variieren:
IT-Systeme (Server, Anwendungen, Endgeräte): ca. 60 bis 90 Tage
OT-Systeme (Industrieanlagen, kritische Infrastrukturen): oft mehr als 150 Tage – teils sogar Jahre
Unternehmen insgesamt: Durchschnittlich 205 Tage, bis eine Schwachstelle vollständig geschlossen ist (laut Studien von IBM & Ponemon Institute)
Je nach Branche und Kritikalität können diese Werte jedoch stark schwanken.
Warum dauert das so lange?
Fehlende Sofort-Patches durch Hersteller
Viele Schwachstellen werden von Herstellern erst nach gründlicher Analyse mit einem Patch versehen, was mehrere Wochen oder Monate dauern kann. Besonders bei älteren Systemen gibt es oft keine offiziellen Updates mehr, sodass Unternehmen Workarounds oder zusätzliche Sicherheitsmaßnahmen ergreifen müssen.
Testaufwand & Qualitätssicherung vor Implementierung
Bevor ein Update in ein produktives System eingespielt wird, muss es erst in einer Testumgebung geprüft werden. Besonders in regulierten Bereichen (Banken, Gesundheitswesen, KRITIS) sind umfassende Tests erforderlich, um ungewollte Systemausfälle zu vermeiden. Eine komplette identische Testumgebung ist oft nicht vorhanden.
Eingeschränkte Wartungsfenster & Betriebsrisiken
Produktionsanlagen, Krankenhäuser oder Stromnetze können nicht einfach abgeschaltet werden. Updates müssen in geplanten Wartungszyklen erfolgen. Verzögerungen sind oft unausweichlich, weil Unternehmen Risiken wie Betriebsunterbrechungen und Umsatzausfälle minimieren müssen.
Hohe Kosten & begrenzte Ressourcen
Patch-Management kostet Zeit und Geld, insbesondere für große, komplexe IT- und OT-Umgebungen. Unternehmen müssen zwischen Investitionen in Sicherheit & Kostendruck abwägen. Manche Organisationen priorisieren daher andere Projekte, bevor sie Patches ausrollen. Für ältere Systeme fehlen oft die Fachleute, die schon alle in Rente sind. Jungen Teams fehlt das Wissen zu den älteren Lösungen.
Sünden der Vergangenheit
Wenn man über Jahre die Dokumentation vernachlässigt hat, sind Korrekturen mühsam. Gutes und robustes Systemdesign über Jahre hinweg ist anspruchsvoll, nicht jeder löst das zufriedenstellend.
Kundenanzahl
Je mehr Kunden man hat, desto mehr Druck und Budget ist für die Entwicklung des Patches vorhanden. Wenn über die Jahre die Kunden weniger werden, fehlt auch das Geld und Druck für die Reparaturen
Markterwartung & wirtschaftlicher Druck
Unternehmen, die digitale Produkte & Softwarelösungen anbieten, müssen zwischen Schnelligkeit & Sicherheit balancieren. Die Erwartungshaltung am Markt ist: Schnelle Innovation, aber auch sichere Software.
Komplexe Lieferketten & Drittanbieter
Unternehmen sind oft von Software-Lieferanten oder Cloud-Dienstleistern abhängig. Wenn ein Patch von einem Drittanbieter nicht rechtzeitig bereitgestellt wird, können Kunden nichts tun, außer auf eine Lösung zu warten.
Gegenmaßnahmen
Mögliche Gegenmaßnahmen zur Beschleunigung von Patches & Updates können eine bessere Planung sein, bei der mehr Tage als bisher für Änderungen geplant sind, die man nutzen kann. Oder man versucht die Architektur so stabil wie möglich, was aber wieder die Weiterentwicklung hemmt.
Am Ende ist es die Frage der Risiken, Kosten und Prioritäten.
Was hat der Begriff des „Technical Debt“ damit zu tun?
Der Begriff "Technical Debt" (technische Schuld) beschreibt die bewusste oder unbewusste Ansammlung von technischen Defiziten in Software, IT-Systemen oder Infrastrukturen. Diese Defizite entstehen aus verschiedenen Gründen, sowohl durch technischen Fortschritt, Kostendenken oder auch das Hinauszögern von Änderungen. Aber manchmal auch durch schnelle, kurzfristige Entscheidungen, die später aufwendige Nachbesserungen erfordern.
Wie hängt "Technical Debt" mit Patching und Sicherheitsmaßnahmen zusammen?
Veraltete Software & Legacy-Systeme
Unternehmen arbeiten oft mit alten Systemen, die nicht mehr regelmäßig aktualisiert werden. Viele dieser Systeme sind nicht für moderne Sicherheitsanforderungen ausgelegt und benötigen individuelle Workarounds, um sicher betrieben zu werden.
Unzureichendes Patch-Management
Wenn Unternehmen Patches nicht rechtzeitig einspielen, wächst die technische Schuld weiter. Je länger Updates aufgeschoben werden, desto schwieriger und teurer wird die spätere Behebung von Schwachstellen.
Sicherheitsrisiken durch fehlende Wartung
Schwachstellen in nicht gewarteten Systemen machen Unternehmen anfällig für Cyberangriffe. Viele Ransomware-Angriffe nutzen genau diese technischen Schulden aus, indem sie bekannte, aber nicht behobene Sicherheitslücken ausnutzen.
Hohe Kosten für spätere Korrekturen
Das Aufschieben von Sicherheitsmaßnahmen spart kurzfristig Ressourcen, aber langfristig steigen die Kosten für Notfallmaßnahmen, Incident Response oder gar Schadensersatzforderungen. Untersuchungen zeigen, dass die Behebung eines Sicherheitsproblems exponentiell teurer wird, je später es adressiert wird.
Falsche Anreizsysteme
Wenn Führungskräfte nur für aktuelle Gewinne oder niedrige Kosten belohnt werden, schieben Sie Modernisierung hinaus, die ja ohnehin nur dem Nachfolger zugute kommt. Also bleibt alles wie es ist, obwohl man schon weiß, daß es später teurer wird und Kunden unzufrieden sind.
Fazit
Technical Debt in der IT-Sicherheit kann man u.a. vermeiden durch regelmäßige Sicherheitsupdates & etabliertes Patch-Management, mehr "Security by Design" statt kurzfristige Workarounds zu bekämpfen. Man sollte technische Schulden frühzeitig erkennen & priorisieren.
Jede Verzögerung bei der Behebung einer Sicherheitslücke bedeutet ein erhöhtes Risiko für Cyberangriffe, Datenschutzverstöße oder Betriebsausfälle. Technical Debt ist eine der Hauptursachen dafür, warum Sicherheitslücken lange bestehen.
Ein schnelleres und strategisch optimiertes Patch-Management auf Seite der Hersteller und Anwender hilft, Cyberrisiken zu reduzieren.
Der technische Fortschritt wird aber – machen wir uns nichts vor – dazu führen, daß manches Altsystem keine Patches mehr bekommt und vom Markt verschwindet. Wenn Unternehmen versuchen, ihren Technologie-Stack modern zu halten, reduzieren sie das Risiko, am Ende ohne Option für Patches und Updates ihrer Lösungen dazustehen.
Problematisch ist auch die geringe Macht der Anwender, die schlechtes Patchmanagement vom Anbieter akzeptieren müssen, sie sind oft machtlos gegenüber den Softwarekonzernen.
Solange der Markt das kurzfristige Profitstreben der Anbieter bei schlechtem Langzeit-Service akzeptiert, wird sich kaum etwas ändern. Der Börsenkurs dankt es ihnen ja auch, wenn Kosten in der Wartung gespart werden und der Profit hoch ist! Beispiel Microsoft: Lag der Umsatz in Q4/2024 bei 64,7 Milliarden US-Dollar, belief sich der Reingewinn auf lächerliche 22 Milliarden US-Dollar. Wovon soll man da mehr in Sicherheit investieren?
Warum also etwas für Patches und die Sicherheit tun? Es läuft doch auch so!
Comentários