@@ -592,19 +592,25 @@ Note: "account" refers to a user in the operating systems sense: a unique system
#### 4.5.1.1 Number of Users
**[RF-NUSR]:**Manufacturers of operating systems which are intended to store personal data, including user login data, shall account for the risk to such data in the risk calculation and ensure that appropriate protections are available. System-level users (such as root) do not count towards this risk.
**[RF-NUSR]:**The greater the number of users capable of using an operating system, the greater the risk to each user's assets stored or processed by that operating system.
* NUSR-0: the operating system is designed not to allow end-users to authenticate
* NUSR-1: the operating system is designed to only allow one end-user to authenticate; to switch users, the user must factory reset the device FIXME is this correct?
* NUSR-2: the operating system is designed to allow for more than one end-user account
Recommendation: Therefore, manufacturers of operating systems which are intended to store personal data, including user login data, shall account for the risk to such data in the risk calculation and ensure that appropriate protections are available. System-level users (such as root) do not count towards this risk.
* NUSR-0: the operating system does not allow end-users to authenticate.
* NUSR-1: the operating system allows only one end-user to authenticate; to switch users, the user must reset the device.
* NUSR-2: the operating system's forseeable use is a single user device.
* NUSR-3: the operating system is designed for a high number of users.
#### 4.5.1.2 User Concurrency
**[RF-CUSR]:** Manufacturers of operating systems which are intended to support end-user accounts, either concurrently or sequentially, shall account for the increased risk to per-user data from other users and ensure that appropriate protections are available. System-level users (such as root) count towards this if they are configurable or accessible by end-users.
**[RF-CUSR]:** The greater the number of concurrent users active on an operating system, the greater the risk to each user's assets stored or processed by that operating system.
Recommendation: Therefore, manufacturers of operating systems which are intended to support concurrent use by multiple end-users accounts shall account for the increased risk to per-user data from other users, and ensure that appropriate protections are available. System-level users (such as root) count towards this if they are configurable or accessible by end-users.
* CUSR-0: the operating system is designed not to allow end-users to authenticate
* CUSR-1: the operating system is designed to only allow one end-user to authenticate concurrently; to switch users, the authenticated user must logout.
* CUSR-2: the operating system is designed to allow for more than one end-user account, and end-user accounts may be simultaneously active on the device.
* CUSR-0: the operating system does not allow end-users to authenticate
* CUSR-1: the operating system only allows one end-user to authenticate concurrently; to switch users, the authenticated user must logout.
* CUSR-2: the operating system's forseeable use allows for more than one end-user account, and end-user accounts may be simultaneously active on the device.
* CUSR-3: the operating system is designed for highly concurrent use.
#### 4.5.1.3 Data Storage
@@ -2029,6 +2035,42 @@ FIXME Do we have any assumptions that result in no difference in risk between di
# Annex D (informative): Risk evaluation guidance
## D.0 Explanation of Risk Modeling Approach
**Aeva's Notes on Risk Model**
for any use case,
identify and document
- the forseeable uses
- modulo each risk factor
this should result in a predictable set of mitigations
- i.e. preventative measures
risk = impact & likelihood
#TODO separate Risk Factors into those that affect impact vs likelihood
#TODO rewrite Risk Factors to clearly articulate Risk and Forseeable Mitigation separately
#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
- articulate risks that emerge from forseeable (mis)uses of products
- map each risk to each use case
- for each use case, sum the risks into an aggregated risk score
- articulate mitigations that protect against forseeable risks
- map each risk to one or more mitigations that protect against it
- map each use case to the relevant set of mitigations (by linking
through the risk mapping, but hiding the risks in the final mapping)
- verify that there are more mitigations required for use cases that
had a higher aggregated risk score
- verify that the risk score of each use cases is proximate to other
similarly-risky forseeable use cases, even in different product
categories.
## D.1 Mapping of risks to requirements
> Table mapping the identified risks to requirements
