6 ms·

Basically the argument, as I see it, the feds are demanding a liability regime, as software producers shouldn't be able to disclaim all liability for the softwa

Basically the argument, as I see it, the feds are demanding a liability regime, as software producers shouldn't be able to disclaim all liability for the software they sell, and the courts are better situated than regulatory agencies to decide liability questions. However, we don't have the time to let a software liability common law regime develop over decades, given the threat presented now. Therefore we should adopt the products liability, design defect analysis, which he explains as: In fact, it turns on two reasonableness inquiries: Was there a “reasonable” alternative design that the manufacturer could have used to avoid the vulnerability, and, without that alternative, was the actual design used “unreasonably dangerous”? Imagine asking the question -- are there reasonable alternative designs for OpenSSL? For C and C++? For Linux? Re: OpenSSL and C and C++ memory vulnerabilities, I'd say maybe, see: Rust and rustls! Re: Linux, I would have to say no. Is there an alternative which doesn't have the same issues? Not really. The author's summary liability regime, in light of the NIST guidance, would be as follows: 1. A rules-based approach would define a floor—the minimum legal standard of care for software—focused on specific product features or behaviors to be included or avoided. 2. However, a list of known coding weaknesses cannot suffice alone. Software is so complex and dynamic that a liability regime also needs to cover design flaws that are not so easily boiled down. For these, I propose a standard based on the defects analysis common to products liability law. 3. But this liability should not be unlimited or unpredictable. As the Biden administration’s National Cybersecurity Strategy recognizes, developers deserve a safe harbor that shields them from liability for hard-to-detect flaws above the floor. For that, I would turn to a set of robust coding practices.

alilleybrinker 3y ago
I think this reading is _mostly_ right. To make it a little clearer: 1. A rules-based approach to define a minimum standard, likely based around existing descriptions of software weaknesses where the rules basically say "you aren't allowed to have this type of software weakness" (the doc specifically gives path traversal as an example). HOWEVER, liability would only be established if a weakness is actually exploited, to help avoid the problem of people proactively scanning for weaknesses and then troll-suing as a way to make money. 2. A process-based safe harbor to avoid liability for exploitation of weaknesses NOT on the rules-based "no no list." Basically, if you can show you followed the safe harbor process requirements, you get the benefit of the safe harbor. This is to protect and encourage organizations to go above and beyond the floor established by the rules-based standard.
- mustache_kimono 3y ago
  > HOWEVER, liability would only be established if a weakness is actually exploited, to help avoid the problem of people proactively scanning for weaknesses and then troll-suing as a way to make money. Agreed. Torts require damages.
  - alilleybrinker 3y ago
    Yeah, the doc acknowledges this concept is "drawing on tort law principles." In this case the author, Jim Dempsey, is proposing a rules-based framework for establishing a floor regardless of what underlying system is used (warranty, torts, etc.). So he's not _inherently_ assuming a tort law framing, and is instead making a recommendation for how it should operate regardless of whether the resulting system is based around tort law.
    - mustache_kimono 3y ago
      > So he's not _inherently_ assuming a tort law framing, and is instead making a recommendation for how it should operate regardless of whether the resulting system is based around tort law. Not to get too in the weeds, but breaches of implied warranties were once/began as torts. But, yes, I guess I was a little glib. I should have said -- it would be sensible to require damages for these types of actions. Although I'm not sure I agree with the author's formulation: > HOWEVER, liability would only be established if a weakness is actually exploited, to help avoid the problem of people proactively scanning for weaknesses and then troll-suing as a way to make money. I think we should encourage customers to look for vulnerabilities. Damages analyses can take into account depreciation, reasonableness of damages/troll suing, etc. If you have 100s of devices you must replace because the vendor won't patch, and your patch request is reasonable (high consequence vulnerability) within 5 years of purchase, I think damages accounting for depreciation make sense, without proof of exploitation. EDIT: Implied 2nd quoted portion was the parent commenter's notion when it was a summary of the author's position.
      - alilleybrinker 3y ago
gavinhoward 3y ago
> Re: ...C and C++ memory vulnerabilities, I'd say maybe, see: Rust In general, yes. However, I hate Rust; my software wouldn't exist if I had to write it in Rust. [1] So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. In my case, my plan is to fuzz, use every one of the fuzz paths found as a test case, and ensure all of those test cases come out clean in sanitizers and Valgrind. Oh, and I'll also do error injection, like SQLite [2], to exercise even more paths, and those paths will also have to come out clean. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i... [2]: https://www.sqlite.org/testing.html#anomaly_testing https://www.sqlite.org/testing.html#anomaly_testing
- alilleybrinker 3y ago
  At the moment there's an effort from the Office and the National Cyber Director (ONCD), CISA, NSF, DARPA, and OMB to encourage a move to memory safe languages, including but not limited to Rust (see [1]). This included an RFI for which there were many responses, including a number of major tech companies (Microsoft, Google, others). The general consensus supports a move to memory safe languages, BUT many of the respondents also caution about the need to prioritize and carefully manage such a transition, and the need to continue to support and assure code written in memory unsafe languages using other assurance techniques like fuzzing, integration testing, unit testing, static code analysis, and more. Hopefully that helps explain where things stand at the moment regarding at least US movement on this topic, and also to assuage concerns about a unilateral mandate that things get rewritten in Rust (or another language). [1]: https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fact-sheet-office-of-the-national-cyber-director-requests-public-comment-on-open-source-software-security-and-memory-safe-programming-languages/ https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fac...
  - gavinhoward 3y ago
    I know. I also know that despite some having caution, there are those that would speed ahead with RIIR.
- 3y ago

alilleybrinker 3y ago

I think this reading is _mostly_ right. To make it a little clearer: 1. A rules-based approach to define a minimum standard, likely based around existing descriptions of software weaknesses where the rules basically say "you aren't allowed to have this type of software weakness" (the doc specifically gives path traversal as an example). HOWEVER, liability would only be established if a weakness is actually exploited, to help avoid the problem of people proactively scanning for weaknesses and then troll-suing as a way to make money. 2. A process-based safe harbor to avoid liability for exploitation of weaknesses NOT on the rules-based "no no list." Basically, if you can show you followed the safe harbor process requirements, you get the benefit of the safe harbor. This is to protect and encourage organizations to go above and beyond the floor established by the rules-based standard.

mustache_kimono 3y ago
> HOWEVER, liability would only be established if a weakness is actually exploited, to help avoid the problem of people proactively scanning for weaknesses and then troll-suing as a way to make money. Agreed. Torts require damages.
- alilleybrinker 3y ago
  Yeah, the doc acknowledges this concept is "drawing on tort law principles." In this case the author, Jim Dempsey, is proposing a rules-based framework for establishing a floor regardless of what underlying system is used (warranty, torts, etc.). So he's not _inherently_ assuming a tort law framing, and is instead making a recommendation for how it should operate regardless of whether the resulting system is based around tort law.
  - mustache_kimono 3y ago
    > So he's not _inherently_ assuming a tort law framing, and is instead making a recommendation for how it should operate regardless of whether the resulting system is based around tort law. Not to get too in the weeds, but breaches of implied warranties were once/began as torts. But, yes, I guess I was a little glib. I should have said -- it would be sensible to require damages for these types of actions. Although I'm not sure I agree with the author's formulation: > HOWEVER, liability would only be established if a weakness is actually exploited, to help avoid the problem of people proactively scanning for weaknesses and then troll-suing as a way to make money. I think we should encourage customers to look for vulnerabilities. Damages analyses can take into account depreciation, reasonableness of damages/troll suing, etc. If you have 100s of devices you must replace because the vendor won't patch, and your patch request is reasonable (high consequence vulnerability) within 5 years of purchase, I think damages accounting for depreciation make sense, without proof of exploitation. EDIT: Implied 2nd quoted portion was the parent commenter's notion when it was a summary of the author's position.
    - alilleybrinker 3y ago

gavinhoward 3y ago

> Re: ...C and C++ memory vulnerabilities, I'd say maybe, see: Rust In general, yes. However, I hate Rust; my software wouldn't exist if I had to write it in Rust. [1] So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. In my case, my plan is to fuzz, use every one of the fuzz paths found as a test case, and ensure all of those test cases come out clean in sanitizers and Valgrind. Oh, and I'll also do error injection, like SQLite [2], to exercise even more paths, and those paths will also have to come out clean. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i... [2]: https://www.sqlite.org/testing.html#anomaly_testing https://www.sqlite.org/testing.html#anomaly_testing

alilleybrinker 3y ago
At the moment there's an effort from the Office and the National Cyber Director (ONCD), CISA, NSF, DARPA, and OMB to encourage a move to memory safe languages, including but not limited to Rust (see [1]). This included an RFI for which there were many responses, including a number of major tech companies (Microsoft, Google, others). The general consensus supports a move to memory safe languages, BUT many of the respondents also caution about the need to prioritize and carefully manage such a transition, and the need to continue to support and assure code written in memory unsafe languages using other assurance techniques like fuzzing, integration testing, unit testing, static code analysis, and more. Hopefully that helps explain where things stand at the moment regarding at least US movement on this topic, and also to assuage concerns about a unilateral mandate that things get rewritten in Rust (or another language). [1]: https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fact-sheet-office-of-the-national-cyber-director-requests-public-comment-on-open-source-software-security-and-memory-safe-programming-languages/ https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fac...
- gavinhoward 3y ago
  I know. I also know that despite some having caution, there are those that would speed ahead with RIIR.
3y ago