Monthly Archives: October 2013

Embedded Device Security – Not My Problem



October 23rd, 2013

By: Alan Grau, Icon Labs

Anyone who seriously studies embedded device security will quickly realize that embedded security is very different than enterprise or desktop security.  The challenges for securing enterprise and PC networks are different from the challenges for securing a network of fixed function devices.

A few of the factors that make embedded device security different are:

  • Most embedded devices are fixed function devices.  Once they are shipped they cannot be upgraded to add security after the fact.
  • Embedded devices are special purpose devices, not general purpose devices like PCs or servers, and as a result require special purpose security solutions.
  • Embedded devices frequently run real-time operating systems such as VxWorks or INTEGRITY and cannot run security solutions designed for Windows or Linux based systems.
  • Once deployed, the devices cannot be upgraded to add security fixes unless the device manufacturer provides an upgrade.  The end user cannot buy security software from a third party and install it on the devices.
  • There are millions of devices already deployed that lack protection and for which there is no readily available security solution.

Since end users of embedded devices cannot install security software onto the device after the fact, the responsibility for security would seem to fall squarely onto the shoulders of the OEMs who build the device.  Security for embedded devices has to be built into the device itself.  All too often, however, OEMs push off the responsibility for the security of the device to the operating system running on the device.  They argue that the OS is responsible for the security of the device.  Or even worse, that security is either not a requirement or provides no competitive advantage and therefore can be ignored.

Since you were interested enough to read this article, you likely already agree that security is an important requirement for most embedded, network enabled devices.   Granted, the security requirements differ from device to device.   Security is more critical for a heart pacemaker with wireless communication capability than for Wi-Fi/GPS system that is used to track and locate  lost hospital beds (and yes, according to an engineer with a company building hospital beds, this is a real problem).

If security is a requirement – whose responsibility is it? 

Unlike enterprise and PC security, where responsibility lies mainly with the end user organization, security for embedded devices is primarily the responsibility of the OEM building the devices.  However, the OEM is not solely responsible.  Everyone involved in the development and deployment of the device plays an important role.

The role of the OEM

The OEM plays the primary role in embedded device security.  They are ultimately responsible for specifying security requirements, implementing security in the device and testing the device to ensure it meets the security requirements.  The OEM is responsible for selecting an OS and processor that meet the security requirements of the device. They are also responsible for ensuring that the device uses security protocols, secure authentication and protections mechanisms such as an embedded firewall to protect the device from attack.  Unfortunately, we have seen too many cases of OEMs taking the “not my problem” approach to security far too often.

The FDA and Department of Homeland Security recently issued an alert urging medical device makers and medical facilities to upgrade security protections to protect against potential cyber threats. This came in response to an ICS-CERT publication of a list of more than 300 devices with hard coded passwords.

The role of the OS vendor

While it is the role of the OEM to select the OS, the OS vendor (or open source community creating and maintaining the OS) is responsible for ensuring the security of the OS.  Typical communication protocols and services are bundled with the OS and these provide one of the main attack vectors for cyberattacks.   The OS vendor should be responsible for ensuring the security of each of the components they provide.

The role of the chip vendor

Chip vendors also play a key role in embedded device security.  They are building processors with built in code verification capability, physical tampering detection capability and encryption engines.  These tools allow OEMs to develop and deploy devices that can verify they are running authentic code and to detect when someone has physically opened a device. Once these events are detected, they can then shut the device down or report the event to prevent tampering.

The role of the specialized security companies

OEMs, end users, and even RTOS companies do not always have the expertise to ensure all aspects of device security are addressed.  Companies specializing in embedded device security provide expertise, tools, specialized security solutions and security audit and verification services.  These companies can play a critical role in embedded device security by ensuring compliance with security standards, providing education to OEMs and end users, and testing devices to ensure they are not vulnerable to cyberattacks.

The role of the end user

The end user is depending upon the OEM and the OEM’s suppliers for providing a device with adequate security capability.  It is up to the end user to ensure the device is deployed in a secure manner.  The end user must properly set passwords, enable authentication and perform any other steps required to deploy the device in a secure manner.  Far too often, devices are deployed with weak or default parameters or without security enabled, leaving the device open to attack.

The end user is also responsible for demanding that OEMs add security to their devices.  Just last week I was in a meeting with Fortune 1000 OEM and was told that “our customers are not requiring security”.  Even if this is true, the OEM needs to understand that security is an unstated requirement.  However, more end users need to stand up and demand security.

Security Responibility

Summary

The only way to ensure embedded devices are secure is through the coordinated effort of everyone involved in the development and use of the product.  Unfortunately, no one group can by their efforts alone ensure that a device is secure.  However, a failure to implement or properly use security at any stage in the process can result in a device with a significant security loophole.  No one can afford to say embedded device security is “not my problem” any longer.

Alan Grau

Alan Grau is President and co-founder of Icon Labs, a leading provider of security software for embedded devices.  He is the architect of Icon Labs’ award winning Floodgate Firewall.  Alan has 20 years of embedded software experience.  Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola.  Alan has an MS in computer science from Northwestern University. You can reach him at alan.grau@iconlabs.com