It's easy to make comments like this against automatic updates, but then you get popped because something that would have been automatically updated misses a patch because it was too critical to risk automatic updates.
In practice, failing closed (or crashing) is probably fine for most businesses, and lower cost than a breach, but the correct solution is automated testing across a broad spectrum of devices, staged and rolling updates to prevent entire fleets going down at once, and ensuring that there is an effective, tested rollback mechanism.
> but then you get popped because something that would have been automatically updated misses a patch because it was too critical to risk automatic updates.
This kind of logic only works if you ignore any kind of possible nuances in the problem and just insist on throwing the baby out with the bathwater. Just because someone let you do automatic updates (or let's be real, you probably didn't give them much of an option) that doesn't mean you should use it for everything.
Automatic update of data (like virus definitions) != automatic update of code (like kernel driver)
And really, the only time you could justify doing automatic updates on other people's machines is when have reason to believe the risk of waiting for the user to get around to it is larger than the damage you might do in the process... which doesn't seem to have been the case here.
> This kind of logic only works if you ignore any kind of possible nuances in the problem and just insist on throwing the baby out with the bathwater. Just because someone let you do automatic updates (or let's be real, you probably didn't give them much or an option) that doesn't mean you should do use for everything.
Oh, I agree - automatic updates are nuanced in many cases. Generally speaking, automatic updates are a good thing, but they offer trade-offs; the main trade-off is rapidly receiving security updates, at the risk of encountering new features, which can include new bugs. This is kind of a big reason why folks who buy systems should be requiring that updates offer a distinction between Security/Long Term Support, and Feature updates. It allows the person who buys the product to make an effective decision about the level of risk they want to assume from those updates.
> Automatic update of data (like virus definitions) != automatic update of code (like kernel driver)
Yep, absolutely, except for the case where the virus definitions (or security checks) are written in a language that gets interpreted in a kernel driver, presumably in languages that don't necessarily have memory safety guarantees. It really depends on how the security technology implements it's checks, and the facilities that the operating system provides for instrumentation and monitoring.
> shows the data/code update separation does not prevent problems.
Sure they do? This is like saying seatbelts don't prevent injuries because people still die even while wearing them.
I never said that one weird trick would solve every problem, or even this particular one for that matter. What I was saying was that if you look for ways to add nuance... you can find better solutions than if you throw the baby out with the bathwater. I just gave two examples of how you could do that in this problem space. That doesn't mean those are the only two things you can do, or that either would've single handedly solved this problem.
The problem in your scenario is that kernel mode behavior is being auto updated globally (via data or code is irrelevant), and that should require a damn high bar. You don't do it just because you can. There's got to be a lower bar for user mode updates than kernel, etc.
That's definitely what I meant - just because you wear a seatbelt does not mean it is now impossible to get hurt.
You still need to drive carefully. To me, it looks like these people relied on the safety of seatbelts and drove really fast, and there was, predictably, a horrible crash with a lot of damage.
Crowdstrike themselves seem to have missed the nuance.
In practice, failing closed (or crashing) is probably fine for most businesses, and lower cost than a breach, but the correct solution is automated testing across a broad spectrum of devices, staged and rolling updates to prevent entire fleets going down at once, and ensuring that there is an effective, tested rollback mechanism.
But that shit's expensive, so shrug :/