Performing the Threat Analysis and Risk Assessment (TARA) Analysis Out Of Context
22 Aug, 2025Cybersecurity is becoming a critical focus in embedded systems, particularly within the automotive industry, as vehicles become increasingly interconnected. This blog explores how the ISO 21434 standard is applied to enhance cybersecurity in automotive systems, focusing on the integration of security practices throughout the product lifecycle.
As WITTENSTEIN high integrity system’s flagship product, SAFERTOS® is designed specifically for safety-critical and security-sensitive embedded systems, making it the ideal choice for ensuring robust protection in connected vehicle environments. In this article, we’ll discuss conducting SAFERTOS® security analysis, incorporating Threat Assessment and Risk Assessment (TARA) results, and the practical implementation of these practices, leading to the development of the SAFERTOS® Enhanced Security Module. By aligning with industry standards, this approach provides a structured framework to manage risks and safeguard interconnected vehicle components from evolving threats.
The ISO 21434 Standard
ISO 21434 is a standard focused on managing cybersecurity threats in road vehicles, applying to all organizations involved in the supply chain. It covers cybersecurity management at both the organizational and project levels, as well as throughout the entire product lifecycle, from concept to post-development support. Key areas include managing cybersecurity across the supply chain, ongoing monitoring and incident management, and incorporating TARA methods into product development phases. TARA, referenced throughout the standard, is a continuous process aimed at identifying risks that can affect both organizational and product-level security.
Figure 1 ISO 21434 Scope
The TARA process involves several steps, including asset identification, threat scenario analysis, and impact rating, where risks are assessed across safety, financial, operational, and privacy categories. Attack paths are analyzed for feasibility, and risks are assigned a numerical value. The final step involves risk treatment decisions, which may include avoiding, reducing, sharing, or accepting risks. These activities help to ensure a structured approach to managing and mitigating cybersecurity threats in automotive systems.
Applying the ISO 21434 Standard to a Generic Software Component
ISO 21434 recognizes the role of the supply chain and addresses the use of off-the-shelf components through two approaches: treating them as either a component out of context or as an off-the-shelf component. These approaches are not mutually exclusive, and the choice depends on how the component is integrated.
For an off-the-shelf component, the organization using it must determine its suitability by reviewing documentation to ensure it meets cybersecurity requirements. If the documentation is insufficient, additional activities to conform with ISO 21434 must be performed. In contrast, when a component is developed out of context, the supplier provides it for general use without a specific application in mind. The supplier is responsible for documenting the intended use and external interfaces and must generate cybersecurity requirements based on these assumptions. When the component is deployed, its cybersecurity claims are then validated.
Performing The SAFERTOS® Security Analysis
Performing a SAFERTOS® security analysis presents challenges due to the lack of a defined external interface in end-user applications. As an RTOS, SAFERTOS® offers services controlled by the API, but without knowledge of the application’s purpose or deployment, security analysis becomes difficult.
Figure 2 Performing the SAFERTOS® Security Analysis
Key assumptions were made to define the threat boundary for SAFERTOS®, such as assuming the presence of a cryptographic boot process, the use of a Memory Protection Unit (MPU), and a processor architecture supporting privilege levels. Additionally, physical access threats were considered outside the scope of the component due to its unknown deployment environment. These assumptions were classified as ‘shared’ requirements, to be addressed by the integrator. The threat boundary was defined around the interfaces between the SAFERTOS® kernel and the host application, with the TARA process identifying assets (such as these interfaces) and evaluating them against threat scenarios using the STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
Figure 3 Summary of the TARA Process
In an out-of-context scenario, the impact of security risks for SAFERTOS® cannot be fully assessed without knowing the specific application, so all risks were categorized as affecting all impact areas. During the attack path analysis, each threat’s feasibility was evaluated based on five factors: specialist expertise, window of opportunity, equipment/effort, elapsed time, and knowledge of the item. With an unknown system and environment, worst-case values were assumed, such as public knowledge and unlimited access. The risk value was deemed “severe” due to the unpredictable potential damage, and risk treatment decisions were made, with many risks classified as ‘shared’, ‘reduced’, or ‘accepted’ based on deployment and configuration.
The SAFERTOS® Enhanced Security Module
The primary outcome of our TARA process was the SAFERTOS® Enhanced Security Module (ESM), designed to address vulnerabilities in task management, even with memory protection (MMU/MPU) in place. The ESM provides additional tools to restrict task behaviour and ensures spatial separation between tasks and the kernel using hardware support. It includes a high-level API wrapper that enforces object handle obfuscation, access control policies, and task context data security. While the ESM strengthens system security, it must be used alongside other protections such as secure booting, encryption, and hardware-driven security.
Figure 4 SAFERTOS® and the ESM
Key features of the ESM include obfuscated handles, which prevent direct references to object control blocks and use a lookup table for efficient mapping, and the Access Control Policy (ACP), which restricts task access to specific SAFERTOS® functions. The Object Access Control Policy (OACP) further limits task access to specific objects, while the Penetration Detection Monitor enables error detection to identify potential hacking attempts. Additionally, task context data is isolated in memory, preventing unauthorized access, and all data transfers between SAFERTOS® and user memory are validated for security.
In this blog, we’ve explored the steps involved in enhancing SAFERTOS® to improve its security capabilities in cybersecurity-sensitive environments. We’ve discussed how relevant standards were applied to a product that must function as a versatile, general-purpose component within a broader device ecosystem, such as in the vehicle supply chain. We’ve discussed how the Threat Analysis and Risk Assessment (TARA) process identifies potential vulnerabilities and evaluates risks, leading to the development of the SAFERTOS® Enhanced Security Module (ESM).
By aligning with ISO 21434 and employing advanced security measures, the SAFERTOS® ESM enhances the overall security of automotive systems, ensuring they are better protected against evolving cybersecurity challenges. Find out more today about the ESM.
Author
Stephen Ridley, Engineering Fellow.
Back to News