Incident-Response-Plan unter Realbedingungen testen: der Belastungstest

Fast jedes Unternehmen ab einer gewissen Größe hat einen Incident-Response-Plan. Er liegt im Dokumentenmanagementsystem, trägt das Datum der letzten Revision und beschreibt, wer bei einem Sicherheitsvorfall was zu tun hat. Die unbequeme Frage lautet: Wann wurde dieser Plan zuletzt gegen einen echten Angreifer geprüft – nicht in einer Besprechung, sondern unter Zeitdruck, mit unvollständigen Informationen und mit Menschen, die nicht wissen, dass es eine Übung ist?

Aus unserer Erfahrung als Red Team scheitern Pläne selten am Inhalt. Sie scheitern an der Lücke zwischen Dokument und Wirklichkeit: Alarme, die niemand sieht, Eskalationsketten, die am Wochenende ins Leere laufen, Krisenstäbe, die erst gebildet werden, wenn der Angreifer schon verschlüsselt. Dieser Beitrag erklärt, warum das so ist, wie ein Red Teaming als Belastungstest für Playbooks, Eskalation und Krisenstab dient, welche Rolle das Control Team spielt, worin sich Tabletop-Übung, Red Teaming und Purple Teaming unterscheiden und mit welchen Kennzahlen Sie Ihre Reaktionsfähigkeit messen. Eine Checkliste zur IR-Readiness schließt den Beitrag ab.

Warum Pläne auf dem Papier versagen

Ein Incident-Response-Plan entsteht meist in ruhigen Zeiten und beschreibt einen idealisierten Ablauf: Ein Alarm wird erkannt, bewertet, klassifiziert, eskaliert, eingedämmt. In der Realität fehlt an jeder Stelle etwas, das der Plan voraussetzt.

• Der Alarm kommt nicht an. Das SIEM erzeugt täglich hunderte Meldungen, die relevante geht in der Masse unter oder wird als Fehlalarm geschlossen. In der CISA-Red-Team-Analyse AA23-059A erreichte das Team bei einer als reif geltenden Organisation den Domain Admin, obwohl das EDR mehrfach Alarm schlug – die Alarme blieben ohne Reaktion.
• Die Eskalation setzt Wissen voraus, das niemand hat. Ein Analyst sieht eine auffällige Anmeldung. Ist das ein Vorfall oder ein Administrator im Nachtdienst? Der Plan verlangt eine Klassifizierung, die ohne Kontext nicht möglich ist, und der Analyst wartet lieber ab, als einen Vorstand nachts zu wecken.
• Rollen sind Namen, keine Menschen. Der Plan nennt den „Incident Manager“; die Person ist im Urlaub, der Stellvertreter kennt den Plan nicht, die Telefonnummer im Dokument ist veraltet.
• Technische Annahmen stimmen nicht mehr. Das Playbook sieht vor, ein System vom Netz zu nehmen – das System ist inzwischen in der Cloud, und niemand weiß, wer das Recht hat, dort eine Instanz zu stoppen.
• Der Krisenstab kennt sich nicht. Geschäftsführung, Recht, Kommunikation und IT treffen sich zum ersten Mal in der Krise und müssen Entscheidungen über Lösegeld, Meldung und Abschaltung treffen, ohne je geübt zu haben.

Keiner dieser Punkte steht im Plan. Alle werden erst sichtbar, wenn ein Angreifer die Organisation tatsächlich unter Druck setzt.

Das Red Team als Belastungstest

Ein Red Teaming ist der einzige Test, der einen Incident-Response-Plan unter den Bedingungen prüft, für die er geschrieben wurde: verdeckt, realistisch, ohne Vorwarnung an die Verteidiger. Nur ein kleines Control Team im Unternehmen weiß vom Test. SOC, IT-Betrieb und Krisenstab erleben den Angriff als echten Vorfall – bis zu dem Punkt, an dem das Control Team auflöst.

Für die Prüfung des Plans heißt das konkret:

• Playbooks werden ausgelöst, nicht gelesen. Erkennt das SOC die Techniken, die das Red Team einsetzt, muss es das passende Playbook anwenden – mit allen Lücken, die darin stecken.
• Die Eskalationskette wird durchlaufen. Wir messen, wie lange es vom ersten Alarm bis zur Information des CISO und der Geschäftsführung dauert und wo die Kette abreißt.
• Der Krisenstab wird einberufen – oder nicht. In vielen Tests stellt sich heraus, dass der Krisenstab erst zusammentritt, wenn eine Auswirkung sichtbar ist, nicht, wenn ein Angreifer im Netz erkannt wurde.
• Entscheidungen werden sichtbar. Wer entscheidet, ob ein Produktionssystem isoliert wird? Wer darf externe Forensik beauftragen? Was passiert, wenn die Person nicht erreichbar ist?

Das Ergebnis ist eine Timeline mit Zeitstempeln auf beiden Seiten: Was hat das Red Team wann getan, und was hat die Organisation wann bemerkt und entschieden? Diese Gegenüberstellung ist der ehrlichste Bericht über die Wirksamkeit eines IR-Plans, den es gibt.

Die Rolle des Control Teams

Das Control Team ist das eingeweihte Bindeglied zwischen Red Team und Unternehmen. Es umfasst typischerweise den CISO oder eine von ihm benannte Person, einen Vertreter des IT-Betriebs und je nach Scope Recht oder Compliance. Beim Test der Incident Response hat es drei Aufgaben, die über die übliche Steuerung hinausgehen.

Erstens beobachtet es die Reaktion der Organisation, ohne einzugreifen. Das verlangt Disziplin: Wenn das SOC einen Alarm falsch bewertet, ist die Versuchung groß, einen Hinweis zu geben. Genau das würde das Ergebnis verfälschen.

Zweitens schützt es den Betrieb. In den Rules of Engagement ist festgelegt, welche Schritte das Red Team nur mit Freigabe geht und wann der Test abgebrochen wird – etwa wenn ein echter Angreifer entdeckt wird oder die Reaktion der Organisation den Betrieb zu gefährden droht. Wie solche Regeln aussehen, beschreibt der Beitrag Rules of Engagement für einen sicheren Red-Team-Einsatz.

Drittens steuert es die Auflösung. Wann erfährt das Blue Team, dass es ein Test war? Zu früh, und die Reaktion wird nicht vollständig durchlaufen; zu spät, und die Organisation verbrennt Ressourcen oder meldet den Vorfall nach außen. Für Unternehmen unter NIS2 oder DORA ist dieser Punkt wichtig: Die Meldefristen beginnen mit der Kenntnis eines erheblichen Vorfalls, und das Control Team muss sicherstellen, dass eine Meldung an die Behörde rechtzeitig als Übung gekennzeichnet oder vermieden wird.

Tabletop, Red Teaming oder Purple Teaming

Drei Formate prüfen die Incident Response auf unterschiedliche Weise. Sie ersetzen einander nicht, sondern bauen aufeinander auf.

Eine sinnvolle Reihenfolge: Tabletop-Übung, um Rollen und Entscheidungswege zu klären; Red Teaming, um den Plan unter Realbedingungen zu prüfen; Purple Teaming, um die aufgedeckten Erkennungslücken zu schließen. Wer mit dem Red Teaming beginnt, ohne je eine Tabletop-Übung gemacht zu haben, bekommt meist ein Ergebnis, das er sich hätte denken können – und zahlt dafür einen Preis, der in Purple Teaming besser investiert gewesen wäre. Ob Ihre Organisation bereit ist, klärt der Beitrag Wann ist mein Unternehmen bereit für Red Teaming.

Kennzahlen: Erkennung, Eskalation, Eindämmung

Ein Red Teaming liefert Zeiten, die sich über Jahre vergleichen lassen. Drei davon sind für die Incident Response entscheidend:

1. Zeit bis zur Erkennung (MTTD): Vom ersten Angriffsschritt bis zum ersten Alarm, der von einem Menschen gesehen wird. Nicht bis zum ersten Log-Eintrag – der nützt niemandem, wenn ihn keiner liest.
2. Zeit bis zur Eskalation: Vom Alarm bis zur Entscheidung, dass es sich um einen Vorfall handelt, und zur Information der Verantwortlichen. Hier zeigt sich, ob Playbooks und Eskalationskette funktionieren.
3. Zeit bis zur Eindämmung (MTTR): Von der Eskalation bis zu dem Punkt, an dem der Angreifer keinen Handlungsspielraum mehr hat – Konten gesperrt, Systeme isoliert, Persistenz entfernt.

Als Maßstab hat sich die CrowdStrike-Faustregel 1-10-60 etabliert: eine Minute bis zur Erkennung, zehn Minuten bis zur Bewertung, sechzig Minuten bis zur Eindämmung. Der Grund für diese Härte ist die Geschwindigkeit der Angreifer. Laut CrowdStrike Global Threat Report 2026 lag die durchschnittliche Breakout-Time – die Zeit vom ersten kompromittierten System bis zur Bewegung auf das nächste – bei 29 Minuten, im schnellsten beobachteten Fall bei 27 Sekunden. Wer nach einer Stunde eindämmt, hat den Angreifer im Durchschnitt bereits auf mehreren Systemen.

Die Gegenseite der Statistik: Laut Mandiant M-Trends 2026 lag die mediane Dwell Time, also die Zeit, die Angreifer unentdeckt im Netz verbringen, bei 14 Tagen; nur 52 Prozent der Vorfälle wurden intern erkannt, der Rest durch Dritte. IBM beziffert für Deutschland im Cost of a Data Breach Report 2025 im Schnitt 170 Tage bis zu Erkennung und Eindämmung. Zwischen 1-10-60 und diesen Werten liegt der Raum, in dem Incident Response über die Schadenshöhe entscheidet. Wie Sie Ihr SOC auf die 29 Minuten ausrichten, behandelt der Beitrag Breakout-Time 29 Minuten: Was das für Ihr SOC bedeutet.

Checkliste IR-Readiness

Die folgenden Punkte prüfen wir vor einem Red Teaming gemeinsam mit dem Control Team. Jeder Punkt, der mit Nein beantwortet wird, ist eine Erkenntnis, die Sie ohne Test gewinnen – und die vor dem Test behoben werden sollte, damit der Test mehr liefert als das Offensichtliche.

1. Der IR-Plan wurde in den letzten zwölf Monaten überarbeitet, und alle genannten Personen wissen, dass sie darin stehen.
2. Für jede Rolle gibt es eine benannte Stellvertretung mit aktuellen Kontaktdaten, auch außerhalb der Geschäftszeiten.
3. Es existiert eine Alarmierungskette, die ohne das Unternehmensnetz funktioniert – etwa über private Mobilnummern oder einen separaten Messenger, falls E-Mail und Telefonanlage betroffen sind.
4. Die Kriterien, ab wann ein Ereignis ein Vorfall ist und wer das entscheidet, sind schriftlich festgelegt und dem SOC bekannt.
5. Für die häufigsten Szenarien – Ransomware, kompromittiertes Konto, Datenabfluss, Business E-Mail Compromise – gibt es Playbooks mit konkreten technischen Schritten.
6. Das SOC hat die Berechtigung, Konten zu sperren und Systeme zu isolieren, ohne auf eine Freigabe warten zu müssen; die Grenzen dieser Berechtigung sind definiert.
7. Es ist festgelegt, wer externe Forensik und Rechtsberatung beauftragen darf und wie der Vertrag dafür aussieht – idealerweise vorab vereinbart.
8. Die Meldepflichten nach NIS2, DORA oder DSGVO sind mit Fristen, Zuständigkeit und Meldeweg im Plan hinterlegt.
9. Logs der kritischen Systeme sind zentral gespeichert, für Angreifer nicht löschbar und für die Zeiträume verfügbar, die eine Untersuchung braucht.
10. Backups sind offline oder unveränderlich, und die Wiederherstellung wurde innerhalb des letzten Jahres tatsächlich geprobt.
11. Der Krisenstab hat in den letzten zwölf Monaten eine Tabletop-Übung durchgeführt, und die Ergebnisse sind in den Plan eingeflossen.
12. Die Kommunikationsvorlagen für Mitarbeitende, Kunden, Behörden und Presse liegen vor und sind mit Recht und Kommunikation abgestimmt.

Fazit

Ein Incident-Response-Plan beweist seinen Wert nicht im Dokumentenmanagementsystem, sondern in den ersten Stunden eines echten Angriffs. Tabletop-Übungen klären Rollen, Purple Teaming schärft die Erkennung – aber nur ein verdecktes Red Teaming zeigt, ob Alarme ankommen, Eskalationsketten halten und der Krisenstab rechtzeitig zusammentritt. Die Kennzahlen Zeit bis Erkennung, Eskalation und Eindämmung machen das Ergebnis messbar und über Jahre vergleichbar. Wenn Sie Ihren Plan unter Realbedingungen prüfen möchten, finden Sie unter Red Teaming, wie wir einen solchen Belastungstest aufsetzen – mit einem Control Team, das den Betrieb schützt, und einer Timeline, die beide Seiten zeigt.

Quellen

• CrowdStrike, Global Threat Report 2026
• Mandiant / Google Cloud, M-Trends 2026
• IBM Security und Ponemon Institute, Cost of a Data Breach Report 2025
• CISA, Cybersecurity Advisory AA23-059A: CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks, 2023, cisa.gov
• NIST, Special Publication 800-61 Rev. 3, Incident Response Recommendations and Considerations, 2025, nist.gov

Häufige Fragen zum Thema