Slash Boxes

SoylentNews is people

posted by on Friday June 02 2017, @08:58PM   Printer-friendly
from the looming-global-IoT-shitstorm dept.

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.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by c0lo on Saturday June 03 2017, @12:51AM (1 child)

    by c0lo (156) on Saturday June 03 2017, @12:51AM (#519657) Journal

    I've been thinking along similar lines, since it's obvious that IoT is here to stay and so we'd better figure out how to fix it.

    (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)

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by zocalo on Saturday June 03 2017, @09:46AM

    by zocalo (302) on Saturday June 03 2017, @09:46AM (#519786)
    Now that you mention it, taking over a vendor's vulnerable IoT devices then using them to launch a DDoS against the vendor's infrastructure would also make for a pleasantly cathartic payload for a BrickerBot / Hajime style IoT worm. The author would need to figure out some means of determining what the target should be using the available data (what port and password was used for the compromise, etc.), plus any additional info that can be learnt from the device itself, but that shouldn't be too hard a challenge. I guess some kind of fallback mode if the vendor has already gone bust too - probably quite common given the fly-by-night nature of vendors at the sewer level of the market - and since a patch obviously won't be forthcoming, bricking the device for the greater good seems like a reasonable choice there.
    UNIX? They're not even circumcised! Savages!