On 2024-07-21 at 10:42, Joe wrote: > On Sat, 20 Jul 2024 15:27:17 -0400 gene heskett > <ghesk...@shentel.net> wrote: > >> And even you Hans, leave out the major, all encompassing, reason >> for the lack of market share, which is that most business that have >> a computerized system to run things also value what their MBA >> says. And since there is no one to sue to cover their personal butt >> in case the system goes south like cloudflare has in the last 3 >> days, M$ & cloudflare are a brick and morter legal target they can >> sic the legal team onto. >> >> Their is essentially no one in the linux arena to sue if things go >> south, so it doesn't take more than an eighth grade education to >> see why they won't ever recommend linux no matter how superior it >> may be at the end of a P&L report. They have to have someone to >> sue. Bill Shakespear said it best when he wrote "first, we kill >> all the lawyers." But MBA's had not yet crawled out of the slime >> schools yet, so he can't be blamed for not including MBA's when he >> wrote that famous phrase. > > It's a little bit more subtle than that. Debian offers exactly the > same software warranty as MS or CloudStrike i.e. zilch. Larger > businesses generally buy service contracts from middlemen, who are > the ones who get sued. And so they should be if they have not > provided, as part of their contract, quick and reliable recovery > systems, and immediate response to emergency calls. > > Overnight full backups would have solved this problem,
How? That is, how would they have eliminated the need to go touch each computer in order to get it reverted to a state where it can be managed by e.g. the systems which could restore from the most recent backup? > and it would never have arisen if the system admins had disabled > automatic updates and waited the customary few days before applying > them manually, to see how many people screamed on the day of > release. Quite a few, in this case. While I agree that the admins of the CrowdStrike backend systems should have done more testing before releasing this update to be deployed to client endpoints in the wild, I have no reason to think that that release is controlled by an "automatic updates" mechanism, nor that it is the type of update which it is customary to wait before releasing. For the admins of the endpoint systems which are running the CrowdStrike Falcon sensor, it really depends on which kind of update this was. If this was a new version of the sensor software itself, then there is indeed a delay mechanism available, and in fact built in to the control console for the software, and I fully expect that most people who administer the software for the client enterprises are taking advantage of it. That new-version-delay mechanism lets sysadmins divide their endpoints into groups, and decide which sensor version each group will run: the latest, the next-to-latest, or the one before that. (You can even move endpoints from one group to another, and see them change versions - even potentially downgrading - within short order.) At my own workplace, we have nearly everything set to "the one before that", i.e. two versions prior to the current release - exactly in order to avoid being hit by problems like this one. In this case, however, the problematic update appears to have gone out to *all sensor versions simultaneously*. That tells me that rather than being an update to the sensor itself, this almost has to have been an update to the *data files* used by the sensor as it operates - the equivalent of a definition update, for other common antivirus-type tools. With most such tools that I'm aware of, those type of updates are typically released *daily*, and being even one day behind can leave you vulnerable to a zero-day exploit. I am not at all certain that there is any mechanism to disable "automatic update" of that type of data, or even that there *should* be; I am certainly not aware of any customary practice of waiting a few days before deploying that type of update. Even if there is such a mechanism and such a practice, the frequent releases and the potentially high impact of a delay would seem to make it unreasonable for sysadmins to be expected to make use of them. (I've snipped the rest of what you wrote, as I have no particular disagreement with any of it, and agree with some in ways that I don't feel the need to express.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
