IoT security

Tue Feb 7 11:56:40 UTC 2017

On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec <rsk at gsp.org> wrote:
> On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote:
>> 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.
>
> I can think of at least four reasons why this idea must be killed
> immediately and permanently.  This is off the top of my head *before*
> coffee, so I strongly suspect there are more.
>
> 1. An attacker who takes control of an IoT device can change the contents
> of that packet, cause it to be emitted, suppress it from being emitted, etc.

Hi Rich,

Immaterial. The point is to catch vulnerable devices before they're
hacked. That can't always happen (even with customers and vendors
engaged in best practice patching), but it need only happen often
enough to limit the size of the resulting botnets.

> 2. This will allow ISPs to build a database of which customers have
> which IOT devices.  This is an appalling invasion of privacy.

As I envision it, it's an opt-out system. Anyone who cares and knows
enough to secure their network can turn it off for their devices. No
permission or action from the ISP required to turn it off. In fact,
you need only block packets to the well-known anycast address to
disable it for all devices on your network.

> 3. This will allow ISPs to build a database of which customers have
> which IOT devices.  This will create one-stop shopping for attackers.

Possible, though an ISP which retains the data opens itself to a class
action lawsuit if it can't keep control of it.

Nevertheless, let's not oversell the privacy implications: most of the
IoT devices we're talking about phone home anyway. They're tied to
this or that cloud service rather than accepting local access. An ISP
can't learn as much information by watching who they phone home to
(deep packet inspection), but they can learn an awful lot.

> 4. It won't take long for this to be used as a DDoS vector.

If the ISP can't keep control of its security head-end then sure, at
least until the ISP regains control.

Regardless, I encourage you to suggest alternate solutions which don't
run afoul of the problems you mention. The problem isn't going away.
Entirely cutting off customers doesn't work because there are too many
impacted customers and ISPs don't have the resources or the will to do
so. Demanding that trash vendors not produce trash won't get it done
either. When you eliminate responsible device hardening, cutting
customer connections and the kill switch, what's left?

Regards,
Bill Herrin

-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>