Hi, Eliot and Scott,
Base-on MUD extension with SBOM information, network administrator can evaluate the access risks of IoT devices actively, and adopt some measures for secure access. This is helpful for network administrator. Like “draft-yang-opsawg-iot-devices-active-scanning” described, by active scanning weak password, mandatory and hazardous services, etc, the network administrator can discover security vulnerabilities in advance. Surely, in mud file, these security risk-characters and proposed-policy are listed, which are commonly with default and come to an agreement by iot owner and network administrator. Here, about SBOM risks, I am confused on how to achieve E2E automation integrated with IoT Platform? Like the case for example: A customer bought some iot devices, sometimes he don’t know whether its OS-version is lower or not, (one way is to get from its handbook, but maybe this is also older version), in fact he needn’t care it at all. His aim is to let this devices on-boarding and can be working normally. If its OS-version is lower, the device should access the network securely and finish updating its OS-version rightly, this will be the optimal solution. Especially without his perception… If the network administrator set deny policy firstly based-on MUD information actively, and then wait some time to do the next confirmation, which may make iot user unhappy, especially he didn’t know the reason, … “draft-richardson-shg-mud-quarantined-access-01” give a “quaranteed-device-policy” for devices’ secure updating. I think, if apply this way into the above case, list or pinpoint the fundamental policy in MUD file, may be solve SBOM vulnerabilities during on-boarding, and achieve E2E automation. Is that so, and is my understanding right? Hope to receive your suggestion, Thanks, Best Regards, Jay. [OPSAWG] Fwd: New Version Notification for draft-lear-opsawg-mud-sbom-00.txt Eliot Lear <[email protected]> Mon, 18 May 2020 10:12 UTCShow header<https://mailarchive.ietf.org/arch/msg/opsawg/SR7dHKdL_FMgakJG4Y-71HlUzko/> Hi everyone, Below is a draft that Scott Rose and I have co-authored. Its purpose is to help deployments identify software bills of materials (SBOMs) when they are available. An SBOM is a software inventory that includes some additional meta-information, such as what dependencies a component may have. The idea behind SBOMs is that they can provide licensing status to developers, and some notion of vulnerability status to everyone (and I mean everyone). MUD is ideal as a discovery mechanism. The goal is not to create new ways to retrieve the information, but simply to advertise what ways are available for a given device. Eliot > Begin forwarded message: > > From: <[email protected]><mailto:<[email protected]>> > Subject: New Version Notification for draft-lear-opsawg-mud-sbom-00.txt > Date: 18 May 2020 at 12:05:29 CEST > To: Scott Rose <[email protected]><mailto:<[email protected]>>ov>, > Eliot Lear <[email protected]><mailto:<[email protected]>> > > > A new version of I-D, draft-lear-opsawg-mud-sbom-00.txt > has been successfully submitted by Eliot Lear and posted to the > IETF repository. > > Name: draft-lear-opsawg-mud-sbom > Revision: 00 > Title: SBOM Extension for MUD > Document date: 2020-05-18 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-lear-opsawg-mud-sbom-00.txt > Status: https://datatracker.ietf.org/doc/draft-lear-opsawg-mud-sbom/ > Htmlized: https://tools.ietf.org/html/draft-lear-opsawg-mud-sbom-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lear-opsawg-mud-sbom > > > Abstract: > Software bills of materials (SBOMs) are formal descriptions of what > pieces of software are included in a product. This memo specifies a > means for manufacturers to state how SBOMs may be retrieved through > an extension to manufacturer usage descriptions (MUD). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at > tools.ietf.org<https://tools.ietf.org/>. > > The IETF Secretariat > > Note that SBOMs may change more frequently than access control requirements. A change to software does not necessarily mean a change to control channels that are used. Therefore, it is important to retrieve the MUD file as suggested by the manufacturer in the cache-validity period. In many cases, only the SBOM list will have been updated. Best Regards, [cid:[email protected]] 杨杰 (Jay Yang) 数据通信标准专利部 Mobile: 13852295541 E-mail：[email protected]<mailto:[email protected]> 中国(China)-南京(Nanjing)-雨花台区软件大道101号华为南京基地N3-1F
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
