Protection of RTOS

 

SECURITY AND PROTECTION OF RTOS

With the rapid growth of the IoT and the number of new devices being developed to take advantage of it, it’s becoming more and more likely that you will consider using an RTOS in the near future. But before you come in use with RTOS technology, you have to be CAREFUL and SECURE about your devices and protect your devices from the Hackers. The remainder of this article will explore you from the CYBER ATTACKs and keep protected YOURSELF.

Firstly, what actually a RTOS is?

Real-time operating system (RTOS) is an operating system intended to serve real time application that process data as it comes in, mostly without buffer delay. RTOS are used in environments where a large number of events, mostly external to the computer system, must be accepted and processed in a short time or within certain deadlines. such applications are industrial control, telephone switching equipment, flight control, and real-time simulations.  With an RTOS, the processing time is measured in tenths of seconds. This system is time-bound and has a fixed deadline. The processing in this type of system must occur within the specified constraints. Otherwise, This will lead to system failure.

Examples of the real-time operating systems: Airline traffic control systems, Command Control Systems, Airlines reservation system, Heart Peacemaker, Network Multimedia Systems, Robot etc.

Various ways that can be ATTACKED on to your devices:

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.

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.

 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.

 Memory Protection via Memory Management Unit (MMU)

This protection 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.

 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.

 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.

 

SOLUTION 

But there are couple of solutions from which you can be PROTECT yourself.

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.

 Sufficient Allocation of Storage Space

Quotas are a security control that’s implemented to guard the device from running out of disk, memory, or CPU. As an example, if a DDOS attack is formed 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 number of critical resources –such as CPU — a task is able to consume, the overall system is protected from such an attack.

 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.

RTOS are developed considering the time, space, computational cost constraints. The rise in its use, access, and networking have created the need for securing the system. The security of an RTOS starts at its design and development phase. In this way, software professionals attempt to build software that can withstand attacks proactively.

Some basic  Precautions to be taken:

• 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 behavior.
• 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 behavior 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.

BY -

        Gajendra Jangid

        Tanuja Jadhav

        Vedant Jathe

Sources:

• https://www.geeksforgeeks.org/real-time-operating-system-rtos/
• https://www.guru99.com/real-time-operating-system.html
• https://www.javatpoint.com/real-time-operating-system
• https://insights.tuv.com/blog/embedded-systems-cybersecurity-foundation-within-the-rtos
• https://swaraj-mane18.medium.com/real-time-operating-system-rtos-security-and-protection-9e217812e5c1