syncova-backup/docs/ransomware.md

Ransomware-Heuristik (Phase 16)

Die Vorgabe des Implementierungsplans (§18) steht in vier Worten:

Do not make destructive decisions automatically. Alert first.

Dieses Paket löscht nichts, sperrt nichts und hält nichts an. Es beschreibt, was auffällig ist, und überlässt jede Entscheidung einem Menschen.

Der Grund ist nicht Vorsicht, sondern Erfahrung: Eine Heuristik, die selbsttätig handelt, macht aus jedem Fehlalarm einen Schaden — und Fehlalarme wird es geben, weil ein Betriebssystem-Update von außen genauso aussieht wie ein Verschlüsselungsangriff. Ein Werkzeug, das bei einem Softwarerollout die Sicherungskette anhält, wird abgeschaltet. Ein abgeschaltetes Werkzeug erkennt gar nichts.

Was gemessen wird

Sechs Signale, alle sechs aus dem Plan. Fünf davon fielen bei der Sicherung ohnehin an und mussten nur festgehalten werden; eines — der Entropie-Indikator — verlangte einen Eingriff in die Engine.

Signal	Herkunft	Untergrenze
Neu abgelegte Datenmenge	backups.unique_bytes	100 MiB
Geänderte Objekte	Zusatzsicherung: Changes.ChangedFileCount(); Vollsicherung: alle Dateien	20 Objekte
Verschwundene Objekte	Changes.DeletedPaths	20 Objekte
Anteil nicht verkleinerbarer Blöcke	Kompressionsmarker der Engine	10 Prozentpunkte
Neue Dateiendungen	extension_distribution (JSONB)	25 % der Objekte
Größe des Laufs	backups.logical_bytes	100 MiB

Der Entropie-Indikator kostet nichts, weil die Engine ihn ohnehin bildet. Ob ein Block sich komprimieren ließ, entscheidet ChunkTransformer.Transform bei jedem Block. Bislang verschwand diese Erkenntnis im Marker-Byte; jetzt gibt Transform sie zusätzlich zurück. Verschlüsselte Daten sind nicht komprimierbar — ein Sprung von „5 % der Blöcke unkomprimierbar" auf „100 %" ist das verlässlichste technische Anzeichen massenhafter Verschlüsselung, das eine Sicherungssoftware überhaupt sehen kann. Eine eigene Entropiemessung wäre derselbe Rechenaufwand ein zweites Mal.

Gezählt werden nur neue Blöcke. Ein deduplizierter Block wurde in einem früheren Lauf schon bewertet; ihn erneut mitzuzählen verwässerte den Anteil genau in dem Lauf, in dem er aussagekräftig wird.

Die Endungsverteilung ist auf 20 Einträge gedeckelt, der Rest fällt in einen Sammelposten (weitere). Ohne Deckel wüchse die JSONB-Spalte mit jeder Zufallsendung, die eine Schadsoftware erzeugt — ausgerechnet der Angriff bliese die Datenbank auf. Der Sammelposten ist vom Signal ausgenommen: Er ist per Konstruktion in jedem Lauf „neu".

Warum Median und mittlere absolute Abweichung

Der Basiswert entsteht aus den letzten Läufen derselben Kette, nicht aus einer festen Schwelle. Eine feste Schwelle kann es nicht geben: Ein Dateiserver mit 2 geänderten Dateien je Tag und ein Buildserver mit 40 000 sind beide normal.

Gerechnet wird mit Median und mittlerer absoluter Abweichung, nicht mit Mittelwert und Standardabweichung. Der Grund ist der Kern der ganzen Sache:

Ein einziger Ausreißer ist genau der Fall, den wir erkennen wollen. Würde er den Basiswert mitbestimmen, höbe er die Schwelle an, gegen die er gemessen wird.

Bei fünf normalen Läufen (~100) und einem Angriff (50 000) läge der Mittelwert über 8000 — der nächste Angriff derselben Größe fiele nicht mehr auf. Der Median bleibt bei 100. TestMedianResistsSingleOutlier hält das fest.

Weitere Festlegungen:

• Mindestens fünf Läufe. Mit dreien ist ein Median eine Formalität und die Streuung Zufall. Darunter lautet die Einstufung unknown — ausdrücklich getrennt von none. Wer nicht messen kann, hat nichts gemessen und darf nicht so tun, als sei alles in Ordnung.
• Höchstens zwanzig Läufe. Ein Basiswert aus einem Jahr beschriebe eine Anlage, die es so nicht mehr gibt.
• Nur nach oben geprüft. Weniger geänderte Dateien als sonst sind kein Angriffszeichen; eine zweiseitige Prüfung erzeugte an jedem ruhigen Wochenende einen Befund.
• Zwei Bedingungen zugleich — drei mittlere Abweichungen und 50 % mehr. Der Faktor allein schlüge bei sehr gleichmäßigen Werten schon bei Geringfügigkeiten an; die relative Änderung allein übersähe eine Quelle, die ohnehin stark schwankt.
• Streuung null (eine Quelle, die sich nie ändert) hat keinen Faktor. Dann zählt allein die relative Änderung.

Die absolute Untergrenze ist keine Feinheit

Sie kam durch einen Fehlalarm im Test hinzu. Eine Quelle mit zwei geänderten Dateien je Lauf, jetzt drei: eine Steigerung um fünfzig Prozent, Streuung null — formal ein Befund, tatsächlich vollkommen belanglos. Deshalb hat jedes Signal eine eigene Untergrenze. Zwanzig Dateien mehr sind ein Ereignis, zwanzig Bytes mehr sind Rauschen; eine gemeinsame Grenze für beides gibt es nicht.

Die Erklärung nennt die Untergrenze, statt sie zu verschweigen. Ein Satz wie „der Wert stieg von 336 auf 3 004 350, das liegt unter der Größenordnung" liest sich bei einem tausendfachen Anstieg wie ein Fehler des Werkzeugs — und wer dem Werkzeug einmal misstraut, liest auch den echten Befund nicht mehr.

Einstufung

Stufe	Bedingung	Schweregrad der Meldung
unknown	weniger als fünf Vergleichsläufe, oder keine Signale erhoben	keine Meldung
none	kein Signal auffällig	keine Meldung
elevated	ein Signal auffällig	warning
high	zwei oder mehr Signale auffällig	high

Zwei, nicht eins, für die höhere Stufe: Ein einzelnes auffälliges Signal hat viele harmlose Ursachen — ein großes Update, ein Umzug, ein neuer Datenbestand. Zwei zugleich sind das Muster, das massenhafte Verschlüsselung hinterlässt: viele geänderte Dateien und kaum noch komprimierbare Daten.

Backups aus der Zeit vor dieser Phase tragen die Kennzahlen nicht. Sie fließen nicht als Nullwerte in den Basiswert ein — das zöge ihn nach unten und ließe jeden neuen Lauf auffällig erscheinen. Sie werden übersprungen, und solange zu wenige verwertbare Läufe übrig sind, lautet die Einstufung unknown.

Anbindung

• Meldungswesen: Die Regel unusual_change_rate nutzt seit dieser Phase den Detektor statt einer festen Schwelle. Die Meldung nennt die auffälligen Signale mit Namen und Erklärung.
• API: GET /api/v1/backups/{id}/ransomware-assessment (backups.read) liefert alle sechs Signale einzeln. Ohne diesen Endpunkt bliebe die Meldung „4 von 6 Signalen sind auffällig" eine Behauptung: Ihre Empfehlung lautet „Prüfen Sie die Quelle" — wer aber nicht sehen kann, welche vier Signale gemeint sind, hat keinen Anfang.
• Die Bewertung wird bei jedem Aufruf neu berechnet, nicht gespeichert. Der Basiswert wandert mit den letzten Läufen; eine eingefrorene Bewertung beschriebe einen Vergleich, den es so nicht mehr gibt. Dieselbe Entscheidung wie bei der Recovery Assurance (Phase 10).

Die Empfehlung bei high lautet wörtlich:

Prüfen Sie die Quelle, bevor Sie ältere Wiederherstellungspunkte löschen oder eine Aufbewahrungsregel anwenden. Die Anlage unternimmt von sich aus nichts.

Das ist die einzige Handlung, die die Heuristik überhaupt nahelegt — und sie ist eine Unterlassung. Wer nach einem Verschlüsselungsangriff die Aufbewahrung laufen lässt, vernichtet die letzten sauberen Wiederherstellungspunkte.

Nachweis

Geführt gegen den laufenden Dienst, in beide Richtungen. Beide Richtungen sind nötig: Ein Detektor, der jeden Angriff erkennt, aber auch jeden großen Arbeitstag meldet, wird nach einer Woche ignoriert.

Gegentest — harmloser großer Lauf. 200 neue, gut komprimierbare Dokumente zu einer Quelle mit sonst drei geänderten Dateien:

  Einstufung:  elevated
  Auffällig:   1 von 6 Signalen
     ⚠ Geaenderte Objekte   Bisher lag der Wert stets bei 3.0, jetzt bei 200.0 (6567 Prozent mehr).

Richtig: Die Zahl der Dateien stieg sprunghaft — das ist auffällig und wird gesagt. Der Entropie-Indikator blieb bei 0 %, es verschwand nichts, es kam keine neue Endung hinzu. Genau ein Signal, also elevated und ein warning, kein Alarm.

Angriff — simulierte Verschlüsselung. 150 Dateien durch Zufallsdaten ersetzt, mit der Endung .locked abgelegt, die Originale gelöscht:

  Einstufung:  HIGH
  Auffällig:   4 von 6 Signalen
     ⚠ Geaenderte Objekte                   Bisher lag der Wert stets bei 3.0, jetzt bei 150.0 (4900 Prozent mehr).
     ⚠ Verschwundene Objekte                Bisher lag der Wert stets bei 0.0, jetzt bei 150.0 (15000 Prozent mehr).
     ⚠ Anteil nicht verkleinerbarer Bloecke Bisher lag der Wert stets bei 0.0, jetzt bei 100.0 (10000 Prozent mehr).
     ⚠ Neue Dateiendungen                   1 neue Dateiendungen ([.locked]) betreffen 58 Prozent der Objekte.

Der Anteil nicht verkleinerbarer Blöcke sprang von 0 % auf 100 % — das ist der Fingerabdruck, den nur Verschlüsselung hinterlässt. Beide Meldungen standen korrekt abgestuft im Meldungswesen (high und warning), und das Repository blieb unangetastet: Es wurde nichts gelöscht, nichts gesperrt, nichts angehalten.

Bekannte Grenzen

• Die beiden Byte-Signale tragen bei kleinen Quellen nichts bei. Ihre Untergrenze liegt bei 100 MiB; im Nachweis oben blieben sie deshalb stumm, obwohl die Datenmenge um das Achttausendfache stieg. Das ist gewollt — unter hundert Megabyte ist eine Verschlüsselungswelle weder wirtschaftlich noch bemerkbar —, bedeutet aber: Bei einer kleinen Quelle stützt sich die Erkennung auf vier Signale, nicht auf sechs.
• Ein langsamer Angriff entgeht der Erkennung. Wer über Wochen täglich ein Prozent des Bestands verschlüsselt, verschiebt den Basiswert mit sich. Gegen diesen Fall hilft keine Abweichungsstatistik, sondern die Unveränderlichkeit aus Phase 11.
• Die Zahl geänderter Objekte einer Vollsicherung ist die Zahl aller Dateien. Ein Wechsel von Zusatz- auf Vollsicherung erzeugt deshalb einen Ausschlag. Er ist harmlos und wird als elevated gemeldet — nicht als high, solange die übrigen Signale ruhig bleiben.
• Ein Kettenwechsel setzt den Basiswert zurück. Nach einem neuen Repository oder einer neuen Quelle lautet die Einstufung fünf Läufe lang unknown.
• Keine Erkennung im laufenden Betrieb. Bewertet wird ein abgeschlossener Sicherungslauf. Zwischen Angriff und Meldung liegt bestenfalls ein Sicherungsintervall. Diese Heuristik ist kein Ersatz für einen Endpunktschutz; sie ist die letzte Instanz, die den Schaden bemerkt, bevor die Aufbewahrung die sauberen Wiederherstellungspunkte entfernt.