Of course in our real world, they are unlikely to pay anything at all and just continue operating as-is.
That wouldn't make any sense.
The blame realistically lies within each company who allowed a critical point of failure just so they get checkbox software and not actually have to expend the effort of making sure the company is able to function with their chosen infrastructure.
If airlines skimp on maintenance and planes crash, well, all those dead passengers should have picked an airline that takes maintenance more seriously. Next time they'll know better.
No next time, they're dead, so not a good selection criteria.
Agreed that both sides share some liability, but a vendor that says they create security software with root level code injection access must be held to the highest possible standard, and liability.
If someone puts up a shack and sells hamburgers and hundreds of people die from the rotten meat, they most certainly are liable.
But apparently crowsdstrike can brick computers remotely, causing enormous damage including some deaths, and just say oopsie and walk away without any liability.
Or a world where the regulator that required the checkbox — even if the firm can demonstrate a superior way of achieving the same objective — should pay for it.
With modern tech stacks, we’re talking hundreds of updates a quarter. If not more.
We moved away from that for a reason. And the real fix is to make updates not take down the whole system. When was the last time every Linux system in the world was unable to boot all at the same time?
Even the crowdstrike issue only took down a very limited subset of installs and the blast radius is far more minimal due to the linux kernel being a lot more sane and cautious.
My phone does auto update, and nearly every auto update makes it worse and slower. That's been true for nearly every Android I've had.
One can do the same thing with computers. Build small systems that operate independently, with strictly defined inputs and outputs. Make them un-brickable. Distribute software on read-only media, or outright replace the CPU for each update. You roll back by having the staff unplug the new thing and plug in the old thing.
A high-spec CM4 is $90. A small USB stick costs basically nothing. A bespoke CM4-like machine with only ROM could be made in volume for relatively little money. Most of the problem with an approach like this is that the industry doesn’t think this way.
Maybe a big buyer should step up, e.g. a major military. Non-CrowdStrike-able tech for, say, the US military seems like it would be extremely valuable.
I feel like the answer should be obvious: if you need reliable systems then you don't create a single point of dependency on such fragile systems.
The latest blog from Bruce Schneier is a good writeup on this brittleness:
https://www.schneier.com/blog/archives/2024/07/the-crowdstri...
I've been involved in procurement at a big corporation and one thing we always modified in contracts was making the vendor 100% liable for any damages caused by their outages, but many vendors wouldn't make that modification.
Which in this case is probably a lot less than what these companies are paying in clean up costs.
Realistically, this doesn’t happen because the returns don’t make sense. If vendors are liable for your business, they need to account for your business in their costs. That drives their costs (and prices) up.
That is not a bad thing. Today all these shaky companies exist because they can take all the profit and externalize all the downsides, laughing all the way to the bank.
If they were made liable, one of two things might happen, both of which are positive outcomes.
One, they might upgrade their engineering and quality processes to the point where they can guarantee they won't be the root cause for taking down large parts of the industry. Sure it'll cost more but if they can do it and still make a profit (just less), all is well.
Two, maybe it simply can't be profitable to build these root backdoor systems with enough layers of safety, in which case the companies will disappear. This is also good; if the product can't be safe, it should not exist.
Building bridges is a very overused analogy, but it's still a good one. Structural engineers still design bridges and they get built.
What they don't do it throw some drawing together and YOLO it to the builder and let's see what happens, the way software gets built.
If a bridge has maintenance issues causing it to be unusable while it is being fixed, the bridge makers are not on the hook for the total downstream economic loss.