IoT security

Tue Feb 7 00:10:01 UTC 2017

On 2/6/17 2:31 PM, William Herrin wrote:
> This afternoon's panel about IoT's lack of security got me thinking...
>
>
> On the issue of ISPs unable to act on insecure devices because they
> can't detect the devices until they're compromised and then only have
> the largest hammer (full account ban) to act...
>
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build. The ISP can capture traffic to that anycast
> address, compare the data against a list of devices known to be
> defective and, if desired, respond with a fail message. If the IoT
> device receives the fail message, it must try to report the problem to
> its owner and remove its default route so that it can only communicate
> on the local lan.  The user can override the fail and if desired
> configure the device not to emit the init messages at all. But by
> default the ISP is allowed to disable the device by responding to the
> init message.

Uh, yuck at many levels. Do you leak your cisco ios versions to the 
internet?

Do you really want the responsibility for the remote kill switch for IoT 
S&M gear?

And of course, you're depending on rfc 3514, right?

Mike