Incident Response mit NIST: die Respond-Function und SP 800-61

Problem in der Praxis

Viele Organisationen besitzen einen Incident-Response-Plan, ein SOC und Eskalationslisten, dennoch laufen reale Vorfälle chaotisch. Der Plan ist aktuell auf dem Papier, aber nie geübt; die Eskalation endet in der IT, ohne dass Geschäftsleitung, Recht und Kommunikation rechtzeitig eingebunden werden; Meldefristen gegenüber Behörden und Vertragspartnern verstreichen im Stress.

Ein zweites Muster ist die Phasen-Falle: Teams arbeiten den Lebenszyklus mechanisch ab und behandeln Eindämmung, Beseitigung und Wiederherstellung als nacheinander geschaltete Schritte, obwohl ein moderner Angriff parallele, iterative Reaktion verlangt. Drittens bleibt die wichtigste Phase liegen: Lessons Learned werden nicht systematisch in Schutz, Detektion und Playbooks zurückgespielt, sodass der nächste ähnliche Vorfall erneut unvorbereitet trifft. CSF 2.0 und SP 800-61 Rev. 3 adressieren diese Bruchstellen, indem sie IR als kontinuierlichen Kreislauf statt als abgeschlossene Episode begreifen.

CISO-Einordnung

Laut NIST CSF 2.0 (NIST.CSWP.29, veröffentlicht am 26.02.2024) gliedert sich das Framework in 6 Functions, 22 Categories und 106 Subcategories. Auf Respond entfallen vier Categories, die den Reaktionsbogen abbilden: Incident Management (RS.MA), Incident Analysis (RS.AN), Incident Response Reporting and Communication (RS.CO) und Incident Mitigation (RS.MI). Flankiert wird RS von Detect (DE) und Recover (RC) mit je zwei Categories.

SP 800-61 Rev. 3 (DOI 10.6028/NIST.SP.800-61r3) ordnet IR konsequent in dieses Modell ein: Vorbereitung über Govern, Identify und Protect, Bewältigung über Detect, Respond und Recover. Der aus Rev. 2 bekannte Lebenszyklus (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity) bleibt als Konzept nützlich, gilt aber nicht mehr als zwingend lineare Abfolge, sondern als iterativer Prozess mit kontinuierlicher Verbesserung.

Die outcome-orientierten Respond-Ergebnisse des CSF lassen sich mit konkreten Maßnahmen unterlegen. Im Kontrollkatalog SP 800-53 Rev. 5 (20 Familien, 324 Basis-Controls, 872 Enhancements) liefert die Familie Incident Response (IR) mit zehn Basis-Controls die Tiefe, darunter Incident Response Plan (IR-8), Training (IR-2), Testing (IR-3), Handling (IR-4), Monitoring (IR-5) und Reporting (IR-6). Wiederherstellung verbindet sich mit Contingency Planning (CP) und SP 800-34 (RTO/RPO); Vorfälle in der Lieferkette greifen auf C-SCRM (Familie SR, Category GV.SC) zu.

Umsetzungsperspektive

IR-Reife entsteht entlang des Function-Bogens, nicht in einem Dokument. Bewährt hat sich, die Respond-Logik als Zusammenspiel von Vorbereitung, Reaktion und Verbesserung mit klaren Eigentümern zu führen.

• Vorbereitung (Govern/Identify/Protect): Risikoappetit, Rollen und Eskalationswege vorab festlegen; ein CSIRT mit benannter Leitung, Schnittstellen zu Recht, Datenschutz, Kommunikation und Geschäftsleitung sowie Erreichbarkeit rund um die Uhr einrichten.
• Erkennung und Analyse (Detect/RS.AN): Detektion, Triage und forensische Analyse klären Umfang, Ursache und betroffene Werte; Beweissicherung von Anfang an verwertbar halten.
• Reaktion (RS.MA/RS.MI): Incident Management koordiniert die Bewältigung; Eindämmung und Beseitigung laufen iterativ statt strikt sequentiell, Entscheidungen mit Geschäftsfolgen wandern zur passenden Eskalationsstufe.
• Kommunikation und Meldung (RS.CO): interne und externe Kommunikation vorbereiten; regulatorische und vertragliche Meldepflichten vorab Auslösern und Fristen zuordnen (in Europa etwa NIS2, DORA oder DSGVO als Umfeld des CISO).
• Wiederherstellung und Lessons Learned (Recover/Post-Incident): Wiederanlauf nach RTO/RPO; danach Erkenntnisse strukturiert in Schutzmaßnahmen, Detektionsregeln und Playbooks zurückführen.

Playbooks pro Szenario (Ransomware, Datenabfluss, kompromittierte Zugangsdaten, Lieferantenvorfall) machen die Reaktion wiederholbar und schulbar. Threat-Information-Sharing, also der Austausch von Indikatoren und Lagebildern mit Partnern und Sektor-Netzwerken, beschleunigt Erkennung und Einordnung und gehört nach SP 800-61 Rev. 3 zu einem reifen IR-Programm.

Typische Fehler

1. IR wird als reines SOC-/IT-Thema geführt; Geschäftsleitung, Recht und Kommunikation werden zu spät eingebunden.
2. Der IR-Plan existiert, wird aber nie realitätsnah geübt; im Ernstfall sind Rollen und Eskalationsschwellen unklar.
3. Der Lebenszyklus wird mechanisch-linear abgearbeitet, statt Eindämmung, Beseitigung und Wiederherstellung iterativ zu führen.
4. Lessons Learned (Post-Incident Activity) versanden, sodass Schutz und Detektion nicht aus Vorfällen lernen.
5. Meldepflichten werden erst im Vorfall gesucht statt vorab Auslösern, Fristen und Verantwortlichen zugeordnet.

Risiken und Trade-offs

IR-Steuerung muss Geschwindigkeit und Sorgfalt ausbalancieren. Schnelle Eindämmung kann flüchtige forensische Spuren vernichten, die später für Ursachenanalyse, Meldung oder rechtliche Aufarbeitung gebraucht werden; eine zu lange Analyse erhöht dagegen den Schaden. Diese Abwägung gehört vorab in Playbooks und Eskalationsregeln, nicht in die Hektik des Ernstfalls.

Ein zweiter Trade-off betrifft Transparenz: Frühe, breite Kommunikation schafft Vertrauen und erfüllt Meldepflichten, kann aber laufende Ermittlungen stören oder voreilige Aussagen erzeugen. Drittens steht Zentralisierung gegen Tempo: Ein zentral geführtes CSIRT sichert Konsistenz, kann aber zum Engpass werden; delegierte Erstreaktion mit klaren Leitplanken skaliert besser, verlangt aber Qualifikation und Nachweise.

Entscheidungspunkte

• Wer leitet das CSIRT, und wie sind Mandat, Erreichbarkeit und Eskalationsschwellen zur Geschäftsleitung dokumentiert?
• Welche Vorfallszenarien sind so kritisch, dass sie ein eigenes, geübtes Playbook brauchen?
• Welche regulatorischen und vertraglichen Meldepflichten gelten, und sind ihnen Auslöser, Fristen und Verantwortliche fest zugeordnet?
• Welche Respond-Ergebnisse steuern wir auf CSF-Ebene, und wo unterlegen wir sie mit Controls der IR-Familie von SP 800-53?
• Wie ist sichergestellt, dass Lessons Learned in Protect und Detect zurückfließen, statt folgenlos zu bleiben?

Praktische Empfehlungen

1. Führen Sie IR als Function-übergreifenden Kreislauf: Vorbereitung in Govern/Identify/Protect, Bewältigung in Detect/Respond/Recover, mit benannten Eigentümern je Abschnitt.
2. Richten Sie ein CSIRT mit klarer Leitung, festen Schnittstellen zu Recht, Datenschutz, Kommunikation und Leitung sowie definierten Eskalationsstufen ein und üben Sie es regelmäßig.
3. Erstellen und testen Sie szenariospezifische Playbooks; behandeln Sie Eindämmung, Beseitigung und Wiederherstellung iterativ statt strikt sequentiell.
4. Verankern Sie Meldepflichten vorab, indem Sie jeder Pflicht Auslöser, Frist und Verantwortlichen zuordnen und den Meldeweg mitüben.
5. Machen Sie Lessons Learned verbindlich: Jeder erhebliche Vorfall erzeugt nachverfolgbare Verbesserungen in Schutz, Detektion und Playbooks.
6. Unterlegen Sie kritische Respond-Ergebnisse mit Controls der IR-Familie aus SP 800-53, verbinden Sie Wiederherstellung mit Contingency Planning (CP, SP 800-34, RTO/RPO) und beteiligen Sie sich an Threat-Information-Sharing.

Relevante Normreferenzen

• NIST CSF 2.0 (NIST.CSWP.29, 26.02.2024): Function Respond (RS) mit vier Categories sowie die flankierenden Functions Detect (DE) und Recover (RC). Public Domain.
• NIST SP 800-61 Rev. 3 (April 2025, DOI 10.6028/NIST.SP.800-61r3): "A CSF 2.0 Community Profile", IR eingebettet in die CSF-2.0-Functions. Public Domain.
• NIST SP 800-53 Rev. 5: Kontrollkatalog, insbesondere die Familien Incident Response (IR, zehn Basis-Controls) und Contingency Planning (CP). Public Domain.
• NIST SP 800-34 Rev. 1: Contingency Planning, RTO/RPO als Wiederherstellungskennzahlen. Public Domain.
• Ergänzend: ISO/IEC 27035 (Incident Management); Edition vor Nutzung prüfen.