I'm not saying we can be invulnerable but we need to raise the lowest common denominator so that it's not a walk in the park to steal millions of records. You just need the weakest link to make everyone vulnerable but I do think positive collective behavior can counter that -- especially when you make it easy with things like Let's Encrypt.
I dont think you have quite thought it through. Do you honestly want to have to do code audit on all libraries you use? Freeze all versions? Have a chain of signoffs for every change?
I have briefly done consulting in a place like that -- developers were absolutely miserable. Think about every single corporate IT policy that exists and apply it not just to your desktop/laptop/phone but to what you do on that desktop/laptop/phone.
Security is about management of risk.
If developers demand that the tools they use are better built, then the market will deliver tools/frameworks/etc... that are secure from the start.
"Good" coding has become "good enough" coding, and the problem exists from the bottom of the stack to the top.
This is never going to happen because what is considered secure in one place is not considered secure in another place.
> "Good" coding has become "good enough" coding, and the problem exists from the bottom of the stack to the top.
Because it is about risk management, not about absolutes. It is absolutely irrelevant that a smart samsung TV that I have in my office has garbage security because it is used as one thing and one thing only - dumb 48" HDMI monitor not connected to wireless network. Its Wifi antenna connector has been cut. It matches my risk profile.
I'm going to repeat it again - we do not have a security problem with software. We have a risk management problem.
There's absolutely no reason for Marriott store information on previous guests past certain statue of limitations. In fact, they could probably offloaded it to Iron Mountain after 180 days. Storing it online has a certain risk profile. That risk was not correctly evaluated ( probably not evaluated at all ) and hence it was not minimized.
Storing credit card information ( even encrypted ) after the card was charged and transaction creates another risk profile. It also was not evaluated and it was not mitigated.
Businesses are obsessed with data without understanding the risk.
Most professions and companies are (at least in theory) held accountable for their impacts.
There are a lot of really stupid mistakes made in a lot of these data disclosures that a competent IT team (and dev team) can prevent from happening. The current state of things is that there are hardly any consequences for losing people's data, just make a bulk purchase of credit monitoring and call it a day. This is cheaper than actually hiring the right people and implementing the correct processes.
To stretch the car/driver analogy, you could limit all cars to 10 mph so that they can stop fast enough when a deer runs into the road unexpectedly, but that's probably not worth the tradeoff.
Pedestrians, on the other hand, are a predictable fact of life that you need to deal with when you get in a car. So are bad people on the internet. If you put something on an internet connection and aren't constantly aware of that, you should not be putting it on the internet.
Right, which is why we should increase consequences when there are data breaches so companies may actually care about them when they happen.
Why do you think customers are ready to pay extra for the extra data security?
I really wish more developers had at least a basic ethical grounding and didn't just go "fuckit, revenue!". (Or, in larger companies, "fuckit, my boss told me")
And when you consider opportunity cost - even just double-checking you aren't affected takes a minute of time, as a consumer, that means this hack just wasted close to a thousand years of human life.
Where's the accounting for the opportunity cost of that?
If basic ethical grounding requires security to be the top priority, and security work is inexhaustible, then it must be unethical to ever work on the product being secured.
An ethical approach requires you to reason about which actions are moral, not to be "done" with something. As I said, even a basic knowledge would be really helpful.
If basic ethical grounding requires safety to be the top priority, and safety work is inexhaustible, then it must be unethical to ever work on the product being safe.
In other words, this is an irrelevant nit that serves no purpose except derailment.
Does such a world even make economic sense after accounting for the opportunity cost of the time most that building designers would otherwise spend actually building funky new shapes?
Investing in solutions that assume buildings will collapse seems reasonable to me.
Sql injection is bad but not "a bridge with 50 cars collapsed over a city" bad
1) There are 150 million vehicles which can be remotely controlled via the vehicle manufacturer's software, which has generally mediocre application security.
2) The software in question is vulnerable to SQL injection, allowing up to 150 million vehicles to be remotely commandeered by a small group of attackers.
3) No hostages are taken and no owners of cars are deliberately harmed, because this is an application security scenario and not a kidnapping scenario (which is orthogonal).
The scenario you've posed is oddly florid...thinking through it, no, I don't think the robbery of 150 million vehicles is as serious as a bridge collapse with 50 (presumably occupied) vehicles on it.
Speaking more directly to the point - I think this is a really poor comparison. Logistically speaking it's hard to take seriously the idea that 150 million cars would actually be stolen because of any single SQL injection vulnerability. SQL injection is really bad, but it doesn't directly result in injury or loss of life. It's also hard to conceive of a situation in which SQL injection has the potential to cause systemic collapse like you're describing...maybe SQL injection to a database containing credentials that have write access to a server which can launch ICBMs?
In the modal case, I think it's okay to admit that application security is not as serious a concern as architectural stability. But this entire discussion is pretty much a sideshow; we can just all agree that security needs to be taken seriously and that some bureaucratic scar tissue is okay to make that happen.
In any case, the damage to Iran from the hack was not as significant as building collapse.
The situation is identical to you wanting to have an untamed lion in your back yard. Provided you have the right security in place to ensure it can't hurt me, your neighbor, then the litter box is your problem. If however you do not have the right protections in place, then I have every right to ensure the lion is removed from the neighborhood.
If you don't store valuable data, you won't have large premiums.
If your business model requires storing such data, you better have the revenue to pay the premiums.
I can see a time that software developers (leads at least) will need to be chartered just like someone that designers a bridge.
While companies could probably do better than they are right now, hacks like this are probably never going to be eliminated. There are too many companies and too many developers for nobody to make mistakes, even when they're being mindful not to. Investing in solutions that assume hacks will happen seems reasonable to me.