I also wouldn’t ignore the model where SBOMs will be delivered through 3rd party supply chain attestation data libraries that are already aggregating this data as part of C-SCRM assessment activities for mutual benefit.
Certainly MUD makes a lot of sense in very device-centric scenarios and I’m really excited to plug into this model (as I run one of the above mentioned data libraries, not just SBOM, but HBOM/MBOM, SOC2, build artifacts, other 3rd party product and vendor assessments and product certifications, etc) – but I find that discovery of MUD sources is half of the challenge. What I find really interesting is the potential for dynamic updating of SBOM as firmware is updated and communication of software risks this will make possible to device management infrastructure. Its far more likely 3rd party tools like data aggregators for supply chain or vulnerability risk management will interoperate with the management portal for a fleet of devices than with the individual devices themselves. -- Tony Turner Vice President, Fortress Labs (R&D) Fortress Information Security Cell 321-634-4886 Main 855.FORTRESS 189 S. Orange Ave., Suite 1950, Orlando, FL 32801 fortressinfosec.com<http://fortressinfosec.com/> From: OPSAWG <[email protected]> on behalf of Dick Brooks <[email protected]> Date: Friday, February 4, 2022 at 2:01 PM To: 'Michael Richardson' <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [EXTERNAL SOURCE] Re: [OPSAWG] SBOMs and version non-specific MUD files Michael, The predominant "SBOM delivery channel" I see is through access controlled customer portals where customers can download SBOM's Vulnerability Disclosures and other artifacts needed to perform a NIST C-SCRM risk assessment for Executive Order 14028. Here's a use case to consider, listing all of the evidence data needed: https://github.com/rjb4standards/REA-Products/blob/master/UseCaseVDR117/READ ME.md Thanks, Dick Brooks Never trust software, always verify and report! T http://www.reliableenergyanalytics.com Email: [email protected] Tel: +1 978-696-1788 -----Original Message----- From: OPSAWG <[email protected]> On Behalf Of Michael Richardson Sent: Friday, February 4, 2022 12:40 PM To: [email protected] Cc: [email protected] Subject: [OPSAWG] SBOMs and version non-specific MUD files ietf-opsawg-sbom-access provides for linking to an SBOM from a MUD file. My understanding is that for the sbom-retrival-method==cloud, that a list of sboms is included, one per version of the device firmware. I just wanted to re-iterate that this really is a good thing, because it allows for a version agnostic MUD file to list many things. I would like a cloud example to be added. I think that we need some RFC6125 text for the https: local-well-known text to explain how validation is (not) done. We still need some way to determine what version of firmware a device is running, and while the correct answer is remote attestation, it would be lovely if there was a recommendation for a lighter weight process. LLDP regularly reveals this, but that's unlikely to work over wifi or in residential situations. (I acknowledge that this is out of scope for sbom-access) -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg IMPORTANT: The information transmitted is intended only for the person or entity to which it is addressed. The content may contain business confidential and/or proprietary information, and it may be reviewed and logged for archival purposes by parties at Fortress Information Security other than those named in the message header. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
