Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsNach weltweiter IT-Störung: Wie Unternehmen auf den Crowdstrike-Ausfall reagieren
Als der Crowdstrike-Ausfall vor zwei Monaten weltweit Windows-Systeme zum Absturz brachte, ging es auch schnell um die Frage, wie man sich vor solchen Vorfällen schützen kann. Deutsche Unternehmen wollen nun vor allem an IT-Notfallplänen arbeiten, aber auch Standards wie regelmäßige Updates stehen auf Maßnahmenlisten.
Einfach die Zugriffe klären. Die meiste Verzögerung kam ja daher weil die Leute nicht an das Rootverzeichnis kamen um das fehlerhafte Update zu löschen. Sei es wegen Verschlüsselungen oder virtuellen Maschinen ohne die Möglichkeit das Rootverzeichnis aufzurufen.
Der Mitarbeiter soll also Rootrechte bekommen und somit jeder Schadsoftware Tür und Tor öffnen bzw. selber das Problem fixen?? Es hat schon seinen Grund, warum das der IT vorbehalten ist
Schulungen, Updates, Backups... Das sollte Standard sein!
Die Frage ist nur, inwiefern schützt das vor einem fehlerhaften Patches einer Software, die auf Kernelebene läuft? Richtig, gar nicht. Das Produktivsystem ist dann erstmal platt!
Es gibt einfach Firmen, deren Software sollte man nicht auf Kernelebene ran lassen. Crowdstrike gehört jetzt dazu. Vertrauen verbrannt.
Umgesetzt werden sie, sofern vorhanden, aber erfahrungsgemäß sehr chaotisch, weil man nicht geübt ist. Das könnte man mit Planspielen machen, aber das kostet Zeit und Geld. Das will kaum ein Unternehmen investieren. Man setzt auf das Prinzip Hoffnung.
Und wenn mal Pläne existieren, sind sie in der Regel veraltet, mal von irgendjemand zusammengeschustert oder irgendeine Vorlage wurde einfach umgeschrieben.
weil crowdstrike den einsatz in kritischen systemen in seinen agb ausschliesst und generell keine fehlerfreiheit garantiert. konnte (und sollte) jeder vor dem kauf und der installation durchlesen. insofern - selbst schuld.
Was sind denn das für total unsinnige Antworten?
Häufiger updaten um ein Problem zu verhindern welches beim (vollautomatischen) Update auftritt? 🤔
Vor genau so einem Problem wird überhaupt nichts schützen.
Wenn das nächste Woche wieder passiert wird der Impact genauso groß sein wie beim ersten Mal.
Höchstens die Zeit für die Wiederherstellung wird bedingt durch die vorhandene Übung was geringer sein.
Der Mitarbeiter soll also Rootrechte bekommen und somit jeder Schadsoftware Tür und Tor öffnen bzw. selber das Problem fixen?? Es hat schon seinen Grund, warum das der IT vorbehalten ist
Der Mitarbeiter soll also Rootrechte bekommen und somit jeder Schadsoftware Tür und Tor öffnen bzw. selber das Problem fixen?? Es hat schon seinen Grund, warum das der IT vorbehalten ist
Das wäre schon mal eine gute Maßnahme, sollte jedoch eine Selbstverständlichkeit sein, genauso wie Backups, die eigentlich das A und O einer guten IT Infrastruktur aus machen.
Wieso steht auch bei so vielen Usern, "Kein Backup, kein Mitleid" im kleingedruckten.
Was bedeutet das in der Praxis?
Bekommt dann einfach jeder Adminrechte, weil: man hatte ja ne Schulung in "wie ich gehe ich mit Adminrechten um"?
Oder nur die Entwickler, weil die müssen ja ständig Software "ausprobieren" um innovativ zu bleiben?
Oder keiner, außer man fragt danach?
Bekommen dann eigentlich alle Linux, weil Windows offensichtlich zu unsicher ist? Was machen wir eigentlich mit den Windows Kisten, die wir da seit 30 Jahren rumschleppen? Wie stellen wir sicher, dass alle immer die Linux-Distribution aktuell halten. Da gibts bestimmt Tools für. Aber gibts die auch in zwei Jahren noch? Oder muss ich dann komplett wechseln? Wie soll ich das in meine Fantasie-Wirtschaftsplanung einbringen!
Schalten wir dann von heute auf morgen alles um? Aber was machen wir mit den 146 dann "Altsystemen"? 98 davon können wir vielleicht migrieren. Aber die anderen benötigen dringend ein Windows-System. Sonst laufen sie nicht.
Irgendeine Bullshit-Compliance Security-Richtlinie empfiehlt Windows. Das zugehörige Zertifikate würden wir dann verlieren, wenn wir auf ein sicheres OS wechseln würden. Oh und mist. SAP empfiehlt Windows. Vielleicht können wir das als VM unter Linux laufen lassen. Aber dann gibts wieder Kosten für die Lizenz.
Die äußere Logik ist einfach: EINFACH ALLES ÄNDERN. Die innere Logik ist ziemlich kompliziert. Vor allem im laufenden Betrieb.
Ich sollte Bullshitbeauftragter in dem Unternehmen werden, in dem ich arbeite .
Der Puritaner schrieb:
Das wäre schon mal eine gute Maßnahme, sollte jedoch eine Selbstverständlichkeit sein, genauso wie Backups, die eigentlich das A und O einer guten IT Infrastruktur aus machen.
Wieso steht auch bei so vielen Usern, "Kein Backup, kein Mitleid" im kleingedruckten.
Also aus persönlicher Erfahrung als Angestellter in einem kleineren "Konzern" muss ich sagen: Backups waren/sind vorhanden. Downtimes waren dennoch da. Es gibt einfach zu viele Einzelserver die zwar gesichert werden, aber dennoch von Hand wieder hergestellt werden müssen.
Wir als "Cloud-Abteilung", die den ganzen Kram auf AWS verwalten, haben dem Geschehen nur interessiert zugeschaut. Im Zweifel würd ich sagen: spielt halt das Docker-Image von gestern auf 🤷♂️. Daten sind eh getrennt vom OS. Uns wird immer vorgeworfen, was wir denn machen würden, wenn AWS mal down wäre... Aber wegen solchen Aktionen steht es mittlerweile insgesamt 3:0 für uns (seit 2020 machen wir sowas).
Im Gegenteil. Wir haben eine Lambda laufen, die regelmäßig die Verfügbarkeit unserer Services prüft und regelmäßig zum Ergebnis kommt, dass die Server vor Ort (Authentifizierung gegen on-premise) mit einer gewissen Regelmäßigkeit nicht verfügbar sind).
[...] Wir als "Cloud-Abteilung", die den ganzen Kram auf AWS verwalten, haben dem Geschehen nur interessiert zugeschaut. Im Zweifel würd ich sagen: spielt halt das Docker-Image von gestern auf 🤷♂️. [...] Uns wird immer vorgeworfen, was wir denn machen würden, wenn AWS mal down wäre... [...]
Mein Arbeitgeber hatte allein dieses Jahr schon drei RZ-Ausfälle von mehreren Stunden, zwei Downtimes beim Anbieter des Cloud-basierten Ticketsystems und des ebenfalls Cloud-basierten Wiki-Systems und vier ISP-Störungen an einzelnen Standorten gehabt. Und halleluja, dank MPLS mehrere Netzwerkstörungen mit ordentlicher Tragweite, bei dem die einzelnen Fallback-Lösungen via Mobilfunk "nicht wirklich funktionierten".
Der Geschäftsführer fragt die IT süffisant, wie wir den Betrieb über die Cloud sicherstellen wollen. Wir so: "Gar nicht, weil das Rechenzentrum nicht uns gehört.". pikachuface.jpg 😮 par excellence, sage ich dir.
Der Geschäftsführer fragt die IT süffisant, wie wir den Betrieb über die Cloud sicherstellen wollen. Wir so: "Gar nicht, weil das Rechenzentrum nicht uns gehört.". pikachuface.jpg 😮 par excellence, sage ich dir
Wir sind ebenfalls vor ein paar Monaten von eigener Serverfarm zu einem Dienstleister migriert, der nun unsere Terminalsessions Hostet. Wenn es da Probleme gibt, dann lautet die Standardantwort mittlerweile entweder: “Problem des Dienstleisters, können wir nix machen” oder “Joa, bitte warten. wir schreiben ein Ticket”
Man glaubt nicht wie doof die Blicke teilweise sind. Aber wenn das obere Management es so haben will, bekommt es was es will. Mit allen Konsequenzen
Irgendeine Richtlinie oder das BSI oder weil man KRITIS ist oder oder oder… letztendlich geht es vielerorts mittlerweile mehr darum Compliance Checklisten zu erfüllen und nicht um wirkliche Absicherung.
Wir sind im Betrieb seit gut einem Jahr dabei irgendwelche Risikobewertungen und Bullshit Bingo Listen auszufüllen anstatt um das reine Tun. Selbst wenn externe Dienstleister Updates einspielen muss das bei uns intern durch ein Advisory Panel “genehmigt” werden. Lustig wird es, wenn was abgelehnt wird und der Dienstleister so oder so einspielt.
@cansys
Nach gut 20 Jahren als Netzwerker komme ich zu den persönlichen Fazit, das ne hohe Verfügbarkeit mindestens zur Hälfte reine Glückssache ist und oft gar nichts über die Kompetenz des Betreibers aussagt und man auch nicht von vergangener Verfügbarkeit auf die zukünftige schließen kann.
In der Theorie klingt das immer ganz einfach Dinge redundant zu bauen.
Man nimm einfach zwei Router mit redundanter Anbindung, VRRP nach unten hin, eventuell noch Router mit zwei Routing engines, MPLS auf den Backbone links.
Gegebenenfalls testet man das dann auch noch (einzelne Interfaces ziehen, gegebenenfalls das ganze Gerät ausmachen) und alles läuft super.
In der Praxis läuft man dann drei Wochen später in nen Softwarebug rein, der dazu führt, dass da irgendein Prozess auf dem Router abschmiert, das Teil erstmal fünf Minuten seine Routen neu lernen muss, währenddessen aber der failover nach unten hin unverändert bleibt und die Kiste den Traffic nullroutet.
Vor 15 Jahren hatte ich ein Netzwerk aus veralteten Catalysts, die wir ohne Support gebraucht gekauft haben, Kunden wurden größtenteils unredundant angeschlossen, Hauptsache billig, inline Management über die public IP, kein oobm, updates vielleicht alle zwei Jahre, monitoring bestenfalls rudimentär.
Heute habe ich hier das feinste Equipment für mehrere Millionen mit Herstellersupport stehen.
In die Entwicklung des Setups / die Configs sind tausende Stunden Arbeit geflossen, die Dinger werden immer up to date gehalten.
Und trotzdem: menschliche Fehler und ddos mal außen vor gelassen hatte das alte Setup eine deutlich bessere Verfügbarkeit, schlichtweg weil wir dort nicht in Unmengen an Bugs reingelaufen sind.
.
