Hi Christian, just following up on this: On 16.09.22 07:45, Eliot Lear wrote:
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.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.
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: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.* 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.
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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
