2 ms·

When we talk to companies that are in the business of helping other companies that were hacked, the stories we hear are never that they were hacked by some 0-da

by uecker 2y ago

When we talk to companies that are in the business of helping other companies that were hacked, the stories we hear are never that they were hacked by some 0-day in the Linux kernel or a server software caused by some memory-safety issue. Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part.

lelanthran 2y ago
> Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part. Last I checked (a few months ago) 8 out of 10 breaches were due to human error. As far as reducing breaches go, you'll get more bang for your buck by ensuring employees are up to date on their routine security awareness training. Your employees are much much easier to hack than your computers. "Choice of language" is a blip in the stats.
adrianN 2y ago
> because some did not install updates of some component on the webserver But how many of those updates fix memory issues?
- galangalalgol 2y ago
  I guess his point is that these bugs get found and patches are available before most people have to worry about it, because people don't burn zero day exploits unless it is very likely to net them more than the price of a zero day. But the people who handle enough value that they are worth a zero day still often use the same kernel, so they have an interest in paying to secure it. And separately, the people willing to burn a zero day are likely to be more careful in maintaining their access undetected, sometimes inserting evidence ahead of an investigation to indicate a different compromise route to preserve their zero day and potentially their access. And even if we are finding all these UB vulnerabilities before they get used, that is a giant cost we don't have to pay in new projects of we start them with something like rust. The infamous learning curve isn't a thing of you are coming from modern c++. I have never come across someone coming from c++ that didn't take to it immediately. Modern c might be a different story but I doubt it. Rewriting things should be reserved for codebases that are small, high risk, producing lots of vulnerabilities, or some combination of those. Unless someone just wants to do it for fun.

by uecker 2y ago

lelanthran 2y ago

> Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part. Last I checked (a few months ago) 8 out of 10 breaches were due to human error. As far as reducing breaches go, you'll get more bang for your buck by ensuring employees are up to date on their routine security awareness training. Your employees are much much easier to hack than your computers. "Choice of language" is a blip in the stats.

adrianN 2y ago

> because some did not install updates of some component on the webserver But how many of those updates fix memory issues?

galangalalgol 2y ago
I guess his point is that these bugs get found and patches are available before most people have to worry about it, because people don't burn zero day exploits unless it is very likely to net them more than the price of a zero day. But the people who handle enough value that they are worth a zero day still often use the same kernel, so they have an interest in paying to secure it. And separately, the people willing to burn a zero day are likely to be more careful in maintaining their access undetected, sometimes inserting evidence ahead of an investigation to indicate a different compromise route to preserve their zero day and potentially their access. And even if we are finding all these UB vulnerabilities before they get used, that is a giant cost we don't have to pay in new projects of we start them with something like rust. The infamous learning curve isn't a thing of you are coming from modern c++. I have never come across someone coming from c++ that didn't take to it immediately. Modern c might be a different story but I doubt it. Rewriting things should be reserved for codebases that are small, high risk, producing lots of vulnerabilities, or some combination of those. Unless someone just wants to do it for fun.