Both sets of changes applied. Thanks! - Sam Ruby
On Fri, Jan 7, 2022 at 11:47 AM Dirk-Willem van Gulik <[email protected]> wrote: > > I would perhaps rephrase the section: > > The Apache Software Foundation is an example of an open source > organization. Companies and invited experts collaborate there to produce > releases of software components and products. Along the way, those companies > and individuals contribute their intellectual property to make this happen. > > into: > > The Apache Software Foundation is an example of an open source > organization. Self managed groups of experts (e.g. academics, people seconded > by their company or otherwise voluntary) collaborate there to produce > releases of software components and products. In this way; the industry as a > whole; i.e. companies, academia, the public sector and individuals contribute > their intellectual property to make this happen. > > Or something along these lines. And possibly add: > > The open source organisation facilitates and defines this process. By > means of the open source license, the governance and ability of these experts > to self manage and by means of providing things such a a cross group release > policy, distribution policy and security coordination function. > > And I would consider in the key-take-aways to somehow explain that Community > == wider industry/public-sector/academia. > With kind regards, > > Dw On Fri, Jan 7, 2022 at 11:55 AM Dirk-Willem van Gulik <[email protected]> wrote: > > After testing this on a few very technical policy makers and asking them what > they read perhaps also change:L > > - " those who use them" -> "companies that build these into their > product" > > - "JNDI (a part of the Java runtime library)" -> JNDI (a part of the > Java runtime; supplied its respective supplier; not part of Log4J) > > Dw > > On 7 Jan 2022, at 17:10, Phil Steitz <[email protected]> wrote: > > > > 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]
