3 ms·

IMO the first step to fixing is to add liability. If a breach happens through a piece of software, then the vendor is liable. Same way cars get recalls. (someti

IMO the first step to fixing is to add liability. If a breach happens through a piece of software, then the vendor is liable. Same way cars get recalls. (sometimes)

Txmm 5y ago
Really? I don’t think this is at all similar to a car safety recall. That’s more like trying to issue a recall for a car because people can smash it’s windows and break in.
- maerF0x0 5y ago
  yeah of course it's an analogy. But by adding liability we'll get more recalls (patches) done. Vendors will stop playing FUD and will focus on the real cost of their security flaws. And yes some will still not do patches, just like some car vendors are considered less trustworthy. But at least the risk of suit will loom over their heads.
  - tempestn 5y ago
    But the parent's point is that's still putting the liability on the vendor rather than the actual criminal. Perhaps it's more like if a car is sold without an immobilizer or an alarm, holding the manufacturer liable if it's stolen. But if that kind of fails, because it's pretty simple to mandate a handful of security additions to cars, whereas software is orders of magnitude more varied and complex. It would be hard for any vendor, let alone small companies, to prove they'd followed every conceivable best practice. Might even be impossible, as some likely conflict. And if you try to codify exactly what security practices should be followed, what do you do when those practices become obsolete?
    - maerF0x0 5y ago
      Yeah, I think it's just a fault in the analogy and in part demonstrating why reason from analogy is faulty. My point is this If vendors were liable (at least in part) for security faults in their products, then they would be more diligent about closing those gaps.
      - tempestn 5y ago
        Yeah, and in principle I agree. It's just tough to imagine how exactly you'd regulate that in practice without doing a lot of unintended harm along the way, especially to (potential) small vendors.
hnick 5y ago
Liable in what way? Wouldn't that just kill OSS? Or do you not count programmers who upload swiss-cheese scripts to Github as vendors? What about Linux, openSSH, etc?
- fabianhjr 5y ago
  OSS licenses include a very broad waiver, after all it is a gift provided as-is. Software that runs critical infrastructure (or could cause injury or death if it malfunctioned) should be required to use formal methods and that certainly would include everything to make it run also used such formal methods. (From the OS to shared libraries and even the compilers)
  - hnick 5y ago
    A lot of commercial software has similar waivers, too. See Windows 10. "Microsoft and the device manufacturer and installer exclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement." You'd have to outlaw that or breed a more discerning consumer. One way to do that would be to blame the company using it, which would make them take more care in what they choose to use. It just gets broad and vague after a point. Can the software that schedules trains use Linux or MySQL? People could die if it puts two trains on the same track. Note that GP never mentioned safety either. Just being hacked. But yes I'd hope that anything bespoke should be covered under a contractual agreement with SLAs and penalties.
    - Symbiote 5y ago
      Signaling is where this is done right. The software that schedules trains can do what it likes, because there are several, independent safety layers below it: the signaling system itself, and the software and hardware locks within the signaling system, and formal methods usedto prove their integrity. Any signaling failure will fail safe (all trains stop). Any trusted actor (controller, train driver, sometimes passengers etc) can also stop part or all of the system. (On many European railways, if the driver sees a problem, like a car crashed into the railway, they press a red button and all trains in that region are halted.)

IMO the first step to fixing is to add liability. If a breach happens through a piece of software, then the vendor is liable. Same way cars get recalls. (sometimes)

Txmm 5y ago

Really? I don’t think this is at all similar to a car safety recall. That’s more like trying to issue a recall for a car because people can smash it’s windows and break in.

maerF0x0 5y ago
yeah of course it's an analogy. But by adding liability we'll get more recalls (patches) done. Vendors will stop playing FUD and will focus on the real cost of their security flaws. And yes some will still not do patches, just like some car vendors are considered less trustworthy. But at least the risk of suit will loom over their heads.
- tempestn 5y ago
  But the parent's point is that's still putting the liability on the vendor rather than the actual criminal. Perhaps it's more like if a car is sold without an immobilizer or an alarm, holding the manufacturer liable if it's stolen. But if that kind of fails, because it's pretty simple to mandate a handful of security additions to cars, whereas software is orders of magnitude more varied and complex. It would be hard for any vendor, let alone small companies, to prove they'd followed every conceivable best practice. Might even be impossible, as some likely conflict. And if you try to codify exactly what security practices should be followed, what do you do when those practices become obsolete?
  - maerF0x0 5y ago
    Yeah, I think it's just a fault in the analogy and in part demonstrating why reason from analogy is faulty. My point is this If vendors were liable (at least in part) for security faults in their products, then they would be more diligent about closing those gaps.
    - tempestn 5y ago
      Yeah, and in principle I agree. It's just tough to imagine how exactly you'd regulate that in practice without doing a lot of unintended harm along the way, especially to (potential) small vendors.

hnick 5y ago

Liable in what way? Wouldn't that just kill OSS? Or do you not count programmers who upload swiss-cheese scripts to Github as vendors? What about Linux, openSSH, etc?

fabianhjr 5y ago
OSS licenses include a very broad waiver, after all it is a gift provided as-is. Software that runs critical infrastructure (or could cause injury or death if it malfunctioned) should be required to use formal methods and that certainly would include everything to make it run also used such formal methods. (From the OS to shared libraries and even the compilers)
- hnick 5y ago
  A lot of commercial software has similar waivers, too. See Windows 10. "Microsoft and the device manufacturer and installer exclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement." You'd have to outlaw that or breed a more discerning consumer. One way to do that would be to blame the company using it, which would make them take more care in what they choose to use. It just gets broad and vague after a point. Can the software that schedules trains use Linux or MySQL? People could die if it puts two trains on the same track. Note that GP never mentioned safety either. Just being hacked. But yes I'd hope that anything bespoke should be covered under a contractual agreement with SLAs and penalties.
  - Symbiote 5y ago
    Signaling is where this is done right. The software that schedules trains can do what it likes, because there are several, independent safety layers below it: the signaling system itself, and the software and hardware locks within the signaling system, and formal methods usedto prove their integrity. Any signaling failure will fail safe (all trains stop). Any trusted actor (controller, train driver, sometimes passengers etc) can also stop part or all of the system. (On many European railways, if the driver sees a problem, like a car crashed into the railway, they press a red button and all trains in that region are halted.)