Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-lear-opsawg-mud-sbom-00.txt

From: "Rose, Scott W. (Fed)" <[email-masked]>
Date: Wed, 1 Jul 2020 14:50:53 +0000

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-masked]<mailto:[email-masked]>
ph: +1-301-975-8439
GVoice: +1-571-249-3671

From: "Yangjie (Jay, IP Standard)" <[email-masked]>
Date: Wednesday, July 1, 2020 at 12:00 AM
To: "[email-masked]" <[email-masked]>, "Rose, Scott W. (Fed)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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-masked]> 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%7Cf7b98d9579ae425f024a08d81d7354d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637291728475117803&sdata=4fzxnVpAobexz9lVjQHz1E%2FYCo5qdz6Friu5TcJ%2Fj1Q%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-masked]><mailto:&lt;[email-masked]&gt;>

> 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-masked]><mailto:&lt;[email-masked]&gt;>ov>, Eliot Lear <[email-masked]><mailto:&lt;[email-masked]&gt;>

> 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%7Cf7b98d9579ae425f024a08d81d7354d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637291728475122786&sdata=UXYF3UBRZM9I5VbguUOQkYK2csNdnBVKBah%2Bw%2FgGJh4%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%7Cf7b98d9579ae425f024a08d81d7354d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637291728475127759&sdata=gn023A8Kv7L3aqWR2cL%2FoNG48bE5X0cVOMDvwqB3SAc%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%7Cf7b98d9579ae425f024a08d81d7354d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637291728475132735&sdata=UmAZYy1R0227uGCbNwDjDWQxPgYqTX8QDzVJq2fwjxM%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%7Cf7b98d9579ae425f024a08d81d7354d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637291728475132735&sdata=wX8fCnkrV2R6RWOBFZJyiGP1zlGHC4rci%2BlILsucFHs%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%7Cf7b98d9579ae425f024a08d81d7354d0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637291728475137715&sdata=KTTCZmjXDkhdmBJnMjqQ%2FasNv1b%2BCPnBkwBn%2B1Qw5Xg%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,

杨杰 (Jay Yang)
数据通信标准专利部
Mobile: 13852295541
E-mail：[email-masked]<mailto:[email-masked]>
中国(China)-南京(Nanjing)-雨花台区软件大道101号华为南京基地N3-1F