Awesome work everyone! Just now I noticed an important key point that may has slipped through:
Built into the "genes" of every project is that we (the ASF) make software for the public good, at no charge and free to use for everyone. -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Fri, Jan 7, 2022, 18:23 Jacques Le Roux <[email protected]> wrote: > Very good work indeed (I followed it closely), thanks to all the > participants. > > Phil's remarks is right to the point! > > Jacques > > Le 07/01/2022 à 17:10, Phil Steitz a écrit : > > This looks really good to me. Many thanks to those who contributed to > the content. I have one comment that does not need to be reflected in the > > doc, but which may come up in discussion. I agree strongly with the > basic point that system owners need to take accountability for knowing what > > they are running, what is critical and what needs to be upgraded. We > need to be careful though about people forming the mental picture of all of > > the vulnerable running software as monolithically compiled applications > that "contain" components like manufactured goods contain fabricated > parts. > > Most actual "systems" today leverage distributed components that "system > owners" don't directly build or control. That does not change anything in > > terms of accountability, but it it does makes the problem a little > harder for system owners as vulnerability extends in many cases beyond > direct > > control or ability to patch. > > > > On 1/7/22 7:05 AM, Mark J Cox wrote: > >> Since the pre-meeting we've been updating the Position Paper (so if you' > >> 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] > >>> > >>> > > > > > > --------------------------------------------------------------------- > > 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] > >
