Embedded Systems Cybersecurity – foundation within the RTOS

In late July 2019, a real-time operating system from VxWorks was making headlines for a bug that had exposed 200 million critical devices. Unlike Windows, iOS, or Android, this OS from VxWorks was probably unheard of until security firm Armis detailed a cluster of 11 vulnerabilities in the platform networking protocols – 6 of which could potentially provide hackers remote device access and allow a worm to propagate the malware across other devices. While there was no known impact from the vulnerabilities discovered, device manufacturers are increasingly getting aware of cyber risks around the devices they design and manufacture.

Some key attributes for an RTOS in the context of cyber readiness

A real-time operating system is a multitasking operating system designed for real-time applications. Real-time operating systems are commonly found and used in robotics, medical equipment, elevator controls, cameras, complex multimedia animation systems, scientific research equipment and communications. RTOS is frequently used in cars, military, government systems, and other systems that need real-time results. Given that RTOS is used in industries and applications which requires tasks to be processed quickly without delay, the security aspect of RTOS needs to be given high importance as any security compromise to the system may disrupt its operations, which could potentially lead to catastrophic impacts affecting the environment and safety of human being.

Below are some of the security capabilities and features which should be considered for the selection of an RTOS during the product development program:

• Usage of MILS (Multiple Independent Levels of Security) architecture – It is an architecture that defines an approach to security. Unlike monolithic kernels that perform all trusted functions for a secure operating system, MILS introduces the concept of a separation kernel to implement a set of functional security policies that regulate the information flow.
  
  The MILS divide-and-conquer approach is implemented in four layers: trusted hardware, separation kernel, middleware, and applications. The separation kernel is built on four fundamental security policies:
• Data isolation, which ensures that a partition cannot access resources in other partitions
• Periods processing, which ensures that applications within partitions execute for the specified duration in the system schedule
• Information flow, which defines the permitted information flow between partitions
• Fault isolation, which means that a failure in one partition does not impact any other partition within the system
• Identification and authorization – The RTOS system should have a secure identification and authorization mechanism in place to verify a user. If users are not properly identified and authenticated, then the embedded device is potentially vulnerable to access by unauthorized users. User accounts within an embedded device should not be static in nature. Features that allow separation of user accounts for internal web management, internal console access, as well as remote web management and remote console access should be available to prevent automated malicious attacks.
• Authorization and privilege levels – any access must be authorized, users accessing must have the least privileges 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 as low as possible. The use of privilege levels gives the RTOS a tool for preventing malicious programs from seriously affecting system operation.
• RTOS 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. The firewall should only allow communication via required TCP/IP ports – a firewall is a good first line of defense against network attacks. The firewall ensures all non-essential ports and services are closed off and only allows ports that are specifically configured to be open and available for connection.
• Usage of secure communication channels – IPSec, SSH, SSL or VPN access should be used as appropriate for all methods of communication. Assume data transmission can and will be intercepted and it is better to assume that all data is sensitive.
• Disallow insecure services – Insecure services such as Telnet or TFTP should be disabled. RTOS system should support more secure alternatives such as SSH and SFTP.
• Support the use of official encryption certificates – Network communication and secure services should use official encryption certifications to provide some assurance for trusted connections (e.g. SSL certificates for device terminal connections via SSH)
• Disable debug services – Debug services should be disabled when the RTOS system is in operation, if possible. Otherwise, ensure that there are security controls in place to secure it. Debug services are meant for device development and enable full access to the RTOS, memory and devices. Removing the debug agent is recommended.
• Disable all non-essential services – enable only those essential for RTOS 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 system runs in).
• Usage of industry standard cryptography libraries – if, for example, optional levels of encryption are offered by RTOS system, a robust hashing or cryptographic library should be selected.
• 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 mode privilege – many RTOS provide user and kernel mode execution. User mode execution usually excludes system functions that can disrupt the entire system.
• Sufficient allocation of storage space - Quotas are a security control that is implemented to protect the device from running out of disk, memory, or CPU. As an example, if a DDOS attack is made against the RTOS system with the intent of overusing the CPU, an unprotected device could essentially appear to freeze up. By being able to set limits on the amount of critical resources –such as CPU – a task is able to consume, the overall system is protected from such an attack.
• Secure Boot Loading and Execution – Securing the boot image is an important step to secure the RTOS system. RTOS system should have the capability to verify authenticity of boot loader and also secure mechanism in place to prevent and detect tampering of boot image.
• Secure Data Storage – RTOS system should have capabilities to store data securely using techniques such as encryption and partitioning. No assumptions should be made about the classification and privacy of data used in RTOS systems.
• Residual information protection – the system should have a residual information protection security feature in place which ensures that whenever a resource is allocated or freed, the content of the resource can be made unavailable to others’ processes. A secure RTOS makes user memory and file-system data unavailable to others when it is freed, resulting in a more secure system. Whenever a file-system object is removed, all the blocks allocated to that file-system object will be filled with zeros.
• Audit logging – Audit facilities allow an embedded device to capture significant system events and perform security monitoring of these events. Examples of fine-grained event auditing include events like login, logout, object accesses, and administrative tasks, all of which can be logged to an audit trail. The audit trail contains valuable information that can be used to review security-critical events, discover attempts to bypass security mechanisms, and perform forensic analysis. The audit trail thus provides a deterrent against attempted attacks since audit logging captures any intrusion attempts.
• Software update verification – Updates for RTOS should be delivered over a secured channel and verified after download to ensure that updates are legitimate. Binary signing (and checking) and update hashes delivered over a verified, encrypted, channel ensure that malicious updates are not installed on the system. If there are 3rd party components being used, the RTOS system should have the capability to report on versions and update these components as they age or security updates become available.

Additionally, the following is a list of security best practices (Source “Writing Secure Code” Michael Howard; David LeBlanc, Microsoft Press, 2004) as applied to embedded development:

• Minimize the attack surface – Turn off features, services and access not necessary for most users to reduce the number of attack vectors into the system.
• Least privilege – assigning just enough privilege to an application, task or process to achieve the job at hand. High privilege level that is unnecessarily assigned allows for unwanted access or behaviour.
• Defense in depth – rely on more than one layer of defense and do not count on any one layer as providing complete protection.
• Diversity in defense – use different types of defense, different devices, software or vendors.
• Secure the weakest link – as with any system, it’s only as good as its weakest component. Similarly for security the most insecure component, interface or application is the most likely avenue of attack.
• Fail-safe stance – expect vulnerabilities to be found, and expect physical and remote attacks on the system. The embedded system should have capabilities to fail securely when there are unexpected or unintended operations being performed.
• Assume external systems are insecure – do not make assumptions about what other devices the system will be connected to. It is safer to assume that external devices are insecure and that the system is connected to a wide-open network.
• Secure by default – set the default configuration and behaviour of the system to be as secure as possible. This includes turning off features, services and access not necessary for most users.
• Simplicity and usability – in general a good design principle. Simpler designs are less likely to have security bugs and vulnerabilities, easier to understand and audit, and easier to test.

If you are a product engineering firm designing and manufacturing products using embedded systems for automotive, medical, marine, imaging technology, UAVs, and Robotics and would like to know how we could help you manage your cyber risks, click below:

Sources:

https://blogs.windriver.com/security/2012/02/improving-embedded-operating-system-security.html

https://blogs.windriver.com/security/2012/03/improving-embedded-operating-system-security-part-2-enable-a-more-secure-configuration.html

https://blogs.windriver.com/security/2012/03/improving-embedded-operating-system-security-part-3-secure-your-network-communication.html

http://mil-embedded.com/articles/securing-connected-embedded-devices-using-built-in-rtos-security/

https://www.eetimes.com/document.asp?doc_id=1279000

http://people.cs.ksu.edu/~danielwang/Investigation/RTOS_Security/RTOS_Security.pdf