Der Post-Incident-Review ist die Phase, die nach jedem Vorfall im Prozess steht und in der Praxis am häufigsten ausfällt. Die Systeme laufen wieder, alle sind müde, das Tagesgeschäft hat sich aufgestaut, und die Sitzung, in der die Organisation aus dem Vorfall lernen würde, wird verschoben und dann vergessen. Das Ergebnis ist der zweite Vorfall durch dieselbe Lücke, oft innerhalb eines Jahres. Dieser Beitrag beschreibt, wann und mit wem der Review stattfindet, wie er abläuft, ohne zur Schuldzuweisung zu werden, was in den Bericht gehört, wie aus Erkenntnissen Erkennungsregeln werden und woran Reviews scheitern.
Warum Lessons Learned ausfallen
Drei Gründe kommen fast immer zusammen. Erschöpfung: Nach zwei Wochen Vorfall will niemand noch einmal jede Stunde durchgehen. Angst: Wer den Klick auf den Anhang gemacht oder den Alarm geschlossen hat, fürchtet die Sitzung, und Vorgesetzte fürchten die Frage, warum die Kontrolle fehlte, die sie vor zwei Jahren abgelehnt haben. Und fehlende Verankerung: Der Review steht als letzte Phase im Incident-Response-Prozess, aber niemand hat einen Termin, einen Moderator und eine Vorlage dafür. Der erste Grund löst sich mit dem richtigen Zeitpunkt, der zweite mit der richtigen Haltung, der dritte mit dem Incident-Response-Plan, in dem der Review als Pflichtschritt mit Frist steht.
Wann und mit wem
Der Review findet ein bis zwei Wochen nach Abschluss des Vorfalls statt: spät genug, dass Zeitlinie und Ursache feststehen und niemand mehr im Krisenmodus ist, früh genug, dass die Erinnerung noch stimmt. Bei großen Vorfällen hilft ein kurzer erster Durchgang direkt nach der Eindämmung, in dem nur festgehalten wird, was in den ersten Stunden gefehlt hat, weil genau diese Details nach zwei Wochen verschwommen sind. Teilnehmer sind alle, die eine Rolle hatten: Incident Lead, Analysten, IT-Betrieb, Kommunikation, Datenschutz, Recht, und ein Vertreter der Geschäftsführung, damit die Maßnahmen, die Geld kosten, am Tisch entschieden werden statt später per Antrag zu versanden. Moderiert wird von jemandem, der den Vorfall nicht geführt hat.
Die Haltung: Ursachen statt Schuldige
Die Softwarebranche hat für diese Sitzungen einen Begriff geprägt, den die Sicherheit übernehmen sollte: der schuldfreie Postmortem, wie ihn Google in seinem Handbuch zum Site Reliability Engineering beschreibt. Die Annahme dahinter ist nicht, dass niemand Fehler macht, sondern dass Menschen unter den gegebenen Umständen vernünftig gehandelt haben und die Umstände das eigentliche Untersuchungsobjekt sind. Der Analyst hat den Alarm geschlossen, weil dieselbe Regel in der Woche 200 Fehlalarme erzeugt hatte. Die Mitarbeiterin hat den Anhang geöffnet, weil er von einem echten Lieferanten mit echter Signatur kam und Makros im Unternehmen erlaubt waren. Wer an dieser Stelle einen Schuldigen benennt, bekommt beim nächsten Vorfall keine ehrlichen Aussagen mehr, und ohne ehrliche Aussagen gibt es keine Zeitlinie. „Menschliches Versagen“ ist im Review keine zulässige Ursache, sondern der Hinweis, dass die Analyse noch nicht fertig ist.
Der Ablauf der Sitzung
- Zeitlinie durchgehen. Vom ersten Ereignis, das der Angreifer erzeugt hat, bis zur Wiederherstellung, mit Zeitstempeln aus dem Vorfallprotokoll und den Logs. An jedem Punkt die Frage: Was war zu diesem Zeitpunkt bekannt, und was wurde entschieden? Die Zeitlinie ist das Gerüst für alles andere; ohne sie diskutiert die Runde Erinnerungen.
- Was gut lief. Zuerst, und ernst gemeint. Was hat funktioniert, welche Kontrolle hat gegriffen, welche Entscheidung war richtig? Das ist die Liste dessen, was beim nächsten Mal nicht geopfert werden darf, und sie verändert die Stimmung im Raum.
- Was nicht lief. Wo wurde Zeit verloren, welche Information fehlte, welche Kontrolle hat versagt, wo wurde über Kanäle kommuniziert, die es nicht hätten sein dürfen?
- Wo Glück im Spiel war. Die unbequemste und wertvollste Frage. Der Angreifer hat das Backup-System übersehen. Ein Mitarbeiter war zufällig früh im Büro. Alles, was durch Zufall gut ausging, ist beim nächsten Mal ein Schaden.
- Ursache und beitragende Faktoren. Die Ursache ist die Lücke, durch die der Angreifer kam. Die beitragenden Faktoren sind das, was den Vorfall größer gemacht hat als nötig: fehlende Segmentierung, kein MFA, eine Regel ohne Tuning, ein Playbook, das niemand kannte. Die Technik der fünf Warum hilft, solange man bei der Organisation ankommt und nicht bei einer Person.
- Maßnahmen. Konkret, mit Verantwortlichem und Termin. „Awareness verbessern“ ist keine Maßnahme; „Makros aus dem Internet per Richtlinie blockieren bis Ende des Monats, Verantwortlich: Client-Team“ ist eine.
Was in den Bericht gehört
| Abschnitt | Inhalt |
|---|---|
| Zusammenfassung | Fünf Sätze für die Geschäftsführung: Was ist passiert, was war der Schaden, was wird geändert. |
| Zeitlinie | Angreiferaktivität und Reaktion nebeneinander, mit Zeitstempeln und Quellen. |
| Auswirkung | Betroffene Systeme, Daten, Geschäftsprozesse, Ausfallzeit, Kosten soweit bekannt. |
| Ursache und beitragende Faktoren | Einstiegspunkt, ausgenutzte Schwächen, Verstärker. |
| Erkennung und Reaktion | Wann hätte der Angriff erkannt werden können, wann wurde er erkannt, wie lange bis zur Eindämmung. Die Differenz ist die Kennzahl, an der sich Verbesserung messen lässt. |
| Techniken | Die beobachteten Angriffstechniken nach ATT&CK, mit Vermerk, welche erkannt wurden und welche nicht. |
| Maßnahmen | Liste mit Verantwortlichem, Termin und Status. Getrennt nach kurzfristig, mittelfristig, strategisch. |
| Meldungen und Kommunikation | Was an wen gemeldet wurde, wann, und ob Fristen eingehalten wurden. |
Für Organisationen unter NIS2 deckt sich dieser Bericht in weiten Teilen mit dem Abschlussbericht, der einen Monat nach der Folgemeldung an das BSI geht. Wer den Review sauber macht, hat den Abschlussbericht fast fertig; die Einzelheiten stehen im Beitrag zu den Meldepflichten.
Von der Erkenntnis zur Erkennung
Der Abschnitt zu den Techniken ist der wertvollste Teil des Reviews für das Blue Team, und er wird am häufigsten übersprungen. Jede beobachtete Technik, die nicht erkannt wurde, ist eine Aufgabe für das Detection Engineering: Welche Logquelle hätte sie gezeigt, welche Regel hätte gegriffen? Die Antwort wird zur Sigma-Regel, die Regel wird in einer Purple-Team-Übung mit derselben Technik getestet, und die Abdeckungskarte bekommt einen Eintrag. Erst dann ist der Vorfall wirklich abgeschlossen. Ein Review, der mit „wir schulen die Mitarbeiter“ endet, hat die Erkennung nicht verbessert; ein Review, der drei neue Regeln und eine neue Logquelle hinterlässt, hat den nächsten Angreifer schon behindert. In der Cyber Kill Chain gesprochen: Für jede Phase, die der Angreifer unbemerkt durchlaufen hat, entsteht eine Kontrolle.
Maßnahmen nachverfolgen
Der Unterschied zwischen einem Bericht und einer Verbesserung ist die Nachverfolgung. Maßnahmen aus dem Review landen im selben System wie andere Projekte, mit Verantwortlichem, Termin und einem monatlichen Blick darauf, bis sie erledigt sind. Wer nach sechs Monaten prüft, welche Maßnahmen aus den letzten drei Reviews umgesetzt wurden, weiß, ob die Organisation lernt oder dokumentiert. Die Kennzahl dafür ist einfach: Anteil der Maßnahmen, die zum Termin erledigt waren. Und die Frage für den nächsten Review: Ist der Vorfall durch eine Lücke passiert, die in einem früheren Review schon als Maßnahme stand? Wenn ja, ist das der eigentliche Befund.
Woran Reviews scheitern
- Zu spät oder nie. Ohne Termin im Plan verdrängt das Tagesgeschäft den Review.
- Schuldzuweisung. Einmal, und die Runde liefert beim nächsten Vorfall nur noch das, was sich sicher sagen lässt.
- Keine Zeitlinie. Die Sitzung wird zur Diskussion über Erinnerungen. Das Vorfallprotokoll aus dem Vorfall ist die Grundlage; wer keins geführt hat, lernt das als erste Maßnahme.
- Maßnahmen ohne Verantwortliche. „Wir sollten“ ist keine Zuordnung.
- Der Bericht im Ordner. Ein PDF, das niemand liest, verändert nichts. Die Zusammenfassung geht an die Geschäftsführung, die Techniken an das Detection Engineering, die Maßnahmen ins Projektsystem, und eine anonymisierte Kurzfassung an die Belegschaft, damit die Meldebereitschaft steigt statt fällt.
- Nur nach großen Vorfällen. Die kleinen Vorfälle und die Beinahe-Vorfälle, bei denen die Kontrolle gerade noch gegriffen hat, sind die günstigste Lernquelle, die es gibt. Ein Review in Kurzform, eine halbe Stunde, ohne Bericht, nur mit Maßnahmenliste.
Fazit
Der Post-Incident-Review ist der Moment, in dem ein Vorfall von einem Schaden zu einer Investition wird, und er kostet einen Nachmittag. Ein fester Termin, ein Moderator, eine Zeitlinie, eine Haltung, die Ursachen sucht statt Schuldige, ein Bericht mit den beobachteten Techniken und Maßnahmen mit Namen und Datum. Wer daraus Erkennungsregeln macht und die Maßnahmen nachverfolgt, hat aus dem Vorfall mehr gelernt als der Angreifer. Und das ist der einzige Vorteil, den ein Blue Team nach einem Einbruch noch haben kann.