Make formatting of FIXME and TODO consistent

Firmware running on a device is an operating system if its core function is to abstract the hardware platform and control the execution of software that uses services it provides. Otherwise it is special purpose device-specific firmware.

> FIXME make the above more specific.

> FIXME: make the above more specific.

Device drivers are generally included in the security-relevant parts of an operating system. However, the manufacturer of the operating system is only responsible for device drivers included in the product.

> FIXME add diagram(s) showing relationship to hypervisors, containers, boot managers, IAM, network interfaces, antivirus, hardware, and software.

> FIXME: add diagram(s) showing relationship to hypervisors, containers, boot managers, IAM, network interfaces, antivirus, hardware, and software.

# 2 References

**principle of least privilege:** design principle requiring that users, processes, and interfaces are granted only the minimum level of permission necessary to perform their legitimate functions, and nothing more

FIXME define "Platform"

> FIXME: define "Platform"

## 3.2 Symbols

![Figure 1: Temporary architecture diagram](media/architecture.png)

> FIXME GitLab pipeline doesn't work with mermaid

> FIXME: GitLab pipeline doesn't work with mermaid

Operating system architecture is quite varied, depending on factors such as the intended use case, the underlying platform, and the design philosophy of the developers. This overview will focus on the elements of operating system architecture that have a significant impact on the security functions and risk mitigations of an operating system.

## 5.3 Risk Mitigation Sets

> **TODO**: Connect the technical security requirements in clause 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in clause 6.

> TODO: Connect the technical security requirements in clause 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in clause 6.

# 6 Conformity Assessment

f* NUSR-2: foreseeable use is primarily a single user account for an end-user authenticating, but supports multiple user accounts for end-users

* NUSR-3: foreseeable use of the operating system is multiple user accounts for end-users

FIXME add the separate concept of users apart from accounts

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

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

**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.

> FIXME: Totals are wrong, risk factors are missing.

> 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_ |

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

Risk is determined by a combination of impact and likelihood. Each risk factor measures impact, likelihood, or a combination of the two.

TODO separate Risk Factors into those that affect impact vs likelihood

> TODO: separate Risk Factors into those that affect impact vs likelihood

TODO rewrite Risk Factors to clearly articulate Risk and Foreseeable Mitigation separately

> TODO: rewrite Risk Factors to clearly articulate Risk and Foreseeable Mitigation separately

TODO Also need to distinguish between

- device capability

- mitigations that limit it to the use case

> TODO: Also need to distinguish between

> - device capability

> - mitigations that limit it to the use case

Approach to the whole document:

- start from a (possibly too long) list of product use cases