1.3. Threat Analysis components

In this section we identify all the possible actors involved in the Threat Model.

For each threat, we will identify the asset that is under threat, the threat agent and the threat type. Each threat will be given a risk rating that represents the impact and likelihood of that threat.

Any threat which needs to be mitigated by the RME hardware as well as by EL3 Root code is out of the scope of this Threat Model.

1.3.1. Assets

We have identified the following assets for RMM:

Table 2: RMM Assets



Sensitive Data

These include sensitive RMM and Realm data that an attacker must not be able to tamper with.
Also, RMM should protect the confidentiality of of such data.

Code Execution

This represents the requirement that Realms should only run code in R-EL1/EL0 that is
allowed by the RMM ABI. The Realm code execution cannot be hijacked by an attacker.
This also represents the requirement that RMM should protect itself from privilege escalation
and code injection by an attacker into R-EL2. The RMM execution cannot be hijacked by an
attacker through the use of the RMM ABI.


Availability of Realm world is out of scope for this Threat Model. However, RMM should be
designed in such a way that neither Realm nor RMM should significantly affect the availability
of NS Host and Secure World.

1.3.2. Threat Agents

To understand the attack surface, it is important to identify potential attackers, i.e. attack entry points. The following threat agents are in scope of this threat model.

Table 3: Threat Agents

Threat Agent



Malicious or faulty code running in the Realm world, including R-EL0 and R-EL1 levels.


Malicious or faulty code running in the Secure or Non-Secure world, EL0 and EL1 levels.


Physical adversary using debug build of RMM or access to debug sources of the system.

There is also a number of Threat Agents which are not covered by this Threat Model. These are listed in the table below.

Table 4: Threat Agents not covered by this Threat Model

Threat Agent



Malicious or faulty code running at Root Level (e.g. EL3 Firmware). Since RootCode is part of TCB
of the system, any fault in Root code is usually a critical vulnerability and not easily mitigated by
RMM. This Threat is considered out-of-scope of analysis.


Physical adversary having access to external device communication bus and to external flash
communication bus using common hardware.
An advanced physical atacker that has the capability to tamper with hardware (e.g. “rewiring” a chip
using a focused ion beam -FIB- workstation or decapsulate the chip using chemicals).

1.3.3. Threat Types

In this threat model we categorize threats using the STRIDE threat analysis technique. In this technique a threat is categorized as one or more of these types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service or Elevation of privilege.

1.3.4. Threat Risk Ratings

For each threat identified, a risk rating that ranges from informational to critical is given based on the likelihood of the threat occurring if a mitigation is not in place, and the impact of the threat (i.e. how severe the consequences could be). Table 4 explains each rating in terms of score, impact and likelihood.

Table 4: Rating and score as applied to impact and likelihood

Rating (Score)



Critical (5)

Extreme impact to entire organization if exploited.
Threat is almost certain to be exploited.
Knowledge of the threat and how to exploit it are in the public domain.

High (4)

Major impact to entire organization or single line of business if exploited
Threat is relatively easy to detect and exploit by an attacker with little skill.

Medium (3)

Noticeable impact to line of business if exploited.
A knowledgeable insider or expert attacker could exploit the threat
without much difficulty.

Low (2)

Minor damage if exploited or could be used in conjunction with other
vulnerabilities to perform a more serious attack
Exploiting the threat would require
considerable expertise and resources

Informational (1)

Poor programming practice or poor design decision that may not represent an
immediate risk on its own, but may have security implications if multiplied and/or
combined with other threats.
Threat is not likely to be exploited on its own, but may be used to
gain information for launching another attack

Aggregate risk scores are assigned to identified threats. Specifically, the impact score multiplied by the likelihood score. For example, a threat with high likelihood and low impact would have an aggregate risk score of eight (8); that is, four (4) for high likelihood multiplied by two (2) for low impact. The aggregate risk score determines the finding’s overall risk level, as shown in the following table.

Table 5: Overall risk levels and corresponding aggregate scores

Overall Risk Level

Aggregate Risk Score (Impact multiplied by Likelihood)











The likelihood and impact of a threat depends on the target environment in which RMM is running. For example, attacks that require physical access are unlikely in server environments while they are more common in Internet of Things (IoT) environments. In this threat model we only consider Server target environments.