#Crowdstrike huh? Was lernen wir daraus?
Gucken wir uns erst mal den sehr guten englischen Wikipedia Artikel an, um zu wissen, was da falsch lief… https://en.wikipedia.org/wiki/2024_CrowdStrike_incident
#Crowdstrike huh? Was lernen wir daraus?
Gucken wir uns erst mal den sehr guten englischen Wikipedia Artikel an, um zu wissen, was da falsch lief… https://en.wikipedia.org/wiki/2024_CrowdStrike_incident
Es wird immer besser. Oder Hahnebüchen.
Also: Ein Anbieter von Sicherheitslösungen für Millionen Kunden pusht einen Speicheradressierungsfehler in C++ (jetzt keine Diskussion ob das sinnvoll ist, von der Sprache her) weltweit.
Das ist eigentlich nahezu unmöglich, dass das passiert, also angenommen, dass dein Unternehmen sowas wie ne mehrstufige Qualitätssicherung hat.
Scheint Crowdstrike aber halt null pointer drauf zu kennen.
Versicherungen so: Ja hm, also das ist so ein Thema, da müssten wir mal gucken, aber bei Cyberversicherungen, eher nein. https://www.golem.de/news/laut-gdv-crowdstrike-schaeden-nicht-vom-versicherungsschutz-abgedeckt-2407-187267.html
Das führt aber auch zu einer veränderten Architektur von EDR-Funktionen:
- Mehr Zwiebelschalen um Endpoints herum und nicht auf Endpoints (Firewalls, Malwarescanner auf Netzwerk Storage)
- Mehr Anwendungen in vollständig kontrollierbaren Umgebungen (der Server, die Cloud, die einfacher nach XYZ definierbar sind)
- generell eher weniger mächtiger Endpunkte
Das ist okay, weil auf den Nicht-Endpunkten ist mehr Performance und mehr
beherrschbare Kette von Security-Maßnahmen. Bessere Experience.
Klar, das geht eher nur im Unternehmenskontext, aber was hat Crowdstrike gerade zerballert: Unternehmen. qed.
Irgendwie hat der Thread jetzt zumindest einen endenden Faden und naja, irgendwann ist auch Wochenende.
Grüße an alle IT-Leute, die den Schlamassel ausbaden müssen. Auf Euch.
(Und ganz und gar nicht auf die Security Snakeoil Companies)
Lese gerade, dass die Triebfeder des CEO von Crowdstrike "das ist alles zu langsam" war.
Ja okay, aber wenn dir alles zu langsam ist, musst du sehr schnell zu einem last known good Zustand zurückkommen, wenn es scheitert.
Und nicht in dem Menschen händisch an Devices rumdoktoren. Herrje. Du musst beides haben, sonst geht schnell nicht. https://en.wikipedia.org/wiki/George_Kurtz
Ich will jetzt nicht die zurecht gebrachten Snake Oil Analogien zu Security Glitzer Lösungen bringen, sondern eher nur sagen, dass die Teil eines Grundproblems sind:
Die Teile verkaufen sich, weil sie das Gefühl vermitteln, dass Security ein Produkt sei, das ich einmal kaufe und gut.
Hier ein Packen Security als Anwendung wie praktisch. Macht alles für dich, musste dich auch nicht mehr ärgern.
Und ist auch gut für Compliance.
So leider das funktionierende Marketing.
*Cocktail Pause, der Tag war hart*
So, zurück zu EDR Systemen.
Bei denen liegt oftmals eine sehr falsche Vorstellung zugrunde: Dass es überhaupt möglich ist, in einem System auf einem Device alles Evil dieser Cyberwelt abzuhalten. Nö geht nicht.
Security ist mehr oder weniger ein Prozess von mehreren Ebenen, die scheitern können, bei denen eine allein nie zum vollständigen Zusammenbruch deiner Security oder deines Systems / Business etc. führen sollte.
Aber bei Crowdstrike ist genau das passiert.
Gucken wir mal auf die User-Perspektive: Ein System, das im Hintergrund Ressourcen frisst, vom Arbeiten abhält und immer dazwischen funkt, tut Security einen Bärendienst.
Du musst eher zumindest als Unternehmen ausgehen, dass du deine User und dessen Device nicht komplett als Risiko eindämmen solltest, weil sie sonst Methoden gegen das System finden, um arbeiten zu können.
Nur deutet die Historie des CEO von Crowdstrike eher auf eine Kultur von "Ah egal, mach mal großes Update" hinaus https://www.golem.de/news/crowdstrike-ceo-nicht-zum-ersten-mal-ganze-unternehmensgruppen-lahmgelegt-2407-187257.html
Schon mal ein großes Update versemmelt und 2024 noch mal getoppt. Toller Track Record (ironisch).
Also erster möglicher Fehler: Falsche Updatekultur beim Dienstleister.
Auch wenn du dir mit deinen Updates relativ sicher bist und auch wenn du ne edgy Security Good Cop Programmerbude bist: Der Teufel in der IT ist eine Kette von unvorhergesehenen Problemen für die du vielleicht nichts kannst.
Daher ist es vollkommen okay, wenn du erst mal bei nicht kritischen Updates guckst, ob von deinen x tausend Instanzen nach Update und Reboot etc. die noch laufen und du dann erst die anderen Updatest.
Das kann tatsächlich ne Art von Design Goal bei IT-Prozessen sein: Schutz vor totaler Verkonfigurierung oder Update-Zerstörung durch nur eine Änderung.
Was hier tatsächlich genau so eingetreten ist.
Das zweite Problem betrifft Systeme wie Crowdstrike Falcon.
Also sagen wir mal EDR-Systeme im Allgemeinen (Endpoint Detection and Response).
Die haben oft (eigentlich immer) das Ansinnen als eine Art Superheld Systeme zu schützen.
Und deshalb brauchen die auch immer ganz ganz viele Systemprivilegien.
Überhebliches und gefährliches Gehabe (siehe Updatekultur).
Spannend finde ich die Timeline hier mal als Ausgangslage:
04:09 UTC Release fehlerhaftes Update im Release Channel
05:27 UTC Update wird zurückgezogen
Das ist es echt nicht viel Zeit. Eigentlich
Wir merken an der Timeline des Wikipedia Artikels allein, dass hier sehr schnell Updates eine Kaskade von Problemen auslösen. Nein, das Azure Problem ist eine von Crowd Strike VMs, keines von Azure https://azure.status.microsoft/en-gb/status
Wir haben aber in der Timeline 1 Stunde 18 Minuten als Zeit, in der ein Update verteilt werden konnte, das den ganzen Schlamassel auslösen konnte.
Das ist… lasst uns mal gucken, ob das viel oder wenig Zeit ist für ein Update.
Erst mal die relativ einfache Frage: Was rechtfertigt ein weltweites Update an alle meine Endpunkte ohne Verfahren im Rolling Update*:
1. Es brennt wirklich
2. Eigentlich nichts
*Rolling update ist ein Verfahren, bei dem Instanzen schrittweise geupdated werden. Dabei nimmt man schrittweise ein paar Prozent von upzudatenden Instanzen auf eine neue Version und schaut, ob die nicht explodieren. Wenn dann die ersten 5 % meinetwegen okay waren, kommt so langsam der Rest nach bis 100%.
Klar, so ein Rolling Update Verfahren kann manchmal ein paar Tage dauern, bis alles aktuell ist.
Aber: Es gibt Updates, bei denen das vollkommen okay ist. Google macht das z.B. bei großen Android Updates sehr erfolgreich.
Ausnahme: Es ist so ein Zero Day Fix Update, da ist ein Rolling Update eher zu langsam.
Was herauszufinden ist: Wie kritisch das Update von Crowdstrike war. War es kein Hotfix Zero Day irgendwas Update, war das Updateverfahren eher fahrlässig.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.