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

[Roman Danyliw via Datatracker <[e-mail]>]

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”?


----------------------------------------------------------------------
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.  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.”

** 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.

** 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.

** 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”?

** 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/.

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

** 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.

** 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.

** 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/
-- Can a stronger statement be made here?  Is this YANG module intended or not
to be access via NETCONF/RESTCONF?

** 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.

** 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.

** 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.

** 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?

** 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?

** 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

-- 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?