IT-Notfallmanagement: Incident Response und Krisenmanagement

IT-Notfallmanagement ist die organisierte Vorbereitung auf, Reaktion auf und Wiederherstellung nach IT-Sicherheitsvorfällen. Der Unterschied zwischen einer Katastrophe und einem bewältigten Incident liegt oft nur im Vorhandensein eines guten Plans.

Das NIST Incident Response Framework

Das NIST (National Institute of Standards and Technology) definiert 4 Phasen:

Phase 1 - Vorbereitung (Preparation): Incident Response Plan erstellen, Team und Rollen definieren, Tools bereitstellen (Forensik-Software, Backup-Systeme) und regelmäßig üben (Tabletop Exercises).

Phase 2 - Erkennung und Analyse (Detection & Analysis): Incident erkennen (SIEM-Alert, Nutzer-Meldung, externe Meldung), Scope und Schwere einschätzen, Logs sichern (nicht überschreiben!) und Zeitstempel dokumentieren.

Phase 3 - Eindämmung, Beseitigung und Wiederherstellung (Containment, Eradication & Recovery): Schadensausbreitung stoppen, Angreifer aus dem System entfernen und Systeme schrittweise wiederherstellen.

Phase 4 - Post-Incident-Aktivitäten: Root Cause Analysis durchführen, Lessons Learned ableiten, Prozesse verbessern und regulatorische Reports finalisieren.

Der Incident Response Plan

Kernelemente eines IR-Plans

1. Incident Classification Matrix

Schwere	Beispiele	Reaktion
P1 - Kritisch	Laufender Ransomware-Angriff, vollständiger System-/Netzwerkausfall, aktive APT-Kompromittierung	Sofortige Eskalation auf C-Level, Krisenteam vollständig aktivieren
P2 - Hoch	Kompromittierter Admin-Account, Datenverlust sensitiver Daten, Malware auf mehreren Systemen	IT-Leitung und CISO informieren, Forensik-Dienstleister aktivieren
P3 - Mittel	Kompromittierter normaler User-Account, Malware auf einem isolierten Endpunkt, Phishing-Mail geöffnet	Standardprozess IT-Security
P4 - Niedrig	Spam-Kampagne ohne Klicks, verdächtige Mail gemeldet	Dokumentation, Standard-Response

2. RACI-Matrix (Rollen und Verantwortlichkeiten)

Person/Rolle	Erkennen	Entscheiden	Kommunizieren	Beheben
IT-Administrator	R/A	I	I	R
CISO/IT-Leiter	I	R/A	R	A
Geschäftsführung	I	A (P1/P2)	R (extern)	I
PR / Kommunikation	I	I	R/A (extern)	I
Datenschutzbeauftragter	I	R (DSGVO)	R (Behörden)	I
Forensik-Dienstleister	I	C	I	R/A
Rechtsabteilung	I	C	R (legal)	C

R = Responsible, A = Accountable, C = Consulted, I = Informed

3. Kontaktliste (24/7)

Die Kontaktliste muss intern und extern besetzt sein: Intern gehören CISO/IT-Leiter (Handy + Signal), Geschäftsführer, Datenschutzbeauftragter und eine 24/7-IT-Notfallhotline dazu. Extern müssen vertraglich auf Abruf stehen: Forensik/IR-Dienstleister (SLA: 4h Reaktion), Cyber-Anwalt und die Schadenshotline der Cyber-Versicherung. Behörden: BSI/CERT-Bund (0800 274 1000, kostenlos), zuständiges LKA Cybercrime sowie die zuständige Landesdatenschutzbehörde.

Die ersten 72 Stunden - Chronologie

Stunde 0-1: Erkennung und erster Response

Minute 0: Alert eingeht (SIEM, Nutzer, externer Report). Minute 5: IT-Administrator informiert und führt Erstbewertung durch. Minute 15: CISO/IT-Leiter informiert. Minute 20: Scope bestimmen (wie viele Systeme, welche Daten?). Minute 30: Schweregrad-Entscheidung P1/P2/P3/P4. Minute 45: Bei P1/P2 Krisenteam einberufen und GF informieren. Stunde 1: Erste Containment-Maßnahmen (Isolation betroffener Systeme).

Stunde 1-4: Containment

Erstes Ziel ist Ausbreitung stoppen, nicht heilen.

Bei Ransomware/Malware:

Betroffene Systeme vom Netz trennen (Kabel physisch trennen)
NICHT herunterfahren (forensische Daten im RAM würden verloren gehen)
Logs sichern BEVOR Systeme isoliert werden
Passwörter aller betroffenen Accounts ändern
Admin-Accounts sperren und neu erstellen mit frischen Credentials

Bei kompromittiertem Account:

Account deaktivieren (nicht löschen - forensische Spuren erhalten)
Alle Sessions invalidieren
Alle Geräte des Nutzers prüfen
Scope definieren: Welche Daten hatte der Account Zugang?

Stunde 4-24: DSGVO-Meldepflicht

Nach DSGVO Art. 33 gilt: Innerhalb von 24 Stunden muss eine erste Einschätzung erfolgen, ob personenbezogene Daten betroffen sind. Sind sie es, muss innerhalb von 72 Stunden eine Meldung an die Datenschutzbehörde erfolgen.

Das Meldeformular enthält: Art des Vorfalls (Ransomware, Datenleck etc.), Kategorien und ungefähre Anzahl betroffener Personen, wahrscheinliche Folgen sowie getroffene Maßnahmen.

Wenn der Scope noch unklar ist, ist eine Vorab-Meldung ("Vorsichtsmeldung") möglich: "Vorfall erkannt, Scope noch unklar, Update folgt."

Stunde 24-72: NIS2-Meldepflicht (für betroffene Unternehmen)

Nach NIS2 Art. 23 gilt ein dreistufiges Melderegime: Innerhalb von 24 Stunden ist eine Frühwarnung an das BSI zu senden (Incident-Typ und erste Einschätzung, kein vollständiger Bericht nötig). Innerhalb von 72 Stunden folgt die vollständige Meldung mit Ursache soweit bekannt, Auswirkungen und Gegenmaßnahmen. Nach 30 Tagen ist ein Abschlussbericht fällig. Meldestelle ist das BSI / CERT-Bund über das Online-Portal.

Forensik: Beweise sichern

Wichtig: Forensische Beweise sichern bevor Systeme gereinigt oder neu aufgesetzt werden.

Speicher (RAM): Memory Dump vor dem Abschalten erstellen, da er laufende Prozesse und Credentials enthält. Tools: DumpIt, WinPmem, LiME (Linux).

Festplatten: Forensische Kopie (bit-genaue Kopie) erstellen BEVOR das System bereinigt wird, inklusive Hash-Wert (SHA256) für die Beweiskette. Tools: dd, FTK Imager, EnCase.

Logs: Windows Event Logs (System, Security, Application), PowerShell-Logs (Module Logging, Script Block Logging), Firewall-Logs, Proxy-Logs, DNS-Logs sowie SIEM-Export der letzten 30-90 Tage.

Netzwerk: Alle ausgehenden Verbindungen der letzten Stunden und Tage sowie PCAP-Captures wenn verfügbar.

Business Continuity während des Incidents

Drei Themenbereiche müssen sofort beantwortet sein:

Kommunikation: Wie kommuniziert das Unternehmen während des Incidents? Da E-Mail möglicherweise kompromittiert ist, sollten Signal oder Threema als Backup bereitstehen. Externe Kommunikation: Wer spricht mit Kunden, Presse und Behörden?

Betrieb: Können kritische Prozesse manuell weiterlaufen? Welche Systeme sind kritisch versus nicht-kritisch? Gibt es Hot-Standby-Systeme?

Backup: Wann war das letzte saubere Backup? Sind Backups vom Angreifer möglicherweise ebenfalls verschlüsselt worden? Recovery Time Objective (RTO): Wann muss der Betrieb wieder laufen?

Tabletop Exercise - Incident Response üben

Die beste Vorbereitung ist das Üben - bevor es ernst wird:

Das Format: 2-4 Stunden, Teilnehmer aus IT, Führungsebene, Kommunikation und Recht. Ein Szenario wird vorgelesen, das Team diskutiert die Reaktion.

Beispiel-Szenario: "Montag 06:30 Uhr. Mitarbeiter rufen an: alle Server zeigen verschlüsselte Dateien und eine Lösegeldforderung. Was tun Sie in den nächsten 60 Minuten?"

In der Auswertung werden folgende Fragen analysiert: Wie lange dauerte es bis zum ersten Alert? Waren alle Kontakte erreichbar? Kannte jeder seine Rolle? Welche Lücken im Plan wurden entdeckt?

Lessons Learned und kontinuierliche Verbesserung

Nach jedem Incident (P1-P3):

Der Post-Incident Review (innerhalb 1-2 Wochen) umfasst: Timeline des Incidents rekonstruieren, Root Cause Analysis (Wie ist der Angreifer reingekommen?), Bewertung was funktioniert hat und was nicht sowie welche Controls den Angriff hätten verhindert oder früher erkannt.

Typische Ergebnisse: "MFA auf VPN fehlte - Sofortmaßnahme: MFA einführen." "SIEM hatte keine Regel für diesen Angriff - Neue SIEM-Regel erstellen." "Backup-Wiederherstellung dauerte 8h, RTO nicht erfüllt - Backup-Strategie überarbeiten." "Kommunikationspfade unklar - RACI aktualisieren."

IT-Notfallmanagement ist kein Einmal-Projekt - es ist ein kontinuierlicher Prozess aus Vorbereitung, Übung, Response und Verbesserung.