Kurz gesagt: Lessons Learned nach einem IT-Vorfall heißt: Nach dem technischen Abschluss setzen sich alle Beteiligten zusammen, rekonstruieren den Ablauf, benennen ohne Schuldzuweisung, was gut lief und was nicht, und leiten daraus Maßnahmen mit Verantwortlichen und Terminen ab. Das gilt auch für Beinahe-Vorfälle wie eine glimpflich verlaufene PHP2Shell-Woche. Entscheidend ist nicht das Protokoll, sondern die spätere Kontrolle, ob die Maßnahmen umgesetzt wurden.
Warum die Woche nach dem Vorfall so wichtig ist
Wenn der Server wieder läuft und die Patches eingespielt sind, ist die Versuchung groß, schnell zum Alltag zurückzukehren. Genau dann geht das wertvollste Wissen verloren: Wer hat wann was bemerkt? Wo fehlte eine Information? Welche Entscheidung hat zu lange gedauert? In ein paar Wochen weiß das niemand mehr genau.
Die Oktoberwoche 2026 ist dafür ein gutes Beispiel. Viele Unternehmen haben PHP-Server gepatcht, Hoster angeschrieben, Websites vorsorglich abgeschaltet oder Logs gesichert. Auch wenn kein Einbruch festgestellt wurde, steckt darin viel Lernstoff. Wie lange hat es gedauert, bis feststand, welche Systeme betroffen waren? Wer musste die Abschaltung genehmigen, und war diese Person erreichbar?
Die technischen Schritte nach einem Angriff selbst behandelt die Checkliste nach einem Hack. Dieser Beitrag setzt danach an: Was lernen wir daraus?
Lessons Learned im IT-Vorfall: Grundregeln für die Nachbesprechung
Eine Nachbesprechung ist kein Tribunal. Wer befürchtet, dass Fehler persönliche Folgen haben, erzählt nur die halbe Geschichte. Deshalb gilt der Grundsatz: Wir suchen nach Ursachen in Abläufen, Werkzeugen und Informationen, nicht nach Schuldigen. Menschen haben mit dem Wissen gehandelt, das sie in dem Moment hatten.
Laden Sie alle ein, die beteiligt waren, auch Externe wie Hoster, Agentur oder Dienstleister, soweit möglich. Planen Sie zwei Stunden ein. Bitten Sie vorher um Material: Tickets, Chatverläufe, E-Mails, Notizen, Logauszüge. Daraus entsteht die Zeitleiste, das Rückgrat der Besprechung. Wie Sie sie sauber aufbauen, beschreibt Die Zeitleiste eines Vorfalls erstellen.
Die Moderation sollte nicht die Person übernehmen, die den Vorfall operativ geführt hat. Sie würde sonst ihre eigenen Entscheidungen bewerten. Neutral ist zum Beispiel jemand aus einer anderen Abteilung oder ein externer Partner.
Der Ablauf in sechs Schritten
- Zeitleiste vorstellen: Was geschah wann, von der ersten Meldung bis zum Abschluss? Lücken in der Zeitleiste markieren, nicht raten.
- Was lief gut? Beginnen Sie bewusst mit dem Positiven. Das zeigt, was erhalten bleiben soll, und entspannt die Runde.
- Wo hakte es? Jede Verzögerung, jede fehlende Information, jede Unsicherheit wird gesammelt, zunächst ohne Diskussion über Lösungen.
- Ursachen klären: Für die wichtigsten Punkte fragen Sie mehrfach nach dem Warum. „Der Patch kam spät“ ist ein Befund, „niemand wusste, dass auf dem alten Server noch PHP läuft“ ist eine Ursache.
- Maßnahmen festlegen: Zu jeder Ursache eine konkrete Maßnahme, eine verantwortliche Person und ein Termin.
- Nachkontrolle vereinbaren: Ein Termin in vier bis acht Wochen, an dem geprüft wird, was umgesetzt ist.
Typische Fragen und Maßnahmen nach einer PHP-Lage
Die folgende Tabelle zeigt Fragen, die sich nach einer Lage wie PHP2Shell häufig stellen, und mögliche Antworten in Form von Maßnahmen. Nicht jede passt für jedes Unternehmen; sie soll den Blick schärfen.
| Frage in der Nachbesprechung | Typischer Befund | Mögliche Maßnahme |
|---|---|---|
| Wie haben wir von der Lücke erfahren? | Zufällig aus den Nachrichten | Sicherheitsmeldungen von php.net und BSI gezielt abonnieren |
| Wussten wir, welche Systeme betroffen sind? | Liste unvollständig, Altsystem vergessen | Inventar aller Websites und Server mit PHP-Version |
| Wer durfte die Abschaltung entscheiden? | Unklar, Entscheidung verzögert | Entscheidungsbefugnis im Notfallplan festschreiben |
| Hat der Hoster den Patch bestätigt? | Nur mündlich oder gar nicht | Schriftliche Bestätigung anfordern, Vertrag ergänzen |
| Wurden alle PHP-Prozesse neu gestartet? | Nicht überprüft | Neustart und Kontrolle als festen Schritt aufnehmen |
| Waren Logs ab dem 20.10. verfügbar? | Teilweise schon überschrieben | Aufbewahrungsdauer verlängern, Logs zentral sichern |
| Wie lief die Kommunikation nach innen und außen? | Mitarbeitende erfuhren es aus der Presse | Interne Erstinformation vorbereiten |
Halten Sie auch fest, was Sie bewusst nicht ändern. Manchmal ist ein Befund bekannt, aber die Maßnahme wäre unverhältnismäßig. Eine dokumentierte Entscheidung ist besser als ein stilles Vergessen.
Trennen Sie im Protokoll belegte Tatsachen, wahrscheinliche Annahmen und offene Fragen. Gerade nach PHP2Shell, für das es keine veröffentlichten, bestätigten Indicators of Compromise gibt, ist diese Trennung wichtig.
Vom Protokoll zur Veränderung
Das häufigste Scheitern von Lessons Learned ist banal: Das Protokoll wird verschickt, und dann passiert nichts. Drei Gewohnheiten helfen dagegen. Erstens gehört jede Maßnahme in das System, in dem ohnehin gearbeitet wird, also Ticketsystem oder Aufgabenliste, nicht in ein separates Dokument. Zweitens bekommt die Nachkontrolle einen festen Termin im Kalender der Geschäftsführung. Drittens fließen die Ergebnisse in Notfallplan, Kontaktliste und Übungen ein.
Wer die Erkenntnisse prüfen will, ohne auf den nächsten echten Vorfall zu warten, kann sie in einer Notfallübung am Tisch durchspielen. Und wo die Nachbesprechung zeigt, dass Updates zu sehr vom Zufall abhingen, lohnt der Umbau zu einem Patch-Management als Prozess.
Für Datenschutz, Versicherung und gegebenenfalls Behörden ist der Abschlussbericht zudem ein wichtiges Dokument. Die rechtliche Bewertung, etwa ob eine Meldung nach Art. 33 DSGVO nötig war, gehört aber zu Datenschutzbeauftragten oder Anwalt, nicht in die technische Nachbesprechung.
Wie hilft PHP SOS konkret?
- Wir erstellen aus Logs, Tickets und Notizen eine Zeitleiste des Vorfalls und kennzeichnen Lücken.
- Wir moderieren die Nachbesprechung als neutrale Stelle und achten darauf, dass Ursachen statt Schuldige gesucht werden.
- Wir übersetzen technische Befunde in Maßnahmen mit Aufwandsschätzung und Priorität.
- Wir begleiten die Nachkontrolle und setzen technische Maßnahmen auf Wunsch selbst um, so wie in unserer Incident Response vorgesehen.
Fazit
Ein Vorfall ist teuer genug. Wer ihn nicht auswertet, bezahlt beim nächsten Mal noch einmal. Eine ehrliche Nachbesprechung ohne Schuldzuweisung, eine saubere Zeitleiste und Maßnahmen mit Namen und Termin machen aus einer schwierigen Woche einen dauerhaften Gewinn an Sicherheit.
Häufige Fragen
Wann sollte die Lessons-Learned-Besprechung stattfinden?
Wenn der Vorfall technisch abgeschlossen ist, aber die Erinnerung noch frisch ist. In der Praxis bewährt sich ein Termin etwa ein bis zwei Wochen nach Abschluss. Vorher fehlt oft der Abstand, später verblassen die Details.
Muss man auch nach einem Beinahe-Vorfall eine Nachbesprechung machen?
Es lohnt sich. Eine Lage wie PHP2Shell, bei der am Ende nichts passiert ist, zeigt trotzdem, wo Abläufe hakten. Diese Erkenntnisse sind besonders wertvoll, weil sie ohne Schaden zustande kamen.
Wer leitet die Nachbesprechung?
Am besten jemand, der den Vorfall nicht selbst operativ geführt hat. So bleibt die Moderation neutral, und niemand muss seine eigenen Entscheidungen verteidigen. Das kann auch ein externer Dienstleister sein.
Was passiert mit den Ergebnissen?
Jede Erkenntnis wird zu einer Maßnahme mit verantwortlicher Person und Termin. Notfallplan, Kontaktliste und Dokumentation werden angepasst. Nach einigen Wochen prüft jemand, was tatsächlich umgesetzt wurde.