Re: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

[Eliot Lear <[e-mail]>]

Hi Wei Pan,

Thanks for this excellent review.  Please see below.

> On 24 Jan 2021, at 15:14, Panwei (William) <[e-mail]> wrote:
> 
> I've read the draft and I support the adoption. In addition, I have the following comments:
> 
> 1)
> 1. Introduction
> An application-layer management system retrieving an SBOM in order
> to evaluate the posture of an application server of some form.
> These application servers may themselves be containers or
> hypervisors. Discovery of the topology of a server is beyond the
> scope of this memo.
> 
> Comment> I know there are application-layer firewalls, but I don't think it's also appropriate to use "application-layer" to describe the management system. The management system manages the application server, but should not be specific to "application-layer".

I think your concern is with the term “application server”.  If so, I agree with you, the intent here is not to address application layer matters, but at the layer below.  Perhaps we could reword this to be a bit more clear.


> 
> Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it just send a SBOM URL?

Actually, the intent is to not require certain application servers to send any URL ;-). Rather, to have a well known URI prefix so that the SBOM can be discovered through a query.

> 
> 2)
> 1. Introduction
> A network-layer management system retrieving an SBOM from an IoT
> device as part of its ongoing lifecycle. Such devices may or may
> not have interfaces available to query SBOM information.
> 
> Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

I am happy to remove the word “network-layer”, but I would rather not get into behavioral evaluation, as these are two different functions.

> 
> Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".
> 

Ok.

> 3)
> 1.3. Discussion points
> Are there other retrieval mechanisms that need to be specified?
> 
> Comment> Can the SBOM info be directly stored/written in the MUD file?

Not in this design.  MUD is intended only for discovery, and is certainly not intended to be the only discovery mechanism.

> 
> 4)
> 3. The mud-sbom augmentation to the MUD YANG model
> In the description of "leaf-list sbom-local", it is said:
> "The choice of sbom-local means that the SBOM resides at
> a location indicated by an indicted scheme for the
> device in question, at well known location
> ’/.well-known/sbom’. For example, if the MUD file
> indicates that coaps is to be used and the host is
> located at address 10.1.2.3, the SBOM could be retrieved
> at ’coaps://10.1.2.3/.well-known/sbom’. N.B., coap and
> http schemes are NOT RECOMMENDED.";
> 
> Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

This has to be known by the MUD Manager.  I think it’s a good idea to say a bit more about this, though, since that may not be the case for all previous MUD Managers.  Do you agree?

> 
> 5)
> 4. Examples
> The first MUD file demonstrates how to get the SBOM
> without ACLs, and the second has ACLs.
> 
> Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

Yes indeed.

> 
> 6)
> 5. Security Considerations
> Another risk is a skew in the SBOM listing and the actual software
> inventory of a device/container. For example, a manufactuer may
> update the SBOM on its server, but an individual device has not be
> upgraded yet. This may result in an incorrect policy being applied
> to a device. A unique mapping of a device’s firmware version and its
> SBOM can minimize this risk.
> 
> Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Indeed that is available, but a caution: MUD files that are tied to X.509-based MUD-URLs won’t show latest and greatest firmware.  This draft actually could heal that deficiency - to a point.

Eliot