I added much of this text. Feel free to adjust as you see fit. - Sam Ruby
On Thu, Jan 6, 2022 at 10:07 AM Mark Thomas <[email protected]> wrote: > > Some ideas that we might want to weave into the existing text: > > In the critical components bullet: > > - the owner of a system is best placed to determine the criticality > of that system and the degree to which individual components > contribute to that criticality > > - Criticality depends on usage. We need to avoid solutions that create > burdens for all system owners using a software component when the > component is only critical for some systems. > > In the speed of rolling out updates bullet: > > - Referencing papers such as [1]. I don't think we could do enough to > emphasis importance of the last sentence in the abstract: > "We also find that a typical zero-day attack lasts 312 days on average > and that, after vulnerabilities are disclosed publicly, the volume of > attacks exploiting them increases by up to 5 orders of magnitude." > We need to find a way to get this meeting to focus on the 99.999% part > of the problem and not on the 0.001% part. > Now, I am playing a little fast and loose with the statistics since > "volume of attacks" != "volume of successful attacks" and attacks > should become less successful over time as more system owners patch > but, the volume increases for a reason. > > - This is a really hard problem to solve. Like with criticality, whether > a system is exposed to a particular vulnerability depends on usage. We > don't want to introduce something that impacts all systems when only > some are vulnerable. > > - Adding automatic update checks could work for products but not > libraries. Even then there are plenty of system owners (including most > of the US Federal Government) who don't want their software phoning > home for any reason. > > - Logging regular warnings once the software reaches a certain age > requires assumptions to be made in terms of expose to vulnerabilities > that are likely to be wrong for a reasonable proportion of systems. > And, again, is only really workable for products. > > - The most viable approach I can think of is to incentivize system > owners to ensure that they are not exposed to vulnerabilities via > using a product within their system: > a) with known vulnerabilities; > b) that has no established process for handling vulnerability reports > and publishing details of confirmed vulnerabilities; and/or > c) has reached End of Life > without effective mitigation for the associated security risks. > I think the incentive has to be some form of liability (civil and/or > criminal) if a system owner does any of the above. > Such liability may already exist [2]. Expanding the funding of the > organizations tasked with enforcement in one possible option. > > Mark > > > [1] https://dl.acm.org/doi/10.1145/2382196.2382284 > [2] https://techcrunch.com/2022/01/05/ftc-legal-action-log4j/ > > > On 05/01/2022 23:30, Sam Ruby wrote: > > On Wed, Jan 5, 2022 at 5:54 PM David Nalley <[email protected]> wrote: > >> > >> We discussed the prebrief doc that's going out over the weekend. Our > >> submission (if any) is due by EoD Friday, EST. > > > > Observing what has worked and what hasn't worked in the past, and not > > being aware of any "silver bullets" that solve the issues that we > > face, I'm wondering if we should instead share our experiences on what > > worked and what didn't work so well in the past. > > > > Two things in particular we need to address: > > > > * Our position that our contributors are volunteers, while correct, is > > confusing and counter productive. > > > > * Intentionally or otherwise, we are being treated as a company, and > > one that is somehow more problematic than the other companies who > > produce software. > > > > I've drafted a position paper which attempts to draw the comparison > > between the ASF and standards organizations. Like all analogies, it > > is deeply flawed. The question is whether it is more useful than the > > approaches we have tried to date. > > > > It is just a draft. If it doesn't resonate with others, it can be > > discarded. If it has any redeemable value, it is on a wiki and can be > > improved: > > > > https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper > > > > My hope is that the result is more approachable and makes the > > connections between our experiences and our positions clearer. It also > > provides a graceful way for us to say "yes, but" to ideas such as > > identifying critical components. > > > > - Sam Ruby > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
