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

Asset	Description
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	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	Description
RealmCode	Malicious or faulty code running in the Realm world, including R-EL0 and R-EL1 levels.
HostSoftware	Malicious or faulty code running in the Secure or Non-Secure world, EL0 and EL1 levels.
AppDebug	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	Description
RootCode	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.
PhysicalAccess	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)	Impact	Likelihood
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)
Critical	20–25
High	12–19
Medium	6–11
Low	2–5
Informational	1

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.

---