Slashdot Mirror
Do Embedded Systems Need a Time To Die?
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."
In-Q-Tel
Best Slashdot Co
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.
Sent from my PDP-11
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.
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?
I do not fail; I succeed at finding out what does not work.
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_.
All rites reversed 2010
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.
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.
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies
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.
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.
Consciousness is an illusion caused by an excess of self consciousness.
And how do you predict when that would be?
Does it help at all when I design my embedded device self destruct on 14 May 2019, if the next Heartbleed type bug affecting it is found tomorrow?
Are my customers going to come back and buy from me again if it is still rock solid with no known bugs on the day I choose for it to expire, and word quickly gets around that everyone's device was preprogrammed to die on that day?
OpenWRT is so fucking easy to install and configure (easier than some consumer out-of-the-box experiences, even) that there really is no excuse if you expect a secure local network ... there is no actual technical knowledge required, just basic keyboard/mouse skills, and reading comprehension.
I think you're *wildly* overestimating the skill and confidence of the average home network user and the quality of open source project web sites. Let me walk you through the hidden minefield in your instructions. I'll use a Linksys WRT150N for reference.
The real Step 1 is "realize that I'm supposed to install OpenWrt, and understand what that means". Most users have little to no idea of how the router actually works, so the idea of upgrading the firmware is not an obvious one.
But let's say someone tells them to do it. They go to the OpenWrt web site. The second sentence under "What is OpenWrt?" is "Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management.". Many users will be too terrified to proceed beyond this point. But let's say they make it to the Table of Hardware, and skip past the text about developer snapshots and hardware VLANs and the note from 2009 saying that the page might not be up to date. (That's not realistic -- many users expect to read sequentially.) Instead of a column that says "yes, this router is supported", there's a column named "Status" that gives the first OpenWrt version that supports the router. Next to that there's a column named "Version" that is undefined. I'm assuming it's the router version, but many users could get confused. But the important column is the "Target" column, which lists the specific OpenWrt platform that users should (but probably won't) remember for later. There are two targets for the WRT150N and no indication of which to choose. One of them no longer exists in the current version.
Clicking on the model number in the table gives me an unorganized series of notes from various users. One of them, "An account of flashing OpenWrt to a WRT150N", sounds sort of like installation instructions, but is too brief and technical to be of any use. It does have a working download link, but it's to a version that's five years old. The one after that suggests that one target option (the nonexistent one) is better than the other. None of this is in clear newbie-friendly language and it's all after pages of Linux log dumps. If they land on this page, most users will probably click the back button as fast as they can.
Alternately, we could do it your way:
Step 1, find out what runs on your router (at wikidevi or similar)
That's somewhat better, but they still have to read through a dense, abbreviation-heavy table of technical specs. (That's after they figure out they need to search for their router's model number and not "Linksys".) At least there's a simple indication that OpenWrt supports the router. But how would they know to go to WikiDevi? I hadn't even heard of it before today. And most importantly, how would they figure out which target to use, or even that targets exist?
step 2, download the firmware image
Now we're in for some fun! There's a download link at the top of the OpenWrt site. Clicking on it gives me a directory listing. None of the directory names look like they contain software to download, even to me. On the right side of the OpenWrt main page there's another download link for the latest release. This gives another directory listing. (Apparently the correct directory is /attitude_adjustment/12.09.) Now there's a list of subdirectories that look (to me) like p
Visit the