IoT security

Tue Feb 7 13:58:46 UTC 2017

I think the fundamental problem here is that these devices aren't good
network citizens in the first place.  The odds of getting them to add
functionality to support a new protocol are even likely than getting them
to not have open services externally IMHO.

Couldn't a lot of this be caught by proactive vulnerability scanning and
working with customers to have an SPI firewall in place, or am I missing
something?

Historically residential ISP CPE options have been terrible.  If you could
deliver something closer to user expectations you would likely see much
more adoption and less desire to rip and replace.  Ideally a cloud-managed
device so that the config wouldn't need to be rebuilt in the event of a
hardware swap.

On Mon, Feb 6, 2017 at 5:31 PM, William Herrin <bill at herrin.us> 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.
>
> Would have to cryptographically sign the fail message and let the
> device query the signer's reputation or something like that to avoid
> the obvious security issue. Obvious privacy issues to consider.
> Anyway, throwing it out there as a potential discussion starting
> point.
>
>
>
> The presentation on bandwidth policers...
>
> Seems like we could use some form of ICMP message similar to
> destination unreachable that provides some kind of arbitrary string
> plus the initial part of the dropped packet. One of the potential
> strings would be an explicit notice to the sender that packets were
> dropped and the bandwidth available.
>
> Yes, we already have ECN, but ECN tells the receiver about congestion,
> not the sender. More to the point, ECN can only be flagged on packets
> that are passed, not the packets that are dropped, so the policer
> would have to be complicated enough to note on the next packet that
> the prior packet was dropped. Also, ECN only advises that you're close
> to the limit not any information about the policer's target limit.
>
> This thought is not fully baked. Throwing it out for conversation purposes.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>

-- 
Ray Patrick Soucy
Senior Cyber Security Engineer
Networkmaine, University of Maine System US:IT

207-581-3526