Best practices: Improving embedded operating system security

Bill Graham, Wind River

February 14, 2012

Bill Graham, Wind River

Applying Best Practices to Your Embedded Systems
(1) Enable a More Secure Configuration. Despite the hype surrounding the state of embedded security, many of the run-time platforms that these systems are based on can be made more secure through proper configuration.

It is likely that security defects in a new version of an operating system have been fixed when there may still be vulnerabilities in older versions.

Default configurations for embedded operating systems are often tuned for performance and memory footprint and have various features turned off by default. Follow manufacturer guidelines for enabling security features, including the following:

  Enable authorization and privilege levels. Any access must be authorized; users accessing must have the least privilege necessary for all services.

  Enable the network firewall. Modern real-time operating systems (RTOSes) have network firewall capabilities, and any device with a network connection should run with a firewall in place.

  Disable all nonessential services. Enable only those essential for device operation.

  Enable or include robust cryptography libraries as needed.

  Enable memory protection via the memory management unit (MMU); leverage real-time processes (RTPs) instead of kernel level.

  Execute at user privilege unless absolutely necessary.

By choosing a more secure configuration, many of the attack vectors to the device can be removed. It’s better to assume a device is going to be attacked and ensure the configuration that a customer receives is more secure “out of the box.”

(2) Secure Network Communication. Many security issues with existing embedded systems stem from their connection via a network and access that is open to a large population (enterprise network) or even directly to the Internet.

It’s safer to assume that all external connections to a device are unsecure; proliferation of a device to your customer base may go beyond perceived use cases. The best practice is to secure all communications in and out of the device:

* Enable and leverage communication security features of the RTOS network stack.

* Enable the network firewall; allow only communication via required TCP/IP ports.

* Enable secure communication channels: IPsec, SSH, SSL, or VPN access.

* Disable unsecure services such as Telnet.

* Disable debug services if possible; if not, make sure they are secured.

* Consider a VPN-based infrastructure for device-to-device and device-to-control communication.

(3) Partition systems for protection. An effective security technique is to separate different major components of a system into partitions. In some cases, these partitions are physical. Now with virtualization technologies, partitions can be virtual, in software, on the same device or processor.

An example of this is combining a general purpose OS (GPOS) such as Microsoft Windows or Linux and an RTOS on the same device, but each runs in its own virtual environment. In this way, security attacks and vulnerabilities on the GPOS do not affect the mission-critical control done in the RTOS.

Similarly, the GUI and remote access for a device can be in one partition and the control systems in another. Remote attacks that deny service or crash the GUI partition do not affect the control systems. The advantages of combining systems are significant because it greatly reduces hardware complexity and costs.

By leveraging virtualization and the latest multi-core processors, this consolidation is now practical and cost beneficial. Moreover, the separation of critical and non-critical improves safety and security in these devices. Figure 1 below shows an example of a partitioned embedded system.

An attacker may be able to gain access or interfere with a GPOS but would not be able to affect the other partitions in the system. The virtualization layer can ensure proper share of processor time and access to hardware resources to prevent a crashed partition from interfering with the others.

So if the GPOS was taken down or put into an infinite loop, for example, it wouldn’t stop the critical parts of the system from operating. In fact, a partition could be restarted to restore correct operation of the system.