News CrowdStrike: Update legt PCs & Server weltweit lahm, Workarounds helfen

Conqi schrieb:
Das hat jetzt aber absolut nichts mit Cloud zu tun. Da wurde eine fehlerhafte Datei ausgerollt, was dir im Prinzip mit jeder noch so klassischen Antivirus-Lösung passieren kann.
Ja nun, jein?
Du hast einen Punkt, allerdings:
Crowdstrike ist ein TopTier "Managed ... plenty of stuff" Provider. XDR, CloudProtection, alles selbstverständlich mit KI etc. pp. Wenn Du in Gartner guckst (und das muss man, denn dein Manager macht das auf JEDEN Fall), stehen in die in vielen Bereichen oben rechts.

Deren Lösungen sind allesamt SaaS.
Zumindest wüsste ich jetzt nicht, was da nur OnPrem rumgammelt.

Dass die jetzt natürlich ihre etwas älteren Versionen mit einer Config abschiessen, entbehrt nicht einer gewissen Ironie. Die sind ganz klar Cloudbasiert.
Daher ging das Update wohl in deren Umgebung und von dort dann in alle weiteren angeschlossenen Kunden.
Und weil managed == automatisch verteilt in die Tenants die in der Cloud hängen ... bumm.
Von daher stimmt meine Aussage durchaus.

Witzig ist, dass die mit ihrem Managed Services ausgerechnet alle diejenigen abgeschossen haben, die keine eigene Abteilung haben die sich um sowas kümmert.

Mir stellt sich halt die Frage, inwieweit die das überhaupt getestet haben, oder ob das wieder so eine YOLO Dev war. Von deren Aussagen nach zu urteilen haben die nur die aktuelle Version getestet, ohne auf die von Ihnen immer noch unterstützten älteren Versionen Rücksicht zu nehmen.

Sowas geht halt gar nicht.
Ergänzung ()

k0ntr schrieb:
die frage ist eher, wie schnell wird das problem behoben. auch hierfür, wie du geschrieben hast, gibt es SLAs.
Ja, auf die wäre ich auch mal gespannt, auf deren SLAs.
 
JustAnotherTux schrieb:
GGF. ja weil auf unterschiedliche Distros,
mit unterschiedlicher Softwarekonfiguration,
unterschiedlichen Updateintervallen,
und unterschiedliche Softwareversionen gesetzt wird.
Ja, damit wäre eventuell der totale Impact geringer, aber für ein einzelnes Unternehmen, dass z.B. eine von so einem Problem betroffene Distribution einsetzt, macht es keinen Unterschied.
 
@TomH22

Bei sehr wichtigen Systemen sollten die Updates manuel laufen.
Zuerst wird das dev Setup aktuallisiert dann Q und dort sollten dann
zuerst alle Akzeptanztests durchlaufen bevor es nach X Tagen dann auf Prod geht.


Das machen wir bei uns im Unternehmen auch so.


Wenn es zur kritischen Infrastruktur gehört, würde ich davon ausgehen, das es jedes Stage sogar zweimal gibt und dann per LoadBalancer einfach hin und her gewechselt werden kann.
Wenn das neue dann nicht geht kann direkt zum alten System zurückgewechselt werden.
 
  • Gefällt mir
Reaktionen: trb85, Ja_Ge, Unnu und eine weitere Person
Auch wenn Crowdstrike hier eine Hauptschuld trifft, zeigt es doch sehr deutlich, wie fehleranfällig unsere Gesellschaft ist mit den ganzen einzelnen Komponenten.
Nach meinem Verständnis hat der Fehler im Crowdstrike update zu weiteren Fehlern geführt, die auch nicht immer gleich sind. Und es sind auch nicht alle Systeme mit Crowdstrike betroffen. Das zeigt doch, dass das Problem etwas komplizierter ist.

Ich teile die Kritik, dass wir KRITIS-relevante System nicht so aufbauen sollte, dass so ein Fehler zum Totalausfall führt und vor allem, dass das Wiederherstellen so aufwendig ist und lange dauert.
Problematisch ist hier nicht nur die IT-Seite (die Server konnten relativ schnell wieder hergestellt werden), sondern wie abhängig das "System" davon ist. Und wie schnell dann "gar nichts mehr" funktioniert.
Und wir reden hier nicht von nicht vorhersehbaren Naturkatastrophen oder gezielten Anschlägen - sondern von einem Fehler eines Updates - damit MUSS man planen. Dafür MUSS es eine Lösung geben.
Das Stichwort heißt "Business Continuity". Und da ist "IT Recovery" nur ein Teil von.

Das wird hoffentlich in Ruhe analysiert und die entsprechenden Schlüsse gezogen - vor allem politisch. Genau dafür ist KRITIS ja da. Ich hoffe, dass alle KRITIS Unternehmen und Einrichtungen spätestens am Montag Post bekommen. So etwas darf nicht noch einmal passieren.
 
  • Gefällt mir
Reaktionen: cruse
Tja, bei uns in der Firma sind praktisch nur die betroffen, die ihren PC über Nacht anlassen, obwohl man eigentlich angewiesen ist, das nicht zu tun, und dann automatisch das tolle Update gekriegt haben. Karma is a bitch ;)
 
habla2k schrieb:
Das ist ein viel wichtigerer Punkt. Wenn es nicht nur eine sondern 5 oder 10 dieser Firmen gäbe, die sich das aufteilen, wäre der Impact auch deutlich kleiner. Das ist viel realisitischer, als dass plötzlich jede Firma 100 Mitarbeiter für manuelle Update Tests abstellt.
Naja, "manuelle Updates" und testen ist ein weiter Begriff.

Zumindest wir handhaben das so, dass erst ungetestet, dh direkt vom Patchanbieter übernommen auf die Testumgebung ausgerollt wird. Automatisch. Die Produktivumgebung wird erst "freigeschaltet" nachdem der Betrieb in der Testumgebung keine Auffälligkeiten zeigt.
Bei grösseren Softwareupdates wird natürlich dediziert in der Testumgebung noch die jeweiligen Softwarefunktionen geprüft.

Wir setzten die Software hier nicht ein, jedoch eine ähnliche (Zscaler). Dort sind verschiedene Computergruppen und Updatepolicies konfigurierbar. Gibt es einen neuen Client wir bei uns wie oben beschrieben vorgegangen. Kann sein (und ist auch schon passiert), dass dann halt ein paar PCs in der Testumgebung nicht mehr tun - aber das Risiko und die 1-2 Tage Verzögerung ist das durchaus wert.

Natürlich wird das bei Definition Updates für AVs nicht gemacht. So wie ich es aber verstanden habe, war das kein Definition Update sondern ein Client / Driver Update.
 
  • Gefällt mir
Reaktionen: Unnu
MS sieht Crowdstrike und so: "Hold my beer"

"Preliminary root cause: A configuration change in a portion of our Azure backend workloads, caused interruption between storage and compute resources which resulted in connectivity failures that affected downstream Microsoft 365 services dependent on these connections."

Hey, wir haben unsere Kunden auch aus versehen abgeschossen.
😂 😂 🤪 🤦‍♂️
 
fox40phil schrieb:
"Halten Sie Ihre Systeme stets aktuell!"
Das wäre sinnvoll gewesen, denn lt. Crowdstrike waren nur die beiden Vorgängerversionen betroffen.
Ergänzung ()

CadillacFan77 schrieb:
Die Produktivumgebung wird erst "freigeschaltet" nachdem der Betrieb in der Testumgebung keine Auffälligkeiten zeigt.
Bei grösseren Softwareupdates wird natürlich dediziert in der Testumgebung noch die jeweiligen Softwarefunktionen geprüft.
Und wie lange lasst ihr euch da Zeit im Mittel?
Produktiv geht bei uns nach spätestens 48 Stunden.

Kritische Server natürlich etwas länger, jedoch ebenfalls unter einer Woche.
Ergänzung ()

Mäxle87 schrieb:
Was zum Henker ist CrowdStrike?
Service für diejenigen die von "Cyber" dezent entkoppelt sind:
https://www.crowdstrike.com/de-de/
 
  • Gefällt mir
Reaktionen: Hunder
Taron schrieb:
Ich finde es schäbig wie ein Unterehmen einfach mal die Welt halb lahmlegen kann.
Soll der CEO ruhig mal dafür bluten, immerhin greift der die meiste Kohle von allen ab.
Als ob die das absichtlich machen würden.
 
Es ist wirklich witzig, wieviele Leute bei solchen Events hinterher der festen Überzeugung sind, dass sie das ja immer schon gewusst haben und die Lösung war doch von vornherein offensichtlich und easy.
"Einfach nicht updaten", "erstmal ordentlich testen", "Admins sollte das Update nicht freigeben","Windows user sind selber Schuld - nutzt halt Linux" und solche tollen Statements zeugen eher von Unverständnis des Themas.
 
  • Gefällt mir
Reaktionen: ComputerJunge, Justiin, areiland und 10 andere
Das wir Klagen hageln, bin gespannt wie es mit der Firma weitergeht
 
CadillacFan77 schrieb:
Naja, "manuelle Updates" und testen ist ein weiter Begriff....
Bei Crowdstrike kann man auch verschiedene Update Ringe konfigurieren, auch für den betroffenen Falcon-Sensor. Problem ist nur das dieses "Channel-Update", wie Crowdstrike es nennt, auch die älteren Versionen des Sensors, also auf Systemen die im N-1, N-2 usw. Updatering sind betrifft.
 
  • Gefällt mir
Reaktionen: tavoc, fox40phil, Unnu und 2 andere
JustAnotherTux schrieb:
Bei sehr wichtigen Systemen sollten die Updates manuel laufen.
Das Problem im vorliegenden Fall scheinen ja eher die vielen „nicht sehr wichtigen“ Systeme zu sein, also z.B. die Client Computer. EDR Systeme sind ja genau dafür gedacht, dort eingesetzt zu werden.
Der kurzfristige Impact ist dadurch natürlich trotzdem sehr groß, außerdem ist die Reparatur durch die Anzahl aufwändig.
 
  • Gefällt mir
Reaktionen: JustAnotherTux
Wir sind auch betroffen. Ich arbeite in der Produktion und da wird noch viel mit Papier gemacht. Wir konnten erst mal "normal" wieter arbeiten. Andere Abteilungen hatten früher heute frei.

Firefly2023 schrieb:
Als ob die das absichtlich machen würden.
Sagt ja niemand. Soll das jetzt ein Freibrief werden deine Aussage? Dann kann wirklich jeder machen was er will.
 
lorpel schrieb:
Das ist genau der Grund warum ich keine Schutzprogramme einsetze und auch keine Updates automatisch einspielen lasse.

Fritte: Update aus❗
Windows: Updates aus ❗
Programme: Updates aus ❗
Handy, TV, AVR: Updates aus❗

Wenn dann manuell einspielen, aber vorher nach Problemen googlen. Einmal im Jahr reicht mir die Prozedur.

Q.e.d.

Das kannst du als Privatperson gern so machen aber nicht in einer Firmenumgebung.
 
  • Gefällt mir
Reaktionen: Kalsarikännit, Miuwa, Justiin und 13 andere
Der ältere Mann mit dem Einkaufswagen. Ich kann ihn hören.
 
  • Gefällt mir
Reaktionen: fox40phil
Zurück
Oben