Von Veröffentlicht am

Ransomware: Wenn Daten zum Druckmittel werden

Einleitung

Ransomware wurde in vielen Unternehmen lange vor allem als Verfügbarkeitsrisiko wahrgenommen: Systeme werden verschlüsselt, der Betrieb steht, und irgendwo fordert jemand Lösegeld. Inzwischen hat sich das Geschäftsmodell der Angreifer jedoch grundlegend weiterentwickelt. Immer häufiger geht es nicht mehr nur darum, Daten unzugänglich zu machen, sondern sie gezielt zu exfiltrieren und mit ihrer Veröffentlichung zu drohen – auch bei besonders sensiblen personenbezogenen Daten von Kundinnen und Kunden, Patienten oder Mitarbeitenden.

In solchen Situationen taucht in Diskussionen schnell die gleiche Frage auf: „Sollten wir nicht zahlen, um unsere Betroffenen zu schützen?“ Meine klare Antwort ist: NEIN.
In diesem Artikel zeige ich, wie Erpressung mit Datenveröffentlichung technisch und organisatorisch abläuft, warum Lösegeldzahlungen weder Datenschutz noch Sicherheit garantieren und welche Maßnahmen tatsächlich helfen, Angriffe zu erschweren, früher zu erkennen und im Ernstfall verantwortungsvoll zu reagieren.

Um sinnvoll über „zahlen oder nicht zahlen“ sprechen zu können, muss man zunächst verstehen, womit wir es genau zu tun haben. Deshalb starte ich mit der Frage: Was ist eigentlich Erpressung mit Datenveröffentlichung – und warum trifft sie längst nicht mehr nur „die anderen“?

Worum es in diesem Artikel konkret geht:

  • wie sich klassische Ransomware-Angriffe hin zu datengetriebenen Erpressungsmodellen entwickelt haben
  • welche technischen und organisatorischen Maßnahmen helfen, Exfiltration zu erschweren und früher zu erkennen
  • warum Lösegeldzahlungen aus Datenschutz‑, Sicherheits‑ und Governance-Perspektive keine verlässliche Lösung sind
  • was Organisationen tun können, um im Ernstfall strukturiert, transparent und verantwortungsvoll zu reagieren

Was ist eigentlich Ransomware?

Ransomware ist eine Form von Schadsoftware, die darauf ausgelegt ist, Unternehmen oder Einzelpersonen zu erpressen. Klassische Varianten verschlüsseln Daten oder ganze Systeme und fordern ein Lösegeld, damit die Betroffenen wieder Zugriff erhalten. Moderne Ransomware-Gruppen gehen inzwischen weiter: Sie kombinieren Verschlüsselung mit Datendiebstahl und drohen zusätzlich damit, die erbeuteten Informationen zu veröffentlichen oder weiterzuverkaufen. Aus technischer Sicht handelt es sich dabei meist um gezielte Angriffe mit mehreren Phasen – vom initialen Zugriff über die Ausbreitung im Netzwerk bis hin zur Exfiltration großer Datenmengen und der anschließenden Erpressung.

Problemrahmen und Relevanz

Bei Erpressung mit Datenveröffentlichung geht es im Kern um einen Vertrauensbruch auf mehreren Ebenen. Zum einen gegenüber den betroffenen Personen, deren Daten nur für klar definierte Zwecke verarbeitet und angemessen geschützt werden sollten. Zum anderen gegenüber allen, die mit der Organisation zusammenarbeiten – Kundinnen und Kunden, Geschäftspartnern, Mitarbeitenden und der Öffentlichkeit.

Diese Form der Erpressung ist deshalb weit mehr als „nur ein IT-Problem“. Sie betrifft Informationssicherheit, Datenschutz, Compliance, Reputation – und letztlich die Frage, wie ernst eine Organisation ihren Auftrag zum Schutz anvertrauter Daten nimmt. Hinter der Formel „Wir hatten einen Cyberangriff“ steht immer auch die Bewertung: Wie gut waren wir vorbereitet – und wie gehen wir mit den Folgen um?

Häufig unterschätzt wird, dass Erpressung mit Datenveröffentlichung nicht nur große, prominente Ziele trifft. Gerade kleinere und mittlere Unternehmen, Praxen, Kanzleien oder kommunale Einrichtungen geraten ins Visier: Die Datenbestände sind hochsensibel, die Ressourcen für professionelle IT-Sicherheit aber begrenzt. Für Angreifer ist das eine attraktive Kombination – ausreichend verwertbare Daten bei vergleichsweise geringem Widerstand.

Einmal abgeflossene Daten lassen sich beliebig kopieren, anreichern und in vielen Kontexten wiederverwenden – im Untergrundhandel, für Social Engineering, für erneute Erpressungen oder die direkte Ansprache der Betroffenen. Genau das macht das Modell so profitabel und erklärt, warum sich entsprechende Vorfälle inzwischen regelmäßig in Berichten von Sicherheitsbehörden und Incident-Response-Teams wiederfinden.

Funktionsweise der Angriffe

In der Praxis verlaufen diese Angriffe selten als „ein großer Hack“, sondern als Abfolge mehrerer Phasen:

  • Initialzugriff: Ausnutzung unsicherer Remote-Zugänge, ungepatchter Dienste oder kompromittierter Zugangsdaten (z. B. durch Phishing oder schwach geschützte Partnerzugänge). In dieser Phase geht es vor allem darum, einen ersten stabilen Zugangspunkt zu schaffen, über den sich die Angreifer später weiter vorarbeiten können – möglichst ohne sofort aufzufallen.
  • Seitwärtsbewegung & Erkundung: Schrittweise Rechteausweitung, Ausbreitung im Netzwerk und Identifikation interessanter Systeme und Datenquellen. Angreifer versuchen, von normalen Benutzerkonten zu privilegierten Konten zu wechseln, in Server- oder Admin-Netze zu gelangen und dabei ein genaues Bild der Umgebung zu gewinnen: Wo liegen Dateiserver, Datenbanken, E-Mail-Systeme, Backups oder Cloud-Speicher mit besonders sensiblen Informationen?
  • Exfiltration: Kopieren größerer Datenmengen und Abfluss über scheinbar legitime Kanäle (z. B. verschlüsselter Web-Traffic, VPN, Admin-Tools), möglichst gut im Normalverkehr getarnt. Häufig werden dazu Bordmittel des Betriebssystems oder gängige Administrationswerkzeuge genutzt, damit die Aktivitäten wie normale Administration oder Datensynchronisation aussehen. Ziel ist, möglichst viel verwertbares Material aus der Umgebung herauszubekommen, ohne von Monitoring oder Anomalieerkennung gestoppt zu werden.
  • Erpressung: Kontaktaufnahme mit der Organisation, Präsentation von „Beweismustern“, Fristen, Lösegeldforderung und zusätzliche Drohkulisse (Veröffentlichung, weitere Angriffe). Typischerweise legen die Täter Screenshots, Dateilisten oder Datenausschnitte vor, um ihre Drohung zu untermauern, und drohen mit Veröffentlichung im Darknet, Weitergabe an Medien oder direkter Ansprache der Betroffenen. Oft wird dieser Druck noch verstärkt, indem gleichzeitig Systeme verschlüsselt oder zusätzliche Angriffe (z. B. DDoS) gestartet werden – die bekannten Double- oder Multi-Extortion-Szenarien.

Für die Verteidigung ist es entscheidend, diese Kette zu verstehen, um gezielt ansetzen zu können – auch ohne jedes technische Detail zu kennen. Typischerweise verschaffen sich Angreifer zunächst einen Einstieg, arbeiten sich zu höher privilegierten Konten vor, lokalisieren sensible Datenquellen und exfiltrieren diese über unauffällige Kanäle, bevor die eigentliche Erpressung sichtbar wird. Entscheidend ist: Der Schaden entsteht bereits mit dem unbemerkten Abfluss sensibler Daten, nicht erst mit der Erpressungs-Mail – deshalb darf sich die Diskussion nicht auf „zahlen oder nicht zahlen“ verengen, sondern muss alle Phasen des Angriffs in den Blick nehmen.

Präventive Maßnahmen: Angriffe erschweren, Daten schützen

Verantwortungsvolle Vorbereitung beginnt damit, es Angreifern so schwer wie möglich zu machen, überhaupt an sensible Daten heranzukommen – und sie anschließend aus der Umgebung herauszubekommen. Das klingt banal, ist in der Praxis aber oft genau der Punkt, an dem Organisationen hängen bleiben: Man weiß ungefähr, dass man „etwas tun müsste“, aber nicht, wo man konkret anfangen soll.

Hilfreich ist es, hier in ein paar klaren Bausteinen zu denken:

Angriffsfläche reduzieren:

  • Exponierte Systeme (VPN, E-Mail-Gateways, Webanwendungen, Appliances) konsequent härten und zeitnah patchen.
  • Regelmäßige, risikobasierte Schwachstellenscans und – wo es sinnvoll ist – Penetrationstests durchführen, um nicht nur „auf dem Papier“ sicher zu sein.
  • Alte, nicht mehr benötigte Dienste, Schnittstellen und Accounts konsequent abschalten, statt sie „für alle Fälle“ liegen zu lassen.
  • Standardkonfigurationen und Default-Credentials systematisch beseitigen, insbesondere bei Appliances und OT-/IoT-Systemen.

Netzwerk sinnvoll segmentieren:

  • Trennung von User-, Server- und Admin-Netzen, statt ein großes, flaches Netz, in dem man sich frei bewegen kann.
  • Besonders sensible Systeme (z. B. mit Gesundheits-, Finanz- oder Personaldaten) in eigene, stärker geschützte Segmente legen.
  • Zugriffe zwischen Segmenten nur so weit wie nötig erlauben, technisch erzwingen (Firewall/ACLs, Mikrosegmentierung) – alles andere bleibt standardmäßig zu.
  • Remote-Zugriffe und Partneranbindungen über klar definierte, überwachte Übergabepunkte führen.

Identitäten und Berechtigungen im Griff haben:

  • „Least Privilege“ ernst nehmen: Nur die Rechte vergeben, die jemand wirklich für seine Aufgabe braucht, und zeitlich begrenzen, wo möglich (Just-in-Time-Privilegien).
  • Multi-Faktor-Authentisierung (MFA) überall dort verpflichtend machen, wo ein Konto besonders wertvoll ist: Remote-Zugänge, Admin-Konten, zentrale Cloud-Dienste, privilegierte SaaS-Anwendungen.
  • Getrennte Admin-Konten nutzen, keine Dauer-Admins auf normalen Arbeitsrechnern, regelmäßige Reviews von Gruppenmitgliedschaften und privilegierten Rollen.
  • Passwort- und Secret-Management professionell umsetzen (z. B. Passwortmanager, Rotation, Schutz technischer Accounts und API-Keys).

Robuste Backup- und Restore-Strategien:

Auch wenn es hier primär um Erpressung mit Datenveröffentlichung geht, bleiben gute Backups ein zentraler Baustein der Vorbereitung. Sie lösen zwar nicht das Problem abgeflossener Daten, sorgen aber dafür, dass der Betrieb nach einem Angriff schneller und kontrollierter wieder anlaufen kann – ohne dass man sich über verschlüsselte Systeme zusätzlich erpressbar macht.

„Gutes Backup“ bedeutet in der Praxis konkret – unabhängig von der Unternehmensgröße:

  • Es existiert eine durchdachte Strategie (z. B. nach der 3‑2‑1‑Regel: mehrere Kopien, unterschiedliche Medien, mindestens ein Offsite‑Backup). In kleinen Unternehmen kann das eine Kombination aus lokalem Backup und einem getrennten Offsite‑Speicher sein; in größeren Umgebungen oft dedizierte Backup‑Appliances und getrennte Rechenzentrums‑ oder Cloud‑Standorte.
  • Wo möglich, kommen unveränderbare Sicherungen (Immutable‑ oder WORM‑Backups) zum Einsatz, die nach dem Schreiben für einen definierten Zeitraum nicht mehr gelöscht oder überschrieben werden können. Damit wird es für Angreifer deutlich schwerer, im Rahmen eines Angriffs auch noch die Sicherungen zu kompromittieren.
  • Backups werden regelmäßig getestet – nicht nur, ob sie „durchlaufen“, sondern ob sich Systeme und Geschäftsprozesse im Notfall wirklich wiederherstellen lassen. Bei sehr kleinen Umgebungen kann das ein geplanter Restore‑Test pro Quartal sein, bei größeren Organisationen gehören strukturierte Restore‑Tests in die Notfallvorsorge.
  • Backup‑Infrastruktur und ‑Zugänge sind selbst gut geschützt und logisch vom Produktionsnetz getrennt, damit Angreifer nicht als Erstes auch noch die Sicherungen mit verschlüsseln oder löschen.

Datenabfluss erschweren (DLP & Egress-Kontrolle):

  • Sensible Daten identifizieren und klassifizieren: Wo liegen welche Datentypen, wie schützenswert sind sie, wer darf tatsächlich darauf zugreifen?
  • DLP-Funktionen auf Endpunkten, E-Mail-Gateways und Web-Proxys einsetzen, um auffällige Transfers zu markieren, zu protokollieren oder zu blocken.
  • Ausgehenden Traffic (Egress) nicht pauschal „alles erlauben“, sondern bewusst steuern und überwachen: Welche Protokolle, welche Ziele, welche Datenmengen sind normal, welche nicht?
  • Uploads zu Cloud-Diensten und File-Sharing-Plattformen regulieren und – wo notwendig – auf definierte, kontrollierte Kanäle begrenzen.

Datensparsamkeit und Datenhygiene:

  • Nicht alles für immer aufbewahren: Löschkonzepte tatsächlich leben und Altlasten abbauen, statt Datenbestände unbegrenzt wachsen zu lassen.
  • Besonders sensible Datensätze (z. B. bestimmte Gesundheits‑, Finanz‑ oder Identitätsdaten) zusätzlich absichern – etwa durch stärkere Verschlüsselung, Pseudonymisierung oder strengere Zugriffsbeschränkungen.
  • Test- und Entwicklungsumgebungen nicht mit produktiven personenbezogenen Daten füttern, nur weil es „praktischer“ ist, sondern mit synthetischen oder anonymisierten Daten arbeiten.
  • Datenhaltungen und Schatten-IT regelmäßig überprüfen, damit keine unkontrollierten Kopien sensibler Informationen entstehen.

Ein wichtiger Punkt ist: Prävention heißt nicht, dass danach nichts mehr passieren kann. Aber je konsequenter diese Basisthemen umgesetzt sind, desto kleiner wird die Angriffsfläche – und desto besser sind die Chancen, einen Angriff früh zu bemerken oder zumindest den Schaden zu begrenzen.

Detection & Incident Response: Früh merken, strukturiert handeln

So gut Prävention auch ist – einen hundertprozentigen Schutz gibt es nicht. Deshalb ist die zweite Säule genauso wichtig: Angriffe früh zu erkennen und im Ernstfall nicht im Chaos zu versinken. Genau das leisten saubere Detection-Mechanismen und ein geübtes Incident-Response-Vorgehen.

Ein zentraler Baustein ist Sichtbarkeit. Wer nicht weiß, was im eigenen Netz und in den angebundenen Cloud-Diensten passiert, kann eine Datenexfiltration auch nicht erkennen. Dazu gehört ein zentrales Log-Management oder ein SIEM, in dem relevante Ereignisse zusammenlaufen – etwa Firewall- und Proxy-Logs, Anmeldeereignisse, Aktivitäten auf File-Servern und Datenbanken sowie Security-Events aus Endpoint- und Cloud-Sicherheitslösungen. Entscheidend ist dabei weniger, „alles zu sammeln“, sondern die wirklich relevanten Signale so aufzubereiten, dass Anomalien sichtbar werden.

Konkret geht es um Use Cases, die gezielt auf Datenabfluss und verdächtige Bewegungen zielen. Dazu zählen zum Beispiel:

  • ungewöhnlich große Datenmengen, die in kurzer Zeit an externe Ziele übertragen werden.
  • Verbindungen zu bislang unbekannten oder untypischen Zielen, insbesondere in Hochrisiko-Regionen oder zu frischen Domains.
  • Massenzugriffe auf File-Shares oder Datenbanken, die nicht zum normalen Nutzungsmuster eines Kontos passen.
  • Zugriffe oder Datenbewegungen zu ungewöhnlichen Zeiten, etwa mitten in der Nacht aus Accounts, die sonst tagsüber genutzt werden.
  • wiederholte, fehlgeschlagene Zugriffsversuche auf sensible Speicherorte oder Backup-Systeme.

Ergänzend dazu brauchen Endpoints und Server einen Schutz, der über den klassischen Virenscanner hinausgeht. Moderne EDR‑ oder XDR‑Lösungen können verdächtige Aktivitäten erkennen, bei denen legitime Werkzeuge für schädliche Zwecke missbraucht werden – etwa wenn plötzlich mit Bordmitteln große Datenarchive erzeugt und per Kommandozeile in die Cloud geschoben werden. Genau solche „Living off the Land“-Taktiken sind bei heutigen Angreifern beliebt, weil sie im Grundrauschen normaler Administrationstätigkeiten untergehen sollen. In vielen realen Vorfällen sehen wir zum Beispiel Tools wie Rclone, verschleierte PowerShell-Skripte oder eingebaute Systemwerkzeuge, um große Datenmengen in Cloud-Speicher oder zu externen Servern zu übertragen. Solche Muster sollten in EDR‑ und SIEM-Use-Cases explizit abgebildet sein – inklusive Alarmen bei ungewöhnlichen Datenvolumina, neuen Zielen oder auffälligen Prozessketten.

All diese Technik nützt aber wenig, wenn unklar ist, was bei einem Alarm passieren soll. Ein klar definierter Incident-Response-Plan ist deshalb Pflicht – gerade in Organisationen mit sensiblen Daten. Darin sollte festgelegt sein, wer im Ernstfall welche Rolle übernimmt, wie eskaliert wird, welche internen und externen Ansprechpartner eingebunden werden (z. B. Datenschutz, Rechtsabteilung, Forensik, Management, Kommunikation) und wie Entscheidungen dokumentiert werden. Wichtig ist, dass dieser Plan nicht nur als PDF in einem Ordner liegt, sondern regelmäßig geübt wird – etwa in Form von Tabletop-Übungen mit realistischen Szenarien, in denen auch unbequeme Entscheidungen (z. B. Systemabschaltungen, Meldepflichten, externe Kommunikation) durchgespielt werden.

Steht der Verdacht auf Datenexfiltration im Raum, geht es im Kern um drei technische Schritte:

  • Eindämmung (Containment): Betroffene Systeme isolieren, auffällige Benutzerkonten sperren oder Passwörter zurücksetzen, vermutete Exfiltrations- und Steuerungskanäle blockieren. Ziel ist, weiteren Schaden zu begrenzen, ohne vorschnell alle Spuren zu zerstören.
  • Forensik und Scope-Bestimmung:  Relevante Logs und Artefakte sichern, um nachzuvollziehen, wie die Angreifer hineingekommen sind, wie lange sie im System waren und auf welche Daten sie mit hoher Wahrscheinlichkeit zugegriffen haben. Diese Erkenntnisse sind sowohl für technische Härtung als auch für die datenschutzrechtliche Bewertung und eventuelle Meldungen entscheidend.
  • Wiederherstellung und Härtung: Kompromittierte Systeme bereinigen oder sauber neu aufsetzen, die genutzten Schwachstellen schließen, Konfigurationen nachschärfen und die gewonnenen Erkenntnisse in Monitoring, Use Cases und Schulungen einfließen lassen.

Ein guter Indikator für Reife ist nicht, ob es „keine Vorfälle“ gibt, sondern wie professionell mit einem Vorfall umgegangen wird. Organisationen, die hier vorbereitet sind, geraten im Ernstfall weniger in Panik, treffen weniger Kurzschlussentscheidungen (einschließlich vorschneller Lösegeldzahlungen) und können deutlich besser erklären, was passiert ist und was sie daraus gelernt haben.

Governance, Recht & Transparenz: Verantwortung zeigen, nicht verstecken

Spätestens wenn klar ist, dass sensible Daten betroffen sind, reicht es nicht mehr, rein technisch zu denken. Dann stellen sich Fragen wie: Welche Pflichten haben wir gegenüber Betroffenen und Aufsichtsbehörden? Wer entscheidet was? Und wie offen kommunizieren wir das Ganze? Genau hier zeigt sich, ob eine Organisation Verantwortung übernimmt – oder versucht, ein Problem unter den Teppich zu kehren.

Ein zentraler Baustein ist eine saubere Rollen- und Aufgabenverteilung. Informationssicherheit, Datenschutz, Rechtsabteilung, Management und Kommunikation sollten im Vorfeld wissen, welche Rolle sie im Ernstfall haben. Dazu gehört, dass der oder die Datenschutzbeauftragte frühzeitig eingebunden wird, um das Risiko für die betroffenen Personen zu bewerten, und dass die Rechtsabteilung Melde- und Haftungsfragen im Blick hat. Genauso wichtig ist eine klare Führungsrolle, die Entscheidungen trifft und priorisiert, statt alles im Klein-Klein versanden zu lassen.

Rechtlich relevant wird es vor allem, wenn personenbezogene Daten im Spiel sind oder kritische Dienste betroffen sind. In der EU gibt die DSGVO hier den Rahmen vor: Organisationen müssen prüfen, ob ein (hohes) Risiko für die Rechte und Freiheiten der Betroffenen besteht und daraus Meldepflichten ableiten. Für viele Unternehmen kommt mit NIS2 zusätzlich eine Meldepflicht für erhebliche IT‑Sicherheitsvorfälle gegenüber der zuständigen Cyber-Sicherheitsbehörde hinzu – mit eigenen Fristen und Inhalten.

Praktisch bedeutet das:

  • innerhalb kurzer Zeit (Stunden, nicht Wochen) eine erste Einschätzung treffen, ob und welche personenbezogenen Daten und gegebenenfalls kritischen Dienste betroffen sind.
  • gegebenenfalls die zuständige Datenschutzaufsichtsbehörde binnen 72 Stunden informieren – auch wenn noch nicht alle Details geklärt sind, mit der Option, nachzumelden.
  • sofern NIS2-relevant: erhebliche Sicherheitsvorfälle zusätzlich der zuständigen NIS2-/BSI-Stelle melden, idealerweise im gleichen abgestimmten Prozess.
  • bei hohem Risiko für die Betroffenen diese direkt informieren, in verständlicher Form und ohne juristische Schutzformeln, die am Kern vorbeigehen.

Sobald eine Datenexfiltration bestätigt oder sehr wahrscheinlich ist, liegt in aller Regel eine meldepflichtige Datenschutzverletzung vor – auch wenn die Daten noch nicht im Darknet aufgetaucht sind. Die typischen „Beweismuster“ der Angreifer (Daten-Samples, Screenshots, Dateilisten) sind deshalb ein ernst zu nehmender Hinweis und kein Grund, abzuwarten, „ob wirklich etwas veröffentlicht wird“.

Parallel dazu stellt sich die Frage, wie offen man insgesamt mit dem Vorfall umgeht. Versuche, Vorfälle kleinzureden oder zu verschweigen, werden mittelfristig fast immer teurer – durch Vertrauensverlust, interne Konflikte oder eine spätere, unkontrollierte Veröffentlichung durch Angreifer oder Dritte. Transparenz bedeutet dabei nicht, jedes technische Detail nach außen zu tragen, sondern die wesentlichen Punkte klar zu benennen:

  • Was ist grundsätzlich passiert?
  • Welche Arten von Daten sind betroffen?
  • Welche Risiken ergeben sich daraus für die Betroffenen?
  • Welche Maßnahmen wurden ergriffen, um den Schaden zu begrenzen und Wiederholungen zu vermeiden?

Ein weiterer wichtiger Aspekt in diesem Kontext ist eine klare Haltung zu Lösegeldzahlungen. Wird diese Frage erst im akuten Stressfall diskutiert, ist die Gefahr groß, dass Emotionen, politischer Druck oder Angst vor Reputationsschäden zu Kurzschlussentscheidungen führen. Sinnvoller ist es, vorab eine Grundlinie festzulegen – etwa im Sinne von: „Wir zahlen grundsätzlich kein Lösegeld. Sollten in extremen Ausnahmefällen andere Erwägungen entstehen, werden diese dokumentiert, mit den relevanten Stellen abgestimmt und rechtlich geprüft.“ Zu verantwortungsvollem Handeln gehört auch, offen anzuerkennen, dass Zahlungen Kriminalität finanzieren und das Risiko für andere erhöhen – und deshalb allenfalls als äußerst seltene Ultima Ratio diskutierbar sind.

Wenn die Frage „zahlen oder nicht zahlen“ im Raum steht, sollten mindestens diese Dimensionen strukturiert betrachtet werden:

  • rechtliche Risiken (z. B. Sanktionsrecht, Regelungen zur Terrorismusfinanzierung, aufsichtsrechtliche Bewertung, Haftungsfragen).
  • technische Lage (Backups, Wiederanlaufszenarien, verbleibende Angriffswege, Grad der eigenen Kontrolle über die Umgebung).
  • Risiko für Betroffene (Art und Sensibilität der Daten, potenzielle Missbrauchsszenarien, bereits eingetretene oder absehbare Schäden, Informationsstand der Betroffenen).
  • systemische Folgen (Signalwirkung gegenüber Angreifern, Stabilisierung des Geschäftsmodells, mittelbare Risiken für andere Organisationen und Betroffene).

Auch wenn im Einzelfall argumentiert wird, dass eine Lösegeldzahlung die Wahrscheinlichkeit einer späteren Veröffentlichung oder eines Weiterverkaufs der Daten verringern könnte, bleibt dieser Effekt kaum verlässlich überprüfbar. Weder lässt sich sicher feststellen, ob Kopien tatsächlich gelöscht wurden, noch ob Daten nicht doch zu einem späteren Zeitpunkt erneut auftauchen oder anderweitig missbraucht werden. Dem steht ein sehr reales systemisches Risiko gegenüber: Jede Zahlung stabilisiert das Geschäftsmodell der Täter, finanziert weitere Angriffe und erhöht damit mittelbar auch die Gefahr für andere Organisationen und Betroffene. Hinzu kommt: Je nach Tätergruppe, Zahlungsweg und involvierten Ländern können Sanktionsrecht und Regelungen zur Terrorismusfinanzierung berührt sein – ein weiterer Grund, warum Zahlungen aus meiner Sicht keine verantwortbare Standardoption sind.

Am Ende geht es bei Governance, Recht und Transparenz um mehr als um Compliance-Häkchen. Es geht darum, ob eine Organisation glaubwürdig vermitteln kann: Wir wissen, was passiert ist, wir nehmen die Auswirkungen ernst, wir informieren ehrlich und wir leiten konkrete Verbesserungen ab. Wer das schafft, wird selbst nach einem schweren Vorfall eher als verantwortungsvoll wahrgenommen – auch wenn der Angriff selbst vielleicht nicht vollständig zu verhindern gewesen wäre.

Fazit

Entscheidend ist nicht das schnelle „Freikaufen“, sondern die Qualität von Vorbereitung, Reaktion und Transparenz. Lösegeldzahlungen bieten keine Garantie für Datenschutz oder Sicherheit, sie finanzieren Kriminalität und erhöhen das Risiko für weitere Angriffe auf andere Organisationen und Betroffene. Verantwortungsvolle Sicherheitsarbeit zeigt sich darin, Angriffe so gut wie möglich zu verhindern, Vorfälle früh zu erkennen, offen mit Betroffenen und Aufsichtsbehörden zu kommunizieren und aus jedem Vorfall konsequent zu lernen. Lösegeld kann man zahlen – Vertrauen, Integrität und Lernbereitschaft nicht.