3 ms·
Safety-critical systems and secure systems are completely orthogonal. Although the article makes a good point, I don't think it was very sensible to use the exp
by pnako 7y ago
Safety-critical systems and secure systems are completely orthogonal. Although the article makes a good point, I don't think it was very sensible to use the expression "safety-critical software", for this reason.
In a safety-critical system (which might include software), you are trying to protect yourself against mother nature. Which is tricky but doable, because we can predict it. Generally, the security assessment is minimal because the system is assumed to be "behind the firewall": in a secure cabinet in a plane, in an access-controlled building or factory, etc.
Of course, all hell breaks loose the day someone decides to connect that system to the Internet, where thousands of smart humans with bad intentions try to break it.
I think the author would have helped his point better if he simply talked about secure software, not safety-critical software.
- killjoywashere 7y ago> Safety-critical systems and secure systems are completely orthogonal This strikes me as the most true statement in this conversation. I feel like I need this as a bumper sticker. I think a significant issue in this space is figuring out how to get the security people to put as much skin in the game as the safety-critical people have. The security people often get to continue paying their mortgage as long as they say "no". And as a physician leading a development team, I really struggle with this. If the budgets need to go up to solve the compliance problems, that's fine, but the compliance people seem to always have one more tissue-thin layer of requirements to add. It's like trying to drill your way out of a growing onion.
- tptacek 7y agoCompliance people and software security people aren't the same people. Software security people aren't generally in the business of saying "no"; they start with the requirements of the system, established elsewhere, and try to ensure that the implementation of those requirements doesn't cough up calc.exe.
- killjoywashere 7y agoPoor control of nouns on my part, fair enough. I'm happy to hire SWEs with an interest in secure systems. But how do I move the compliance piece away from static pre-defined standards and toward something that supports a devops development paradigm? What's the mutually agreed trust-but-verify layer? Testing? And how do you get that "MVP" out the door in that case?
- irundebian 7y agoSaying "no" because of compliance requirements is imho pretty similar to saying "no" because a software bug was revealed. Both don't help much in building secure systems. At least with certain compliance requirements you can focus on avoiding certain bad practices or bug classes while with finding some bugs, in most times, you can't be sure you have found all relevant bugs. Ideally bug hunting acts as a validation of compliance requirements, to check that these are fulfilling their overall goal, and to improve them, if not.