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

[Dick Brooks <[e-mail]>]

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: [e-mail]
Tel: [phone]

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


Hannes Tschofenig <[e-mail]> 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.)

    > 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.

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 <[e-mail]>, Sandelman Software Works  -=
IPv6 IoT consulting =-