Improving Embedded Operating System Security Part 2: Enable a More Secure Configuration

By Bill Graham

Bill GrahamDespite the hype surrounding the state of embedded security, many of the runtime platforms that these systems are based on can be made more secure through proper configuration. Moreover, it’s important to keep the platform updated since the RTOS likely has many security vulnerabilities fixed that were present in older versions.  Default configurations for embedded operating systems are often tuned for performance and memory footprint and have various features off by default. Follow manufacturer guidelines for enabling security features which may include:

  • Enable authorization and privilege levels – any access must be authorized, users accessing must have least privilege necessary – for all services. If command line shell access is required, for example, ensure it is secure, password protected and the user privilege level is a low as possible.
  • Enable the network firewall – modern RTOS have network firewall capabilities and any device with a network connection should run with a firewall in place. Firewalls are standard practice for desktop and server systems – embedded devices are increasingly connected to the same networks as larger scale devices.
  • Disable all non-essential services; enable only those essential for device operation. Many attacks on networked devices are looking for open ports, sometime left open unintentionally (or intentionally but without foresight to the insecure environment the product runs in).
  • Enable or include cryptography libraries as needed – if, for example, optional levels of encryption are offered, select a robust hashing or cryptographic library
  • Enable memory protection via the memory management unit (MMU), leverage real time processes (RTPs) instead of kernel level tasks. Most RTOS provide POSIX-compatible user-level processes and threads that can be used for application coding. Memory protection and isolation from the kernel-mode operation provides a layer of protection against malicious code.
  • Execute at user privilege unless absolutely necessary – many RTOS provide user and kernel mode execution. User mode execution usually excludes system functions that can disrupt the entire system.

By choosing a more secure configuration, one can remove many of the attack vectors to the device. It’s better to assume your device is going to be attacked and ensure the configuration that your customer receives is more secure “out-of-the-box.” Above all, provide user authentication and a proper password policy – all the security features in the OS are for naught if an attacker can bypass authentication with an easily guessed password.

I’d like to hear of other built-in features that I’ve missed from this list – let me know in the comments.


For additional information from Wind River, visit