Improving Embedded Operating System Security Part 3: Secure Your Network Communication

By Bill Graham

Bill GrahamMany security issues with embedded systems stem from their connection via a network with access open to a large population (enterprise network) or even directly to the Internet.  Also, devices designed for small local private networks are increasingly connected to large corporate networks or the Internet directly.

It’s safer to assume that all external connections to your device are insecure – proliferation of your device to your customer base may go beyond your perceived use cases. In other words, expect the worst when it comes to network communication security – don’t assume the data you transmit is not sensitive or not of interest to outside parties. The best practice is to secure all communications in and out of your device (at a minimum make it optional.)

Equally important to data privacy and protection is making sure your device is not susceptible to attack via its network connections. In fact, network connectivity might be the main attack vector for the device so its important to leverage all network security features to prevent successful attacks.

Some examples of network capabilities that improve operating system security include:

  • Enable the RTOS network firewall, allow only communication via required TCP/IP ports – a firewall is a good first line of defense against network attacks. The firewall prevents all non-essential ports and services to be closed off and only allow ports that are specifically configured to be open and available for connection.
  • Enable secure communication channels – IPSec, SSH, SSL or VPN access as appropriate. Assume data transmission can and will be intercepted and its better to assume that all data is sensitive.
  • Disable insecure services such as Telnet or TFTP.  Use more secure alternatives such as SSH and SFTP, for example.
  • Use official encryption certificates for secure services to provide some assurance for trusted connections (e.g. SSL certificates for device terminal connections via SSH)
  • Disable debug services if possible, if not make sure they are secured. Debug services are meant for device development and enable full access to the RTOS, memory and devices. Removing the debug agent is recommended.
  • Consider a VPN-based infrastructure for device-to-device and device-to-control communication. Some RTOS such as VxWorks, support full VPN connectivity allowing privately networked devices.

These suggestions can go a long way to improving the security of the transmission of data and preventing attacks via your device’s network connections. I’ve listed a few recommended practices; I’d like to hear more suggestions.