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

Eliot Lear <> Thu, 26 March 2020 07:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78AE13A03F1; Thu, 26 Mar 2020 00:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7_aoThYkol91; Thu, 26 Mar 2020 00:59:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F7023A046D; Thu, 26 Mar 2020 00:59:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1723; q=dns/txt; s=iport; t=1585209584; x=1586419184; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JSRcLeSLYJpRVE4zdpRmsYMuuS4FzU5c9PeRndIkUG0=; b=bVYWWvOPaesF7Cn+xXTAIUescd/gFwC64tgQdAu1Q8LNpKMgx2F14Ans gpV00ds7uf2Zx7VYsH0egjBNvfTKw5SgzxRD10N+aNT+JuHAdV8JiMiyL 2yDO1FqDQ7X1EEc4NgeouSby4d8OxyCUT60Z3CmKcp90NV6eHH8rhqjzw 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.72,307,1580774400"; d="scan'208";a="24710157"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2020 07:59:42 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 02Q7xfjs008866 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Mar 2020 07:59:42 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Eliot Lear <>
In-Reply-To: <27885.1585179569@localhost>
Date: Thu, 26 Mar 2020 08:59:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <17397.1585086427@localhost> <> <> <27885.1585179569@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Iot-onboarding] [Mud] Some new stuff for
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Mar 2020 07:59:53 -0000

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