Testen, testen, testen – DORA’s Anspruch an Resilience-Übungen

Testen, testen, testen – DORA’s Anspruch an Resilience-Übungen

Resilienz ist kein Zufallsprodukt. Sie entsteht nicht allein durch technische Schutzmaßnahmen oder durch das Verfassen von Notfallplänen. Wirkliche Widerstandsfähigkeit zeigt sich erst im Ernstfall – und dafür müssen Unternehmen vorbereitet sein. DORA macht deshalb unmissverständlich klar: Digitale Resilienz ist nicht nur zu planen, sondern regelmäßig und systematisch zu testen. Der Grundgedanke ist einfach: Ein Unternehmen kann nur dann sicherstellen, dass es auf IKT-Störungen, Cyberangriffe oder sonstige digitale Notlagen wirksam reagiert, wenn es diese Szenarien vorher geübt hat. Dabei geht es nicht um symbolische Trockenübungen, sondern um realistische, teilweise sehr anspruchsvolle Tests, die technische Systeme, organisatorische Abläufe und menschliches Handeln gleichermaßen prüfen.

Kritische Funktionen kennen: Ohne Zielbild keine sinnvollen Übungen

Die Grundlage solcher Resilienztests ist eine klare Definition der kritischen Funktionen und Prozesse. Nur wenn bekannt ist, welche Systeme, Daten, Anwendungen und Kommunikationswege für den Geschäftsbetrieb unverzichtbar sind, lassen sich sinnvolle Übungsszenarien entwickeln. DORA verlangt, dass Unternehmen ihre kritischen Assets genau kennen und für diese gezielt Testpläne entwickeln. Das muss nicht immer die gesamte Organisation betreffen – oft sind fokussierte Tests auf einzelne, hochkritische Prozesse effektiver. Entscheidend ist, dass die Auswahl der Tests risikobasiert erfolgt: Je kritischer eine Funktion, desto intensiver und häufiger wird getestet. Dazu gehört auch eine Business-Impact-Analyse (BIA) mit RTO/RPO-Zielen sowie Schutzbedarfen entlang von Vertraulichkeit, Integrität und Verfügbarkeit – ergänzt um Resilienz, Nachvollziehbarkeit und Portabilität.

Testlandschaft nach DORA: Vom Hygiene-Check bis zum Angriff unter Realbedingungen

DORA unterscheidet verschiedene Testarten, die jeweils unterschiedliche Ziele verfolgen:

1) Technische Basistests (Hygiene)

Regelmäßige Schwachstellenscans, Konfigurationsprüfungen, Patch-Tests, Härtungs-Checks, Zertifikats- und Schlüsselrotationen. Sie liefern den Puls der Sicherheitsbasis und decken Abweichungen früh auf. Automatisierung (z. B. in CI/CD) erhöht Frequenz und Qualität.

2) Funktionale Wiederherstellungstests

Konkrete Failover-Übungen (aktiv/aktiv, aktiv/passiv), Backup-Restore mit Integritätsprüfung, Notbetriebsverfahren (Runbooks) sowie Wiederanlauf nach kontrollierten Ausfällen. Hier zählt nicht, ob ein Plan existiert, sondern ob er unter Zeitdruck funktioniert, wer welche Rolle übernimmt und welche Abhängigkeiten bremsen.

3) Szenariobasierte Übungen (Tabletop/Planspiele)

Teams bearbeiten gemeinsam ein realistisches Vorfallsszenario: Entscheidungen, Kommunikation, Koordination, Eskalation, externe Meldungen. Der Fokus liegt auf Organisation und Führung, nicht auf dem Terminal. Es wird sichtbar, ob Eskalationswege, Freigaben und Kommunikationslinien klar sind.

4) Angriffsnahe Tests (Red/Blue/Purple Teaming)

Red Teams agieren wie Angreifer, Blue Teams verteidigen mit bestehenden Mitteln; im Purple Teaming werden TTPs gemeinsam durchgespielt und Detection/Response gezielt verbessert. Ziele: Erkennungsfähigkeit, Eindämmung und Reaktionsgeschwindigkeit messbar machen.

5) Threat-Led Penetration Tests (TLPT)

Das „Königsformat“: Auf realer Bedrohungsinformation beruhende, behördlich flankierte Tests mit unabhängigen Spezialteams, klaren Rules of Engagement und Abschlussbericht. Für Institute mit hohem Risiko-Profil fordert DORA regelmäßige TLPT; für andere sind sie ein starker Hebel, die Wirksamkeit der gesamten Verteidigungskette zu belegen.

6) Chaos- und Resilienztests in Produktion-nahen Umgebungen

Kontrollierte Fehlerinjektion (z. B. Latenz, Paketverlust, Dienstabbrüche, CPU/Memory-Druck), Region-Failover-Proben, „Game Days“ für Technik und Fachbereich. Ziel: robuste Architektur und eingespielter Betrieb, nicht Heldentaten im Ausnahmezustand.

Testplanung: Risikobasiert, kalendarisch, wiederholbar

Ein wirksames Programm lebt von Planbarkeit:

• Testkalender: Quartalsweise Tabletop-Übungen, halbjährliche DR-Tests für Kernservices, jährliche (oder risikobasierte) Red/Purple-Team-Kampagne, TLPT nach Vorgaben und Risikoprofil, monatliche Hygiene-Checks.
• Scope-Matrix: Zuordnung von Services/Assets zu Testarten und Frequenzen; je höher die Kritikalität, desto dichter das Netz.
• Abhängigkeiten: Lieferanten, Identitätsdienste, Netz-Perimeter, Zahlungsverkehr, Kernbank, Trading, Reporting – kritische Ketten gehören immer mit ins Szenario.
• Testdaten: DSGVO-konforme synthetische Daten oder minimierte, pseudonymisierte Datensätze; Lösch- und Bereinigungsprozesse nach den Übungen verpflichtend.
• Security by Design: Bereits in Architektur- und Projektphasen planen, wie später getestet wird (z. B. schaltbare Feature-Flags, simulierte Ausfallschalter, exportierbare Konfigurationen).

Rollen, Mandate und das „War-Room“-Prinzip

Tests sind nur so gut wie die Verantwortlichkeiten:

• Sponsor (C-Level): Verankert Ziele, Ressourcen, Toleranzen, nimmt Ergebnisse in Management-Reviews ab.
• Testleitung/Exercise Director: Plant, koordiniert, dokumentiert, misst.
• Incident Commander (IC): Führt in szenario- und vorfallnahen Übungen.
• Regulatory Liaison: Stellt DORA-kompatible Meldestrukturen sicher; denkt DSGVO/NIS gleich mit.
• Forensics Lead/SOC Lead: Detection, Beweissicherung, IoCs, Zeitleisten.
• IT Operations/BCM Lead: Notbetrieb, Wiederanlauf, Kapazitätssteuerung.
• Comms Lead: Interne/Externe Kommunikation, Q&A, Medien, Kundenbriefe.
• Business Owner: Auswirkungen auf Kund:innen/Prozesse, Service-Priorisierung.
• Supplier Manager: Einbindung kritischer Dienstleister, Testnachweise, Eskalationen.

Alle Rollen benötigen Stellvertretungen und Mandate, um ohne Wartezeit zu entscheiden.

Success-Kriterien und Metriken: Was „gut“ konkret bedeutet

Ohne Messung kein Fortschritt. Typische KPIs/KRIs:

• Time to Detect (MTTD) und Time to Recover (MTTR) je Serviceklasse.
• Time to Classify / Time to Notify (bis Schweregrad und Erstmeldung).
• RTO-/RPO-Erfüllung bei DR-Tests, Integrität des Restores (Checksummen).
• Detection Coverage (Prozent der relevanten TTPs, die Alarme auslösen).
• Containment Time (seitliche Bewegung bis Isolation).
• Kommunikationslatenz (Minuten bis Management-/Kundeninformation).
• Lieferanten-Response (Zeit bis Erstreaktion, Qualität der Incident-Daten).
• Fix-Throughput (Abarbeitung von Findings innerhalb vereinbarter Fristen).
• Übungsdichte (Tabletop/DR/Red-Team pro Quartal), Wiederholfehler-Quote.

Definieren Sie vorab Akzeptanzkriterien (z. B. „RTO ≤ 2 h für Service X“, „Alarm ≤ 10 Minuten bei Y“). Ergebnisse gehören in Management-Reviews mit klaren Entscheidungen (Budget, Prioritäten, Termine).

Dokumentation: Evidenz, die trägt – intern und gegenüber Aufsicht

DORA verlangt nachvollziehbare Dokumentation: Zielsetzung, Umfang, Rollen, Zeitplan, Ausgangslage, Durchführung, Beobachtungen, Metriken, Abweichungen, Root-Cause-Analysen, Lessons Learned, Maßnahmenplan mit Ownern und Fälligkeiten, Re-Test-Plan. Gute Doku ist kurz & klar im Executive Summary und detailtief im Anhang (Artefakte, Logauszüge, Bildschirmfotos, Konfig-Diffs). Versionieren Sie Berichte, verknüpfen Sie Maßnahmen mit Tickets und halten Sie Evidenzpfade (Chain of Custody bei forensischen Materialien) sauber.

Tabletop-Beispiel: Vom Phishing zur DORA-Meldung

Szenario (90 Minuten): Ein externer Zahlungsdienst meldet Unregelmäßigkeiten. Parallel erkennt das SOC ungewöhnliche API-Aufrufe über einen kompromittierten Partnerzugang.
Ziele: Meldefähigkeit (DORA/DSGVO), Eskalation, Kommunikationsfähigkeit, Lieferanteneinbindung, Entscheidungsfreude.
Injects: Presseanfrage, Kunde mit Ausfallmeldung, widersprüchliche Log-Zeitstempel, Lieferant verzögert Antwort.
Erwartet: Schweregrad in ≤ 30 Min., Erstmeldung ≤ 2 h, konsistente Kernbotschaften, forensische Sicherung, Notbetriebsweg für Zahlungspfad, Lieferanten-SPOC aktiv.
Bewertung: Zeitlinien, Qualität der Entscheidungen, Vollständigkeit der Meldung, Konsistenz der Kommunikation, Disziplin in der Dokumentation.

DR-Probe: Restore zählt, nicht Backup

Backups sind nur so gut wie der getestete Restore. Mindestumfang:

• Voll- und Teildaten-Restores mit Prüfsummenabgleich.
• Konfigurations- und Geheimnis-Recoveries (z. B. KMS-Keys, Secrets).
• Isolierter Test (kein Rückschreiben in Produktion), anschließend Produktion-nahe Generalprobe mit Zeitvorgabe.
• Anwendungs-Kohärenz (Transaktionskonsistenz, Reconciliation).
• Abhängigkeitsprüfung (DNS, IAM, Messaging, Fileshares).
• Playbooks aktualisieren, Lessons Learned festhalten, Re-Test terminieren.

Threat-Led Penetration Test (TLPT): Ablauf in sieben Schritten

1. Scoping & Governance: Ziele, Systeme, rechtliche Rahmenbedingungen, Rules of Engagement, Abstimmung mit Aufsicht.
2. Threat Intelligence: Relevante TTPs (z. B. Branchenkampagnen, Missbrauch plausibler Lieferketten).
3. Red-Team-Phase: Initialzugang, Privilege Escalation, Lateral Movement, Zielaktionen – ohne unnötige Störung.
4. Blue-Team-Beobachtung: Erkennungs-/Reaktionsleistung messen (teils bewusst „Black Box“, später Purple-Iterationen).
5. Hot Wash: Sofort-Feedback, priorisierte Findings, Quick Wins.
6. Final Report: Technische Details, Geschäftsbezug, Evidenz, Remediations mit Prioritäten.
7. Re-Test & Governance: Nachweis umgesetzter Maßnahmen, Lessons Learned in ISMS/BCM integrieren.

Lieferanten im Test: Shared Responsibility praktisch leben

Kritische Drittparteien gehören in die Übungen – vertraglich abgesichert:

• Vorfall-Meldefristen und Inhalte, 24/7-SPOCs, gemeinsame War-Rooms.
• DR-/Failover-Proben mit Provider-Team (inkl. Einblick in deren RCA).
• Telemetrie-Exports (Logs, Events) in eigenes SIEM; APIs für Gesundheitsdaten.
• Exit-Trockenübungen: Datenexport/-Import, Konfigurations-Übernahme, Umschaltung auf Alternativ-Pfad.
• Sub-Prozessor-Transparenz: Einbindung relevanter Viertparteien, wenn angemessen.

Recht & Ethik im Test: Grenzen wahren, Wirkung maximieren

• DSGVO: Minimierte/synthetische Testdaten, Zweckbindung, Löschkonzepte.
• Betriebsvereinbarungen: Keine Personalkontrolle, sondern Prozess-/Systemprüfung; Anonymisierung bei Auswertungen.
• Genehmigungen: Klare Freigaben für invasive Tests, Dokumentation der Erlaubnisse.
• Sicherheitsnetze: „Kill Switches“, Out-of-Band-Kommunikation, Rollback-Pläne.
• Transparenz: Frühzeitige Information relevanter Stakeholder – ohne Details preiszugeben, die Tests verfälschen.

Integrationen: ISMS, BCM, Risiko – ein Kreislauf

Tests sind kein Fremdkörper, sondern Teil eines Regelkreises:

• ISMS (ISO 27001): Findings → Korrekturmaßnahmen → SoA-Anpassungen → interne Audits.
• BCM (ISO 22301): Übungen speisen BIA-Updates, RTO/RPO-Anpassungen, Notbetriebspläne.
• Risikomanagement: Neue Szenarien, geänderte Wahrscheinlichkeiten/Impacts, aktualisierte Toleranzen.
• Security-Engineering: Detection-Use-Cases, Hardening, Architektur-Verbesserungen aus Purple-Erkenntnissen.

Maturity-Modell: Von ad-hoc zu adaptiv

• Level 1 – Ad-hoc: Einzeltests, kaum Doku, wenig Management-Sicht.
• Level 2 – Definiert: Kalender, Rollen, Vorlagen; unregelmäßige Auswertung.
• Level 3 – Gemanagt: Kennzahlen, regelmäßige Reviews, Re-Tests, Lieferanten eingebunden.
• Level 4 – Integriert: Vollverzahnt mit ISMS/BCM/Risk; automatisierte Hygiene-Checks; Game Days.
• Level 5 – Adaptiv: Threat-intel-gestützt, kontinuierliche Verbesserung, automatisierte Resilienz-Checks in CI/CD, proaktives Portfoliosteuern.

Typische Stolpersteine – und wie man sie umschifft

• „Papier-Notfallpläne“ ohne Übung → Lösung: Klein anfangen, vierteljährlich Tabletop, halbjährlich DR.
• Zu breite, unkonkrete Szenarien → Lösung: Fokus auf 1–2 kritische Ketten, klare Erfolgskriterien.
• Technik ohne Organisation → Lösung: Comms/Legal/Business verpflichtend in Szenarien.
• Keine Re-Tests → Lösung: Jede Maßnahme mit Termin für Wirksamkeitsnachweis.
• Lieferanten außen vor → Lösung: Vertragsklauseln, Scorecards, gemeinsame Übungen.
• Daten-/Loglücken → Lösung: NTP-Pflicht, WORM/Append-Only, Sensor-Abdeckung messen.
• Schuldzuweisung statt Lernen → Lösung: „Blameless“-Postmortems, psychologische Sicherheit, Fokus auf Systeme, nicht auf Personen.

Beispiel-Jahresplan (kompakt)

• Q1: Tabletop „Cloud-Region down“ (inkl. Comms), Hygiene-Sprint (Scans/Hardening), DR-Test Kernservice A, Purple-Workshop (3 TTPs).
• Q2: Red-Team-Kampagne (4 Wochen), Restore-Generalprobe, Lieferanten-DR-Drill, Re-Test Q1-Findings.
• Q3: Tabletop „Datenexfiltration durch Drittpartei“, Chaos-Day (Latenz/Throttling), DR-Test Kernservice B, Exit-Trockenübung SaaS X.
• Q4: TLPT (falls im Scope), konzernweites Comms-/Crisis-Exercise, Jahres-RCA-Review, Plan/QKPIs für Folgejahr.

Tools, die das Testen beschleunigen

• Case-/Exercise-Management: Planung, Injects, Aufgaben, Artefakte, Berichte.
• SIEM/XDR: Szenario-Use-Cases, Detektionslücken sichtbar machen.
• Chaos-Frameworks: Last-/Fehlerinjektion, automatisierte Resilienz-Checks.
• BCM-Suites: RTO/RPO-Planung, Runbooks, Ressourcenmanagement.
• Vault/KMS: Key-Rotation-Tests, Notfallzugriffe („Break Glass“).
• Synthetic Monitoring/APM: Nutzernahe Indikatoren in Übungen.

Kultur: Üben schafft Vertrauen – innen und außen

Resilienztests sind auch Kulturarbeit. Wer regelmäßig übt, senkt Stressspitzen, fördert Meldekultur und beschleunigt Entscheidungen. Kund:innen und Aufsicht vertrauen eher einem Unternehmen, das seine Meldefähigkeit, Wiederanlaufzeiten und Kommunikationsstärke belegen kann. Führungskräfte müssen sichtbar hinter Übungen stehen: Termine sind „heilig“, Ergebnisse haben Konsequenzen, Erfolge werden geteilt.

Von der Übung zur Verbesserung: Der Lernzyklus

Nach jeder Übung: Hot-Wash (sofortige Eindrücke), binnen 10 Werktagen der Detailbericht mit priorisiertem Maßnahmenplan, spätestens nach 90 Tagen Re-Test der wichtigsten Punkte. Wiederholte Befunde fließen in Architektur-Roadmaps und Risikotoleranzen ein. So entsteht ein kontinuierlicher Verbesserungsprozess – genau das, was DORA fordert.

Fazit: Testen ist die Brücke zwischen Plan und Realität

DORA verfolgt mit der Testpflicht ein klares Ziel: Sicherheit und Resilienz sollen keine theoretischen Versprechen bleiben, sondern im Ernstfall belastbar sein. Wer seine Organisation regelmäßig auf die Probe stellt, erhöht nicht nur die Chance, eine Krise zu überstehen, sondern baut auch Vertrauen auf – bei Kunden, Partnern und Regulierern. Resilienztests sind keine lästige Pflicht, sondern eine Investition in Stabilität, Handlungsfähigkeit und Wettbewerbsvorteile in einer Welt, in der digitale Störungen jederzeit Realität werden können. Kurz: Üben, messen, lernen, verbessern – und wieder von vorn. So wird Resilienz vom Schlagwort zur gelebten Fähigkeit.