Ein Backup ist keine Wiederherstellung. Kann Ihr Unternehmen den Betrieb nach einem Angriff tatsächlich wiederaufnehmen?

Ein Ransomware-Vorfall wird häufig mit der Verschlüsselung von Daten und einer anschließenden Lösegeldforderung in Verbindung gebracht. Aus Sicht eines Unternehmens ist die praktische Folge jedoch noch wichtiger. Mitarbeitende können sich nicht anmelden, Anwendungen funktionieren nicht, Produktion oder Logistik haben keinen Zugriff auf die benötigten Systeme, und die Zeit bis zur Rückkehr zum Normalbetrieb beginnt, finanzielle und betriebliche Schäden zu verursachen.

Genau in diesem Moment zeigt sich der Unterschied zwischen einem Unternehmen, das Backups hat, und einem Unternehmen, das seinen Wiederherstellungsprozess beherrscht. Das erste verfügt über Kopien der Daten. Das zweite weiß, welche Kopien vertrauenswürdig sind, was daraus wiederhergestellt werden muss, in welcher Reihenfolge und wie überprüft wird, ob die wiederhergestellte Umgebung sicher ist.

Backup und Wiederherstellung sind nicht dasselbe

Backup bedeutet, eine weitere Kopie von Daten oder des Systemzustands zu erstellen, die bei Verlust, Beschädigung oder Kompromittierung der ursprünglichen Daten verwendet werden kann. Wiederherstellung ist der gesamte Prozess, mit dem ein Unternehmen nach einem Vorfall wieder in einen funktionsfähigen Zustand zurückkehrt. Sie umfasst daher weit mehr als einen Klick auf die Schaltfläche „Wiederherstellen“.

Der Unterschied lässt sich wie folgt vereinfachen:

Backup	Wiederherstellung
Erstellt eine Kopie der Daten	Bringt den Prozess wieder in Betrieb
Beantwortet die Frage „Was haben wir gespeichert?“	Beantwortet die Frage „Was können wir wieder starten?“
Ist eine technische Fähigkeit	Ist ein technischer und organisatorischer Prozess
Kann automatisch erfolgen	Erfordert Entscheidungen und Prioritäten
Bestätigt allein nicht die Nutzbarkeit	Muss praktisch getestet werden

 

Ein Backup ist eine Voraussetzung für die Wiederherstellung, nicht deren Beweis. Auch ein korrekt erstelltes Backup kann unbrauchbar, zu alt, beschädigt oder für die Wiederherstellung der gesamten Anwendungsumgebung unzureichend sein. Beim Schutz vor Ransomware reicht es daher nicht aus, nur die Häufigkeit der Backups zu bewerten. Ebenso wichtig ist es zu wissen, wie lange die Wiederherstellung dauert, welche Systeme voneinander abhängig sind und ob eine ausreichend sichere Kopie aus der Zeit vor der Kompromittierung existiert.

Der gefährlichste Satz nach einem Vorfall: „Wir haben doch ein Backup“

Ein Gefühl der Sicherheit entsteht oft bereits in dem Moment, in dem die IT bestätigt, dass regelmäßig Backups erstellt werden. Das Problem ist, dass die Antwort auf die Frage „Haben wir ein Backup?“ keine Auskunft darüber gibt, ob das Unternehmen auf die Wiederherstellung nach einem größeren Angriff vorbereitet ist. Ein Backup kann vorhanden sein und das Unternehmen kann trotzdem tagelang außer Betrieb bleiben.

Die Annahme „Wir haben Backups, also sind wir sicher“ ignoriert beispielsweise folgende Fragen:

• Ist das Backup auch nach der Kompromittierung von Administratorkonten verfügbar?
• Kann es ohne die ursprüngliche Infrastruktur wiederhergestellt werden?
• Enthält es alle Daten, die für den Betrieb der Anwendung erforderlich sind?
• Ist bekannt, welche Version noch sicher ist?
• Wie lange dauert die Wiederherstellung von Terabytes an Daten?
• Wer entscheidet, was zuerst wiederhergestellt wird?
• Sind die Server, Identitäten und Netzwerkdienste vorbereitet, die zum Starten der Anwendungen erforderlich sind?

Gerade deshalb ist es bei Ransomware wichtig, über ein umfassenderes Resilienzmodell nachzudenken. Prävention und Erkennung bleiben unverzichtbar, doch der Schutz der Unternehmensinfrastruktur muss auch die Möglichkeit berücksichtigen, dass es einem Angriff gelingt, die präventiven Maßnahmen zu überwinden.

Ransomware muss nicht nur Produktionsdaten verschlüsseln

Ein fortgeschrittener Angriff muss nicht bei Arbeitsstationen oder einem gemeinsam genutzten Laufwerk enden. Erlangt der Angreifer ausreichende Berechtigungen, kann er versuchen, auch die Mechanismen außer Kraft zu setzen, die das Unternehmen für die Rückkehr zum Betrieb nutzen würde. Die Backup-Infrastruktur wird daher selbst zu einem attraktiven Ziel.

Besonders riskant können Situationen sein, in denen:

• Backups dieselben Administratorkonten wie die Produktionsumgebung verwenden,
• der Backup-Speicher ständig mit derselben Infrastruktur verbunden ist,
• ein einziges kompromittiertes Konto sowohl Produktionsdaten als auch Backups löschen kann,
• alle Kopien verändert oder gelöscht werden können,
• die Organisation keine getrennte oder unveränderliche Kopie besitzt.

Wenn ein Angreifer auch Backups löschen oder verschlüsseln kann, verliert eine ursprünglich starke Sicherheitsmaßnahme ihre Bedeutung. Backups zum Schutz vor Ransomware müssen daher nicht nur den Ausfall der Produktionssysteme berücksichtigen, sondern auch einen aktiven Angriff auf den Wiederherstellungsprozess selbst.

Ein Ransomware-Vorfall sollte daher als Zusammenspiel von Prävention, Erkennung, Eindämmung des Angriffs und Wiederherstellung betrachtet werden. Allein das Stoppen des schädlichen Prozesses bedeutet noch keine Rückkehr zum normalen Betrieb, ebenso wenig wie das bloße Vorhandensein eines Backups eine erfolgreiche Wiederherstellung garantiert.

Eine unveränderliche oder isolierte Kopie verändert die Situation

Ein Grundprinzip des Backup-Schutzes besteht darin, sicherzustellen, dass zumindest ein Teil der Kopien nicht mit denselben Berechtigungen wie die Produktionsdaten einfach verändert oder gelöscht werden kann. In der Praxis kann es sich um unveränderlichen Speicher, eine logisch oder physisch getrennte Kopie oder ein anderes Modell handeln, das den Zugriff des Angreifers auf die Backup-Umgebung begrenzt.

Entscheidend ist nicht die konkrete Bezeichnung der Technologie, sondern das Sicherheitsprinzip: Eine Kompromittierung der Produktionsumgebung sollte nicht automatisch die Kompromittierung aller Wiederherstellungsmöglichkeiten bedeuten. Wenn ein einziges Konto oder eine einzige Administrationsebene Zugriff auf alles gewährt, schafft die Organisation einen gemeinsamen Ausfallpunkt.

Bei der Konzeption von Backups müssen daher auch folgende Aspekte bewertet werden:

• Trennung administrativer Berechtigungen,
• Authentifizierungsmethode,
• Schutz der Backup-Konsolen,
• Möglichkeiten zum Löschen von Kopien,
• Aufbewahrungsdauer,
• Überwachung von Änderungen in der Backup-Umgebung.

Dies hängt selbstverständlich auch mit dem Prinzip der Begrenzung von Vertrauen und Berechtigungen zusammen. Zero-Trust-Sicherheit beruht darauf, dass allein die Präsenz eines Kontos oder Geräts in der Unternehmensumgebung nicht automatisch uneingeschränktes Vertrauen bedeuten darf. Das ist gerade bei Administrator- und Backup-Konten besonders wichtig.

Systemwiederherstellung ist nicht dasselbe wie Datenwiederherstellung

Selbst wenn eine Datenbank erfolgreich wiederhergestellt wurde, muss die Anwendung noch nicht funktionieren. Moderne Unternehmenssysteme bestehen häufig aus mehreren voneinander abhängigen Komponenten, die in der richtigen Konfiguration verfügbar sein müssen. Ohne sie kann das Daten-Backup selbst praktisch unbrauchbar sein. Eine typische Unternehmensanwendung kann abhängen von:

• Datenbanken,
• Anwendungsservern,
• Identität und Authentifizierung,
• DNS,
• Zertifikaten,
• Netzwerkkonfiguration,
• Integrationsdiensten,
• Dateispeichern,
• weiteren internen oder cloudbasierten Systemen.

Wird nur die Datenbank wiederhergestellt, während Identitäts- oder Integrationsschicht weiterhin nicht verfügbar sind, funktioniert der Geschäftsprozess noch immer nicht. Ziel der Wiederherstellung ist daher nicht, einzelne Dateien zurückzubringen, sondern einen Dienst oder Prozess wieder in einen nutzbaren Zustand zu versetzen.

Abhängigkeiten zwischen Systemen bestimmen die tatsächliche Wiederherstellungsreihenfolge

Nach einem schwerwiegenden Vorfall können nicht alle Systeme gleichzeitig wiederhergestellt werden. Die Kapazitäten des Teams, der Infrastruktur und der Datenübertragung sind begrenzt, daher muss eine Reihenfolge festgelegt werden. Diese Reihenfolge sollte jedoch nicht allein davon abhängen, welches System als das wichtigste erscheint.

Ein ERP-System kann für das Unternehmen kritisch sein, aber ohne Identitätssystem, Datenbank oder Netzwerkdienste möglicherweise nicht funktionieren. Ein Onlineshop kann für den Vertrieb Priorität haben, doch ohne Lager- oder Zahlungssystem kann er eine Bestellung nicht abschließen. Die Wiederherstellung muss daher sowohl technische als auch prozessuale Abhängigkeiten berücksichtigen. Ein vereinfachtes Beispiel kann so aussehen:

Reihenfolge	Ebene	Warum
1	Basisinfrastruktur	Netzwerk, DNS, Virtualisierung
2	Identität und Zugriff	Anmeldung und Berechtigungen
3	Datenbanken	Grundlage der Anwendungen
4	Kritische Anwendungen	ERP, Produktion, Logistik
5	Integrationen	Verknüpfung der Systeme
6	Weniger kritische Dienste	Sekundäre Prozesse

 

Die konkrete Reihenfolge wird in jeder Organisation anders sein. Wichtig ist, dass sie vor dem Vorfall bekannt ist und nicht erst festgelegt wird, wenn bereits die Hälfte der Infrastruktur nicht funktioniert.

Das kritischste System muss nicht als Erstes wiederhergestellt werden

Dieser Umstand wird bei der Wiederherstellungsplanung häufig übersehen. Die Kritikalität eines Systems und seine Position in der Wiederherstellungsreihenfolge sind nicht zwangsläufig dasselbe. Die wichtigste Anwendung kann technisch von mehreren weniger sichtbaren Diensten abhängen. Daher muss eine Abhängigkeitsübersicht erstellt werden, die beispielsweise folgende Fragen beantwortet:

• Von welchen Diensten hängt die kritische Anwendung ab?
• Welche Datenbanken benötigt sie?
• Welches Identitätssystem verwendet sie?
• Welche Integrationen müssen verfügbar sein?
• Benötigt sie Zugang zum Internet oder zu Partnernetzwerken?
• Welche Zertifikate und Schlüssel werden benötigt?
• Was geschieht, wenn eine der Komponenten nicht wiederhergestellt wird?

Eine solche Analyse deckt häufig auch Abhängigkeiten auf, die der normale Betrieb verbirgt. Ein System kann jahrelang problemlos funktionieren, sodass die Organisation es nie vollständig von Grund auf neu starten musste. Ein Vorfall zeigt dann, dass die Dokumentation oder das Wissen über die ursprüngliche Startreihenfolge nicht mehr aktuell ist.

Ein Backup kann technisch erfolgreich und dennoch unbrauchbar sein

Das Backup-System kann jeden Tag den erfolgreichen Abschluss eines Backups melden. Dieser Status bestätigt jedoch in der Regel, dass der Backup-Prozess erwartungsgemäß abgelaufen ist, nicht aber, dass sich aus dieser Kopie ein gesamter Geschäftsprozess erfolgreich wiederherstellen lässt. Der Unterschied zeigt sich erst bei einem realen Test. Ein Problem kann beispielsweise dadurch entstehen, dass:

• das Backup beschädigt ist,
• ein Teil der Anwendungsdaten fehlt,
• erforderliche Konfigurationsdateien nicht gesichert werden,
• das Wiederherstellungsverfahren nicht bekannt ist,
• das neue System nicht mit der alten Konfiguration arbeiten kann,
• die Wiederherstellung deutlich länger dauert als angenommen.

Daher ist ein Wiederherstellungstest ebenso wichtig wie das Backup selbst. Das Unternehmen braucht nicht nur die Bestätigung, dass ein Backup erstellt wurde, sondern den Nachweis, dass daraus ein konkreter Dienst innerhalb einer akzeptablen Zeit wiederhergestellt werden kann.

Ein Wiederherstellungstest sollte nicht nur die Prüfung einer einzelnen Datei sein

Die Wiederherstellung eines Testdokuments bestätigt, dass das Backup eine bestimmte Datei enthält. Sie bestätigt jedoch nicht, dass die Organisation nach einem Ransomware-Angriff ein ERP-System, Domänendienste oder ein Produktionssystem wiederherstellen kann. Die Tests müssen daher dem entsprechen, was das Unternehmen bei einem tatsächlichen Vorfall wiederherstellen möchte. Der Umfang des Tests kann schrittweise wachsen:

• Wiederherstellung einer einzelnen Datei,
• Wiederherstellung einer Datenbank,
• Wiederherstellung eines virtuellen Servers,
• Wiederherstellung einer gesamten Anwendung,
• Wiederherstellung mehrerer voneinander abhängiger Systeme,
• Simulation eines größeren Ausfalls.

Je kritischer ein Prozess ist, desto wertvoller ist das Testen eines realistischen Szenarios. Der schlechteste Zeitpunkt, um festzustellen, dass das Wiederherstellungsverfahren nicht funktioniert, ist der Tag eines tatsächlichen Ransomware-Angriffs.

Die regelmäßige Überprüfung der Bereitschaft hängt auch mit dem umfassenderen Problem zusammen, sich auf isolierte Sicherheitsmaßnahmen zu verlassen. Die häufigsten Fehler in der IT-Sicherheit entstehen oft gerade dann, wenn eine Organisation eine Technologie zwar einsetzt, aber nicht überprüft, wie sie in einem realen Vorfallszenario funktioniert.

Die Wiederherstellung muss auch die Frage beantworten: Von welchem Zeitpunkt?

Bei Ransomware ist das neueste Backup nicht automatisch das beste. Wenn sich ein Angreifer bereits einige Zeit in der Umgebung befand, bevor der Vorfall entdeckt wurde, kann die letzte Kopie bereits schädliche Änderungen oder eine kompromittierte Konfiguration enthalten. Eine Wiederherstellung daraus könnte einen Teil des Problems zurückbringen.

Das Unternehmen muss daher ungefähr bestimmen können, wann die Kompromittierung begonnen hat. Dies kann eine Analyse von Protokollen, Identitätsereignissen, Endgeräten und weiteren Sicherheitsdaten erfordern. Je besser die Organisation den Vorfall rekonstruieren kann, desto besser kann sie einen vertrauenswürdigen Wiederherstellungspunkt auswählen.

Genau hier verbindet sich die Wiederherstellung mit dem Monitoring. Wenn Sicherheitsereignisse nicht kontinuierlich ausgewertet werden, kann es sehr schwierig sein festzustellen, ob der sichere Wiederherstellungspunkt zwei Stunden, zwei Tage oder zwei Wochen vor der Entdeckung des Vorfalls liegt. Die Fähigkeit des SOC, Ereignisse zu analysieren und daraus eine Zeitleiste des Angriffs zu erstellen, hilft daher nicht nur bei der Erkennung, sondern auch bei der Entscheidung über eine sichere Wiederherstellung.

Für die Wiederherstellung ist eine saubere Umgebung erforderlich

Einer der größten Fehler wäre es, Daten in einer Umgebung wiederherzustellen, die noch immer kompromittiert ist. Wenn der Angreifer weiterhin Zugriff hat, der Schadmechanismus nicht entfernt wurde oder kompromittierte Konten aktiv geblieben sind, können die wiederhergestellten Systeme erneut angegriffen werden. Eine schnelle Wiederherstellung ohne Beseitigung der Ursache kann daher einen weiteren Vorfall auslösen. Vor der Rückkehr kritischer Systeme ist insbesondere zu prüfen:

• ob die Bedrohung isoliert wurde,
• welche Identitäten kompromittiert wurden,
• welche Geräte bereinigt oder neu erstellt werden müssen,
• ob Sicherheitsupdates installiert wurden,
• ob gefährliche Sitzungen und Zugriffe beendet wurden,
• ob der ursprüngliche Eintrittspunkt beseitigt wurde.

Dieses Prinzip ist auch bei der Kompromittierung von Identitäten wichtig. Verfügt der Angreifer weiterhin über ein gültiges Administratorkonto, löst die Wiederherstellung der Server allein das Problem nicht. Deshalb muss die Wiederherstellung an die Reaktion auf den Vorfall anknüpfen und darf nicht als isolierter technischer Prozess funktionieren.

RTO: Wie lange darf ein Prozess nicht verfügbar sein?

Bei der Wiederherstellungsplanung wird der Begriff RTO (Recovery Time Objective) verwendet. Er bezeichnet die angestrebte maximale Zeit, während der ein bestimmter Dienst oder Prozess nach einem Vorfall nicht verfügbar sein darf. Nicht jedes System benötigt dabei dasselbe Verfügbarkeitsniveau. Ein Beispiel kann so aussehen:

System	Akzeptables Wiederherstellungsziel
Produktionssystem	Stunden
Onlineshop	Stunden
ERP	Stunden bis zu einem Tag
Internes Archiv	Tage

 

Dies ist nur ein veranschaulichendes Beispiel, da die tatsächlichen Werte von den konkreten geschäftlichen Auswirkungen abgeleitet werden müssen. Der Zweck der RTO besteht darin, die technischen Wiederherstellungsmöglichkeiten damit zu verknüpfen, wie lange das Unternehmen es sich leisten kann, einen bestimmten Prozess nicht zu betreiben.

Ohne eine definierte RTO lässt sich nicht objektiv beurteilen, ob die Wiederherstellung schnell genug ist. Eine Wiederherstellung in zehn Stunden kann für ein System ein hervorragendes Ergebnis und für ein anderes inakzeptabel sein.

RPO: Wie viele Daten darf ein Unternehmen verlieren?

Der zweite wichtige Begriff ist RPO (Recovery Point Objective). Er bezeichnet den maximalen zeitlichen Datenverlust, den eine Organisation zu akzeptieren bereit ist. Wird beispielsweise einmal täglich ein Backup erstellt, muss bei einem Vorfall theoretisch mit dem Verlust der Änderungen fast eines ganzen Tages gerechnet werden.

Die RPO beeinflusst die Häufigkeit von Backups oder Replikationen. Ein System, in dem jede Minute kritische Transaktionen entstehen, kann eine völlig andere Strategie benötigen als ein Dokumentenarchiv, das nur einige Male pro Woche verändert wird. Auch hier gibt es daher keinen universellen Wert für das gesamte Unternehmen. RTO und RPO helfen gemeinsam, zwei unterschiedliche Fragen zu beantworten:

• Wie schnell muss das System wieder verfügbar sein?
• Wie viele der zuletzt entstandenen Daten dürfen verloren gehen?

Die bloße Aussage „Wir erstellen täglich Backups“ beantwortet keine dieser Fragen.

Die Wiederherstellungsreihenfolge muss sich an den geschäftlichen Auswirkungen orientieren

Die IT kennt naturgemäß die technische Architektur. Geschäftsleitung und Prozesseigentümer wissen wiederum, welche Dienste die größten Auswirkungen auf Kunden, Produktion oder Finanzen haben. Ein Wiederherstellungsplan kann daher nicht nur als technisches Dokument einer einzigen Abteilung erstellt werden. Bei der Festlegung der Prioritäten sind beispielsweise zu bewerten:

• Auswirkungen des Ausfalls auf den Umsatz,
• Stillstand von Produktion oder Logistik,
• Auswirkungen auf Kunden,
• regulatorische Pflichten,
• Abhängigkeiten weiterer Systeme,
• Verfügbarkeit eines manuellen Ersatzprozesses.

Ein weniger sichtbarer interner Dienst kann eine höhere Priorität haben als eine Anwendung, die von Hunderten Mitarbeitenden genutzt wird, wenn der Start der übrigen Umgebung von ihm abhängt. Die Wiederherstellungsreihenfolge muss sich daher aus einer Kombination von geschäftlicher Kritikalität und technischen Abhängigkeiten ergeben.

Was ein Unternehmen bereits vor einem Vorfall über seine Backups wissen sollte

Ein guter Wiederherstellungsplan muss nicht mit einer komplizierten technischen Dokumentation beginnen. Ein großer Teil der Schwachstellen lässt sich bereits anhand einiger praktischer Fragen erkennen. Gibt es darauf keine eindeutige Antwort, bietet das bloße Vorhandensein eines Backups nur begrenzte Sicherheit. Das Unternehmen sollte zumindest wissen:

• welche Systeme tatsächlich gesichert werden,
• wie häufig Kopien erstellt werden,
• wo sie gespeichert sind,
• wer sie ändern oder löschen kann,
• wie lange sie aufbewahrt werden,
• wann die Wiederherstellung zuletzt erfolgreich getestet wurde,
• wie lange die Wiederherstellung gedauert hat,
• wer sie durchführen kann,
• was zuerst wiederhergestellt werden muss,
• von welchen weiteren Systemen die Wiederherstellung abhängt.

Diese Fragen zeigen zugleich den Unterschied zwischen technischer Konfiguration und betrieblicher Bereitschaft. Das Backup-System kann korrekt eingerichtet sein, doch wenn nur eine Person das Verfahren kennt oder die Abhängigkeiten unbekannt sind, bleibt das organisatorische Risiko hoch.

Der Wiederherstellungsplan muss auch berücksichtigen, dass die üblichen Werkzeuge nicht funktionieren

Bei einem schwerwiegenden Vorfall sind E-Mail, Unternehmenschat, Dokumentation oder Identitätssystem möglicherweise nicht verfügbar. Ein Wiederherstellungsplan, der nur auf demselben Server gespeichert ist, der gerade verschlüsselt wurde, ist im kritischen Moment unbrauchbar. Ebenso problematisch ist eine Kontaktliste, die nur über die nicht verfügbare Unternehmensinfrastruktur zugänglich ist. Daher müssen auch praktische Fragen berücksichtigt werden:

• Wo ist der Wiederherstellungsplan gespeichert?
• Wie greift das Team während eines Ausfalls darauf zu?
• Gibt es alternative Kommunikationskanäle?
• Sind die erforderlichen Passwörter oder Notfallkonten verfügbar?
• Wer ist befugt, über Prioritäten zu entscheiden?
• Wer kommuniziert mit der Geschäftsleitung, Kunden oder Partnern?

Cyberresilienz ist nicht nur eine Eigenschaft der Technologie. Sie ist die Fähigkeit einer Organisation, koordinierte Entscheidungen zu treffen, selbst wenn ihre üblichen Arbeitsmittel nicht verfügbar sind.

Ein manueller Ersatzprozess kann ebenso wichtig sein wie die technische Wiederherstellung

Nicht jedes System kann innerhalb weniger Minuten wiederhergestellt werden. Bei kritischen Geschäftsprozessen kann daher auch ein vorübergehender manueller oder eingeschränkter Betrieb Teil der Kontinuität sein. Dieser kann den grundlegenden Betrieb aufrechterhalten, bis das Informationssystem sicher wiederhergestellt ist. Ein solcher Plan kann beispielsweise Folgendes festlegen:

• eine vorübergehende Methode zur Annahme von Bestellungen,
• manuelle Erfassung kritischer Vorgänge,
• eine alternative Kommunikationsmethode,
• einen eingeschränkten Produktionsbetrieb,
• bevorzugte Betreuung wichtiger Kunden.

Wichtig ist, dass der Ersatzprozess nicht erstmals während eines Vorfalls entsteht. In einer Stresssituation ist es einfacher, ein vorab vorbereitetes und getestetes Verfahren zu verwenden, als die Arbeitsweise einer ganzen Abteilung zu improvisieren.

Sieben Anzeichen dafür, dass Backups ein falsches Sicherheitsgefühl vermitteln

Das bloße Vorhandensein eines Backups kann besonders dann irreführend sein, wenn das Unternehmen die weiteren Bestandteile der Wiederherstellung nicht beherrscht. Die folgenden Situationen sind ein guter Grund, die Bereitschaft zu überprüfen:

1. Die Wiederherstellung der gesamten Anwendung wurde noch nie getestet.
2. Es ist nicht bekannt, wie lange die Wiederherstellung dauern würde.
3. Produktion und Backups verwenden dieselben privilegierten Konten.
4. Niemand verfügt über eine aktuelle Übersicht der Systemabhängigkeiten.
5. Die Wiederherstellungsreihenfolge ist nicht im Voraus festgelegt.
6. Nur ein oder zwei Mitarbeitende kennen das Wiederherstellungsverfahren.
7. Das Unternehmen weiß nicht, von welchem Punkt aus es nach einem Ransomware-Angriff sicher wiederherstellen würde.

Eines dieser Probleme muss nicht automatisch bedeuten, dass die Organisation kein funktionsfähiges Backup hat. Ihre Kombination verringert jedoch erheblich die Gewissheit, dass sich ein Backup bei einem realen Vorfall in eine schnelle und sichere Wiederherstellung umsetzen lässt.

Backups sind die letzte Absicherung, nicht die einzige Verteidigung

Die Wiederherstellung ist ein äußerst wichtiger Bestandteil des Schutzes vor Ransomware, sollte jedoch weder die erste noch die einzige Verteidigungslinie sein. Erreicht ein Angriff die Produktionssysteme und muss das Unternehmen eine umfangreiche Infrastruktur wiederherstellen, hat der Vorfall unabhängig von der Qualität des Backups bereits betriebliche Kosten verursacht. Ein besseres Ergebnis ist es, den Angriff noch vor der destruktiven Phase zu erkennen und einzudämmen. Deshalb werden Backups ergänzt durch:

• Identitätsschutz,
• Segmentierung,
• Schutz von Endgeräten,
• Schwachstellenmanagement,
• Monitoring,
• Erkennung ungewöhnlichen Verhaltens,
• Reaktion auf Vorfälle.

Gerade die Kombination mehrerer Schutzebenen verringert die Wahrscheinlichkeit, dass ein einzelner Fehler zu einem unternehmensweiten Ausfall führt. Dasselbe Prinzip liegt auch dem mehrschichtigen Schutz der Unternehmensinfrastruktur zugrunde, bei dem keine einzelne Maßnahme als absoluter Schutz betrachtet werden kann.

Der wichtigste Test lautet nicht „Haben wir ein Backup?“

Viel hilfreicher ist die Frage: Könnten wir morgen früh den kritischen Betrieb wiederherstellen, wenn ein Teil der Infrastruktur verschlüsselt wäre und der Produktionsumgebung nicht vertraut werden könnte?

Eine solche Frage verändert sofort die Perspektive. Es reicht nicht mehr, das grüne Symbol des letzten Backups zu zeigen, denn es müssen ein sicherer Wiederherstellungspunkt, eine neue oder bereinigte Umgebung, Identitäten, Abhängigkeiten, Wiederherstellungskapazitäten und die Personen berücksichtigt werden, die den gesamten Prozess durchführen.

Deshalb ist es beim Schutz vor Ransomware sinnvoll, nicht nur die Prävention des Angriffs selbst zu bewerten, sondern auch die Bereitschaft für den Fall, dass sich ein Vorfall nicht vollständig verhindern lässt. Ransomware-Prävention und die Reaktion nach ihrer Entdeckung sind zwei Teile desselben Problems. Die Wiederherstellungsfähigkeit entscheidet darüber, wie schnell aus einem Sicherheitsvorfall keine betriebliche Krise mehr wird.

Vom Backup zur Cyberresilienz

Der Unterschied zwischen Backups und tatsächlicher Bereitschaft lässt sich einfach zusammenfassen. Ein Backup schützt eine Kopie der Daten, die Wiederherstellung stellt Systeme wieder her, und die Betriebskontinuität sorgt dafür, dass das Unternehmen während und nach einem Vorfall arbeitsfähig bleibt. Erst die Kombination dieser Bereiche schafft echte Cyberresilienz.

Vor der Bewertung technologischer Wiederherstellungsmöglichkeiten müssen daher vor allem die kritischen Prozesse, ihre Abhängigkeiten und die maximal akzeptable Ausfallzeit bekannt sein. Auf dieser Grundlage können anschließend eine geeignete Backup-Architektur, der Schutz der Kopien, die Testhäufigkeit und die Wiederherstellungsreihenfolge festgelegt werden. Der Wiederherstellungsplan sollte danach konzipiert sein, was das Unternehmen wieder in Betrieb nehmen muss, und nicht nur danach, was es technisch sichern kann.

Ein Backup hat erst dann einen Wert, wenn damit der Betrieb wiederhergestellt werden kann

Ransomware kann Daten, Identitäten, Server und auch die Backup-Infrastruktur selbst treffen. Daher reicht es nicht zu wissen, dass ein Backup existiert. Man muss wissen, ob es vertrauenswürdig, ausreichend getrennt, getestet und in der tatsächlichen Wiederherstellungsreihenfolge nutzbar ist. Ein erster Schritt kann die Überprüfung von fünf Bereichen sein:

• kritische Systeme und Prozesse,
• verfügbare und geschützte Backups,
• RTO- und RPO-Anforderungen,
• technische Abhängigkeiten,
• regelmäßige Wiederherstellungstests.

ANASOFT deckt den Bereich der Cybersicherheit einschließlich der Wiederherstellung nach Vorfällen und der Betriebskontinuität als Teil einer umfassenderen Sicherheitsstrategie ab. Ziel ist es nicht nur, eine Kopie der Daten aufzubewahren, sondern die Fähigkeit zu schaffen, kritische Systeme sicher und innerhalb eines Zeitrahmens wiederherzustellen, der den Betrieb des Unternehmens nicht gefährdet.

Häufig gestellte Fragen