Reaktion auf Sicherheitsvorfälle für ein kleines Team: ein Minimalverfahren

Ziel

Mit einer vermuteten Kompromittierung umgehen (durchgesickerte Anmeldedaten, ausgenutzte Abhängigkeit, unerwarteter Administrator-Login, verunstaltete Seite), sodass der Schaden begrenzt bleibt, Beweise erhalten bleiben und das Team daraus lernt, ohne eine dedizierte Sicherheitsfunktion.

Voraussetzungen

NIST SP 800-61 Rev. 3 (April 2025) ordnet die Reaktion auf Vorfälle in das laufende Cybersicherheits-Risikomanagement einer Organisation unter dem Cybersecurity Framework 2.0 ein: im Voraus vorbereitet, nicht improvisiert. Das OWASP-Cheatsheet zu Secure Product Design listet einen eingeübten Plan zur Reaktion auf Sicherheitsvorfälle unter seinen Konfigurationsempfehlungen. Vorzubereiten: eine Kontaktliste (wer entscheidet, wer Anmeldedaten widerrufen kann, Hosting-Anbieter, Registrar, Zahlungsanbieter), ein Inventar der Geheimnisse mit ihren Rotationsschritten, Logs, die von den Hosts, die sie beschreiben, weggeschrieben werden, sowie eine schriftliche Regel zur Beweissicherung.

Schritte

1. Ausrufen: Eine Person benennt es als Vorfall, eröffnet ein Zeitleisten-Dokument und hält von da an jede Handlung mit Zeitstempel fest. Höchstens zwei Rollen: Verantwortliche Person für die Reaktion und für die Kommunikation.
2. Umfang: Welche Anmeldedaten, Hosts und Daten könnte die angreifende Person erreicht haben? Vom plausibel schlimmsten Fall ausgehen, bis Beweise ihn eingrenzen.
3. Eindämmen vor Beseitigen: offengelegte Anmeldedaten widerrufen oder rotieren, den Weg der angreifenden Person kappen (Konto deaktivieren, Schlüssel entfernen, Endpunkt vom Netz nehmen) und jedes Geheimnis rotieren, das die kompromittierte Komponente lesen konnte. Umkehrbare Massnahmen bevorzugen.
4. Beweise sichern, bevor Zustand zerstört wird: Snapshots von Platten oder Containern erstellen, Logs exportieren, laufende Prozesse und Verbindungen festhalten; danach neu aufbauen statt an Ort und Stelle bereinigen.
5. Beseitigen und wiederherstellen: betroffene Systeme aus bekanntermassen unversehrten Images und aus dem Quellcode neu aufbauen, die Korrektur anwenden, Daten aus Backups von vor der Kompromittierung wiederherstellen, wo die Integrität zweifelhaft ist, und bestätigen, dass jede rotierte Anmeldeinformation im Einsatz ist.
6. Sachlich mit betroffenen Nutzenden und Partnern kommunizieren; welche Meldepflichten gelten, hängt von Rechtsordnung und Verträgen ab und sollte mit einer dazu qualifizierten Person geklärt werden.
7. Mit einer schuldzuweisungsfreien Nachbetrachtung abschliessen: Zeitleiste, Ursache, welche Erkennung es früher entdeckt hätte, Massnahmen mit verantwortlichen Personen.

Erwartetes Ergebnis

Die erste Stunde folgt einer Checkliste statt einer Debatte; die Nachbetrachtung hat Beweise, mit denen sie arbeiten kann; jede Anmeldeinformation, die die angreifende Person hätte sehen können, wurde rotiert; der Vorfall führt zu konkreten Änderungen an Erkennung und Konfiguration.

Grenzen und Prüfbasis

Dies ist eine auf ein kleines Team herunterskalierte Zusammenfassung der zitierten Anleitung, kein rechtliches oder regulatorisches Verfahren; Pflichten werden hier nicht genannt. Es einmal mit einem fiktiven durchgesickerten Schlüssel einüben: Ein Plan, der nie durchgespielt wurde, ist ein Dokument, keine Fähigkeit.