[192680] in North American Network Operators' Group
Re: Spitballing IoT Security
daemon@ATHENA.MIT.EDU (Eliot Lear)
Fri Nov 11 12:57:46 2016
X-Original-To: nanog@nanog.org
To: Marcel Plug <marcelplug@gmail.com>
From: Eliot Lear <lear@ofcourseimright.com>
Date: Fri, 11 Nov 2016 18:55:32 +0100
In-Reply-To: <CACfXSnA6wqi_w_up5_keqWWy2HbCbEVLYts37tdw2wJeSgAAPA@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pre9TN8bQDumgEOgJ644OXSnrmSI6x8bE
From: Eliot Lear <lear@ofcourseimright.com>
To: Marcel Plug <marcelplug@gmail.com>
Cc: "Ronald F. Guilmette" <rfg@tristatelogic.com>,
"nanog@nanog.org" <nanog@nanog.org>
Message-ID: <293b4596-6869-c6a4-709b-b68e4bd8cde9@ofcourseimright.com>
Subject: Re: Spitballing IoT Security
References: <85741.1478581532@segfault.tristatelogic.com>
<360ddb0d-59a3-f6c1-8bc7-b1dccd784160@ofcourseimright.com>
<CACfXSnA6wqi_w_up5_keqWWy2HbCbEVLYts37tdw2wJeSgAAPA@mail.gmail.com>
In-Reply-To: <CACfXSnA6wqi_w_up5_keqWWy2HbCbEVLYts37tdw2wJeSgAAPA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Moving offlist on this. For those who are interested, send ping.
On 11/11/16 4:42 PM, Marcel Plug wrote:
> On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear <lear@ofcourseimright.com
> <mailto:lear@ofcourseimright.com>> wrote:
>
> It is worth asking what protections are necessary for a device that=
> regulates insulin. =20
>
>
> Insulin pumps are an example of devices that have been over-regulated
> to the point where any and all innovation has been stifled. There
> have been hardly any changes in the last 10+ years, during a time when
> all other technology has advanced quite a bit. Its off-topic for
> Nanog, but i promise you this is very frustrating and annoying topic
> that hits me close to home.
>
> There has to be a middle ground. I guarantee we do not want home
> firewalls, and all the IoT devices to be regulated like insulin pumps
> and other medical devices. I think I'm starting to agree with those
> that want to keep government regulation out of this arena...
>
> Marcel
> =20
>
> Eliot
>
>
> On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> > In message <20161108035148.2904B5970CF1@rock.dv.isc.org
> <mailto:20161108035148.2904B5970CF1@rock.dv.isc.org>>,
> > Mark Andrews <marka@isc.org <mailto:marka@isc.org>> wrote:
> >
> >> * Deploying regulation in one country means that it is less like=
ly
> >> to be a source of bad traffic. Manufactures are lazy. With
> >> sensible regulation in single country everyone else benefits as=
> >> manufactures will use a single code base when they can.
> > I said that too, although not as concisely.
> >
> >> * Automated updates do reduce the numbers of vulnerable machines=
> >> to known issues. There are risks but they are nowhere as bad a=
s
> >> not doing automated updating.
> > I still maintain, based upon the abundant evidence, that
> generallized
> > hopes that timely and effective updates for all manner of
> devices will
> > be available throughout the practical lifetime of any such IoT
> thingies
> > is a mirage. We will just never be there, in practice. And thus=
,
> > manufacturers should be encouraged, by force of law if necessary,=
to
> > design software with a belt-and-suspenders margin of safety built=
in
> > from the first day of shipping.
> >
> > You don't send out a spacecraft, or a medical radiation machine,
> without
> > such addtional constraints built in from day one. You don't
> send out
> > such things and say "Oh, we can always send out of firmware
> update later
> > on if there is an issue."
> >
> > From a software perspective, building extra layers of
> constraints is not
> > that hard to do, and people have been doing this kind of thing
> already
> > for decades. It's called engineering. The problem isn't in
> anybody's
> > ability or inability to do safety engineering in the firmware of =
IoT
> > things. The only problem is providing the proper motivation to
> cause
> > it to happen.
> >
> >
> > Regards,
> > rfg
> >
>
>
>
--pre9TN8bQDumgEOgJ644OXSnrmSI6x8bE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJYJgYVAAoJEIe2a0bZ0noznukH/iCc3qIxG4L14JQgYqY1KBnu
qXCixEs8otIV5pTdw2joTgSjvWdeae1fQvZBndk9sYGC15H9isbg26MUdGqQDMgG
CR3ZPSTlT9V4l38vnqgWkWhPIPNUMKBgT/GqUeUURKEBD2yzuKWMex5Car/+CLpH
CFJQdJylVm1ywpygPno7COrMgl7z2ySDwN+jzvBQDNV3n9DzQp2rQQdBZjWMPQYU
nkMn7zLGT1mvr6hVGb7o61+cJXToXkfakjPcXEskLEtpMAAb9cXwZsugDDLFk9y7
YPadO5SoBXoDj2I3QPNl7PtWNRHAc7oMprhPFYaTCNbrdxBPQ9dStaBwbQfQOd0=
=oOFG
-----END PGP SIGNATURE-----
--pre9TN8bQDumgEOgJ644OXSnrmSI6x8bE--
