TechDirt reports
In the wake of the Wannacry ransomware, University of Pennsylvania researcher Sandy Clark has proposed something along these lines: firmware expiration dates. Clark argues that we've already figured out how to standardize our relationships with automobiles, with mandated regular inspection, maintenance and repairs governed by manufacturer recalls, DOT highway maintenance, and annual owner-obligated inspections. As such, she suggests similar requirements be imposed on internet-connected devices:
A requirement that all IoT software be upgradeable throughout the expected lifetime of the product. Many IoT devices on the market right now contain software (firmware) that cannot be patched even against known vulnerabilities.
A minimum time limit by which manufacturers must issue patches or software upgrades to fix known vulnerabilities.
A minimum time limit for users to install patches or upgrades, perhaps this could be facilitated by insurance providers (perhaps discounts for automated patching, and different price points for different levels of risk)."
Of course, none of this would be easy, especially when you consider this is a global problem that needs coordinated, cross-government solutions in an era where agreement on much of anything is cumbersome. And like previous suggestions, there's no guarantee that whoever crafted these requirements would do a particularly good job; that overseas companies would be consistently willing to comply; or that these mandated software upgrades would actually improve device security. And imagine being responsible for determining all of this for the 50 billion looming internet connected devices worldwide?
That's why many networking engineers aren't looking so much at the devices as they are at the networks they run on. Network operators say they can design more intelligent networks that can quickly spot, de-prioritize, or quarantine infected devices before they contribute to the next Wannacry or historically-massive DDoS attack. But again, none of this is going to be easy, and it's going to require multi-pronged, multi-country, ultra-flexible solutions. And while we take the time to hash out whatever solution we ultimately adopt, keep in mind that the 50 million IoT device count projected by 2020--is expected to balloon to 82 billion by 2025.
(Score: 4, Interesting) by bob_super on Friday June 02 2017, @10:01PM (4 children)
The only way to stop the idiocy (besides "not buying webcam-microwaves") is to upgrade consumers to firewalls treating any new device as a threat.
"This device will be isolated from the rest of the network, until you explicitly enable it (via a grandma-friendly GUI) to connect to that other one, on that particular port, or that web server, and absolutely nothing else, ever, and you can only add permissions with the code that the firewall keeps changing on its front panel."
Plug-and-play is the problem. Convenience sells devices, but it sells them to clueless people who endanger everyone else.
If manufacturers want to connect a device to their servers, it should always be to a "trusted" single entry point, so you can firewall everything else.
(Score: 2) by jmorris on Friday June 02 2017, @10:09PM
I like it. How about revise to when a new device appears ask you (if it can't auto id it) if it is a) a general purpose computing device that will receive regular OS/Browser updates and connects to a wide variety of web resources or b) an IoT device. If IoT, assume it is secure when first unboxed and thus observe traffic to/from it and build a whitelist from that over a week or two. After that provide a button for 'reconfiguring device' for cases like a Roku where you might subscribe to a new service via it and need to permit it to connect to the servers for it.
(Score: 4, Interesting) by zocalo on Friday June 02 2017, @10:40PM (2 children)
What seems to needed is a way for the router to autoconfigure firewalling based on the requirements of IoT device in question, which is going going mean some kind of lookup, either via querying the device itself (a standard URL to return basic device info, perhaps?) or an unconfigured device broadcasting the information in a similar manner to an ARP or DHCP request until it gets an ACK from the router that it has been configured. For security, all this should obviously be local subnet only unless manually configured otherwise, which shouldn't be beyond the capabilities of anyone running multiple subnets in the first place, and there's going to need to be at least some manual intervention to prevent spoofing ("Hi, I'm a newly compromised PC, but I'm pretending to be a new IoT device - now, if you can just open ports..."
Problem is, as with that form for solutions to the spam problem, this approach advocates a technical and market-based approach (and maybe legislative too)... There are too many big players that are going to want to push their own take on the necessary "standard", and even if/when they all get behind a small enough subset for vendors of CPE to have a shot, there are too many cheap-ass vendors of IoT devices that won't bother supporting it anyway.
UNIX? They're not even circumcised! Savages!
(Score: 2) by c0lo on Saturday June 03 2017, @12:51AM (1 child)
(malevolent trollish grin - if the provider of this IoT thingies make such a crap, how about spoofing a malfunctioning device and feed - plausible deniable - crap to their server?
While doing it, good chances I might discover weaknesses on their serverside in the process, but why bother exploit it when "poisoning attack" is good enough for the lulz?
They can try to disable the "defective device", but... you see? ... it's defective, won't answer to "firmware upgrade" commands.
I'd even publish the source code for the spoofer - a non-compiled version of course - for any other willing to share the fun. Source code is speech)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by zocalo on Saturday June 03 2017, @09:46AM
UNIX? They're not even circumcised! Savages!