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

[Roman Danyliw <[e-mail]>]

Hi Eliot!

Thanks for the quick and detailed follow-up.  Everything you described below looks great.

Thanks,
Roman

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Eliot Lear
> Sent: Tuesday, April 25, 2023 3:25 PM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; opsawg-
> [e-mail]
> Subject: Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sbom-
> access-15: (with DISCUSS and COMMENT)
> 
> 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-posi
> > tions/ 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
> >