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

Eliot Lear <lear@cisco.com> Thu, 26 March 2020 07:59 UTC

Return-Path: <lear@cisco.com>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AE13A03F1; Thu, 26 Mar 2020 00:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_aoThYkol91; Thu, 26 Mar 2020 00:59:50 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7023A046D; Thu, 26 Mar 2020 00:59:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0DCAAAqYHxe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYMUVSASKoQaiQKHZiWbRwoBAQEMAQEbFAQBAYREAoJ?= =?us-ascii?q?QNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVjAQEBAQIBI1YFCwsYAgImAgJXBhO?= =?us-ascii?q?DJgGCXCCtEnWBMoVLhQmBDioBiWKCZoIAgREnDBSCHy4+hDwPgxEygiwEjgs?= =?us-ascii?q?hoimCRoJWhQmPKh2CTIECmBGEX4wClnGDNAIEBgUCFYFoI4FYMxoIGxVlAYJ?= =?us-ascii?q?BCTUSGA2OJEmIN4VCQAMwjGSCQQEB?=
X-IronPort-AV: E=Sophos;i="5.72,307,1580774400"; d="scan'208";a="24710157"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2020 07:59:42 +0000
Received: from ams3-vpn-dhcp2001.cisco.com (ams3-vpn-dhcp2001.cisco.com [10.61.71.209]) by aer-core-3.cisco.com (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.80.23.2.2\))
From: Eliot Lear <lear@cisco.com>
In-Reply-To: <27885.1585179569@localhost>
Date: Thu, 26 Mar 2020 08:59:41 +0100
Cc: iot-onboarding@ietf.org, mud@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4450F7B2-D9F2-4480-93D7-2DF2B062D83D@cisco.com>
References: <0DE46278-4708-42B6-8DFF-A8BC67B23F7E@cisco.com> <CAHiu4JPqXd2emEFCRK2dq0L6OFOcr-UdNkhJ2W+Cx5TUCLrprA@mail.gmail.com> <17397.1585086427@localhost> <CAHiu4JNfWBBMZV0bO41Emdo4GO2EFmicw+E=np_Xey_xG4JsKA@mail.gmail.com> <A19C04FE-3A50-4466-84D4-521C575C43C0@cisco.com> <27885.1585179569@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.71.209, ams3-vpn-dhcp2001.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/dbuknfVL5g-Fhcl0VVgXYQxCHw8>
Subject: Re: [Iot-onboarding] [Mud] Some new stuff for mudmaker.org
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2020 07:59:53 -0000


> On 26 Mar 2020, at 00:39, Michael Richardson <mcr+ietf@sandelman.ca> 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