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 definieren, Rollen klären
  → Tools bereitstellen (Forensik-Software, Backup-Systeme)
  → Regelmäßig üben (Tabletop Exercises)

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

Phase 3: EINDÄMMUNG, BESEITIGUNG & WIEDERHERSTELLUNG
  (Containment, Eradication & Recovery)
  → Schadensausbreitung stoppen
  → Angreifer aus dem System entfernen
  → Systeme schrittweise wiederherstellen

Phase 4: POST-INCIDENT AKTIVITÄTEN
  → Root Cause Analysis
  → Lessons Learned
  → Prozesse verbessern
  → Regulatorische Reports finalisieren

Der Incident Response Plan

Kernelemente eines IR-Plans

1. Incident Classification Matrix

Schwere-Level:

P1 - KRITISCH:
  Laufender Ransomware-Angriff
  Vollständiger System-/Netzwerkausfall
  Aktiver 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 Endpunkt (isoliert)
  Phishing-Mail geöffnet
  → Standardprozess IT-Security

P4 - NIEDRIG:
  Spam-Kampagne, keine 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
Datenschutzbeauftrag. 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)

Intern:
  CISO/IT-Leiter:      [Name] [Handy] [Signal]
  Geschäftsführer:     [Name] [Handy]
  Datenschutzbeauft.:  [Name] [Handy]
  Notfallhotline IT:   [Nummer] (24/7)

Extern - auf Abruf vertraglich:
  Forensik/IR-Dienst:  [Firma] [Nummer] [SLA: 4h Reaktion]
  Cyber-Anwalt:        [Kanzlei] [Ansprechpartner]
  Cyber-Versicherung:  [Police-Nr.] [Schadenshotline]

Behörden:
  BSI / CERT-Bund:     0800 274 1000 (kostenlos)
  LKA Cybercrime:      [zuständiges LKA]
  Datenschutzbehörde:  [Landesbehörde eintragen]

Die ersten 72 Stunden - Chronologie

Stunde 0-1: Erkennung und erster Response

0:00 - Alert eingeht (SIEM, Nutzer, externer Report)
0:05 - IT-Administrator informiert → Erstbewertung
0:15 - CISO/IT-Leiter informiert
0:20 - Scope bestimmen: Wie viele Systeme? Welche Daten?
0:30 - Entscheidung: Schweregrad P1/P2/P3/P4?
0:45 - P1/P2: Krisenteam einberufen, GF informieren
1:00 - Erste Containment-Maßnahmen (Isolation betroffener Systeme)

Stunde 1-4: Containment

Erstes Ziel: Ausbreitung stoppen, nicht heilen!

Bei Ransomware/Malware:
  ✓ Betroffene Systeme vom Netz trennen (Kabel physisch trennen)
  ✓ NICHT herunterfahren (forensische Daten im RAM verloren)
  ✓ Logs sichern BEVOR Systeme isoliert werden
  ✓ Passwörter aller betroffenen Accounts ändern
  ✓ Admin-Accounts sperren → neu erstellen mit frischen Credentials

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

Stunde 4-24: DSGVO-Meldepflicht

DSGVO Art. 33:
  24h: Erste Einschätzung ob personenbezogene Daten betroffen
  72h: Falls betroffen → Meldung an Datenschutzbehörde

Meldeformular enthält:
  → Art des Vorfalls (Ransomware, Datenleck, etc.)
  → Kategorien und ungefähre Anzahl betroffener Personen
  → Wahrscheinliche Folgen
  → Getroffene Maßnahmen

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

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

NIS2 Art. 23:
  24h: Frühwarnung an BSI
    → Incident-Typ, erste Einschätzung
    → Kein vollständiger Bericht nötig
  72h: Vollständige Meldung
    → Ursache soweit bekannt
    → Auswirkungen und Gegenmaßnahmen
  30 Tage: Abschlussbericht

Meldestelle: BSI / CERT-Bund (online-Portal)

Forensik: Beweise sichern

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

Zu sichernde Artefakte:

Speicher (RAM):
  → Memory Dump vor Abschalten (enthält laufende Prozesse, Credentials)
  → Tools: DumpIt, WinPmem, LiME (Linux)

Festplatten:
  → Forensische Kopie (bit-genaue Kopie) BEVOR bereinigt wird
  → Hash-Wert (SHA256) für 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
  → SIEM-Export der letzten 30-90 Tage

Netzwerk:
  → Alle ausgehenden Verbindungen der letzten Stunden/Tage
  → PCAP-Captures wenn verfügbar

Business Continuity während des Incidents

Fragen die sofort beantwortet sein müssen:

Kommunikation:
  → Wie kommuniziert das Unternehmen während des Incidents?
  → E-Mail möglicherweise kompromittiert → Signal/Threema als Backup?
  → Externe Kommunikation: wer spricht mit Kunden, Presse, Behörden?

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

Backup:
  → Wann war das letzte saubere Backup?
  → Sind Backups vom Angreifer auch verschlüsselt worden?
  → Recovery Time Objective (RTO): Wann muss Betrieb wieder laufen?

Tabletop Exercise - Incident Response üben

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

Tabletop Exercise Format:
  Dauer: 2-4 Stunden
  Teilnehmer: IT, Führungskräfte, Kommunikation, Recht
  Format: Szenario wird vorgelesen, Team diskutiert 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?"

Auswertung:
  → Wie lange dauerte es bis erster 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):

Post-Incident Review (innerhalb 1-2 Wochen):
  → Timeline des Incidents rekonstruieren
  → Root Cause Analysis: Wie ist Angreifer reingekommen?
  → Was hat funktioniert? Was nicht?
  → Welche Controls hätten verhindert / 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.