Backup-Restore-Test: Prüfen Sie Ihre Backups vor der Ransomware

Bevor Ransomware Ihre Backups auf die Probe stellt, führen Sie drei Prüfungen selbst durch: ob jemand die Backups löschen kann, ob ein gestohlener Admin-Account sie erreicht und wie lange ein echter Restore dauert - gemessen an dem, was das Unternehmen verkraften kann.

Die NCSC-Empfehlungen zur Abwehr von Malware und Ransomware sind eindeutig. Aktuelle Backups sind der wirksamste Weg, sich von einem Ransomware-Angriff zu erholen. Ransomware nimmt sie gezielt ins Visier, um die Zahlungsbereitschaft zu erhöhen, und Angreifer haben bereits kopierte Dateien zerstört oder die Wiederherstellung gestört, bevor sie den eigentlichen Angriff gestartet haben. Testen Sie Ihre Backups deshalb so, wie es ein Angreifer tun würde.

Test 1: Versuchen Sie, Ihr eigenes Backup zu löschen

Die Beispiele hier verwenden Amazon S3 Object Lock. Suchen Sie bei anderen Lösungen die entsprechende Immutability- oder Retention-Sperre in Ihrem Backup-Produkt. Prüfen Sie, ob sie aktiviert ist, wie lang die Aufbewahrungsfrist ist und wer sie verkürzen oder aufheben kann. Versuchen Sie dann, ein dauerhaftes Löschen durchzuführen: als gewöhnlicher Benutzer, als Ihr am höchsten privilegierter Backup-Administrator und mit einem Konto, das ein Angreifer plausiblerweise übernehmen könnte. Halten Sie fest, wer damit Erfolg hat.

Arbeiten Sie bei S3 in einem Scratch-Bucket. Object Lock funktioniert nur in Buckets mit aktiviertem S3 Versioning, prüfen Sie das also zuerst. Verwenden Sie den Governance-Modus, den AWS als Möglichkeit beschreibt, Retention-Einstellungen zu testen, bevor eine Aufbewahrungsfrist im Compliance-Modus angelegt wird.

Wenden Sie im Scratch-Bucket niemals den Compliance-Modus an. Im Compliance-Modus lässt sich der Retention-Modus nicht ändern und die Frist nicht verkürzen. Ein per Compliance-Modus gesperrtes Objekt lässt sich vorzeitig nur löschen, indem man den zugehörigen AWS-Account löscht.

Führen Sie diese Versuche sowohl über die Konsole als auch über die API bzw. CLI durch und vergleichen Sie die Ergebnisse:

Die zweite Zeile ist kein Fehlschlag: Die gesperrte Version bleibt erhalten, denn Aufbewahrungsfristen verhindern nicht, dass neue Versionen oder Delete Marker angelegt werden. Die dritte Zeile ist das eigentliche Problem. Die S3-Konsole sendet den Header x-amz-bypass-governance-retention:true standardmäßig mit. Wer diese Berechtigung besitzt, kann Governance-gesperrte Objekte daher mit wenigen Klicks löschen.

Senden Sie anschließend dasselbe dauerhafte Löschen als dieser Benutzer über die API bzw. CLI ohne den Header. AWS verlangt ihn bei jeder Anfrage, die den Governance-Modus übergeht, daher sollte das mit Access Denied enden. Falls es gelingt, prüfen Sie den Retention-Modus des Buckets und die Sperreinstellungen der Objektversion.

Prüfen Sie dann, wer die Sperre aufheben kann

Listen Sie alle Principals auf, deren Richtlinien s3:BypassGovernanceRetention erlauben, einschließlich Rollen, Gruppen und Inline-Richtlinien. Gehen Sie ebenso für s3:PutObjectLegalHold vor: Ein Legal Hold hat kein Ablaufdatum, und jeder Benutzer mit dieser Berechtigung kann Holds beliebig setzen und wieder entfernen.

Entziehen Sie beide Berechtigungen allen Konten, die ein Angreifer plausiblerweise übernehmen könnte. Erwägen Sie für Daten, die Sie nicht verlieren dürfen, den Compliance-Modus mit einer bewusst gewählten Aufbewahrungsfrist.

Test 2: Versuchen Sie, das Backup mit den falschen Zugangsdaten zu erreichen

Unveränderlicher Speicher hilft nicht, wenn der Angreifer die Konsole kontrolliert, über die er verwaltet wird. Versuchen Sie, sich mit einem Domain-Admin, einem Backup-Operator-Konto und einem Cloud-IAM-Benutzer an der Backup-Konsole und am Speicher anzumelden, und prüfen Sie, ob jedes dieser Konten Daten löschen oder Retention-Einstellungen ändern kann.

Das NCSC empfiehlt für Backup-Konten folgende Schutzmaßnahmen:

• Privileged Access Workstations und Hardware-Firewalls, die IP-Allowlisting durchsetzen.
• MFA, wobei die MFA-Methode nicht auf dem Gerät installiert sein darf, mit dem die Backups administriert werden.
• Privileged Access Management, damit Administratoren nicht direkt auf hochwertige Backup-Systeme zugreifen.

Backup-Laufwerke und USB-Sticks sollten nicht dauerhaft mit Ihrem Netzwerk verbunden sein, und die Backup-Produkte müssen gepatcht werden. Stellen Sie bei einem Cloud-Dienst sicher, dass frühere Versionen vor sofortigem Löschen geschützt sind und Sie darauf zurücksetzen können. Denn Dienste synchronisieren oft unmittelbar, nachdem Ihre Dateien durch verschlüsselte Kopien ersetzt wurden.

Test 3: Stellen Sie etwas wieder her - mit Stoppuhr

Wählen Sie ein System, das das Unternehmen innerhalb eines Tages vermissen würde, und stellen Sie es aus dem Backup in einer sauberen, isolierten Umgebung wieder her, damit eine wiederhergestellte Infektion nicht auf Produktivsysteme übergreifen kann. Notieren Sie die verstrichene Zeit, wer was getan hat und jede Stelle, an der jemand ein Passwort, einen Lizenzschlüssel oder ein Dokument suchen musste, das auf den Servern liegt, die Sie gerade wiederherstellen.

Scheitert der Restore auf halber Strecke, halten Sie den Schritt, die verstrichene Zeit, die Ursache und die Lösung fest, starten dann ab diesem Schritt neu und protokollieren die verbleibende Zeit getrennt. Halten Sie die Schritte zwischen den Durchläufen identisch, damit die Ergebnisse vergleichbar bleiben.

Verbinden Sie Backups vor der Wiederherstellung nur mit bekanntermaßen sauberen Geräten und scannen Sie sie auf Malware, bevor Sie Dateien zurückspielen. Ransomware kann sich bereits in Backups ausgebreitet haben, bevor sie entdeckt wurde, ein scheinbar sauberer Wiederherstellungspunkt muss also nicht sauber sein.

Vergleichen Sie Ihre gemessene Zeit mit dem, was das Unternehmen als tolerierbar angibt. Lassen Sie sich diese Zahl vor dem Test vom Systemverantwortlichen nennen, damit Sie das Ziel nicht dem Ergebnis anpassen. Eine vollständige Wiederherstellung nach Ransomware kann, sofern sie überhaupt möglich ist, mehrere Wochen dauern. Betrachten Sie den Wert für ein einzelnes System daher als Untergrenze.

Überlegen Sie auf dem Papier, was passiert, wenn sowohl die lokalen Systeme als auch die Cloud-Backup-Server unbrauchbar sind und Sie aus Offline-Backups neu aufbauen müssen, und wie Sie kritische Geschäftsprozesse weiter am Laufen halten würden. Prüfen Sie, dass Playbooks, Checklisten und Kontaktdaten an einem Ort vorliegen, auf den Sie auch ohne Ihre IT-Systeme zugreifen können. Unser Incident-Response-Service deckt solche Übungen ab, falls Sie eine Sicht von außen wünschen.

Wo Sie anfangen

1. Wählen Sie ein geschäftskritisches System und fragen Sie dessen Verantwortlichen, wie lange es ausfallen darf. Schreiben Sie die Zahl zuerst auf.
2. Legen Sie einen Scratch-S3-Bucket mit Versioning und Object Lock im Governance-Modus an, niemals im Compliance-Modus. Versuchen Sie ein dauerhaftes und ein einfaches Löschen und halten Sie die Antworten fest.
3. Wiederholen Sie das dauerhafte Löschen als Benutzer mit s3:BypassGovernanceRetention, über die Konsole und über die API bzw. CLI ohne den Bypass-Header. Listen Sie dann alle Inhaber dieser Berechtigung und von s3:PutObjectLegalHold auf und entziehen Sie sie denjenigen, die sie nicht benötigen.
4. Versuchen Sie, sich mit einem Domain-Admin, einem Backup-Operator und einem Cloud-IAM-Benutzer an der Backup-Konsole anzumelden. Wo eine Anmeldung funktioniert hat, planen Sie MFA auf einem separaten Gerät und IP-Allowlisting. Stellen Sie sicher, dass eine Offline-Kopie existiert, nicht dauerhaft verbunden ist und daraus bereits wiederhergestellt wurde.
5. Stellen Sie das gewählte System aus einem gescannten Backup in einer isolierten Umgebung wieder her, messen Sie jeden Schritt und vergleichen Sie das Ergebnis mit der Zahl aus Schritt 1.
6. Schließen Sie die größte Lücke und wiederholen Sie die Tests, sobald sich das Backup-Design ändert.