" 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. "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? 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. This is not to say we should do nothing (obligatory 'Perfect is the enemy of good' comment) but it's something to think about when discussing possibilities. On Tue, Feb 7, 2017 at 6:56 AM, William Herrin <bill@herrin.us> wrote:
On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec <rsk@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@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>