Since the pre-meeting we've been updating the Position Paper (so if you've not been 'watching' it on the wiki please take another look and comment here). We're likely to submit this in the next few hours and it'll be sent to all the delegates attending the meeting in advance. We've also been informed the meeting is now hybrid, with one in-person representative and up to two remote and we've adjusted our plans to match that.
https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper Regards, Mark J Cox ASF Security On Thu, Jan 6, 2022 at 3:40 PM Sam Ruby <[email protected]> wrote: > 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] > >
