Commit 061590ba authored by Valerie Aurora (Bow Shock)'s avatar Valerie Aurora (Bow Shock)
Browse files

Reorganize use cases and security levels to be their own sections

parent 83d5e57b
Loading
Loading
Loading
Loading
+16 −18
Original line number Diff line number Diff line
@@ -282,14 +282,12 @@ _Explain the overall architecture and relationship among the parts of the produc

<mark> FIXME write an operating systems overview and make some diagrams </mark>

## 4.3 Use cases and security levels
## 4.3 Use cases

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

## 4.3.1 Use cases

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.

<mark> FIXME are these the right division of use cases into security levels? </mark>
@@ -409,16 +407,7 @@ Very high security level:

<mark> FIXME more use cases? </mark>

### 4.3.2 Security levels

_This will become a table of use cases by security level._

1. Low
2. Medium
3. High
4. Very high

### 4.3.3 Discussion
**Discussion**

A few risk factors extracted from the use cases:

@@ -436,7 +425,16 @@ We may be able to use these risk factors to calculate a recommended
security level for special purpose operating systems not covered by
use cases.

## 4.4 Essential functions
### 4.4 Security levels

_This will become a table of use cases by security level._

1. Low
2. Medium
3. High
4. Very high

## 4.5 Essential functions

_List the essential functions of the product, including:_

@@ -470,7 +468,7 @@ An operating system may provide, depending on the hardware available and its con

<mark> FIXME need update/monitoring/etc. </mark>

## 4.5 Operational Environment
## 4.6 Operational Environment

_Describe the expected operating environment given the exclusions in Section 4.2. This includes:_

@@ -488,7 +486,7 @@ _The technical requirements of the present document apply under the environmenta

<mark> FIXME not sure how to describe an operational environment for all operating systems! </mark>

## 4.6 Users
## 4.7 Users

_Describe the classes of users for this product, as differentiated by sophistication in understanding and taking responsibility for security risks. More sophisticated users can be expected to follow more instructions and cope with higher levels of unmitigated risks._

@@ -500,7 +498,7 @@ _Describe the classes of users for this product, as differentiated by sophistica

<mark> FIXME list more kinds of users? </mark>

## 4.7 Risk distribution
## 4.8 Risk distribution

_Describe what risks are delegated to sub-components, as well as what risk management features this product offers to things integrating it._

@@ -521,7 +519,7 @@ The operating system often provides many security functions to other components
* Logging and monitoring mechanisms
* Secure deletion and data transfer

## 4.8 Support period
## 4.9 Support period

_Describe the expected support period and its impact on security risks. Generally the support period should be at least 5 years, shorter or longer according to the expected period of use. See Article 13.8 and Recitals 59 - 62 of the CRA for more information._