On Tue, Feb 7, 2017 at 8:13 AM, Tom Beecher <beecher@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@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@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@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>