Re: potential security issues with embedded systems?

[Gary Flynn <flynngn () JMU EDU>]

Kyle Barger wrote:

> The recent story about Diebold teller machines being hit by the Nachi worm
> started me thinking.  In the past few months I've seen demonstrations of a
> PBX system and of a "one card" debitcard/building access system that were
> both based on Windows.
>
> We all know what we've had to deal with in terms of security issues for
> Windows as a server and desktop OS.  What has the track record been for
> embedded systems that use Windows?  Is this enough of a concern to take
> such products out of the running for future consideration?  What about
> other operating systems?  If I buy a firewall appliance that's built on
> Linux, should I worry about how fast the vendor will be releasing firmware
> upgrades to handle Linux security issues that crop up?
>
> Any experiences or thoughts are appreciated.

No experience. Just some random thoughts.

Like the present situation with desktops, we may not realize
how vulnerable we are until a critical mass of devices are
in existence and people start paying the wrong kind of
attention to them. Then we're left to cope with a population
of devices designed and deployed in an environment that has
transformed into something they were not meant to deal with.

A lot has to do with the level of accessibility and user
interaction.

If a client system ships with listening ports, be wary.
It means the vendor hasn't learned any lessons about leaving
doors open to software which could later be found to have
problems (or is just behaving irresponsibly in that regard).

Lacking listening ports, and assuming core functionality is
solid (like properly subtracting withdrawals from balances),
leaves user interaction and communications as the risk points.

A lot of the problem with general purpose computers is that
they're general purpose, totally under the control of the
generally computer-uneducated end user, and loaded up with
multi-purpose, high functionality software. That leaves the
designers with having to deal with almost infinite
variables.

Single function devices with limited functionality should
have less complexity and a smaller risk footprint regardless
of vendor. The interface to a 10 digit keypad with menu
selected choices should be easier to verify than the
interface to a web browser. Kind of like a VT100 or thin
client. :)

Of course, if functionality starts getting layered on
(customized internet streamed music while you wait for your
receipt, check your email while you get your money, remote
administration web servers, ATM access from a cell phone,
etc.) then all bets are off. That isn't so much a security
problem with the product as it is a demonstration of poor
judgment and discipline on the part of the vendor and
purchaser.

The other consideration is whether a mission critical or
high value target should use a public network for
communications when it does not need to be accessed by the
general public over the public network. SCADA systems and
ATM machines come to mind.

Finally, regarding vendor support, ideally it would be
contractual. Vendor has X days or weeks to retrofit security
patches into the product. But how many of you have been told
by a vendor that a service pack or security patch hasn't been
tested or isn't supported on your configuration? When we sign
licensing contracts that state the software isn't guaranteed
to do anything and limits damage to the lessor of actual loss
or $5.00, its difficult to force vendors to act responsibly. :)

Viewing the dichotomy between certain vendor's marketing web
sites and their licensing terms and security recommendations
reminds me of the cigarette manufacturers' commercials
touting their smoking and health information web sites. Its
nauseating.

Interesting related item:
http://www.microsoft.com/automotive/windowsautomotive/
http://www.usatoday.com/tech/news/techinnovations/2003-03-27-car-windows_x.htm
http://www.microsoft.com/presspass/press/2002/jul02/07-15TelematicsWorldwidePR.asp

--
Gary Flynn
Security Engineer - Technical Services
James Madison University

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.