Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sbom-access-15: (with DISCUSS and COMMENT)

[Eliot Lear <[e-mail]>]

Hi Roman,

On 25.04.23 17:53, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-opsawg-sbom-access-15: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> ** Section 1.2.
>     When both vulnerability and software inventory
>     information is available from the same location, both sbom and vuln
>     nodes MUST indicate that.
>
> What are “sbom and vuln nodes”?  Those names don’t map to YANG model described
> in Section 3.  Is this “sbom-url” and “vuln-url”?

You are correct.  And I will correct as stated.



>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Christian Huitema for the SECDIR review.
>
> ** Section 1.  Editorial.
>
>     These two classes of information can be used in concert.  For
>     instance, a network management tool may discover that a system makes
>     use of a particular software component that has a known
>     vulnerability, and a vulnerability report may be used to indicate
>     what if any versions of software correct that vulnerability, or
>     whether the system exercises the vulnerable code at all.
>
>     Both classes of information elements are optional under the model
>     specified in this memo.  One can provide only an SBOM, only
>     vulnerability information, or both an SBOM and vulnerability
>     information.
>
> The second paragraph seems to suggest that the classes of information are SBOM
> and vulnerability information.
That's right.
> However, the example provided in paragraph one
> doesn’t make that distinction clear since the “network management tool”
> implicitly bundled SBOM+vulnerability information into one information element
> by both knowing what software was loaded and that it was vulnerable.
> Editorially, the case isn’t make that “these two classes of information can be
> used in concert.”

I think there are two issues here.  The first is that it helps to have a 
source of vulnerabilities such as the NVD.  The second is to use the 
manufacturer-provided status of those vulnerabilities (a'la CSAF).  I 
will clarify this point.



>
> ** Section 1.1
> In the first few reads of the text, it was obvious that there were different
> interfaces, but not that they served different content.  Likewise, the title of
> the section “How This Information Is Retrieved” didn’t match the text which
> covered the properties of the retrieval rather than explicitly summarize it.  I
> would recommend adding something explicit about the role of the interfaces with
> appropriate forward references at the start of the section.
>
> PROPOSED NEW:
> Section 4 describes a data model to extend the MUD file format to carry SBOM
> and vulnerability information.  Section 1.5 of RFC8520 describes mechanisms by
> which devices can emit a URL to point to this file.  Additionally, devices can
> share this URL either through documentation or within a QR code on a box.
> Section 2 describes a well-known URL from which an SBOM could be served from
> the local device.

Used, thank you.

>
> ** Section 1.2
>     When these are retrieved either directly from the
>     device or directly from a web server
>
> Recommend being clearer about the location of the web-server.  Retrieval from
> the device could be from its internal web.
>
> PROPOSED NEW
> When these are retrieved either directly from the device or from a remote web
> server.

Used, thank you.


>
> ** Section 1.2.  Editorial.
>     ... tools will need to observe the
>     content-type header to determine precisely which format is being
>     transmitted.
>
> Is it “content-type” or “Content-Type”?
Corrected, thanks.
> ** Section 1.2.
>     When both vulnerability and software inventory
>     information is available from the same location
>
> Recommend being precise by saying: s/from the same location/from the same URL/.

Corrected.

>
> ** Section 4. sbom-archive-list.  Does this list have a recommend sort order?
> Is random ok?  Newest to old?

Yes, because the order would duplicate (and might well get wrong) 
information that would be in the SBOMs themselves.

>
> ** Section 5.1
>     The second example demonstrates that just SBOM information is
>     included.
>
>    {
>      "ietf-mud:mud": {
>        "mud-version": 1,
>        "extensions": [
>          "transparency"
>        ],
>        "mudtx:transparency": {
>          "sbom-local-well-known": "https"
>        },
>        "mud-url": "https://iot.example.com/modelX.json",
>        "mud-signature": "https://iot.example.com/modelX.p7s",
>        "last-update": "2022-01-05T13:29:47+00:00",
>        "cache-validity": 48,
>        "is-supported": true,
>        "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>        "mfg-name": "Example, Inc.",
>        "documentation": "https://iot.example.com/doc/modelX",
>        "model-name": "modelX"
>      }
>    }
>
> The “systeminfo” text is not accurate (“retrieving vuln and SBOM info via a
> cloud service”) as no vulnerability information appears to be provided in the
> MUD file and the text describing the example also says no vulnerability
> information is provided.


Thanks.  Cut and paste error.


>
> ** Section 5.2
>     In this example, the SBOM is retrieved from the device, while
>     vulnerability information is available from the cloud.  This is
>     likely a common case, because vendors may learn of vulnerability
>     information more frequently than they update software.
>
> {
>    "ietf-mud:mud": {
>      "mud-version": 1,
>      "extensions": [
>        "transparency"
>      ],
>      "mudtx:transparency": {
>        "sbom-local-well-known": "https",
>        "vuln-url": "https://iot-device.example.com/info/modelX/csaf.json"
>      },
>      "mud-url": "https://iot-device.example.com/modelX.json",
>      "mud-signature": "https://iot-device.example.com/modelX.p7s",
>      "last-update": "2022-01-05T13:25:14+00:00",
>      "cache-validity": 48,
>      "is-supported": true,
>      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
>      "mfg-name": "Example, Inc.",
>      "documentation": "https://iot-device.example.com/doc/modelX",
>      "model-name": "modelX"
>    }
> }
>
> The “systeminfo” text in this example is not accurate ( “retrieving vuln and
> SBOM info via a cloud service”) as the SBOM appears to be locally served per
> the file MUD file text and the text description of this example.

Fixed.


>
> ** Section 6
>    In particular, the YANG
>     module specified in this document is not necessarly intended to be
>     accessed via regular network management protocols, such as the
>     NETCONF [RFC6241] or RESTCONF [RFC8040], and hence the regular
>     security considerations for such usage are not considered here.
>
> -- Typo. s/necessarly/necessarily/
Fixed here.
> -- Can a stronger statement be made here?  Is this YANG module intended or not
> to be access via NETCONF/RESTCONF?

The MUD mechanisms are not intended to be used by NETCONF/RESTCONF, but 
that's this document.  But it's a YANG model.  So someone might try it.

> ** Section 6
>     If an attacker modifies the elements, they may misdirect automation
>     to retrieve a different set of URLs than was intended by the
>     designer.  This in turn leads to two specific sets of risks:
>
>     *  the information retrieved would be false.
>
>     *  the URLs themselves point to malware.
>
> Additionally, there is a tracking/asset identification risk.  If the attacker
> can control the target of the URL (without having access or prior knowledge of
> the devices), they could potentially discover the existence of particular
> hardware at a given netblock/organization.

That's a MUD issue, not specific to this model.


>
> ** Section 6
>     SBOMs provide an inventory of software.  If software is available to
>     an attacker, the attacker may well already be able to derive this
>     very same software inventory.
>
> Recommend being explicit on why knowing the SBOM helps the attacker.
>
> PROPOSED NEW
> SBOMs provide an inventory of software.  Knowledge of which specific software
> is loaded on a system can aid an attacker in identifying an appropriate exploit
> for a known vulnerability or guide the development of novel exploit against
> this system.


Sure.


>
> ** Section 6
>     SBOMs provide an inventory of software.
>     …
>     When this information resides on the
>     endpoint itself, the endpoint SHOULD NOT provide unrestricted access
>     by default.
>
> Is this text referencing the “.well-known” interface?  If so, please be clear.

Ack.

>
> ** Section 6
>     In
>     particular, if a system attempts to retrieve an SBOM via HTTP and the
>     client is not authorized, the server MUST produce an appropriate
>     error, with instructions on how to register a particular client.
>
> Assuming this sentence is talking about the “.well-known” interface, does this
> same kind of guidance apply to CoAP?

Good point.  Added.


>
> ** Section 6
>     To further mitigate attacks against a device, manufacturers SHOULD
>     recommend access controls.
>
> Good guidance. What’s the context of this recommendation given that this
> specification is about an API to retrieve SBOM/vulnerability information.
> Access controls on what?

That should be "network access controls."


>
> ** Section 6
>     Vulnerability information is generally made available to such
>     databases as NIST's National Vulnerability Database.  It is possible
>     that vendor may wish to release information early to some customers.
>     We do not discuss here whether that is a good idea, but if it is
>     employed, then appropriate access controls and authorization SHOULD
>     be applied to the vulnerability resource.
>
> -- Please provide a reference for the NIST NVD

Ok.


>
> -- Per “vulnerability resource”, is that a typo and it should be “vulnerable
> resource” or is the text saying that the pre-release vulnerability information
> needs to be protected?
>
Clarified.  Thanks!

Eliot

>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>