Jede Organisation, bei der eine Wiederherstellung jemals gescheitert ist – und davon gibt es mehr, als öffentlich zugegeben wird –, hatte eines gemeinsam: Sie glaubte, die Wiederherstellung sei möglich, noch bevor sie es überhaupt versucht hatte.
Diese Überzeugung hatte irgendwo ihren Ursprung. Eine abgeschlossene Tabletop-Übung. Ein Backup-System, das „grün“ anzeigte. Ein bestandener jährlicher Disaster-Recovery-Test. Alles dokumentiert. Alles zu einem bestimmten Zeitpunkt korrekt. Nichts davon aktuell, als der Vorfall tatsächlich eintrat. Das ist die Vertrauenslücke. Und genau diese Lücke soll durch die kontinuierliche Validierung der Wiederherstellung geschlossen werden.
Was „Testen“ in den meisten Unternehmen eigentlich bedeutet
Fragt man die meisten Sicherheits- oder IT-Verantwortlichen, wie oft sie ihre Wiederherstellungsfähigkeit testen, lautet die Antwort in der Regel „einmal jährlich“, manchmal „zweimal jährlich“. Der Test umfasst die Wiederherstellung eines Teils der Systeme aus dem Backup in eine Testumgebung, die Überprüfung, ob diese ordnungsgemäß hochfahren, und die Erstellung eines Berichts. Manchmal wird parallel dazu eine Tabletop-Übung durchgeführt. Was diese Art von Tests jedoch nicht leisten: zu überprüfen, ob die Backup-Daten frei von Malware sind; zu bestätigen, dass die Recovery-Reihenfolge bei voneinander abhängigen Diensten funktioniert; die Recovery von Identitäten wird nicht getestet, obwohl dies unerlässlich ist, wenn kompromittierte Anmeldedaten den Angriff erst ermöglicht haben. Es wird nicht überprüft, ob das Team, das die Recovery tatsächlich durchführen würde, die aktuellen Runbooks kennt. Und es werden keine aussagekräftigen Nachweise erbracht, die eine Aufsichtsbehörde, einen Wirtschaftsprüfer oder den Vorstand davon überzeugen könnten, dass die Recovery-Fähigkeit real und aktuell ist. Kurz gesagt: Es dient der Validierung eines bestimmten Zeitpunkts. Resilience Operations (ResOps) erfordern eine kontinuierliche Validierung.
Das Modell der kontinuierlichen Validierung
Die kontinuierliche Validierung der Wiederherstellbarkeit ist nicht einfach nur ein einzelner Test, der häufiger durchgeführt wird. Es handelt sich vielmehr um eine Reihe integrierter Maßnahmen, die einen fortlaufenden, evidenzbasierten Nachweis der Wiederherstellbarkeit kritischer Dienste liefern. Automatisierte Überprüfung der Backup-Integrität. Jedes Backup wird kontinuierlich auf Anomalien, Verschlüsselungsmuster und Malware-Signaturen überprüft. Nicht zum Zeitpunkt der Recovery – sondern bereits davor. Das Ziel ist es, zu wissen, ob Ihre Recovery-Punkte einwandfrei sind, bevor Sie sie benötigen, und nicht erst während eines Vorfalls.
Geplante „Cleanroom Recovery“. Mindestens zweimal jährlich erfolgt eine Wiederherstellung aus unveränderlichen Sicherungspunkten in eine isolierte „Cleanroom Recovery“ – weder in der Produktion noch in einer produktionsnahen Testumgebung, sondern in einem wirklich isolierten Bereich, in dem forensische Analysen ohne das Risiko einer erneuten Infektion durchgeführt werden können. Diese Übungen liefern dokumentierte Nachweise für die Wiederherstellbarkeit unter Einhaltung definierter Auswirkungstoleranzen.
Überprüfung der Identitätswiederherstellung. Da der Missbrauch von Anmeldedaten der häufigste Angriffsvektor ist, müssen neben der Datenwiederherstellung auch die Wiederherstellung von Active Directory und Entra ID getestet werden. Unternehmen, die Systeme wiederherstellen, ohne zuvor eine als sicher verifizierte Identitätsschicht wiederherzustellen, laufen Gefahr, dass Angreifer erneut durch dieselbe Tür eindringen.
Dashboards zum Service-Resilience-Indikator (SRI). SRIs – kontinuierliche Signale, die aus Backup-Telemetriedaten, Abhängigkeitskartierungen und Testergebnissen gewonnen werden – bieten CISOs, CIOs und Vorständen einen Echtzeit-Überblick über den Stand der Wiederherstellungsfähigkeit. Kein Momentaufnahme-Bericht, sondern ein fortlaufendes operatives Signal.
Jede dieser Maßnahmen trägt zu dem bei, was Deloitte und Commvault als „Resilience Backlog“ bezeichnen: eine kontinuierlich aktualisierte, nach Prioritäten geordnete Liste von Lücken, die durch Tests identifiziert und bis zu ihrer Behebung nachverfolgt werden. Dies ist der Mechanismus, durch den die Validierung Verbesserungen vorantreibt, anstatt lediglich Berichte zu erstellen.
Was bedeutet die durchschnittliche Wiederherstellungszeit nach einem Ausfall?
Herkömmliche Recovery-Kennzahlen – Recovery Time Objective (RTO) und Recovery Point Objective (RPO) – messen Geschwindigkeit und Aktualität der Daten. Sie geben jedoch keinen Aufschluss darüber, ob die wiederhergestellten Daten vertrauenswürdig sind. Die „Mean Time to Recovery“ (MTR) schließt diese Lücke: Sie misst die Zeit, die erforderlich ist, um Daten wiederherzustellen, die nachweislich fehlerfrei sind – und nicht nur technisch verfügbar.
MTR ist von Bedeutung, da bei einem Ransomware-Vorfall das Ziel des Angreifers oft darin besteht, die Wiederherstellungsmöglichkeiten zu sabotieren – und nicht nur die Produktionssysteme zu verschlüsseln. Ein Unternehmen, das zwar schnell eine Wiederherstellung durchführt, dabei jedoch auf ein kompromittiertes Backup zurückgreift, hat sich nicht wirklich erholt. Es hat sich vielmehr erneut infiziert.
Die Einbindung von MTCR in Ihr Rahmenwerk zur Messung der Ausfallsicherheit – neben RTO und RPO – verändert die Optimierungsziele und die Berichterstattung an die Geschäftsleitung. Geschwindigkeit plus Aktualität plus Integrität: Das ist das vollständige Bild der Wiederherstellungsbereitschaft.
Nachweisbare Resilienz
Die Organisationen, die Cyber-Störungen mit dem geringsten Schaden bewältigen, haben eines gemeinsam: Sie betrachten die Wiederherstellungsfähigkeit als etwas, das kontinuierlich unter Beweis gestellt werden muss, und nicht als etwas, das nur in regelmäßigen Abständen bestätigt wird. Sie kennen ihren MTCR. Ihre SRIs sind auf dem neuesten Stand. Ihr Cleanroom wurde in den letzten 90 Tagen getestet. Diese Haltung ist nicht allein das Ergebnis besserer Technologie. Sie ist das Ergebnis einer betrieblichen Disziplin – ResOps –, die Resilienz kontinuierlich, messbar und steuerbar macht. Die Plattform von Commvault bietet die technische Grundlage: saubere Recovery, automatisierte Validierung und die einheitliche Transparenz über Daten, Identitäten und Dienste hinweg, die ResOps in großem Maßstab erfordert.
Was die organisatorische Seite dieser Gleichung betrifft – wie man Auswirkungstoleranzen definiert, die Führungsspitze auf eine Linie bringt und die Governance-Struktur aufbaut, die diese Disziplin aufrechterhält –, lesen Sie den begleitenden Blogbeitrag von Deloitte: „The Resilience Conversation Your Board Isn’t Having Yet“.
Und für das vollständige ResOps-Framework, einschließlich der sechs ResOps-Bereiche und des Messmodells, das die technische Wiederherstellbarkeit mit der Rechenschaftspflicht auf Vorstandsebene verknüpft, lesen Sie das gemeinsame Whitepaper: „From Minimum Viability to Operational Resilience: ResOps in Practice“.
Bill O’Connell ist Chief Security Officer bei Commvault
.
