On 9/28/2022 12:06 AM, Eliot Lear wrote:
Hi Christian, just following up on this:
And following up myself. I am looking at the deltas between draft 10 and
draft 9, and while it goes in the right direction, I would love to see a
bit more work to address my main points:
1) It would be nice to have some structure in the security section,
delineating the different attacks that we are worried about. But that's
a nice to have, and I will soon stop asking for that.
2) I am not concerned about the disclosure of software vulnerabilities
per software versions, but I am still concerned about the inventory of
devices. Especially if there is an easy way to query devices and find
what software version they are running. Attackers are going to love an
automated way to find out which devices run what vulnerable version.
3) Of course, in managed networks, defenders can also use the inventory
of devices running vulnerable versions to shore up defenses, so there is
clearly a trade-off. But that trade-off does not happen in networks that
are not managed, especially networks in which devices may be plugged in
more or less in their default configuration. The attackers can get the
data, and there are no defenders to use it. The discussion with Elliot
and Michael concluded with Michael's suggestion that the inventory
functions should be disabled by default, and should only be enabled
after devices are properly onboarded. That recomendation is not found in
draft-10.
4) Draft-10 introduces a kind of typo. The sentence "These are the
subtrees and data nodes and their sensitivity/vulnerability:" was moved
from the paragraph starting "There are a number of data nodes" to the
paragraph starting "Some of the readable data nodes". Or I guess that
was the intent, because the sentence was left at one position and copied
at the other. Easy fix.
5) The sentence about "some network environments" was not removed, but
merely moved a few paragraphs down. That sentence includes no less than
three qualifiers to minimize the potential threat: "some data nodes"
(how many? just a few?), "may be considered sensitive" (but perhaps the
authors doubt it?), "in some network environments" (which ones? just a
few?). I would really like to read something more direct.
-- Christian Huitema
On 16.09.22 07:45, Eliot Lear wrote:
To address your second point first, it helps to keep in mind that
what is described in this draft is not a retrieval mechanism but a
*discovery* mechanism. The device does not at all need to offer an
SBOM, in which case Internet-based retrieval methods are offered. I
agree with you that devices should not offer a web server for this
purpose alone for the very reasons you state, and would be happy to
make that clearer.
I've added one sentence and strengthened another to make clear that we
are discussing a discovery mechanism, and that the mechanism itself
does not provide access to the underlying data.
The reason we use "MAY" is that there is a philosophical difference
within the SBOM community about whether the information should be
freely available. Here is the argument for the information being
freely available, at least in some circumstances:
* There are many reasons for this, and the circumstances vary
widely. For commonly used CPE that is almost entirely based on
OpenWRT, what precisely does one think on is hiding, given that
one can easily scan either the source or a docker image? On the
other hand, for an MRI scanner that uses a modicum of OSS, whose
images are encrypted, then yeah, maybe security through obscurity
will work for a while. Those two examples are poles, with many
devices fitting in the middle. To be clear, if the
software/firmware image is accessible in any way, a fairly
accurate SBOM can be generated by the attacker.
* As to attacks at scale, if the information is authenticated and
authorized – at scale – we must assume that it will leak to the
attacker, leading to information asymmetry in favor of the
attacker, at scale.
Your argument goes the other way, and I won't recapitulate it. In the
end, only deployment experience will help us understand which
approach is better. The draft doesn't take a position on any of
this. Since it's simply a discovery mechanism, it is entirely up to
the implementation to decide what authentication and authorization
model to use with the underlying substrate.
No change here. However, there is a related topic hiding here for
iotops about industrial/critical services authentication that I will
raise in due course.
With regard to "some network environments" text, I agree with you
that is poorly written. The nature of the device as mentioned above
is probably more the issue. I'll try to come up with better wording.
After re-reading that sentence, I simply removed it as superfluous.
Eliot
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
