Reorder Annex C

* Logging

* Monitoring/notifications

## C.4 Threats

## C.2 Risk factors

### C.4.1 General

The approach to listing threats is to separate them by mitigation so that they may be associated with mitigations more directly.

### C.4.2 Risk assessment methodology

Risk factor levels for each security profile are determined by reading the descriptions for each risk factor level and choosing the one that most accurately represents the highest risk for the intended purpose and reasonably foreseeable use and misuse of the product, as specified by the manufacturer.

For each threat, a formula based on the risk factor levels is used to calculate the Likelihood and Impact of the threat, on a scale of Low, Medium, and High.

For each threat, both likelihood and impact must be Low before the risk is considered sufficiently mitigated. If the calculated levels are not already Low, then mitigations must be applied until they are both Low. The mitigation sets that will accomplish this are listed in each threat description.

The risk factors by type are:

  * Likelihood: NUSR CUSR PHYS UEIN LOSS HWMD SWMD DVCS TNET FNET CONF ADMN SUPP

  * Impact: SNDS SNDT SENF

The mitigations that reduce risk by type are:

Likelihood:

MI-KEVD: Documentation for secure update before or during first use

MI-KEVA: Automatic secure update before or during first use

MI-KEVM: Documentation of mitigation of known exploitable vulnerabilities

MI-KEVT: Testing for known exploitable vulnerabilities

MI-SCAN: No easily scannable known exploitable vulnerabilities

MI-SSCA: Static source code analysis for memory errors

MI-FZ95: Runtime code coverage checking with memory access error detection

MI-IMSL: Implement in a memory-safe language

MI-BTIN: Boundary testing of inputs that may cause memory errors

MI-SCFS: Secure compilation flags

MI-MMAC: Memory access control

MI-CCON: Prevent creation of more than one user account

MI-UCON: Prevent concurrent user account usage

MI-PMSC: Prevent memory leaks through microarchitectural side channels in provided executables

MI-TRMD: Transfer risk of microarchitectural side channel data leaks to user

MI-ASLR: Address Space Layout Randomization

MI-MSAF-1: Stack exhaustion detection

MI-MSAF-2: Stack linear buffer overflow detection

MI-MSAF-3: Array bounds checking

MI-MSAF-4: Heap linear buffer overflow detection

MI-MSAF-5: Heap use-after-free access prevention

MI-MSAF-6: Heap free checking

MI-MZRO-1: Stack memory zeroing

MI-MZRO-2: Heap memory zeroing

MI-MRWX-1: Prevent writes to executable and read-only data memory

MI-MRWX-2: Prevent execution of non-kernel code memory

MI-NKAM: Prevent unintentional kernel access to userspace memory

MI-PLLC: Prevent linked list corruption

MI-MRCO: Mitigate reference counter overflow

MI-CFIN: Control flow integrity

MI-MPMT: Memory protection using memory tagging

MI-MDOC: Document transfer of risk of minimizing impact to operating environment

MI-MNET: Minimize negative impact of network transmission

MI-MAMP: Minimize negative impact of network traffic amplification

MI-ADEF: Authorization required by default to access security-relevant assets

MI-DPAH: Documentation of product assets accessible from host

MI-PDDI-1: Document how to protect access to debug/management interfaces

MI-PDDI-2: Protect or disable local software access to debug/management interfaces

MI-PDDI-3: Protect or disable network access to debug/management interfaces

MI-SCHL: Low security updates provided by operational environment

MI-SCHM: Medium security updates provided by operational environment

MI-SCHH: High security updates provided by operational environment

MI-RSET: Secure deletion via reset

MI-INST: Secure deletion via reinstallation

MI-DELE: Secure deletion via secure deletion function

MI-VULH: Vulnerability handling

Impact:

MI-CDST: Protect confidentiality of data stored on the product

MI-CDTX: Protect confidentiality of data transmitted by product

MI-DOCC: Document transfer of risk of confidentiality of data transmitted by product

MI-IDST: Protect integrity of data stored on the product

MI-DCST: Detect corruption of data stored

MI-DCTX: Detect corruption of data transmitted by the product

MI-DJST: Document and justify processed data

MI-AVNT: Availability of network services

MI-WDOG: Watchdog and self-initiated reset

MI-FDRP: Fast packet drop

MI-LMEM: Limit memory usage

MI-FAIR: Fair resource usage and prioritization

MI-DOST: Document risk transfer to operational environment for denial of service

MI-JSTY: Document and justify exposed interfaces

MI-LOGG: Logging

MI-SDRF: Secure data read from product

MI-SDTR: Secure data transfer to another product

**[TH-USDA]:** An attacker may read or modify security-relevant data without proper authorization while stored or in transmission.

**[TH-DATA]:** An attacker may read or modify data without proper authorization while being processed, stored, or transmitted by the product.

**[TH-FUNC]:** An attacker may use or modify functions of the product without proper authorization.

**[TH-TRCH]:** An attacker may access or intercept the establishment of a communication channel over a network with a trusted system without proper authorization, or masquerade as a trusted system during the establishment.

**[TH-NETA]:** An attacker may transmit or access data over the network without proper authorization.

**[TH-MASQ]:** An attacker may masquerade as the product itself to access data in remote systems without proper authorization.

**[TH-DOSE]:** An attacker may prevent the performance of the essential functions of the product by overloading system resources.

**[TH-DOSA]:** An attacker may use the unauthorized access to the product to prevent the performance of the essential functions of other devices.

**[TH-CONF]:** An attacker may read or modify configuration data of the product without proper authorization.

**[TH-UPDA]:** An attacker may cause unauthorized software updates to be installed or prevent authorized software updates.

## C.3 Assumptions

> List assumptions that are relevant to the risk analysis for these threats. Everything is hackable if you try hard enough. What kinds of threats are in and out of scope? What are you assuming is the sophistication of attack? Relate to use cases.

Assumptions can be updated to be less stringent as more use cases and mitigations are added to the standard.

### C.3.1 Proper platform

**[AS-PP]:** The platform the product runs on is trustworthy. The OS may choose to detect and/or correct hardware errors.

### C.3.2 Proper administrator

**[AS-PA]:** The product administrator is not intentionally hostile and is engaging in good faith efforts to administer the system properly.

### C.3.3 Attacker has limited physical access to product

**[AS-LP]:** An attacker will have only temporary physical access to the product.

### C.3.4 Attacker has limited resources

**[AS-LR]:** An attacker has the resources available to a small group of skilled individuals, without the backing of large corporations, nation-states, or immense wealth.

## C.4 Risk assessments of threats

> For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security levels.

> Guidance from latest PT1 draft:

>

> An analysis in terms of likelihood and magnitude of a product’s threats is required to be able to determine the product’s risks.

> NOTE 1 The present document does not require a specific methodology for a cybersecurity risk analysis as long as the cybersecurity risk estimation is based on the likelihood of occurrence and magnitude of loss or disruption of cybersecurity risks. Thus, different approaches and models such as the fishbone model, event tree analysis or fault tree models can be used within the analysis of cybersecurity risks.

> NOTE 2 A qualitative estimation of the cybersecurity risks can be performed using risk matrices that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to cybersecurity risk categories.

> NOTE 3 A quantitative estimation of the cybersecurity risks can be performed using scoring systems that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to certain values.

## C.5 Risk factors

### C.5.1 List of risk factors

### C.2.1 List of risk factors

Risk factors determine which mitigation(s) satisfy each of the technical requirements in clause 5.2. The manufacturer determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the operating system.

> FIXME: reference guidance on risk assessment when it exists.

#### C.5.1.x Number of User Accounts

#### C.2.1.x Number of User Accounts

**[RF-NUSR]:** The number of user accounts of end-users expected on the system, excluding administrator accounts.

> FIXME: add the separate concept of users apart from accounts

#### C.5.1.x User Account Concurrency

#### C.2.1.x User Account Concurrency

**[RF-CUSR]:** The number of user accounts expected to use the system concurrently, including administrator accounts if they are configurable or accessible by end-users.

* CUSR-2: foreseeable use of the operating system is multiple authenticated users simultaneously active on the operating system who are trusted not to actively attempt to compromise the system

* CUSR-3: foreseeable use of the operating system is multiple authenticated untrusted users simultaneously active on the operating system

#### C.5.1.x Sensitivity of Data Stored

#### C.2.1.x Sensitivity of Data Stored

**[RF-SNDS]:** Sensitivity of data stored, as measured by impact of loss of its integrity, confidentiality, or availability.

* SNDS-2: foreseeable use includes storing moderate amounts of sensitive data

* SNDS-3: foreseeable use includes storing extensive amounts of sensitive data by default

#### C.5.1.x Sensitivity of Data Transmitted

#### C.2.1.x Sensitivity of Data Transmitted

**[RF-SNDT]:** Sensitivity of data transmitted, as measured by impact of loss of its integrity, confidentiality, or availability.

* SNDT-2: foreseeable use includes transmission of moderate amounts of sensitive data

* SNDT-3: foreseeable use includes transmission of extensive amounts of sensitive data by default

#### C.5.1.x Sensitivity of Functions

#### C.2.1.x Sensitivity of Functions

**[RF-SENF]:** Sensitivity of functions of device, as measured by impact of loss of its integrity, confidentiality, or availability.

* SENF-2: foreseeable use may provide arbitrary sensitive functions

* SENF-3: foreseeable use provides sensitive functions by default

#### C.5.1.x Physical Access by Threat Actors to the Device

#### C.2.1.x Physical Access by Threat Actors to the Device

**[RF-PHYS]:** Exposure of the device to physical access by users.

* PHYS-1: foreseeable use includes incidental exposure to untrusted users

* PHYS-2: foreseeable use is primarily by untrusted users, e.g. the general public

#### C.5.1.x Processing of Untrusted External Inputs

#### C.2.1.x Processing of Untrusted External Inputs

**[RF-UEIN]:** Exposure to untrusted external inputs that are processed by the platform.

* UEIN-1: may incidentally process untrusted external inputs

* UEIN-2: used primarily to process untrusted external inputs

#### C.5.1.x Probability of Loss of the Device

#### C.2.1.x Probability of Loss of the Device

**[RF-LOSS]:** Likelihood of loss or theft of the device, allowing threat actors unlimited physical access to the device.

* LOSS-2: foreseeable use is in a device with moderate loss likelihood

* LOSS-3: foreseeable use is in a device with a high loss likelihood, such as devices which are common targets of theft such as mobile phones

#### C.5.1.x Hardware Modifiability by End Users

#### C.2.1.x Hardware Modifiability by End Users

**[RF-HWMD]:** Likelihood that the hardware of the platform will be changed from its secure-by-default state.

* HWMD-1: foreseeable use includes hardware modifications by skilled administrators

* HWMD-2: foreseeable use includes hardware modification by unskilled users

#### C.5.1.x Software Modifiability by End Users

#### C.2.1.x Software Modifiability by End Users

**[RF-SWMD]:** Likelihood that the software on the platform (including firmware) will be changed from its secure-by-default state.

* SWMD-2: foreseeable use allows for the installation of arbitrary software or for substantial modification of pre-installed software

* SWMD-3: foreseeable use actively encourages and facilitates the installation of arbitrary software

#### C.5.1.x Untrusted Peripheral Devices

#### C.2.1.x Untrusted Peripheral Devices

**[RF-DVCS]:** Likelihood of unstrusted peripheral devices being attached to the platform via a connection that is a plausible attack vector, such as by USB or PCI bus.

* DVCS-1: foreseeable use includes only trusted and safe peripheral devices

* DVCS-2: foreseeable use allows for arbitrary peripheral device attachment

#### C.5.1.x Access to a Public Network

#### C.2.1.x Access to a Public Network

**[RF-TNET]:** Likelihood that the device will initiate connections to public networks.

* TNET-1: foreseeable use allows internet access for only highly restricted functions, such as retrieving security updates

* TNET-2: foreseeable use allows for arbitrary access to a public network, such as by browsing the web

#### C.5.1.x Accessed From Untrusted Networks Including a Public Network

#### C.2.1.x Accessed From Untrusted Networks Including a Public Network

**[RF-FNET]:** Likelihood that the device will be exposed to incoming traffic from public networks.

* FNET-2: foreseeable use includes being connected directly to the open internet

* FNET-3: foreseeable use includes being a firewall connected directly to the open internet

#### C.5.1.x Configurability

#### C.2.1.x Configurability

**[RF-CONF]:** Degree of security-relevant configuration change of the operating system necessary for use.

* CONF-1: foreseeable use involves operating system configuration changes only by skilled administrators

* CONF-2: foreseeable use of the operating system includes configuration changes by end-users

#### C.5.1.x Administration

#### C.2.1.x Administration

**[RF-ADMN]:** Availability and skill of administrators.

* ADMN-1: foreseeable use always has skilled administrators available on call

* ADMN-2: foreseeable use may involve unskilled administrators

#### C.5.1.x Support and Foreseeable Updates

#### C.2.1.x Support and Foreseeable Updates

**[RF-SUPP]:** How long the product is expected to be in use, and whether the product is expected to be updated throughout its life cycle.

* SUPP-2: foreseeable use includes the installation of updates by end-users with access to the operating system

* SUPP-3: foreseeable use necessitates that the manufacturor provide frequent, automatic, and/or time-sensitive updates to the product, and may reasonably include a requirement for over-the-air updates.

### C.5.2 Mapping of Use Cases to Risk Factors

## C.3 Assumptions

Assumptions can be updated to be less stringent as more use cases and mitigations are added to the standard.

### C.3.1 Proper platform

**[AS-PP]:** The platform the product runs on is trustworthy. The OS may choose to detect and/or correct hardware errors.

### C.3.2 Proper administrator

**[AS-PA]:** The product administrator is not intentionally hostile and is engaging in good faith efforts to administer the system properly.

### C.3.3 Attacker has limited physical access to product

**[AS-LP]:** An attacker will have only temporary physical access to the product.

### C.3.4 Attacker has limited resources

**[AS-LR]:** An attacker has the resources available to a small group of skilled individuals, without the backing of large corporations, nation-states, or immense wealth.

## C.4 Risk assessments of threats

### C.4.1 General

The approach to listing threats is to separate them by mitigation so that they may be associated with mitigations more directly.

### C.4.2 Risk assessment methodology

Risk factor levels for each security profile are determined by reading the descriptions for each risk factor level and choosing the one that most accurately represents the highest risk for the intended purpose and reasonably foreseeable use and misuse of the product, as specified by the manufacturer.

For each threat, a formula based on the risk factor levels is used to calculate the Likelihood and Impact of the threat, on a scale of Low, Medium, and High.

For each threat, both likelihood and impact must be Low before the risk is considered sufficiently mitigated. If the calculated levels are not already Low, then mitigations must be applied until they are both Low. The mitigation sets that will accomplish this are listed in each threat description.

The risk factors by type are:

  * Likelihood: NUSR CUSR PHYS UEIN LOSS HWMD SWMD DVCS TNET FNET CONF ADMN SUPP

  * Impact: SNDS SNDT SENF

The mitigations that reduce risk by type are:

Likelihood:

MI-KEVD: Documentation for secure update before or during first use

MI-KEVA: Automatic secure update before or during first use

MI-KEVM: Documentation of mitigation of known exploitable vulnerabilities

MI-KEVT: Testing for known exploitable vulnerabilities

MI-SCAN: No easily scannable known exploitable vulnerabilities

MI-SSCA: Static source code analysis for memory errors

MI-FZ95: Runtime code coverage checking with memory access error detection

MI-IMSL: Implement in a memory-safe language

MI-BTIN: Boundary testing of inputs that may cause memory errors

MI-SCFS: Secure compilation flags

MI-MMAC: Memory access control

MI-CCON: Prevent creation of more than one user account

MI-UCON: Prevent concurrent user account usage

MI-PMSC: Prevent memory leaks through microarchitectural side channels in provided executables

MI-TRMD: Transfer risk of microarchitectural side channel data leaks to user

MI-ASLR: Address Space Layout Randomization

MI-MSAF-1: Stack exhaustion detection

MI-MSAF-2: Stack linear buffer overflow detection

MI-MSAF-3: Array bounds checking

MI-MSAF-4: Heap linear buffer overflow detection

MI-MSAF-5: Heap use-after-free access prevention

MI-MSAF-6: Heap free checking

MI-MZRO-1: Stack memory zeroing

MI-MZRO-2: Heap memory zeroing

MI-MRWX-1: Prevent writes to executable and read-only data memory

MI-MRWX-2: Prevent execution of non-kernel code memory

MI-NKAM: Prevent unintentional kernel access to userspace memory

MI-PLLC: Prevent linked list corruption

MI-MRCO: Mitigate reference counter overflow

MI-CFIN: Control flow integrity

MI-MPMT: Memory protection using memory tagging

MI-MDOC: Document transfer of risk of minimizing impact to operating environment

MI-MNET: Minimize negative impact of network transmission

MI-MAMP: Minimize negative impact of network traffic amplification

MI-ADEF: Authorization required by default to access security-relevant assets

MI-DPAH: Documentation of product assets accessible from host

MI-PDDI-1: Document how to protect access to debug/management interfaces

MI-PDDI-2: Protect or disable local software access to debug/management interfaces

MI-PDDI-3: Protect or disable network access to debug/management interfaces

MI-SCHL: Low security updates provided by operational environment

MI-SCHM: Medium security updates provided by operational environment

MI-SCHH: High security updates provided by operational environment

MI-RSET: Secure deletion via reset

MI-INST: Secure deletion via reinstallation

MI-DELE: Secure deletion via secure deletion function

MI-VULH: Vulnerability handling

Impact:

MI-CDST: Protect confidentiality of data stored on the product

MI-CDTX: Protect confidentiality of data transmitted by product

MI-DOCC: Document transfer of risk of confidentiality of data transmitted by product

MI-IDST: Protect integrity of data stored on the product

MI-DCST: Detect corruption of data stored

MI-DCTX: Detect corruption of data transmitted by the product

MI-DJST: Document and justify processed data

MI-AVNT: Availability of network services

MI-WDOG: Watchdog and self-initiated reset

MI-FDRP: Fast packet drop

MI-LMEM: Limit memory usage

MI-FAIR: Fair resource usage and prioritization

MI-DOST: Document risk transfer to operational environment for denial of service

MI-JSTY: Document and justify exposed interfaces

MI-LOGG: Logging

MI-SDRF: Secure data read from product

MI-SDTR: Secure data transfer to another product

**[TH-USDA]:** An attacker may read or modify security-relevant data without proper authorization while stored or in transmission.

**[TH-DATA]:** An attacker may read or modify data without proper authorization while being processed, stored, or transmitted by the product.

**[TH-FUNC]:** An attacker may use or modify functions of the product without proper authorization.

**[TH-TRCH]:** An attacker may access or intercept the establishment of a communication channel over a network with a trusted system without proper authorization, or masquerade as a trusted system during the establishment.

**[TH-NETA]:** An attacker may transmit or access data over the network without proper authorization.

**[TH-MASQ]:** An attacker may masquerade as the product itself to access data in remote systems without proper authorization.

**[TH-DOSE]:** An attacker may prevent the performance of the essential functions of the product by overloading system resources.

**[TH-DOSA]:** An attacker may use the unauthorized access to the product to prevent the performance of the essential functions of other devices.

**[TH-CONF]:** An attacker may read or modify configuration data of the product without proper authorization.

**[TH-UPDA]:** An attacker may cause unauthorized software updates to be installed or prevent authorized software updates.

## C.5 Mapping of Use Cases to Risk Factors

**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in Annex C.6 Table 1. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.

**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in Annex C.7.3 Table 1. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.

> FIXME: Need to update with current set of risk factors and fix the totals.

| Risk Factor  | NUSR   | CUSR   | DATA   | SNDS   | PHYS   | LOSS   | HWMD   | SWMD   | DVCS   | TNET   | FNET   | CONF   | _TOTAL_   |

|------------|------|------|------|------|------|------|------|------|------|------|------|------|---------|

|--------------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|-----------|

| **Use Case** | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | --------- |

| **UC-LR**    | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 0         |

| **UC-IoT-1** | 0      | 0      | 0      | 0      | 1      | 0      | 0      | 0      | 0      | 0      | 0      | 0      | 1         |