4 ms·

Are you worried that a medical device manufacturer will intentionally replace certified software with known uncertified software? That would be shockingly stup

by Veserv 3y ago

Are you worried that a medical device manufacturer will intentionally replace certified software with known uncertified software? That would be shockingly stupid. There is exactly zero plausible deniability if they did that. That is “slam-dunk go directly to jail and get fined billions” stupid. There is exactly zero reason to worry about that at all at the device manufacturer level (component suppliers might lie which transitively affects the final product, but that should be handled when identifying the target of evaluation). If they want to be evil, there are plenty of ways that do not require them to put their evil in legally binding writing. If you are concerned about a hack or accidental deployment, that is a real concern, but image integrity, secure boot, and secure update are really part of the certified process/product.

transpute 3y ago
> Are you worried that a medical device manufacturer will intentionally replace certified software with known uncertified software? Only that certified source code and software binaries can be continuously evaluated after production shipment, as original developers and certifiers move onto other projects. See the "Right to Repair" movement. Over timeframes of multiple years, we learn more about stacks of hardware, software and threats, as can be observed in the constant stream of CVEs for CPU microcode, firmware, operating systems and application code.
- Veserv 3y ago
  That is just standard compulsory defect remediation. Like the hardware components they should be required to monitor and remediate any and all newly discovered defects in any components and the product. Again, this is something they already have to do for the physical components and which is done in literally every other industry to great effect. It is just not done for the software for some bone-headed reason. Note that failure to remediate known defects in components or covering it up is a very serious offense in basically every regulatory regime. That is basically “the thing” that gets you in trouble. Those standards should probably be made stricter, but that is for another time. Just getting software to “industry standard” is a major win.
  - transpute 3y ago
    > standards should probably be made stricter What do you think of the EU CRA requirements for critical software?
    - Veserv 3y ago
      I only know about it broadly, but in terms of what I have read about it, it is almost reasonable except that it overly encumbers FOSS and non-commercial software. Liability should lay with the provider of the final product to use components fit for purpose, not with the component providers to make their component fit for every possible purpose. This is how it works on every other industry. Airplane manufacturers must use airplane-grade screws; they do not get to demand that every screw in Home Depot be fit for airplanes. If a company wants to use a FOSS library then they must make sure it fits their standards, or they must fund development and verification to make it meet their required standards. They do not get to unilaterally demand the library authors work harder to line their own pockets.

by Veserv 3y ago

transpute 3y ago

> Are you worried that a medical device manufacturer will intentionally replace certified software with known uncertified software? Only that certified source code and software binaries can be continuously evaluated after production shipment, as original developers and certifiers move onto other projects. See the "Right to Repair" movement. Over timeframes of multiple years, we learn more about stacks of hardware, software and threats, as can be observed in the constant stream of CVEs for CPU microcode, firmware, operating systems and application code.

Veserv 3y ago
That is just standard compulsory defect remediation. Like the hardware components they should be required to monitor and remediate any and all newly discovered defects in any components and the product. Again, this is something they already have to do for the physical components and which is done in literally every other industry to great effect. It is just not done for the software for some bone-headed reason. Note that failure to remediate known defects in components or covering it up is a very serious offense in basically every regulatory regime. That is basically “the thing” that gets you in trouble. Those standards should probably be made stricter, but that is for another time. Just getting software to “industry standard” is a major win.
- transpute 3y ago
  > standards should probably be made stricter What do you think of the EU CRA requirements for critical software?
  - Veserv 3y ago
    I only know about it broadly, but in terms of what I have read about it, it is almost reasonable except that it overly encumbers FOSS and non-commercial software. Liability should lay with the provider of the final product to use components fit for purpose, not with the component providers to make their component fit for every possible purpose. This is how it works on every other industry. Airplane manufacturers must use airplane-grade screws; they do not get to demand that every screw in Home Depot be fit for airplanes. If a company wants to use a FOSS library then they must make sure it fits their standards, or they must fund development and verification to make it meet their required standards. They do not get to unilaterally demand the library authors work harder to line their own pockets.