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]
