Warnstufe Rot: „Internet-Apokalypse“

Never change a winning team, sagt man im Sport. Never change a running system, sagt man in der IT – und ändert trotzdem ständig am System herum. Dabei passieren Fehler. Und zwar so regelmäßig, daß sogar die Rechtsprechung anerkannt hat: Es gibt keine fehlerfreie Software. Damit müssen wir leben. Doch vor einer Woche entdeckte man eine Sicherheitslücke, die die IT-Welt in helle Aufregung versetzt hat: Log4Shell.

Was steckt dahinter? Um nicht immer wieder das Rad neu erfinden zu müssen, verwendet man für häufig in Programmen benötigte Funktionen vorgefertigte und für den Programmierer nicht einsehbare Programmschnipsel, die in sogenannten Bibliotheken gesammelt sind. Man bindet die Schnipsel einfach ins Programm ein und spart sich damit viel Zeit und Aufwand. Einer dieser häufig verwendeten Schnipsel kann etwas tun, von dem die meisten Programmierer nichts zu wissen scheinen: Er kann sich Programmcode von woanders holen und ihn ausführen. Das ist kein Fehler. Er tut, was er soll. It’s not a bug, it’s a feature. Doch die Tragweite dieser Funktion wird erst jetzt deutlich: Man kann auf diesem Weg auch von außen Schadsoftware ins Programm schleusen, und damit in das Computersystem eindringen, auf dem das Programm läuft.

Programmierer und Hacker im Wettlauf

Nun herrscht also in den IT-Abteilungen hektische Betriebsamkeit. Wie viele Programme betroffen sind, wie oft die Schwachstelle schon ausgenutzt wurde, wie viele Hintertüren für spätere Angriffe schon installiert worden sind – darüber hat man bisher noch keinen Überblick. Ich habe selbst viele Jahre lang Computer programmiert, und will mir gar nicht vorstellen, welch einen Streß die armen Software-Leute jetzt so kurz vor Weihnachten haben. Als ich vor fast 4 Jahrzehnten in die Programmierung einstieg, war Programmieren noch eine herausfordernde Kunst. Mit neuen Programmiermethoden wurde sie zum Handwerk, das ich viele Jahre lang gern ausübte. Doch die spätere erste Berührung mit einer neuen Art von Programmiersprache – das heute weit verbreitete Java – hat mir den Spaß verdorben. Vorbei das Handwerk, jetzt fühlte es sich nach Fließbandarbeit an.

„Leider machen nicht nur Sicherheitsteams, sondern auch Hacker Überstunden.“
Rüdiger Trost, IT-Sicherheitsfirma F-Secure

Durchaus faszinierend an Java war die große Zahl der Programmschnipsel, mit denen man alle möglichen Dinge machen kann, ohne das erst mühsam programmieren zu müssen. Die Kehrseite war, daß alles ziemlich unübersichtlich wurde. Man programmierte nicht mehr, man codierte nun. Man stapelte hermetisch gekapselte Blackboxen aufeinander, ohne wirklich zu wissen, was in ihnen steckte. Das fühlte sich nicht gut an. Mir fehlte der Überblick über das, was ich tat. Wichtig war nun, daß die gestapelten Kisten irgendwie zusammenpaßten und zusammenarbeiteten.

Wenn Sie es nicht schon vorher wußten, ahnen Sie jetzt sicher: Die Sicherheitslücke Log4Shell hat mit Java zu tun, mit einer Programmschnipsel-Bibliothek namens Log4j. Nicht daß ich damals schon ahnte, daß mal so etwas passieren würde. Aber es wundert mich heute auch nicht, daß es passiert ist. Im Rückblick bin ich sehr, sehr dankbar für die Zeit in der IT, für den Einblick, den ich in diese faszinierende Branche gewonnen habe, und für das, was ich dort für meine heutige Arbeit lernte. Heute arbeite ich mit Menschen. Das ist etwas ganz anderes, und doch ähnlich. Auch mit dem Menschen ist es kompliziert. Er ist sogar ein komplexes Wesen. Was in seiner Seele vorgeht, muß aber nicht verschlossen bleiben, denn man kann ihn – anders als einen Java-Programmschnipsel – ansprechen und fragen.

Getrieben vom Kostendruck

Warum schreibe ich das alles? Ein anderer Programmierer, Kristian Köhntopp, der zur gleichen Zeit wie ich zu programmieren begann, kommentierte im IT-Portal Heise online die Sicherheitslücke. Und denkt angesichts der Lage nun über eine Karriere als Landschaftsgärtner nach.

Der Kommentar ist für Fachleute geschrieben. Doch auch Laien wird in all dem Fachchinesisch nicht entgehen, wie es um die Programmierung steht. Was ich als Feelgood Manager am Schluß mit Kopfschmerzen lese: „Wir verwenden eine moderne Architektur und agile Methoden, um die Entwicklungsgeschwindigkeit zu steigern.“ Das heißt: Moderne Programmiersprachen und beschleunigte Arbeitsweisen sollen möglichst schnell etwas Lauffähiges zustande bringen. Ob es fehlerfrei oder sicher ist, kann man in der Hektik nicht prüfen. Programmieren beschleunigen, Effizienz steigern, Kosten sparen. Aus eigener Programmiererfahrung weiß ich: Zeitdruck erzeugt Fehler. Doch Fehler nachbessern erzeugt Mehrkosten. Und nicht genug damit: Fehlerhafte Software hat bereits Menschenleben gekostet.

„Mehr Entwicklungsgeschwindigkeit macht größere Krater.“
Kristian Köhntopp

Der Spiegel berichtet, Programmbibliotheken wie Log4j würden oft von kleinen Programmierteams entwickelt, die dafür gar nicht bezahlt werden. Sie tun es neben ihrer eigentlichen Arbeit, einfach aus Spaß am Programmieren. Für große Unternehmen seien diese Bibliotheken dann eine kostengünstige Lösung. Eigentlich sei solche sogenannte Open-Source-Software sicher, weil andere Programmierer mit geeigneten Werkzeugen den Programmcode prüfen können. Aber manchmal würden eben doch Fehler übersehen. Wir sparen – koste es, was es wolle.

Agil programmieren

Wenn ich auf diesen Seiten das Wort agil benutze, meine ich damit in der Regel nicht agile Programmiermethoden, sondern die Art, wie man sinnvoll mit Komplexität umgeht. Komplexität entsteht durch Globalisierung und Digitalisierung und ist die vielleicht größte Herausforderung an unsere heutige Arbeitswelt. Hier aber geht es doch um agile Programmiermethoden. Ihre Ideen und Erfahrungen faßt das Agile Manifest zusammen, das eine Gruppe von Softwareexperten vor nunmehr 20 Jahren verfaßt hat. Sein Kern sind vier Werte:

„Individuen und Interaktionen stehen über Prozessen und Werkzeugen.
Funktionierende Software steht über einer umfassenden Dokumentation.
Zusammenarbeit mit den Kunden steht über Vertragsverhandlungen.
Reaktion auf Veränderung steht über dem Befolgen eines Plans.“
Agiles Manifest der Softwareentwicklung

Wenig bekannt ist, daß Agilität anfangs gegen das Management gerichtet war. Dessen Rolle sei bei kreativer und komplexer Arbeit eher kontraproduktiv, so einer der Unterzeichner des Manifests. Stand-up Meetings (Besprechungen im Stehen) sollten die Zeit des Informationsaustausches im Team kurz halten und damit auf das Fachliche reduzieren. Sprints sollten den Programmierern für einen definierten Zeitraum den Rücken für ungestörte Arbeit freihalten. Ein anderer Unterzeichner bezeichnete agiles Programmieren als eine Art Vertrag zwischen „den drängenden Managern und den Entwicklern, die Zeit zum Nachdenken und Entdecken brauchen“.

Nicht gehaltene Versprechen

Letzten Endes scheint die agile Revolution nicht geglückt. Sie kann ihre Versprechen nicht halten. Agile Programmiermethoden seien heute eher Mittel, die Arbeit anzutreiben. Einer der Unterzeichner des Manifests resümierte später: „Wenn ‚agile‘ Ideen schlecht umgesetzt werden, führen sie oft zu mehr Konflikten mit den Entwicklern, weniger Zeit für die Arbeit, höheren Druck und der Forderung, ‚schneller‘ zu arbeiten.“ Schlecht für die Entwickler, schlecht für die Software, schlecht fürs Unternehmen.

Kann das Feelgood Management hier etwas ausrichten? Ich fürchte nicht, solange Effizienzstreben und Kostenreduktion oberste Unternehmensziele sind. Bestenfalls kann es den Druck etwas erleichtern. Doch das ist ein Kompromiß. Er kratzt nur an der Oberfläche und ist nicht nachhaltig. Erforderlich ist ein generelles Umdenken in der Unternehmensführung (und in der Ökonomie insgesamt) – vielleicht angestoßen durch die Erfahrung, daß sich die Effizienz nicht beliebig steigern läßt. Ab einem bestimmten Punkt kommt nur noch das Gegenteil des Beabsichtigten heraus. Erweitert man den Blick, dann erkennt man ohnehin einen kommenden, vielleicht zunächst ernüchternden Paradigmenwechsel: Weg von der heute überbetonten, Effizienzwunder versprechenden Rolle des Digitalen, hin zu den unerschöpflichen Potentialen des Menschen.