[English]Kunden des dänischen Cloud-Anbieters CloudNordic haben erfolgreich gelernt, was es heißt, sich die Verantwortung zu teilen. Der Anbieter hatte beim Umzug in ein neues Rechenzentrum eine Ransomware-Infektion, so dass das Cloud-Angebot komplett für die Kundschaft ausgeknipst wurde. Der Anbieter musste die Kunden informieren, dass alle Server und Kundendaten gelöscht wurden. Zudem teilte CloudNordic mit, dass es die Lösegeldforderung der Cyberkriminelle nicht bezahlen will und kann. Wer kein Backup hat, für den ist nun "Schicht im Schacht", es muss alles manuell neu aufgesetzt werden.
Anzeige
Cloud-Hack löscht alles
Der Cloud-Anbieter CloudNordic hat auf seiner (nur schwer erreichbaren) Webseite eine entsprechende Meldung an seine Kunden veröffentlicht. Ich bin bei The Register auf die Information über diesen Cyber-Vorfall gestoßen. Hier die grobe Übersetzung:
Leider ist CloudNordic in der Nacht zum Freitag, den 18. August 2023 um 4 Uhr morgens einem Ransomware-Angriff zum Opfer gefallen, bei dem kriminelle Hacker alle Systeme abgeschaltet haben. Websites, E-Mail-Systeme, Kundensysteme, die Websites unserer Kunden, usw. Einfach alles. Ein Einbruch, der CloudNordic komplett lahmgelegt hat und auch unsere Kunden hart getroffen hat.
Da wir die finanziellen Forderungen der kriminellen Hacker nach Lösegeld nicht erfüllen können und wollen, haben das IT-Team von CloudNordic und externe Experten hart daran gearbeitet, sich einen Überblick über den Schaden zu verschaffen und darüber, was wiederhergestellt werden konnte.
Leider hat es sich als unmöglich erwiesen, weitere Daten wiederherzustellen, und die meisten unserer Kunden haben alle Daten bei uns verloren. Dies gilt für alle, die wir noch nicht kontaktiert haben.
Der Hackerangriff wurde zwar bei der Polizei angezeigt, aber der Totalschaden ist für die Kunden und den Cloud-Anbieter eingetreten. Das Unternehmen zeigt sich sehr besorgt über die Situation und weiß auch, dass der Angriff für viele unserer Kunden ebenfalls sehr kritisch ist. Denn es wurden nicht nicht nur Daten, sondern auch alle CloudNordic Systeme und Server verloren und konnten nicht mehr kommunizieren.
Die IT-Leute des Anbieters haben zwar jetzt die leeren Systeme wiederhergestellt, z. B. Namensserver (ohne Daten), Webserver (ohne Daten) und Mailserver (ohne Daten). Damit können Kunden die betreffenden Funktionen wieder neu aufsetzen, damit Webseiten und Mail-Server für Kunden wieder ohne Domain-Umzug zu einem anderen Anbieter funktionieren.
Wer kein Backup besitzt, für den wird das Ganze aber wohl schwierig – je nach Unternehmen dürfte das sogar existenzbedrohend werden. Das Unternehmen gibt noch Hinweise, wie Kunden ggf. einen Domain-Umzug organisieren oder Webinhalte, für die es kein Backup gibt, per Webarchiv restaurieren können.
Anzeige
Wie konnte das passieren?
Die Frage, die mich sofort umtrieb: Wie konnten die Angreifer in die Cloud-Infrastruktur eindringen? Hier sitzt der Teufel wohl im Detail, denn die Cybergang hat die Phase eines Umzugs der Server in ein anderes Rechenzentrum genutzt. Dazu schreibt CloudNordic:
Nach unserem Kenntnisstand waren beim Umzug von Servern von einem Rechenzentrum in ein anderes und trotz der Tatsache, dass die umzuziehenden Maschinen sowohl durch eine Firewall als auch durch ein Virenschutzprogramm geschützt waren, einige der Maschinen vor dem Umzug mit einer Infektion infiziert. Diese Infektionen wurden im vorherigen Rechenzentrum nicht aktiv genutzt, und wir hatten keine Kenntnis von der Infektion.
Während des Umzugs von Servern von einem Rechenzentrum in das andere wurden Server, die sich zuvor in separaten Netzwerken befanden, unglücklicherweise verkabelt, um auf unser internes Netzwerk zuzugreifen, das für die Verwaltung aller unserer Server verwendet wird.
Über das interne Netzwerk verschafften sich die Angreifer Zugang zu den zentralen Verwaltungssystemen und den Backup-Systemen. Über das Backup-System gelang es den Angreifern, sich Zugang zu verschaffen zu:
- Allen Speichern (Daten)
- Sicherungssystem für die Replikation
- Sekundäres Sicherungssystem
Den Angreifern gelang es, alle Server-Disks sowie das primäre und sekundäre Backup-System zu verschlüsseln, so dass alle Rechner abstürzten und wir den Zugriff auf alle Daten verloren.
Bei dem Angriff wurden alle Datenträger der virtuellen Maschinen verschlüsselt, damit war definitiv "finito". Die IT hat aber keine Anzeichen für einen Datenmissbrauch festgestellt. Es konnte nicht feststellen werden, dass die Angreifer Zugriff auf den Dateninhalt der virtuellen Maschinen selbst hatten. Die Zugriffe der Angreifer bezogen sich ausschließlich auf die Verwaltungssysteme, von denen aus sie die jeweils ganzen Disks verschlüsseln konnten. Es wurden sehr große Datenmengen verschlüsselt, wobei NordicCloud keine Anzeichen dafür gefunden hat, dass versucht worden wäre, große Datenmengen herauszukopieren.
Für die Kunden geht es mit einem "blauen Auge" ab, es ist dann wohl kein DSGVO-Verstoß zu melden. Aber wenn einem die komplette Server-Infrastruktur der Cloud abraucht, ist auch "fertig". Wohl dem, der die "geteilte Verantwortung" zwischen Kunde und Cloud-Anbieter verstanden hat und zumindest über eigene aktuelle Backups der Inhalte verfügt. Dieser könnte er schnell wieder einspielen und wäre dann wieder arbeitsfähig. Wenn diese Backups fehlen, sieht es düster aus.
Einen ähnlichen Fall berichtet heise im Beitrag InfluxData: Server aus, Kundendaten weg.
Anzeige
Ok,
ich bin dann mal der erste der schreibt „ich will was mit Blumen machen".
Ich denke man kann sich die üblichen Hinweise sparen und einfach eine Kerze für die Unternehmen anzünden die jetzt den Bach runter gehen werden.
Häme ist hier fehl am Platz. Dazu werden zu viele arme Schweine ihren Job verlieren die vermutlich noch nicht mal so richtig verstehen was da passiert ist.
Gruß
Häme ist nicht, aber gab es bei den Sozialisten nicht irgend einen Spruch "von … lernen, heißt siegen lernen" – vielleicht ist es ja Weckruf, sich der Risiken des Cloud-Angebots bewusst zu werden – man ist für sein eigenes Zeugs da draußen verantwortlich. Eines der Argumente für die Cloud war doch "da braucht man sich nicht zu kümern".
Autsch!
Ich glaube nicht, dass dies ein Cloud-spezifisches Risiko ist. Wenn es Hacker gelingt, die On-Prem-Storages der On-Prem-Vsphere/HyperV/… und Backup-Infrastruktur zu sprengen, ist die Kagge genauso am Dampfen. Solche Konfigurationsfehler passieren auch OnPrem. Es ist dann halt nur eine Firma betroffen, und nicht gleich mehrere. Das ist der einzige Unterschied. Hämisch muss man allerdings sein: Kein ausgelagertes Backup, kein Mitleid. Ich hoffe, dass wenigstens die Kunden ein Backup haben, und ich würde denen dringend raten, sich einen anderen Cloudprovider für die Migration zu suchen.
Wenn der Cloud-Anbieter nichtmal Backups der Systeme ausgelagert hat, dann war er bestimmt zu billig.
Ich möchte gerade nicht in der Haut des Teams stecken, dass die Netzwerkstruktur während der Migration so falsch konfiguriert hat. Und ich möchte auch nicht in der Haut der Kollegen stecken, deren Job es eigentlich gewesen wäre, den Einbruch und Infektion vor der anstehenden Migration zu finden… Ich weiß aber auch, das kann uns allen auch jederzeit auch passieren. Deswegen, Backup, Backup, Backup…
Ich möchte gerade nicht in der Haut des Teams stecken, das Backups der eigenen Firma bei CloudNordic in die Cloud gesichert haben.
Doch, das ist ein Cloud spezifisches Problem. Denn im Grunde heißt es, du musst für alles was du in der Cloud hast für die Sicherung sorgen, und dann brauchst du eben ein Backup mit allem Drum und Dran. Storage, Software, Server. Und wenn du HA haben willst, brauchst du nicht nur den Server fürs Backup der Daten, sondern auch Server, die die Cloud sofort ersetzen können. Also… entweder eine zweite Cloud (hallo Kosten), die auch eine echte Trennung zwischen Backup und Production bringt (und das Risiko eines Datenlecks multipliziert) oder ein eigenes RZ (wofür war die Cloud noch gleich?).
Daß man seien Daten (auch wenn die primäre Instanz in der Cloud liegt) selbst sichern muß ist eigentlich selbstverständlich und steht sowohl in deren AGBs als auch in den IT-Grundschutzleitfäden.
Wir setzen z.B. für M365 das "Veeam Backup for Microsoft Office 365" (die Namensgebung hält nicht ganz Schritt mit MS) ein, "hinten heraus" genau so wie oben etliche Male beschrieben mit LTO-Bändern, die in entsprechenden Datentresoren an einem 5km entfernten Firmenstandort (mein täglicher Arbeitsweg) eingelagert werden.
Die zusätzliche B2D-Instanz dient eher der Bequemlichkeit, um Anfragen wie "stell mir mal schnell die Datei xxx von gestern wieder her" in Minuten abarbeiten zu können.
@Fritz:
Was würde Euch das Backup nutzen, wenn die MS365-Cloud für längere Zeit nicht verfügbar wäre?
Dann hättet ihr zwar die Exchange-, Onedrive-, Sharepoint-Daten vorliegen, aber keinerlei Ressourcen (Server, Speicher etc.), um diese Daten als Notfall-Konzept wieder nutzbar zu machen. Wie löst ihr das Dilemma?
Ganz ehrlich: es juckt dann fast niemanden, die GF redet sich raus, egal was die entschieden haben und die Schuld wird auf einen MA ausgelagert.
Das man denen mehrfach mitgeteilt hat, dass dieses Risiko besteht und es auch eintreten kann, will am Ende eh keiner hören und die Schuld wird wo anders gesucht. Das Risiko wird wissentlich hingenommen und wenn es eintritt wird jemand anderes dafür verantwortlich gemacht und am Ende ändert sich wenig bis nichts.
Sehe ich in ähnlicher Weise täglich: die Performance von M365 Produkten ist so erbärmlich langsam was die PowerApp Plattform betrifft. Vorgänge die vorher in Millisekunden erfolgten dauern mitunter ein paar Sekunden. Geschwindigkeit die onPrem extrem wichtig (war) spielt in der Cloud keine Rolle mehr. Die zum Teil erheblichen Einschränken von Webanwendungen gegenüber "Fat"-Clients lassen wir da mal komplett außen vor.
Wir haben eine größere VMware-Umgebung on premise und könnten da auch einen kompletten Exchange-Server oder eine andere Mail-Lösung ausrollen. Letzendlich schützt uns das Backup nicht nur gegen technisches Versagen Microsofts sondern auch kommerzielles oder politisches (Microsofts Kunden in Rußland können ein Lied davon singen).
Als (primär) industrielles Unternehmen haben wir eigentlich das meiste on-premise, M365 wurde in der Corona-Zeit ausgerollt um weitgehendes Homeoffice zu ermöglichen, in anderen Bereichen (z.B. CAD) haben uns die verfügbaren Cloud-Lösungen nicht überzeugt.
Wenn Ihr dann 256GB RAM pro Exchange VM über habt…
Ja, das ist alles soweit richtig und ich widerspreche dem ja auch nicht (im Gegenteil, gelebte Praxis hier).
Mein Argument zielte auf die Vertriebskultur der Cloudanbieter und ich legte zunächst dar, wenn man die Downtime beim Ausfall einer Cloud gering halten will, muss man eine Alternative schon parat haben; etwa einen anderen Dienstleister (bereits vertraglich involviert oder sowieso Parallelbetrieb, weil im Ernstfall brennt es) oder einen anderen Notfallplan. Auch wenn ich das Backup als Cloudservice umsetze, brauche ich einen zweiten Dienstleister (+damit verbundenen Risiken und Kosten).
Doch wenn ich mir Aufwand+Ausgaben anschaue, die das mit sich bringt, frage ich mich wieso man überhaupt seine Onprem Bleche abbauen sollte. USV, Klima, Firewall etc. und Raum brauch' ich ja trotzdem, wenn ich es richtig machen will. Und Leute, die das bedienen können.
Ich weiß noch gut, wie Vertrieb und Consultants von Systemhäusern die Cloud als Lösung für alles verkauft haben (teilweise jetzt noch "was, sie betreiben noch ihr eigenes RZ?"). Als IT darf man dann der GF die ganze Sache wieder ausreden. Und was bleibt am Ende von den vollmundigen Versprechungen? Ernüchterung, wie man sieht.
@Markus.M: Genau den von Dir beschriebenen Einwand meinte ich: Was nützt mir das Backup (wohlgemerkt: nur der Daten), wenn ich nicht einen zweiten Cloud-Dienstleister oder ein ausreichend dimensioniertes on-prem-Rechenzentrum als Standby parat stehen habe?
Bei unserem Weg in die MS365-Cloud haben wir zwar ein on-prem-Rechenzentrum beibehalten, aber die Kapazitäten würden nie im Leben ausreichen, um die Verarbeitungskapazitäten (Server, Speicherplatz, auch Install-/Konfig-Knowhow) der Cloud zu ersetzen.
Ihr reitet also wissentlich und willentlich auf einer Rasierklinge.
Günter der Spruch hieß "von der Sowjetunion lernen heißt siegen lernen" und die Geschichte der SU dürfte bekannt sein. Aber Ransomware gabs da auf alle Fälle noch nicht.
"erfolgreich gelernt" Gü ich hab mag deinen Optimismus, teile ihn aber nicht.
Das zielt auf die Top Etagen, wo BWLler meinten, dass man kaum IT-Sachverstand vor Ort, im Unternehmen braucht, kann ja in die Cloud ausgelagert werden, die wuppen dass dann beim Provider.
Was ich nicht verstehe:
– Der Angreifer war bereits vor dem Umzug auf den Systemen – und keiner hat es gemerkt?????
– Der Angreifer konnte auf ALLE Backups zugreifen? Waren die ALLE IMMER online?
Waren das Backups oder Archivierungen?
Es ist natürlich sträflich unwissend alle Backmedien online zu halten.Es ist in der Microsoft Welt aber auch nicht so wirklich üblich, Medien ständig zu umounten und erst bei Bedarf wieder zur Verfügung zustellen, oder? Es waren wohl keine Bandlaufwerke, die wohl kaum so schnell verschlüsselt werden können. Man könnte sie nur schnell löschen.
Waren es aber Festplatten so wäre es relativ trivial gewesen diese treilweise durch eine unabhängige Zeitsteuerung bei Bedarf zu aktivieren.
So wie ein Bank Tresor nur zu bestimmten Zeiten zu öffnen sind.
Ein Problem sollte beim Backup nicht in der Panik übersehen werden:
Die Backdoor könnte mitgesichert worden sein…
Bänder kann man nicht löschen oder verschlüsseln, man kann sie höchstens überschreiben …
Das ist heute das übliche Vorgehen.
Man infiziert alle Systeme und erpresst die lohnensten zu erst.
Hier könnte auch der Fall sein, das das infizierte System nicht mehr erreichbar war
Aber durch den Umzug kam man wieder drauf.
Wenn die da ein root Kit installiert haben bekommst Du davon Null mit. Außer man sucht explizit ob man gerootet ist.
Von daher ist ein Rootkit nicht immer optimal.
Da wohl nur wenige Admins die Funktion jedebExevind dll kennen und MS nicht klar kommuniziert, fällt wahrscheinlich nicht auf, wenn der Fake Scheduler Fake Schedules ausführt?
Wer bestimmt schon CRC und Inodes aller Binary files vor und nach jedem Update und prüft die Abweichungen?
Oder wie sollte man feststellen dass man einen Untermieter hat. Sag ja erst nicht Virusscanner.
Sollte SecureBoot nicht eigentlich Root Kits verhindern?
War SecureBoot in der NordicCloud gar nicht im Einsatz oder war es wirkungslos?
So wie ich die bisherige Berichterstattung gelesen habe, scheint es mir, als sei das *interne* Netzwerk des Anbieters bereits infiziert gewesen. Dass Verschlüsselungstrojaner in Windows-Netzwerken auf gute Gelegenheiten lauern, ist nicht neu. Dann hat jemand eine Direktverbindung der Cloudrechner zu diesem Netzwerk hergestellt. Und das war es dann.
Das folgende ist ausdrücklich pure Spekulation:
Nach dem Lesen der verschiedenen Quellen (u.a. die dänische Notwebsite) reime ich es mir wie folgt zusammen:
* Ein oder mehrere interne Systeme sind infiziert worden
Vermutlich RDP-Systeme von weniger technikaffinen Leuten wie z.B. Buchhaltung oder Auftragsabwicklung, die schon mal auf unbekannte Mailanhänge klicken.
* Dabei wurde eine Backdoor im System eingepflanzt, von den Hackern aber vermutlich als wenig lohnenswertes Ziel eingestuft.
* Ein interner Umzug dieser Systeme (ob physisch oder virtuell erschließt sich mir nicht ganz) in ein anderes Rechenzentrum stand an.
* Als zusätzliche Vorkehrung hat man diese Systeme ins Backup-Netz gehängt und entsprechende Images (falls beim Umzug was schiefgeht) erzeugt.
* Nach dem Umzug sind sie in diesem Backup-Netz verblieben
* Die Hacker haben wieder vorbei geschaut (vermutlich hat der Umzug eine Meldung an den C&C-Server getriggert) und die neue Situation erkannt.
* Die zum Backup genutzten Systeme (z.B. ein Veeam-Repository oder ein NAS) waren schlecht gesichert, da ja im internen Netz und eigentlich unzugänglich. Möglicherweise Default-Paßwörter, AD-Anbindung oder eine ungepatchte Sicherheitslücke.
* Die Hacker verschlüsseln alle Repositories bzw. löschen sie (sowie die Echtsysteme) und stellen ihre Lösegeldforderung.
* Man will oder kann nicht auf die Forderung eingehen
* Kundendaten kann man noch rekonstruieren (vielleicht Papierkopien der Rechnungen oder ein revisionssicheres DMS), alle von den Kunden eingebrachten Daten (sogar die DNS-Zonen und natürlich die Images der Kundensysteme) allerdings nicht.
* Die vom Development betreuten Templates der DNS-Zonen und Kundeninstanzen liegen vor und werden leer neu gemäß Kundenliste ausgerollt, wer sich authentifiziert (im Kundenstamm hinterlegte Mail oder Telefon) erhält neue Zugangsdaten und kann seine Backups zurück spielen.
* Wer das Vertrauen verloren hat kann trotzdem "schnellstmöglich" Authcodes für seine Domains bekommen und die zu einem anderen Anbieter umziehen.
* Vorsorglich wird dementiert, daß irgendwelche Kundendaten in die Hände der Hacker gelangt sind, um die recht harschen Strafen der DSGVO abzuwenden
* Ansonsten wurde über Geld (ob etwa die Rechnung für den laufenden Monat erlassen wird oder gar ein Sonderkündigungsrecht vor Ende der Vertragslaufzeit besteht) noch gar nicht gesprochen
Dann doch lieber MS und das auch nur mit einem Backup 😀
Weil bei M$ nicht gelöscht, sondern nur kompromittiert wird, ist das besser?
Devinitiv.
Moin,
schliesse mich da rpr an und ich mag mir gar nicht ausmalen was mit dem M$ Master Key angestellt wurde/wird, nur wenn Azure Down geht bleibt as nicht nur ein Grundrauschen …
in diesem Sinne
Und wir werden immer wieder belächelt, dass wir wöchentlich alle Server und Daten auf Band spielen, entnehmen und sicher offline lagern. "Warum sichern Sie nicht in die Cloud?" kann ich nicht mehr hôren. 55 Euro für 10TB (LTO8), die nicht verschlüsselt werden können und im Notfall sofort zur Verfügung stehen – deswegen.
"die nicht verschlüsselt werden können"
Sei dir da mal nicht so sicher! Üblicherweise sichert man ja erstmal "schnell" auf eine Disk und lässt von da das Band laufen. Was ist wenn dir "to Disk" schon verschlüsselt wird und du es nicht merkst? Dann hast du verschlüsselt auf Band im Tresor…
Recovery-Test auf getrennten Systemen mit standardisierten Datenprüfungen sollten schon dazu gehören.
Der Aufwand lässt sich ins Erträgliche runteroptimieren. Oder man kriegt einfach ausreichend Ressourcen zugewiesen. Soll vorkommen. :)
Wer die Recovery nicht testet, hat kein Backup.
nen Backup das nicht auch getestet wurde ist kein Backup! Ich weis den Fehler machen viele, aber sorry mein Mitleid hält sich da in Grenzen… lernen durch schmerz ist immer noch die effektivste Methode!
Wir sichern täglich to disk und zusätzlich wöchentlich to tape, nie von Disk to Tape.
Abgesehen davon würde man beim Backup to disk schon merken, wenn die verschlüsselt ist, denn dann kann der Backup Server seine Backup Chain nicht mehr lesen.
Aber danke für den Hinweis, vielleicht hilft das ja anderen, ihre Strategie zu überdenken.
Wir sichern täglich auf Disk und täglich auf Tape. Auf Disk können wir 30 Tage zurück, Tapes haben wir für 14 Tage. Wichtig ist natürlich alle Möglichkeiten zur Verschlüsselung des Backups abzusichern, ganz richtig.
Bei jedem größeren Umbau in der Umgebung (neue VM, neue Software) wird mind. eine Recovery geprüft, für die Serverkomponente des Backup gibt es ein Backup.
Und wir arbeiten mit einem lächerlichen IT-Budget …
Genauso ists bei uns, aber es wird täglich auf LTO gesichert.
Bänder werden außer Haus gelagert.
Offline Backups kann eine Ransomware nicht verschlüsseln.
Bei einem Cloudanbieter würde ich auch ein Offline-Backup erwarten.
Speziell dafür gibts doch LTO-Libraries.
Mit LTO-9 gibts die bis 25 PB Speicherkapazität.
Und wenn das nicht reicht, nimmt man eben mehrere solcher Libraries.
Mit 25 PB kostet das zwar ca. 100.000,- €, aber man kann die Teile auch leasen. Die 25 PB kosten dann nur 3000,- € im Monat.
Für einen Cloudanbieter sollte das keine unüberwindlichen finanziellen Hürden darstellen.
Und das Offline-Backup kann man den Kunden ja als separates Modul verkaufen, ist also sogar noch etwas dran verdient.
Der Vorfall zeigt gut, das man mit On-Prem gar nicht so schlecht fährt.
Same here,
eine Runde Bänder pro Woche gehen in ein Schliessfach.
Gruß
Komisch. Wir werden dafür nicht belächelt.
Gut, wir machen 95% on premise.
Aber, die Chefetage hatte nach einem größeren Zwischenfall mit Datenverlust in der Branche meine Wünsche erhört und ein noch besseres Offline-Backup als das angeforderte als eigenen Wunsch an mich zurückgegeben. Plus alle gewünschten Personalstunden und finanzielle Ressourcen für standardisierte Recovery-Tests und -prüfungen auf getrennten Systemen.
Seitdem geht die Chefetage damit allerorten hausieren.
Und statt belächelt zu werden, bekommt sie dafür jede Menge positive Rückmeldung in ihrer eigenen Peergroup und sonnt sich darin. Nicht zu Unrecht. Und es steckt andere an.
Hier, also bei Sicherungen, hat sich viel getan in der Wertung von "offline". Das wird als eigener Wert zunehmend anerkannt und als Gewinn bewertet. Also ganz oben, in den technikfernen Strategieetagen. Die verstehen die Logik und sehen wohl auch, dass das eine valide Risikoreduktion für kompletten Datenverlust darstellt, dem schlimmsten Fall den drastischen Schrecken nimmt.
Die Berichterstattung hier und woanders hat also durchaus auch Wirkung, zumindest in meinem Umfeld.
Wenigstens den absoluten Notanker wollen immer mehr. Und das wird so weiter gehen.
Hatte gerade heute wieder einen Rücklauf dazu, wie wichtig das geworden ist. Es wurde ein Statusbericht angefordert und gefragt, ob noch was benötigt wird.
Ehrlich gesagt: In letzter Zeit selten so viel Interesse bei irgendwas anderem erlebt… :)
Dieser Vorfall ist wieder eine Chance, in diesem Bereich Mittel und Interesse zu erhalten. Für jeden, der hier noch Nachhol- oder Verbesserungsbedarf sieht und bisher nicht erhört wurde.
ja, die meisten vergessen oft, dass die Rücksicherung auf OnPrem auch Zeit braucht, selbst mit einer Gbit Leitung braucht das ewig Mal eben TB große Backups zu laden. Cloud BkP macht meiner Meinung nach nur Sinn, wenn das Disaster Recovery dann auch in der Cloud stattfindet oder als zusätzliche Kopie für den Notfall neben der OnPrem Offsite Offline Kopie.
Also hier (beruflich) liegen die backups der letzten 5 Wochen, der letzten 12 Monate und des letzten Jahres an einem externen und sehr sicheren Ort. Wenn in so einem Zeitraum keinerlei – dokumentierte und von der Geschäftsleitung kontrollierte – Prüfung auf Wiederherstellbarkeit stattfindet, dann läuft gewaltig was falsch.
Und hier (privat) gibt es zwar keine Bänder, aber es gibt neben dem backup to disk auch die regelmäßige externe Kopie. Und Dank der Mitbewohner ist der Recoverytest fast schon Tagesgeschäft :-)
"Und Dank der Mitbewohner ist der Recoverytest fast schon Tagesgeschäft :-)"
Kommt mir bekannt vor. :)
vielleicht verstehen ja langsam einige was es heißt, Klumpenrisiken einzugehen.
Klar kann man lokale Windows Systeme hacken und Daten verachlüsseln, aber die Aufwände für Hacker bei einer 50 oder 500 Mann Bude stehen doch in einem schlechten Verhältnis zum Ertrag. Da ist es doch klüger, einen Cloudanbieter oder RZ mit 10.000 Kunden zu kompromittieren.
Oder einen Masterkey für Azure AD zu ergattern.
Wenigstens hat die NSA noch Backups aus M365, von den Dänen eher nicht.
"Wenigstens hat die NSA noch Backups aus M365, von den Dänen eher nicht." Die Backups sind nicht das Problem. Ich finde auf den Seiten der NSA das passende Formular fürs recovery nicht, das ist viel schlimmer! ;-)
Anfrage raus an info(at)nsa.gov – das sollte helfen. :-D
Und im Falle eines Falles kann man ja auch noch die +49 800 111 0 111 bzw. +49 800 222 0 222 wählen! Die spenden Trost!
Wer keine lokalen Sicherungen hat, hat auch keine wichtigen Daten. Somit ist der Komplett-Verlust beim Cloud-Anbieter absolut bedeutungslos und eine reine Bequem-Entscheidung.
Wer Sarkasmus findet, darf diesen zu Höchstpreise auf ebay veräußern. Ich habe nur Häme für ein solches Gebaren übrig – und das als Cloud-Fan (wenn zu 100 % unter eigener Kontrolle).
Wer dort einen Backup Service gebucht hat und die Daten jetzt komplett weg sind kann die bis in die Insolvenz auf Schadenersatz verklagen.
da dürfte es entsprechende Klauseln geben (höhere Gewalt etc.).
Ich denke nicht das komplette Unfähigkeit unter höhere Gewalt fällt, dazu zählt eher Hochwasser oder Sturmschäden.
Ich denke, daß sich kein Vorsatz konstruieren läßt, über grobe Fahrlässigkeit müssen im Zweifelsfall Gutachter vor Gericht entscheiden.
Ein anders gelagerter, aber von den Auswirkungen her ähnlich fataler Fall war vor zwei Jahren der Brand im OVH-Datacenter in Straßburg, der auch für viele Kunden ohne Backup katastrophal wurde.
Wobei das in Frankreich eher die Regel aus Ausnahme ist. inside-it.ch/brand-in-rz-legte-cloud-services-von-google-lahm-20230428
Bei OVH war es ganz klar Vorsatz. Alles aus Holz und keine Löschanlage. Und dann hauen die so etwas raus. handelsblatt.com/technik/it-internet/hyperscaler-wie-ovh-gegen-die-amerikanischen-cloud-konzerne-bestehen-will/29246186.html
Bei mir gilt seit dem Finger weg von französichen Anbietern.
Wessen Daten jetzt "komplett weg sind" hatte kein eigenes Backup und sollte kleine Brötchen backen.
Warum werden keine Infos über den Schädling veröffentlicht, damit man danach scannen und so einen ähnlichen Vorfall anderswo verhindern kann?
Checksumme, Dissassemblierung, Informationen über das eingesetzte Betriebssystem und den Infektionsweg wären hilfreich.
Ein Cloudanbieter, der sämtliche Backups online im Netzwerk verfügbar hält, der handelt grob fahrlässig und sowas sollte zusätzlich bestraft werden und erst gar keine Marktzulassung erhalten dürfen. Da hat der Aufsichtsrat der NordicCloud gepennt und muss entlassen werden und die Aufsichtsbehörde des Staates hat ebenfalls gepennt.
Sowas ist ja nichtmal Amateurlevel, sondern bloody Noob.
Jede Firma sollte auch mal genauer mit verdeckten internen Ermittlungen ihre Mitarbeiter überprüfen, denn da sind eventuell Saboteure darunter, die hier und da mal kurz einen Stick reinstecken oder einen Port in der Firewall öffnen.
Außerdem sollte man bei einem gewissen Schweregrad solcher Hacks auch mal das Militär einsetzen, um den Angreifer mittels Waffeneinsatz zu vernichten, denn ein Hackerangriff auf die Wirtschaftskraft eines Landes ist potentiell existenzbedrohend und kann als eine Kriegserklärung gewertet werden. In den USA ist das offizielle Doctrin, Europäer sind für sowas noch zu unbedarft zu verweichlicht.
Es ist durchaus möglich, dass diesen Angriff auf die NordicCloud ein feindlicher Staat durchgeführt hat als Reaktion, Warnung und Einschüchterungsversuch für die Unterstützung Dänemarks für der Ukraine, denn Dänemark hat kürzlich versprochen, auch F-16 zu liefern. Hack am 18.8, Termin Selenskyj in Dänemark am 20.8.
So eine große zeitliche Nähe ist verdächtig und passt ins Schema des amoklaufenden Russki, aber weiter pennen ist bequemer, zumindest bis die Einschläge zu nah kommen.
Wie viele weaponsgrade-IT-Bomblets habt ihr bereits im System ohne es zu wissen?
Ich würde da nochmal sehr gründlichst nachschauen, ob man wirklich von jeder einzelnen Datei weiß, wo die herkommt und dort hin gehört, oder ob das nicht ein U-Boot in Lauerstellung ist, das auf die Befehle am Tag X wartet.
Frischer Clean-Install von einer known-good-source könnte helfen, das Risiko zu minimieren. Unmittelbar danach Checksummen generieren und per Signaturcheck-Whitelist nur diese known-good-Programme ausführbar machen, damit Fremdprogramme nicht aktiv werden können.
Ransomware hat weder eine passende Checksumme, noch steht die auf der Whitelist, kann dann also nichts machen.
Dazu muss man aber sicher stellen, dass der Admin ebenfalls ein known-good ist und nicht ein Saboteur in feindlichem Auftrag. Deshalb sollte das 4-Augen-Prinzip eingeführt werden, also kein Admin alleine arbeiten dürfen.
Elf-Signaturchecks sind in Linux schon seit über 10 Jahren möglich und Applocker und Software Restriction Policies in Windows sind auch eine gutes Schutzschild, aber die Admins müssen sowas auch mal benutzen und aktivieren.
Die Naivität und die Schlafmützigkeit sollte enden und IT-Systeme abgesichert werden wie Fort-Knox oder eine Geheimdienstzentrale. Da sind keine gelangweilten Script-Kiddies am Werk, sondern echte beinharte feindliche Staaten.
Paranoides Misstrauen ist angesagt, um in diesem Cyberkrieg bestehen zu können.
Den zeitlichen Zusammenhang mit Kampfjets halte ich nicht für gegeben. Der Hack dürfte schön länger laufen. Über den Rest kann man inhaltlich sicher diskutieren aber 3 Nummern kleiner formuliert wäre wahrscheinlich zielführender um Entscheidern das Mittel "der Spinner übertreibt" aus der Hand zu schlagen.
Mein Lieblingsthema zur Zeit:
Rechenzentrum in Irland, nur gut das unter Wassre nichts kaputt gehen kann und noch nie mal was Unerwartetes passiert ist.
Wer ist denn für den Blödsinn mit den vielen Schutzsoftwaregeschichten verantwortlich?
So etwas ist hochgradiger Unsinn und nicht ohne Grund schreiben eigentlich alle Schutzsoftwareanbieter in die Installationsanleitung, das man keine andere Schutzsoftware installieren soll.
Und viele Schutzprogramme setzen entweder auf den Microsoft Defender auf oder sie deaktivieren ihn bei der Installation, eben, damit sich die beiden Sachen nicht ins Gehege kommen.
Viel hilft viel ist bei Schutzsoftware kontraproduktiv!
Das ultimativ sichere Computer-System steht unten im Keller, hat keine physische Verbindung zu irgendeinem Strom- oder Datennetz und ist allseitig von mindestens 3 Metern wasserundurchlässigem Beton umgeben.
Alles andere ist Irrglauben. Als erstes wird die Anti-Ransomware Schutzsoftware — hier heißt sie liebevoll "Produktivitätsmassenvernichtungswerkzeug" — entweder außer Dienst genommen oder ihr wird beigebracht, dass die gerade gelieferte Ransomware zu den guten Programmen gehört und ungestört ausgeführt werden darf. Und das wars dann auch schon.
Ich darf hier regelmäßig ein mit Microsoft Defender, Symantec Endpoint Protection, Carbon Black Bit 9 und sonstigen Anti-Ransomware Highlights präpariertes Notebook mit Windows 10 Enterprise verwenden bzw. ich darf davor sitzend auf Reaktion des Systems auf meine Eingaben warten. Allein die regelmäßige Updateinstallation zum gewohnten Patchday dauert vom Runterladen übers Installieren bis hin zum Neustart und Zuendeinstallieren *JEDESMAL* *MINDESTENS* 75 Minuten. Während der Installation kannste im Taskmanager zusehen, wie sich die Schutzsoftware um die verfügbaren Ressourcen prügelt und das System mehr oder weniger unbenutzbar macht. Es geht und geht nichts vorwärts. Ehrlich gesagt zum Brechen.
Und zu 100% sicher ist das nicht (siehe oben), aber es ist 100%ig sicher, dass viel zu viel Zeit drauf geht, während der ich NICHT ARBEITEN kann. Und auch das sonstige Arbeiten leidet unter der eingeschränkten Geschwindigkeit durch den allumfänglichen Überprüfungswahn.
Paranoia und diese Art von Verbarrikadieren sind allerhöchstens die schlechteste aller möglichen Lösungen aber bestimmt nicht DIE Lösung.
Ich habe mir mal die Webseite kurz auf archive.org angesehen.
Zitat:
"ISO/IEC 27001:2013 ISMS
We have based our technical infrastructure solutions and the way we work with these on ISO 27001: 2013 Information Security Management System (ISMS) standard, so all our customers and other partners always know what quality service they expect from us. "
Unter Solutions:
"Cloud Support
If you have placed your servers and solutions in one of the major worldwide Cloud solutions, then perhaps you also been hit by the fact, that they can fall out and need restarting, updates, analysis of cause errors and 24/7 monitoring?
Maybe your best technical skilled people are now using their time and company resources on 24 hour shifts and preparedness to ensure keeping an eye on these services, instead of focusing on daily operations and development."
Auch die Businessterms "https://web.archive.org/web/20230331193544/https://www.cloudnordic.com/en/about-us/privacy-policy-gdpr/"
Paragraf 7.2.3 (Responsibility) ist der Einzige mit dem Wort Backup:
"7.2.3 It is the customer's sole responsibility to connect to the Internet and CloudNordic can not be held liable for any problems. The customer is fully responsible for continuous updating and maintenance of code and data, as well as backup of these. For certain products, a static IP address at the customer is a requirement, which CloudNordic has no responsibility, since the operation and maintenance of this happens to the customer himself."
Das wäre also die Dänische Variante von IONOS, Hetzger, All-Inkl. , Strato.
Das Logo ziert auch noch den Spruch "The Nordic Cloud Experts".
Ich denke das Problem des GAU wird in Dänemark nicht so einfach mal vom Tisch rutschen!
Auf jeden Fall sollte es mal ein Lehrstück für alle sein, das nichts unmöglich ist und man mit dem Glauben an die Cloud nicht im Himmel der Glückseligen sondern auch auf dem Vorhof zur Hölle spazieren kann.