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

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Jul 15, 2019 at 12:16 PM Eliot Lear <[e-mail]> wrote:

> Phil,
>
> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <[e-mail]>
> 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.
>

No, there is no absolute security requirement here. There are two concerns
that are potentially in conflict

1) The vendor may have introduced a security vulnerability
2) The vendor may use an update to reduce or remove functionality.

Again, I have $2,000 worth of Nest equipment in the house. Google recently
announced that they are discontinuing support for their previous
interconnectivity support that my current home configuration uses. My hub
provider may or may not support the new scheme. What this means is that my
device vendor has abused its update privilege to restrict my device
functionality for its own profit.

That is a security concern that affects my wallet and it matters much more
to me than the possibility that the vendor might want to distribute a
legitimate update patch to address their potential incompetence.

Setting up the first requirement that affects a manufacturer interest as
absolute and unchallengable is wrong. There are two requirements here.
patches are not a security requirement, they are a security control.

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

If the vendors were capable of doing strong audit controls, they would be
capable of writing code that can't be compromised by a buffer overrun
exploit.

I see this demand for patching as being an anti-pattern that is being
promoted by the folk who think that dumping linux plus some Python on an
IoT device and shipping it is an acceptable IoT approach. It isn't. You
cannot secure a platform with 15 million lines of code. IoT devices should
not be built round kernels designed to support a general purpose computing
model. The attack surface is ridiculous. There is no way that is going to
be patchable.

Using a dedicated IoT kernel like .NET Core running on the bare metal with
as little intermediation  as possible is the way forward.

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

Cloud computing is good. But it doesn't have to be the cloud provided by
the manufacturer.

Devices should connect to the cloud I provide which may be off site or may
be onsite. A Raspberry Pi W for $5 has more computing power than the
machine I used when I was designing the Web specs at CERN. We used the same
class of machine to control experiments with 550 tons of depleted uranium.

Moving the control points off site is a lazy model. The smart home should
be capable of working even if the Internet service is down. I have at least
two dozen machines in the house capable of delivering a gigaflop. So I
really should not need to move anything out of my house to process.


The podcast series I am currently editing is called 'Should this be
Internet' and it is about IoT devices. I will be giving something of a
preview a week on Thursday. Spoiler alert: the answer on all the segments
so far is 'no'. And I am the person who has been spending a small fortune
buying all this stuff.

My big fear here is that we are trading on the enthusiasm of the early
adopter market and there is a real risk that if we don't start building IoT
devices that aren't more trouble than they are worth before that enthusiasm
is spent, we will end up with an IoT winter.

Remember that (almost) everything we are currently seeing in 'AI' is stuff
that was basically developed in the 1980s. They set expectations that
couldn't be met by the technology of the day. By the later 1990s, the
machines were plenty powerful enough but the AI winter didn't see a thaw
for another decade.