Schnelles und gezieltes Handeln waren erfolgskritisch, denn durch die „Log4Shell“ getaufte Schwachstelle boten sich dem Angreifer unterschiedlichste Einfallstore, um einzelne Systeme zu kompromittieren, Daten zu manipulieren oder ganze IT-Infrastrukturen zu kapern.
Unser Blogartikel: Was wir aus der log4j Sicherheitslücke lernen können! betrachtet Ursachen und Auswirkungen der Schwachstelle etwas tiefer und leitet drei grundlegende Maßnahmen ab, die inzwischen bei jeder IT-Organisation angekommen sein sollten.
Trotzdem läuft in kaum einer Organisation die Abwehr einer derart breit gestreuten Bedrohung „optimal“ ab. Aber auch bei enger begrenzten Vorfällen, die zur Betriebsstörung eines IT-Systems geführt haben („Incident“) oder auch nur hätten führen können, sollten „lernende“ Organisationen überlegen, ob daraus Verbesserungsmaßnahmen für die Zukunft abzuleiten sind. Im Krisenfall zahlt es sich aus, wenn die notwendigen Prozesse über Jahre hinweg ständig optimiert worden sind. Dabei ist nichts ist ärgerlicher, als einem Problem zum zweiten Mal zum Opfer zu fallen.
Hier setzen Post Mortems an: Sie sind ein geeignetes Analyseformat für IT-Organisationen mit einer Lern-Kultur, um den Grundursachen von Störungen als solchen, aber auch Problemen bei der raschen Beseitigung von Störungen auf die Spur zu kommen.
In diesem Beitrag stellen wir vor, was zu einem erfolgreichen Post Mortem bei iteratec alles dazu gehört.
- Was ist ein "Post Mortem"?
- Regeln für ein Post-Mortem
- Wie läuft ein Post-Mortem ab?
1 Was ist vorgefallen?
2 Event Storming
3 Root Causes und Maßnahmen
4 Follow-up vereinbaren
5 Post-Mortem veröffentlichen - Fazit
1. Was ist ein "Post Mortem"?
"Nach dem Tod“, „Leichenschau“ – ein Post Mortem ist im Kern ein zweistündiges Meetingformat zur rückblickenden Analyse einer Betriebsstörung: Wie konnte es überhaupt dazu kommen? Wie können wir dies für die Zukunft verhindern? An welchen Stellen (und wie!) wollen wir die Prozesse zu Störungsbehebung verbessern?
Dazu kommen Betroffene aus Infrastruktur/Betrieb, Entwicklung und Security möglichst rasch nach der Störung (Tage, nicht Wochen) zusammen und nähern sich Stück für Stück den wirklichen, tiefen Ursachen des Problems („Root Causes“) und erarbeiten Maßnahmen, um diese zukünftig als Störungsursachen auszuschließen.
2. Regeln für ein Post-Mortem
Jedes gut moderierte Meeting folgt ein paar einfachen Umgangsregeln; so auch ein Post Mortem. Und auch hier sollte die Moderation zu Beginn explizit auf die Regeln hinweisen, selbst wenn sie meistens aus „normalen“ Retrospektiven (oder auch „nur“ täglichem wertschätzendem Umgang miteinander) wohlvertraut sind.
- Im Post Mortem gilt die „Prime Directive“ einer Retrospektive, dass jeder zu jederzeit mit guter Absicht das getan hat, was er in der Situation für richtig und wichtig erachtete.
- Aber anders als bei Team-Retrospektiven, wie wir sie z.B. aus Scrum kennen, bleiben die Ergebnisse nicht im Raum der Teilnehmer. „Anti-Vegas“: Das Post-Mortem-Protokoll und seine Erkenntnisse sollen in der Organisation verbreitet werden, um den Lerneffekt zu maximieren.
- Fehlerursachen (und damit zu reparieren) sind immer kaputte Systeme oder Prozesse – nie die Menschen, die sie erstellen oder ausführen: You can’t fix people ...
Der letzte Punkt führt gelegentlich zu Irritationen und ist deshalb ein Beispiel wert: Auch selbstkritische Äußerungen wie „Da hätte ich Diesunddas machen sollen, habe ich aber nicht dran gedacht.“ beschreiben nie die Grundursache, sondern nur ein Symptom. Wie konnte es denn passieren, dass jemand in einem Notfall etwas Wichtiges vergisst? Das ist nur menschlich und deshalb nie auszuschließen.
Die Ursache ist dann aber darin zu suchen, dass wir für den Fall nicht ausreichend vorbereitet waren, z.B. keine Checkliste vorliegt, an der sich die Bearbeiter hätten orientieren können. Und so hat man auch gleich eine mögliche Maßnahme identifiziert, solch einen Fall künftig zuverlässiger zu behandeln.
Diese Einstellung ist ein kritischer Erfolgsfaktor in jedem Post Mortem: Die Ursachenforschung über die konkreten (Nicht-)Aktivtäten der handelnden Personen hinaus auf die unterliegenden Abläufe in der Organisation fokussieren!
3. Wie läuft ein Post Mortem ab?
Ein Post Mortem hangelt sich bei iteratec an einer festen Agenda mit einem intensiv vorbreiteten Protokollentwurf im Wiki entlang. Alle Teilnehmer sehen das Protokoll über das gesamte Meeting hinweg entstehen und können und sollen es ergänzen.
Auch deswegen ist eine stringente Moderation erforderlich, damit die Zeit optimal eingesetzt ist. Zwei Stunden sind bei komplexeren Themen sehr knapp bemessen. Der Moderator kommt immer aus einem kleinen Pool von Kollegen, so dass sich auch hier ein Lerneffekt in der Moderation von Post Mortems ausbildet.
1. Was ist vorgefallen?
Wir reden wirklich alle über das gleiche Thema, oder? Auch im Post Mortem sollte dies zu Beginn ganz kurz sichergestellt werden. Im vorbereiteten Protokoll ist der Incident kurz beschrieben und der Verweis ins Ticketsystem enthalten. Beides gehen wir im Termin rasch durch und setzen so den gemeinsamen Rahmen für das Event Storming.
2. Event Storming
Grundlage für alle weiteren Schritte ist die gemeinsame Sicht auf den zeitlichen Ablauf der Störung und ihrer Behebung. Jeder Teilnehmer trägt in einer chronologisch sortierten Tabelle alle bekannten Ereignisse ein, die mit der Störung im Zusammenhang stehen.
Dies umfasst nicht nur persönliche Wahrnehmungen („Alarmierung über Security-Mailing-Liste erhalten“) und Aktivitäten („Notfallplan aktiviert“, „System xyz aus dem Internetzugriff ins VPN verlegt“, …).
Auch ggf. länger zurückliegende oder „generische“ Ereignisse können wichtig sein: Wir hatten das Log4Shell-Problem schließlich nur, weil wir Log4J in hunderten Entwicklungsprojekten eingesetzt haben und einsetzen sowie Java-basierte Produkte auch von Dritten betreiben. Diese Ursache liegt schon viele Jahre zurück und ist nicht konkret an einem Datum festzumachen.
Wie man sofort sieht: Beim Event Storming identifizieren wir bereits einige mögliche Root Causes und erste Vorschläge für Maßnahmen. Nicht jede mögliche Maßnahme schafft es aber bis auf die Maßnahmenliste: Auf Log4J ab sofort zu verzichten oder Java-basierte Produkte abzuschalten, über die HR unsere Gehälter anweist, hatte niemand vorgeschlagen …
Das Event Storming nimmt zumeist den größten Teil der Zeit des Post Mortems ein, weil dabei auch viel „Tipparbeit“ und gegenseitiges Vorstellen durch die Teilnehmer gefragt ist. Deshalb ist es Aufgabe des Moderators, die Teilnehmer zu ermuntern, „ihre“ Ereignisse bereits in der Vorbereitung auf den Termin in den Protokollentwurf einzutragen. Dies beschleunigt das Event Storming spürbar. Bei iteratec wird mitunter bereits während der Behebung einer Störung, die offensichtlich „Post-Mortem-würdig“ ist, ein Protokoll vorbereitet und das Event Storming nebenbei befüllt.
3. Root Causes und Maßnahmen
Der entscheidende Schritt des Post Mortems ist jetzt, für alle Ereignisse im Event Storming, die auf die Störungsursachen einzahlen oder die Behebung der Störung gebremst haben, die Grundursachen zu identifizieren und ggf. Gegenmaßnahmen vorzuschlagen. Beispiele:
- Die Kommunikation der Log4Shell-Bedrohung ging durcheinander, weil auch Kollegen außerhalb des Security-Teams unabgestimmt Maßnahmen in internen Channels vorgeschlagen haben? Das geht besser: Wir nehmen in den Notfallplan in unserem Information Security Management System (ISMS) auf, dass wir einen separaten Channel je Vorfall eröffnen, in den wir sachdienliche Hinweise der Kollegen einladen. Diesen Channel muss aber nicht halb iteratec mitlesen, um up-to-date zu bleiben. Dafür reicht es, den zentralen Security-Channel zu verfolgen, in dem ausschließlich kompakte, gesicherte Informationen aus dem Security War Room veröffentlicht werden.
- Wir haben nicht für jedes Projekt und jedes Produkt ein Inventar, welche Libraries diese einsetzen? Dieses zu pflegen wäre für uns unrealistisch aufwändig und vermutlich nie qualitativ ausreichend. Aber wir haben mit unserer secureCodeBox ein Tool an Bord, das Security-Schwachstellen finden kann. Wir haben die secureCodeBox auch für die Suche nach Log4Shell-Schwachstellen angepasst, das hat nur recht lange gedauert. Wenn wir hierfür eine Anleitung erstellen, dank der wir sehr rasch auf eine spezifische neue Schwachstelle in der internen Infrastruktur scannen können, sind wir nächstes Mal viel schneller.
Diese und andere Maßnahmen haben wir im Post Mortem zu Log4Shell abgeleitet. Wie in jedem Meeting gilt aber auch hier: Keine Maßnahmen beschließen, die die Anwesenden nicht eigenverantwortlich umsetzen können! Dann lieber einen Schritt dazwischen vereinbaren, also z.B. die Maßnahme aufnehmen, bei der Geschäftsführung eine Freigabe für eine Aktivität zu erwirken, wenn diese den Rahmen der Eigenverantwortung sprengt.
4. Follow-up vereinbaren
Maßnahmen sind nur wertvoll, wenn sie auch umgesetzt werden. Das ist im Projektalltag nicht immer so leicht unterzubringen. Manchmal ändert sich auch der Blickwinkel auf Maßnahmen oder es finden sich im Nachgang andere, effektivere Aktivitäten.
Daher gehört zum Post-Mortem-Prozess auch ein Follow-up-Termin; oft genug auch ein zweiter ...
Die Runde kommt nochmals kurz zusammen und geht über die Maßnahmen. Dazu haben die Maßnahmen-Kümmerer die zugehörigen Aufgaben-Tickets oder Stories zwischenzeitlich im Protokoll vermerkt. So können wir rasch abgeschlossene und offene Maßnahmen erkennen. Wir berichten ggf. kurz über umgesetzte Maßnahmen und diskutieren offene Maßnahmen und wie wir damit umgehen. Niedrig priorisierte Maßnahmen können dabei auch dem schlichten Zeitmangel zum Opfer fallen; das kennen wir alle aus jedem Projekt.
5. Post-Mortem veröffentlichen
Nach dem Post Mortem-Termin muss das Protokoll finalisiert und veröffentlicht werden. Eine kurze Zusammenfassung der wichtigsten Erkenntnisse dient als „Teaser“ für die unbeteiligten Kollegen und wird in relevante Regeltermine getragen: Lohnt es sich hineinzuschauen? Kann ich hier etwas lernen?
4. Fazit
Das Post Mortem ist ein Werkzeug, um die Root Causes zu ermitteln, die zu einer Störung geführt oder die Beseitigung einer Störung behindert haben. Ziel ist die Ableitung zielgerichteter Maßnahmen, um Ausfälle vergleichbarer Natur in Zukunft zu verhindern. Konsequent durchgeführte Post Mortems bieten damit einen formalisierten, aber leichtgewichtigen Lernprozess für Organisationen, die IT-Infrastruktur betreiben.
Denn die nächste Störung, die nächste kritische Security-Schwachstelle kommt bestimmt!
iteratec konnte bei der Log4Spring-Schwachstelle in Spring Boot im März 2022 auch direkt von den Maßnahmen profitieren, die aus dem Post Mortem nach Log4Shell umgesetzt wurden.
Noch Fragen?
Sie möchten das Werkzeug „Post Mortem“ in Ihrem Unternehmen ausprobieren? Unser Kollege Dr. Martin Schönhoff hat jahrelange Erfahrungen mit Post Mortems und hat bei iteratec die Post Mortems zu den Log4Shell- und Spring4Shell-Schwachstellen moderiert. Gerne unterstützt er unsere Kunden bei der Durchführung ihrer eigenen Analysen.