Ransomware-Attacken laufen ins Leere

Schnelle Wiederaufnahme des Geschäftsbetriebs nach Ransomware-Angriffen ist möglich, wenn gewährleistet ist, dass die Backup-Daten unveränderbar sind. Immer wieder wird von betroffenen Unternehmen berichtet, die nicht mehr auf ihre geschäftskritischen Daten zugreifen können.

Die Angreifer bringen den Geschäftsbetrieb zum Erliegen, indem sie den Zugriff auf Produktionsdaten und Datenspeicher verschlüsseln. Dem Emsisoft Malware Lab zufolge haben Ransomware-Angriffe im Jahr 2019 „mindestens 966 Regierungsbehörden, Bildungseinrichtungen und Gesundheitseinrichtungen betroffen“. Dies verursachte potenzielle Kosten von über 7,5 Milliarden US-Dollar. Die Folgen und Gefahren für die vielen Millionen mittelständischer Unternehmen können nur erahnt werden.

„Obwohl die Cybersicherheitsteams vielerorts in zahlreiche Schutzinstrumente investiert haben, finden Erpresser dennoch weiterhin Möglichkeiten wichtige Unternehmensdaten zu verschlüsseln – es genügt schon ein Mitarbeiter, der aus Versehen ein gefährliches Attachment öffnet“, erklärt Roland Rosenau SE Manager EMEA Central and West bei Rubrik. „Dies ist kein Geheimnis, denn selbst die führenden IT-Sicherheitsanbieter geben offen zu: 100% Schutz vor Eindringlingen gibt es nicht.“

So stellt sich also die Frage, wie man eine Ransomware-Attacke ins Leere laufen lassen kann, selbst wenn der Angreifer schon erfolgreich in die jeweilige IT-Infrastruktur eingedrungen ist. Die Antwort hat nur sieben Buchstaben: Backups. Backups sind eine der wichtigsten, wenn nicht sogar die wichtigste, Verteidigungsmaßnahme gegen Ransomware, wenn sie selbst nicht von den Angreifern beschädigt wurden. Aber: Aktuelle Ransomware-Technologien zielen jetzt auch vermehrt direkt auf Backups ab. Sie modifizieren oder löschen diese vollständig. Damit überwinden die Angreifer die letzte Verteidigungslinie und können hohe Lösegeldforderungen stellen. 

Direkte Folgen von Ransomware

Ransomware soll Daten so verschlüsseln, dass sie nicht mehr verwendbar sind. Häufig bedeutet dies die Verschlüsselung von Daten, die auf dem Primärspeicher vorgehalten werden, was massive Anstrengungen zur Datenwiederherstellung von Bandspeicher oder anderen Archiven erfordert. Zusätzlich führen die Angreifer eine Verschlüsselung auf niedrigerer Ebene des Master Boot Record (MBR) oder auf Betriebssystemebene durch, um das Booten und andere gängige Operationen zu blockieren. In virtualisierten Umgebungen ist der gemeinsam genutzte Datenspeicher, der zum Hosten virtueller Maschinen verwendet wird, ein primäres Ziel, wie z.B. bei NFS-unterstützten Datenspeichern. Dadurch können kritische Dienste effektiv lahm gelegt werden. Die Angreifer verlangen dann ein Lösegeld, um die Daten oder Systeme freizugeben, damit Unternehmen die Dienste wieder aufnehmen können.

Wie geht man nach einem Ransomware-Angriff vor?

Datensicherungen sind generell eine effektive Methode zur Wiederherstellung von Daten, die durch den Angriff gesperrt/verschlüsselt wurden. Was aber, wenn die Sicherungsdaten ebenfalls verschlüsselt oder durch einen Ransomware-Angriff gelöscht wurden? Wie stellen Unternehmen sicher, dass Ihre Sicherungsdaten nicht für diese Angriffe anfällig sind?

Entscheidend sind unveränderbare Backups

Während primäre Speichersysteme offen und für Clientsysteme verfügbar sein müssen, sollten Backup-Daten unveränderbar sein. Das bedeutet, dass einmal geschriebene Daten von den Clients im Netzwerk nicht mehr geändert oder gelöscht werden können. Dies ist die einzige Möglichkeit, die Wiederherstellung sicherzustellen, wenn die Produktionssysteme kompromittiert werden. Dies geht weit über einfache Dateiberechtigungen, Ordner-ACLs oder Speicherprotokolle hinaus. Das Konzept der Unveränderbarkeit muss in die Backup-Architektur „eingebacken“ werden, damit die Backups nicht manipuliert werden können.

Konzeptionell auf Unveränderbarkeit ausgelegt

Führende Anbieter zeitgemäßer Lösungen für Data Management verwenden eine auf unveränderbare Daten ausgelegte „Immutable“-Architektur, die ein Immutable-Dateisystem mit einem Zero-Trust-Cluster-Design kombiniert. Alle Datenoperationen können nur über authentifizierte APIs durchgeführt werden.

Ein unveränderbares verteiltes Dateisystem

„Den Ansatz der unveränderlichen Backups haben wir von Anfang an verfolgt“, berichtet Roland Rosenau. „Eine der ersten Designentscheidungen von Rubrik war die Konstruktion von Atlas, einem unveränderbaren Dateisystem im Userspace (FUSE), das weitgehend POSIX-konform ist.“

Dies ermöglicht eine strenge Kontrolle darüber, welche Anwendungen Informationen austauschen können, wie jeder Datenaustausch abgewickelt wird und wie die Daten über physische und logische Geräte angeordnet werden. Atlas ist als ein verteiltes und unveränderbares Dateisystem zum Schreiben und Lesen von Daten für andere Dienste konzipiert.

Die Unveränderbarkeit wird über zwei Schichten bereitgestellt: die logische Schicht (Patch-Dateien, Patch-Blöcke) und die physische Schicht (Stripes, Chunks). Die Dynamik zwischen diesen beiden Schichten wird in den nächsten Abschnitten näher erläutert.

Die logische Schicht

Alle in das System eingebrachten Kundendaten werden in eine proprietäre Sparse-Datei, eine so genannte Patch-Datei, geschrieben. Es handelt sich dabei um reine Append-only Files (AOFs), was bedeutet, dass Daten nur in die Patch-Datei aufgenommen werden können, wenn diese als offen markiert ist. Alle Snapshot- und Journal-Daten werden in Atlas gespeichert, was die Verwendung von Patch-Dateien in der zugrundeliegenden Verzeichnisstruktur erzwingt. Dieses Dateisystem verweigert Schreibvorgänge auf API-Ebene, die nicht nur angehängt werden, wie z.B. Situationen, in denen der Schreibversatzwert (Write Offset Value) nicht der Dateigröße entspricht. Atlas hat die vollständige Kontrolle darüber, wie und wo Kundendaten geschrieben werden.

Wenn Backup-Daten verändert wurden, sind sie im Prinzip wertlos. Dieses Problem wurde gelöst, indem gewährleistet ist, dass für jeden Patch-Block innerhalb einer Patch-Datei Prüfsummen generiert werden. Diese Prüfsummen werden berechnet und in eine Fingerprint-Datei geschrieben, die zusammen mit der Patch-Datei gespeichert wird. Rubrik führt immer eine „Fingerabdruckprüfung“ durch, bevor eine Datentransformation erfolgt. Dadurch ist gewährleistet, dass die Originaldatei mit erzwungener Validierung während der Leseoperationen intakt bleibt.

Um einem Ransomware-Angriff entgegenzuwirken, müssen die ursprünglichen, validierten Daten aus dem Backup wiederhergestellt werden. Rubrik verifiziert routinemäßig die Patch-Blöcke anhand ihrer Prüfsummen, um die Datenintegrität auf der Ebene der logischen Patch-Blöcke sicherzustellen. Die Patch-Dateien sind keinen externen Systemen oder Kunden-Administratorkonten ausgesetzt. Somit wird akribisch darauf geachtet, genau das wiederherzustellen, was ursprünglich in einem Backup gespeichert wurde.

Beim herkömmlichen Ansatz hingegen wird administrativer Zugriff auf das Dateisystem gewährt, insbesondere bei der Verwendung von Allzweckspeichern. Dies bringt weitere Herausforderungen hinsichtlich Vertraulichkeit und Integrität mit sich und öffnet einen weiteren Angriffsvektor für „Leakware“. Darüber hinaus stellen viele andere Lösungen einfach die Daten wieder her, die sich im Backup-Ordner oder -Volume befinden, ohne dass eine Validierung durchgeführt wird und andere notwendige Überprüfimgen der Daten durchgeführt wird.

Die physische Schicht

Während sich die logische Schicht auf die Datenintegrität auf Dateiebene konzentriert, konzentriert sich die physische Schicht auf das Schreiben von Daten auf dem unveränderbaren Cluster, um Datenintegrität und Datenstabilität zu erreichen. Zu diesem Zweck werden Patch-Dateien logisch in Segmente fester Länge, die als Stripes bezeichnet werden, unterteilt. Beim Schreiben von Stripes berechnet die AOF eine Prüfsumme auf Stripe-Ebene, die sie in den einzelnen Stripe-Metadaten speichert.

Die Stripes werden weiter in physische Chunks unterteilt, die auf physischen Platten innerhalb des Rubrik-Clusters gespeichert sind. Aktivitäten wie die Replikations- und Löschcodierung finden auf der Chunk-Ebene statt. Genau wie bei Patch-Dateien wird beim Schreiben jedes Chunks eine Chunk-Prüfsumme berechnet und in den Stripe-Metadaten neben der Liste der Chunks gespeichert. „Diese Prüfsummen werden als Teil des Hintergrundscans von Atlas regelmäßig neu berechnet, indem die physischen Chunks gelesen und mit den Prüfsummen in den Stripes-Metadaten verglichen werden. Zusätzlich wird im Falle einer erforderlichen Neuerstellung der Daten die durch die Löschkodierung gebotene Widerstandsfähigkeit automatisch im Hintergrund genutzt“, erklärt Rosenau weiter.

Zero-Trust-Cluster-Design

Herkömmliche Ansätze zur Clustersicherheit beruhen oft auf einem „Full Trust“-Modell, bei dem alle Mitglieder des Clusters miteinander kommunizieren können. In einigen Fällen beinhaltet dies Autorität auf Root-Ebene, keine gegenseitige Authentifizierungsprüfung und die Möglichkeit, Daten, die im Dateisystem gespeichert sind, zu lesen oder zu ändern. Dies schafft eine empfindliche Angriffsfläche, wenn eine Architektur eigentlich nach dem „Defense in Depth“-Prinzip entworfen werden soll. Wenn Backup-Daten kompromittiert werden können, gibt es keinen Pfad zur Wiederherstellung.

Gesicherte Cluster-Kommunikation

Jeder Cluster hat eine bestimmte Anzahl von Knoten, die miteinander kommunizieren müssen. Das bedeutet, dass jeder Knoten, der Daten austauschen möchte, validiert werden muss. Bei vielen Lösungen gibt es wenig bis gar nichts, um die Kommunikation zwischen den Knoten zu schützen. Rubrik verwendet für die gesamte Kommunikation innerhalb der Knoten und zwischen den Clustern sowie für die Kommunikation mit externen Anwendungen das TLS-Protokoll mit zertifikatsbasierter gegenseitiger Authentifizierung für eine sichere Kommunikation. Dabei werden keine unsicheren Protokolle wie NFS oder SMB eingesetzt, um Informationen innerhalb des Clusters weiterzuleiten. Die Kommunikation erfolgt stattdessen über sichere und vertrauenswürdige Kanäle. So läuft die gesamte interne Kommunikation über TLS 1.2 mit starken Verschlüsselungs-Suites und Perfect Forward Secrecy (PFS). 

Standards zur Systemhärtung

Es gibt zahlreiche andere Elemente, die in der Lage sind, die Integrität des Systems durch interne Härtungsstandards zu schützen. Hier sind einige, die bei der Bekämpfung von Ransomware helfen:

Wesentlich ist zudem ein API-first-Design als Teil der Architektur. An allen Endpunkten, die für den Betrieb der Lösung verwendet werden, ist eine Authentifizierung erforderlich. Diese kann über Zugangsdaten oder sichere Token erfolgen. Dazu gehören Umgebungen, die rollenbasierte Zugriffskontrolle (RBAC) oder Multi-Tenancy-Funktionen verwenden, um die verwalteten Rollen, Funktionen und Ressourcen logisch aufzuteilen. Die CLI (Command Line Interface), SDKs (Software Development Kits) und andere Tools nutzen die API und unterliegen denselben Sicherheitsanforderungen.

Authentifizierte APIs

API-Endpunkte, die das zugrundeliegende Verhalten des Systems steuern, erfordern eine zusätzliche Autorisierungsebene, die nur von einem zertifizierten technischen Support-Ingenieur bereitgestellt werden kann. Dadurch wird verhindert, dass ein böswilliger Akteur das Verhalten eines Clusters ändern kann.

Schlussfolgerung

Zahlreiche Experten sprechen sich öffentlich für eine „Defense in Depth“-Strategie aus. Diese umfasst die Schulung des Sicherheitsbewusstseins von Mitarbeitern, die schnelle Bereitstellung von Patches und einen soliden Backup-und-Recovery-Plan. Das ist sicherlich kein Fehler.

„Wichtig ist es auf jeden Fall – zumindest für die Verantwortlichen – die technologischen Hintergründe zu verstehen. Die Vorteile einer Kombination aus Daten-Unveränderbarkeit und einem Zero-Trust-Cluster-Design sollten ihnen bekannt sein“, fasst Roland Rosenau von Rubrik abschließend zusammen. „Unternehmen müssen in der Lage sein, Ransomware-Angriffen ohne Schaden zu überstehen, um minimale Ausfallzeiten ihrer kritischen Dienste zu gewährleisten. Eine Architektur, die unveränderbare Backups garantiert, gibt Unternehmen die Gewissheit, dass sie bei Bedarf jederzeit auf ihre Daten zugreifen können, um den regulären Geschäftsbetrieb fortzusetzen.“

www.rubrik.com