Ein Beitrag von Uwe Graf, Head of Consulting bei EasiRun.
Wenn heute über Cybersecurity gesprochen wird, stehen häufig Prävention und Erkennung im Mittelpunkt. Zugriffe werden kontrolliert, Daten verschlüsselt, Netze segmentiert und verdächtige Aktivitäten möglichst früh identifiziert. All das ist notwendig, beantwortet aber noch nicht die Frage, die nach einem erfolgreichen Angriff entscheidend wird: Wie bringt ein Unternehmen seine geschäftskritischen Systeme wieder in einen Zustand, dem es tatsächlich vertrauen kann?
Genau hier beginnt der Unterschied zwischen klassischem Backup und Cyber Resilience.
Ein Backup beantwortet zunächst die Frage, ob eine Kopie der Daten vorhanden ist. Nach einem Cybervorfall reicht diese Information jedoch nicht aus, denn dann muss zusätzlich geklärt werden, ob die gesicherten Daten überhaupt noch sauber sind, wann eine mögliche Manipulation begonnen hat und ob sich aus dem gewählten Stand wieder ein konsistenter Geschäftsbetrieb herstellen lässt.
Für Banken, Versicherungen und andere Unternehmen mit geschäftskritischen Mainframe-Anwendungen ist dieser Unterschied besonders wichtig. Dort besteht ein Geschäftsprozess selten aus einem einzelnen Datenbestand. Datenbanken, VSAM-Dateien, CICS-Anwendungen, Batch-Verarbeitung, MQ-Verbindungen, Scheduler und zahlreiche Schnittstellen greifen ineinander. Die erfolgreiche Wiederherstellung einer einzelnen Komponente bedeutet deshalb noch lange nicht, dass der gesamte Prozess anschließend wieder zuverlässig funktioniert.
Cyber Resilience geht über Datensicherung hinaus
Ein klassisches Backup bleibt unverzichtbar. Es schützt vor technischen Defekten, Bedienfehlern und vielen anderen Störungen. Bei einem Cyberangriff kommt jedoch eine zusätzliche Schwierigkeit hinzu: Der Zeitpunkt, an dem ein Angriff entdeckt wird, muss nicht mit dem Zeitpunkt übereinstimmen, an dem die Manipulation begonnen hat.
Ein Angreifer kann sich bereits über Tage oder Wochen in einer Umgebung bewegen, bevor der eigentliche Vorfall sichtbar wird. In dieser Zeit können Daten verändert oder Systeme kompromittiert worden sein, ohne dass dies unmittelbar auffällt. Werden regelmäßig Sicherungen erzeugt, können damit auch technisch vollkommen korrekte Backups entstehen, die bereits manipulierte Informationen enthalten.
Damit verschiebt sich die zentrale Frage. Es geht nicht mehr nur darum, ob eine Sicherung vorhanden ist, sondern darum, welcher Sicherungsstand noch vertrauenswürdig ist.
Cyber Resilience verbindet deshalb Schutz, Erkennung und Wiederherstellung. Daten müssen möglichst unveränderbar gesichert werden, ungewöhnliche Veränderungen sollten früh erkannt werden und für den Ernstfall braucht es einen getesteten Weg zurück zu einem bekannten und verifizierten Zustand.
Auch NIST behandelt Recovery ausdrücklich als eigenständigen Bestandteil einer Cybersecurity-Strategie und empfiehlt, Wiederherstellungsverfahren regelmäßig zu planen und zu testen. Der entsprechende „Guide for Cybersecurity Event Recovery“ ist unter https://www.nist.gov/publications/guide-cybersecurity-event-recovery verfügbar.
Gerade für Finanzunternehmen wird dieser Ansatz zusätzlich durch regulatorische Vorgaben relevant. DORA verlangt dokumentierte Backup-, Restore- und Recovery-Verfahren und sieht regelmäßige Tests dieser Prozesse vor. Bei einer Wiederherstellung muss außerdem sichergestellt werden, dass die Datenintegrität erhalten bleibt. Die Verordnung ist unter https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2022.333.01.0001.01.ENG abrufbar.
Damit wird klar, dass Cyber Resilience nicht einfach ein anderes Wort für Backup ist. Es geht darum, geschäftskritische Funktionen nach einem Vorfall kontrolliert und nachvollziehbar wieder aufnehmen zu können.
Die schwierigste Frage lautet oft: Welcher Stand ist noch sauber?
Nach einem klassischen technischen Ausfall ist der Wiederherstellungszeitpunkt häufig klar. Fällt eine Komponente um 10:15 Uhr aus, liegt es nahe, einen geeigneten Stand kurz vor diesem Zeitpunkt wiederherzustellen.
Bei einem Cyberangriff kann die Situation völlig anders aussehen. Wird eine auffällige Datenveränderung erst am Freitag entdeckt, obwohl die eigentliche Kompromittierung bereits am Montag begonnen hat, wäre eine Sicherung vom Donnerstag zwar aktuell, möglicherweise aber längst betroffen.
Genau deshalb reicht es nicht aus, einfach das jüngste Backup zurückzuspielen.
IBM verfolgt mit IBM Z Cyber Vault einen Ansatz, bei dem unveränderliche Sicherungskopien, Validierung und Recovery enger miteinander verbunden werden. IBM beschreibt Cyber Vault als Framework für geschäftskritische IBM-Z-Umgebungen, das unter anderem isolierte und unveränderliche Kopien, automatisierte Validierung und eine gesonderte Umgebung für Analyse und Wiederherstellung kombiniert. Weitere Informationen finden sich unter https://www.ibm.com/de-de/products/z-cyber-vault.
Eine wichtige technische Grundlage kann dabei DS8000 Safeguarded Copy bilden. Diese Kopien sind so ausgelegt, dass sie vom Hostsystem nicht direkt verändert werden können und sich deshalb besser gegen Manipulationen aus der Produktionsumgebung schützen lassen. IBM beschreibt dieses Verfahren unter https://www.ibm.com/docs/en/csm/6.3.18?topic=copy-safeguarded-in-ds8000.
Der entscheidende Punkt ist allerdings, dass auch eine unveränderliche Kopie noch nicht automatisch eine saubere Kopie ist. Wenn die Daten bereits vor ihrer Erstellung manipuliert wurden, bleibt die Manipulation auch in einer unveränderlichen Sicherung erhalten. Deshalb muss ein Recovery-Konzept zusätzlich die Möglichkeit vorsehen, mehrere Zeitpunkte zu untersuchen und daraus einen belastbaren Wiederherstellungspunkt abzuleiten.
Gerade dieser Unterschied zwischen „vorhanden“ und „vertrauenswürdig“ macht Cyber Recovery wesentlich anspruchsvoller als eine klassische Wiederherstellung nach einem Hardwarefehler.
Erkennung und Wiederherstellung gehören zusammen
Je früher ein Cybervorfall erkannt wird, desto einfacher wird in der Regel auch die Wiederherstellung. Bleibt eine Manipulation über längere Zeit unentdeckt, wächst nicht nur der Zeitraum, der untersucht werden muss. Es steigt häufig auch die Zahl der möglicherweise betroffenen Systeme, Datenbestände und Abhängigkeiten.
Mit IBM zSecure Detection hat IBM eine Lösung vorgestellt, die ungewöhnliche Aktivitäten unter z/OS gezielter erkennen und untersuchen soll. Dazu gehören beispielsweise auffällige Zugriffe auf Datensätze, privilegierte Aktivitäten oder ungewöhnliche kryptografische Vorgänge. IBM beschreibt den Ansatz unter https://www.ibm.com/products/zsecure-detection.
Für eine Resilience-Strategie ist diese Verbindung wichtig, weil Detection und Recovery nicht getrennt betrachtet werden sollten. Je schneller sichtbar wird, dass etwas Ungewöhnliches passiert, desto besser lässt sich eingrenzen, welche Datenstände noch als vertrauenswürdig gelten können.
In hybriden Umgebungen kommt hinzu, dass ein Angriff nicht an Plattformgrenzen haltmacht. Ein kompromittiertes Benutzerkonto oder ein manipuliertes System kann Aktivitäten über Mainframe, Distributed Systems und Cloud hinweg verursachen. Deshalb sollten auch Mainframe-Ereignisse Teil eines übergreifenden Security-Operations-Modells sein.
Die eigentliche Herausforderung beginnt nach dem Restore
Selbst wenn ein sauberer Datenbestand gefunden und technisch wiederhergestellt wurde, ist noch nicht automatisch sichergestellt, dass der Geschäftsprozess wieder funktioniert.
Nehmen wir eine Zahlungsverkehrsanwendung. Wird eine Datenbank auf einen früheren Stand zurückgesetzt, muss anschließend geklärt werden, welche Zahlungen in der Zwischenzeit bereits an externe Systeme übermittelt wurden, welche Transaktionen erneut verarbeitet werden dürfen und ob andere beteiligte Systeme noch zum wiederhergestellten Zustand passen.
Bei Versicherungen entstehen vergleichbare Fragen etwa bei Schadenfällen, Beitragsbuchungen oder Vertragsänderungen. Auch dort kann ein technisch erfolgreicher Restore fachlich problematisch sein, wenn abhängige Systeme inzwischen einen anderen Stand besitzen.
Cyber Recovery ist deshalb nicht nur ein Storage- oder Security-Thema. Es ist genauso eine Frage von Anwendungsverständnis, Dokumentation, Test und Betriebsprozessen.
Wer nicht weiß, welche Anwendungen miteinander verbunden sind, welche Datenbestände gemeinsam verarbeitet werden und welche Batch-Ketten oder Schnittstellen voneinander abhängen, kann einzelne Komponenten wiederherstellen, aber nur schwer beurteilen, ob daraus wieder ein konsistenter Geschäftsprozess entsteht.
Genau an dieser Stelle berührt Cyber Resilience auch klassische Modernisierungsthemen. Eine saubere Anwendungsanalyse hilft nicht nur dabei, Systeme weiterzuentwickeln. Sie schafft gleichzeitig die Transparenz, die für einen belastbaren Recovery-Prozess notwendig ist.
RPO und RTO reichen bei Cyberangriffen nicht immer aus
Klassische Recovery-Konzepte werden häufig mit zwei Kennzahlen beschrieben: dem Recovery Point Objective, also der maximal tolerierbaren Menge verlorener Daten, und dem Recovery Time Objective, also der maximal akzeptablen Wiederherstellungsdauer.
Beide Kennzahlen bleiben wichtig. Bei Cybervorfällen kommt jedoch eine weitere Dimension hinzu: das Vertrauen in den wiederhergestellten Zustand.
Ein Recovery Point von fünf Minuten hilft wenig, wenn die Daten bereits seit mehreren Tagen manipuliert wurden. Ebenso nützt ein hervorragendes RTO wenig, wenn das System innerhalb einer Stunde wieder startet, aber niemand sicher beurteilen kann, ob seine Daten fachlich korrekt und frei von Manipulationen sind.
Deshalb sollte Cyber-Resilience-Planung zusätzlich berücksichtigen, wie ein vertrauenswürdiger Zustand erkannt und verifiziert werden kann.
DORA greift genau diesen Punkt auf, wenn die Verordnung bei der Wiederherstellung Kontrollen verlangt, mit denen die Integrität der Daten sichergestellt werden soll. Damit wird deutlich, dass schnelle Wiederherstellung allein kein ausreichendes Qualitätsmerkmal ist.
Recovery muss getestet werden, bevor es gebraucht wird
Viele Unternehmen wissen sehr genau, wann ihr letztes Backup erstellt wurde. Schwieriger wird häufig die Frage, wann zuletzt unter realistischen Bedingungen geprüft wurde, ob sich daraus tatsächlich ein kompletter Geschäftsprozess wiederherstellen lässt.
Ein technischer Restore-Test kann beispielsweise zeigen, dass sich ein Db2-Bestand zurückspielen lässt. Ein belastbarer Cyber-Recovery-Test sollte jedoch zusätzlich prüfen, ob die abhängigen Anwendungen starten, Schnittstellen korrekt funktionieren, Batch-Verarbeitung wieder anlaufen kann und die Fachbereiche mit dem wiederhergestellten Zustand tatsächlich arbeiten können.
Je komplexer die Anwendung, desto wichtiger wird ein reproduzierbarer Testprozess.
IBM Z Cyber Vault unterstützt den Aufbau einer isolierten Umgebung, in der Recovery und Analyse durchgeführt werden können, ohne die Produktion zu beeinflussen. Das ist deshalb interessant, weil Wiederherstellung damit nicht erst während eines realen Angriffs ausprobiert werden muss.
Auch NIST weist ausdrücklich darauf hin, dass Backups und Recovery-Verfahren regelmäßig getestet werden sollten. Hinweise dazu finden sich unter https://csrc.nist.gov/pubs/other/2020/04/24/protecting-data-from-ransomware-and-other-data-los/final.
Gerade für Banken und Versicherungen wird ein solcher Nachweis zunehmend wichtiger. Es reicht nicht, technisch erklären zu können, wie eine Wiederherstellung theoretisch funktionieren würde. Entscheidend ist, ob der Ablauf bereits praktisch erprobt wurde.
Modernisierung und Cyber Resilience gehören zusammen
Modernisierungsprojekte verändern fast immer auch die Recovery-Landschaft. Eine ursprünglich weitgehend geschlossene Mainframe-Anwendung kann nach einer Modernisierung aus z/OS-Komponenten, APIs, Cloud-Services und verteilten Anwendungen bestehen.
Dadurch entstehen neue Abhängigkeiten. Wenn im Recovery-Fall nur der Mainframe auf einen früheren Datenstand zurückgesetzt wird, während ein externer Service seinen aktuellen Zustand behält, können fachliche Inkonsistenzen entstehen.
Modernisierung sollte deshalb nicht nur beantworten, wie eine Anwendung künftig entwickelt und betrieben wird. Sie sollte auch berücksichtigen, wie der vollständige Geschäftsprozess nach einem schwerwiegenden Cybervorfall wiederhergestellt werden kann.
Das macht Anwendungsanalyse zu einem wichtigen Bestandteil der Resilience. Nur wenn Datenflüsse, Abhängigkeiten und fachliche Zusammenhänge bekannt sind, lässt sich entscheiden, welche Komponenten gemeinsam wiederhergestellt werden müssen und welche Prüfungen anschließend notwendig sind.
Automatisierung kann dabei helfen, ersetzt dieses Verständnis aber nicht. Werkzeuge wie GDPS können Recovery-Prozesse orchestrieren und wiederholbar machen. Ein automatisierter Ablauf ist jedoch nur so gut wie die Regeln und Abhängigkeiten, die zuvor definiert wurden.
Wenn dieses Wissen fehlt, wird durch Automatisierung im schlimmsten Fall lediglich ein unvollständiger Recovery-Prozess schneller ausgeführt.
Cyber Resilience beginnt lange vor dem Angriff
Die wichtigste Erkenntnis aus all dem ist, dass Cyber Resilience nicht erst dann beginnt, wenn ein Unternehmen angegriffen wurde. Sie beginnt mit der Frage, welche Geschäftsprozesse wirklich kritisch sind und welche Systeme daran beteiligt sind.
Dazu gehören unveränderliche Sicherungskopien ebenso wie Monitoring, Anomalieerkennung, dokumentierte Abhängigkeiten und regelmäßig getestete Recovery-Verfahren. Für Banken und Versicherungen kommt hinzu, dass diese Anforderungen inzwischen auch regulatorisch eine immer größere Rolle spielen.
Die Europäische Kommission beschreibt Cyber Resilience ausdrücklich als die Fähigkeit, Cyberbedrohungen nicht nur zu verhindern, sondern ihnen standzuhalten und sich von Vorfällen wieder zu erholen. Weitere Informationen dazu finden sich unter https://finance.ec.europa.eu/digital-finance/cyber-resilience_en.
Damit verändert sich der Blick auf Backup grundlegend. Eine Sicherung ist keine fertige Resilience-Strategie, sondern eine notwendige Voraussetzung für Wiederherstellung.
Die entscheidende Frage lautet deshalb nicht nur, ob eine Kopie vorhanden ist. Entscheidend ist, ob Unternehmen wissen, welcher Stand vertrauenswürdig ist, welche Komponenten gemeinsam wiederhergestellt werden müssen und ob dieser Prozess unter realistischen Bedingungen getestet wurde.
Gerade bei geschäftskritischen Anwendungen entsteht daraus eine Aufgabe, die Security, Storage, Mainframe-Betrieb, Anwendungsentwicklung, Fachbereiche und Business Continuity miteinander verbindet.
Und vielleicht lässt sich der Unterschied zwischen Backup und Cyber Resilience genau darauf reduzieren:
Ein Backup zeigt, dass Daten gesichert wurden.
Eine belastbare Resilience-Strategie zeigt, wie daraus wieder ein funktionierender Geschäftsbetrieb entsteht.