Subject: [Suit] How are firmware and firmware versions expressed in manifest?

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 3 Jun 2020 09:22:41 +0000

Hi all,

in his review of the recent manifest draft Saad (on CC) pointed out that it is not clear how the firmware version is identified in the manifest. This is a good question and I thought I bring up to the group. It turns out that there are different use cases that require identification of different pieces of software and here is a list of what I consider relevant:

* The manifest needs to point to a location where to obtain the firmware. This is accomplished with a URL. Section 7.3 describes an example (look for the uri parameters directive).

* There is the digest of the firmware, which is used for security purposes, and there is an example in Section 7.3 (look for the image digest parameters directive).

* Then, there is also the component id, which indicates where to store the software / image. We discussed this recently in the context of TEEP where the binaries of trusted applications are protected with the manifest and those binaries will typically end up on a file system. In the OP-TEE secure world OS those binaries are stored with the UUIDs in their file name. In a low end IoT device, like a Cortex M class processor, there is typically no file system and hence the firmware image ends up in a flash memory slot.

* There is also the case with a differential update where the manifest needs to indicate to what firmware images the differential update can be applied to. This is accomplished with the image match condition.

* Finally, there is also a version condition. This allows to express that a manifest is applicable to one or multiple versions of the firmware. As described in the information model draft, this situation occurs when you upload an application that relies on existing software to be present on the device. (Think of it as an API version.)

It is important to note that the manifest is not meant to be used to describe the software running on the device. This is the job of other tools, such as COSWID. The manifest instead provides instructions on how to update firmware and to accomplish secure boot.

Is this a topic that needs to be better described in the draft?

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 3 Jun 2020 13:57:01 -0400

My Company provides Risk Assessment software to the US Electric Industry to
meet NERC CIP-010-3 R1, Part 1.6 software integrity and authenticity and
verification standards across the software supply chain; my comments pertain
specifically to this use case.

See responses inline: DB>>

Thanks,

Dick Brooks

 <https://reliableenergyanalytics.com/products> Never trust software, always
verify and report! T

 <http://www.reliableenergyanalytics.com/>
http://www.reliableenergyanalytics.com

Email:  <mailto:[email-masked]>
[email-masked]

Tel: +1 978-696-1788

From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, June 03, 2020 5:23 AM
To: [email-masked]
Cc: Saad EL JAOUHARI <[email-masked]>
Subject: [Suit] How are firmware and firmware versions expressed in
manifest?

Hi all, 

in his review of the recent manifest draft Saad (on CC) pointed out that it
is not clear how the firmware version is identified in the manifest. This is
a good question and I thought I bring up to the group. It turns out that
there are different use cases that require identification of different
pieces of software and here is a list of what I consider relevant: 

DB>> Risk assessments for NERC CIP-010-3 R1, Part 1.6 require corroborating
evidence to establish trust in a software object. It's important that the
identification marks within a software object be consistent across domains.
The data in the installation file must match data in the digital signature
and metadata within vulnerability databases so that we can get accurate risk
assessments. 

* The manifest needs to point to a location where to obtain the firmware.
This is accomplished with a URL. Section 7.3 describes an example (look for
the uri parameters directive).

DB>> The "Trusted Source Location URL" where the "real/trusted" software
object is available is vitally important for an effective NERC CIP-010-3
risk assessment. This is part of the corroborating evidence that's needed.

* There is the digest of the firmware, which is used for security purposes,
and there is an example in Section 7.3 (look for the image digest parameters
directive). 

* Then, there is also the component id, which indicates where to store the
software / image. We discussed this recently in the context of TEEP where
the binaries of trusted applications are protected with the manifest and
those binaries will typically end up on a file system. In the OP-TEE secure
world OS those binaries are stored with the UUIDs in their file name. In a
low end IoT device, like a Cortex M class processor, there is typically no
file system and hence the firmware image ends up in a flash memory slot. 

* There is also the case with a differential update where the manifest needs
to indicate to what firmware images the differential update can be applied
to. This is accomplished with the image match condition.

DB>>Patches/Updates must contain clear metadata that can be correlated with
a specific software object that represents the original installation, and
other patch dependencies that must be in place for a successful deployment.
A  "Trusted Source Location URL" is also required, for CIP-010-3 software
integrity and authenticity risk assessments.

* Finally, there is also a version condition. This allows to express that a
manifest is applicable to one or multiple versions of the firmware. As
described in the information model draft, this situation occurs when you
upload an application that relies on existing software to be present on the
device. (Think of it as an API version.)

It is important to note that the manifest is not meant to be used to
describe the software running on the device. This is the job of other tools,
such as COSWID. The manifest instead provides instructions on how to update
firmware and to accomplish secure boot. 

DB>> I'm hoping to use the manifest as a virtual SBOM. Will let you know if
I'm successful in this regard. 

DB>> I believe so.

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Jun 2020 16:44:43 +0000

Hi Dick,

Thanks for the review comments and for the pointer to NERC CIP-010-3.

Please see my comments below:

~~ snip~~

Hi all,

DB>> Risk assessments for NERC CIP-010-3 R1, Part 1.6 require corroborating evidence to establish trust in a software object. It's important that the identification marks within a software object be consistent across domains. The data in the installation file must match data in the digital signature and metadata within vulnerability databases so that we can get accurate risk assessments.

[Hannes] Looking at Part 1.6 I see two requirements, namely: 1.6.1. Verify the identity of the software source; and 1.6.2. Verify the integrity of the software obtained from the software source.

This is certainly met by the digital signature covering the manifest (provided by the COSE wrapper) and the manifest also includes the digest of the firmware/software, which ensures the integrity of it.

Part 1.6 then goes on and says: "An example of evidence may include, but is not limited to a change request record that demonstrates the verification of identity of the software source and integrity of the software was performed prior to the baseline change or a process which documents the mechanisms in place that would automatically ensure the identity of the software source and integrity of the software."

I am not sure about this part and whether it there is something needed in addition to what we already have in the previously mentioned security wrapper.

DB>> The "Trusted Source Location URL" where the "real/trusted" software object is available is vitally important for an effective NERC CIP-010-3 risk assessment. This is part of the corroborating evidence that's needed.

[Hannes] The URL is included in the manifest and, while there is a way to override it (assuming proper authorization). Since the software/firmware is, as mentioned above, also integrity protected there is another layer of defense provided.

DB>>Patches/Updates must contain clear metadata that can be correlated with a specific software object that represents the original installation, and other patch dependencies that must be in place for a successful deployment. A  "Trusted Source Location URL" is also required, for CIP-010-3 software integrity and authenticity risk assessments.

[Hannes] This is indeed provided and I think we are good there. We should probably add an example.

DB>> I'm hoping to use the manifest as a virtual SBOM. Will let you know if I'm successful in this regard.

[Hannes] Thanks, feedback would be highly appreciated.

DB>> I believe so.

[Hannes] I will give it a try and post text for a new section to the list.

Thanks for the feedback.

Ciao
Hannes

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 4 Jun 2020 13:24:10 -0400

Thanks, Hannes - I very much appreciate your thoughts and insights; my
responses are shown inline DB2>>

Thanks,

Dick Brooks

Tel: +1 978-696-1788

From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Thursday, June 04, 2020 12:45 PM
To: Dick Brooks <[email-masked]>; [email-masked]
Cc: 'Saad EL JAOUHARI' <[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in
manifest?

Hi Dick, 

~~ snip~~ 

Hi all, 

 

[Hannes] Looking at Part 1.6 I see two requirements, namely: 1.6.1. Verify
the identity of the software source; and 1.6.2. Verify the integrity of the
software obtained from the software source.

This is certainly met by the digital signature covering the manifest
(provided by the COSE wrapper) and the manifest also includes the digest of
the firmware/software, which ensures the integrity of it. 

Part 1.6 then goes on and says: "An example of evidence may include, but is
not limited to a change request record that demonstrates the verification of
identity of the software source and integrity of the software was performed
prior to the baseline change or a process which documents the mechanisms in
place that would automatically ensure the identity of the software source
and integrity of the software."

I am not sure about this part and whether it there is something needed in
addition to what we already have in the previously mentioned security
wrapper. 

DB2>>You have to look a little deeper to understand what it means to
"verify" identity and authenticity (see page 36 of CIP-010-3 technical
guidelines for software verification for more detail). A digitally signed
object can still carry malware, so it takes more digging to conduct an
effective verification than simply relying on a digitally singed object
(which could contain a contaminated library in the build process - hopefully
not).

 

[Hannes] The URL is included in the manifest and, while there is a way to
override it (assuming proper authorization). Since the software/firmware is,
as mentioned above, also integrity protected there is another layer of
defense provided.

DB2>>Does the URL include the path+filename of the actual software object
being downloaded? If yes, this would be very useful information.

[Hannes] This is indeed provided and I think we are good there. We should
probably add an example. 

DB2>>This is very good to know. Thanks for the insights. An example would be
very helpful.

 

DB>> I believe so.

DB2>> I'm also curious to know if SUIT will work for FPGA bitstreams - do
you know? This one is turning out to be a tough nut to crack - very little
info on FPGA bitstreams metadata (i.e. embedded IP could be concerning). I
welcome any advice you can offer on this point.

Thanks for the feedback. 

Ciao

Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jun 2020 20:32:09 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > * Finally, there is also a version condition. This allows to express
    > that a manifest is applicable to one or multiple versions of the
    > firmware. As described in the information model draft, this situation
    > occurs when you upload an application that relies on existing software
    > to be present on the device. (Think of it as an API version.)

    > describe the software running on the device. This is the job of other
    > tools, such as COSWID. The manifest instead provides instructions on
    > how to update firmware and to accomplish secure boot.

There are some efforts to include RFC8520 (MUD) definitions into the
Manifest, either by value or reference. (Henk!)

There are other efforts to include CoSWID into RFC8520, I think.
I may be mistaken as to the direction of the arrows here.

    DB> I'm hoping to use the manifest as a virtual SBOM. Will let you know
    DB> if I'm successful in this regard.

The manifest could include a reference to a SBOM, but I don't think it is
reasonable to to include it by value.  I think that the right place to get
the SBOM is via an RFC8520 (MUD) object.

I think that it would help if SUIT considered how some BCPs and/or
Applicability statements that helped to tie some things together.
(Specifically, from the charter:
       This group will not define any new transport or discovery mechanisms,
       but may describe how to use existing mechanisms within the architecture.
)
A lot of Enterprises would like to cache all firmware contents somewhere
locally, avoiding external access for devices.  There is an overlap here
with processes that might report on success updates, caching the new SBOMs
into an audit system, etc.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 5 Jun 2020 09:11:28 -0400

Thanks, Michael Richardson. I'm uncertain that MUD has exactly what I'm
looking for to meet NERC CIP-010-3 R1, Part 1.6 expectations, after a
cursory look at the standard. I don't see where the MUD process would
support deep introspection and corroborating evidence within a risk
assessment control prior to deployment, which is what I need for NERC
CIP-010-3. The base case I'm working with is where a device in the Bulk
Electric System (BES) has been acquired and deployed, that contains a
firmware component. A patch has been distributed for that firmware and a
grid operator wants to perform a risk assessment on the patch before any
attempt at deployment. 

I'm still thinking that SUIT may be more appropriate than MUD for this use
case, but I may be missing an important point. Can you provide a distinction
between MUD and SUIT that would apply to the use case I describe, to help me
understand your assertion that MUD may be more appropriate than SUIT? 

I genuinely just want to find the best solution to the problem I'm trying to
solve, whatever that turns out to be.

Wonderful thing about standards, there are so many to choose from!

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Thursday, June 04, 2020 8:32 PM
To: Hannes Tschofenig <[email-masked]>; Dick Brooks
<[email-masked]>; [email-masked]; 'Saad EL JAOUHARI'
<[email-masked]>; Eliot Lear <[email-masked]>; Henk Birkholz
<[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in
manifest?

       but may describe how to use existing mechanisms within the
architecture.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Jun 2020 18:15:06 +0200

Dick,

Think of MUD as nothing more than a JSON blob that points at things or otherwise provides guidance to the deployment about the device.  It’s quite generic.  One of the things it can point to is how to retrieve a software bill of materials.  Another thing it can point to is a list of certifications.  If JSON scares you, it wouldn’t be that hard to serialize into CBOR.

Eliot

> On 5 Jun 2020, at 15:11, Dick Brooks <[email-masked]> wrote:
>

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 5 Jun 2020 13:22:11 -0400

Thanks, Eliot. JSON is a fine medium. 

Will the MUD/JSON blob exist within the same sphere of provenance as the actual software object it describes? The chain of trust is key for both the software/firmware object and it's MUD metadata. Ideally the integrity and authenticity "lock" covers both objects. 

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Eliot Lear <[email-masked]> 
Sent: Friday, June 05, 2020 12:15 PM
To: Dick Brooks <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]; Saad EL JAOUHARI <[email-masked]>; Henk Birkholz <[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Dick,

Eliot

> Thanks, Michael Richardson. I'm uncertain that MUD has exactly what 
> I'm looking for to meet NERC CIP-010-3 R1, Part 1.6 expectations, 
> after a cursory look at the standard. I don't see where the MUD 
> process would support deep introspection and corroborating evidence 
> within a risk assessment control prior to deployment, which is what I 
> need for NERC CIP-010-3. The base case I'm working with is where a 
> device in the Bulk Electric System (BES) has been acquired and 
> deployed, that contains a firmware component. A patch has been 
> distributed for that firmware and a grid operator wants to perform a 
> risk assessment on the patch before any attempt at deployment.
> 
> I'm still thinking that SUIT may be more appropriate than MUD for this 
> use case, but I may be missing an important point. Can you provide a 
> distinction between MUD and SUIT that would apply to the use case I 
> describe, to help me understand your assertion that MUD may be more appropriate than SUIT?
> 
> I genuinely just want to find the best solution to the problem I'm 
> trying to solve, whatever that turns out to be.
> 

> Subject: Re: [Suit] How are firmware and firmware versions expressed 
> in manifest?
> 
> 
>> occurs when you upload an application that relies on existing 
>> software to be present on the device. (Think of it as an API 
>> version.)
> 
> The manifest could include a reference to a SBOM, but I don't think it 
> is reasonable to to include it by value.  I think that the right place 
> to get the SBOM is via an RFC8520 (MUD) object.
> 
> A lot of Enterprises would like to cache all firmware contents 
> somewhere locally, avoiding external access for devices.  There is an 
> overlap here with processes that might report on success updates, 
> caching the new SBOMs into an audit system, etc.
> 
> --
> -=

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 5 Jun 2020 17:30:55 +0000

FWIW I thought that COSWID would provide information about the software libraries on a device.

-----Original Message-----
From: Eliot Lear <[email-masked]>
Sent: Friday, June 5, 2020 6:15 PM
To: Dick Brooks <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]; Saad EL JAOUHARI <[email-masked]>; Henk Birkholz <[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Dick,

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jun 2020 13:36:28 -0400

Dick Brooks <[email-masked]> wrote:
    > CIP-010-3.

It does not offer any of those things.

It offers an attribute/value mechanism signed by the manufacturer, possibly
specific to a given firmware revision, in which you can put a pointer to
some kind of SBOM that would provide you the right information.

We can also do this from the SUIT Manifest, but I suspect that the extra
layer of indirection will benefit the ecosystems.

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 5 Jun 2020 13:41:18 -0400

Thank you, Michael. I need to think through this a bit more.

Thanks to all for your insights.

Thanks,

Dick Brooks

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Friday, June 05, 2020 1:36 PM
To: Dick Brooks <[email-masked]>
Cc: 'Hannes Tschofenig' <[email-masked]>; [email-masked]; 'Saad EL
JAOUHARI' <[email-masked]>; 'Eliot Lear' <[email-masked]>; 'Henk
Birkholz' <[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in
manifest?

    > Thanks, Michael Richardson. I'm uncertain that MUD has exactly what
I'm

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jun 2020 17:37:53 -0400

> FWIW I thought that COSWID would provide information about the software

No, AFAIK, it just identifies the materials. (i.e. "libcurl 1.0.2")

Assembling them into a BOM requires another process:
  "curl 1.0.2" contains "libcurl 1.0.2", "curl-main",
                        "libssl 1.1.1f", "glibc 2.19", "pcre 1.0.2"

I could mis-understand though.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 5 Jun 2020 17:55:15 -0400

Here's an example of a "manufactured" SBOM that my SW creates today as part
of a CIP-010-3 risk assessment, which I'm hoping to produce from a firmware
object following SUIT/MUD:

Performing program introspection for risks...
*************** PROPERTIES *******************
----> Manufacturer : Microsoft
----> ProductCode : {B6B7DDDB-1FF6-47F6-AB32-457052610E19}
----> ProductName : PowerToys (Preview)
----> ProductVersion : 0.15.2
*************** FILES AND COMPONENTS *******************
----> Executable; FileName:  ruguzy_l.exe|PowerToys.exe  in module:
powertoys_exe
----> Executable; FileName:  h-ey7k2x.exe|PowerToysSettings.exe  in module:
settings_exe
----> Executable; FileName:  syxida6a.dll|Notifications.dll  in module:
notifications_dll
----> Executable; FileName:  _6j56zho.dll|shortcut_guide.dll  in module:
Module_ShortcutGuide
----> Executable; FileName:  3xugv-xs.dll|fancyzones.dll  in module:
Module_FancyZones
----> Executable; FileName:  big0xqbx.dll|PowerRenameExt.dll  in module:
Module_PowerRename
----> Executable; FileName:  bundle.js  in module:  settings_js_bundle
----> Executable; FileName:  mdhcn61j.exe|FancyZonesEditor.exe  in module:
Module_FancyZones
----> Executable; FileName:  9bdoaowy.dll|ControlzEx.dll  in module:
Module_FancyZones
----> Executable; FileName:  eb2enddq.dll|MahApps.Metro.dll  in module:
Module_FancyZones
----> Executable; FileName:  p_v6yvui.dll|Microsoft.Xaml.Behaviors.dll  in
module:  Module_FancyZones
----> Executable; FileName:  jve_oxvy.dll|Microsoft.Bcl.AsyncInterfaces.dll
in module:  Module_FancyZones
----> Executable; FileName:  qmwo-wq3.dll|System.Buffers.dll  in module:
Module_FancyZones
----> Executable; FileName:  cmhozp3b.dll|System.Memory.dll  in module:
Module_FancyZones
----> Executable; FileName:  dfjkhcy2.dll|System.Numerics.Vectors.dll  in
module:  Module_FancyZones
----> Executable; FileName:
p781ucha.dll|System.Runtime.CompilerServices.Unsafe.dll  in module:
Module_FancyZones
----> Executable; FileName:  yrific62.dll|System.Text.Encodings.Web.dll  in
module:  Module_FancyZones
----> Executable; FileName:  dwnfqiw_.dll|System.Text.Json.dll  in module:
Module_FancyZones
----> Executable; FileName:
fut-sab_.dll|System.Threading.Tasks.Extensions.dll  in module:
Module_FancyZones
----> Executable; FileName:  6cuycogx.dll|System.ValueTuple.dll  in module:
Module_FancyZones
A trust score of: 86.0 has been calculated for this step. Do you wish to
assign a passing grade (Y)/N?

Thanks,

Dick Brooks

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Friday, June 05, 2020 5:38 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Eliot Lear <[email-masked]>; Dick Brooks
<[email-masked]>; [email-masked]; Saad EL JAOUHARI
<[email-masked]>; Henk Birkholz <[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in
manifest?

Hannes Tschofenig <[email-masked]> wrote:
    > FWIW I thought that COSWID would provide information about the
software
    > libraries on a device.

--
]               Never tell me the odds!                 | ipv6 mesh networks
[
]   Michael Richardson, Sandelman Software Works        |    IoT architect
[
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails
[

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 6 Jun 2020 08:19:37 +0000

I think the BOM terminology is misleading because hardware is not software. The bill of material to produce an IoT product typically does not change (unless you desolder parts) while the software and configuration will regularly change.

Leaving that aside, I believe someone active in COSWID needs to clarify what COSWID does. My understanding was that it documents the software libraries on devices. Whether it would be " libcurl 1.0.2" alone or all the libraries that are used to build "libcurl 1.0.2" is a granularity question that the COSWID specs should / could also answer. That's why I thought it would be useful to have it included in the manifest (as supplementary information; as a severable field).

If COSWID does not do this then someone needs to explain to me what purpose it serves.

Ciao
Hannes

---

From: Eliot Lear <[email-masked]>
Date: Sat, 6 Jun 2020 11:03:54 +0200

The NTIA is conducting an effort relatied to this known as SBOM (Software Bill of Materials).  They are in trials with healthcare delivery organizations (HDOs) medical device manufacturers (MDMs) and software providers, including people from the Linux Foundation.  There are several different formats discussed, including Software ID Tags (SWID) (ISO-19770) and Software Package Data Exchange (SPDX) which looks very much like what you showed, Dick.  NTIA takes no position on what formats are used.  NIST is planning to move toward SWID as they transition away from the structure used in the National Vulnerability Database (NVD).  I take no position on which of these formats is better, so long as a downstream consumer can easily determine which format is being presented ;-)

The goal of SBOM is to provide transparency throughout the supply chain as to what is running on an IoT device.  SBOMs at a minimum are intended to provide a manifest, and then optionally some additional stuff like a dependency graph, licensing information, and maybe some additional security attributes such as access requirements, and links assertions about whether a particular component has a vulnerability or has been patched.

The US FDA is planning to require SBOMs as a part of pre-sales qualification.

There are great many open issues with regard to SBOMs, some of which this group and the TEEP folk may wish to pursue.  The biggest issue is around naming.  When referring to Java, is that com.sun.java or com.oracle.java or does it matter?  When referring to a supplier, is that IBM or Red Hat (or if it’s REALLY old software, Cygnus)?

A similar issue arises with versioning.  Is that openssl 1.0.1 version patched or unpatched and how does one know?

Another issue is how an SBOM is retrieved.  What is its well known location?  Does the BOM reside on the device, and is there an interface to retrieve it?  If not, where else is it?  Is it even retrievable?  Does it require permissions to do so if it resides at a vendor locale, and if so, how is versioning managed?

This is the basis for draft-lear-opsawg-mud-sbom-00.txt that Scott Rose from NIST and I put together, and would like to present at opsawg.  The goal of that draft is simply a means o discovery to determine how to retrieve an SBOM.  An example of how one would use this extension for an on-the-box approach in its simplest form would be that the manufacturer advertises a RESTful interface at /.well-known/sbom and returns its favorite format (let’s say SPDX).  The back end interface could be as simple as ‘cat /var/lib/dkpg/installed’ or perhaps a bit more complex using a more secure interface to retrieve a signed manifest.

Anyway, I provide this information mostly without fully understanding the context here, but it seems relevant, given the line of discussion.  NTIA project information can be found at https://www.ntia.doc.gov/SoftwareTransparency.

Eliot

> On 6 Jun 2020, at 10:19, Hannes Tschofenig <[email-masked]> wrote:
> 
> From: Michael Richardson <[email-masked] <mailto:[email-masked]>>
> To: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> Cc: Eliot Lear <[email-masked] <mailto:[email-masked]>>; Dick Brooks <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Saad EL JAOUHARI <[email-masked] <mailto:[email-masked]>>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 6 Jun 2020 10:03:10 +0000

Thanks, Eliot. This is very useful background on the terminology. I have hear about this NTIA effort but didn’t follow it.
I am not surprised that you already wrote a draft about it. Thanks for the pointer.

Ciao
Hannes

PS: I am still wondering how COSWID fits into all of this now.

From: Eliot Lear <[email-masked]>
Sent: Saturday, June 6, 2020 11:04 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Dick Brooks <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Eliot

On 6 Jun 2020, at 10:19, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Sent: Friday, June 5, 2020 11:38 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Eliot Lear <[email-masked]<mailto:[email-masked]>>; Dick Brooks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Saad EL JAOUHARI <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

FWIW I thought that COSWID would provide information about the software
libraries on a device.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Dick Brooks" <[email-masked]>
Date: Sat, 6 Jun 2020 09:52:47 -0400

Thank you, Eliot. That was very insightful and useful. I’ll check out the ntia work – looks promising.

Thanks,

Dick Brooks

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[email-masked]> [email-masked]

Tel: +1 978-696-1788

Sent: Saturday, June 06, 2020 5:04 AM

Eliot

On 6 Jun 2020, at 10:19, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

Ciao
Hannes

-----Original Message-----
From: Michael Richardson < <mailto:[email-masked]> [email-masked]>
Sent: Friday, June 5, 2020 11:38 PM
To: Hannes Tschofenig < <mailto:[email-masked]> [email-masked]>
Cc: Eliot Lear < <mailto:[email-masked]> [email-masked]>; Dick Brooks < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]; Saad EL JAOUHARI < <mailto:[email-masked]> [email-masked]>; Henk Birkholz < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked] <mailto:[email-masked]>   http://www.sandelman.ca/        |   ruby on rails    [

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 6 Jun 2020 19:00:24 +0200

Hi all,

my comment preliminary about this is (as my previous comment seems to 
have been gobbled up by something) is basically this:

Yes. In summary (my previous, gobbled up comment was more elaborate):

* SBOM seems to be a sub-set of CoSWID, and
* a co-author of CosSWID is a member of the NTIA SBOM group.

> ----> Executable; FileName:  syxida6a.dll|Notifications.dll  in module:

I am rather sure that CoSWID can represent exactly this sub-set of of 
application context. In general, CoSWID are more on the semantic 
inter-operational side of things (in contrast of SBOM). In essnece, 
CoSWID can express this SBOM context. The question here is (,I think), 
if SBOM efforts intend to go down into this lane of representation context.

We can talk more about this. But while CoSWID in fact incorporates the 
SBOM context, I wonder if the strict prescriptions of CoSWID are in fact 
appropriate for the rather loose context of expressiveness of SBOM.

If your target of SBOM is - effectually - resilient and reliable 
post-processing, then CoSWID is seems to be a viable candidate.

If your goal is to convey a rather unspecified set of software 
components via a loose set of attributes (which I think SBOM is all 
about today), CoSWID seems to be way too specific due to the 
corresponding goal of semantic interoperability. please correct me, if I 
am wrong here.

Viele Grüße,

Henk

On 06.06.20 12:03, Hannes Tschofenig wrote:
> Thanks, Eliot. This is very useful background on the terminology. I have 
> hear about this NTIA effort but didn’t follow it.
> 
> *From:* Eliot Lear <[email-masked]>
> *Sent:* Saturday, June 6, 2020 11:04 AM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; Dick Brooks 
> <[email-masked]>; [email-masked]; Henk Birkholz 
> *Subject:* Re: [Suit] How are firmware and firmware versions expressed 
> in manifest?
> 
> The NTIA is conducting an effort relatied to this known as SBOM 
> (Software Bill of Materials).  They are in trials with healthcare 
> delivery organizations (HDOs) medical device manufacturers (MDMs) and 
> software providers, including people from the Linux Foundation.  There 
> are several different formats discussed, including Software ID Tags 
> (SWID) (ISO-19770) and Software Package Data Exchange (SPDX) which looks 
> very much like what you showed, Dick.  NTIA takes no position on what 
> formats are used.  NIST is planning to move toward SWID as they 
> transition away from the structure used in the National Vulnerability 
> Database (NVD).  I take no position on which of these formats is better, 
> so long as a downstream consumer can easily determine which format is 
> being presented ;-)
> 
> The goal of SBOM is to provide transparency throughout the supply chain 
> as to what is running on an IoT device.  SBOMs at a minimum are intended 
> to provide a manifest, and then optionally some additional stuff like a 
> dependency graph, licensing information, and maybe some additional 
> security attributes such as access requirements, and links assertions 
> about whether a particular component has a vulnerability or has been 
> patched.
> 
> There are great many open issues with regard to SBOMs, some of which 
> this group and the TEEP folk may wish to pursue.  The biggest issue is 
> around naming.  When referring to Java, is that com.sun.java or 
> com.oracle.java or does it matter?  When referring to a supplier, is 
> that IBM or Red Hat (or if it’s REALLY old software, Cygnus)?
> 
> A similar issue arises with versioning.  Is that openssl 1.0.1 version 
> patched or unpatched and how does one know?
> 
> Another issue is how an SBOM is retrieved.  What is its well known 
> location?  Does the BOM reside on the device, and is there an interface 
> to retrieve it?  If not, where else is it?  Is it even retrievable? 
>   Does it require permissions to do so if it resides at a vendor locale, 
> and if so, how is versioning managed?
> 
> This is the basis for draft-lear-opsawg-mud-sbom-00.txt that Scott Rose 
> from NIST and I put together, and would like to present at opsawg.  The 
> goal of that draft is simply a means o discovery to determine how to 
> retrieve an SBOM.  An example of how one would use this extension for an 
> on-the-box approach in its simplest form would be that the manufacturer 
> advertises a RESTful interface at /.well-known/sbom and returns its 
> favorite format (let’s say SPDX).  The back end interface could be as 
> simple as ‘cat /var/lib/dkpg/installed’ or perhaps a bit more complex 
> using a more secure interface to retrieve a signed manifest.
> 
> Anyway, I provide this information mostly without fully understanding 
> the context here, but it seems relevant, given the line of discussion. 
>   NTIA project information can be found at 
> https://www.ntia.doc.gov/SoftwareTransparency.
> 
> Eliot
> 
> 
> 
>     On 6 Jun 2020, at 10:19, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I think the BOM terminology is misleading because hardware is not
>     software. The bill of material to produce an IoT product typically
>     does not change (unless you desolder parts) while the software and
>     configuration will regularly change.
> 
>     Leaving that aside, I believe someone active in COSWID needs to
>     clarify what COSWID does. My understanding was that it documents the
>     software libraries on devices. Whether it would be " libcurl 1.0.2"
>     alone or all the libraries that are used to build "libcurl 1.0.2" is
>     a granularity question that the COSWID specs should / could also
>     answer. That's why I thought it would be useful to have it included
>     in the manifest (as supplementary information; as a severable field).
> 
>     Cc: Eliot Lear <[email-masked] <mailto:[email-masked]>>; Dick Brooks
>     <[email-masked]
>     <mailto:[email-masked]>>;[email-masked]
>     <mailto:[email-masked]>; Saad EL JAOUHARI <[email-masked]
>     <mailto:[email-masked]>>; Henk Birkholz
>     <[email-masked]
>     <mailto:[email-masked]>>
>     Hannes Tschofenig <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     ] [email-masked] <mailto:[email-masked]>
>     http://www.sandelman.ca/        |   ruby on rails    [
> 
>     recipient, please notify the sender immediately and do not disclose
>     the contents to any other person, use it for any purpose, or store
>     or copy the information in any medium. Thank you.
> 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.

---

From: "Dick Brooks" <[email-masked]>
Date: Sat, 6 Jun 2020 15:14:14 -0400

Henk,

Thanks for raising the question of context, it goes directly to the point of what purpose an SBOM serves.

My case is very specific to performing US Bulk Electric System NERC CIP0-010-3 R1, Part 1.6 software integrity and authenticity verification using a risk assessment control function. I'm guessing that my requirements may not represent the broader audience. 

The main philosophical underpinnings of this risk assessment are: 
- Collect corroborating evidence from data gathered throughout the risk assessment to assign a trust score, called a SAGScore(TM) that enables a party to make a risk based decision to install/not install a software object;
- A software object is presumed guilty until proven innocent; 
- Never trust software, always verify and report!(TM)

The risk assessment software introspection function uses the SBOM as the baseline for establishing the product developer, product name/identifier, version, release date and component parts that are contained within the software object. This information is used to start the investigation/risk assessment. Corroborating evidence confirming the integrated file SBOM contents align with other information gathered during procurement negotiations and other "ground truth", are used to determine a trust score. The integral SBOM also aids in the identification of malware and vulnerabilities that may be embedded in the software object, which the original developer may not even be aware of. I want the ability to initiate a vulnerability search using the SBOM contents and this requires alignment of the SBOM metadata across  CVE databases and domains.

CVE search engines have a very poor signal/noise ratio, based on my experience. One vendor is starting a new vulnerability search operation, Rapid 7 AttackerKB, that I've asked to include parameter based search capabilities using an expressive language, i.e. sql, to search for vulns using parameters such as component filename, product name, version identifier, legal vendor name and source location URL, using data obtained from an integrated SBOM. I'm hoping this will improve the signal/noise ratio of CVE search results - don't know if this will be delivered, but I have put in my wish list. Ideally values found in the SBOM will align with those kept in the CVE databases.

To summarize, I'm hoping to use a "integrated firmware level SBOM" as the primary information source that must be validated and proven trustworthy through the use of a corroborating evidence algorithm, triangulated among several data sources, including CVE and "known malware" databases. 

I know some people are looking to use an SBOM in license management, but that is not my case. I'm looking to keep bad software from being installed in the US Bulk Electric System and the integrated SBOM of a downloaded software object is my starting point for the risk assessment.

Thanks to everyone that has contributed their time, talent, knowledge and experience to this discussion; it is truly appreciated.

Thanks,

Dick Brooks

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Saturday, June 06, 2020 1:00 PM
To: Hannes Tschofenig <[email-masked]>; Eliot Lear <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Dick Brooks <[email-masked]>; [email-masked]
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Hi all,

my comment preliminary about this is (as my previous comment seems to have been gobbled up by something) is basically this:

Effectively, as I tried to post previously, I am looking at this:

> ----> ProductName : PowerToys (Preview) ProductVersion : 0.15.2

I am rather sure that CoSWID can represent exactly this sub-set of of application context. In general, CoSWID are more on the semantic inter-operational side of things (in contrast of SBOM). In essnece, CoSWID can express this SBOM context. The question here is (,I think), if SBOM efforts intend to go down into this lane of representation context.

We can talk more about this. But while CoSWID in fact incorporates the SBOM context, I wonder if the strict prescriptions of CoSWID are in fact appropriate for the rather loose context of expressiveness of SBOM.

If your target of SBOM is - effectually - resilient and reliable post-processing, then CoSWID is seems to be a viable candidate.

If your goal is to convey a rather unspecified set of software components via a loose set of attributes (which I think SBOM is all about today), CoSWID seems to be way too specific due to the corresponding goal of semantic interoperability. please correct me, if I am wrong here.

Viele Grüße,

Henk

On 06.06.20 12:03, Hannes Tschofenig wrote:
> Thanks, Eliot. This is very useful background on the terminology. I 
> have hear about this NTIA effort but didn’t follow it.
> 
> (SWID) (ISO-19770) and Software Package Data Exchange (SPDX) which 
> looks very much like what you showed, Dick.  NTIA takes no position on 
> what formats are used.  NIST is planning to move toward SWID as they 
> Database (NVD).  I take no position on which of these formats is 
> better, so long as a downstream consumer can easily determine which 
> format is being presented ;-)
> 
> The goal of SBOM is to provide transparency throughout the supply 
> chain as to what is running on an IoT device.  SBOMs at a minimum are 
> intended to provide a manifest, and then optionally some additional 
> stuff like a dependency graph, licensing information, and maybe some 
> additional security attributes such as access requirements, and links 
> assertions about whether a particular component has a vulnerability or 
> has been patched.
> 
> location?  Does the BOM reside on the device, and is there an 
> interface to retrieve it?  If not, where else is it?  Is it even retrievable?
>   Does it require permissions to do so if it resides at a vendor 
> locale, and if so, how is versioning managed?
> 
> This is the basis for draft-lear-opsawg-mud-sbom-00.txt that Scott 
> Rose from NIST and I put together, and would like to present at 
> opsawg.  The goal of that draft is simply a means o discovery to 
> determine how to retrieve an SBOM.  An example of how one would use 
> this extension for an on-the-box approach in its simplest form would 
> be that the manufacturer advertises a RESTful interface at 
> /.well-known/sbom and returns its favorite format (let’s say SPDX).  
> The back end interface could be as simple as ‘cat 
> /var/lib/dkpg/installed’ or perhaps a bit more complex using a more secure interface to retrieve a signed manifest.
> 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Jun 2020 18:59:18 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > software. The bill of material to produce an IoT product typically does
    > not change (unless you desolder parts) while the software and

This thinking is really a serious part of the problem that I think SBOM is
trying to address.

We think that the hardware does not change, because it's hardware, but it
does change, because it's a device with an MCU with code baked in by the
manufacturer.
*AND* hardware *DOES* change because there are line cards, expansion slots,
USB connectors that provide PCIe connectivity...

But, a TPM is good example of something one might call hardware, but it's got
a whole SoC in there with software.  That software could have bugs.

    > Leaving that aside, I believe someone active in COSWID needs to clarify
    > what COSWID does. My understanding was that it documents the software

Agreed.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 8 Jun 2020 11:27:38 +0000

Hi Michael,

Of course it depends a bit on the type of devices you look at. Many IoT devices are purpose built and they cannot be extended or the extension possibilities are extremely limited. It is not like a PC where you plug in PCI cards, add more DRAM chips, or swap out the processor. This is why an IoT product developed for precision farming will not become your smart vacuum cleaner the next day. RFC 7228 was written to explain that there are many IoT devices that are different to general purpose computing devices. We are mixing the properties of general purpose computing devices with the billions of low end IoT devices out there. Not only is the hardware different but also the software running on those devices. FWIW the software development process is also different.

I have to look at the links Eliot shared but I hope that people are not overly excited about the value of having information about what software version is on their devices for the purpose of drawing security conclusions. You have been at many hackathons where we created firmware for Cortex M-class devices and we used, for example, Mbed TLS in many instances. Does this tell you anything about the security? Can you draw conclusions when you hear that version X has a security vulnerability? Should you be concerned when a security researcher was able to mount a fault injection attack against a specific MCU with a specific version of Mbed TLS running on it? No, not really because you have to know what compile-time configurations were used to build the firmware, what hardware it is running on and what run-time configuration is present.

I understand that people want to have some easy way to find out whether their devices are secure but the story is obviously more complex. Not a surprise to you, for sure, but maybe for others who are not following the embedded development space.

Ciao
Hannes

PS: We are drifting a bit away from the actual manifest work done in this group ...

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Michael Richardson
Sent: Sunday, June 7, 2020 12:59 AM
To: [email-masked]
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

    > configuration will regularly change.

This thinking is really a serious part of the problem that I think SBOM is trying to address.

We think that the hardware does not change, because it's hardware, but it does change, because it's a device with an MCU with code baked in by the manufacturer.
*AND* hardware *DOES* change because there are line cards, expansion slots, USB connectors that provide PCIe connectivity...

But, a TPM is good example of something one might call hardware, but it's got a whole SoC in there with software.  That software could have bugs.

Agreed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jun 2020 07:21:43 +0000

Thanks, Henk, for sharing your views on this subject.

In the manifest we currently allow various pieces of information to be conveyed. Those are placed in severable fields, i.e. fields that can be removed from the manifest prior to forwarding it to the IoT device (without impacting the security wrapper).

We have extension points in the manifest (in the envelope to be more precise) to get other "encodings" / "formats" added in the future.

It sounds to me that this entire idea of describing software on a device is a still work in progress and further work is needed. Luckily, there is nothing in the manifest that depends on the process of this work. It would still be good, maybe in a separate document, to explain how this COSID & co is supposed to provide extra value.

Ciao
Hannes

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: Saturday, June 6, 2020 7:00 PM
To: Hannes Tschofenig <[email-masked]>; Eliot Lear <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Dick Brooks <[email-masked]>; [email-masked]
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Hi all,

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 9 Jun 2020 10:01:35 +0200

Hi Hannes,

the core definition of an ISO interoperable CoSWID is basically done. 
The work on extensions to use them as endorsements is done. Maybe some 
of this guidance on "describing software on a device" can go into the 
text about endorsements and reference values. We can talk more about a 
separate document whhile the CoSWID RIM and SUIT Manifests I-D progress.

There is an upcoming update to the design of severable fields that will 
homogenize the use of these fields via one CDDL group definition. In 
general, I think, it is likely that a CoSWID will reside in the envelope 
(and its digest in the signed manifest). I am rather sure that we will 
add a few sentences about that "where do these fields go and why do it 
this way" earlier than section 8/9 as that became a quite vital concept 
to how manifests are using COSE and why it can be okay to have 
"unsigned" serverable fields in the envelope, etc. Maybe even in the 
next I-D submission already.

Viele Grüße,

Henk

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Jun 2020 11:27:00 +0200

Hannes

> On 8 Jun 2020, at 13:27, Hannes Tschofenig <[email-masked]> wrote:
> 

Actually, the people who should be concerned are the manufacturers, who are going to receive calls from customers who have learned that the manufacturer used EmbedOS but didn’t know that the option in a particular device is disabled.  This is an aspect of SBOMs that is understood to be problematic, and so discussion is gradually shifting to something they call Vulnerability EXchange (VEX) (I hate the name, but as someone who created something called MUD I have no real leg to stand on).  The idea behind VEX, fuzzy as it is, is that one would be able to query to determine if the manufacturer has investigated and affirmatively determined whether a particular product has a particular vulnerability.  I like the concept, because in industrial much of the tooling is already flagging quite a lot of false positive CVEs.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jun 2020 11:52:43 +0000

I guess we have to wait and see how this will play out. My understanding is that the manifest can accommodate for all sorts of meta-data attachment and from that side we are doing fine.

Ciao
Hannes

From: Eliot Lear <[email-masked]>
Sent: Tuesday, June 9, 2020 11:27 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Hannes

On 8 Jun 2020, at 13:27, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Eliot

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 9 Jun 2020 10:18:20 -0400

I agree with Eliot on this point “I like the concept, because in industrial much of the tooling is already flagging quite a lot of false positive CVEs.”

The current vulnerability reporting domain has a very poor signal/noise ratio (lots of false positives) and the latency between vulnerability discovery and CVE data repository awareness can be significantly longer than it should be to effectively mitigate a vulnerability.

This is perhaps the biggest problem I’m facing, making it difficult to determine an accurate trustworthiness level (score) for a software object.

I have to agree; MUD – what were you drinking when that became the best choice?

Thanks,

Dick Brooks

Tel: +1 978-696-1788

From: Suit <[email-masked]> On Behalf Of Eliot Lear
Sent: Tuesday, June 09, 2020 5:27 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

Hannes

On 8 Jun 2020, at 13:27, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2020 12:40:15 -0400

Eliot Lear <[email-masked]> wrote:
    > stand on).  The idea behind VEX, fuzzy as it is, is that one would be
    > able to query to determine if the manufacturer has investigated and
    > affirmatively determined whether a particular product has a particular
    > vulnerability.  I like the concept, because in industrial much of the
    > tooling is already flagging quite a lot of false positive CVEs.

Let me tell you as an opensource software maintainer, that I get CVEs to
review that apply to version Y of product Z which is of class "SSL VPN",
and yet, the CVE people will pattern matched on "VPN", and assumed it
must apply to IPsec systems too.  The WTF level is ridiculous.
The cost of review is serious and signficant, particularly as the details are
often really hard to find.

VEX will be a good thing.
Being able to sign them would be awesome.