Indeed - good work. I do think it may be useful to put the word academia or public services in there; just to stress that our community is not just tech/IT - but also people from Universities or (in Europe at least) considerable numbers of people from the public sector who (got) volunteered (as part of their day job as a civil servant).
This is mainly for strategic/defensive reasons - to avoid being lumped in with 'them tech with lots of money' and get painted on a 'side' of us.v.s them. So if we could work that back in near the top - that would be useful. Dw. > On 7 Jan 2022, at 19:46, Dominik Psenner <[email protected]> wrote: > > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
