In einem Artikel des c’t Magazins werden faule Programmierer in Dantes Terrasse Nummer vier des Fegefeuers gestoßen, weil sie zwei bis drei Zeilen Code sparen wollten. Ohne wie der Autor des Beitrags an dieser Stelle die Kenntnis von Dantes Göttlicher Komödie nachzuweisen, scheint die Konklusion zu Log4J dennoch gewagt.
Kein Freitag wie jeder andere
Den 10. Dezember 2021 wird kein IT-Experte so schnell vergessen. Es trat ein Softwarefehler ins Rampenlicht der IT-Welt, wie es ihn glücklicherweise nur selten gibt. Millionen von Servern kleiner und großer Firmen ließen sich damit theoretisch aus der Ferne komplett übernehmen. Der Begriff Log4J, den viele bis dato nicht kannten, führte in der operativen IT als auch im Management zu Schweißperlen, wie man sie seit Y2K nicht mehr gesehen hat.
Die meisten Leser kennen die Vorgeschichte, hier trotzdem die Zusammenfassung:
Am 24.11.2021 schrieb ein Entwickler von Alibaba an die Apache Software Foundation und berichtete über den Bug. Panik setzte ein. Ein Betreuer der Software Gary Gregory dachte nur: „Oh Sch… Wir waren überrascht. Nicht, weil es ein Sicherheitsproblem gab, sondern ob seines Ausmaßes.“ Log4J ist eine kostenlose Lösung, die im Hintergrund von Java-Anwendungen protokolliert. Da diese Komponente jedoch so tief im Kern vergraben ist, setzen Unmengen von Applikationen diese ein und sind damit für Angriffe anfällig. Diese Applikation wurde von Entwicklern in Ihrer Freizeit entwickelt und kostenlos als Open Source zur Verfügung gestellt.
Danach versuchten die Experten die Lücke zu stopfen, das ging jedoch nicht so schnell, wie die Lücke geleakt wurde. Mindestens seitdem 01.12.2021 nutzten Hacker dann die Lücke (diese bestand bereits seit 2013). Der Bug wurde spätestens durch das BSI offiziell und innerhalb weniger Stunden stieg die Anzahl der Attacken von wenigen Tausend in den Millionenbereich. Hacker machen gerne Überstunden.
Einfluss auf Versicherungen und Softwarehersteller
Viele Versicherungen und Softwarehersteller waren durch Angriffe betroffen. Es wurden dabei Attacken auf Häuser wie die R+V versucht. Manche Versicherungen wie Signal Iduna, Allianz oder Debeka haben vorsorglich Teile ihrer IT-Struktur abgeschaltet. Versicherungen wie Zurich Deutschland oder Hanse Merkur gingen in erhöhte Alarmbereitschaft. Auch die Gothaer steuerte mithilfe Ihres ISM und einer Task-Force durch das Geschehen. Die Debeka schaltete kurzfristig Ihre Homepage ab. Selbst die großen Player wie Apple, Google oder Amazon blieben nicht verschont. Und auch wir als adesso bildeten keine Ausnahme und haben manche Services kurzfristig sicherheitshalber eingeschränkt. Cyberversicherer befürchteten gigantische Schadenssummen rund um diesen Schwarzen Freitag. Die Anfragen bei IT-Security-Experten gingen durch die Decke. Geld war nebensächlich, Sicherheit wurde benötigt.
Die gefürchtete IT-Apokalypse trat glücklicherweise nicht ein. Viele VUs und Softwarehersteller konnten mithilfe eines funktionierendem ISM, Notfallplänen und wahrscheinlich auch vielen Überstunden das Schlimmste verhindern. Obwohl anfänglich erwartet wurde, dass die großen Attacken erst zeitversetzt nach Übernahme der Server stattfinden würden, sind bis dato wenig Schäden bekannt.
Warum ist es aber möglich, dass so außerordentlich wichtiger Programmcode in der Verantwortung von wenigen ehrenamtlichen Entwicklern liegt? Dadurch können viele Software-Hersteller auf diese Komponenten zurückgreifen und müssen nicht immer von vorne entwickeln. Hier können viele Experten den Code überprüfen. Das geht bei proprietär entwickelter Software nicht so einfach. Open-Source-Komponenten sind grundsätzlich die richtige Entscheidung. Das Problem bei Open-Source-Komponenten ist häufig die Finanzierung. Die Log4J-Entwickler haben beispielsweise hauptberuflich in Vollzeit gearbeitet und wurden für die Pflege von Log4J nicht bezahlt:
- Unternehmen sollten Verträge mit Open-Source-Entwicklern abschließen, damit diese ihre Arbeit auch bezahlt bekommen.
- Open-Source-Teams sollen nicht mehr als 3–4 Projekte betreuen.
- Auf staatlicher Ebene sollten Open-Source-Entwicklungen unterstützt werden, da staatliche ebenso wie private Institutionen betroffen waren. Hierzu gibt es eine Machbarkeitsstudie von der NGO Open Knowledge Foundation (OKFN), welche „die Entwicklung, Verbesserung und Instandhaltung von Offenen Digitalen Basistechnologien“ unterstützen soll.
Fazit
Es geht also nicht um faule Programmierer, die das Fegefeuer verdient haben, sondern die Unternehmen, der Staat und die Politik müssen sich überlegen, was Ihnen IT-Sicherheit und Resilienz wert ist.
Politisch stehen die Chancen dafür gar nicht so schlecht, denn „die Ampel“ hat sich in ihrem Koalitionsvertrag an verschiedenen Stellen zum Open-Source-Gedanken bekannt. Zum einen soll es offene Standards für öffentliche IT-Projekte geben. Auch „Entwicklungsaufträge werden in der Regel als Open Source beauftragt“ und die dabei entstehende Software soll grundsätzlich öffentlich gemacht werden. Ebenfalls findet sich das Schlagwort der „digitalen Souveränität“ in dem Vertrag wieder, sie soll unter anderem durch das Recht auf Interoperabilität und Portabilität sowie das Setzen auf offene Standards, Open Source und europäische Ökosysteme, etwa bei 5G oder KI, erreicht werden.
Unabhängig davon ist es für die Softwarehersteller und VUs wichtig, über ein funktionierendes ISM mit klaren Prozessen, Verantwortlichkeiten, Kommunikationsketten, Eskalationsregeln und entsprechender Kundenkommunikation zu verfügen. Entscheidend ist nicht, ob Probleme auftreten, sondern wie mit diesen professionell und lösungsorientiert umgegangen wird. Trotzdem, ich weiß nicht, wie es Ihnen damit geht: Den nächsten Exploit dieser Größenordnung bitte erst wieder in 20 Jahren.
Sie stehen vor der Herausforderung, hochindividuelle Bestands- und Leistungssysteme zu standardisieren und resilient zu machen? Sie benötigen einen Softwarehersteller mit bewährten ISM-Prozessen? Wir stehen Ihnen mit unserem Experten tatkräftig zur Seite und freuen uns darauf, diese Herausforderung gemeinsam mit Ihnen in Partnerschaft anzugehen! Kontaktieren Sie gerne unseren Experten Karsten Schmitt, Head of Business Development.
