Patchmanagement gegen Zero-Day-Attacken
Wenn's schnell gehen muss
Veröffentlicht in Ausgabe 02/2024 - SCHWERPUNKT
Fehlerfreie Software gibt es nicht, zumindest nicht ab einem gewissen Komplexitätsgrad. Das zeigt sich schon daran, dass jeden Monat Tausende von Patches für Software bereitgestellt werden, trotz einer erheblichen Professionalisierung von Softwareentwicklung, trotz Testautomation und trotz SDLCs (Software Development Lifecycles) mit Fokus auf Qualitätsverbesserung und Sicherheit.
Automatisierte Patchinstallation als Norm
Die Bereitstellung von Patches ist dabei gerade bei den führenden, großen Softwareanbietern über die letzten beiden Dekaden kontinuierlich verbessert und automatisiert worden, sodass sich die Sicherheitsflicken beispielsweise für Windows und iOS automatisch einspielen lassen und Anwendungen wie die Office-Programme in Microsoft 365 regelmäßig automatisch aktualisiert werden. Auch bei Clouddiensten, sowohl bei PaaS (Platform-as-a-Service) als auch bei SaaS (Software-as-a-Service), sind diese regelmäßige Aktualisierung und funktionale Erweiterung (und das gelegentliche Abschalten von Funktionen und APIs) inzwischen die Norm.
Dennoch gibt es noch immer viele Organisationen, in denen die automatisch bereitgestellten und gelieferten Patches beispielsweise für Windows-Systeme nicht automatisiert eingespielt werden, wobei der Zeitpunkt des Neustarts ja selbst bei restriktiven Richtlinieneinstellungen noch ein Stück weit vom Nutzer gesteuert werden kann. Stattdessen findet sich immer wieder der Ansatz, dass die IT-Abteilung Patches zunächst gründlich testet, oft über mehrere Wochen hinweg, bevor sie auf allen relevanten Systemen installiert werden müssen. Dahinter steht die Befürchtung, dass ein Patch zu einem Fehlverhalten in Systemen bis hin zum völligen Ausfall führen kann. Solche Probleme, die viele Systeme betroffen haben, kamen in der (entfernteren) Vergangenheit beispielsweise bei Windows gelegentlich vor.
Fehlerfreie Software gibt es nicht, zumindest nicht ab einem gewissen Komplexitätsgrad. Das zeigt sich schon daran, dass jeden Monat Tausende von Patches für Software bereitgestellt werden, trotz einer erheblichen Professionalisierung von Softwareentwicklung, trotz Testautomation und trotz SDLCs (Software Development Lifecycles) mit Fokus auf Qualitätsverbesserung und Sicherheit.
Automatisierte Patchinstallation als Norm
Die Bereitstellung von Patches ist dabei gerade bei den führenden, großen Softwareanbietern über die letzten beiden Dekaden kontinuierlich verbessert und automatisiert worden, sodass sich die Sicherheitsflicken beispielsweise für Windows und iOS automatisch einspielen lassen und Anwendungen wie die Office-Programme in Microsoft 365 regelmäßig automatisch aktualisiert werden. Auch bei Clouddiensten, sowohl bei PaaS (Platform-as-a-Service) als auch bei SaaS (Software-as-a-Service), sind diese regelmäßige Aktualisierung und funktionale Erweiterung (und das gelegentliche Abschalten von Funktionen und APIs) inzwischen die Norm.
Dennoch gibt es noch immer viele Organisationen, in denen die automatisch bereitgestellten und gelieferten Patches beispielsweise für Windows-Systeme nicht automatisiert eingespielt werden, wobei der Zeitpunkt des Neustarts ja selbst bei restriktiven Richtlinieneinstellungen noch ein Stück weit vom Nutzer gesteuert werden kann. Stattdessen findet sich immer wieder der Ansatz, dass die IT-Abteilung Patches zunächst gründlich testet, oft über mehrere Wochen hinweg, bevor sie auf allen relevanten Systemen installiert werden müssen. Dahinter steht die Befürchtung, dass ein Patch zu einem Fehlverhalten in Systemen bis hin zum völligen Ausfall führen kann. Solche Probleme, die viele Systeme betroffen haben, kamen in der (entfernteren) Vergangenheit beispielsweise bei Windows gelegentlich vor.
Die Frage, die sich heute aber stellt, ist, ob mit Blick auf veränderte Cyberrisiken ein solcher Ansatz noch valide ist oder ob die Gefahren im Bereich Cybersicherheit nicht inzwischen so groß sind, dass schnelles Patchen wichtiger und weit weniger kritisch ist als die Bedrohung durch Cyberangriffe, die dann beispielsweise über Ransomware die gesamte IT lahmlegen können – und das manchmal über Tage oder Wochen.
Cyberrisiko Zero-Day-Exploits
Über die vergangenen Jahre haben Cyberattacken kontinuierlich zugenommen, in der Tendenz sowohl bezüglich der Zahl der Angriffe als auch hinsichtlich der hierdurch verursachten Schäden. Der Branchenverband Bitkom spricht allein für Deutschland von jährlichen Schäden durch Cyberattacken von über 200 Milliarden Euro. Diese werden nicht nur durch die Kosten für das Wiederherstellen von IT-Systemen verursacht oder durch das Bezahlen von Lösegeld nach Ransomware-Angriffen. Die höchsten Kosten entstehen durch die operativen Ausfälle in Produktion und Verwaltung von Unternehmen. Manche Organisationen und Behörden benötigen Wochen oder sogar Monate, um wieder vollständig produktiv zu werden.
Ein wesentlicher Teil dieses Risikos entsteht dabei durch sogenannte Zero-Day-Exploits, also Schwachstellen, die bereits beim Bekanntwerden, an Tag Null, von Angreifern ausgenutzt werden. Der Begriff "Zero Day" ist dabei bedauerlicherweise ein Euphemismus, weil die allermeisten dieser Schwachstellen schon vorher ausgenutzt werden, in manchen Fällen sogar Monate und Jahre vor ihrer Entdeckung.
Mit dem Tag Null nimmt die Zahl der Angriffe bei Schwachstellen, insbesondere solchen, die leicht ausnutzbar oder bezüglich der Sicherheitsrisiken besonders kritisch sind, sprunghaft zu. Viele der Angreifer, ob kriminelle Organisationen oder Akteure aus dem staatlichen Umfeld, arbeiten hochprofessionell und sind in der Lage, in sehr kurzer Zeit automatisierte Angriffe zu fahren. Diese zielen darauf ab, entweder direkt in Systeme einzudringen oder dort Malware zu platzieren, die dann weitere Angriffe von gezielten Attacken bis hin zu sehr breit gestreuter Ransomware umfassen können.
Das Problem ist, dass das Zeitfenster für die Reaktion auf Angriffe damit sehr eng geworden ist. Dies ist daher auch der Grund, warum viele der Exploits erst veröffentlicht werden, wenn der Patch zur Verfügung steht.
Erst mit dem Patch sinkt das Risiko
Der Zeitraum der Bedrohung lässt sich in mehrere Phasen mit hoher Kritikalität einteilen:
1. Eine Schwachstelle, die von Angreifern ausgenutzt werden könnte, besteht, ist aber bisher nicht entdeckt worden. Es gibt foglich das Risiko, dass Angreifer diese Lücke identifizieren und für sich ausnutzen.
2. Die Schwachstelle wird von Angreifern und nicht von Verteidigern entdeckt, ist aber noch nicht allgemein bekannt. Das Risiko ist, abhängig davon, wie einfach und wofür sich die Vulnerability nutzen lässt, potenziell sehr hoch.
3. Die Schwachstelle wird identifiziert und an den Softwareanbieter gemeldet. Das Risiko ist weiterhin sehr hoch. Falls die Schwachstelle bereits hier allgemein bekannt wird, steigt das Risiko noch.
4. Der Softwarehersteller entwickelt einen Patch, gegebenenfalls in Phasen mit einem ersten Hot-Fix vor dem finalen Patch, und stellt diesen bereit. Bis der Patch bereitsteht, bleibt das Risiko unverändert hoch, auch abhängig davon, ob die Lücke allgemein bekannt ist oder sich noch vor dem Tag Null befindet.
5. Spätestens mit der Bereitstellung des Patches wird die Schwachstelle allgemein bekannt. Das Risiko wächst weiter an. Allerdings lassen sich nun mit der Patchinstallation wirksame Gegenmaßnahmen ergreifen.
6. Das Risiko sinkt mit der schrittweisen Verbreitung des Patches, wobei gleichzeitig die Angriffe zunehmen, die die Schwachstelle ausnutzen. Für gepatchte Systeme ist das Risiko der Schwachstelle adressiert. Für ungepatchte wächst es weiter an.
In den Phasen 1 bis 4 können Unternehmen nur generische mitigierende Maßnahmen im Bereich der Cybersicherheit ergreifen, also die gängigen Mechanismen für den Schutz (Protection) und die Erkennung (Detection) von Cyberangriffen.
Dass das Einspielen von Patches selbst für bekannte, hochkritische Sicherheitslücken oft sehr lange dauert, hat sich beispielsweise bei Heartbleed gezeigt, wo nach einer mit der Suchmaschine Shodan durchgeführten Analyse auch fast drei Jahre nach dem Vorfall noch beinahe 200.000 Systeme ohne Patch gefunden wurden. Für Log4j waren es nach unabhängigen Quellen rund ein Drittel der Systeme, die nach vier Monaten noch nicht gepatcht waren.
Laut einer Kaseya-Studie von 2019 haben damals jeweils 42 Prozent der Organisationen angegeben, Windows-Patches beispielsweise via Windows Update automatisch einzuspielen respektive das innerhalb von 30 Tagen nach Prüfung zu machen. Auch wenn sich diese Zahlen seitdem vermutlich – oder zumindest hoffentlich – zugunsten des automatischen Patchens verbessert haben, ist weiterhin davon auszugehen, dass ein signifikanter Teil der Systeme nicht automatisch gepatcht wird.
Die veränderte Balance
Mit dem kontinuierlichen Anstieg der Cyberrisiken auf der einen Seite und der sehr viel höheren Zuverlässigkeit von Patchprozessen gerade für Endgeräte wie Windows- und Apple-Systeme hat sich die Balance in den vergangenen Jahren verändert. Diese Veränderung ist nicht erst jetzt geschehen, sondern kontinuierlich über mindestens die letzten zehn Jahre. Das Risiko, dass beim Einspielen eines Patches größere Probleme entstehen oder gar flächendeckende Ausfälle von Systemen, ist heute als sehr gering einzuschätzen. Es war vor zehn oder mehr Jahren noch höher.
Auf der anderen Seite sind die Cyberrisiken heute nochmal deutlich höher als vor zehn Jahren und steigen weiter an. Die Auswirkungen fallen dabei zudem oftmals noch viel schwerwiegender als früher aus. Die Konsequenzen von Ransomware-Angriffen mit teils tagelangen Produktionsausfällen in Fertigungsunternehmen sind wesentlich gravierender als die, die durch eine Neuinstallation von Betriebssystemen auf Endgeräten je entstanden sind, insbesondere bei einem Blick auf die heutige hohe Effizienz bei der Einrichtung von modernen Systemen.
Daraus lässt sich der Schluss ziehen, dass ein genereller Ansatz, bei dem Patches verzögert auf allen Systemen eingespielt werden, in jedem Fall falsch und unter Risikogesichtspunkten nicht mehr vertretbar ist. Der Regelfall muss das automatisierte Patchen bei Verfügbarkeit des Patches sein, insbesondere bei Endgeräten. Auch dabei kann etwas schiefgehen. Das Risiko ist aber geringer und kann sich beispielsweise durch effiziente Wiederherstellungsprozeduren und ein kontinuierliches Monitoring des Systemstatus während des Rollouts von Prozessen weiter verringern lassen.
Doch wie immer gibt es ein "aber", weil in Unternehmenes Systeme vorhanden sind, bei denen IT-Verantwortliche abwägen müssen, was der richtige Ansatz ist.
Kritischen Systeme: Business-Anwendungen, Server, OT
Für die gängigen Endgeräte im Office-Umfeld ist das Ergebnis der Gleichung eindeutig. Anders sieht es in weiteren Bereichen aus, beispielsweise bei Kassensystemen im Handel, die ja auch Endgeräte sind, bei Endgeräten im Produktionsumfeld, bei Business-Anwendungen wie SAP, bei den Serversystemen "unterhalb" dieser Business-Anwendungen und insbesondere im Bereich OT (Operational Technology), also den produktionssteuernden Plattformen.
Zunächst gibt es für viele dieser Systeme keine automatisierte Bereitstellung von Patches, zumindest soweit es sich nicht – wie bei Business-Anwendungen und Serversystemen zunehmend üblich – um PaaS- oder SaaS-Dienste handelt. In manchen Bereichen ist ferner kein ausreichend professionalisierter Prozess für die Bereitstellung von Patches und deren Automatisierung gegeben, während es beispielsweise im SAP-Umfeld ausreichend Tools gibt, um Hotfixes (temporäre Patches), Patches und Support Packages auch automatisiert, aber immer vom Anwenderunternehmen kontrolliert, einspielen zu können. Dennoch lassen sich überall definierte Prozesse, ob manuell oder automatisiert, festlegen, um eine schnelle Bereitstellung von Patches sicherzustellen und das Zeitfenster für Angreifer zu reduzieren.
Dabei gilt es aber, eine differenzierte Abwägung vorzunehmen, wie auch beispielsweise für Windows-Systeme, nur dass der Ausgang dieser Abwägung nicht so eindeutig ist:
- Sicherheitsrisiken: Auf der einen Seite stehen die Sicherheitsrisiken. Dabei geht es darum zu analysieren, ob ein konkretes Risiko für das betroffene System besteht, wie einfach die Schwachstelle auszunutzen ist, wie groß der mögliche Schaden durch Ausfälle, Datendiebstahl oder andere Schäden ist und ob es andere wirksame Mitigationsmaßnahmen gibt, die bereits implementiert sind oder ergriffen werden können. Eine realistische Betrachtung der Wirksamkeit solcher Maßnahmen ist wichtig, da viele der genannten Systeme typische Ziele für gezielte Angriffe sind. Bei diesen versuchen Hacker mit hohem Aufwand, vorgeschaltete Sicherheitssysteme zu umgehen, um beispielsweise an Geschäftsgeheimnisse zu gelangen oder Steuerungssysteme für Produktionsanlagen auszuschalten.
- Patchrisiko: Auf der anderen Seite steht das Patchrisiko, also die Einschätzung, mit welcher Wahrscheinlichkeit das Einspielen des Patches zu Problemen im System oder zu Folgeproblemen in abhängigen Systemen führt. Das betrifft beispielsweise einen Patch des Betriebssystems und seine Auswirkungen auf Datenbanken, oder welche Folgen Änderungen bei Datenbanken auf Anwendungssysteme haben könnte – etwa weil sich Funktionen verändern. Hierbei helfen Erfahrungswerte. Es gibt aber keine generell verlässlichen Aussagen.
- Verfügbarkeitsrisiken: Aus den zuvor genannten Faktoren resultiert das Verfügbarkeitsrisiko, also die Gefahr, dass ein für das Unternehmen zentrales System zeitweise nicht mehr zur Verfügung steht. Dieses hängt nicht zuletzt mit der Fähigkeit zur Wiederherstellung auf einem stabilen Stand zusammen. Je kleiner diese Gefahr ist, desto geringer das Patchrisiko. Geprobte Wiederherstellungsprozesse sind daher essenziell. Es gilt aber auch, Verfügbarkeitsrisiken ebenso realistisch wie Sicherheitsrisiken zu bewerten. Nicht jeder Ausfall einer Business-Anwendung oder eines Produktionssystem ist gleichermaßen kritisch. Wenn ein eCommerce-System im Handel nicht mehr funktioniert oder das Fließband in der Produktion steht, ist das ungleich schwerwiegender als der Ausfall eines HR-Systems für wenige Stunden.
- Wartungszeitfenster: Da das Einspielen von Patches typischerweise mit einem Neustart verbunden ist, der gerade in komplexeren Anwendungssystemen Abhängigkeiten zwischen Betriebssystem, Middleware, Datenbanken und Anwendungssystemen beinhalten kann, muss das Verteilen des Patches auf Wartungszeitfenster gelegt werden, soweit es kein Hochverfügbarkeits-/Failover-Werkzeug gibt, das eine schrittweise Installation ermöglicht. Letzteres ist grundsätzlich für hochkritische Systeme sinnvoll, weil damit – neben vielen anderen positiven Auswirkungen – Patches mit geringerem Risiko und im laufenden Betrieb einspielen lassen. Wenn der Patch auf einem Knoten fehlschlägt, lässt sich der Prozess abbrechen und dieser Knoten wiederherstellen, im Idealfall ohne Auswirkungen auf das Gesamtsystem.
- Haftungs-/Garantierisiken: Gerade im OT-Umfeld kommen teilweise noch Haftungs- und Garantierisiken bei der Änderung von Systemen dazu, wozu auch Aktualisierungen von (oft veralteten) Betriebssystem gehören können.
Wichtig ist, dass IT-Verantwortliche eine solche Risikoabwägung vornehmen, am besten im Rahmen einer umfassenden Business-Impact-Analyse.
Fazit
Generell ist es höchste Zeit, Patchstrategien auf den Prüfstand zu stellen. In vielen Bereichen ist das automatisierte Deployment inzwischen der beste Weg, weil sich die Gefahren deutlich vom Patch- zum Sicherheitsrisiko verschoben haben, auch wenn es immer noch ein Restrisiko durch die Patchinstallation gibt.
In anderen Bereichen bedarf es einer differenzierten Abwägung. Dort, wo nicht unmittelbar gepatcht werden kann, ist zunächst zu überlegen, ob sich Risiken beispielsweise durch (allerdings teure) Hochverfügbarkeits- und Failover-Ansätze reduzieren lassen. Die Alternative sind ergänzende Sicherheitsschichten, um das Risiko durch ungepatchte Systeme so gering wie möglich zu halten. Auch diese Maßnahmen kosten Geld.
In jedem Fall braucht es aber eine definierte Strategie, strukturierte Entscheidungsprozesse zum Patchmanagement und definierte und geprobte Prozesse sowohl für das Einspielen von Patches als auch das Troubleshooting im Fehlerfall, beispielsweise durch effiziente Prozesse bei der Wiederherstellung.
(ln)