Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Eliot Lear <lear@cisco.com> Mon, 15 July 2019 16:16 UTC

Return-Path: <lear@cisco.com>
X-Original-To: smart@ietfa.amsl.com
Delivered-To: smart@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6731201E4 for <smart@ietfa.amsl.com>; Mon, 15 Jul 2019 09:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 T64bhqitv96o for <smart@ietfa.amsl.com>; Mon, 15 Jul 2019 09:16:32 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A0C1201C6 for <smart@irtf.org>; Mon, 15 Jul 2019 09:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9579; q=dns/txt; s=iport; t=1563207392; x=1564416992; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=N13LoiowyybiA01V642pR/uJJ3WHqu6HXtG7jhCpMqA=; b=bhb1ppWJV6GrAk8w6Y2owsQLtpcjf9+ZUVI5CslMUrCro0SFjQ5fMGxz KpEjyqQJ+OoZdyTk/tH+JEGxnYw5MKQ6AGSDfHycWuT/PzCNsGhjp8hUS CNZV6ZENH4EsT8Llvp7EG4Q8CNDtMmghFEMB+yqXpu0usjSxFhdt9YGKZ Y=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYAAB9pixd/xbLJq1lGgEBAQEBAgEBAQEHAgEBAQGBVgIBAQEBCwGBZwWBOisBIBIohByIe4tTJZJ6h34CBwEBAQkDAQEvAQGEQAIOgno3Bg4BAwEBBAEBAgEFbYVIhUoBAQEBAgEjTQcCBQsLGBgSAgJXBhODIgGBew+rcIEyhUeEZhCBNAGBUIdFgmCBf4E4DBOBTlAuPoQoa4I7MoImBIwFTQKIHZUFbQmCG4IfgQyOLoIzG4ItlV2OZpMUgwsCBAYFAhWBZiI3B4EaMxoIGxVlAYFZaD6COm8BDI0TPQMwjX2CLgEB
X-IronPort-AV: E=Sophos;i="5.63,494,1557187200"; d="asc'?scan'208,217";a="14262987"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 16:16:30 +0000
Received: from ams3-vpn-dhcp3718.cisco.com (ams3-vpn-dhcp3718.cisco.com [10.61.78.134]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6FGFWeN028388 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 16:16:29 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <2E98BE46-174B-4423-976C-6EB48A3A714F@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_DB5207E9-3DF1-48CC-8377-66F138A7E1E5"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 15 Jul 2019 18:16:29 +0200
In-Reply-To: <CAMm+LwgtM=oYCSgeNAkbRD=TaJe8O750reTQ7s6Ux954Dz=YhQ@mail.gmail.com>
Cc: Bret Jordan <jordan.ietf@gmail.com>, smart@irtf.org, Melinda Shore <melinda.shore@nomountain.net>, IETF SecDispatch <secdispatch@ietf.org>
To: Phillip Hallam-Baker <phill@hallambaker.com>
References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <CAMm+Lwh3KW6ZBbMktwmLcKyY8=_ysLYJF_7MsAuiOat6baQ=Kg@mail.gmail.com> <B551EF79-7E6E-4C4E-ADCA-6538F7972222@gmail.com> <CAMm+Lwg+2RFiXK43nJv7pD3OgM8y=ziVYxBkXD3F2kJyz37SxQ@mail.gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <CAHbuEH5WUv-a4nKt5YAZosO-vE773Jh3xn1+-hA=4J7RBERc3g@mail.gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <d5f05651-849f-4048-3123-8ee17a0c0a96@nomountain.net> <C2AD999E-2B53-4E17-B033-4B722ADFA677@cisco.com> <AC7FADF1-A556-46AF-9A5C-F464AA4772B9@gmail.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> <A59918B5-C6B7-4632-B95F-E9AD24C16C96@gmail.com> <CAMm+LwgtM=oYCSgeNAkbRD=TaJe8O750reTQ7s6Ux954Dz=YhQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.78.134, ams3-vpn-dhcp3718.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/smart/NJtbZ5WLQ2Y4lZqRch3g1iR1Vd4>
X-Mailman-Approved-At: Mon, 15 Jul 2019 09:33:44 -0700
Subject: Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-BeenThere: smart@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Stopping Malware And Researching Threats <smart.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/smart>, <mailto:smart-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smart/>
List-Post: <mailto:smart@irtf.org>
List-Help: <mailto:smart-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/smart>, <mailto:smart-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 16:16:35 -0000

Phil,



> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> I am pretty sure this is not security 101 stuff. In fact I am pretty sure that it will be quite a while before the academy really gets to grips with this stuff. They don't have the same biases we do but they have different ones.
> 
> For example, the need to patch systems is brought up and this is almost always seen as a good thing. Not in the process control world it isn't. The problem of unauthorized updates is a very serious concern for them.


I think I agree with your thesis statement but not your supporting statement above.  There are a great many “best practices” that are coming out, and they all to a one usually involve usernames and passwords for a good number of devices that might not require either.  And in fact, the idea of a password for machine controlled devices is Just Bad.

Patches themselves from the vendors are absolutely required to be available, but the timing of their installation needs to be left to customers based on when – if at all – those devices can allow for a window where the device may miss a beat.  But even in these cases, process control systems need in service upgrade mechanisms, because the reality is that the bugs will be there.


> 
> Devices that automatically update themselves are vulnerable to a denial of service attack by the device provider.
> 
> This is not an attack many device providers are worried about because it isn't an attack that is going to affect them (for a start) and they think they can trust themselves. Which may well not be true. I have seen a single employee cause $1 million worth of vandalism after being upset that his wages were being garnished for alimony. I really doubt that more than 5% of the companies that make IoT devices have effective controls.

Ok, but that is no reason to not have automated updates available.  That is more of a reason to have strong audit processes in place.

> 
> The same is true of devices that depend on a tied service. My Revolv hub is useless because Google bought the company and shut down the service leaving me with $2500 worth of dead equipment in my walls.
> 
> This is not 101 stuff and in fact I don't think that a single one of the IoT vendors out there is showing that they understand it. We are still at what I call the 'narcissistic' phase of the market in which every medium sized IoT vendor thinks it is all about themselves.
> 
> 
> The fact that an IoT device makes the owner dependent on the provider is totally a security issue. The fact that the device providers don't want to acknowledge it doesn't make it any less so.

I agree that this is indeed a security issue, but that doesn’t mean that it’s the wrong way to go.  There are other factors to take into consideration, not the least of which is cogs and e-Waste associated with unnecessarily shipping extra horse power to 20 million endpoints when a little elastic processing in the cloud will do.

Eliot