Recover: Wiederherstellung und Resilienz nach CSF und SP 800-34

Problem in der Praxis

Viele Organisationen haben Backups und ein Notfallhandbuch, aber keine belastbare Wiederherstellungsfähigkeit. Backups werden erstellt, aber selten unter realistischen Bedingungen zurückgespielt. Wiederanlaufzeiten sind oft nicht aus den Geschäftsfolgen abgeleitet, sondern technisch geschätzt. Und im Ernstfall zeigt sich, dass niemand verbindlich entscheidet, was zuerst zurückkommt.

Hinzu kommt eine Begriffsverwirrung. Begriffe wie Business Continuity, Disaster Recovery und Incident Response werden synonym gebraucht, obwohl sie unterschiedliche Reichweiten und Eigentümer haben. SP 800-34 unterscheidet bewusst mehrere Plan-Typen, weil sie verschiedene Fragen beantworten: Geschäftsprozess oder einzelnes System, IT-Wiederanlauf oder Personensicherheit, technische Bewältigung oder Krisenkommunikation. Wer diese Pläne vermengt, hat im Ernstfall ein dickes Dokument, aber keine klaren Verantwortlichkeiten und Auslöser.

CISO-Einordnung

Im CSF 2.0 ist Recover eine der sechs Functions; von insgesamt 22 Categories und 106 Subcategories entfallen auf Recover zwei Categories. Thematisch decken sie die Durchführung der Wiederherstellung (Incident Recovery Plan Execution, RC.RP) und die Wiederherstellungskommunikation (Incident Recovery Communication, RC.CO) ab. Recover ist damit eng mit Respond verzahnt: Respond stoppt und begrenzt den Vorfall, Recover bringt den Betrieb zurück und koordiniert die Kommunikation darüber. SP 800-61 Rev. 3 betont diese Verzahnung, indem es Incident Response nicht mehr als starren Phasenzyklus, sondern eingebettet in die CSF-Functions beschreibt, wobei die Bewältigung über Detect, Respond und Recover läuft.

Die operative Tiefe liefert SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems). Sein Siebenschritt-Prozess ist der rote Faden: (1) Notfallplanungs-Policy, (2) Business Impact Analysis (BIA), (3) präventive Controls, (4) Wiederherstellungsstrategien, (5) Erstellung des Information System Contingency Plan (ISCP), (6) Test, Training und Übungen, (7) Pflege. Die BIA ist das Herzstück: Sie leitet aus den Geschäftsfolgen die Zielwerte ab, allen voran das Recovery Time Objective (RTO, maximal akzeptable Ausfalldauer) und das Recovery Point Objective (RPO, maximal akzeptabler Datenverlust), ergänzt um MTD und WRT.

Mit Maßnahmen unterlegt wird das alles durch die Familie Contingency Planning (CP) in SP 800-53 Rev. 5, die 13 Basis-Controls von der Notfallplanung (CP-2) über Training (CP-3), Test (CP-4), Ausweichstandorte (CP-6/CP-7), System-Backup (CP-9) bis zu System Recovery and Reconstitution (CP-10) umfasst. Die zugehörigen Baselines stehen in SP 800-53B.

Umsetzungsperspektive

SP 800-34 unterscheidet acht Plan-Typen (Table 2-2), die sich nach Reichweite und Schutzziel trennen lassen. Sie als getrennte, aber verzahnte Dokumente mit eigenen Eigentümern zu führen, ist der Kern einer belastbaren Recovery-Architektur:

• Business Continuity Plan (BCP): erhält die geschäftskritischen Prozesse während und nach einer Störung; breitester Geltungsbereich.
• Continuity of Operations Plan (COOP): sichert die geschäftswesentlichen Funktionen, typischerweise an einem Ausweichstandort.
• Crisis Communications Plan: regelt die interne und externe Kommunikation in der Krise.
• Critical Infrastructure Protection (CIP) Plan: schützt kritische Infrastrukturkomponenten.
• Cyber Incident Response Plan: regelt die Reaktion auf Cyberangriffe gegen Systeme.
• Disaster Recovery Plan (DRP): IT-fokussierter Wiederanlauf nach einer größeren Störung, oft an einem Ausweichstandort.
• Information System Contingency Plan (ISCP): Wiederherstellung eines einzelnen Informationssystems nach einer Störung.
• Occupant Emergency Plan (OEP): schützt Personen und Sachwerte vor physischen Gefahren am Standort.

Die Reihenfolge der Umsetzung folgt dem Prozess, nicht der Dokumentenliste: erst Policy und BIA, daraus Zielwerte (RTO/RPO), daraus die Wiederherstellungsstrategie (etwa Backup-Konzept, Ausweichstandorte, redundante Telekommunikation), erst dann die Pläne selbst und schließlich Test und Pflege. Ein Plan, der nie unter realistischen Bedingungen geübt wurde, ist kein Plan, sondern eine Annahme.

Typische Fehler

1. Backups ohne nachgewiesene Wiederherstellung. Gesichert wird regelmäßig, ein vollständiger Restore-Test fehlt.
2. RTO und RPO werden technisch gesetzt statt aus der BIA und den Geschäftsfolgen abgeleitet.
3. Plan-Typen werden vermengt. Ein einziges Dokument soll BCP, DRP, ISCP und Krisenkommunikation gleichzeitig sein.
4. Recovery-Kommunikation (RC.CO) wird vergessen. Technisch läuft alles wieder, aber Kunden, Aufsicht und Mitarbeitende werden nicht koordiniert informiert.
5. Pläne werden geschrieben und abgelegt, aber nicht getestet, geschult und gepflegt; Schritt 6 und 7 des SP-800-34-Prozesses entfallen.

Risiken und Trade-offs

Resilienz kostet Geld, und ambitionierte Zielwerte kosten mehr. Ein RTO von Minuten verlangt heiße Redundanz und automatisiertes Failover; ein RTO von Tagen erlaubt schlankere Lösungen. Die Kunst liegt nicht in maximaler Verfügbarkeit für alles, sondern in einer aus der BIA begründeten Staffelung: kritische Prozesse schnell, weniger kritische langsamer. Eine pauschale Hochverfügbarkeit für alle Systeme bindet Budget, das anderswo fehlt.

Ein zweiter Trade-off betrifft die Plan-Pflege: Zu viele, zu detaillierte Pläne veralten schneller, als sie gepflegt werden können. Wenige, getestete, klar verantwortete Pläne schlagen ein umfangreiches, ungeprüftes Handbuch.

Entscheidungspunkte

• Sind RTO und RPO je kritischem Prozess aus einer BIA abgeleitet und von der Leitung bestätigt?
• Welche der acht Plan-Typen brauchen wir tatsächlich, und wer ist jeweils Eigentümer?
• Wie oft und unter welchen Bedingungen testen wir Wiederherstellung, inklusive vollständiger Restores?
• Wer entscheidet im Ernstfall über die Reihenfolge des Wiederanlaufs, und wie ist dieses Mandat dokumentiert?
• Wie ist die Recovery-Kommunikation an interne und externe Stakeholder sowie an Meldepflichten angebunden?

Praktische Empfehlungen

1. Starten Sie mit der BIA, nicht mit der Technik. Leiten Sie RTO und RPO aus den Geschäftsfolgen ab und lassen Sie sie von der Leitung bestätigen.
2. Trennen Sie die Plan-Typen nach SP 800-34 sauber und geben Sie jedem Plan einen Eigentümer, einen Geltungsbereich und einen Reviewzyklus.
3. Testen Sie Wiederherstellung regelmäßig und realistisch, inklusive vollständiger Restores und Tabletop-Übungen; behandeln Sie Test, Training und Pflege als feste Schritte (SP 800-34 Schritt 6 und 7).
4. Unterlegen Sie die Wiederherstellungsstrategie mit Controls der Familie CP aus SP 800-53 Rev. 5, insbesondere Backup (CP-9), Ausweichstandorte (CP-6/CP-7) und System Recovery (CP-10).
5. Planen Sie Recovery-Kommunikation (RC.CO) als eigenen Strang mit vorbereiteten Bausteinen, definierten Empfängern und Anbindung an Meldepflichten.

Relevante Normreferenzen

• NIST CSF 2.0 (NIST.CSWP.29, 26.02.2024): Function Recover (RC) mit zwei Categories zu Wiederherstellungsdurchführung und Wiederherstellungskommunikation. Public Domain.
• NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems): Siebenschritt-Prozess, BIA, RTO/RPO/MTD/WRT, acht Plan-Typen (Table 2-2). Public Domain.
• NIST SP 800-53 Rev. 5: Kontrollkatalog, insbesondere die Familie Contingency Planning (CP) mit 13 Basis-Controls; Baselines in SP 800-53B. Public Domain.
• NIST SP 800-61 Rev. 3: Incident Response, eingebettet in die CSF-Functions; Bewältigung über Detect, Respond und Recover. Public Domain.
• Ergänzend: ISO 22301 (Business Continuity Management); Edition vor Nutzung prüfen.