Incident Response ist der geplante Prozess, mit dem ein Unternehmen auf einen Sicherheitsvorfall reagiert: erkennen, bewerten, eindämmen, bereinigen, wiederherstellen und aus dem Vorfall lernen.
Incident Response (IR) bezeichnet die organisierte Reaktion auf einen Sicherheitsvorfall, vom ersten Verdacht bis zur Nachbereitung. Ziel ist, den Schaden zu begrenzen, den Angreifer aus der Umgebung zu entfernen, den Betrieb wiederherzustellen und Nachweise für Meldepflichten, Versicherer und gegebenenfalls Strafverfolgung zu sichern. Incident Response ist damit mehr als Technik: Sie umfasst Entscheidungswege, Kommunikation nach innen und außen und die Zusammenarbeit mit Dienstleistern, Behörden und Rechtsberatung.
Die Grundlage ist ein schriftlicher Notfallplan mit Rollen, Erreichbarkeiten und Playbooks für die wahrscheinlichsten Szenarien, allen voran Ransomware, kompromittierte Konten und Datenabfluss.
Die Phasen der Incident Response
Gängige Rahmenwerke wie NIST SP 800-61 oder der BSI-IT-Grundschutz beschreiben einen Zyklus aus sechs Schritten:
- Vorbereitung: Rollen, Kontaktlisten, Werkzeuge, Logquellen, Verträge mit IR-Dienstleistern, Übungen.
- Erkennung und Analyse: Alarm aus SOC, EDR oder Hinweis eines Dritten; Einstufung nach Schwere und Ausmaß.
- Eindämmung: Betroffene Hosts isolieren, Konten sperren, Zugangsdaten zurücksetzen, ohne Beweise zu vernichten.
- Beseitigung: Persistenzmechanismen, Hintertüren und Schadsoftware entfernen; Ursache schließen.
- Wiederherstellung: Systeme aus sauberen Backups oder Neuinstallation zurückführen, überwacht wieder in Betrieb nehmen.
- Nachbereitung: Lessons Learned, Anpassung von Erkennungsregeln und Plan, Abschluss der Meldungen.
Bedeutung für Unternehmen
Die Reaktionsfähigkeit entscheidet über den Schaden. Laut IBM Cost of a Data Breach 2025 vergingen in Deutschland im Schnitt 170 Tage, bis ein Datenleck erkannt und eingedämmt war; die durchschnittlichen Kosten lagen bei 3,87 Millionen Euro. Regulatorisch ist IR inzwischen Pflicht: NIS2 verlangt eine dreistufige Meldung (Erstmeldung nach 24 Stunden, Aktualisierung nach 72 Stunden, Abschlussbericht nach einem Monat), DORA und die DSGVO kennen eigene Fristen. Wer im Ernstfall erst klärt, wer meldet, verliert die Frist.
Was wir in Einsätzen sehen: Pläne existieren, sind aber nie unter Druck durchgespielt worden. Kontaktlisten sind veraltet, der Dienstleister hat keinen Rahmenvertrag und damit keine garantierte Reaktionszeit, und die Entscheidung, ob ein System abgeschaltet werden darf, hängt an einer Person. Ein Red Teaming ist die realistischste Probe für diesen Prozess, weil das Blue Team nicht weiß, dass es sich um eine Übung handelt.
Praxis: Umsetzung und Test unter Realbedingungen
- Entscheidungsbefugnisse vorab festlegen: Wer darf das Netz vom Internet trennen, die Produktion stoppen, mit Erpressern kommunizieren? Schriftlich, mit Vertretungsregel.
- Out-of-Band-Kommunikation: Wenn E-Mail und Chat kompromittiert sind, brauchen Sie einen zweiten Kanal mit vorab verteilten Kontakten.
- Playbooks für drei Szenarien: Ransomware, Kontokompromittierung in Microsoft 365 oder Entra ID, Datenabfluss. Mehr ist zu Beginn nicht nötig, aber diese drei müssen sitzen.
- Beweissicherung vor Bereinigung: Ein neu aufgesetzter Server ist forensisch wertlos. Sichern Sie Speicherabbilder und Logs, bevor Sie bereinigen.
- Red-Team-Einsatz als Belastungsprobe: Wir dokumentieren jede Aktion mit Zeitstempel. Im Abgleich mit Ihren SOC-Tickets zeigt sich, wo Erkennung, Eskalation und Eindämmung Zeit verlieren. Ein Red Team rechnet damit, dass die Eindämmung unvollständig bleibt; ob Ihre Beseitigungsphase wirklich alle Zugänge schließt, ist eine der wichtigsten Fragen im Abschlussbericht.