Stories
Slash Boxes
Comments

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: 4, Interesting) by bob_super on Friday June 02 2017, @10:01PM (4 children)

    by bob_super (1357) on Friday June 02 2017, @10:01PM (#519593)

    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.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by jmorris on Friday June 02 2017, @10:09PM

    by jmorris (4844) on Friday June 02 2017, @10:09PM (#519596)

    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)

    by zocalo (302) on Friday June 02 2017, @10:40PM (#519605)
    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. If you take as given that any item of hardware and software will, at some point, have an exploitable weakness discovered on it and that not all users will know even the first principles of security, then defence in depth is the best mitigation. For most home IoT devices there are three tiers in the model; the device itself, their home router, and their ISP - with the brunt of the work falling on the router, since it's the closest we've got to an edge firewall and central management device. Protecting the router (also susceptible to "any given item of hardware...") is largely going to be down to better management of the admin interfaces, and the ISP.

    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)

      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)

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0
      • (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!