This is exactly the problem, which the feds face: you can't beat a quasi-monopolistic company, which builds items deemed essential for national security, into submission with monetary fines. If they become unprofitable, they'll threaten default and fed money will flow. The only measure, which will fix their attitude, are long term prison sentences for the responsible executives. Their corrupt and reckless business decisions willingly risk and cost more live than those of the casual Fentanyl peddler, so why not treat them in the same fashion?

I would be very surprised, if Boeing was still able to self certify after the MAX8 debacle, but there's a non-trivial chance, that the certification of the MAX9 still comes from these old days of self-certification. However: a set of at least 4 loose bolts is not a design flaw (unlike the deeply flawed MCAS), much rather a sign of completely broken down manufacturing and quality control standards.

Are you really trying to make us believe, that a billion dollar business going on for over a decade comes about by "wash trading" and "scammy stable coins"? Is this really the best research into the matter you can come up with?

You may hate crypto for whatever reason (the bro culture, recklessness and carelessness of main players, "wen lambo" culture, the whole youtuber community of crypto peddlers, unmitigated scams running rampant, ....), but please at least come up with solid arguments against crypto currencies, not some unfounded immature garbage. You may end up discovering, that this field is not nearly as bleak as you try to paint it, and that a lot of bright minds actually come up with lots of very interesting new ideas and concepts with very real world applications for the technology. But yes, this would require a modicum of effort, quite a lot to ask for these days ...

Cry harder, could you?

Yes, current "security products" sometimes bring in weaknesses, which even a standard home router (at least one without remote access) would have handled better. Yes, this is a massive shame, but I see no immediate change in this industry, in fact I do not even see any pressure for change. For Solarwinds, Microsoft and Kaseya everything is business as usual, as if nothing ever happened. However, and this is where these lame "security product" vendors still shine compared to your average home router: they seem to acknowledge security lapses and actually provide updates to address the just discovered issues. More often than not these massive exploit sprees happen long after updated versions of these "security products" have been released. Equifax got hit by a security issue, which was known for two whole months by then.

If we look at security lapses, then we commonly see a combination of lameness: "platform security chips with buffer overflows", "endpoint security products with SQL injection", "network management software providers with lame passwords", "routers with hardcoded admin password", but also oblivious users and operators of these devices with no inclination to follow security news (and by that I don't mean black hat darknet sites, but standard tech info like slashdot, arstechnica, techradar or bleeping computer) and act on reported issues.

Yes, security is actual work, it requires regular maintenance (but no hax0r madsk1llz), especially if you want goodies like remote access or remote management. Even OpenBSD had remote root holes in the last two decades, so get prepared to regularly update your systems, and to consequently throw out and replace devices that have no support&upgrade options.

Yes, this is precisely what makes circuits for person safety a challenge, and it requires a vastly different mind set than the current culture in web services. BTDT.

Yes, one mitigating factor for public transport is, that most safety circuit's assumed threats are (randomly) faulty components (which I called "dumb opponents" before), whereas human hackers can be cunning and smart enough to simulate "normal operation" where operation is anything but normal and safe. We all observed this in action at the nuclear enrichment facility in Natanz (which were just a bunch of air gaped Windows computers driving centrifuges, so very very different from actual SIL 4 circuits).

Either way, these were super duper nation level hackers, not the random bozo scanning the web with Metasploit or SQLMap. I expect neither train operations, nor web services to withstand dedicated top nation level hacking attempts in the long run, but current affairs in web services are so far away from that, it feels like someone stepping on a chair discussing the challenges of climbing K2.

As I outlined, incentive to disrupt public transportation systems in at least two countries is enormous, the pressure is not even comparable to the bozos hurling month old exploits against web services (and succeeding!). If you think, trains in Europe and Russia run, because nobody bothers looking at them, then please go back to your "ultra large scale ASP.net project with five hundred version locked external components" and be happy.

It's too close to a holiday that I would explain you the difference between a forced safe shutdown and a full ransacking of a platform. Consider for a few minutes, whether we even had this discussion, had Equifax and Mr. Cooper just taken their services offline for an hour after a safety circuit determined unusual access to their DBs.

As I already described with my reference to Russia and Ukraine, there would be much more incentive to permanently disable each country's train system than all your "high value targets" (corporate web services), which you pretend to defend with your inadequate means, could ever offer to an intruder.

"Stopping the train" is considered the safe response to detected abnormal conditions, and that's apparently all which state level actors so far have been capable of. You can consider this as far apart from "full control of trains" as a DDoS would be away from remote root level access. Let's also not forget, that the two known affected train systems were Spanish and Belarussian, and that despite probably considerable and aggressive efforts neither Russian nor Ukrainian trains ever stopped during the last 2 years.

Will worse things happen? Sure! Some train control systems will eventually end up on AWS, and unplanned train stoppages will increase, I grant you that. That's still light years away from this Dodo crowd, which you try to sell me as "sensible and considerate practices" in the world of corporate web services.

Yes, sir, directly and personally and as a team lead. And if you had any real experience in this field, then you'd know, that a "stupid lock to keep corrupt nurses away from opioids", however important it may sound to you, is nothing like a safety circuit rated for public transport. The latter are circuits (plus firmware), for which you have actually prove beyond reasonable doubt, that they either perform their job perfectly, or reliably switch the system to a safe state. Certification for such circuits can take years and cost millions (for small and relatively simple systems). If potential sources of faulty behavior are identified, operations stop to a halt until the issue is verifiably remedied. If the responsible people toy with the system to render it unsafe (but e.g. more convenient to run), they face a world of legal pain.

Obviously nobody can develop&run a corporate web page in the same fashion as a railway switch, but maybe the former can learn a few things from the latter, especially if data entrusted to these web pages becomes more and more sensitive and voluminous:

"We can't update our just discovered unsafe brake assist system because the MCU depends on exactly this version" said no car make ever. "We'll disable the flaky safety system and run this thing by hand" said one Greek train operator, and caused a major accident. The court cases are still ongoing and will likely end with long prison sentences, unlike Equifax.

Yes, router software is written like corporate web pages, and of course they make regular headlines for anonymous remote root exploits. Same software culture leads to same outcome, no surprise here. Oh, in case you really didn't know this: a router is no safety circuit.

Did you actually read that article? It starts with explaining, that trains are an attractive target to nation level attackers. It gives a number of examples, where their web services were shredded/pilfered by random crooks, then a lot of could/should/would hand waving about operations. Then it gives two examples, in which trains have been stopped by attackers, which isn't nice, but well, "stopping the train" is the generally assumed safe response to a system anomaly, so nothing derailed, no one fell off a bridge. All that colorfully extrapolated "but they will" by an Erran Morad style ex spook.

Sorry, but that's nothing compared to the daily shit show of corporate web pages.

There is a big difference between most safety related circuits and public facing web services: safety circuits mostly shield against a "dumb opponent": faulty hardware, whereas web pages typically fall to "smart opponents": hackers. Anyone with moderate experience level in the field could trick a safety system into misbehaving all the way into major disaster, and the main reason this doesn't happen often is, that bad actors typically can't access these systems.

However, few of these massive data leaks were due to "ultra smart hackers chaining most puzzling zero days". Most were pwned through ancient and well known holes, often months after their discovery. There was really not much sophistication involved (compared to e.g. stuxnet or OPM hack) in their exploitation, brazenness and the protection by hostile governments were all that was required - and Dodo like targets.

Yes, health care commits their own share of blunders, but they actually pale in comparison to other industries. Looking at this wall of shame 2023, there is one health industry provider in the list, but that one got owned through an actual zero day, from which a long list of Dodos fell later on. While I am sure, that you must have seen odious stuff in health care, it just gives us a hint how much worse the others are. Time for cleanup maybe?

Sometimes I get the impression you intentionally twist my words to make them appear ridiculous, if that's the case: please stop. What I tried to express was, that an embedded OS is not inherently more secure than a server OS, quite to the contrary. The reason, why trains stay on track, while their ticket sales servers get pwned left and right, is not the choice of OS or embedded vs. server, but the overall software culture behind it, the risk awareness/management, and the urgency to address threats to system integrity.

Building a system, which controls train safety, is also hard. Building a reliable brake assist system or power steering is hard, too. Cry me a river! System safety or security is a fundamental design decision and a question of software development biotope, some have it (or at least: are expected to have it), and others don't seem to care much "what's that data worth anyway?" "all do it like this" "it would be hard to ...".

You can defend "established practices for large software systems" all day long. Once stricter fines and regulations appear, you will all either change pace or go the way of the Dodo, and the comparison with the Dodo is shockingly accurate for describing large corporate software culture right now.

Now you sound like the inexperienced noob. Chinese and Russian government hackers would be perfectly happy crashing western infrastructure. Russia does it a bit more subtly, poking here and there, taking a few data sets of high interest, but when China is on a rampage, they take everything. Chinese are deeply embedded in western infrastructure and will inflict massive damage if that furthers their agenda.

The real reason, why trains don't derail every holiday season is, that the systems responsible for their safe operation are built and run entirely differently from what you describe and defend as SOP in corporate web services. While you claim "no train derails if a ticket sales page is pwned", you ignore the fact, that some entities own data sets, which you really don't want to be on sale in the dark web (or elsewhere).

Embedded OS are certainly not immune, and it would be both silly and pointless to run a corporate web site off an embedded OS. It's not the embedded OS, which makes trains stay on track, though. It's the security culture in that industry, it's the "if security can not be guaranteed, the system won't start" mantra.

This high level of security and alertness may not be necessary for "show me your coolest photos" type pages, but as I showed you by example of Ashley Madison's data, a massive security lapse can actually cause loss of life. Hospitals affected by ransomware have also had additional complications, because their systems failed. Financial info falls somewhere in the middle, but given how frequently it gets pwned by bad actors, some screw tightening will come. Expect new "laws that govern liability for data losses and harm caused by cybersecurity errors, software vulnerabilities, and other risks created by software and digital technologies."

Sooner or later the "we couldn't update the system, because", "nobody ever got fired for choosing Microsoft", and the "we didn't verify the security practices of our component vendor, so" crowd will go silent, because they can't afford the fines and liability any longer. Good riddance!

This is not about writing everything yourself, no one does that. This is about responsible supply chain management, service level agreements for bug fixes, and well documented and established processed for updating vulnerable components which can sink the ship. That "data leak map" would look quite empty, if these measures eventually became industry standard. Yes, things would have to be run differently, but not necessarily at much higher cost.

As you can see, these ransomware attacks targeted the online resources offered by these companies. No train derailed because of the attack, no bus fell off a bridge. The web resources are typically run by people who follow your way of running systems, Windows everywhere, huge systems kludged together from hundreds of components offered by dozens of different vendors with no upgrade path, no system updates "because something could break", and yes, you just offered three more examples, where this kind of corporate reasoning leads us.

When I was talking about vehicle safety systems, I had those little invisible components in your car in mind, or those running the safety systems in public transportation. No, these can not be built like your corporate web pages, these actually have to work reliably at all times, and when they don't, like in Colonials pipeline case, it makes major headlines.

If cars have shitty door locks, it affects a few thousand folks every month. It's quite frustrating, and contrary to what you write, car makes actually get quite some flak, if they don't follow established security practices. Ask Hyundai about their "ultra smart" decision to offer the engine immobilizer only as an extra option, they were actually fined for that.

Your personal data may already be out there, but in the case of Equifax and Mr. Cooper the situation is somewhat different. These two hacks were, as far as we know, not just about names, addresses, phone numbers and SSN. Those hacks revealed very personal financial details, which should warrant a lot more protection than the average "register your hand mixer to get 6 months extended product warranty". Data sets such as those spilled by Equifax, Ashley Madison and Mr. Cooper can actually mess with your personal life, and "two years of credit monitoring" won't necessarily fix all aspects of this.

Since we likely agree, that over 14 million data sets were accessible to hackers, we can hopefully also agree, that the ratio of necessary data records vs. actually available data records is 1:3. That's a lot of extra data and a lot of extra associated risk and responsibility.

You can stash all the (real or perceived) requirements you want, and argue "it's impossible to keep such a system up to date", but what you really argue is this: such systems shouldn't exist in the way they do, because they seemingly can operate only in a very risky fashion.

There's a reason, why fail safe systems for public transport aren't just "somewhat locked down Windows or linux computers doing their thing". The only difference is that safety agencies effectively prevent makers of public transportation systems from releasing such follies, whereas as soon as it gets to millions of records of highly personal health and financial records, all mayor players seemingly agree, that they have to do reckless stuff anyway.

Systems and their components do have vulnerabilities all the time, even OpenBSD had at least two remote root holes in the last 20 years in their default install, and unpatched production systems will be exploited sooner or later.

If two months is just a "blip" for fixing a remotely and anonymously exploitable vulnerability, then you can't handle such data in a safe fashion, and your company shouldn't do it. If I physically broke into your compound and started stealing paper records, would you accept a police response after two months of pilfering?

You either willingly or unconsciously confuse a scheduled major version update with a bugfix release. If you are such a huge outfit with "millions of concurrent users", then you will (hopefully) have an SLA with all your software vendors, which covers acceptable response times to newly discovered holes, and hopefully also bugfix support for the precise version of the software you have running on your production systems. You do, yes? Yes????

And if that place you're trying to secure is a large depot for nuclear fuel rods, then "everyone is using high-security deadbolts from Home Depot" and "we know, that this security bolt can be easily circumvented, but the new bolt is back ordered for two months!" is not going to cut it. We all accept and embrace this fact for vehicle safety, nuclear safety, air transport safety, industrial machine safety, but as soon as it comes to highly sensitive personal data, we all treat it like a Lego Mindstorm control panel "Huh? Have you tried turning it off and on again?". Expect regulation sooner or later.

Lots of these poorly written DeFi smart contracts fail under extreme asset inflow, which changes asset prices in a chaotic fashion that can be exploited for personal gain. While on the surface this looks like a "normal trade with big profit", it can be also seen as market manipulation, which is quite illegal. That's how many DeFi exploiters end up in legal trouble.

It should be abundantly clear, that neither Mr. Cooper, nor Equifax supported "millions of concurrent users" at any time during their online presence. They were responsible for a remarkable treasure trove of data, but both mortgages and credit worthiness are not something the majority of their customers would check on a daily basis.

At the same time their products were not exactly marvels of technical sophistication. They chose to implement their web apps in such a way, that a rapid response to a novel security threat was more or less impossible, and like it or not: this is not going to work in the long run. We don't know yet, whether Mr. Cooper's data was just accessible, or whether these 14 million data sets have actually been drained, but at least the latter should have raised automated alarms fast enough to stop the service after just a tiny fraction.

If security is such a hassle, then it would be at least worthwhile to reduce the treasure offered to attackers. Why did Mr. Cooper have ALL data sets online and readily accessible? Why were even those of former customers there?

You presented the "you can't possibly update a complex system within 2 months, and anyone to claim otherwise is an inexperienced noob" thesis with such vigor and personal conviction, that it's hard for me to believe, that this is not your SOP. You can't ridicule me or my "impossible demands", claim that you can't run a large outfit without Microsoft at its core and their attitude towards security baked into everyone's soul, that rapid emergency updates are impossible with large projects, and then claim, that you take good care of large, sensitive data sets.

Thorough software tests and pen testers are nice but worthless, if gaping security holes under active exploitation remain unpatched for two months straight (Equifax). These tests are also worthless, if one of your core suppliers doesn't share this security consciousness (Solarwinds, Kaseya, Ipswitch, Microsoft) and is yet deemed irreplaceable by your management. That knowledge gained by testing and pen testing represents the current state of knowledge at the time the tests are done. That state of knowledge will change over time as new bugs are discovered, and if you can not respond to new threats in a very timely fashion, then your outfit will break in most inconvenient ways.

I generally don't work on Windows software, but trust me: I know how to write and run software. Look at my user ID, I am certainly not new to this field. Some of my software drives systems, that people's lives depend on. These 14 million data records involuntarily exposed by Mr. Cooper will not lead to immediate loss of life, but mess with enough people's data long enough, and the outcome will be quite dire in some situations.

BTW I did not claim, that it is easy to keep such a system updated and afloat, but that's exactly the responsibility you get into when you handle such personal data sets. If hackers are known to exploit your software setup all over the world, and if you can't update that component of your system within less than a day, then you're doing it wrong! Your system and your processes are broken by design, you are just waiting to be the next Mr. Cooper, and you should certainly not lecture other people about "how the big boys do it". There are some "big boys", who do it your way (shrug shoulders, "how could we possible update this?"), and people like you have made way too many headlines in the last 20+ years.

You are correct, we have little direct information about Mr. Cooper's failings and how much effort that company put in to avoid precisely that, but we have seen internals from Equifax and Solarwinds. Those internals were discussed at length here on slashdot and elsewhere, and the situation always unfolded the same way:

• Disclosure of hack and data theft, expressions of disbelief, that this could happen so such an honest and well organized outfit.

• The usual hogwash from CEO down, that this hack was absolutely unexpected and most inexplicable.

• The typical discovery, that the responsible company flaunted many common security protocols, traded security for cost savings and was basically a shipwreck waiting to happen at some point.

• Expression of shock and anger by the affected people, and some people coming out of the wood work "experienced people would know, that this is how software is run by professionals, don't criticize the poor victim company for their bad luck".

How much more actually has to happen until those companies change course?