The Internet Is Burning
techcrunch.com
techcrunch.com
The fact of the matter is that security is hard. Balancing security with usability with speed of development with ROI is a tricky proposition. Cisco has a fundamental need to write high-security code because what they are selling is highly-secure infrastructure. That same need doesn't exist for other entities, and it shouldn't exist, because that security comes at financial and usability costs, at the least. That isn't to say that software developers shouldn't employ best practices and strive for secure code, but security is not a boolean, and it seems somewhat naive to equate "many people write imperfectly secure code" with "nobody cares about security".
There's a middle ground between security being a "debacle" and it always being a persistent threat. Bugs exist - and will always exist. You can spend lots and lots of money making sure that fewer bugs exist in your code, and you can spend lots and lots of money writing in-house code or auditing external code, but unless there is economic incentive to do so ("a security breach in our difficult-to-update firmware will leave our company devastated"), spending those resources makes very little sense. Additionally, all it takes is one bug to bring your massively expensive hyper-engineered software to its knees, as we saw in the Cisco case.
Security is always not about writing perfectly-engineered, hyper-secure code. It's about tradeoffs between financial resources and usability, and it's about mitigation of potential damage. If you write code predicated on "this is so well written that it can never be broken", you're in for a bad time.
Things were much less complex back then but the security was far worse on the whole than it is today. People would just telnet around! In plaintext! On local networks that were largely switch-free with ethernet adapters that would gladly go into promiscuous listening mode. Not to mention things like full-blown IP spoofing before ingress/egress filtering was common and all the TCP stacks had terribly predictable sequencing.
The important things that changed are as you said that dramatically greater number of people are impacted by these issues, and to a lesser degree the people hacking into systems back then on average were less likely to have any malicious intent or financial motives (the change with this is somewhat directly related to the first point).
One big problem, though, is that governments are buying zero-days. Why tolerate that, and the people making zero-days? They should be treated like bioterrorists making enhanced ebola virus.
That is the silliest thing I've heard on hackernews in a while. Criminalizing disclosure of security flaws would make everything MUCH less secure. Security flaws would still be found by unscrupulous individuals, it's just that the users and creators of the flawed software wouldn't know about them.
I made no such suggestion, much less proposal. The problem is commercial, militarized development of zero-day exploits and selling to the highest bidder.
UNLIKE responsible disclosure by legitimate security researchers, weaponized exploits are very analogous to the freelance development of bioweapons and then auctioning them off to the highest bidder. It is a cancer on computing, and deserves to be stamped out, as such a bioweapons development would get wiped out quickly and conclusively.
It isn't all that different than the 'real world' where if someone decides to target you in meatspace there isn't a lot you can do (except perhaps arm yourself and the outcome of that is dubious at best). I'm all in favor of building a more secure network though. We could even use the pipes that are there, definitely going to start small though.
When did it become appropriate to diss open source software without the expertise to create something better, and why does he think this is brag-worthy?
It's almost like fashion.
I know cancer is bad, even though I lack the expertise to treat it. I know house fires are bad, even though I lack the expertise to put them out.
You don't need to be an expert on some piece of software to see that it's bad. You only need to be an expert if you're actually trying to implement it.