Cyberangriffe auf Unternehmen und deren Netzwerke fallen oft erst auf, lange nachdem die Angreifer eingedrungen sind. Angreifer agieren im Geheimen, was es schwierig macht, den Hergang eines Angriffs im Nachhinein zu rekonstruieren und auf dieser Basis effektive Schutzmaßnahmen für die Zukunft zu etablieren. Daher sind Erkenntnisse aus aufgedeckten Cyberangriffen über die Vorgehensweise der Angreifer ggf. hilfreich.
Anzeige
aDvens, ein Unternehmen für Cybersicherheit, hat anhand der Daten aus seinem Security Operations Center den typischen Ablauf eines Cyberangriffs analysiert (abgesehen von Angriffen, denen keine finanziellen Motive zugrunde liegen – zum Beispiel Sabotage) und drei unterschiedliche Schritte identifiziert:
- Erstzugriff: In diesem Schritt verschaffen sich Angreifer auf diskrete Art und Weise Zugang zum Unternehmensnetzwerk. Laut aDvens geschieht dies in 80 Prozent aller Fälle über legitime, zugangsberechtigte Nutzerkonten und in 80 Prozent davon wiederum über externe Zugänge von Drittanbietern oder Dienstleistern. Auch Social- Engineering-Angriffe wie Phishing sind bei Cyberkriminellen beliebt, wie auch die Nutzung von öffentlich zugänglichen Schwachstellen. Obwohl es zu diesem Zeitpunkt noch keine oder kaum direkte Auswirkungen auf das Unternehmen gibt, ist bereits dieses Stadium des Angriffs gefährlich. Denn viele Angreifer verkaufen die erbeuteten Anmeldedaten zusätzlich im Darknet, was weitere Angriffe zur Folge haben kann.
- Auskundschaften: Im nächsten Schritt identifizieren Angreifer potenziell für ihre Ziele relevante Daten (z. B. HR-Daten oder Verträge). Dafür bewegen sie sich innerhalb des Systems mithilfe kompromittierter, aber legitimer Nutzerkonten und Verwaltungs-Tools, die keinen Verdacht erregen. Obwohl das Auskundschaften manchmal die Verbindung mit Systemkomponenten wie dem ERP oder mit Authentifizierungs-Tools stören kann, gibt es auch zu diesem Zeitpunkt noch keine oder kaum Auswirkungen auf das Unternehmen.
- Ausnutzung: Im letzten Schritt sind die Auswirkungen auf das Unternehmen am größten, denn jetzt kommt üblicherweise die Ransomware zum Einsatz. Sobald die Angreifer die für sie relevanten Daten identifiziert haben, werden diese gestohlen und/oder verschlüsselt, um ein Lösegeld für die Entschlüsselung oder den Nichtverkauf der Daten zu fordern. Um die Zahlung des Lösegelds wahrscheinlicher zu machen, werden Tools verwendet, die es den Angreifern ermöglichen, die Kontrolle über die Systemverwaltung zu erlangen und evtl. vorhandene Daten-Backups zu löschen – so soll der Druck auf das Unternehmen erhöht werden, indem Alternativen zur Lösegeldzahlung wegfallen.
Weitere Bedrohungstrends und -entwicklungen sowie die Maßnahmen, die das Experten-Team von aDvens als besonders relevant für die aktuelle und zukünftige Bedrohungslage ansieht, finden Sie hier im vollständigen, englischsprachigen Threat Status Report von aDvens zum Download.
Anzeige
Daten-Backups löschen funktioniert nur bei einen Online Backupsystem.
Best Practice bei Backups ist aber ein Offline Backupsystem, d.h. die Backupmedien werden nur für die Zeit des Backups/Restores mit dem System verbunden.
Und natürlich sollte man mehrere Generationen eines Backups vorhalten für den Fall, das mal ein Backupmedium nicht lesbar ist.
In Frage kommen da USB-Medien oder auch LTO-Bänder.
In großen Rechenzentren nutzt man dafür LTO-Loader, die mit hunderten Bändern bestückt sind und vielen parallel laufenden Laufwerken.
Bei einem Offline-Backup ist das Löschen des Backups weitgehend ausgeschlossen.
Tja so machen das Experten… leider gibt es da nicht mehr allzuviele in den Firmen, da agieren eher "Hobbyadmins".
Frägst du heutzutage in die Runde nach Backupstrategien kriegst du nur große Augen. Ich nutze sogar Privat schon seit Jahrzehnten LTO-Bänder zum Backup (auf nem Laufwerk von Quantum, derzeit LTO 8), sicherer geht es fast kaum. Die Bänder liegen dabei in nem F120 Safe und nen zweiter Satz im Schließfach bei meiner Bank. Privat ist da ja auch kein tägliches Backup notwendig ;-P
Naja, mit einem Offline-Backup adressiere ich zwar die Thematik, dass das Medium getrennt wird und nicht nachträglich verschlüsselt werden kann (z.B.) ich habe aber u.U. ein großes Thema mit der RTO. Das mag privat a) nicht die große Rolle spielen und privat habe ich b) vermutlich nicht die Volumina wie in Unternehmen.
Offline-Medien haben aus dem Blickwinkel von BCM aber nach meiner Auffassung zwei Probleme:
1. Es dauert für die Aufrechterhaltung der Geschäftsprozesse zu lange, bis ich die Wiederherstellung abgeschlossen habe
2. Ich kann nicht im Backup anhand von IOCs z.B. nach Hashwerten suchen
Der Punkt 2 ist m.E. eine von mehreren Ursachen für meinen Punkt 1. Ich stelle aus dem Backup wieder her und muss feststellen, dass auch dieses Backup schon kompromittiert ist (weil der Angreifer schon im Netz war, bevor ich ihn erkannt habe). Also geht die Bänderschubserei weiter und ich nehme das nächste Backup. Ebenso ist das Problem, dass ich gar nicht erkennen kann, wie viele meiner 900 VMware-Maschinen überhaupt kompromittiert sind. Es dauert also vielleicht Wochen, bis ich alle mühsam wiederhergestellt habe, um an Ende zu realisieren, dass von 900 Maschinen nur 45 infiziert waren.
D.h. ob LTO-Bänder oder nicht brauche ich zusätzlich (!) eine Lösung im Bereich Disaster Recovery und ich brauche dafür auch Rechenpower in einer gut isoliertem Testumgebung, um einzelne VMs dort hochzufahren zu können und zu prüfen.
Diese Lösung muss eine ganze Reihe Security-Features enthalten, die z.B. bermerken, wenn massenweise Daten verändert wurden (was auf eine Verschlüsselung hindeuten). Wenn ich rein auf Offline-Backup setze, habe ich zwar die höhere Sicherheit, was meine Daten angeht, aber mir läuft die Zeit einfach weg.
Ich habe schon einmal eine Debatte geführt, dass dieses Disaster Recovery-Lösungen keinen Mehrwert bieten und man über Transaktionslogs ja jede Datenbank (wenn korrekt konfiguriert und gesichert) zu jedem Zeitpunkt wiederherstellen kann. Das ist in der Theorie richtig, wenn ich in der IT 12 Leute habe, die vielleicht 65 Datenbanken in unterschiedlichen Anwendungen von 35 Herstellern betreuen, dann wird das in der Praxis nicht in einer vertretbaren Zeit möglich sein und das Thema muss ich lösen.
Veto… es gibt im BCM nichts schnelleres als Offlinemedien (ich nutze USB-Festplatten) zur Wiederherstellung. Einfach an einem Standby-System oder frisch installiertem Rechner anklemmen und los geht's. Schlägt jedes Bandlaufwerk oder LWL bei der Transfergeschindigkeit. Rotation hilft gegen kaputte Platten und ermöglicht einem in die Vergangenheit zurück zu gehen.
Backup und Restore in ein "digitalen Zwilling" erfolgt komplett automatisiert Das Skript dazu habe ich unlängst auf Nachfrage hier gepostet:
https://blog.jakobs.systems/micro/20241016-hyperv-backups-faq/
Das ist zugleich auch Lösung zum "Schrödinger-Backup-Problem" und neue Updates oder Changes können immer zuerst sicher in einer Testumgebung ausprobiert werden, wo ich das komplette AD als Kopie vorhalte.
Bänder haben Ihre unschlagbaren Vorteile bei Langlebigkeit – sofern die Lesegeräte und Schnittstellen auch aufbewahrt werden. Versuche mal heute einen Rechner mit SCSI zu finden, der Bänder aus den 1990ern einlesen könnte.
Bei Datenbanken helfen nur feste RPOs, sprich Zeitpunkte wo man sicher zurückkehren kann. Irgendwo ein Diff gibt es immer, diese sind aber eher verkraftbar als gar nicht mehr zu haben.
USB ist halt sehr langsam, und hat enorm viele Fehler Quellen. Alles schon durch. Von falsch/unvollständig angesteckt, fallen gelassen und niemand hat es bemerkt, kaputte Stecker, kaputte Kabel.. und dann ist USB halt langsam. Klassische HDDs schaffen da keine sinnvollen Datenraten, SSDs mit mehreren TB gibt es nicht zu kaufen. Viele Server haben gar keine extra schnellen USB Ports.
Wer prüft vor dem Einstecken dass das USB Gerät nicht den Server schädigt? Z.b. durch Kurzschluss?
Usw. Usw.
In meiner Welt ist nur die letzte Sicherung relevant welche OK ist.
Falls man Daten archivieren muss, ist das ein anderes Thema.
Viele Kunden sichern inzwischen alle 2 Minuten. Das ist selbst bei sehr kleinen Severn (kleiner 2000eur) ohne großen Aufwand machbar.
Fast Recovery also z.b. boot der VM direkt aus der Sicherung ist auch eher Standard.
Und natürlich muss man nicht nur OnPrem sichern.. Google/O365 braucht auch Sicherung.
"In meiner Welt ist nur die letzte Sicherung relevant welche OK ist." >> Was ist wenn man erst beim Restore merkt dass diese nicht OK ist?
Dann sollte man schon noch ein paar Datensicherungen davor haben. Sonst ist das wie wenn man ohne Sicherung auf den Berg klettert und 1000m runter fällt.
Zu USB:
Beim Kauf des Server bzw. des Server mit der Backup-Software drauf, ein (oder mehrere) USB3.x oder USB-C Interface Karten mit 2-4 Port einplanen. Später nachrüsten scheitert manchmal daran, dass die passenden PCIe-Slot werksseitg schon mit NIC-Karte(n) oder FC-Interfaces belegt sind. Oder dann überdimensionierte Server kaufen wo auch nach 10-15 Jahren Betriebszeit immer noch 6 PCIe-Slot frei sind.
Zu sichern in die Cloud:
Beim Restore drängt die Zeit – wenn da nicht eine 1 GBit/s Glasfaser-Verbindung zur Verfügung steht kann das je nach Datenmenge von Stunden bis Tage dauern.
Noch ein Aspekt wird gerne beim Backup vergessen:
Steuerrelevante Daten (Finanzbuchhaltung, Lohnbuchhaltung, etc.) müssen so gesichert werden das die nicht mehr nachträglich verändert oder gar gelöscht werden können.
Und diese Backups müssen für die Dauer der gesetzlich vorgeschriebenen Aufbewahrungsfrist aufbewahrt werden.
Und sie müssen auch jederzeit lesbar sein. Um das zu gewährleisten, muß man i.d.R. auch die zur Sicherung verwendete Soft- und Hardware entsprechend lange aufbewahren.
Als Backupmedium für steuerrelevante Daten kommen daher nur WORM-Medien in Frage.
Also z.B. CD-R, DVD-R, BD-R oder bei den heutigen Datenmengen eher LTO WORM-Bänder.
USB-Festplatten sind keine WORM-Medien und daher für die Sicherung steuerrelevanter Daten nicht zulässig.
Sorry das mit der "Unabänderbarkeit" ist eine längst widerlegte Mär aus der GoBD. Denn müssten die Tabellen diverser ERP und Warenwirtschaftssysteme an jedem Datensatz Prüfsummen hinterlegen und Logs müssten mit Hashes der jeweiligen Vorzeile arbeiten und darauf Ihre neue, eigene Hash bilden. Kein DMS System der Welt macht das, Belege werden meist Raw als Datei irgendwo im Filesystem abgelegt, maximal mit einem Hash versehen, der im Klartext in der Datenbank steht und ebenfalls manipuliert werden könnte. Am Ende des Tages kann man auch immer ein Original und eine manipulierte Kopie brennen. Das ganze auch nachträglich.
Ich empfehle den Podcast "Rechtsbelehrung" Folge 129 zur digitalen Forensik.
Wer archivierungspflichtige Dokumente in einem zertifizierten Dokumentmanagmentsystem (DMS) speichert wird wohl kaum den Backup dieses Systems auch nochmals auf einem WORM-Medium speichern müssen. Nach dem Restore sollte das System ja weiterhin "beweisen" können, dass die Belege nicht verändert wurden.
Was IMHO die Referenz ("Docuware") schlicht ergreifend nicht kann, weil Datenbank und Dokumente direkt frei bearbeitbar sind.
"Bei einem Offline-Backup ist das Löschen des Backups weitgehend ausgeschlossen."
Direkt hast du recht – indirekt nicht. Solche Angriffe versuchen natürlich auch, auf die "offline" Backups zuzugreifen und sie – zumindest – zu stören.
Und das funktioniert komischerweise auch ganz gut! Offenbar sind viele Backups nicht so richtig abgesichert …
Und wie soll das bei Bändern funktionieren?
Auf ein Band, das nicht im Laufwerk ist, kann nicht zugegriffen werden.
Und was den Restore angeht:
Bevor hier ein Band zum Restore ins Laufwerk wandert, wird erst einmal der Schreibschutzschieber benutzt, damit keine Schadsoftware den Inhalt des Bandes überschreiben kann.
Bei uns wird der Schreibschutzschieber benutzt sobald das LTO-Tape aus dem Wechsler entnommen wird. Wenn die Tapes aus der Tagessicherungs-Rotation nach einigen Wochen wieder in den Wechsler kommen, sollte man den Schreibschutz dann nicht vergessen wieder auszuschalten. Gab deswegen schon Nachtspaziergänge in den Serverraum. In meinem Fall nur 10 Min. Wegstrecke und Gesund nach einem Tag hinter dem Bildschirm …
@Luzifer,
Der Grund für "HobbyAdmins" ist ganz einfach. Billiger. Wird ja schon klappen.
Oder so wie ich es kennen gelernt habe, Vitamin B. Ich kenne eine Firma die einen Admin haben, ist der Schwiegersohn, der wirklich null Ahnung hat. Der kann nicht mal einen Port freischalten weil er nicht weiß was das ist.
TL;DR aus der Realität:
Es gibt keinen typischen Ablauf eines Cyberangriffs
1984 – HP3000 – Jeden Mittag hatte der jüngste Auszubildende die Aufgabe alle 15 Min. die Bandspule zu wechseln, bis die Datensicherung abgeschlossen war. Danach kamen die Spulen in den feuerfesten Datentresor.
Einmal pro Woche, anfangs der 90er-Jahre waren es 8 grosse Spulen, die Spulen dann zum Banktresor tragen. Ein Ortsbus gab es damals auch noch nicht und Auto fahren war, wegen zu jung, noch nicht erlaubt.
Wir machen das heute noch so, nach DAT und DLT, heute mit LTO.
Auch wenn wir inzwischen ältere Herren mit mehr oder weniger Haaren, meist grau oder bald ganz weiss sind, diese Praxis ist kein Zeichen das man langsam das berufliche EOL erreicht. Ganz im Gegenteil – wer kein vergleichbares Konzept mit Offline-Medien hat, erreicht sein IT-berufliches EOL eventuell schon viel früher…
Was 2024 gegenüber 1984 ein grosser Vorteil ist – die Konzepte von Online-und Offline-Backup lassen sich sehr gut kombinieren. Backup to Disk to Tape – oder parallel oder was auch immer. Im Alltag ist Rücksicherung ab Disk sehr schnell, im Worst Case, wenn alles verschlüsselt und/oder zerstört wurde (Wasser, Feuer, Elemtarschäden), gibt es dann jedoch immer noch die Offline-Tapes an einem sicheren, externen Ort.