Was wir aus dem Top Security Breach 2021 „Log4j“ in Automotive IT-Projekten für die Zukunft lernen können

Dieser Beitrag zeigt, was wir in IT-Projekten daraus lernen können und warum Continuous Delivery für IT-Systeme Priorität hat.

Log4j und dessen Folgen

Log4J war wahrscheinlich das prominenteste Security Thema im Jahr 2021 und natürlich war auch die Automotive Branche und ihre IT-Systeme davon betroffen. Seit dem 10.12.2021 warnte das BSI vor einer extrem kritischen Bedrohung in der Java-Bibliothek „Log4j“ und das Thema schaffte es sogar in die Tagesschau. Die Sicherheitslücke führt eventuell zur Verwundbarkeit von global mehreren Milliarden Computern. Nur wenige Tage nach Veröffentlichung wurde die Sicherheitslücke bereits kriminell ausgenutzt. Am 16. Dezember 2021 wurden mit dem Internet verbundene Systeme des belgischen Militärs über die Lücke angegriffen. Am 17. Dezember 2021 wurde die Webseite des Bundesfinanzhofs wegen einer solchen Attacke abgeschaltet. [1]

Quelle: BSI – Schwachstelle in Java Bibliothek log4j (bund.de)

„Log4j“ ist eine weit verbreitete Bibliothek für Java-Anwendungen. Hierbei handelt es sich um eine Software, die zur Umsetzung einer bestimmten Funktionalität in weitere Produkte eingebunden wird. Sie ist daher oftmals tief in der Architektur von Software-Produkten verankert. Die Bibliothek „Log4j“ stellt zum Beispiel Funktionalitäten zur Protokollierung von Programmaktivitäten zur Verfügung. Diese Protokolle dienen oft der Fehlersuche und sind deshalb in Software üblich. Da „Log4j“ diese Meldungen bislang schnell und effizient verwaltet hat, wurde die Bibliothek von vielen Systemadministratoren und Entwicklern auf der ganzen Welt in IT-Systeme eingebaut. [2]

Quelle: Log4j – Wikipedia

Durch das schnelle Nacheinander-Patchen von den IT-Systemen mit der Version 2.15, 2.16 und 2.17. konnte ein potentieller Schaden in den IT-Systemen verhindert werden.
Doch warum waren zum Beispiel OEMs davon betroffen?

Software-definierte Fahrzeuge benötigen viele IT-Systeme im Hintergrund

Die Zunahme an digitalen Geschäftsmodellen und die dazu benötigten Dienste führt auch zu einer großen IT-Infrastruktur mit vielen Softwarekomponenten (Microservices) bei OEMs. Das Software-definierte Fahrzeug verfolgt einen ganzheitlichen Ansatz, bei dem Fahrzeuge innerhalb der Grenzen ihrer Hardware kontinuierlich optimiert werden können – zum Beispiel durch die Aktualisierung von Fahrzeugfunktionen durch Over-the-Air-Updates und -Upgrades. Softwarelösungen werden damit in Zukunft zu einem entscheidenden Differenzierungsmerkmal.
Der Mehrwert des Software-definierten Fahrzeugs steigt, ähnlich wie bei einem Smartphone, mit der Anzahl der verfügbaren Anwendungen und Dienste. Im Hintergrund muss man hier jedoch beachten, dass dies eine hohe Anzahl an IT-Komponenten mit vielen externen Bibliotheken und Frameworks wie Log4j nach sich zieht.

Doch nach dem Angriff ist vor dem Angriff – was kann man aus dem Log4j Vorfall lernen?

Das Thema Log4j konnte bei den meisten Unternehmen zunächst schnell gefixt werden, doch die nächste Sicherheitslücke in einem ähnlichen kritischen Umfang wird kommen. Das ist leider in der Zukunft nicht anders zu erwarten. Die Frage stellt sich, was man aus dem Log4j Vorfall in der Zukunft lernen kann?

Deployment muss 24/7 möglich sein

Es hat sich gezeigt, dass die Fähigkeit, zeitnahe und schnelle Deployments durchzuführen, ein kritischer Aspekt bei der Bewertung eines IT-Systems ist. Mit Continuous Deployment können Entwicklungsteams Codeänderungen direkt in die Produktionsumgebung einspielen, sofern zuvor automatisierte Tests erfolgreich durchgeführt wurden. Dadurch wird sichergestellt, dass die neu hinzugefügten Elemente keine negativen Auswirkungen auf die Lauffähigkeit des Endsystems haben. Lange gab es analog zur Hardwareentwicklung sehr lange Release Zyklen (z.B. sechsmal im Jahr) mit jeweils einem abschließenden großen manuellen Deployment. Dies hat sich durch die organisatorische Einführung durch Scrum (bzw. SAFe, was die Abstimmung, Zusammenarbeit und Ausführung über zahlreiche Agile-Teams hinweg fördert) bereits in vielen IT-Komponenten in den letzten Jahren verbessert. Security Themen wie Log4j zeigen aber, dass ein kurzfristiges, möglichst automatisiertes Deployment möglich sein muss. In unserem Beispiel musste Philipp kein Deployment-Experte sein (auch wenn er das sogar ist), sondern konnte sich auf viele automatisierte Prozesse und Konfigurationen verlassen. Dies ist nicht nur in diesem Log4j ein Vorteil, sondern auch, wenn es generell um das Thema Urlaubsvertretung oder Personenwechsel in den Projekten geht.

Ende-zu-Ende-Testbarkeit und automatisierte Tests von Kundenprozessen

Das schnelle Deployment ist das eine Thema. Das andere ist das Ende-zu-Ende-Testen der Connected Car Kundenfunktionalitäten. Dabei stellt sich die Frage, wie gut zum Beispiel Fahrzeugfunktionalitäten im Backend emuliert werden können oder wie viel Automatisierung beim abtesten von Frontend Umfängen (z.B. Selenium) möglich ist. Durch den Einsatz von automatisierten Tests (z.B. Cucumber) als Teil einer Deployment Pipline kann sehr schnell eine Aussage darüber getroffen werden, ob das Deployment erfolgreich war und auf Kundenseite keine Fehlfunktionen durch das Update zu erwarten sind. Gerade, wenn ein Deployment schnell durchgeführt werden muss, erweisen sich solche automatisierten Tests als wertvoll.

Ein eingespieltes DevOps Team zahlen sich aus

Ein wesentliches Merkmal von DevOps ist, dass Entwicklungs- und Operationsteams direkt zusammenarbeiten und ihre Arbeit besser verzahnt wird, als bei herkömmlichen Entwicklungsprozessen. Somit können potenzielle Designüberlegungen oder Probleme im Bereich Operations bereits bei der Entwicklung berücksichtigt werden, während das Operationsteam unmittelbar vom Wissen über aktuelle Neuerungen profitiert. Insgesamt kommt es zu einem deutlich besseren Informationsaustausch, der genau in einem solchen Fall von Bedeutung ist und einen schnellen Fix ermöglicht.

Technische Schulden frühzeitig erkennen und reduzieren

Als Product Owner fällt die Backlog Priorisierung häufig auf sichtbare Features. Eine frühzeitige Aktualisierung von eingesetzten Frameworks ist zumeist nicht im Fokus. Deshalb macht es Sinn, regelmäßig die aktuellen Softwarestände zu prüfen und gesamtheitlich zu aktualisieren. Technische Schulden sind einer der wichtigsten Faktoren, warum in Softwareentwicklungsprojekten Meilensteine nicht oder nicht rechtzeitig erreicht werden oder es zu möglichen Security Problemen kommen kann. Ebenfalls kritisch ist es, wenn ein Update von einer Bibliotheksversion weitere Updates von anderen veralteten Bibliotheken oder externen Frameworks nach sich zieht. So geht wertvolle Zeit beim schnellen Patchen und Deployment verloren. Ein Tool wie „Renovate“ kann hier helfen, diesen Prozess zu automatisieren.

Bewertung von Einsatz von externen Bibliotheken und Frameworks

Der Einsatz von externen Bibliotheken und Frameworks ist ein Standardvorgehen in IT-Entwicklungsprojekten. Eine komplette Eigenentwicklung ist in den meisten Fällen nicht zielführend und der Einsatz von beispielsweise Open-Source-Komponenten sinnvoll. Der Fall Log4j zeigt: Basistechnologien werden oft als Open Source entwickelt. Zunächst einmal ist das gar nichts so Ungewöhnliches. Denn viele Basiskomponenten sind als Open-Source-Projekte entwickelt worden und werden in unzähligen Programmen eingesetzt. Die Software-Hersteller greifen auf solche Komponenten zurück, um nicht immer alles neu entwickeln zu müssen. Darüber hinaus hat Open-Source-Software den Vorteil, dass der Quellcode öffentlich eingesehen werden kann. Dabei können Fachleute bzw. die Community Fehler entdecken und sie korrigieren. Und dass sich in Open-Source-Software so gefährliche Lücken auftun wie jetzt, ist die große Ausnahme.
Trotzdem sollte in Zukunft bei der Auswahl der externen Bibliotheken und Frameworks das Thema Security stärker berücksichtigt werden.

Trickreich wird es bei Log4j: Hier handelt es sich ein Logging Framework, das oftmals tief in der Architektur von anderen Software-Produkten oder Bibliotheken verankert ist, wie zum Beispiel bei Spring Boot. Das Spring Framework (kurz Spring) ist ein quelloffenes Framework für die Java-Plattform, welches oft für Web-Anwendungen verwendet wird. Ziel des Spring Frameworks ist es, die Entwicklung mit Java/Java EE zu vereinfachen und gute Programmierpraktiken zu fördern. [3]

Log4j-Sicherheitslücke: Der Ruf nach Open-Source-Förderung | BR24

Murphys Law: Security Themen, die immer am Freitag oder Wochenende auftreten

Zumindest in Europa wurde das Thema Log4j am Freitagnachmittag bekannt: Die Hoffnung, dass ein kritischer IT-Security-Incident nur während den regulären Arbeitszeiten und nicht am Wochenende eintrifft, ist wünschenswert, aber nicht realistisch. Dementsprechend müssen für diese Fälle Prozesse definiert sein. Rufbereitschaft, Reaktionszeiten und Lösungszeiten sind zumeist in IT-Service-Agreements festgelegt und müssen auch eingeplant werden – auch für Komponenten, die nicht direkt als besonders sicherheitsrelevant betrachtet werden.

Log4j lässt ahnen: Nur mit dem schnellen Patchen ist es nicht getan

Kriminelle Angreifer haben Log4Shell eventuell zunächst dazu genutzt, um möglichst lautlos und unerkannt Hintertüren in bislang hoch gesicherten Bereichen zu installieren. Die eigentlichen Angriffe auf die IT-Infrastruktur durch Datenklau oder Verschlüsselungstrojaner und anschließenden Erpressungen könnte erst noch bevorstehen. Typischerweise erkunden Angreifer ihr Opfer erst ausgiebig, bevor sie zuschlagen. Deshalb ist es wichtig, fortlaufend auf kleinste Anzeichen zu achten. Jetzt im Frühjahr, wo wieder der Alltag eingekehrt und etwas Gras über Log4j gewachsen ist, könnte die nächste heiße Phase beginnen. [4] Kleine Ursache, Super-GAU | c’t | Heise Magazine

Der Anteil der Softwareentwicklung beim Thema Connected Car steigt und damit auch die potentiellen IT-Risiken. Continuous Delivery unterstützt Automotive OEMs dabei, agile Softwareentwicklung konsequent umzusetzen und die Möglichkeit, ihren Kundinnen und Kunden ständig verbesserte Services zu liefern, aber auch schnell auf kritische (Sicherheits-)Themen zu reagieren.
doubleSlash setzt deswegen in seinen Produkten und in Kundenprojekten auf Continious Delivery. Auch führen wir Migrationsprojekte durch, wo ältere Software Architekturen Continious Delivery fähig gemacht werden.
Du möchtest bei doubleSlash in einem DevOps Team arbeiten? Dann kannst du dich hier bewerben: DevOps Engineer (m/w/d) in Friedrichshafen (doubleslash.de)

Mehr über Java-Programmierung erfahren

Quellen: