Wenn Prävention nicht mehr ausreicht: Die neue Mathematik der Cyber-Recovery

Die wichtigsten Erkenntnisse

• Frontier AI verkürzt die Zeitfenster für die Behebung von Sicherheitslücken – Prävention allein kann die Sicherheit nicht mehr gewährleisten.
• Die Frage, die sich Vorstände, Aufsichtsbehörden und Versicherer derzeit stellen, lautet nicht: „Haben wir Backups?“, sondern: „Können wir nachweisen, dass wir die Daten fehlerfrei wiederherstellen können?“
• Backups sind keine Wiederherstellung: Eine Kopie zeigt lediglich an, dass Daten vorhanden sind, nicht aber, ob sie fehlerfrei oder wiederherstellbar sind.
• Die „Mean Time to Recovery“ (MTCR) muss zu einer Kennzahl auf Vorstandsebene werden, die kontinuierlich gemessen wird – und nicht nur eine theoretische Schätzung bleiben.
• Eine isolierte Wiederherstellungsumgebung – mit Luftspalt, unveränderlich, gehärtet und identitätsisoliert – ist die Grundvoraussetzung und keine erweiterte Funktion.
• Was als „sauber“ gilt, wird sich ständig ändern, da KI-Modelle immer besser in der Lage sind, Schwachstellen zu finden, die Menschen nicht vorhersehen können.

Ich habe einen Großteil meiner Karriere damit verbracht, Produktionssysteme zu betreiben. Ich kenne Backup-Umgebungen in- und auswendig – jene, denen Kunden tatsächlich vertrauen. Ich weiß, dass Recovery-Pläne ihre Schwächen erst dann offenbaren, wenn bereits etwas schiefgelaufen ist. Diese Erfahrung verändert die Sichtweise auf Cyber-Resilienz.

Aus der Ferne betrachtet klingen Backup and Recovery überschaubar. Schütze die Daten, speichere Kopien, dokumentiere das Runbook, teste, wann immer du kannst, und stelle Daten wieder her, wenn es nötig ist. Doch jeder, der solche Umgebungen in großem Maßstab betrieben hat, kennt die härtere Wahrheit: Bei Recovery werden Annahmen auf die Probe gestellt. Und derzeit arbeiten zu viele Unternehmen mit Annahmen, die nicht mehr zutreffen. Jahrelang folgte die Sicherheitsarbeit einem vertrauten Ablauf: Schwachstelle finden, beheben, die Umgebung absichern, Aktivitäten überwachen. Dieses Modell ist nach wie vor wichtig. Doch das Zeitfenster, auf das es angewiesen ist, schrumpft.

Frontier AI hat das Tempo bei der Entdeckung von Sicherheitslücken, der Verknüpfung von Angriffspfaden und der Generierung von Exploits verändert. Modelle wie „Claude Mythos“ und „GPT-5.5-Cyber“ haben bereits gezeigt, wie dies aussieht – bislang zwar im Rahmen kontrollierter Early-Access-Tests, die noch auf menschliches Fachwissen angewiesen waren und erhebliche Falsch-Positiv-Raten aufwiesen, doch die Entwicklung ist unverkennbar. Mit zunehmender Verbreitung gelangen diese Fähigkeiten auch in die Hände von Angreifern.

Innerhalb eines einzigen Monats meldete Palo Alto Networks nach der Einführung innovativer KI-Modelle zur Code-Prüfung 26 CVEs, die 75 zugrunde liegende Probleme betrafen – im Vergleich zum üblichen Volumen von weniger als fünf CVEs pro Monat. Forscher warnen zudem davor, dass die KI-gestützte Erkennung die Zeitfenster für die Behebung immer weiter verkürzt, wobei manche Exploits mittlerweile bereits innerhalb von Minuten nach der Offenlegung auftauchen. Wenn das Patch-Fenster verschwindet, geht die Mathematik der Behebung nicht mehr auf. Prävention allein kann nicht die gesamte Last der Readiness tragen.

Prävention ist nach wie vor wichtig, definiert aber nicht mehr die Readiness. Die Kunden, mit denen ich spreche, fragen nicht, ob sie mehr Kontrollmaßnahmen benötigen. Sie wissen bereits, dass dies der Fall ist. Sie fragen, ob sich ihr Unternehmen ordnungsgemäß erholen kann, wenn diese Kontrollmaßnahmen versagen, wenn Angreifer schneller sind als die Behebungszyklen oder wenn eine Kompromittierung bereits länger besteht, als irgendjemandem bewusst war.

Genau diese Frage stellen sich nun Vorstände, Aufsichtsbehörden und Versicherer. Sie sind über die Frage „Haben wir Backups?“ hinausgegangen und beschäftigen sich nun mit einer weitaus wichtigeren Frage: „Können wir nachweisen, dass wir die Daten einwandfrei wiederherstellen können?“ Dieser Nachweis beginnt mit einer Unterscheidung, die die meisten Unternehmen nach wie vor falsch verstehen: Backups sind nicht gleichbedeutend mit Wiederherstellung.

Ein Backup zeigt Ihnen an, dass eine Kopie vorhanden ist. Es gibt jedoch keinen Aufschluss darüber, ob die Daten fehlerfrei sind, ob Anwendungsabhängigkeiten intakt sind, ob Identitätsdienste sicher wiederhergestellt werden können oder ob die Wiederherstellungsreihenfolge noch der aktuellen Umgebung entspricht. Ich habe Pläne geprüft, die vollständig aussahen, bis jemand versuchte, sie auszuführen. Das Runbook war vorhanden, aber veraltet. Die Wiederherstellung funktionierte zwar, dauerte aber dreimal länger als veranschlagt. Das System lief wieder, aber nachgelagerte Anwendungen konnten keine Verbindung herstellen. Nichts davon ist ungewöhnlich. Genau das soll durch echte Tests aufgedeckt werden. Das Problem ist, dass die meisten Unternehmen diese Lücken erst während eines tatsächlichen Vorfalls entdecken. Die wichtigste Kennzahl, wenn etwas schiefgeht, ist, wie schnell man wieder einen Zustand erreichen kann, von dem man weiß, dass er einwandfrei ist. Deshalb muss die „Mean Time to Recovery“ (MTR) zu einer Kennzahl auf Vorstandsebene werden – nicht als theoretische Schätzung in einem Plan, sondern als gemessene, validierte Zeit.

Das bewegliche Ziel: Was heute sicher ist, muss morgen nicht unbedingt noch sicher sein

Was die Frontier-KI-Modelle angeht, lautet die ehrliche Antwort: Man kann nicht garantieren, dass jede Schwachstelle rechtzeitig entdeckt und behoben wird. Angreifer, die dieselben Modelle nutzen, entdecken und verknüpfen Exploits schneller, als es ein Programm zur Behebung von Schwachstellen realistisch gesehen jemals nachholen kann. Das ist kein Versagen Ihres Sicherheitsteams. Es ist die neue Realität der Bedrohungslandschaft.

Was Sie kontrollieren können, ist Ihre Recovery-Fähigkeit. Das bedeutet eine isolierte Recovery-Umgebung – Backups, die vom Internet getrennt sind, vom Produktionsnetzwerk aus nicht erreichbar sind und vor der lateralen Bewegung geschützt sind, die für einen ausgeklügelten Angriff charakteristisch ist. Es bedeutet Unveränderlichkeit und Compliance-Sperre, sodass keine Anmeldedaten – egal wie privilegiert sie auch sein mögen – die Aufbewahrungsfrist verkürzen oder Daten außerhalb eines autorisierten Prozesses löschen können. Und es bedeutet ResOps in der Praxis: nicht nur das Sichern von Daten, sondern das kontinuierliche Testen von Recovery, die Automatisierung der Integritätsprüfung und die Messung Ihres MTCR – der validierten Zeit bis zur Rückkehr in einen bekanntermaßen einwandfreien Zustand.

Doch hier liegt der Aspekt, den die meisten Unternehmen noch nicht berücksichtigen: Was als „sauber“ gilt, ist kein feststehender Wert. Je leistungsfähiger KI-Modelle werden, desto häufiger werden sie Schwachstellen aufdecken, die der menschliche Verstand schlichtweg nicht vorhersehen kann – neuartige Angriffspfade, schlummernde Implantate, subtile Manipulationen, die lange vor ihrer Entdeckung eingebettet wurden. Ein Recovery-Punkt, der nach heutigen Maßstäben als „sauber“ gilt, kann Kompromittierungen enthalten, die die KI-gestützte Forensik von morgen aufdecken wird. Das bedeutet, dass sich Ihre Definition von „sauber“ kontinuierlich weiterentwickeln muss. MTCR ist keine Zahl, die man einmal festlegt. Es ist eine Disziplin, die man aufrechterhält, indem man immer wieder überdenkt, was „sauber“ bedeutet, die Validierungskriterien aktualisiert und Resilienz als einen lebendigen Standard betrachtet und nicht als eine Zertifizierung, die man einmal besteht.

Was ist also ein gutes MTCR? Basierend auf meinen praktischen Erfahrungen sollte das Ziel für Ihr gesamtes „Minimum Viable Company“ – also die kleinste Systemgruppe, die den Betrieb aufrechterhält und die ich weiter unten genau definiere – unter sechs Stunden liegen. Sechs Stunden sind mit der richtigen Architektur erreichbar: ein einsatzbereites IRE, eine vorab validierte Recovery-Sequenz und Runbooks, die ausführbar statt nur lesbar sind. Wenn Ihr aktuelles MTCR in Tagen gemessen wird, liegt die Lücke fast immer bei einem dieser drei Punkte.

Vier Schritte, um im Zeitalter der „Frontier AI“ widerstandsfähig zu bleiben

Der Ausgangspunkt ist die Erkenntnis, dass Prävention allein nicht ausreicht. Von da an wird die Arbeit konkret. Hier sind die Schwerpunkte, auf die sich Unternehmen meiner Meinung nach konzentrieren sollten.

1. Bewerten Sie Ihre tatsächlichen Risiken bei der Datenwiederherstellung.

Die meisten Bewertungen von Recovery-Risiken stellen die falschen Fragen. „Gibt es Backups?“ ist nicht dasselbe wie „Können wir eine saubere Recovery durchführen?“ Die schwierigeren Fragen lauten: Können kritische Systeme wiederhergestellt werden, ohne die Bedrohung erneut einzuschleusen? Sind die Wiederherstellungsumgebungen von kompromittierten Produktionssystemen isoliert? Sind die Wiederherstellungspläne auf aktuelle Abhängigkeiten abgestimmt – und nicht auf die Architektur von vor zwei Jahren?

In einem sich schnell verändernden Umfeld von Sicherheitslücken ist die Lücke zwischen „Wir haben Backups“ und „Wir können Daten wiederherstellen“ genau der Punkt, an dem Unternehmen Schaden nehmen. Eine ehrliche Bewertung dieser Lücke, bevor ein Vorfall das Thema erzwingt, muss der Ausgangspunkt der Resilienzplanung sein. Diese Bewertung muss eine Analyse der geschäftlichen Auswirkungen beinhalten: Welche Systeme haben ein Recovery-Fenster von wenigen Minuten, welche von Stunden und welche können einen Tag warten? Ohne diese Einstufung erscheint jedes System während eines Vorfalls gleich dringlich, und nichts wird schnell genug wiederhergestellt.

2. Isolierte Wiederherstellung und Air-Gapping sollten die Regel sein – nicht die Ausnahme.

Wenn Sie luftisolierte, unveränderliche Kopien nach wie vor als erweiterte Funktion und nicht als Standardanforderung betrachten, trifft diese Annahme nicht mehr zu. Wenn sich die Zeitfenster für Angriffe auf wenige Minuten verkürzen, benötigen Sie Ausweichmöglichkeiten, die strukturell von den Identitäts-, Netzwerk- und Verwaltungsebenen der Produktionsumgebung getrennt sind – logisch oder physisch isoliert, unveränderlich und ohne direkten Rückweg zur Produktionsumgebung, dem ein Angreifer folgen könnte.

Das Ziel besteht nicht nur darin, sich vor der aktuellen Bedrohung zu schützen, sondern auch sicherzustellen, dass Ihnen saubere Wiederherstellungsoptionen zur Verfügung stehen, falls eine Schwachstelle ausgenutzt wird, für die Sie noch keinen Patch installiert haben. Das kommt mittlerweile vor. Bereiten Sie sich darauf vor. Isolation funktioniert nur, wenn die umgebende Infrastruktur gehärtet ist. Das bedeutet eine Backup-Infrastruktur auf gehärteten Betriebssystemen, nicht auf generischen Images, und idealerweise auf physischen Servern, die einen Angriff auf Hypervisor-Ebene überstehen. Das bedeutet, dass Verschlüsselungsschlüssel außerhalb der Backup-Plattform gespeichert werden – in einem externen Tresor mit Just-in-Time-Zugriff und ohne Abhängigkeit vom produktiven Active Directory. Und es bedeutet, Ihre Backup-Domäne als separate Identitätsgrenze zu behandeln: keine Vertrauensbeziehung zum produktiven Active Directory, obligatorische MFA und Autorisierung durch mehrere Personen für destruktive Vorgänge. Nichts davon ist übertrieben, es ist die Grundvoraussetzung dafür, dass Ihre Umgebung in einen nicht kompromittierten Zustand wiederhergestellt werden kann.

Ebenso wichtig ist die Frage, von welchem Zustand aus Sie die Recovery durchführen. Branchenweite Daten zur Incident-Response zeigen durchweg, dass die durchschnittliche Dauer eines Sicherheitsvorfalls im Bereich von Wochen und nicht von Tagen liegt. Das bedeutet, dass Ihre Recovery-Kopien weit genug zurückreichen müssen, um einen wirklich sauberen Zeitpunkt zu finden – nicht nur das Backup von gestern. Kritische Systeme erfordern mehrere geografisch getrennte Kopien, darunter mindestens eine unveränderliche Kopie und eine, die vollständig offline ist. Die Aufbewahrungsrichtlinie ist keine Entscheidung über Speicherkosten. Es ist eine Sicherheitsentscheidung.

3. Finden Sie heraus, auf welche Systeme das Unternehmen nicht verzichten kann – und stellen Sie diese als Erstes wieder her.

Die meisten Unternehmen stellen erst während eines Vorfalls fest, wie ihr Wiederherstellungsablauf aussieht. Deshalb werden die ersten 24 bis 48 Stunden nicht damit verbracht, Systeme wiederherzustellen, sondern damit, zu entscheiden, was wirklich wichtig ist. Unternehmen wissen, dass sie Identitätsplattformen, Abrechnungssysteme, operative Datenbanken und die Kerninfrastruktur wiederherstellen müssen. Was sie jedoch oft nicht erfasst haben, sind die Reihenfolge, die Abhängigkeiten zwischen diesen Systemen und die nachgelagerten Anwendungen, die erst dann wieder funktionieren können, wenn bestimmte Dienste wieder verfügbar sind.

Dies wird umso komplexer, je stärker KI in die Geschäftsabläufe eingebunden ist. Datenpipelines, Modell-Repositorys, Vektordatenbanken, agentenbasierte Workflows – all dies sind mittlerweile betriebliche Abhängigkeiten und nicht mehr nur technische Infrastruktur. Wenn Ihre Wiederherstellungsabläufe diese Faktoren nicht berücksichtigen, sind Ihre Schätzungen zur Wiederherstellungszeit wahrscheinlich falsch. Die Definition dessen, was es bedeutet, als „Minimum Viable Company“ zu agieren (die kleinste Menge an Systemen, die erforderlich ist, um den Geschäftsbetrieb aufrechtzuerhalten), und die darauf aufbauende Recovery-Planung sind keine theoretische Übung. Es ist die praktische Antwort auf die Frage, die sich jedes Führungsteam während eines Vorfalls stellen wird: Was stellen wir als Erstes wieder her?

Nach meiner Erfahrung bei der Unterstützung von Kunden während aktiver Vorfälle wird diese Frage in den ersten 12 Stunden beantwortet, unabhängig davon, ob Sie dies geplant haben oder nicht – was in diesem Zeitfenster wiederhergestellt wird, wird standardmäßig zu Ihrem MVC. Die Organisationen, die am schnellsten wieder einsatzfähig sind, haben im Voraus entschieden: Sie wussten genau, welche Systeme innerhalb von 12 Stunden wieder verfügbar sein mussten, und hatten überprüft, dass sie dazu in der Lage waren. Wenn Ihr MVC nicht innerhalb von 12 Stunden umgesetzt werden kann, ist es kein MVC, sondern eine Wunschliste. Die Aufgabe besteht darin, den Umfang so lange zu reduzieren, bis das, was übrig bleibt, realistisch innerhalb dieses Zeitfensters wiederhergestellt werden kann, und dies dann so lange zu testen, bis Sie es nachweisen können.

4. Automatisieren Sie die Ausfallsicherheit und führen Sie kontinuierlich Tests durch – nicht nach einem festen Zeitplan.

Ein Wiederherstellungsplan, der nur auf dem Papier steht und jährlich überprüft wird, ist keine Wiederherstellungsfähigkeit. Es handelt sich um eine Hypothese, die noch nie in der Praxis erprobt wurde. Das Problem bei kalenderbasierten Tests ist, was zwischen den Zyklen übersehen wird. Umgebungen ändern sich ständig: neue Workloads, aktualisierte Abhängigkeiten, eine Infrastruktur, die von den Angaben im Runbook abweicht. Wenn der jährliche Test schließlich durchgeführt wird, validiert er eine Momentaufnahme einer Umgebung, die nicht mehr existiert. In einer Bedrohungslandschaft, in der eine Ausnutzung bereits innerhalb von Minuten nach Bekanntwerden erfolgen kann, ist diese Verzögerung nicht akzeptabel. Das Scannen nach Bedrohungen, die Identifizierung intakter Wiederherstellungspunkte, die abhängigkeitsbewusste Wiederherstellung und die Koordination der Wiederherstellung müssen automatisiert werden und kontinuierlich ablaufen. Nicht, weil Automatisierung eine bewährte Vorgehensweise ist, sondern weil die manuelle Alternative mit dem heutigen rasanten Tempo nicht Schritt halten kann. Kontinuierliches Testen hängt auch von kontinuierlicher Erkennung ab. Sie können keinen unbeeinträchtigten Wiederherstellungspunkt auswählen, wenn Sie nicht wissen, wann die Kompromittierung begann. Deshalb müssen sich Bedrohungserkennung, Anomalie-Scans der Sicherungsdaten und die Analyse der Wiederherstellungspunkte gegenseitig ergänzen: Die Erkennung zeigt Ihnen, welche Kopien vor dem Eindringen erstellt wurden, und diese Feststellung bestimmt, von welchem Zeitpunkt aus Sie tatsächlich wiederherstellen. Ohne diese Verknüpfung führen Sie die Wiederherstellung zu einem Zeitpunkt durch, von dem Sie hoffen, dass er unbeeinträchtigt ist, anstatt zu einem Zeitpunkt, den Sie überprüft haben – und in einer von Frontier AI geprägten Bedrohungslandschaft ist Hoffnung keine Wiederherstellungsstrategie.

Was bei kontinuierlichen Tests zutage tritt, unterscheidet sich von dem, was bei jährlichen Tests festgestellt wird. Regelmäßige Tests dienen in der Regel dazu, zu bestätigen, dass der Plan unter kontrollierten Bedingungen funktioniert. Bei kontinuierlichen Tests werden hingegen die Abhängigkeiten entdeckt, die sich im letzten Monat geändert haben, die Wiederherstellungssequenz, die versagt, wenn eine bestimmte Arbeitslast hinzukommt, sowie der Identitätsdienst, dessen Wiederherstellung doppelt so lange dauert wie ursprünglich veranschlagt. Das sind die Schwachstellen, auf die es im Ernstfall ankommt, und die einzige Möglichkeit, sie zu entdecken, bevor es zu einem Vorfall kommt, besteht darin, ständig Tests durchzuführen.

Das Testen muss zudem in der richtigen Umgebung erfolgen. Ein Recovery-Test, der auf der Produktionsinfrastruktur durchgeführt wird, gibt keinen Aufschluss darüber, ob ein Recovery-Prozess möglich ist, wenn die Produktion beeinträchtigt ist. Durch „Cleanroom“-Tests – also die Validierung des Recovery-Prozesses in einer vollständig isolierten Umgebung ohne Verbindung zur Produktion – stellen Sie sicher, dass Ihre Sicherungskopien unter Vorfallbedingungen tatsächlich einsetzbar sind. Dazu gehört die isolierte Recovery von Identitätsdiensten, der externen Schlüsselverwaltung und Tier-0-Anwendungen mithilfe spezieller „Break-Glass“-Konten, die außerhalb Ihres normalen Verzeichnisses liegen.

Was tägliche Tests erst möglich macht, ist „Validate Restore“ – eine Wiederherstellungsart, bei der der gesamte Wiederherstellungspfad für jede kritische Ressource durchgespielt wird, ohne die Produktion zu beeinträchtigen. Ihre Plattform muss dies nativ unterstützen; wenn sie nicht täglich einen automatisierten, unterbrechungsfreien Wiederherstellungstest für Ihr gesamtes MVC durchführen kann, wissen Sie nicht wirklich, ob Ihre Backups funktionieren. Bei Commvault erfolgt diese Wiederherstellung anhand Ihrer Gruppen kritischer Ressourcen, mit automatisierter Berichterstattung über den Wiederherstellungsstatus jedes geschützten Systems.

Das Gleiche gilt für Ihre Runbooks. Ein Runbook, das als Word-Dokument oder PDF-Datei vorliegt, ist ein Nachschlagewerk, kein operatives Werkzeug – es setzt voraus, dass jemand die Zeit, den Überblick und den Zugriff hat, es unter Zeitdruck zu lesen. Echte Runbooks sind digitale Skripte, die die Recovery-Sequenz ausführen und jeden Schritt validieren, wobei sie bestätigen, dass die Anwendung tatsächlich funktioniert, bevor sie fortfahren: nicht „der Dienst wurde gestartet“, sondern „die Anwendung hat korrekt auf eine synthetische Transaktion reagiert“. Die „Commvault Cleanroom Runbooks“ sind genau dafür konzipiert – ausführbare Workflows, die eine durchgängige Wiederherstellung in einer isolierten Umgebung vorantreiben, ohne dass bei jedem Schritt ein Mensch ein Dokument auswerten muss.

Ein letzter Punkt, der in Recovery-Plänen selten berücksichtigt wird, bis es zu spät ist: Bei einem schwerwiegenden Vorfall kann Ihre Unternehmenskommunikationsinfrastruktur selbst kompromittiert oder nicht verfügbar sein. E-Mail, Teams und Slack laufen auf derselben Infrastruktur, die Angreifer ins Visier nehmen. Legen Sie im Voraus fest, welche Out-of-Band-Kanäle Ihr Team zur Koordination nutzen wird, und stellen Sie sicher, dass diese Kanäle zusammen mit Ihren technischen Recovery-Verfahren getestet werden. Erfahren Sie mehr von Bill O’Connell, Chief Security Officer bei Commvault, über die vier entscheidenden Schritte für Ausfallsicherheit im Zeitalter der KI.

Resilienz ist eine operative Disziplin, kein Projekt

Die Organisationen, die den durch KI beschleunigten Bedrohungen standhalten werden, sind diejenigen, die Resilienz als operative Disziplin betrachten – gemessen an MTCR, kontinuierlicher Validierung und einer Wiederherstellungsfähigkeit, die sie unter Beweis gestellt haben und nicht nur als gegeben annehmen. Das Problem ist nicht, dass die Angriffe immer schneller werden. Das Problem ist, dass die Wiederherstellung noch nicht Schritt gehalten hat, und solange das so bleibt, geht die Rechnung nicht auf.

FAQs

F: Was ist die „Mean Time to Clean Recovery“ (MTCR) und warum ist sie wichtig?
A: Die MTCR misst, wie schnell ein Unternehmen nach einem Cyberangriff in einen verifizierten, als funktionsfähig bestätigten Zustand zurückkehren kann – nicht nur durch die Wiederherstellung der Daten, sondern durch die Bestätigung, dass diese fehlerfrei sind und die Anwendungsabhängigkeiten intakt sind. Sie sollte eine Kennzahl auf Vorstandsebene mit einer gemessenen, validierten Zeit sein, nicht eine theoretische Schätzung, die in einem Recovery-Plan verborgen ist. Das Ziel für ein gut konzipiertes MVC – das alle Identitätssysteme, kritische Anwendungen und die Readiness der isolierten Wiederherstellungsumgebung abdeckt – liegt bei unter sechs Stunden.

F: Was ist eine isolierte Recovery-Umgebung und wie unterscheidet sie sich von einem Standard-Backup?
A: Eine isolierte Recovery-Umgebung (IRE) ist eine vollständig „air-gapped“, unveränderliche Kopie kritischer Daten, die strukturell von Produktionsnetzwerken, Identitätssystemen und Verwaltungsebenen getrennt ist. Ein Standard-Backup sagt Ihnen, dass eine Kopie existiert. Eine IRE sagt Ihnen, dass diese Kopie vor demselben Angriff geschützt ist, der Ihre Produktionsumgebung getroffen hat.

F: Woher wissen wir, ob wir heute tatsächlich eine Wiederherstellung durchführen können?
A: Die einzig ehrliche Antwort ergibt sich aus Tests, nicht aus der Dokumentation. Wenn Sie nicht auf eine aktuelle, validierte Recovery Ihres „Minimum Viable Company“ verweisen können – idealerweise einen täglichen automatisierten Test –, dann wissen Sie es nicht, sondern gehen lediglich von einer Annahme aus. Eine stichhaltige Antwort gegenüber dem Vorstand ist ein gemessener MTCR, der durch kontinuierliche Validierung untermauert wird, und kein Recovery-Plan, der auf dem Papier vollständig aussieht.

F: Was erwarten Aufsichtsbehörden und Cyberversicherer mittlerweile?
A: Die Messlatte hat sich von „Haben Sie Backups?“ zu „Können Sie nachweisen, dass Sie einwandfreie Recovery-Prozesse durchführen können, und wie schnell?“ verschoben. Aufsichtsbehörden erwarten zunehmend nachweisbare Recovery-Fähigkeit und getestete Ausfallsicherheit; Versicherer berechnen ihre Prämien – und zahlen Schadensersatz – zunehmend auf der Grundlage von Nachweisen über isolierte, unveränderliche Backups und validierte Wiederherstellungszeiten. Ein gemessener MTCR und ein dokumentierter Testrhythmus werden für beide Seiten zur Grundvoraussetzung. Rajiv Kottomtharayil ist Chief Product Officer bei Commvault.