Was Hafnium und Log4 Shell für die Zukunft der IT-Sicherheit bedeuten

Eine Konstante, die sich durch die gesamte Berichterstattung zieht, sind Verzögerungen oder Versäumnisse auf Seiten der betroffenen Unternehmen. Geschwindigkeit wird immer wichtiger, wenn es um die Aktualisierung verwundbarer Systeme geht. Das Reaktionsfenster wird mit jedem grossen Angriff und jeder kritischen Sicherheitslücke kleiner. Haben wir uns vor einigen Jahren noch im Bereich von Tagen bewegt, ist die Zeit zwischen dem Bekanntwerden einer Sicherheitslücke und deren Ausnutzung durch verschiedene Angreifergruppen und deren Trittbrettfahrer auf wenige Stunden zusammengeschmolzen. In diesem Zusammenhang ist interessant: Oft tauchen neue Sicherheitslücken kurz vor dem Wochenende oder vor Feiertagen auf. Solches Timing ist kein Zufall, sind doch zu solchen Zeiten viele Unternehmen bereits im Wochenend- oder Ferienmodus.

Die Ereignisse zeigen, dass Kriminelle auf diese Befindlichkeiten nur wenig Rücksicht nehmen – im Gegenteil. "Ach, das kann auch bis Montag warten", scheint eine häufige Reaktion zu sein. Wer meint, dass es schon nicht so schlimm sein wird, weil das eigene Unternehmen kein lukratives Ziel darstellt, der verkennt eindeutig den Ernst der Lage. Die Entscheidung darüber, ob ein Unternehmen ein lohnendes Angriffsziel darstellt, liegt nicht beim betroffenen Unternehmen, sondern beim Angreifer. Es gab sogar bereits Fälle, in denen deutsche Datenschutzbehörden explizit darauf hinwiesen, dass automatisch ein nach der EU-Datenschutzgrundverordnung meldepflichtiger Vorfall eingetreten sein kann, wenn Updates zu einem bestimmten Zeitpunkt noch nicht installiert waren. Wer also die Hände in den Schoss legt und darauf hofft, dass nichts passiert, macht sich – je nach Lesart – bereits durch Untätigkeit strafbar.

Triage bei den Anbietern

Gerade die Exchange-Sicherheitslücke, welche die Hafnium-Gruppierung ausgenutzt hat, erwischte viele Unternehmen sprichwörtlich eiskalt. Wohl dem, der hier vorgesorgt und einen entsprechenden Notfallplan mit Option auf Vor-Ort-Unterstützung aufgestellt hat. Denn zeitweise waren Incident-Response-Experten schwer zu finden – jedenfalls wenn es um kurzfristige Verfügbarkeit ging. Viele Anbieter haben Triage-Systeme eingerichtet, in denen eigene Kunden Priorität bei tiefergehender Betreuung genossen. Dass das notwendig werden würde, war klar, als das Ausmass der Lücken bekannt wurde und eine grosse Anzahl potenziell betroffener Unternehmen sich hilfesuchend an die Fachleute wandten und auch noch weiterhin wenden.

Am Anfang steht ein Compromise Assessment, das schnell Fälle in die Kategorien "wahrscheinlich kompromittiert" und "wahrscheinlich nicht kompromittiert" einordnet. Personelle Ressourcen lassen sich so besser planen. Der eine oder andere Leser wird sich an dem Wort "wahrscheinlich" stossen, weil das doch wenig konkret klingt. Aber für eine definitive Antwort bräuchte es – richtig – Ressourcen in Form von Zeit und Personal. Und diese Ersteinschätzung soll ja gerade zur Planung von Ressourcen und deren Einsatz dienen.

Zu alldem kommt noch erschwerend dazu, dass eine verlässliche Einschätzung, ob ein Netzwerk kompromittiert ist oder nicht, mit fortschreitender Zeit immer schwerer abzugeben ist. Denn ein Angreifer, der die initiale Sicherheitslücke bereits ausgenutzt hat, hatte gegebenenfalls schon Zeit, seine Spuren zu verwischen und sich im Netzwerk einen eigenen Brückenkopf zu errichten.

Gleiches gilt sowohl für die Hafnium-Angriffe als auch für Log4shell. Letzteres nutzte eine Sicherheitslücke in einer verbreiteten Open-Source-Softwarekomponente aus. Das entfachte eine teils sehr leidenschaftliche Diskussion über den Einsatz von quelloffener und freier Software in Unternehmensnetzen und -produkten. Gemäss ihrem Naturell wird freie Software nicht immer von einem Einzelunternehmen entwickelt, und jede freie Software trägt einen Disclaimer, der jegliche Haftung ausschliesst und darauf hinweist, dass die Software "so, wie sie ist" zur Verfügung steht. Also ganz anders als etwa Exchange, das von Microsoft angeboten, verkauft und gewartet wird.

Zwar waren die Dispute zu diesem Thema nicht immer zielführend, aber haben zumindest die Frage aufgeworfen, wie in solchen Fällen künftig zu verfahren sei und wie sich der Umgang mit freier Software in einer kommerziellen Umgebung gestalten liesse. Einer der Ansätze schlägt vor, dass die Entwicklung freier und quelloffener Software durch Unternehmen, die sie einsetzen, aktiv vorangetrieben wird – sei es durch eigene Eingaben oder durch monetäre Unterstützung in Form von Spenden. Fakt ist, dass sich in den letzten Jahren stellenweise ein Anspruchsdenken gegenüber der FOSS-Community (Free and Open Source Software) entwickelt hat, dem diese jedoch weder gerecht werden kann, noch unbedingt gerecht werden will – und auch nicht sollte. Und schliesslich leben Projekte wie Log4j davon, dass auch Input von Nutzerinnen und Nutzern hereinkommt.

Wichtig ist unabhängig davon auch die Differenzierung zwischen "frei" und "kostenlos" – eine Unterscheidung, die sprachlich im Englischen nicht existiert. Zwar fallen für die Anschaffung und den Einsatz keine unmittelbaren Lizenzkosten an und jeder, der will, kann den Quellcode einsehen und anpassen. Doch es sind Spezialistinnen und Spezialisten vonnöten, die die Programme kennen und entsprechend warten können. Wer freie Software einsetzt, hat keinen Anspruch auf irgendeine Garantie oder technische Unterstützung mit Service Level Agreements – ausser gegen Bezahlung. Das verkennen einige anscheinend.

Prioritäten bei der Reaktion

Was können Firmen also tun, wenn sie sich auf eine solche Grosslage vom Typ Log4shell oder Hafnium vorbereiten wollen? Zunächst einmal muss das Sicherheitskonzept auf den Prüfstand gestellt werden – sofern denn eines existiert. Entgegen einer Meinung, die noch weit verbreitet scheint, ist ein Penetrationstest (kurz "Pentest" genannt) nicht dazu geeignet, eine Einschätzung zum Status der Sicherheit zu geben, vor allem wenn ein Unternehmen bisher keine anderen aktiven Massnahmen zur Stärkung der Sicherheit ergriffen hat. Insofern ist das Ergebnis eines Pentests immer im Zusammenhang zu betrachten und für sich genommen nur bedingt aussagekräftig. Ein solcher Test ist nur dann sinnvoll, wenn es darum geht, die verbliebenen Lücken in einem bereits gut abgesicherten Netzwerk zu finden und zu schliessen. Zudem ist es sehr sinnvoll, sich externen Beistand zu versichern. Das kann so aussehen, dass etwa speziell der Bereich IT-Sicherheit in die Verantwortung eines spezialisierten Anbieters übergeht. Auch wenn die IT weiterhin vollständig inhouse bleibt, so sind doch die wenigsten IT-Abteilungen darauf geschult, einen ausgewachsenen Angriff auf das eigene Netzwerk zu erkennen und entsprechend zu reagieren. Hier für den Notfall vorzusorgen ist unumgänglich.

Die eigene Handlungsfähigkeit zu erhalten, hat oberste Priorität. In diesem Zusammenhang kann sich kein Unternehmen "Single points of failure" leisten und darauf hoffen, dass eine bestimmte Konstellation schon nicht eintreten wird. Dazu gehört auch, dass im äussersten Fall eine initiale Bewältigung auch ohne externen Beistand möglich sein muss. Das ist eine der Lektionen, die die Exchange-Sicherheitslücke uns gelehrt hat. Wenn die Lücke gravierend genug ist und genug Unternehmen davon betroffen sind, kann sich jeder ausrechnen, was es bedeutet, wenn der Bedarf an IT-Notfallbetreuung plötzlich gen Himmel schiesst: Wer hier nicht vorgesorgt hat, steht allein da.