Forgot your password?
typodupeerror
Security Software Hardware

Do Embedded Systems Need a Time To Die? 187

Posted by Soulskill
from the upgrade-or-perish dept.
chicksdaddy writes: "Dan Geer, the CISO of In-Q-Tel, has proposed giving embedded devices such as industrial control and SCADA systems a scheduled end-of-life in order to manage a future in which hundreds of billions of them will populate every corner of our personal, professional and lived environments. Individually, these devices may not be particularly valuable. But, together, IoT systems are tremendously powerful and capable of causing tremendous social disruption. 'Is all the technologic dependency, and the data that fuels it, making us more resilient or more fragile?' he wondered. Geer noted the appearance of malware like TheMoon, which spreads between vulnerable home routers, as one example of how a population of vulnerable, unpatchable embedded devices might be cobbled into a force of mass disruption. Geer proposes a novel solution: embedded systems that do not have a means of being (securely) managed and updated remotely should be configured with some kind of 'end of life,' past which they will cease to operate. Allowing embedded systems to 'die' will remove a population of remote and insecure devices from the Internet ecosystem and prevent those devices from falling into the hands of cyber criminals or other malicious actors, Geer argued."
This discussion has been archived. No new comments can be posted.

Do Embedded Systems Need a Time To Die?

Comments Filter:
  • by Narcocide (102829) on Wednesday May 14, 2014 @06:29AM (#46997437) Homepage

    ... change the password to something other than the default.

    • by gbjbaanb (229885)

      or not have a single default password, each device could have a random one set as default (like how each has a unique MAC address for example) that's printed on the back.

      Oh, and maybe we could make control software that is designed to automatically update remotely.

      Or... radically, we could just not put a network port on them.

      • by mlts (1038732)

        I've always wanted an e-Ink display on consumer routers. Press a button, up comes the password. When the router is completely reset, the default password is randomly re-generated [1], and shown on the display. Of course, this is easily changed, but it would help ensure that router "A" isn't going to have the same default as "B", and that if someone hands the router to another party after it is reset, the previous party won't be privy to the default passcode.

        I've wondered what happened to "data diode" tec

    • How about this innovative approach....keep improving products and let the customers decide which risks they are willing to accept or need to remove.
    • by Lumpy (12016) on Wednesday May 14, 2014 @10:26AM (#46998951) Homepage

      and it's easy to do. every polycom comes with the admin password set to the serial number of the unit. Any programmer that made it out of the first year of college could easily add this feature during firmware initialization.

  • by wiredog (43288) on Wednesday May 14, 2014 @06:31AM (#46997443) Journal

    In-Q-Tel [iqt.org]

    The IQT Mission

    We identify, adapt, and deliver innovative technology solutions to support the missions of the Central Intelligence Agency and broader U.S. Intelligence Community.

    • by cusco (717999)

      OK, this makes more sense. Only true morons of that caliber could imagine that ripping and replacing the control system for a power dam, the guts of a multimillion dollar CNC mill, or the access control system for an entire enterprise every few years was a good thing. Know how long it takes to update the embedded firmware on a reader board over RS-485? Fifteen to forty five minutes. Each door. I've worked in enterprises with as many as 21000 reader panels.

      Not just "NO", but "NO FUCKING WAY, NO!"

  • Terrible idea (Score:5, Informative)

    by mirix (1649853) on Wednesday May 14, 2014 @06:33AM (#46997451)

    You'll have to install custom firmware to prevent things from having to go to the dump on their third birthday?

    Seems pretty ridiculous, not to mention that it can still have a hole exploited on the day they launch the device, and not be updated for years (in it's allotted lifespan).

    I'm more for the option of make things easier to update, and, the important part... actually release bloody updates! I'm looking at you, almost every embedded device manufacturer out there.

    • by CastrTroy (595695)
      This is why I will never buy an Android phone again. The lack of guaranteed updates is a huge problem. I have a hen which has decent hardware, but the software is stuck in the past. Apple and even Windows phones do a much better job at being kept up to date.
      • Try a Nexus, droid vendors tend to only update current far sale hardware and that changes every 6-12 months.

        • by Simulant (528590)
          Even Nexus is only good for a few years.... I'm holding my breath for another year of N4 updates.
          • by tepples (727027)
            A fourth-generation iPod touch purchased the day before Apple started selling the fifth-generation iPod touch stopped getting substantial updates in less than a year. That's when Apple introduced iOS 7, and the iPT4 didn't have enough RAM to run it.
      • by dbIII (701233)

        I have a hen which has decent hardware, but the software is stuck in the past.

        Eggsactly.

      • > This is why I will never buy an Android phone again. The lack of guaranteed updates is a huge problem.

        Is Apple really any better though?

        Try getting iOS updates to the original iPad. Mine is stuck on iOS5. :-(

        I'm using iOS6 on iPhone 5 but I don't see any other vendor doing a better job of support. Apple isn't interested in fixing bugs in iOS6.

    • Never a good solution.

      Techs who have been around before the year 2000 tend to have this policy. Upgrade only after it has been proven. This is a lesson they have learned because especially during the late 90's. Patches and Upgrades, didn't go in smoothly and often caused more problems then they fixed.
      Today patching and upgrades tend to go in far more smoothly, however we still want to be sure that it is proven to work before we are the first to jump in.

      Now this means our systems are also more vulnerable f

    • Like androids in Bladerunner...

      I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser gate. All those moments will be lost in time, like tears in rain. Time to die.

    • Agreed. Forced obsolescence is NOT the answer.

  • by kruach aum (1934852) on Wednesday May 14, 2014 @06:35AM (#46997465)

    Imply the opposite of what is expected, without regard for reality, truth or common sense. Ex:

    "'Is all the technologic dependency, and the data that fuels it, making us more resilient or more fragile?"

    Look at this amazing thinker. Didn't he just blow your fucking mind?

    • There's also what I refer to as the "lone voice in the wilderness" effect. Whereby, whatever the issue, if someone simply states that they have an "inexpressible doubt" in something then they will seem to be the smartest person in the room. This is used quite often in political debates. It's also quite effective for opening up "I told you so" options later, when they never really told anyone anything.
    • Look at this amazing thinker. Didn't he just blow your fucking mind?

      If he were a Slashdot poster, his every post would be modded up through the roof.

  • my thermostat (Score:4, Insightful)

    by spectrokid (660550) on Wednesday May 14, 2014 @06:37AM (#46997477) Homepage
    My thermostat will never be connected to anything and does not need an end of life thank you very much. And I want to see the manager who will approve buying this kind of stuff.
  • Planned obsolescence (Score:5, Interesting)

    by Melkman (82959) on Wednesday May 14, 2014 @06:39AM (#46997487)
    What could possibly go wrong ? A PLC controlling a plant stopping at some random date is perfectly acceptable, right. I'm sure manufacturers will love this. A guaranteed replacement market is a wet dream for any market.
    • I think *that* is the main point of this idea, security is just a way of selling it.

    • A lot. You can't do that with a PLC as that would be clinically insane and might have serious safety/economic ramifications. No engineer worth his salt would touch such a device. You might configure it to simply fail to startup after a powerdown on a certain date, but not have it stop while the system is running.

      • by thegarbz (1787294)

        You might configure it to simply fail to startup after a powerdown on a certain date, but not have it stop while the system is running.

        Interesting thought which breaks down when you consider that many such devices are power down only when they reach end of life and need replacing. Anyway the commercial impact is still ludicrous. Go stand in front of management and tell them we are losing $1000000 per day because the power outage triggered an and of life time bomb in the control system and the vendor needs 6 weeks to ship a new one.

        The entire premisepremise is retarded, protesting things should artificially due because a vendor refuses to p

        • I would agree, though I have had a number of long running plants I have sat in front of that were offline for weeks because they were "broken", and investigation showed that the operator had simply forgotten how to look for and clear a startup error....

          It is ridiculous in any case, and I don't think it is a good idea. The trouble is, in a long running plant, they will never apply any "security fix" because that means shutting down the system anyway. Possibly even re-commissioning and testing the damn thin

        • by afidel (530433)

          Hell, $1M per day is nothing, when the major auto companies are selling a certain line of cars as fast as they can make them downtime is in the multiple millions per hour range, and with a steel plant a cold shutdown can result in hundreds of millions in damage.

    • by cusco (717999)

      A manufacturer who implements this will see his customer base abandon him in droves and will be reduced to only doing work for the consumer market. I have worked on access control systems that have been in place for well over 20 years, I would never install one that we knew would fail after 3.

    • by jeffmeden (135043)

      What could possibly go wrong ? A PLC controlling a plant stopping at some random date is perfectly acceptable, right. I'm sure manufacturers will love this. A guaranteed replacement market is a wet dream for any market.

      Obsolescence is already planned for every single product, no matter what, period. If done properly (imho) then a guarateed fail-by date would cause the realization that the true cost of ownership per year for a system would include the cost of scrapping it when it's too old to work right. Today, what happens is a system is bought because it fit in the budget this year, and it's held on to for as long as possible, long after security and failure risk have climbed way way up past an acceptable point, becaus

  • Here's a better idea (Score:5, Interesting)

    by msobkow (48369) on Wednesday May 14, 2014 @06:40AM (#46997495) Homepage Journal

    Here's a better idea. Charge anyone who ships unpatchable and unpatched hardware with sponsoring terrorism, because it's their laziness causing the problem.

    Why the hell should I be forced to buy, buy, and rebuy the same god damned hardware over and over to save them from patching their shitty systems that they sell?

    • by AmiMoJo (196126) *

      Maybe if you didn't demand a $20 wireless router you could expect better firmware quality and regular updates. Otherwise you have to accept that it will probably only last months before either the hardware fails or someone discovers a way to exploit it.

      I'm all for requiring vendors to patch, just don't expect equipment to be cheap any more.

    • by Lumpy (12016)

      You have the answer. Forced liability on software companies.

      Company hacked because of a Windows flaw? Microsoft owes you the $22 trillion it cost for cleaning up the hack... Yes, use the over inflated numbers they claim.

  • Absolutely not (Score:5, Insightful)

    by Ceriel Nosforit (682174) on Wednesday May 14, 2014 @06:42AM (#46997501)

    These are not consumer items. Industrial systems seldom live just one life, and after being decommissioned they usually go up for action to be recommissioned somewhere else. If you artificially disrupt this dynamic you cause enormous economic loss, and for what? To perpetuate a buzzword?

    The entire proposal is barking up the wrong tree.

    It is however a moderately interesting insight into the echo-chamber of national intelligence. Rather funny to see how Mr. Geer talks about monocultures while laying on their own lore _thick_.

  • by pipedwho (1174327) on Wednesday May 14, 2014 @06:45AM (#46997513)

    If a device does not have a way to keep track of time (eg. in built real time clock, with backup battery that will last for the duration of the device's 'lifetime'), then it becomes vulnerable to permanent denial of service when something spoofs a fake future date and time. What happens when a hundred thousand devices go offline because someone spoofed an NTP response?

    You may as well force every device to have a kill switch and remotely shut it down when it's too old. At least that'll probably require some kind of public key signature from an authenticated service (in the same way you'd authenticate a remote firmware update).

    What I'm trying to say is this is one of those 'management ideas' that sounds great in the philosophical sense, but fails in technical merit.

    • Simple enough. Skip the clock entirely, and let the battery itself be the "clock". The battery dies, and the device no longer operates. It's not particularly difficult to design a system with an embedded, non-rechargable battery that lasts for a specified lifespan. There may be some variability in that time, but you can get close enough this way to kill off neglected devices by a certian point.

      • by RDW (41497) on Wednesday May 14, 2014 @07:56AM (#46997843)

        Simple enough. Skip the clock entirely, and let the battery itself be the "clock". The battery dies, and the device no longer operates. It's not particularly difficult to design a system with an embedded, non-rechargable battery that lasts for a specified lifespan. There may be some variability in that time, but you can get close enough this way to kill off neglected devices by a certian point.

        Take out 'non-rechargeable' and this is pretty much Apple's business model.

    • by jeffmeden (135043)

      If a device does not have a way to keep track of time (eg. in built real time clock, with backup battery that will last for the duration of the device's 'lifetime'), then it becomes vulnerable to permanent denial of service when something spoofs a fake future date and time. What happens when a hundred thousand devices go offline because someone spoofed an NTP response?

      You may as well force every device to have a kill switch and remotely shut it down when it's too old. At least that'll probably require some kind of public key signature from an authenticated service (in the same way you'd authenticate a remote firmware update).

      What I'm trying to say is this is one of those 'management ideas' that sounds great in the philosophical sense, but fails in technical merit.

      That's easy, let it count the hours it runs (as most devices already do) irrespective of time. After 3 years (or whatever) of operation, it stops or creates an annoying ass alarm buzz or something.

      And more to the point, you have probably hit on the real "solution" to the security issue, a remote kill switch. If a vulnerability gets in the wild, simply kill all the affected devices until they can be reflashed with a fixed version (and a new timer). That's what you want to have happen anyway, right? 10 mi

  • by gnalre (323830) on Wednesday May 14, 2014 @06:46AM (#46997515)

    As someone who has to support legacy systems, there is nothing more I would like to see old embedded systems die (and in some cases, incinerated and the embers crushed into the ground).

    But we have to be realistic.

    The main effort in systems like SCADA is the commissioning time required. You cannot just rip out a system, plug in a new box and expect everything to work as before.

    Secondly who pays for this? The customer will not be happy if we say every 5 years we say you have to close your factory down for 2 weeks while we rip out all your old boxes and replace with new ones.

    Finally what is the guarantee that the new box has not introduced a new security hole?

    The real solution is the segmentation of the security and application code. Use Trusted boot technologies to verify the running code and ring fence the code with your security management application. Then if a new threat is introduced you only need to update the security app, leaving the hardware and application untouched.

    Unfortunately at present industrial application either have no security or are very closely coupled meaning that updates are difficult and costly.

    • by number17 (952777)

      Secondly who pays for this? The customer will not be happy if we say every 5 years we say you have to close your factory down for 2 weeks while we rip out all your old boxes and replace with new ones.

      And that assumes that all your boxes perform the same function, were purchased at the same time, from the same manufacturer, and have the same end of life. Otherwise these things would be like individual light bulbs dieing out in an office tower. You would have to have somebody managing the lifetime of every device otherwise its reactionary.

  • by Stephen Bryant (3653487) on Wednesday May 14, 2014 @07:06AM (#46997579)
    There are a lot of cars, insurance telematics devices, security alarms, etc. sitting on mobile phone networks generating signaling and consuming radio resources. They were designed in the early days and largely not reachable. Simply terminating the credentials in the network doesn't help - it actually makes the problem worse because the firmware on the device is often quite aggressive and keeps trying to attach. This is something that has absorbed a lot of my time combating and there are efforts in standards bodies to address. This approach actually a pretty good idea IMO.
  • Blinkered (Score:4, Informative)

    by AlecC (512609) <aleccawley@gmail.com> on Wednesday May 14, 2014 @07:09AM (#46997593)

    This guy has an incredible blinkered view of "embedded devices". Most embedded devises are not connected to the Interned. Should my wristwatch, washing machine, car ignition controller, garage door opener, swimming pool pump, dumb TV, bank vault, disk drive, mouse, keyboard, etc all die prematurely because somebody else makes a router that can be prejudiced. There are literally billions of embedded devices in the world,. of which probably less than one a thousand is connected to the internet. Yet this seems to be suggesting that we should kill a thousand devices because one /might/ be prejudiced.

    • by TeknoHog (164938)

      This guy has an incredible blinkered view of "embedded devices". Most embedded devises are not connected to the Interned.

      Did you mean: Most people who design such devices are interned.

  • roybatty.exe (Score:2, Offtopic)

    by ktakki (64573)

    I've... seen things you people wouldn't believe... Iranian cerntrifuges on fire off the shoulder of Orion. I watched c-beams glitter in the dark near the Ford River Rouge Assembly Plant. All those... moments... will be lost in time, like tears... in... rain.

      Time... to die...

  • 1. From a security standpoint, in a highly controlled environment, remote update capability is also a security risk, no matter how supposedly "secure" that capability is. The ability to configure the hardware so that hands on thr device are required to apply updates is important. Physical security is easier to verify than logical security - it's much easier to inspect seals, padlocks, and security tags than it is to inspect the device firmware.,
    2. Flash memory is relatively cheap, especially in the small si

    • by ebyrob (165903)

      Exactly.

      These things need to be built robust and secure in the first place or no amount of "remote management" is going to fix the problem.

      Why is it so impossible that a product could be created and released, and still perfectly functional after 10 years with no need of a single software upgrade? Because we have no quality control of any value in the software industry. If a car (or worse airplane) suddenly died because it was 5 years old, the manufacturer would be out of business in a week.

  • Very stupid rent seeking idea - especially when it involves all those little things in dusty corners relied upon to "just work" and whatever cold spares are around in case they break.
    It's equivalent to demanding that people replace thirty year old transistor radios in their kitchens and workshops.
  • Rediculous premise (Score:4, Insightful)

    by mschaffer (97223) on Wednesday May 14, 2014 @07:51AM (#46997801)

    This is based on a ridiculous premise that newer=more secure.

    Who is going to pay for all of this?
    What happens when someone forgets to replace some critical controller (gee, I thought your group was in charge of replacing it...)?

    Also, what's In-Q-Tel's real motive? Mandating a secret back-door so that the CIA can have access to what they want? Or, are they quietly investing in Siemens, Rockwell Automation, Hitachi, and the like?

  • by Murdoch5 (1563847)
    I've recently started to put a time tracking system in all my embedded firmwares that lock out the system after X amount of time ( usually in years ), the only way to clear the lock out is to send the part back to my company so we can inspect it. It's no longer suitable to use mean life expectancy of parts as the bench mark for the life of a product, this has made it almost impossible to calculate a real end of life date, instead it's much more practical to do what I've started and to require the products
  • by McDrewbie (530348) on Wednesday May 14, 2014 @08:45AM (#46998169)
    Maybe we should realize that not everything needs to be computerized and networked and the like. Not everything needs to be "smart".
  • by Idarubicin (579475) <allsquiet.hotmail@com> on Wednesday May 14, 2014 @08:58AM (#46998269) Journal

    Okay, so my new device (a LeakyTech router, say) has a five-year expiry clock on it. A vulnerability is discovered a year after I buy it. It spends 80% of its lifetime completely exposed. I'm now out of pocket for the cost of a new device every five years, and I'm only protected for 20% of the time. Nice.

    Or, my new device (from Securitron, this time) is actually quite secure. It takes ten years for the bad guys to find an unpatched or unpatchable hole. Five years of reliable, trustworthy use I could have had get thrown away. I've pointlessly reduced the safe, working lifetime of my electronic device by 50%, doubling my hardware cost and incurring extra downtime for no improvement in my security. Nice.

    Better yet, I've gone through a couple of cycles of forced obsolescence. This time around, I've moved from the Securitron product to the LeakyTech one, and now introduced a hole in my security that wasn't there before. Either the LeakyTech device has another rapidly-discovered vulnerability - maybe it was introduced when they tried to patch their first one-year defect- or I didn't configure the new hardware properly when I was making my enforced switchover. Nice.

  • Oh great. (Score:4, Insightful)

    by funwithBSD (245349) on Wednesday May 14, 2014 @09:00AM (#46998297)

    More DRM killswitches.

  • by morgauxo (974071) on Wednesday May 14, 2014 @09:16AM (#46998427)

    This sounds more like an idea for hardware companies that want to ensure people keep buying their new stuff. It's like chipped printer cartridges.

    First off.. how about just making things updateable?

    Second, how about not connecting things to the internet that don' t have a reason to be?

    The last thing we need is yet more perfectly functional electronics sitting in the bottom of landfills.

  • How about we make the manufacturer either maintain support for the device or release full specs (including source and a sane build environment) to their customers and any signing keys they might need to update the things themselves.

    My plan is more fair abnd might keep things out of the landfill rather than filling it faster.

  • Tire manufacturers in the US resist tires having expiration dates. Why would they mind, since that might increase demand for replacements? Distributors and retailers might mind since it means their inventory loses market value quicker than it would otherwise. Supposedly the manufacturers fear that having an expiration date will imply to consumers that their tires should last until that date. The lifetime might be set at 6 years, which is longer than most tires' tread lasts.

    To some degree I'd expect this sor

  • I think I've read this plot in a book. http://www.goodreads.com/book/... [goodreads.com]

  • This will happen in Jan. 2038 anyway, for many devices, because of the Year 2038 Problem http://en.wikipedia.org/wiki/Year_2038_problem [wikipedia.org]. Anything keeping time using a signed, 32 bit integer that uses the Unix epoch of 1970-01-01 will be affected. I hope someone fixes that problem for pacemakers by the 2030's, just in case I need one.

    --
    .nosig

  • Dan Geer, the CISO of In-Q-Tel is a nutjob or a scumbag trying to just figure out how to bring about a forced revenue stream. Unless he proposes that companies that do this MUST buy back the self deactivated equipment at 50% of retail price, he is simply trying to figure out how to force customers into spending more money by artificial controlled failure.

  • Our shop, up until a few years ago, included some n/c milling machines with very old PC-based controllers. They worked. It was sometimes challenging to find replacement hardware when a power supply or IDE hard drive failed, but once you replaced the failed part, the DOS-based controller software did what it was supposed to do, and did it reliably and repeatedly.

    If the electronics had decided it was time to die, we would have had to replace the machine it controlled, as nobody made electronics and senso
  • KRYTEN is packing himself away, as per instructions. LISTER enters, looking more than a bit upset.

    LISTER: How do we stop it? Isn't there something we can do?
    KRYTEN: I'm afraid not, sir. All mechanoids are supplied with a built-in expiry date. Well, if we lasted forever, how would the manufacturors sell the latest models?
    LISTER: I can't believe it.
    KRYTEN: Oh, don't be disressed, sir. I've lived a long and relatively interesting life. The only truly terrible thing is that, as my adopted

  • Planned obsolescence my ass ...what this guy is proposing is enforced obsolescence. Or to put it another way ... He's proposing that we throw away the idea of purchasing electronic devices and instead pay the same amount of money for the privilege of renting it's capabilities for a period of time set by the manufacturer. I don't know about the rest of you but when I buy something I expect it to work until I want to replace it ...not for some arbitrary fixed period decided by the manufacturer.
  • I sit here in the Cassandra suite, watching the tech community finally waking up to the reality of the world. You are starting to panic because you know none of the operating system choices you have are viable for truly secure systems. Soon you will learn about Multi-Level Secure systems, Capabilities, and other features of the secure computing..

    About 10 years from now, you'll get the hints the universe has dropped on you, and start implementing these systems.

    About 10 years after that, some real old timers

Wernher von Braun settled for a V-2 when he coulda had a V-8.

Working...