Subject: [Mud] Some new stuff for mudmaker.org

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Mar 2020 15:41:29 +0100

Hi everyone,

As part of mudding, I’ve been talking to the SBOM people.  These are the folk who are looking to produce a software bill of materials for IOT devices.  The question: how to find it?  Well, MUD to the rescue.  I’ve added a very simple extension (no draft yet but working on it) that would describe just how to get the SBOM.

While I was at it…

I also made some changes as to what happens when you click on the “download” button.  Not only do you get a MUD file, but you also get a DEMO CMS signature file as well.  If you trust this signature for anything other than demonstration purposes, well…

I also have now a demonstration QR code that contains the MUDURL alone.  This would be suitable for sticking on a box or otherwise providing legacy equipment folk.  I have some issues with this.  The first is that just scanning it on your iPhone gets you a JSON file.  From a tooling perspective… that’s not slick.  Also, it’s sometimes unnecessary, given what Michael is planning, and what is going into DPP.  Also, I’m currently using a questionable Google API to generate the QR code.  But as I am a questionable guy, and this is really for demonstration purposes, I think this is ok.

You can try all of this out at https://mudmaker.org/sbom.

I am NOT quite ready to roll any of this out onto the main mudmaker page, but would very much appreciate your comments.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 23 Mar 2020 11:09:12 -0400

Hi Eliot,

On Mon, Mar 23, 2020 at 10:41 AM Eliot Lear <lear=[email-masked]>
wrote:

> Hi everyone,
>
> As part of mudding, I’ve been talking to the SBOM people.  These are the
> folk who are looking to produce a software bill of materials for IOT
> devices.  The question: how to find it?  Well, MUD to the rescue.  I’ve
> added a very simple extension (no draft yet but working on it) that would
> describe just how to get the SBOM.
>
>
 Less travel leads to more MIUDdling :-). There's always a silver lining.

I have a very basic question about the whole notion of mixing SBOM with
MUD. MUD was intended for network access control whereas SBOM is more for
ensuring software integrity. Should this be part of the MUD file or
included (for example) as a pointer in the device certificate so it can be
independent of MUD? Why include this as part of the MUD file?  I'd just
like to understand the motivation.

Stay healthy.

Thanks,

Ranga

>
> --
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud
>

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Mar 2020 16:20:31 +0100

Hi Ranga,

> On 23 Mar 2020, at 16:09, M. Ranganathan <[email-masked]> wrote:
> 
> I have a very basic question about the whole notion of mixing SBOM with MUD. MUD was intended for network access control whereas SBOM is more for ensuring software integrity. Should this be part of the MUD file or included (for example) as a pointer in the device certificate so it can be independent of MUD? Why include this as part of the MUD file?  I'd just like to understand the motivation.

There are several.  
First, they need some sort of a schema to describe how to get the SBOM in the first place, and if they’re going to go that far they will end up reproducing much of the MUD mechanism.  
Second, access control is just one use of MUD.  There are others, and this is one of them.  Another use that we are contemplating is a list of pointers to certification statements that organizations such as UL might make.  One could even envision a MUD file without ACLs, not that I would recommend it.  
Third, if you are going to produce an SBOM, it seems to me you OUGHT to describe what sort of access you expect the device to have so that if an adversary picks off the SBOM for that particular device or device type, you have some protection.
Fourth, if everyone does their own thing with device certificates they are going to bloat, and become operationally unmanageable. I’m not saying there isn’t room for more, but people should think of MUD more as a means to access various statements the vendor wants to make, and less about just ACLs.
Eliot

> 
> Stay healthy.
> 
> Thanks,
> 
> Ranga
>  
> 
> -- 
> Mud mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mud <https://www.ietf.org/mailman/listinfo/mud>
> 
> 
> -- 
> M. Ranganathan 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Mar 2020 17:45:07 -0400

Eliot Lear <lear=[email-masked]> wrote:
    > As part of mudding, I’ve been talking to the SBOM people.  These are
    > the folk who are looking to produce a software bill of materials for
    > IOT devices.  The question: how to find it?  Well, MUD to the rescue.
    > I’ve added a very simple extension (no draft yet but working on it)
    > that would describe just how to get the SBOM.

Right. SBOM... I came across this at FOSDEM and LPC relating to documenting
what is going into containers, which often pick and choose at the file level.
That seems very apropo for IoT devices, which will often do the same thing.
(And ideally, will be upgraded with some container tech, maybe...)

So I see that you have Cloud URL, Local URL and "On Request"
This seems about right to me. just a URL with the rest of the info.

    > I also made some changes as to what happens when you click on the
    > “download” button.  Not only do you get a MUD file, but you also get a
    > DEMO CMS signature file as well.  If you trust this signature for
    > anything other than demonstration purposes, well…

Good, but my open question about whether or not mud-signature is permitted to
be relative still unresolved :-)

    > I also have now a demonstration QR code that contains the MUDURL alone.
    > This would be suitable for sticking on a box or otherwise providing
    > legacy equipment folk.  I have some issues with this.  The first is
    > that just scanning it on your iPhone gets you a JSON file.  From a
    > tooling perspective… that’s not slick.  Also, it’s sometimes
    > unnecessary, given what Michael is planning, and what is going into
    > DPP.  Also, I’m currently using a questionable Google API to generate
    > the QR code.  But as I am a questionable guy, and this is really for
    > demonstration purposes, I think this is ok.

Eliot, I think that we need to figure out how this can go forward.
I haven't received confirmation that opsawg will give me time yet.
Regardless, I think that we need to have a bigger discussion.

Maybe this fits into the NIST Wednesday calls.
(feel free to invite me)

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Mar 2020 17:47:07 -0400

> like to understand the motivation.

For the same reason that the MUD file pointer in the IDevID presents update
problems.  The SBOM is directly connected to the firmware revision, while the
IDevID ought to live across firmware versions (and be hard to replace).

So, a pointer in the MUD definition to the SBOM means that it doesn't have to
be communicated from the device to the network in another way.

It seems like a fine extension to MUD to me.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Mar 2020 17:50:31 -0400

Eliot Lear <lear=[email-masked]> wrote:
    > One could even envision a MUD file without ACLs, not that
    > I would recommend it.

I can imagine a MUD file that just says, "I am a FOO controller"
(Otherwise, I have a fully functional web browser, please don't get in my way)

    > Third, if you are going to produce an SBOM, it seems to me you OUGHT to
    > describe what sort of access you expect the device to have so that if
    > an adversary picks off the SBOM for that particular device or device
    > type, you have some protection.

    > Fourth, if everyone does their own thing with device certificates they
    > are going to bloat, and become operationally unmanageable. I’m not
    > saying there isn’t room for more, but people should think of MUD more
    > as a means to access various statements the vendor wants to make, and
    > less about just ACLs.

+1

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 24 Mar 2020 18:39:57 -0400

> IDevID ought to live across firmware versions (and be hard to replace).

Makes sense now. Still wondering what the network would do with the
SBOM but that is a different thread.

Thanks,
Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Mar 2020 08:20:24 +0100

> On 24 Mar 2020, at 23:39, M. Ranganathan <[email-masked]> wrote:
>> 
> 

Oh no it’s not! ;-)

If your NMS can pick up the SBOM, then the next step is to compare packages and versions on the device with known CVEs.  At that point, you have to decide on remediation strategies.  In some cases, those remediation strategies may just suck.  Imagine a ventilator being vulnerable today.  But one clearly GOOD strategy would be to limit that ventilator’s exposure to attacks.  How might one go about doing that?  I wonder…

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Mar 2020 19:39:29 -0400

> If your NMS can pick up the SBOM, then the next step is to compare
    > packages and versions on the device with known CVEs.  At that point,
    > you have to decide on remediation strategies.  In some cases, those
    > remediation strategies may just suck.  Imagine a ventilator being
    > vulnerable today.  But one clearly GOOD strategy would be to limit that
    > ventilator’s exposure to attacks.  How might one go about doing that?
    > I wonder…

On that specific situation.
I really want to know what network needs a ventilator has other than
firmware updates, and some "mycontroller" connection.
If we assume that it already has a good MUD file, then I'm not sure I know
what immediate thing the network should do if there is a CVE.

Clearly, scheduling it for swap out is important, but you'd never shut it
down at that moment.  There is also a question about audit trail for when the
issue was noticed, when it upgrade was scheduled, when it actually was
upgraded, etc.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2020 08:59:41 +0100

> On 26 Mar 2020, at 00:39, Michael Richardson <[email-masked]> wrote:
> 
> 

It’s going to depend on the nature of the attack, of course, and how the abstractions have been filled out.  I agree with your general logic: either “controller” or “my-controller” are likely to be used.  In medical, I would expect that there will be a generic controller class that points to a nurse’s station.  We might even standardize that over time.  Let me give you an example of how a CVE might cause a MUD file update: suppose the attack is against a non-essential cloud service, like something that keeps statistics.  You might block that service in the MUD file.

> issue was noticed, when it upgrade was scheduled, when it actually was

Yes, the point of much of this is to provide a risk map to administrators, so they know who to yell at and when.  There are some issues with that, particularly false positives that have to be worked through (say, you backported a fix, but your SBOM doesn’t indicate it).  *Some* vulnerabilities may have similar remediation characteristics that the admin can use.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2020 10:28:06 +0100

So there’s one aspect that my early draft glosses over.  Great.  You have a URL, whatever it is.  The manufacturer is likely to want to authenticate you.  What’s the tooling flow?  I think it’s something like this:

MUD URL picked up by mud manager
Mud manager retrieves mud file, dispatches URL of the SBOM to an SBOM consumer of some form that we’ll just call an SBOM manager for the moment.
SBOM manager resolves URL first time.
It has no token to use.  
User must register.  Requires a browser interaction of some form, presumably with OAUTH.  Perfectly reasonable when the SBOM lives in the cloud.  OR
Token is received out of band for this service, either from the device itself, or from the manufacturer service if one is registered through that (requires browser interaction).
There is a token. Authenticate with that and retrieve.

I am thinking that when a token is received out of band for access to a resource, that is a generic exchange that goes well beyond this use case.  Carsten, Hannes, do you have views on any of this?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2020 12:48:32 -0400

Eliot Lear <lear=[email-masked]> wrote:
    > So there’s one aspect that my early draft glosses over.  Great.  You
    > have a URL, whatever it is.  The manufacturer is likely to want to
    > authenticate you.  What’s the tooling flow?  I think it’s something
    > like this:

    > Mud manager retrieves mud file, dispatches URL of the SBOM to an SBOM
    > consumer of some form that we’ll just call an SBOM manager for the
    > moment.

Let me ask clarification question:
  1) SBOM manager is an operator mechanism.
  2) talks to Manufacturer's server to resolve SBOM link to content

Then:
  - so manufacturer needs login to get SBOM content?

Query:
  - why is the SBOM private?  Cereal boxes print the contents.  There was a
        lot of moaning about this in certain sectors, but it clearly has been
        a good thing.

  - if I agree that SBOM could be private, the operator isn't the only entity
    that needs to see the SBOM.  The auditor needs to see it too.

    > User must register.  Requires a browser interaction of some form,
    > presumably with OAUTH.  Perfectly reasonable when the SBOM lives in the
    > cloud.  OR Token is received out of band for this service, either from
    > the device itself, or from the manufacturer service if one is
    > registered through that (requires browser interaction).

But, I'll go with your belief that the SBOM is private, and can only be
revealed to entities that can proove they own the device.

Presumably, the firmware updates will also be available only under the same
criteria.  It seems that this needs to be solved *anyway*.  Certainly, big
BFR vendors that I know, don't let me have updated firmware unless can show
them I have a maintenance agreement.  If we are going to do automated
remediation with firmware updates (using SUIT of course), then we need that
relationship already, and so I think it would make sense to use the same
interfaces.

Now, if you did the onboarding with BRSKI, you'd have a voucher from the
manufacturer pinning the domain registrar with the serial number, and that
could be proof of ownership.  One could use the voucher as proof of
ownership.

How one maps the certificate that is pinned (the domain registrar cert), to
the general organization is a non-obvious mapping, but I can see relatively
easy ways to map things.
Further, if the vendor has strong supply chain integration, then they already
know who their operators are.

But, in less supply chain integrations, the MASA can record the TLS Client
Certificate (and CA) used by the Registrar, and this can provide a way to
build the same kind of database of operators.

This does require that the manufacturer do some coordination, and maybe there
are issues with outsourcing the SBOM server.  This sounds like OAUTH2, but
based upon the TXAUTH BOF, maybe it's not enough to easily do that without a
human browser involved, but it still seems solvable to me.

    > I am thinking that when a token is received out of band for access to a
    > resource, that is a generic exchange that goes well beyond this use
    > case.  Carsten, Hannes, do you have views on any of this?

I also think that maybe the SBOM URL could have some token in it.
That seems pretty brittle though.