Das Backup, das Sie nie getestet haben, ist kein Backup
Ransomware-Gruppen gehen zuerst an die Backups, genau weil ein funktionierender Restore ihnen den Hebel nimmt. Die meisten Organisationen entdecken ihre Wiederherstellzeit während des Vorfalls.
One stopwatch, nothing else
A single mechanical stopwatch on a seamless bone-white surface, viewed slightly from above. Vast empty space around it. Nothing else in frame.
2400×1350 · WebP · <350KB
Jede Organisation, der wir durch einen Ransomware-Vorfall geholfen haben, hatte Backups. Das ist nicht der Unterschied. Der Unterschied ist, ob je jemand daraus wiederhergestellt hat — unter Zeitdruck, während die Person, die das sonst macht, nicht verfügbar war, und während auch der Domänencontroller verschlüsselt war.
Angreifer nehmen sich Backups gezielt vor
Moderne Ransomware-Betreiber sind keine Gelegenheitstäter, die zufällig eine Dateifreigabe verschlüsseln. Sie verbringen zuerst Tage im Netzwerk, und eines ihrer frühesten Ziele ist Ihre Backup-Infrastruktur — denn ein Kunde, der wiederherstellen kann, zahlt nicht. Sie löschen Snapshots, beschädigen Repositories, und wenn Ihr Backup-Server domänengebunden mit einem Domänenadmin-Dienstkonto läuft, tun sie es mit Ihren eigenen Zugangsdaten.
Wenn ein Angreifer mit Domänenadmin-Rechten Ihre Backups löschen kann, haben Sie keine Backups. Sie haben Kopien.
3-2-1-1-0 — und der Teil, den alle überspringen
- 3 Kopien der Daten
- 2 verschiedene Medientypen
- 1 Kopie ausgelagert
- 1 Kopie unveränderlich oder air-gapped — Object-Lock-Speicher, den ein Angreifer selbst mit voller Kontrolle nicht löschen kann
- 0 Fehler bei der Restore-Verifikation
Die letzte Null ist die, die wegfällt, weil sie als Einzige dauerhaften Aufwand statt einer Anschaffung verlangt. Alles davor ist Architektur. Die letzte Ziffer ist eine Gewohnheit.
Wie ein echter Restore-Test aussieht
Nicht ein Backup-Job, der Erfolg gemeldet hat. Eine echte Wiederherstellung, auf isolierte Infrastruktur, eines Systems, auf das es ankommt, mit der Stoppuhr gemessen, durchgeführt von jemandem, der es nicht gebaut hat. Sie testen dabei drei Dinge gleichzeitig: dass die Daten intakt sind, dass das Runbook stimmt und dass ein normales Teammitglied ihm folgen kann.
Machen Sie es mit ausgedrucktem Runbook. In einem echten Vorfall kann Ihr Wiki verschlüsselt sein, Ihr SSO ausgefallen und Ihr Passwortmanager eines der Systeme, die Sie gerade wiederherstellen wollen.
Die Zahlen, die Sie nennen können sollten
Für jede Systemstufe: wie viele Daten Sie verlieren können (RPO), wie lange Sie ausfallen können (RTO) und — getrennt davon — die Wiederherstellzeit, die Sie tatsächlich gemessen haben. Die Lücke zwischen den letzten beiden ist Ihr reales Risiko und die einzige Zahl in diesem Text, die in den Vorstand gehört.
Bei den meisten Organisationen, die wir bewerten, beträgt diese Lücke den Faktor drei oder mehr. Nicht weil die Technik falsch wäre, sondern weil niemand die Stunden für die Wiederherstellung von Active Directory vor den Applikationsservern gezählt hatte — oder bemerkt hatte, dass die ausgelagerte Kopie über eine Leitung zurückkommt, die für ein Terabyte elf Stunden braucht.