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

[Bret Jordan <[e-mail]>]

My key points were due to the responses I hear form some in the IETF, specifically

“If you just patched your endpoints there would be no issue”
“All endpoints can easily run security software”



Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 15, 2019, at 10:16 AM, Eliot Lear <[e-mail]> wrote:
> 
> Phil,
> 
> 
> 
>> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <[e-mail] <mailto:[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.
> 
> 
>> 
>> 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
>