https://www.theinformation.com/articles/companies-are-ditchi...
but the OP's arguments also apply to insurance, yet businesses buy insurance every day. The difference is the fines and liability for data breaches are so paltry it is the rational thing to do not to invest in security. This can only change through legislative action. I wouldn't hold my breath.
This is exactly why the CrowdStrike disaster happened: https://news.ycombinator.com/item?id=41011065
If we could replace things like SSNs, passport numbers, credit card numbers, etc. with org-specific tokens/certificates, they'd be largely useless to anyone else.
Sadly, no one cares enough about security to fix the problem though, not even governments.
In most places worldwide identifiers equivalent to SSNs and passport numbers aren't really treated as financial secrets; they may not be totally public due to certain privacy aspects, but they generally don't result in financial identity theft, that's a fixable problem of certain regions (like USA and a few others). Similarly, moving to proper credit card authentication (chip&pin or wireless chip when card is present, 3dsecure when not, etc) has made many credit card numbers mostly useless for thieves unless accompanied by a more serious compromise.
But all these things above have been implemented only because (and where, and when) the actual companies became financially liable for the consequences - as long as the losses/fraud/etc hit only the users/consumers, there is no motivation to fix anything. Shift the liability to the company which accepts that fundamentally insecure data as good enough, and they'll figure out some way to implement a secure process.
The liability shift that I had in mind is mostly about immunity from liability for the impersonated person, like, if some criminal defrauds a company by claiming to be Bob, then shifting the liability for that risk (compared to currently common cases in USA) to that company which had lax processes and was defrauded would be various consumer protection mechanisms for things like credit score, preventing that company from trying to collect that money from Bob, preventing them from reporting that Bob owes them money (as he doesn't) and requiring that company to correct any adverse credit reports if they had already made them, etc, various means to ensure that the fraud stays between the fraudster and the defrauded company and doesn't affect the person whose identity was falsely used; and removing the implication that they are somehow responsible if that information (which they aren't legally required to keep secret) is used by someone else.
In the banking sector, you can still, to this day, try to get away with stealing money by forging a paper check and hoping the bank honors it. And they may let you walk away with the cash! What protects the system is that when the fraud is detected via auditing and resolution, actual law enforcement will come find you.
The early web never had such legal protections ("Wikipedia's database was hacked? What even is a wikipedia? They got their facts disrupted? What does that mean?"), so they were forced to grow infrastructural protections or be consumed by attackers. But there's a case to be made that the costs inherent with hardening infrastructure like that are unnecessary to bear when the law will actually show up to stop the criminals messing with your infrastructure. It's counter-intuitive for those of us raised on the "You can only rely on yourself; everyone else is a potential attacker" side of the fence, but it's a way to be.
I think these are the main problems and why it's hard to tackle. I think they can help prevent issues but I'd like to hear other suggestions:
1) You can't measure maintenance or security benefits the same way as you can measure costs of failures. You can measure the cost it takes to implement, but when you do you can't measure the counterfactual cost of if you hadn't. It's not actualized. But I'm confident maintenance is always cheaper than repairs. Don't fix things that aren't broken, but do fix things before they break. We need to learn the difference.
2) the world is complex and many costs are outsourced and distributed. I like to think of this like the inverse software success. Software is great because once made you can copy it trivialy and distribute it. But the down side is the mistakes propagate too! So something that may only cause a second delay is seen as miniscule but it's not when you consider a hundred million users using it every day. Enshitification is about these little things adding up and accumulating.
3) we avoid slack like the plague. I don't mean slacking off, but slack in the system. You don't make a ship and only have enough lifeboats for exactly the number of passengers. You need more because you can't assume everyone perfectly makes it to the right life boat, especially in an emergency. Covid should have been a real wakeup call but the global economy shouldn't shut down anytime a single ship gets stuck.
4) doing good and quality work has the stability of an inverse pendulum. Most evil and shit isn't caused by malice, it's that it's harder to do good and with longer and more complex tasks it's easier for something to go wrong along the way which then snowballs.
So a big belief I have is trust we need to slow down if we want to speed up. Move fast and best things is great when problem solving but you need to also also go back and clean up all the mess you've left behind. We've become so accustomed to technical debt we aren't even recognizing how much we have.
We can't be just focused on the next quarter. We're in a much more complex world. Even early humans had to plan for winter. I know what I'm asking for is difficult but nothing worth doing is usually easy. All of us have done hard things and continue to do hard things. But importantly, try not to distribute and amplify mistakes. Squash them when they're small. Don't ask for permission, just fix things.
What's the problem with self-signed certificates? Did they not know each other?
Especially for internal server-to-server connections there shouldn't be any security weaknesses in a fully self-signed architecture where the same scripts that deploy the certificates will also deploy the configuration on other servers specifying that this is the only thing that should be trusted.
At another company in 2015, I discovered we were sending user credentials for a large hospitals in plain text across the network and need to fix this ASAP. When I brought this up to management, they shrugged and said "it's been this way for years and we have other priorities". After a large New York hospital was breached, I suddenly had management show up to my desk in panic asking how we can fix the issue immediately. I came up with a nice write-up for both our company and the hospital IT groups on how to secure our infrastructure with certs and whatnot and they still half-assed it with self-signed certificates.
In 2018 I worked for a fin-tech company in charge of some A-list celebrity 401K portfolios. We had a default admin password for our production database. ZERO encryption on the data; including SSN, birth-date, phone numbers, addresses, beneficiaries info, etc.
Last year one of the leading payroll providers in the country (USA) I used to work for started aggressively out-sourcing the software and allegedly had a really nasty security breach due to a back-door inserted by one of the out-sourced team members. It's alleged that leadership threatened employees if they disclosed the incident to anyone outside a key group of members.
Nobody give a damn about security until their identity is stolen and they have to spend hours/days/weeks/months putting their lives back together from the fallout.