Model-Based Security Risk Analysis

Introduction

How are security risks anticipated and mitigated? Industry standards such as ISO^®/SAE^® 21434 and DO-356 require answering this question before new products are brought to market. This can be hard to do without a unified process for documenting, tracking, implementing, and verifying changes. Depending on your industry, you may know this process as TARA (threat analysis and risk assessment), SRA (security risk assessment), or some other name. By employing a model-based framework for SRA (Figure 1), you can achieve tight coupling between your design and its safety and security through a guided step-by-step process. You can also easily tailor, extend, or automate the process to suit your needs using the many capabilities of MATLAB^®.

A diagram showcasing the security analysis process flow with “Architecture & Implementation Models” and “Security Goals” as inputs. The diagram includes three key steps in the “Static Analysis” phase: 1) Suggest assets, threats, and countermeasures; 2) Enforced Threat & Risk Model; and 3) Model attacks to test security goals. Arrows connect each phase to show the workflow. — Figure 1. Model-based security analysis framework.

Context: Warehouse Robot

This white paper presents an example of a warehouse robot containing a remote operator, software architecture, plant model, and camera model (Figure 3). A detailed look at the software architecture, shown in Figure 4, reveals a planning scheduler, planning, control, and position estimator modules.

The model-based security analysis consists of the following steps (as illustrated in Figure 2):

Asset and threat identification
Security risk calculation
Countermeasure definition, implementation, and verification

Flowchart illustrating security risk management steps: Identify assets and threats, calculate security risk, and define & verify countermeasures. Each section includes questions and relevant images, such as a risk matrix and security cameras. — Figure 2. Steps of model-based security analysis.

A system diagram showing the warehouse robot system with a Control Center, Robot software architecture, and Warehouse Building. It illustrates data flow for robot control, positioning, and navigation. — Figure 3. Warehouse robot architecture model.

A detailed diagram of the warehouse task robot architecture showing Planning Scheduler, Position Estimator, and Control modules managing robot movement and tasks. — Figure 4. Warehouse robot software architecture.

Identifying Assets and Threats

An important question to ask when attempting to identify assets and threats is, “What needs protection?” In a perfect world, the answer is anything that provides value to your system. However, complexity and expenses restrict the choice to protect what is necessary, such as safety-relevant features. These features are referred to as assets, and each asset has one or more properties to protect, such as:

Availability
Integrity
Authenticity
Confidentiality
Non-repudiation
Authorization

Asset Identification: What Do You Want to Protect?

There are many methods to identify assets, such as evaluating their exposure to a user, examining their data flows, reviewing a Software Bill of Materials (SBOM), or considering their role in safety features. As a simple rule, all components that are consuming external inputs should be considered.

Within the robot’s software architecture, there are components that rely on a signal (robotPosition) from the warehouse ceiling cameras (the simulation model):

Planning scheduler
Position estimator

For the purposes of this example, this report will focus on protecting the availability, integrity, and authenticity of that signal in relation to these assets. Please note that there are other properties that should be protected for these assets, and this analysis should be completed for all assets in the system.

To ensure traceability throughout this analysis, it is important to make use of Safety Analysis Manager spreadsheets in Simulink Fault Analyzer™. To add these assets to the spreadsheet, stereotypes in System Composer™ are utilized. When the stereotype of “asset” is assigned to these subsystems, they will be automatically added to the sheet. The spreadsheet tracks the asset type, the protected properties, and any other information you would like to capture (Figure 5). Using Requirements Toolbox™, assets can also be linked to the identified threats to create a digital thread connecting the rest of the analysis. This will help us to:

Meet traceability requirements of industry standards.
Conduct an impact analysis of any changes.

A screenshot of a spreadsheet. It lists two assets: “Planning Scheduler” and “Position Estimator,” both marked as processes with checks for authenticity, integrity, and availability. — Figure 5. An example of an asset spreadsheet.

Threat Identification: What Could Go Wrong?

Now that the assets to be protected have been identified, the next step is to identify the threats presented to these assets. A common method for identifying software security threats is the STRIDE modeling framework. The desired properties of the assets are mapped directly to their respective threats, as seen in Table 1.

**Table 1**
Threat	Desired Property	Threat Definition
Spoofing	Authenticity	Pretending to be something or someone other than yourself
Tampering	Integrity	Modifying something on disk, network, memory, or elsewhere
Repudiation	Non-repudiability	Claiming that you didn’t do something or were not responsible; can be honest or fake
Information Disclosure	Confidentiality	Someone obtaining information they are not authorized to access
Denial of Service	Availability	Exhausting resources needed to provide service
Elevation of Privilege	Authorization	Allowing someone to do something they are not authorized to do

Whether you are employing STRIDE or another method, you can write a MATLAB function to automatically suggest threats from the previously identified properties of the asset. For example, the threat that maps to availability is denial of service. This is a broad terminology, and you will likely need to be more specific to determine the risk posed and the countermeasure. Threat catalogues like CAPEC™¹, ATT&CK^®2, and EMB3D^™3 can be used to obtain more specific information about what the threat may look like; in this case, it could be jamming the signal from the camera to the position estimator.

Once the specific threat is identified, the threats spreadsheet can be updated with the CAPEC entry (e.g., CAPEC-601). Like the assets sheet, the threats sheet also enables traceability and impact analysis through its links to the rest of the analysis.

Calculating Security Risk

Calculating the risk of a particular threat involves main factors. The first factor is feasibility, which refers to how easily the attack can be carried out. The second factor is impact, which considers the severity of the consequences.

Feasibility: How Difficult Is the Task?

Leveraging the Attack Potential method from ISO 18045 provides a systematic framework to estimate the feasibility of an attack based on the following set of required factors:

Expertise: What are the skills of the attacker?
Knowledge: How much insider knowledge is required?
Equipment: Which tools or hardware are necessary to execute the attack?
Elapsed time: How long does it take to identify a vulnerability and develop an exploit?
Window of opportunity: When and where can the attack be carried out?

The threats spreadsheet (Figure 6) has columns for each of the factors to be accounted for, and a customizable MATLAB formula automatically calculates feasibility. As mentioned above, the Attack Potential method is used, which sums up the standardized enumerated value for each factor.

Screenshot of a threat analysis table with risk and feasibility details. — Figure 6. Threats spreadsheet with factors and feasibility highlighted.

Impact: How Bad Is It?

Every threat has a potential impact or consequence. In this example, the impact is determined in terms of safety effects. For this, the impact assessment from an existing safety analysis (i.e., the hazard assessment) is directly leveraged. Note that this is a simplification. Normally, the impact is also determined for operational, financial, and privacy aspects.

In the hazard assessment (Figure 7), the severity of a functional failure of the position sensor ranges from S3 to S5. For simplicity, the highest of these values will be taken as the impact of the denial-of-service (DoS) threat.

A screenshot of the Robot Hazard Assessment table outlining functional failures in planning and position sensors, along with their effects, severity, occurrence, risk, and mitigation strategies. — Figure 7. Hazard assessment of a robot.

Risk Calculation and Treatment

Once feasibility and impact have been evaluated, the risk can be automatically calculated using another MATLAB formula. For this example, risk is calculated by multiplying the feasibility by the impact.

Depending on your risk tolerance, you can decide how to apply risk treatments. The risk treatment is shown in the spreadsheet (Figure 8) by denoting one of the following characteristics:

Avoid: Risk must be fully avoided (e.g., by removing functionality).
Reduce: Risk must be lowered by implementing technical countermeasures.
Share: Risk is transferred to insurance, user, third party, etc.
Retain: Risk is accepted “as is” without any further steps.
Not Applicable: Threat does not exist in this system.

Note: Both Avoid and Reduce risk treatments lead to technical requirements.

A screenshot of a spreadsheet with threats such as “DoS on Position Estimator” and “Tampering on Position Estimator,” with details on attack expertise and risk. A warning is highlighted, indicating a risk level too high for the selected status. — Figure 8. Risk treatment in threats spreadsheet.

The risk calculation and the relation between threats, assets, and other elements can be visualized as a graph, which provides insights into their contribution to the overall risk. Because the graph shows information about the importance of each relation, it can be used to prioritize work. As can be seen from Figure 9, DoS poses a larger threat than tampering and should therefore be treated first. This is because it has a higher severity level (S5) than tampering (S4).

A diagram visualizes the relationships between assets, threats, and the position estimator in a warehouse task robot architecture. Priorities are indicated for threats, with “DoS on Position Estimator” marked as priority 1 and “Tampering on Position Estimator” as priority 2. — Figure 9. Visualization of risk.

Countermeasure Definition, Implementation, and Verification

To reduce the risk of jamming the signal (DoS) from the camera to the position estimator, risk can be mitigated by either reducing the feasibility or with a countermeasure. In this case, the impact was reduced by adding an emergency brake. This measure is traceable back to the threat spreadsheet with a link in the countermeasures sheet (Figure 10). Each countermeasure leads to a security goal, which takes the form of at least one derived requirement. In this case, the requirement is that the robot will stop within one second of jamming detection, which is also linked for traceability and impact analysis.

A screenshot of a table displaying a risk assessment for various threats, including details on attack expertise, feasibility, and risk levels. An arrow points from a countermeasure labeled “Emergency brake to detect and stop spinning” to its related threat, highlighting the link between them. — Figure 10. Linking countermeasures to threats.

Consistency and Completeness Checks

At this point, this white paper has identified threats, evaluated their risks, and defined countermeasures for when the risk was unacceptably high. The next step would be the development of the countermeasure(s). Before handing off security goals, ensure the threat and risk model is valid by verifying the following:

At least one threat has been identified for each asset (notion of completeness).
No threat is unreviewed.
Countermeasures have been allocated when the risk is too high.
Requirements (e.g., security goals) have been created and linked to the countermeasure(s).
There are no broken links between threats, assets, models, and safety analysis.

Using a single function call, it is possible to validate all of this and generate a plot (Figure 11).

A bar chart titled “Threat & Risk Model Validation” displaying the number of findings across different analysis sheets. The chart uses green, orange, and red colors to indicate the status of assets, threats, countermeasures, and robot hazard assessment. — Figure 11. Threat and risk model validation.

Countermeasure Implementation

Once countermeasures have been defined, it is time to implement them in the model. In the Simulink^® model of the controller, MATLAB is used to add a function block (Figure 12), which is linked to the requirement for traceability.

A diagram illustrating the implementation of an emergency brake system with safetyLock and emergencyBrake components. The right panel shows a summary and description of the emergency brake’s function, with a highlighted link to “Emergency Brake Active.” — Figure 12. Implementation of an emergency brake with a linked requirement.

Verification and Validation

Once implemented, the next step is to model the attack and verify the functionality of the countermeasure. This can be accomplished with Simulink Fault Analyzer, which is used to model and simulate the attack. Figure 13 visualizes the settings used when modeling the attack.

A dialog box for adding a fault to a model element, detailing properties such as fault name and behavior. The fault is set to trigger at a specified simulation time, with a behavior type “Stuck-at-Ground.” — Figure 13. Fault dialog box with the trigger highlighted.

After enabling the fault and running the model, one can take a closer look at the signals using the Simulation Data Inspector (SDI) as shown in Figure 14. You can also visualize the attack responses using Navigation Toolbox™, as shown in Figure 15. These tools allow you to visually verify that the countermeasure works as intended, and this workflow can be scaled using the Simulink Test Manager framework to ensure all functionality is properly verified.

A screenshot of a graphical analysis showing a DoS attack on a robot’s position estimator. The top graph indicates when the attack is injected, while the middle graph shows when the robot stops. — Figure 14. Simulink Data Inspector showing where an attack is injected.

Figure 15. Visualization of an attack with (left) and without (right) countermeasures.

Conclusion

A model-based security analysis framework provides a workflow with built-in traceability, customizability to meet your compliance standards, and the ability to automate, ensuring consistency between the design and analysis. Accelerate verification and validation by shifting them earlier in the design process with this streamlined workflow, reducing both development time and costs. From discovering potential threats to quantifying and deciding on risks to defining and simulating the effectiveness of your countermeasures, this end-to-end approach ensures your security process is covered.

References

The MITRE Corporation. “CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™).” Accessed March 18, 2025.
The MITRE Corporation. “MITRE ATT&CK^®.” Accessed March 18, 2025.
The MITRE Corporation. “MITRE EMB3D™.” Accessed March 18, 2025.