Incident Response

Was ist Incident Response?

Incident Response ist das, was eine Organisation tut, wenn mit ihrer Sicherheit etwas schiefgegangen ist: Ein System ist kompromittiert, Daten sind abgeflossen, Ransomware breitet sich aus oder ein Produkt im Feld wird angegriffen. Ziel ist, den Schaden zu begrenzen, den Normalbetrieb wiederherzustellen, Meldepflichten zu erfüllen und eine Wiederholung zu verhindern.

NIST SP 800-61 Rev. 2 beschrieb den Lebenszyklus in vier Phasen, die die meisten Teams weiter nutzen: Vorbereitung; Erkennung und Analyse; Eindämmung, Beseitigung und Wiederherstellung; Nachbereitung. Rev. 3 (2025) ordnet Incident Response als Teil des Cybersecurity-Risikomanagements ein und bildet die Aktivitäten auf die sechs Funktionen des NIST Cybersecurity Framework 2.0 ab, womit klar wird, dass Vorbereitung (Govern, Identify, Protect) und Erkennung (Detect) genauso Teil der Incident Response sind wie die Reaktion selbst.

Wo ist es definiert?

NIST SP 800-61 ist die am weitesten verbreitete Referenz für den Prozess. In der EU kommen die gesetzlichen Pflichten aus NIS2, Richtlinie (EU) 2022/2555: Artikel 21 Absatz 2 Buchstabe b verlangt die Bewältigung von Sicherheitsvorfällen als Risikomanagementmaßnahme, Artikel 23 setzt die Meldepflichten für erhebliche Vorfälle (Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats). Für Hersteller von Produkten mit digitalen Elementen ergänzt der Cyber Resilience Act, Verordnung (EU) 2024/2847, Artikel 14: Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die das Produkt betreffen, werden über die zentrale Meldeplattform der ENISA im selben 24- und 72-Stunden-Rhythmus gemeldet. Für Fahrzeuge verlangt UN R155 Absatz 7.2.2.2 (g) Prozesse zur Erkennung und Beantwortung von Angriffen, Absatz 7.4 die Berichterstattung an die Genehmigungsbehörde. ISO/IEC 27001 Anhang A und ISO/SAE 21434 Kapitel 13 behandeln denselben Prozess für ihre Domänen.

Was es in der Praxis bedeutet

Vorfälle entscheiden sich in den ersten Stunden, und die ersten Stunden laufen nur gut, wenn die Entscheidungen vorher getroffen wurden. Wer darf das Produktionsnetz vom Netz nehmen? Wer spricht mit Kunden? Wo liegt die Kontaktliste, wenn der Mailserver verschlüsselt ist? An welche Behörde meldest du, und wer schreibt den Bericht mit den technischen Fakten so, dass ein Nicht-Techniker ihn lesen kann? Unternehmen, die das einmal geübt haben, und sei es am Tisch, reagieren in einer anderen Liga als die, die den Plan während des Vorfalls zum ersten Mal lesen.

Der zweite entscheidende Faktor ist die Erkennung. Die 24-Stunden-Uhr in NIS2 und CRA startet mit der Kenntnisnahme, und Angreifer sind typischerweise Tage bis Wochen in einem Netz, bevor jemand es merkt. Kontinuierliches Monitoring mit einem SOC macht aus “wir haben es durch die Erpressernachricht erfahren” ein “wir haben den ersten Host Freitagnacht isoliert”. Für Hersteller gilt dasselbe für das Produkt: Ein Prozess zur Schwachstellenbehandlung, der Advisories für die Komponenten in deiner Software-Stückliste beobachtet, macht die CRA-Frist erreichbar.

Häufige Missverständnisse

Incident Response ist nicht dasselbe wie Wiederherstellen aus dem Backup. Wer wiederherstellt, bevor er weiß, wie der Angreifer reinkam und ob er noch da ist, holt ihn mit den Daten zurück. Fertig ist es auch nicht, wenn die Systeme wieder laufen: Die Nachbereitung, der Bericht an die Behörde und die Korrekturen an Erkennung und Architektur gehören zum Prozess. Und es ist kein reines IT-Thema: Für einen Gerätehersteller ist eine ausgenutzte Schwachstelle im Produkt ein Vorfall mit eigener Meldepflicht, auch wenn kein internes System berührt wurde.