Jay, I would like to think that manufacturers would quickly alert customers when they have a vulnerable device, but that is not always what happens. Sometimes threat intelligence service providers, CERT services, etc. are quicker in disseminating alerts about new bugs or vulnerabilities. Many enterprises want the know the components in the device in order to set security policies.
draft-moran-suit-mud-00 is similar to our work, but both may co-exist. Our work is aimed to make as little modification to the MUD controller as necessary. It does not need to parse a SUIT manifest, only perform an action if the SBOM extension is seen. However, both solutions co-exist on different platforms or classes of devices. Scott -- Scott Rose, NIST ITL [email protected]<mailto:[email protected]> ph: +1-301-975-8439 GVoice: +1-571-249-3671 From: "Yangjie (Jay, IP Standard)" <[email protected]> Date: Thursday, July 2, 2020 at 3:30 AM To: "Rose, Scott W. (Fed)" <[email protected]>, "[email protected]" <[email protected]>, Michael Richardson <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: Re : [OPSAWG] Fwd: New Version Notification for draft-lear-opsawg-mud-sbom-00.txt Hi, All, About extending security enhancement based-on MUD architecture, I’m looking forward to design with you. Thanks. And Scott, I think, If MUD file only extend SBOM information without the manufacture’s policy recommendations, maybe this extension will be redundant. When new vulnerabilities are disclosed, the manufacture should be update its devices’ SBOM, and push some alarm to his customer with proposing to patch these as soon as possible, this maybe the current common practice. To the manufacture, if only give the SBOM information in MUD file, but didn’t give the corresponding vulnerabilities repair-suggestion, for most network administrator, they don’t know how to do next, most likely they will ignore these. So one optional solution is collaborate SUIT(or other updating technology) with MUD, like the draft: “draft-moran-suit-mud-00” give the scenario. For one organization, if they wish to have access policy based-on some SBOM on a device, I think this is service layer policy from its user. If network give some special policy which are not known by the user. I think it’s difficult to be standard, unless these policy are common, and it’s better to be given in MUD file, like the draft:”draft-yang-opsawg-iot-devices-active-scanning-00”. And, for the manufacture, what’s the purpose to provide SBOM information in MUD file? They can’t get any benefits at all, even this will less their devices’ features. Security is for better availability, it the vulnerabilities are disclosed, the manufacture have the responsibilities to patch them. So I haven’t understood… (1. If SBOM vulnerabilities have disclosed, the manufacture should patch them quickly. In this case, one optional solution for automation is given a quarantine way for patching with MUD extension, like the draft: “draft-richardson-shg-mud-quarantined-access-01”…) About extending security enhancement based-on MUD architecture, I’m looking forward to design with you. Thanks. Best Regards, Jay from Huawei Technologies Co.,Ltd.. 发件人: Rose, Scott W. (Fed) [mailto:[email protected]] 发送时间: 2020年7月1日 22:51 收件人: Yangjie (Jay, IP Standard) <[email protected]>; [email protected] 抄送: [email protected] 主题: Re: Re : [OPSAWG] Fwd: New Version Notification for draft-lear-opsawg-mud-sbom-00.txt Jay, Yes, that is one possible use of a SBOM for IoT devices. An organization may wish to have access policies based on what OS, firmware or component version is in use on a device. Another scenario is when new vulnerabilities are disclosed, SBOMs may help an organization identify at-risk devices. For example, a new vulnerability is discovered in a common SSH client. An organization can generate a list of devices on their network that has that client version installed and can then perform whatever action they think is necessary (frequent scanning, quarantine until patched, etc.). This draft does not attempt to give instruction on to what organizations should do with the information, just specify a way to discover the SBOM for a given IoT device. Thanks, Scott Scott Rose, NIST ITL [email protected]<mailto:[email protected]> ph: +1-301-975-8439 GVoice: +1-571-249-3671 From: "Yangjie (Jay, IP Standard)" <[email protected]<mailto:[email protected]>> Date: Wednesday, July 1, 2020 at 12:00 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Rose, Scott W. (Fed)" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re : [OPSAWG] Fwd: New Version Notification for draft-lear-opsawg-mud-sbom-00.txt 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]<mailto:[email protected]>> Mon, 18 May 2020 10:12 UTCShow header<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FSR7dHKdL_FMgakJG4Y-71HlUzko%2F&data=02%7C01%7Cscott.rose%40nist.gov%7Ce0b6a55966834e5af8cb08d81e59cb44%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637292718321549766&sdata=OUZIvEE2xWVu2O25SttkdYDbxLqcI22Nu9PsgWv7KFY%3D&reserved=0> 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<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-lear-opsawg-mud-sbom-00.txt&data=02%7C01%7Cscott.rose%40nist.gov%7Ce0b6a55966834e5af8cb08d81e59cb44%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637292718321549766&sdata=poECJf9KadZ54oWW7Mx%2BM79ZOJrnYKemTTmOCkbSIPM%3D&reserved=0> > Status: > https://datatracker.ietf.org/doc/draft-lear-opsawg-mud-sbom/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-lear-opsawg-mud-sbom%2F&data=02%7C01%7Cscott.rose%40nist.gov%7Ce0b6a55966834e5af8cb08d81e59cb44%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637292718321559723&sdata=kLnJAflZ5D%2BU%2Bp%2BQnix18iMUnupEVsFs6wi6YUQdKwU%3D&reserved=0> > Htmlized: > https://tools.ietf.org/html/draft-lear-opsawg-mud-sbom-00<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-lear-opsawg-mud-sbom-00&data=02%7C01%7Cscott.rose%40nist.gov%7Ce0b6a55966834e5af8cb08d81e59cb44%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637292718321559723&sdata=AsARr%2BoONQH2aAPUz5ubjht1hYPlEsPnbHwoOj4EK0w%3D&reserved=0> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lear-opsawg-mud-sbom<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-lear-opsawg-mud-sbom&data=02%7C01%7Cscott.rose%40nist.gov%7Ce0b6a55966834e5af8cb08d81e59cb44%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637292718321559723&sdata=WLZF70S1NGCN%2BqBaLW1Hifi6uY6xGNWC3pZxSunKTLs%3D&reserved=0> > > > 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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Cscott.rose%40nist.gov%7Ce0b6a55966834e5af8cb08d81e59cb44%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637292718321569674&sdata=rn%2F5S1woz3ggmkNtsPMPm4krWxP2fSyiBilDJGGYRsc%3D&reserved=0>. > > 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
