Do Embedded Systems Need a Time To Die? 187
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."
Or you could just you know... (Score:3, Insightful)
... change the password to something other than the default.
my thermostat (Score:4, Insightful)
Absolutely not (Score:5, Insightful)
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_.
What about devices with no RTC? (Score:5, Insightful)
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.
Sympathy, but no go (Score:5, Insightful)
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.
Rediculous premise (Score:4, Insightful)
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?
Re:What about devices with no RTC? (Score:4, Insightful)
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.
Time-based end of life not very helpful (Score:4, Insightful)
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)
More DRM killswitches.
Re:Or you could just you know... (Score:5, Insightful)
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?
Re:Or you could just you know... (Score:5, Insightful)
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 [openwrt.org], 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 [openwrt.org] 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. [wikidevi.com] (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. [openwrt.org] 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. [openwrt.org] (Apparently the correct directory is /attitude_adjustment/12.09.) Now there's a list of subdirectories that look (to me) like p