RTOS in Context of Cyber Security

Conformance Strategy

At Embedded Office, we have made it our mission to support customers with the Flexible Safety RTOS in all areas of safety and security. We therefore prepare the RTOS as a software component for use in compliance with safety and security standards.

In planning the strategy for the Flexible Safety RTOS to achieve the security requirements which are relevant for a software component, we have identified the following approach:

This strategy has three main objectives that we need to keep in mind:

1. Security risks associated with the RTOS must be identified and minimized.

2. The RTOS should be essentially free of systematic errors.

3. Maintenance processes such as hazard logs and update procedures must be in place.

We conclude that we can achieve our top-level goal by performing a gap analysis for the current product's compliance with security standards and a threat analysis at the component level.

Gap Analysis

The RTOS is already a pre-certified component for functional safety in accordance with IEC61508. During the gap analysis, we are looking at all applicable requirements of IEC62443 and identifying the evidence in our established safety management process. As this is a pre-certified product, the main additions required are traceing the existing items to the security requirements.

Threat Analysis

IEC62443 does not give us precise instructions on how to analyze threats but specifies a number of characteristics that we must consider. We base our systematic approach on the ISO21434 standard. In this automotive security standard, threat analysis is referred to as TARA (Threat Analysis and Risk Assessment).

Purpose of the Analysis

Before the analysis starts, we must define the purpose and scope of the investigation. The RTOS analysis aims to minimize the cyber security risks that affect the users and the environment of the customer applications.

Scope of Analysis

The scope of the analysis can only consider cyber attacks within the RTOS provider's sphere of influence. Attacks before the system starts the RTOS or physical attacks are not part of this analysis.

The specific RTOS architecture determines the detailed scope:

1. The API functions provide access to all RTOS services.

2. The configuration of the RTOS is a potential target for cyber attacks.

3. The memory protection system - controlled by the RTOS process manager.

4. The CPU availability - controlled by the RTOS scheduler.

5. The consistency of the delivered RTOS source code.

Hackers can use the API functions and the delivered RTOS source code for their cyber attacks. This is called the attack surface. We need to protect the RTOS configuration, memory protection system, and CPU availability. These items are called the security assets.

Risk Assessment and Risk Treatment

The risk assessment can start once we have identified the safety assets and possible attack paths. The aim is to determine a quantitative risk value for each hazard and define a suitable strategy for dealing with it.

We use a bottom-up approach for the risk assessment, which means that all possible hazards are analyzed qualitatively for each identified security asset. We systematically analyze each security asset's threats, attack paths, and potential damage. The STRIDE model helps us to analyze each threat scenario with the corresponding cyber security property in mind:

• Spoofing (authenticity)

• Tampering (integrity)

• Repudiation (non-repudiation)

• Information disclosure (confidentiality)

• Denial of Service (availability)

• Elevation of Privilege (authorization)

The Impact Rating and the Attack Feasibility Rating determine the quantitative risk values. While it is often difficult to estimate these values precisely, we use the worst-case scenario when in doubt.

Results

The Flexible Safety RTOS has undergone a vulnerability analysis, and 11 potential security issues have been identified and addressed. We implement improvements to the delivery process and enhancements to the documentation and the RTOS functionality. The enhancements include:

1. managing access rights

2. centralized error management

3. extended memory protection system

4. protection of sensitive information

Conclusion

The Flexible Safety RTOS is considered as a component in the IEC62443 standard. As the specific application of the customer product is unknown, and the RTOS cannot provide all required security measures, the possibilities for applying this standard are limited. However, the threat analysis revealed possible improvements in terms of cyber security. Fixing the findings leads to additional functionality to support architectures with trust boundaries. Improved documentation supports the customer in securely integrating the RTOS into their cyber security-compliant product. The vulnerability analysis results lead to improvements that increase user security by supporting the creation of clear trust boundaries and reducing potential integration errors in a cyber security context.