Honestly your comment highlights one of the few defenses... don't sit all on one platform.
Debian has automatic updates but they can be manual as well. That's not the case in Windows.
The best practice for security critical infrastructure in which peoples lives are at stake, is to install some version of BSD stripped down to it's bare minimum. But then the company has to pay for much more expensive admins. Windows admins are much cheaper and plentiful.
Also as a user of Ubuntu and Debian for more than a decade, i have a hunch that this will not happen in India [1].
Or they never considered it, which is far worse.
The specific of this CrowdStrike kernel driver (which AFAIK is intended to intercept and log/deny syscalls depending on threat assessment?) means that this is badnewsbears no matter which platform you're on.
Like sure, if an OS is vulnerable to kernel panics from code in userland, that's on the OS vendor, but this level of danger is intrinsic to kernel drivers!
CloudStrike only uses a kernel level driver on Windows. It's not necessary for Mac, it's not necessary for Linux.
Why did they feel that they needed kernel level interventions on Windows devices specifically? Windows may have some blame there.
I do think there's an argument to be made that CrowdStrike is more invasive on Windows because Windows is intrinsically less secure. If this is true then yeah, MSFT has blame to share here.
I imagine they've simply moved to eBPF if they're not shipping the kernel module anymore.
In particular, while it looks like macOS's Endpoint Security API[0] and Linux 4.x's inclusion of eBPF are both reasonably robust (if the literature I'm skimming is to be believed), ETW is still pretty susceptible to blinding attacks.
(But what about PatchGuard? Well, as it turns out, that doesn't seem to keep someone from loading their own driver and monkey patching whatever WMI_LOGGER_CONTEXT structures they can find in order to call ControlTraceW() with ControlCode = EVENT_TRACE_CONTROL_STOP against them.)
0: https://developer.apple.com/documentation/endpointsecurity
Maybe because everyone else in "security" and DRM does it, so they figured this is how it's done and they should do it too?
My prior on competence of "cybersecurity" companies is very, very low.
What DRM uses kernel drivers? And how do you plan to prevent malware from usermode?
Dmitri Alperovitch agrees with you.[0] He went on record a few months back in a podcast, and said that some of the most atrocious code he has ever seen was in security products.
I am certain he was implicitly referring, at least in part, to some of the code seen inside his past company's own code base.
0: https://nationalsecurity.gmu.edu/dmitri-alperovitch/ ["Co-founder and former CTO of Crowdstrike"]
Crowdstrike uses a kernel level driver ONLY on Windows.
Even better..
ONLY on Windows does CrowdStrike use a kernel level driver.
On Linux, ebpf provides an alternative, and I assume, plenty of advantages over trying to maintain kernel level extensions.
I haven’t researched, but my guess is that Microsoft hasn’t produced a suitable alternative for Windows security vendors.
Updates should not be destructive. Linux doesn't typically overwrite previous kernels, and bootloaders let users choose a kernel during startup.
Furthermore, an immutable OS makes rollback trivial for the entire system, not just the kernel (reboot, select previous configuration).
I hope organizations learn from this, and we move to that model for all major OSes.
Immutability is great, as we know from functional programming. Nix and Guix are pushing these ideas forward, and other OSes should borrow them.
Windows offers it's users nothing here.
Of course that means putting the user in control of when they apply updates, but maybe that would be a good thing anyway.