Re: [Mud] [Iot-onboarding] Some new stuff for mudmaker.org

[Eliot Lear <[e-mail]>]

> On 26 Mar 2020, at 00:39, Michael Richardson <[e-mail]> wrote:
> 
> 
> 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.

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.


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

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