IoT security

Tue Feb 7 15:55:25 UTC 2017

 On Tue, Feb 7, 2017 at 8:13 AM, Tom Beecher <beecher at beecher.cc> wrote:
>> " 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. "
>
> Any semi-competent attacker will simply alter the way the network stack on
> the device works to make it _not_ look like an IoT device for the purposes
> of this check, rendering it moot.

Hi Tom,

Again, the idea is to remediate devices with insecure software
-before- they're breached. Obviously once breached the attacker can
present any profile he wants save that it has to emit packets
consistent with his desired attack.

>> "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."
>
> If the vendor isn't thinking about security already, as evidenced by the
> current issues with these devices, how are they to be convinced to add code
> to make said device do something exceptionally specific?

Because it's consistent with the carelessly throw-together free open
source software process the trash vendors currently follow and when
the industry promotes its "look for the safe network logo" program
they won't want to have problems with their retailers over a trivially
added bit of free software.

> I believe it's important to remember that network endpoints will never be
> sure fully secure. They will never be fully in compliance with $standard .
> They will never always follow best practices.

You can say that again.

On Tue, Feb 7, 2017 at 8:58 AM, Ray Soucy <rps at maine.edu> wrote:
> 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.

Hi Ray,

I can speak to that with authority, but again my working theory is
that adding the kill switch is consistent with the carelessly
throw-together free open source software process the trash vendors
currently follow.

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

One of us is missing something. The customer isn't scanning his
network (if he was, we wouldn't have the problem), and from the
outside of an SPI firewall how is the ISP supposed to do that?

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

The customer buys cool stuff he finds at CostCo. Seeking different
behavior seems unlikely to succeed to me.

On Tue, Feb 7, 2017 at 9:50 AM, Rich Kulawiec <rsk at gsp.org> wrote:
> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:
>> Immaterial. The point is to catch vulnerable devices before they're
>> hacked.
>
> This won't work on the majority of devices: they're pre-compromised
> at the factory.

Well that's a silly misdirection Rich. Manufacturer's misbehavior is a
whole different class of problem than equipment breached by a third
party after deployment. Unless you claim a convenient way to merge
solutions, take it to your own thread.

>> If the ISP can't keep control of its security head-end then sure, at
>> least until the ISP regains control.
>
> I think you're severely underestimating the threat.

I'm not estimating the threat at all, just stating the precondition
for a kill switch to be a denial of service vector.

>> Regardless, I encourage you to suggest alternate solutions which don't
>> run afoul of the problems you mention. The problem isn't going away.
>
> I'm aware of that.  But this is not the way.  I've seen this movie
> WAY too many times:
>
>         1. We must do something
>         2. This is something.
>         3. Let's do this.
>         4. We have done something.
>         5. Congrats and awards all around, everybody.

And I've heard this song before too: If you choose not to decide you
still have made a choice.

Neither one of us will like the government solution, so if you have an
idea that hasn't already demonstrated its failure, let's hear it. When
there's no consensus on an optimal solution, we move forward by trying
ideas until something sticks. That's progress, including the attempts
which fail.

Regards,
Bill Herrin

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