Very good work indeed (I followed it closely), thanks to all the participants.
Phil's remarks is right to the point!
Jacques
Le 07/01/2022 à 17:10, Phil Steitz a écrit :
This looks really good to me. Many thanks to those who contributed to the content. I have one comment that does not need to be reflected in the
doc, but which may come up in discussion. I agree strongly with the basic point that system owners need to take accountability for knowing what
they are running, what is critical and what needs to be upgraded. We need to be careful though about people forming the mental picture of all of
the vulnerable running software as monolithically compiled applications that "contain" components like manufactured goods contain fabricated parts.
Most actual "systems" today leverage distributed components that "system owners" don't directly build or control. That does not change anything in
terms of accountability, but it it does makes the problem a little harder for system owners as vulnerability extends in many cases beyond direct
control or ability to patch.
On 1/7/22 7:05 AM, Mark J Cox wrote:
Since the pre-meeting we've been updating the Position Paper (so if you'
not been 'watching' it on the wiki please take another look and comment
here). We're likely to submit this in the next few hours and it'll be sent
to all the delegates attending the meeting in advance. We've also been
informed the meeting is now hybrid, with one in-person representative and
up to two remote and we've adjusted our plans to match that.
https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper
Regards, Mark J Cox
ASF Security
On Thu, Jan 6, 2022 at 3:40 PM Sam Ruby <[email protected]> wrote:
I added much of this text. Feel free to adjust as you see fit.
- Sam Ruby
On Thu, Jan 6, 2022 at 10:07 AM Mark Thomas <[email protected]> wrote:
Some ideas that we might want to weave into the existing text:
In the critical components bullet:
- the owner of a system is best placed to determine the criticality
of that system and the degree to which individual components
contribute to that criticality
- Criticality depends on usage. We need to avoid solutions that create
burdens for all system owners using a software component when the
component is only critical for some systems.
In the speed of rolling out updates bullet:
- Referencing papers such as [1]. I don't think we could do enough to
emphasis importance of the last sentence in the abstract:
"We also find that a typical zero-day attack lasts 312 days on average
and that, after vulnerabilities are disclosed publicly, the volume of
attacks exploiting them increases by up to 5 orders of magnitude."
We need to find a way to get this meeting to focus on the 99.999% part
of the problem and not on the 0.001% part.
Now, I am playing a little fast and loose with the statistics since
"volume of attacks" != "volume of successful attacks" and attacks
should become less successful over time as more system owners patch
but, the volume increases for a reason.
- This is a really hard problem to solve. Like with criticality, whether
a system is exposed to a particular vulnerability depends on usage. We
don't want to introduce something that impacts all systems when only
some are vulnerable.
- Adding automatic update checks could work for products but not
libraries. Even then there are plenty of system owners (including most
of the US Federal Government) who don't want their software phoning
home for any reason.
- Logging regular warnings once the software reaches a certain age
requires assumptions to be made in terms of expose to vulnerabilities
that are likely to be wrong for a reasonable proportion of systems.
And, again, is only really workable for products.
- The most viable approach I can think of is to incentivize system
owners to ensure that they are not exposed to vulnerabilities via
using a product within their system:
a) with known vulnerabilities;
b) that has no established process for handling vulnerability reports
and publishing details of confirmed vulnerabilities; and/or
c) has reached End of Life
without effective mitigation for the associated security risks.
I think the incentive has to be some form of liability (civil and/or
criminal) if a system owner does any of the above.
Such liability may already exist [2]. Expanding the funding of the
organizations tasked with enforcement in one possible option.
Mark
[1] https://dl.acm.org/doi/10.1145/2382196.2382284
[2] https://techcrunch.com/2022/01/05/ftc-legal-action-log4j/
On 05/01/2022 23:30, Sam Ruby wrote:
On Wed, Jan 5, 2022 at 5:54 PM David Nalley <[email protected]> wrote:
We discussed the prebrief doc that's going out over the weekend. Our
submission (if any) is due by EoD Friday, EST.
Observing what has worked and what hasn't worked in the past, and not
being aware of any "silver bullets" that solve the issues that we
face, I'm wondering if we should instead share our experiences on what
worked and what didn't work so well in the past.
Two things in particular we need to address:
* Our position that our contributors are volunteers, while correct, is
confusing and counter productive.
* Intentionally or otherwise, we are being treated as a company, and
one that is somehow more problematic than the other companies who
produce software.
I've drafted a position paper which attempts to draw the comparison
between the ASF and standards organizations. Like all analogies, it
is deeply flawed. The question is whether it is more useful than the
approaches we have tried to date.
It is just a draft. If it doesn't resonate with others, it can be
discarded. If it has any redeemable value, it is on a wiki and can be
improved:
https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper
My hope is that the result is more approachable and makes the
connections between our experiences and our positions clearer. It also
provides a graceful way for us to say "yes, but" to ideas such as
identifying critical components.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
