You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by David Nalley <da...@gnsa.us> on 2022/01/05 22:53:48 UTC
WH Pre-brief meeting notes
Hi folks,
What follows are my notes from the pre-brief meeting that occurred on
1/5/2022 at 11:00 AM Eastern. I am sure I missed bits, so please feel
free to correct my errors and omissions.
ASF Attendees: Mark Cox, Mark Thomas, Roy Fielding, Sam Ruby, David Nalley
WH Attendees: Anne Neuberger, Amit Mital, Mary Gingrich, Sezaneh Seymour
We started the call with a summary of the purpose of the upcoming
in-person meeting: Gathering together key software companies and
foundations to define a set of initiatives with the goal of improving
gaps in open source supply security. Anne voiced a perception that
in-person was core to having a good discussion, but did say that they
would add virtual options for attendees. She asked for suggestions to
go out to all attendees.
Anne indicated that she hadn't seen the pre-brief document that we sent along.
Anne asked that we start thinking about potential initiatives that
could be used to improve the situation.
Anne identified three potential initiatives that her side was thinking about:
1. Identifying the most critical open source artifacts
2. Building more accountable open source management. This item
particularly seemed to harp on the volunteer nature of our
communities, and emphasized the belief that they needed help.
3. Working on Software Bill of Materials (SBoM)
MarkC responded and called the volunteer problem a red herring and
cited our existing processes, and gates for ingesting, modifying, and
releasing code, as well our security processes. He noted the really
fast turnaround on the log4j vulnerability as an example of that.
MarkC also called out the fact that things are often fixed quickly by
the open source project, but slowly consumed by downstream users. He
cited example of Struts and Log4j, and particularly that many people
were asking for support for Log4j 1.x which had been deprecated 7
years ago.
David called out the fact that identifying the most critical open
source artifacts requires that you know what's being consumed, and
that short of people telling us (or someone) what they are consuming -
you have a chicken and egg situation where you want to identify the
most important pieces, but can't do that effectively without knowing
how broadly something is consumed.
Anne asked about the best way to solve that problem. She asked if SBOM
would help solve that problem.
MarkC said that SBOM may help us in the future, but won't help in the
short or medium term because of the very long tail of software that
exists.
Anne asked again how we would solve identifying critical pieces of
software infrastructure.
MarkC, tried to turn the conversation away from solving that problem
and pointed out that someone saying that something is critical doesn't
change the process.
Amit - asked if identifying isn't a case of the perfect being the
enemy of the good and we should just identify 100 or so packages and
improve their security. (SBOM, processes, etc)
MarkC responded that critical designation wouldn't change speed or
response or quality for our projects at the ASF.
David called out that the ecosystem and various groups had done these
exercises before where we go fix the "top 50" and where that
materially improves the ecosystem, but with few exceptions it hasn't
helped on a broad scale.
MarkC cited his experience with OpenSSL and Heartbleed. He said that
even following all of that clamor, no one was paying attention to
log4j, and that it was on no one's list.
Roy said that we manage 350 products and that in consideration of the
ecosystem, that our impact is so large that we might have 200 of those
be considered critical. He said that because we didn't have any idea
of what was being consumed or how, and that some central registration
of use (SBOM registry?) to better understand that impact.
Anne seemed to latch on to Roy's idea.
David noted that as a vendor of software, we see folks who are not
keeping current with their dependencies. Doing all of the security
work fast and well doesn't matter if the industry doesn't have
mechanisms to ensure currency.
Anne asked us to bring ideas like these to the table.
We discussed the prebrief doc that's going out over the weekend. Our
submission (if any) is due by EoD Friday, EST.
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 8 Jan 2022, at 19:20, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
> 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).
I take that back - just counting NASA and some federal GEO/fin agencies email addresses in our commuinity - same in the USA.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
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 <dp...@gmail.com> 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 <ja...@les7arts.com>
> 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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
>>>>> security-discuss-unsubscribe@community.apache.org
>>>>>>> For additional commands, e-mail:
>>>>> security-discuss-help@community.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>> security-discuss-unsubscribe@community.apache.org
>>>>>> For additional commands, e-mail:
>>>>> security-discuss-help@community.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>> security-discuss-unsubscribe@community.apache.org
>>>>> For additional commands, e-mail:
>>>>> security-discuss-help@community.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> security-discuss-unsubscribe@community.apache.org
>>> For additional commands, e-mail:
>> security-discuss-help@community.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
>> For additional commands, e-mail:
>> security-discuss-help@community.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Dominik Psenner <dp...@gmail.com>.
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 <ja...@les7arts.com>
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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
> >>> security-discuss-unsubscribe@community.apache.org
> >>>>> For additional commands, e-mail:
> >>> security-discuss-help@community.apache.org
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail:
> >>> security-discuss-unsubscribe@community.apache.org
> >>>> For additional commands, e-mail:
> >>> security-discuss-help@community.apache.org
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> security-discuss-unsubscribe@community.apache.org
> >>> For additional commands, e-mail:
> >>> security-discuss-help@community.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: WH Pre-brief meeting notes
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
>>> security-discuss-unsubscribe@community.apache.org
>>>>> For additional commands, e-mail:
>>> security-discuss-help@community.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>> security-discuss-unsubscribe@community.apache.org
>>>> For additional commands, e-mail:
>>> security-discuss-help@community.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
>>> For additional commands, e-mail:
>>> security-discuss-help@community.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
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
Re: WH Pre-brief meeting notes
Posted by Sam Ruby <ru...@intertwingly.net>.
Both sets of changes applied. Thanks!
- Sam Ruby
On Fri, Jan 7, 2022 at 11:47 AM Dirk-Willem van Gulik
<di...@webweaving.org> 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
<di...@webweaving.org> 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 <ph...@steitz.com> 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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
> >>> security-discuss-unsubscribe@community.apache.org
> >>>>> For additional commands, e-mail:
> >>> security-discuss-help@community.apache.org
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail:
> >>> security-discuss-unsubscribe@community.apache.org
> >>>> For additional commands, e-mail:
> >>> security-discuss-help@community.apache.org
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> >>> For additional commands, e-mail:
> >>> security-discuss-help@community.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail: security-discuss-help@community.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
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 <ph...@steitz.com> 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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
>>> security-discuss-unsubscribe@community.apache.org
>>>>> For additional commands, e-mail:
>>> security-discuss-help@community.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>> security-discuss-unsubscribe@community.apache.org
>>>> For additional commands, e-mail:
>>> security-discuss-help@community.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
>>> For additional commands, e-mail:
>>> security-discuss-help@community.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
Re: WH Pre-brief meeting notes
Posted by Phil Steitz <ph...@steitz.com>.
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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
>> security-discuss-unsubscribe@community.apache.org
>>>> For additional commands, e-mail:
>> security-discuss-help@community.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> security-discuss-unsubscribe@community.apache.org
>>> For additional commands, e-mail:
>> security-discuss-help@community.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
>> For additional commands, e-mail:
>> security-discuss-help@community.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Mark J Cox <mj...@apache.org>.
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 <ru...@intertwingly.net> 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 <ma...@apache.org> 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 <da...@gnsa.us> 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:
> security-discuss-unsubscribe@community.apache.org
> > > For additional commands, e-mail:
> security-discuss-help@community.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: WH Pre-brief meeting notes
Posted by Sam Ruby <ru...@intertwingly.net>.
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 <ma...@apache.org> 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 <da...@gnsa.us> 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: security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail: security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Mark Thomas <ma...@apache.org>.
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 <da...@gnsa.us> 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: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Jan 5, 2022 at 6:30 PM Sam Ruby <ru...@intertwingly.net> wrote:
>
> https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper
The plan is to send this to the WH at 5PM Eastern (just under two
hours from now).
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: WH Pre-brief meeting notes
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Jan 5, 2022 at 5:54 PM David Nalley <da...@gnsa.us> 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: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org