  | |  | Guten Tag,
|
| der erste Monat des neuen Jahres liegt schon hinter uns, die ersten Vorsätze sind vielleicht schon umgesetzt oder wieder vergessen. Und wie jedes Jahr bleibt die Erkenntnis, dass eine Jahreszahl allein noch gar nichts ändert...
Das Ende des alten Jahres war turbulent für uns - Mitte Dezember wurde eine Sicherheitslücke einer Standard-Bibliothek der Programmiersprache JAVA publik ("Log4Shell") - und das Internet stand Kopf. Zeitweise waren Apple, Twitter, Amazon betroffen - und hunderttausende Server und Anwendungen mehr.
Die Lücke war potenziell so kritisch, dass wir in einer konzertierten Aktion binnen weniger Tage über 800 Server und Appliktionen aktualisiert haben. Heute teilen wir unsere Learnings und ein paar Gedanken dazu.
Viel Spaß beim Lesen!
| |
| |
|
| |
|
|
| Worum ging's?
Log4j ist ein Framework zum Loggen von Anwendungsmeldungen in Java. Am 12. Dezember 2021 wurde eine kritische Sicherheitslücke bekannt, welche die aktuelle Version der Bibliothek und einige Vorgängerversionen betraf (mehr Infos auf der Website des BSI).
Kittelberger setzt in vielen Applikationen auf JAVA als Programmiersprache - daher war schnell klar, dass hier für uns Handlungsbedarf besteht.
Was haben wir gemacht?
Nach einigen Sofort-Maßnahmen auf den zentralen Firewall-Systemen haben wir den ersten Tag komplett damit verbracht, die nötige Automatisierung für das Inventarisieren und Austauschen der Software-Bibliotheken auf den Weg zu bringen: Bei der Menge an Anwendungen und Servern war klar, dass eine manuelle Umsetzung überhaupt keinen Sinn macht. Gleichzeitig haben wir eine Priorisierung der Anwendungen erarbeitet, auf deren Basis wir einige Applikationen direkt offline genommen oder hinter IP-Walls versteckt haben, um unnötigen Risiken zu minimieren. Im Anschluss haben unsere Entwickler-Teams jeweils koordiniert die Server und Anwendungen aktualisiert - und wo nötig auch entsprechend angepasst.
Natürlich sind uns dabei einige Vorkehrungen zugute gekommen, die wir schon vorab getroffen hatten, auch im Rahmen der Zertifizierung nach ISO27001.
Hier einige Learnings, die wir teilen können:
- Automatisierung! Inventarisierung, Rollout und Update: Ohne einen hohen Grad an Automatisierung ist auf Bedrohungen dieser Größenordnung kaum angemessen zu reagieren. Idealerweise sind Software-Verteilung, Konfiguration und entsprechende Befehlsketten so schnell im laufenden Betrieb anpassbar. Noch besser: Idealerweise sind Build-Tools, automatisierte Tests, statische Codeanalyse und Vulnerability-Scanner als Teil der CI-Pipelines inklusive Software-Verteilung implementiert. Der hohe Automatisierungsgrad, den wir gleich zu Anfang sichergestellt haben, hat uns übrigens dann mehrfach geholfen: Nach Version 2.15 folgte innerhalb kurzer Zeit 2.16 und 2.17.1 - hier waren wir in der Folge besser vorbereitet.
- Organisation! Stay calm and build a taskforce: Im ersten Schritt haben wir eine Taskforce gebildet, in die alle relevanten Abteilungen, die Geschäftsführung und die Kundenbetreuung eingebunden waren. Auf die Art haben wir jeweils kurzfristig Prioritäten gesetzt, auf Neuigkeiten reagiert und die Abstimmung mit unseren Kunden und Lieferanten organisiert.
- Communication is key! Zunächst mal ist es in Fällen wie diesen gut, wenn die "Laufwege" klar sind. Wer ist für welche Applikation verantwortlich? Wer ist beim Kunden wann erreichbar? Weil diese Dinge schon vorbereitet waren, konnten wir uns direkt auf die Kommunikation konzentrieren und unsere Kunden informieren. Und dabei gilt dann: Offen und häufig! In der ersten Woche nach Bekanntwerden von Log4J haben wir so hunderte Kunden-Ansprechpartner mehrfach informiert. Zusätzlich zu den allgemeinen Informationen unseres Unternehmens gab es Infos an die Kundenbetreuer, die diese dann jeweils individuell weiter gegeben haben.
Dass die Gefahr real war, haben übrigens nicht nur die Neuigkeiten im Web bestätigt - sondern auch das Reporting unserer internen Security Systeme: wir hatten stellenweise etwa 30.000 Angriffe, die versucht haben die Schwachstelle in Log4J auszunutzen. Pro Stunde.
Und sonst?
Man darf gespannt sein, wie sich das Thema auf die Software-Landschaft "da draußen" auswirken wird. Gut möglich, dass die großen Software-Konzerne mehr investieren, um die Sicherheit von de-facto-Standards wie Log4J zu erhöhen. Ziemlich sicher: Dass es nicht einfacher werden wird, Anwendungslandschaften sicher und aktuell zu halten. Auch klar: Wir bleiben weiter am Ball, was Automatisierung und Optimierung betrifft!
Noch ein Hinweis: Natürlich können wir an dieser Stelle nicht im Detail auf die eingesetzten Tools und andere sicherheitsrelevante Themen eingehen. Bei Fragen oder Interesse kontaktieren Sie uns gerne direkt!
|
|
|
|
| |
|
| | Schon gewusst? | |
|
| Unsere Zertifizierung nach ISO27001 erfolgte bereits Anfang 2020.
|
|
|
|
| |
| | Hat Dir der Newsletter gefallen? | | Über Feedback in Form von Lob und Kritik freuen wir uns. Schreibe uns daher gerne eine Nachricht an newsletter@kittelberger.de und teile Deine Fragen und Anregungen mit uns!
|
|
|
|
| |
| | Wir sind auch hier erreichbar: | |
|
| |
| |
|
| Kittelberger media solutions GmbH
Bayernstraße 8
72768 Reutlingen
Telefon: +49 (7121) 6289-0
E-Mail: info@kittelberger.de
|
Geschäftsführer:
Jürgen Frücht,
Jan Kittelberger,
Hartmut Kittelberger
Handelsregister:
Amtsgericht Stuttgart, HRB 350819
|
|
| |
|
|
|
