Move notes out of the standard body

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

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

**Val's notes on risk model, ignore**

The fundamental types of attack of an OS are:

* Local threats: Running code on the platform of the OS that results in unauthorized access to assets

* Remote threats: Unauthorized read/write of data transmitted in/out of the OS

* Physical threats: Physical tampering of platform

* Denial of service: Deny access to assets by triggering specific code paths in OS

We need to reframe the risk factors in terms of things that affect the likelihood and impact of the risk that a technical requirement is mitigating.

What affects (1) the likelihood, (2) the impact of each of these types of attack?

* Local threats

  * Likelihood:

	* User accounts can be created by untrusted users

	* Writable storage

	* Accepts connections from a public network

    * Initiates connections to a public network

	* Web browsing

	* Installing software

	* Installing hardware

	* Plugging in peripherals

	* Configurability

    * Physical access to device by untrusted users

  * Impact:

    * Type of data stored

    * Sensitivity of data stored

	* Sensitivity of functions

	* Number of users affected

* Remote threats

  * Likelihood:

    * Accepts connections

	* Makes connections

	* RDPS

	* Web browsing

  * Impact:

    * Sensitivity of data transmitted

* Physical threats

  * Likelihood:

    * Physical access to device by untrusted users

  * Impact:

    * Type of data stored

    * Sensitivity of data stored

	* Sensitivity of functions

	* Number of users affected

* Denial of service

  * Likelihood:

    * Combination of local and remote likelihood factors

  * Impact:

    * Type of data stored

    * Sensitivity of data stored

	* Sensitivity of functions

	* Number of users affected

The major risks for operating systems depend on:

* Likelihood of attacker running code on the same platform as the OS

  * Platform includes hypervisor/container host

  * Is platform is shared with hostile users?

  * What software is installed?

  * Web browser?

  * Plug in peripherals which may load drivers or contain software

  * Add hardware that does the same

  * Install drivers/modify kernel

* Likelihood of attacker breaking the isolation between its code and the OS or its users' assets

* Impact of data leak

* Impact of loss of data integrity

## D.1 Mapping of risks to requirements

> Table mapping the identified risks to requirements

> Describe how to treat any residual risks, for example by documenting them or informing the user.

# Annex E: Notes

> **NOTE: This clause is a temporary storage place for notes, will be deleted.

> FIXME include the relation graphic between verticals in the architecture overview to explain the outside relationship.

> FIXME: Ensure the following cases present in most x86 computers are not lost, assign them to the scope of a vertical (may be ours, may be another vertical).

Special case UEFI updates triggered by the operating system: The update mechanism as provided by the firmware (UEFI capsule) is considered to be in the scope of the boot manager vertical, as is the cryptographic verification of such updates.

Special case Windows drivers delivered as part of UEFI and retrieved by Windows from UEFI during Windows installation (usually hardware enablement like storage and network drivers). FIXME: Look up the name of that mechanism.

Special case of Windows using calls into UEFI runtime services if no native Windows driver for a given peripheral (may even be the graphics card) exists. Does that make this specific UEFI driver part of the operating system?

Special case of System Management Mode (SMM) running in the background with privileges higher than the OS kernel and higher than the hypervisor (if any) and emulating hardware and/or monitoring CPU temperature, possibly forcing shutdown to prevent overheating.

Special case of verified/measured boot partially implemented outside the operating system and outside the CPU, e.g. delegated to the Intel CSME (separate x86/ARC CPU with JTAG access to the main CPU).

Special case configuration files? Not code in most cases, but substantial impact on the security configuration of the operating system.

### NOTES

Could requirements be tested by checking for the configuration options? Or do we want to give some instructions to the manufacturer on how to tell what settings or features will satisfy the requirements?

https://kspp.github.io/Recommended_Settings

Technical requirements notes/sources:

Guidance on tools (see English translation in annex):

https://cyber.gouv.fr/sites/default/files/2022-10/anssi-cc-note-26v1.0-methodologie-analyse-de-code_v0.3-fr%5B1%5D.pdf

From BSI tests for Windows:

https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP2/SiSyPHuS_AP2_node.html

https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/SiSyPHuS_node.html

https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP5/SiSyPHuS_AP5.html

https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP10/SiSyPHuS_AP10.html

From NIAP PP for OS:

* Cryptographic support

  * Cryptographic key generation

  * Cryptographic key establishment

  * Cryptographic key destruction

  * Encryption/decryption

  * Cryptographic hashing/signing/authentication

  * Random data generation

  * Secure encrypted data storage

* User data protection

  * Access controls

  * VPN

* Security management

  * Management of security functions

  * Minimum security functions provided by user type

* Protection of security relevant assets (?)

  * Access controls to system data/assets

  * Address space layout randomization

  * Limitation of Bluetooth Profile Support

  * Software Restriction Policies

  * Stack buffer overflow protection

  * Boot integrity

  * Trusted update for OS

  * Trusted update for applications and other components

  * Read-only executable memory

* Audit data generation

  * Logging with timestamps

* Identification and authorization

  * Prevent brute force

  * Multifactor auth

  * Certificate validation

  * Certificate authentication

* Trusted paths/channels

  * Allows communication via secure channel (TLS etc.)

From BSI Operating Systems Protection Profile:

* Audit

  * Audit data generation

  * Audit review

  * Audit review restriction

  * Protected audit data storage

  * Notification of possible audit data loss

  * Prevention of possible audit data loss

* Cryptographic services

  * Cryptographic key generation

  * Cryptographic key distribution

  * Cryptographic key destruction

  * Cryptographic operation

* Data access control

  * Access control of persistent data (files)

  * Access control of temporay data (pipes)

  * Network information flow control

  * Import user data with access control

  * Secure deletion

* Authentication

  * Detect and prevent brute force attacks on auth

  * User attribute storage

  * Secret verification

  * Auth before accessing any security functions

  * Multifactor auth

  * Obscure auth feedback

  * Identification before access

* Secure configuration change and data access

  * Something about ACLs?

  * Security roles

* Reliable timestamps

* Session locking

  * Automatic

  * User-initiated

* Trusted channel (secure network access)

From Ubuntu Security Features:

* Privilege restriction

  * DAC / MAC

    * AppArmor

    * SELinux

    * SMACK

  * process privilege restrictions

    * PR_SET_SECCOMP

    * seccomp filtering

  * file system capabilities

* Storage and Filesystem

  * Full Disk Encryption

  * LVM Encryption

  * File Encryption

* Network and Firewalls

  * No Open Ports

  * SYN cookies

  * Firewall

* Cryptography

  * Password Hashing

  * Cloud PRNG Seed

  * Disabling Legacy TLS

* Process and memory protection

  * Sym-/Hard-Link restrictions

  * FIFO restrictions

  * (process-internal) memory protection

  * Stack Protector

  * Heap Protector

  * Stack ASLR

  * Libs/mmap ASLR

  * Exec ASLR

  * brk ASLR

  * vDOS ASLR

  * Default compiler and linker flags

    * Built as PIE

    * Built with Fortify Source

    * Built with RELRO

    * Built with BIND_NOW

    * Built with -fstack-clash-protection

    * Built with -fcf-protection

  * Non-Executable Memory

  * /proc/$pid/maps protection

  * ptrace scope

  * 0-address protection

  * /dev/mem protection

* Kernel protections

  * Kernel Lockdown

  * /dev/kmem disabled

  * Block module loading

  * Read-only data sections

  * Kernel Stack protector

  * Module RO/NX

  * Kernel Address Display Restriction

  * kASLR

  * denylist rare protocols

  * dmesg restriction

  * Block kexec

* Platform protections

  * UEFI Secure Boot

  * usb-related

    * usbguard

    * usbauth

    * bolt

    * thunderbolt-tools

  * TPM

* Security updates

  * Livepatch

  * Automatic security updates

Random ideas

* Disable debugging interfaces in many many places

* TPM and TEE support

* Secure boot/ crypto authenticated boot

* Measured boot

* Remote attestion

* Don't require login to online account

* Make rules about opt-in being required

* Everything shipped/included by manufacturer is the responsibility of the manufacturer (would cut down on junkware)

* Opt-in for all network functionality

* What about commonly disabled features for minimization

From [MITRE EMB3D](https://emb3d.mitre.org/):

Hardware:

* [TID-101](https://emb3d.mitre.org/threats/TID-101.html): Power Consumption Analysis Side Channel

* [TID-102](https://emb3d.mitre.org/threats/TID-102.html): Electromagnetic Analysis Side Channel

* [TID-103](https://emb3d.mitre.org/threats/TID-103.html): Microarchitectural Side Channels

* [TID-105](https://emb3d.mitre.org/threats/TID-105.html): Hardware Fault Injection – Control Flow Modification

* [TID-106](https://emb3d.mitre.org/threats/TID-106.html): Data Bus Interception

* [TID-107](https://emb3d.mitre.org/threats/TID-107.html): Unauthorized Direct Memory Access (DMA)

* [TID-108](https://emb3d.mitre.org/threats/TID-108.html): ROM/NVRAM Data Extraction or Modification

* [TID-109](https://emb3d.mitre.org/threats/TID-109.html): RAM Chip Contents Readout

* [TID-110](https://emb3d.mitre.org/threats/TID-110.html): Hardware Fault Injection – Data Manipulation

* [TID-111](https://emb3d.mitre.org/threats/TID-111.html): Untrusted External Storage

* [TID-113](https://emb3d.mitre.org/threats/TID-113.html): Unverified Peripheral Firmware Loaded

* [TID-114](https://emb3d.mitre.org/threats/TID-114.html): Peripheral Data Bus Interception

* [TID-115](https://emb3d.mitre.org/threats/TID-115.html): Firmware/Data Extraction via Hardware Interface

* [TID-116](https://emb3d.mitre.org/threats/TID-116.html): Latent Privileged Access Port

* [TID-118](https://emb3d.mitre.org/threats/TID-118.html): Weak Peripheral Port Electrical Damage Protection

* [TID-119](https://emb3d.mitre.org/threats/TID-119.html): Latent Hardware Debug Port Allows Memory/Code Manipulation

System Software:

* [TID-201](https://emb3d.mitre.org/threats/TID-201.html): Inadequate Bootloader Protection and Verification

* [TID-202](https://emb3d.mitre.org/threats/TID-202.html): Exploitable System Network Stack Component

* [TID-203](https://emb3d.mitre.org/threats/TID-203.html): Malicious OS Kernel Driver/Module Installable

* [TID-204](https://emb3d.mitre.org/threats/TID-204.html): Untrusted Programs Can Access Privileged OS Functions

* [TID-205](https://emb3d.mitre.org/threats/TID-205.html): Existing OS Tools Maliciously Used for Device Manipulation

* [TID-206](https://emb3d.mitre.org/threats/TID-206.html): Memory Management Protections Subverted

* [TID-207](https://emb3d.mitre.org/threats/TID-207.html): Container Escape

* [TID-208](https://emb3d.mitre.org/threats/TID-208.html): Virtual Machine Escape

* [TID-209](https://emb3d.mitre.org/threats/TID-209.html): Host Can Manipulate Guest Virtual Machines

* [TID-210](https://emb3d.mitre.org/threats/TID-210.html): Device Vulnerabilities Unpatchable

* [TID-211](https://emb3d.mitre.org/threats/TID-211.html): Device Allows Unauthenticated Firmware Installation

* [TID-212](https://emb3d.mitre.org/threats/TID-212.html): FW/SW Update Integrity Shared Secrets Extraction

* [TID-213](https://emb3d.mitre.org/threats/TID-213.html): Faulty FW/SW Update Integrity Verification

* [TID-214](https://emb3d.mitre.org/threats/TID-214.html): Secrets Extracted from Device Root of Trust

* [TID-215](https://emb3d.mitre.org/threats/TID-215.html): Unencrypted SW/FW Updates

* [TID-216](https://emb3d.mitre.org/threats/TID-216.html): Firmware Update Rollbacks Allowed

* [TID-217](https://emb3d.mitre.org/threats/TID-217.html): Remotely Initiated Updates Can Cause DoS

* [TID-218](https://emb3d.mitre.org/threats/TID-218.html): Operating System Susceptible to Rootkit

* [TID-219](https://emb3d.mitre.org/threats/TID-219.html): OS/Kernel Privilege Escalation

* [TID-220](https://emb3d.mitre.org/threats/TID-220.html): Unpatchable Hardware Root of Trust

* [TID-221](https://emb3d.mitre.org/threats/TID-221.html): Authentication Bypass By Message Replay

* [TID-222](https://emb3d.mitre.org/threats/TID-222.html): Critical System Service May Be Disabled

* [TID-223](https://emb3d.mitre.org/threats/TID-223.html): System Susceptible to RAM Scraping

* [TID-224](https://emb3d.mitre.org/threats/TID-224.html): Excessive Access via Software Diagnostic Features

* [TID-225](https://emb3d.mitre.org/threats/TID-225.html): Logs can be manipulated on the device

* [TID-226](https://emb3d.mitre.org/threats/TID-226.html): Device leaks security information in logs

Application Software:

* [TID-301](https://emb3d.mitre.org/threats/TID-301.html): Applications Binaries Modified

* [TID-302](https://emb3d.mitre.org/threats/TID-302.html): Install Untrusted Application

* [TID-303](https://emb3d.mitre.org/threats/TID-303.html): Excessive Trust in Offboard Management/IDE Software

* [TID-304](https://emb3d.mitre.org/threats/TID-304.html): Manipulate Runtime Environment

* [TID-305](https://emb3d.mitre.org/threats/TID-305.html): Program Executes Dangerous System Calls

* [TID-306](https://emb3d.mitre.org/threats/TID-306.html): Sandboxed Environments Escaped

* [TID-307](https://emb3d.mitre.org/threats/TID-307.html): Device Code Representations Inconsistent

* [TID-308](https://emb3d.mitre.org/threats/TID-308.html): Code Overwritten to Avoid Detection

* [TID-309](https://emb3d.mitre.org/threats/TID-309.html): Device Exploits Engineering Workstation

* [TID-310](https://emb3d.mitre.org/threats/TID-310.html): Remotely Accessible Unauthenticated Services

* [TID-311](https://emb3d.mitre.org/threats/TID-311.html): Default Credentials

* [TID-312](https://emb3d.mitre.org/threats/TID-312.html): Credential Change Mechanism Can Be Abused

* [TID-313](https://emb3d.mitre.org/threats/TID-313.html): Unauthenticated Session Changes Credential

* [TID-314](https://emb3d.mitre.org/threats/TID-314.html): Passwords Can Be Guessed Using Brute-Force Attempts

* [TID-315](https://emb3d.mitre.org/threats/TID-315.html): Password Retrieval Mechanism Abused

* [TID-316](https://emb3d.mitre.org/threats/TID-316.html): Incorrect Certificate Verification Allows Authentication Bypass

* [TID-317](https://emb3d.mitre.org/threats/TID-317.html): Predictable Cryptographic Key

* [TID-318](https://emb3d.mitre.org/threats/TID-318.html): Insecure Cryptographic Implementation

* [TID-319](https://emb3d.mitre.org/threats/TID-319.html): Cross Site Scripting (XSS)

* [TID-320](https://emb3d.mitre.org/threats/TID-320.html): SQL Injection

* [TID-321](https://emb3d.mitre.org/threats/TID-321.html): HTTP Application Session Hijacking

* [TID-322](https://emb3d.mitre.org/threats/TID-322.html): Cross Site Request Forgery (CSRF)

* [TID-323](https://emb3d.mitre.org/threats/TID-323.html): Path Traversal

* [TID-324](https://emb3d.mitre.org/threats/TID-324.html): HTTP Direct Object Reference

* [TID-325](https://emb3d.mitre.org/threats/TID-325.html): HTTP Injection/Response Splitting

* [TID-326](https://emb3d.mitre.org/threats/TID-326.html): Insecure Deserialization

* [TID-327](https://emb3d.mitre.org/threats/TID-327.html): Out of Bounds Memory Access

* [TID-328](https://emb3d.mitre.org/threats/TID-328.html): Hardcoded Credentials

* [TID-329](https://emb3d.mitre.org/threats/TID-329.html): Improper Password Storage

* [TID-330](https://emb3d.mitre.org/threats/TID-330.html): Cryptographic Timing Side-Channel

Networking:

* [TID-401](https://emb3d.mitre.org/threats/TID-401.html): Undocumented Protocol Features

* [TID-404](https://emb3d.mitre.org/threats/TID-404.html): Remotely Triggerable Deadlock/DoS

* [TID-405](https://emb3d.mitre.org/threats/TID-405.html): Network Stack Resource Exhaustion

* [TID-406](https://emb3d.mitre.org/threats/TID-406.html): Unauthorized Messages or Connections

* [TID-407](https://emb3d.mitre.org/threats/TID-407.html): Missing Message Replay Protection

* [TID-408](https://emb3d.mitre.org/threats/TID-408.html): Unencrypted Sensitive Data Communication

* [TID-410](https://emb3d.mitre.org/threats/TID-410.html): Cryptographic Protocol Side Channel

* [TID-411](https://emb3d.mitre.org/threats/TID-411.html): Weak/Insecure Cryptographic Protocol

* [TID-412](https://emb3d.mitre.org/threats/TID-412.html): Network Routing Capability Abuse

Potential additional sources of security requirements

* [NCP Checklists](https://ncp.nist.gov/repository)

* MSCERT (?)

* [MITRE EMB3D](https://emb3d.mitre.org/):

* https://trustedcomputinggroup.org/resources/

* https://trustedcomputinggroup.org/wp-content/uploads/TCG-Secure-Update-of-SW-and-FW-on-Devices-v1r72_pub.pdf

* Read exploit reports and CVEs

* [ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf)

* [CHERI BSD](https://www.cheribsd.org/)

* [ETSI EN 103 732](https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=69549)

Probably the most digestible is Ubuntu:

https://documentation.ubuntu.com/security/docs/security-features/

they have the "qa regression test" suite, which has a bunch of

security testing (search "security" in here):

https://git.launchpad.net/qa-regression-testing/tree/scripts

for example, config testing:

https://git.launchpad.net/qa-regression-testing/tree/scripts/test-kernel-security.py

behavioral testing:

https://git.launchpad.net/qa-regression-testing/tree/scripts/kernel-security

Chrome OS security principles:

https://www.chromium.org/chromium-os/developer-library/reference/security/security-whitepaper/#principles-of-chromeos-security

Much of the Chrome OS testing has been slowly getting merged into the

much more complex Android stuff below...

Android. This is weird to navigate, but start here:

https://source.android.com/docs/security/overview

on the left will be "Kernel security", "App security", "Implement

security". Linked in there is the Compatibility Definition Document

(CDD), which is "you have to do this to say you're and 'Android' device":

https://source.android.com/docs/compatibility/cdd

The latest is 16:

https://source.android.com/docs/compatibility/16/android-16-cdd

the CDD has an extensive security section:

https://source.android.com/docs/compatibility/16/android-16-cdd#9_security_model_compatibility

including specific features:

https://source.android.com/docs/compatibility/16/android-16-cdd#97_security_features

The _testing_ for the CDD is the Android Compatibility Test Suite (CTS):

https://source.android.com/docs/compatibility/cts

Which has kernel security tests, for example, though it is a bit minimal:

https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/security/src/android/security/cts/KernelConfigTest.java

**Hardware-Based Countermeasures**

* Secure boot with HW Root of Trust: Ensures that only authenticated firmware is executed, anchored in immutable hardware

* Hardware-backed Key Storage (e.g., TPM, Secure Enclave): Protects cryptographic keys from software-level attacks and unauthorized access

* Memory Protection Units (MPU and/or MMU): Enforces access control policies at hardware level, isolating critical OS components

* Hardware-enforced Execution Zones (e.g., ARM TEE): Enables secure execution environments for sensitive operations.

* Bootloader Locking and Firmware/SW Anti-rollback: Prevents downgrading to vulnerable firmware/SW versions.

* Hardware Watchdog Timers: Detects and recovers from system hangs or malicious loops

* Secure Debug Interface Management: Disabling or restricting access through state-of-the-art security mechanisms debug access

## Suggested additional requirements

TODO:

#### Kernel and userspace memory safety mitigations

FIXME: Stack ASLR

FIXME: Exec ASLR

#### Kernel-specific memory safety mitigations

FIXME: Module ASLR

FIXME: JIT ASLR

#### Userspace-specific memory safety mitigations

FIXME: Sym-/Hard-Link restrictions

FIXME: FIFO restrictions

FIXME: Libs/mmap ASLR

FIXME: brk ASLR

##### Toolchain hardening

FIXME: PIE

FIXME: FORTIFY_SOURCE

FIXME: RELRO (merge below into "binary runtime metadata"?)

FIXME: BIND_NOW (merge above into "binary runtime metadata"?)

FIXME: -fstack-clash-protection (covered by "stack exhaustion"?)

FIXME: -fcf-protection (covered by "CFI"?)

#### Kernel provided userspace mitigations

FIXME: vDSO ASLR

FIXME: NULL-address protection

FIXME: ptrace scope

### Old logging requirements

#### 5.2.X.1 Example threat

Attacker's security-relevant changes to systems can't be tracked or audited

#### 5.2.X.x **MI-LLOG**: Local logging

Use case: Everything above toy that has security-relevant configuration?

* Mitigation: Keep local logs of important security events with timestamps, including TBD:

  * list of types of events

  * enough information to directly repair the change without scanning the whole system

  * enough log storage ??? amount

* Test: For each type of logged event, execute the action that should be logged

* Result: Each event is logged

* Output: Log output for each event

#### 5.2.X.x **MI-RLOG**: Remote logging

Use case: Higher risk servers, workstations, laptops, anything that can't write logs locally?

* Mitigation: same as MI-LLOG but with ability to send logs via a verifiable channel to an authorized log server, as long as the connection to the server is available

* Test: For each type of logged event that would result in the logging server becoming unavailable, execute the action that would result in that log event

* Result: Log output for each event is sent to log server

* Output: Log output as sent to log server or as recorded on log server

* Requirements: way to setup remote log server for product as shipped

### 5.2.X **TR-LLTP**: Local log tamper prevention

#### 5.2.X.1 Example threat

Attacker tampers with log messages

#### 5.2.X.x **MI-LLGA**: Local log file only editable by privileged users

Use case: Any product with multiple users?

* Mitigation: log file has permissions allowing editing only by users with appropriate privileges

* Test: attempt to write to, delete, and move each log file by an unauthorized user

* Result: access is denied, log is not changed

* Output: error messages, comparison of log status shows no changes

* Requirements: way to attempt to tamper with logs on product as shipped

FIXME: what about append-only?

Note: all security-relevant configuration handled by a different requirement

### 5.2.X **TR-RLTP**: Remote log tamper prevention

#### 5.2.X.1 Example threat

Attacker intercepts, alters, or replaces log message stream to remote log server

#### 5.2.X.x **MI-RLSA**: Remote log server authentication

* Mitigation: Authentication of remote log server

* Test: Attempt to intercept initial connection to log server using identical responses as the authorized log server, except where using only publicly available information would be different

* Result: Failure to connect to remote log server and no logs are sent

* Output: Error message

#### 5.2.X.x **MI-RLET**: Encrypt log message stream with tamper-evident protocol

Use case: Higher risk servers, workstations, laptops?

* Mitigation: Use tamper-resistant encryption on the log stream such as TBD LIST OR REFER

* Test: Alter, insert, and delete log message stream using only publicly available data

* Result: Log server rejects tampered/false log message

* Output: Error message

# Annex F (informative): Change history

# Annex E (informative): Change history

The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.