There has been growing concern with the security of embedded devices as they continue to proliferate in several industries. This is caused by a confluence of several issues that makes for a difficult problem to solve.

First, these devices more and more rely on commodity operating systems (which carry with them commodity vulnerabilities and exploits).  Second, there is a great deal of restriction with what consumers of these devices can do with them.  Very often, you simply can’t touch the operating system at all.  Last, these devices tend to be notoriously difficult to update usually requiring the vendor to come out with a CD to “reflash” the device. Updates are few and far between, if updates are put in place at all.

The product is that this puts a device subject to a good subset of the same vulnerabilities that any workstation is but makes it very difficult to put it in the same patch rotation much less maintain and harden it.  Ideally, these devices shouldn’t be plugged into a network, but often they are.  For instance, many embedded devices for SCADA and healthcare have reportedly been infected by Conficker (among others).

In those cases, they just got infected with commodity malware and behaved like your typical infected host. The scary part of this is, these devices can control very important things. Years ago, I would chafe at anyone using the word “cyberterrorism”. Terrorism has a specific definition that is a bit more restrictive than “something bad”.  It’s not terrorism unless widespread debilitating fear is involved.

However, now with embedded devices in hospitals, you have devices vulnerability to commodity exploits but the payload can be modified to do something bad with that devices functionality.  In health care, for instance, if the device controls some “life-saving” or “life-sustaining” function, malware could have it intentionally cause harm.  That would be an example of cyberterrorism.  People would very quickly develop a fear of health care.  So what can we do about it?

The real solution is that embedded device manufacturers need to provide updateability to these devices and ship them hardened. Barring that, here are some tips to help protect facilities that use these devices.

1)    If they don’t need to be on a network, take a Cat5 cable, cut off the RJ45 adapter and about an inch of cable and plug that into the port.  Not only does this fill the gap, it makes people think twice before “just plugging it in”.  Hang a note off the cable, if necessary.
2)    If these devices have a unique vendor for the network card, use network access control to simply block all the MAC addresses for that vendor.  For instance, MAC address AA:AA:AA:22:22:22 has a vendor portion of AA:AA:AA and the unique host portion is 22:22:22.  So block AA:AA:AA:*.
3)    If they absolutely must be networked, create an “islanded” network. In short, a network where there is no external facing components or totally isolated LAN.
4)    Limit all access to the device via network, via USB or via Bluetooth.  All these can be used as infection mechanisms.

What are your thoughts? Those of you using embedded devices or vendor “black boxes”, how are you securing them?

--
John Bambenek
bambenek /at/ gmail.com