Was ist Incident Response?

Was ist Incident Response?

Incident Response ist die geordnete Art, wie ein Team mit einem Vorfall umgeht: einem ungeplanten Ereignis, das einen Dienst stört oder die Sicherheit bedroht, etwa ein Ausfall, ein Datenleck oder ein kompromittiertes Konto. Dazu gehören das Erkennen des Problems, das Abschätzen seines Umfangs, das Begrenzen des Schadens, die Wiederherstellung des Dienstes und das Lernen daraus, damit es seltener passiert.

Es gibt zwei Spielarten. Betriebsvorfälle (Ausfälle, langsame Antworten, ein fehlerhaftes Deployment) drehen sich darum, den Dienst schnell wiederherzustellen. Sicherheitsvorfälle (Einbruch, Schadsoftware, gestohlene Zugangsdaten) bringen zusätzlich Beweissicherung und rechtliche Pflichten mit. Beide teilen dasselbe Grundgerüst, deshalb kann ein Prozess beide abdecken.

Der Incident-Response-Zyklus: keine einheitliche Phasenzahl

Eine allgemeingültige Anzahl von Phasen gibt es nicht. Das klassische Modell aus NIST SP 800-61 Revision 2 (2012) hat vier: Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung und Wiederherstellung sowie Nachbereitung. Im April 2025 hat NIST diese Revision durch SP 800-61 Revision 3 ersetzt. Sie ordnet Incident Response den sechs Funktionen des NIST Cybersecurity Framework 2.0 zu (Govern, Identify, Protect, Detect, Respond, Recover) und führt Erkenntnisse in alle Funktionen zurück. Außerdem heißt es dort, jede Organisation solle das Zyklusmodell verwenden, das am besten zu ihr passt. Die vier klassischen Phasen bleiben ein praktisches Vokabular:

1. Vorbereitung. Findet statt, bevor etwas kaputtgeht: Bereitschaftsplan, Eskalationswege, Runbooks, Rollen, Textvorlagen, Übungen.
2. Erkennung und Analyse. Ein Alarm löst aus oder ein Kunde meldet ein Problem. Jemand bestätigt es, schätzt Schwere und Betroffene ein und ruft den Vorfall aus.
3. Eindämmung, Beseitigung und Wiederherstellung. Zuerst den Schaden stoppen (Rollback, Funktion abschalten, Failover, Zugangsdaten widerrufen), dann die Ursache entfernen und den Dienst zurückbringen.
4. Nachbereitung. Den Ablauf rekonstruieren, die beitragenden Ursachen finden, Maßnahmen vereinbaren und umsetzen. Ohne Schuldzuweisung, sonst hören Leute auf, Fehler zu melden.

Rollen

Schon ein Zweierteam profitiert davon, Aufgaben zu benennen; eine Person kann mehrere Rollen halten:

• Incident Commander (Einsatzleitung): leitet die Reaktion und trifft die Entscheidungen. Koordiniert, statt selbst zu reparieren.
• Einsatzkräfte: untersuchen und beheben, nach Anweisung der Einsatzleitung.
• Kommunikationsverantwortliche: halten Kunden und Kollegen auf dem Laufenden. Siehe Vorfallkommunikation.
• Protokollführung: schreibt den Ablauf mit, während er geschieht, was die Nachbereitung deutlich erleichtert.

Ein Beispiel

Das Beispiel ist erfunden. Um 14:05 Uhr melden zwei Überwachungsstandorte, dass POST /checkout mit 500 antwortet. Die Bereitschaft bestätigt das, ruft einen größeren Vorfall aus (Schweregrade und Bezeichnungen legt Ihr Team selbst fest) und benennt eine Einsatzleitung. Die Kommunikation setzt auf der Statusseite "Untersuchung". Ein Techniker bringt die Fehler mit dem Deployment von 13:50 Uhr in Verbindung, und die Einsatzleitung entscheidet sich für einen Rollback statt Fehlersuche im laufenden Betrieb. Die Fehler hören auf, das Team beobachtet die Fehlerrate eine Weile und schließt den Vorfall. Die Nachbereitung zeigt, dass das Deployment eine Prüfung in der Staging-Umgebung übersprungen hat; die Maßnahmenliste enthält diese Prüfung und einen schnelleren Alarm.

Häufige Fehler

• Kein einzelner Verantwortlicher. Mehrere Personen, die parallel Änderungen vornehmen, machen sich gegenseitig die Arbeit zunichte. Benennen Sie immer eine Einsatzleitung.
• Erst untersuchen, dann eindämmen. Meist ist es richtig, den Schaden mit einer groben Lösung zu stoppen und die Ursache danach in Ruhe zu suchen. Bei einem Sicherheitsvorfall sichern Sie beim Eindämmen die Beweise.
• Zu viele Alarme. Wenn Meldungen ignoriert werden, geht ein echter Vorfall darin unter. Siehe Alarmmüdigkeit.
• Schweigen nach außen. Kunden merken den Ausfall früher als Ihr Update. Betreiben Sie die Statusseite auf einer Infrastruktur, die den Vorfall übersteht.
• Nachbereitung ohne Umsetzung. Ein Postmortem, dessen Maßnahmen nie umgesetzt werden, dokumentiert nur den nächsten Vorfall im Voraus.
• Das Runbook erst im Vorfall zum ersten Mal lesen. Üben Sie mit Planspielen (Tabletop) oder Game Days.

Sicherheitsvorfälle und gesetzliche Fristen

Sicherheitsvorfälle können gesetzliche Fristen auslösen. Nach Art. 33 DSGVO muss der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der Aufsichtsbehörde melden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Klären Sie vorab, wer das entscheidet.

Bezug zu Tests und Überwachung

Die Reaktion beginnt mit der Erkennung, und die hängt von Observability ab: Metriken, Logs und Prüfungen, die Ihnen vor den Kunden sagen, dass etwas nicht stimmt. Außerdem gehört sie zum Reliability Engineering, wo schuldfreie Nachbereitungen und Service-Level-Ziele entscheiden, was danach behoben wird. LoadFocus ist keine Incident-Response-Plattform und führt weder Ihre Bereitschaft noch Ihren Prozess. Es liefert zwei Zutaten:

• Das API-Monitoring führt geskriptete Prüfungen nach Zeitplan aus (im Free-Tarif alle 5 Minuten), von mehreren seiner 25 Regionen, prüft Statuscode, Body, Header und Antwortzeit und alarmiert per E-Mail, Slack, Microsoft Teams oder Webhook, in bezahlten Tarifen zusätzlich per PagerDuty und Opsgenie. Mehrere aufeinanderfolgende Fehler oder mehrere betroffene Standorte als Bedingung senken falsche Alarme.
• Statusseiten übernehmen die öffentliche Seite: Vorfallmeldungen laufen von Untersuchung über Ursache gefunden und Beobachtung bis Behoben, danach kann ein Postmortem veröffentlicht werden. Auf der Statusseite schauen Kunden zuerst nach.

Lasttests gehören in die Vorbereitung: Lasttests zeigen, wo ein System unter Last bricht, bevor echter Traffic es herausfindet. Gewohnheiten, die Alarme nützlich halten, beschreibt der Leitfaden Monitoring Best Practices.

Häufige Fragen: Incident Response

Wie viele Phasen hat Incident Response?

Das hängt vom Modell ab. NIST SP 800-61 Revision 2 nutzte vier Phasen. Revision 3 (April 2025) ordnet Incident Response den sechs Funktionen des Cybersecurity Framework 2.0 zu und rät Organisationen, den Zyklus zu wählen, der zu ihnen passt. Entscheidend ist, dass Vorbereitung, Erkennung, Eindämmung samt Wiederherstellung und Lernen abgedeckt sind, wie auch immer Sie es nennen.

Wer sollte die Einsatzleitung übernehmen?

Jemand, der für die Rolle geschult ist, nicht zwingend die dienstälteste Person. Die Aufgabe ist Koordination und Entscheidung, nicht Reparatur. Viele Teams halten eine rotierende Gruppe von Einsatzleitungen bereit, damit die Rolle nicht an einer Person hängt.

Was ist der Unterschied zwischen Incident und Problem?

Im ITIL-Vokabular ist ein Incident eine einzelne ungeplante Unterbrechung und ein Problem die zugrunde liegende Ursache eines oder mehrerer Incidents. Ein Problem, etwa ein erschöpfter Verbindungspool, kann im Lauf der Zeit mehrere Incidents verursachen.

Sollten Postmortems öffentlich sein?

Das ist eine Ermessensfrage. Viele Teams veröffentlichen bei größeren, für Kunden sichtbaren Vorfällen eine kürzere öffentliche Zusammenfassung und behalten die detaillierte Analyse intern. Sagen Sie in beiden Fällen, was passiert ist, was Sie ändern und bis wann.

Wie üben wir Incident Response?

Spielen Sie ein Szenario in einer Tabletop-Übung durch, veranstalten Sie einen Game Day mit einem echten Fehler in einer sicheren Umgebung und lassen Sie neue Bereitschaftskräfte bei einem Einsatz zuerst mitlaufen, bevor sie selbst leiten.