16 ms·

I think comparing an activity that can result in loss of life to one that doesn't is probably on the dishonest side.

by PH95VuimJjqBqy 3y ago

baydarr 3y ago
What language is used to control critical devices like pacemakers?
- r9295 3y ago
  Or fly airplanes for that matter
- PH95VuimJjqBqy 3y ago
  then make different decisions for those devices. That was actually the point being made.
pjmlp 3y ago
Our lives and livelyhood depend on software on any modern society. Additionally people have died due to software bugs, Therac-25 being quite famous, with its Assembly optimization tricks.
- PH95VuimJjqBqy 3y ago
  a plumbers livelihood depends on his tools but no one in their right mind would compare a hammer to a seatbelt like this. The reason people like you are not listened to is that you're so unreasonable. It's not an accident that ada was designed years ago for software that IS critical in this manner, because different decisions get made. But the vast majority of software is not going to end up with people dead, hence why arguments comparing life-or-death situations with your run-of-the-mill C code is assinine. Yes, it's true that GCC code will never live under the same level of scrutiny as NASA code, nor should it.
SenAnder 3y ago
Hospitals in at least 4 states diverting patients from emergency rooms after ransomware attack - https://www.usatoday.com/story/news/nation/2023/11/28/ardent-health-hospital-cyber-attack-ransomware/71726309007/ https://www.usatoday.com/story/news/nation/2023/11/28/ardent... Moreover, it is untenable to maintain a small island of "secure software" for "important things" in a vast ocean of careless and vulnerable code. Inevitably, the island gets infected, and not even air-gaps can save it, as stuxnet showed.
- PH95VuimJjqBqy 3y ago
  I wouldn't let you near security decisions, ever. If anything, this attitude is very representative of what's wrong with "security" nowadays. This idea that all code must be treated equally wrt security is why security people are oddly never effective.
- trealira 3y ago
  > Moreover, it is untenable to maintain a small island of "secure software" for "important things" in a vast ocean of careless and vulnerable code. Inevitably, the island gets infected, and not even air-gaps can save it, as stuxnet showed. Why is it inevitable? As long as it doesn't connect to other software (via internet or other means), isn't it possible to formally verify one critical software component, e.g. in pacemakers? I'm not saying that C would necessarily be the best choice for formally verifying it, though.
  - PH95VuimJjqBqy 3y ago
    more than that, you only have so much time and money, concentrating on more important pieces allows you to be more thorough where the highest impacts are. perfect is the enemy of good, "security" people act as if all breaches are equally relevant. When your surface area is everything you're more likely to have holes, that's just a law of nature. Limit your surface area and suddenly you can be more thorough.
  - SenAnder 3y ago
    Formally verifying does no good if the compiler is infected. In the stuxnet example, formal verification wouldn't even help - how do you formally verify centrifuge timings? Unlike what your sibling comment claims, I'm not saying all software is equally important, or must have equal effort invested in securing it. But insecurity absolutely is infectious, and the more insecure the general environment is, the harder it is to secure a small part of it. For example, you'll want a compiler. How secure is the web stack of the page that delivers your gcc/clang? How secure is its host's infrastructure, and of the DNS provider? The browser you're downloading it with? Did you ever visit any other page that might have compromised it? What about your text editor, your OS, the SDK you're using to flash code onto the pacemaker.. And all of them have vast supply-chain networks.

I think comparing an activity that can result in loss of life to one that doesn't is probably on the dishonest side.

baydarr 3y ago

What language is used to control critical devices like pacemakers?

r9295 3y ago
Or fly airplanes for that matter
PH95VuimJjqBqy 3y ago
then make different decisions for those devices. That was actually the point being made.

pjmlp 3y ago

Our lives and livelyhood depend on software on any modern society. Additionally people have died due to software bugs, Therac-25 being quite famous, with its Assembly optimization tricks.

PH95VuimJjqBqy 3y ago
a plumbers livelihood depends on his tools but no one in their right mind would compare a hammer to a seatbelt like this. The reason people like you are not listened to is that you're so unreasonable. It's not an accident that ada was designed years ago for software that IS critical in this manner, because different decisions get made. But the vast majority of software is not going to end up with people dead, hence why arguments comparing life-or-death situations with your run-of-the-mill C code is assinine. Yes, it's true that GCC code will never live under the same level of scrutiny as NASA code, nor should it.

SenAnder 3y ago

Hospitals in at least 4 states diverting patients from emergency rooms after ransomware attack - https://www.usatoday.com/story/news/nation/2023/11/28/ardent-health-hospital-cyber-attack-ransomware/71726309007/ https://www.usatoday.com/story/news/nation/2023/11/28/ardent... Moreover, it is untenable to maintain a small island of "secure software" for "important things" in a vast ocean of careless and vulnerable code. Inevitably, the island gets infected, and not even air-gaps can save it, as stuxnet showed.

PH95VuimJjqBqy 3y ago
I wouldn't let you near security decisions, ever. If anything, this attitude is very representative of what's wrong with "security" nowadays. This idea that all code must be treated equally wrt security is why security people are oddly never effective.
trealira 3y ago
> Moreover, it is untenable to maintain a small island of "secure software" for "important things" in a vast ocean of careless and vulnerable code. Inevitably, the island gets infected, and not even air-gaps can save it, as stuxnet showed. Why is it inevitable? As long as it doesn't connect to other software (via internet or other means), isn't it possible to formally verify one critical software component, e.g. in pacemakers? I'm not saying that C would necessarily be the best choice for formally verifying it, though.
- PH95VuimJjqBqy 3y ago
  more than that, you only have so much time and money, concentrating on more important pieces allows you to be more thorough where the highest impacts are. perfect is the enemy of good, "security" people act as if all breaches are equally relevant. When your surface area is everything you're more likely to have holes, that's just a law of nature. Limit your surface area and suddenly you can be more thorough.
- SenAnder 3y ago
  Formally verifying does no good if the compiler is infected. In the stuxnet example, formal verification wouldn't even help - how do you formally verify centrifuge timings? Unlike what your sibling comment claims, I'm not saying all software is equally important, or must have equal effort invested in securing it. But insecurity absolutely is infectious, and the more insecure the general environment is, the harder it is to secure a small part of it. For example, you'll want a compiler. How secure is the web stack of the page that delivers your gcc/clang? How secure is its host's infrastructure, and of the DNS provider? The browser you're downloading it with? Did you ever visit any other page that might have compromised it? What about your text editor, your OS, the SDK you're using to flash code onto the pacemaker.. And all of them have vast supply-chain networks.