Dein zweites Bild kann ich zwar nachvollziehen, aber das ist in diesem Fall leider nicht wirklich fair.

Zunächst: Die Standardeinstellung in Crowdstrike, ist immer die zweitneuste Version des Falcon Sensors (dem Agent) zu installieren. Crowdstrike empfiehlt zusätzlich eine kleine Gruppe unkritischer Hosts (idealerweise verschiedenen OS Versionen) zu definieren, die die neuste Version erhalten. Ich gehe davon aus, dass die meisten Kunden das auch so handhaben.

Das Problem ist, dass das Update was das alles verursacht hat kein Update des Falcon Sensors an sich war und deshalb nicht Teil des normalen Updatezyklus ist. Das File was das gaze Verursacht hat war ein “Channel File” (so nennt Crowdstrike die). Ich weiß zwar nicht genau was der Zweck dieser Dateien ist, aber es handelt sich dabei um einen Haufen .sys Dateien mit mehr oder weniger cryptischen Namen in einem Unterordner von %windir%/System32/drivers, die von Crowdstrike laufend und unabhängig von Versionsupdates gepushed werden. Die betroffene Version des Channel File was für den Mist verantwortlich war wurde von Crowdstrike von ich glaube ca. 6 bis 7:30 Uhr Deutscher Zeit gepushed und hat alle Windows Geräte (Clients und Server) erreicht, die den Falcon Sensor installiert haben, unabhängig von der installierten Falcon Sensor Version. Als Kunde hatte man da gar keine Chance. Das ist auch der Grund dafür warum manche Zeitzonen stärker betroffen waren. Wenn die Geräte in der Zeit aus waren, sind sie verschont geblieben.

Wenn überhaupt hätte Crowdstrike also in Wellen deployen müssen um das ganze zu bemerken und nicht die Kunden. Ich würde gerne wissen wofür diese Channel Files sind, falls das jemand weiß. Ob die irgendwelche Malwaredefinitionen oder so beinhalten und man das Risiko eines globalen Deployments gegen Infektionsraten abwägen müsste. Aber irgendwie kann ich mir schwer vorstellen, dass es, unabhängig vom Ausgang, clever ist das so zu machen.