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 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]
>
