Commit 7f826094 authored by Aeva Black's avatar Aeva Black Committed by Valerie Aurora
Browse files

Reformat use-case section and add a table

This commit reformats the Use Case section to:

* define classes of Use Case Risk Factors
* demonstrate several common use cases
* add a table mapping common use cases to forseeable risks

This is still a draft; the table is incomplete but sufficiently demonstrative.
parent df4dd271
Loading
Loading
Loading
Loading
+161 −59
Original line number Diff line number Diff line
@@ -360,66 +360,168 @@ Yes, the statements above somewhat contradict what Wikipedia is saying.



## 4.4 Use cases
## 4.3 Use Cases

For each operating system placed on the market, the manufacturer shall develop a threat model and risk profile based on the forseeable use of the operating system. The risk profile is derived from the forseeable use of the product. The following risk factors shall be taken into account when developing the risk profile.

> _Note: "account" refers to a user in the operating systems sense: a unique system identity associated with certain authorization and permissions. "User" refers to an entity that uses the device for some purpose. Users may have many accounts and accounts may have many users._

### 4.3.1 Use Case Risk Factors

#### 4.3.1.1 Number of Users
**[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.
* 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 device must be reset
* NUSR-2: the operating system is designed to allow for more than one end-user account

#### 4.3.1.2 User Concurrency
**[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.
* 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; to switch users,t he device must be reset.
* 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.

#### 4.3.1.3 Sensitive or Artibrary Data Storage
**[DATA]**: Manufacturers of operating systems may implement measures to prevent the on-device storage of user data, and shall document this and implement appropriate steps to ensure that no user data is stored on the device. Manufacturers may also enable the storage of specific types of data or generally of any user-specified data, and shall document the measures available for the protection of such data.
* DATA-0: the operating system is effectively unable to store per-user data in its forseeable use
* DATA-1: the operating system is designed only to store limited data types
* DATA-2: the operating system is designed to store arbitrary data

#### 4.3.1.4 Physical Access by Threat Actors to the Device
**[PHYS]**: Manufacturers of operating systems may implement protective measures, such as preventing peripheral device driver loading or relying on hardware capabilities such as tamper-evident mechanisms, to mitigate physical access based threats to the device.
* PHYS-0: only used in environments with authorized users **[
* PHYS-1: may be incidentally exposed to untrusted users
* PHYS-2: used primarily by untrusted users, e.g. the general public

#### 4.3.1.5 Probability of Loss of the Device
**[LOSS]**: likelihood of loss or theft should be accounted for in the risk calculation, particularly for devices that store sensitive personal data.
* LOSS-0: forseeable use of the operating system is limited to stationary devices or devices with other loss-prevention mechanisms
* LOSS-1: forseeable use of the operating system is in a device with only incidental loss likelyhood
* LOSS-2: forseeable use of the operating system is in a device with a high loss likelyhood, such as devices which are common targets of theft such as mobile phones

#### 4.3.1.6 Hardware Modifiabiliy by End Users
**[HWMD]**: Manufacturers of operating systems shall account for forseeable risks from hardware modifications within the intended use of the product. 
* HWMD-0: forseeable use of the operating system is limited to devices with hardware that is not modifiable by end-users
* HWMD-1: forseeable use of the operating system includes hardware modifications by skilled or trusted users, such as corporate IT support staff
* HWMD-2: forseeable use of the operating system includes hardware modification by unskilled users, such as in a personal computer

#### 4.3.1.7 Software Modifiability by End Users
**[SWMD]**: Manufacturers of operating systems which are designed to allow end-users to install or substantially modify the software shall account for the risks from arbitrary software execution.
* SWMD-0: forseeable use lacks any reasonable means for end-users to install or modify the software
* SWMD-1: forseeable use only allows the installation of trusted and verified software
* SWMD-2: forseeable use allows for the installation of arbitrary software or for substantial modification of pre-installed software

#### 4.3.1.8 Untrusted Peripheral Devices
**[DVCS]**: Manufacturers of operating systems which are intended for devices that support attached peripheral devices, such as those utilizing USB or PCI conenctions, shall account for the risk posed by untrusted or compromised peripheral devices and implement appropriate safeguards.
* DVCS-0: forseeable use has no accessible peripheral ports
* DVCS-1: forseeable use includes only trusted and safe peripheral devices
* DVCS-2: forseeable use allows for arbitrary peripheral device attachment

#### 4.3.1.9 Access To The Internet
**[TNET]**: Manufacturers of operating systems designed to provide end-users with access to the internet shall implement appropriate safeguards based on the nature of internet access and forseeable use of the operating system.
* TNET-0: forseeable use has no mechanism to reasonably connect to the internet
* TNET-1: forseeable use allows internet access for only highly restricted functions, such as retrieving security updates
* TNET-2: forseeable use allows for arbitrary access to the internet, such as by browsing the web

#### 4.3.1.10 Accessed From Untrusted Networks Including The Internet
**[FNET]**: Manufacturers of operating systems designed to be connected to directly from the internet, rather than placed behind NAT or a firewall, shall implement appropriate safeguards to mitigate risks.
* FNET-0: forseeable use is limited to trusted and private networks.
* FNET-1: forseeable use includes untrusted local networks but not the open internet.
* FNET-1: forseeable use includes being connected directly to the open internet.

#### 4.3.1.11 Configurability
**[CONF]**: Manufacturers of operating systems which are intended to be configurable by end users shall provide secure-by-default configurations and document all available configuration options. Such documentation shall detail any effects on safety and security that such configuration changes may cause. 
* CONF-0: forseeable use of the operating system prevents or is incapable of storing configuration changes.
* CONF-1: forseeable use allows operating system configuration changes only by skilled or trusted users, such as corporate IT support staff.
* CONF-2: forseeable use of the operating system includes configuration changes by end-users.

### 4.3.2 Example Use Cases

_The following use cases are provided as illustrative examples of applying the risk profiles above to developing a threat model. This is not intended to be an exhaustive or complete list of all possible use cases._


* UC-IoT-1 A non-internet-connected device such as a bluetooth speaker
  * does not store any user-specific data
  * has no means to connect directly to the internet
  * not intended to support hardware, software, or operating system changes

* UC-IoT-2 An internet-enabled power switch
  * connects to a central service, operated by the device manufacturer, for remote data processing
  * stores account information to authenticate to WiFi and to cloud service provider
  * has a minimalistic interface, such as a single button for pairing and a reset button
  * does not have accessible I/O ports

* UC-IoT-3 An internet-connected "smart home" device, such as a thermostat, fridge, or alarm system
  * connects to a central service, operated by the device manufacturer, for remote data process
  * stores account information to authenticate to WiFi and to cloud service provider
  * does not support arbitrary file storage or end-user operating system configuration changes
  * does not have accessible I/O ports
  * may display personalized information, such as location-specific weather forecast
  * serviced by trained professionals who do not modify software or hardware outside of manufacturer specifications

* UC-OT-1 A consumer-grade home wireless router
  * stores account information for authentication with ISP
  * not intended for end-user hardware or software modification
  * is exposed to the open internet

* UC-OT-2 A business-grade remote door locking system
  * does not store any user data
  * not intended for hardware or software modification
  * is not exposed to the open internet, and is only connected to trusted networks
  * only serviced by professionals
  * does not have accessible I/O ports
  * hardware likely contains tamper-evident signals which operating system can rely on

* UC-MOB-1 A personal smart phone
  * stores highly sensitive personal information
  * size and cost make it a common target of theft
  * device usage is not limited to trusted locations and loss is forseeable
  * hardware and operating system configuration not intended for modification by users
  * end-users frequently install software of uncertain provenance
  * device frequently connects to untrusted networks

* UC-WE-1 A wearable health tracker, such as a smart watch
  * stores information about a single user only
  * stored information may be highly sensitive, and is likely to be strictly structured (not arbitrary files)
  * does not have accessible I/O ports and is not user-modifiable
  * connects to a central service, operated by the device manufacturer, for remote data processing
  * connections are proxied by a trusted device, such as a mobile phone
  * is not exposed to the internet

* UC-PC-1 A personal computer in a fixed and generally safe location
  * hardware, software and operating system may be configured and modified by the end-user
  * the user may not be either highly skilled or an authorized representative of the manufacturer
  * forseeably connects to the internet and to low-trust local networks, but is not reachable from the open internet
  * stores personal information and arbitrary files

* UC-PC-2 A personal laptop
  * hardware, software and operating system may be configured and modified by the end-user
  * device is a forseeable target of theft and tampering by untrusted 3rd parties
  * stores personal information and arbitrary files
  * unrestricted connection to the internet
  * is frequently connected to untrusted networks
  * hardware likely contains tamper-evident indicators and secure elements for cryptographic storage

* UC-PC-3 An enterprise server in a datacenter
  * installed in a monitored and secured facility
  * serviced by trained professionals who may modify both software and hardware
  * connected to the internet with external mitigations, such as enterprise-grade firewalls
  * connects to trusted local networks
  * hardware likely contains tamper-evident indicators and secure elements for cryptographic storage


| Use Case | NUSR | CUSR | DATA | PHYS | LOSS | HWMD | SWMD | DVCS | TNET | FNET | CONF | _TOTAL_ |
|--|--|--|--|--|--|--|--|--|--|--|--|--|
|UC-IoT-1|--|--|--|--|--|--|--|--|--|--|--|
|UC-IoT-2|--|--|--|--|--|--|--|--|--|--|--|
|UC-IoT-3|--|--|--|--|--|--|--|--|--|--|--|
|UC-OT-1|--|--|--|--|--|--|--|--|--|--|--|
|UC-OT-2|--|--|--|--|--|--|--|--|--|--|--|
|UC-MOB-1|--|--|--|--|--|--|--|--|--|--|--|
|UC-WE-1|--|--|--|--|--|--|--|--|--|--|--|
|UC-PC-1|--|--|--|--|--|--|--|--|--|--|--|
|UC-PC-2|--|--|--|--|--|--|--|--|--|--|--|
|UC-PC-3| 2 | 2 | 2 | 0 | 0 | 1 | 1 | 1 | 2 | 0 | 1 | 12 |

> Create a list of representative use cases, each one representing a different threat profile. If the threat profile is the same for two use cases, then it is basically the same use case for the purposes of the present document. Use cases should include both intended and reasonably foreseeable use/misuse. Use cases don't include industrial operations, automotive, transport, marine, airplane, medical, military, national security, etc.

> When you have many use cases, group them into 3 - 5 levels of risk. These will probably be your security levels. Later you will split this section into use cases and security levels.

Note: "account" refers to a user in the operating systems sense: a unique system identity associated with certain authorization and permissions. "User" refers to an entity that uses the device for some purpose. Users may have many accounts and accounts may have many users.


For each operating system placed on the market, the manufacturer shall develop a threat model and risk profile of the forseeable use of the operating system, and shall consider the interplay between:
- complexity of forseeable use
- likelihood of an incident, given the forseeable use
- impact of an incident, given the forseeable use

These risks are grouped into risk categories and assigned unique identifiers below.

* Number of Users
  * **Rationale**: the storage of personal data on device should be accounted for in the risk calculation
  * **Rationale**: the capability to support multiple user accounts significantly increases product complexity and threat surface
  * **[USR-L-0]** no user data stored on device
  * **[USR-L-1]** single user
  * **[USR-L-2]** multiple users

  * **[USR-L-1-RQ-1]** An operating system which is intended for use cases that allow storage of personal information shall implement appropriate cryptographic libraries to allow the protection of the personal information according to the requirements of the forseeable use. 
  * **[USR-L-2-RQ-1]** An operating system which is supports multiple users shall implement and document appropriate safeguards to protect each user's personal information according to the requirements of the forseeable use.

* Location
  * **Rationale**: likelihood of physical access by threat actors should be accounted for in the risk calculation
  * **Rationale**: likelihood of loss or theft should be accounted for in the risk calculation, particularly for devices that store personal data
  * **[LOC-L-1]** designed for use in private locations (e.g., home or office)
  * **[LOC-L-2]** designed for use outside of private locations
  * **[LOC-L-2-RQ-1]** operating systems intended for use in devices that have a forseeable likelihood of theft, such as mobile phones, shall include appropriate measures to prevent access to personal information by unauthorized and unauthenticated users, including the ability to remotely erase personal information from the device under appropriate circumstances.

* Hardware Modifiability
  * **Rationale**: operating system complexity increases proportionally with complexity of supported hardware configurations
  * **Rationale**: peripheral-based compromises shall be accounted for if the connectivity of third-party or end-user-supplied hardware is forseeable
  * **[HWM-L-0]** relies on hardware which prevents user modifiability or connection of peripheral devices
  * **[HWM-L-1]** relies on hardware which prevents user modifiability but which allows peripheral use
  * **[HWM-L-2]** relies on hardware designed for user modifiability

* Software Modifiability
  * **[SW-L-0]** prevents or does not support 
  * **[SW-L-1]** allows installation only of trusted applications 
  * **[SW-L-2]** allows installation of applications by end-users

* Internet Access
  * **[IAC-L-1]** limits access TO the internet (no web browser)
  * **[IAC-L-2]** does not limit access TO the internet (can browse the web)
  * **[IAC-L-3]** not intended for direct access FROM the internet
  * **[IAC-L-4]** intended for direct access FROM the internet

* Configurability
  * **[CNF-L-1]** no end-user configurability
  * **[CNF-L-2]** allows end-users to modify pre-boot, boot, or post-boot configuration


The following use-cases are provided as illustrative examples of applying the risk profiles above to developing a threat model. This is not intended to be an exhaustive or complete list of all possible use cases.

* Simple Home Automation Device
* 

<mark> FIXME are these the right division of use cases into security levels? </mark>