Add logging and configuration change requirements

  * any setup information for the test (load this module, flip this switch, run this script, etc.)

* The standard can include requirements for the tools used in the test itself (features or sensitivity or maybe even source code available?)

* Any tests should demonstrate both the failure and success version of the test to rule out false positives or negatives

Mitigations are how a technical requirement can be satisfied. Mitigations must be tailored to the use case and take into account the user’s sophistication and the operational environment.

## 5.2 Technical security requirements specifications

* Requirements: features of the product as placed on the market necessary to run the test

* Documentation: what data the manufacturer must save for provision to the MSA

> Copy-n-paste mitigation format

#### 5.2.X.x **MI-XXXX**:

Use case:

* Mitigation:

* Test:

* Result:

* Output:

* False positive test:

* Requirements:

* Documentation:

### 5.2.X **TR-MISO**: Memory isolation

#### 5.2.X.1 Threat description

* Requirements: board support package

* Documentation: source code and output of the tests, source code of operating system, checker information

#### 5.2.X.x **MI-XXXX**: Memory protection using MMU

#### 5.2.X.x **MI-MMUP**: Memory protection using MMU

Use case: Any operating system that requires process isolation (anything with multiple users, potentially untrusted users, untrusted userspace executables, etc.)

### 5.2.X **TR-OOBM**: Out-of-bounds memory access prevention or mitigation

FIXME: should all of this be required for executables running with elevated privileges?

#### 5.2.X.1 Threat description

Threat: attacker uses an operating systems vulnerability to access memory in an unauthorized manner while possessing elevated memory access privileges.

* Requirements: way to read log output on product as shipped

* Documentation:

#### 5.2.X. **MI-KFCI**: Kernel forward control flow integrity

#### 5.2.X.x **MI-KFCI**: Kernel forward control flow integrity

* Sub-threat: Kernel function pointer overwrite

* Mitigation: Protect saved function pointers from overwrite

Use case: phone, other devices at higher risk of malicious code execution

* Mitigation: Use enhanced hardware memory tagging feature for kernel memory allocations

* Test: Allocate memory with a tag, attempt to access the memory without the tag

* Result: segmentation fault, error handling code executed or thread killed

* Output: error message or log message for killed thread

* Requirements: way to read output on product as shipped

* Documentation: source code of tests, output of error message or thread kill

### 5.2.X **TR-LSRE**: Logging of security-relevant events

#### 5.2.X.1 Threat description

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: Log output for each event

* Output: Log output for each event

* Requirements: way to read log output on product as shipped

* Documentation: list of security-relevant configuration, description of tests, source code of tests, output of tests

#### 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 for each event as sent to log server

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

* Documentation: description of tests, source code of tests, output of tests, instructions for setting up log server

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

#### 5.2.X.1 Threat description

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, way to read log output

* Documentation: how to get access to the device to attempt log tampering, source code of tests, documentation to run tests, output of tests

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 Threat description

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

* Output: Log message, error message, no logs are sent

* Requirements: way to read local log output

* Documentation: documentation, source, output for tests, information/software necessary to masquerade as a log server

#### 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: Local log shows lack of confirmation of data sent or error message indicating loss/corruption of data

* Requirements: way to read local log output

* Documentation: documentation, source, output for tests

### 5.2.X **TR-PCFG**: Prevent unauthorized changes of security-relevant configuration

#### 5.2.X.1 Threat description

Threat: Unauthorized user changes security-relevant configuration

#### 5.2.X.x **MI-CFGA**: Security-relevant configuration not editable by unauthorized user

Use case: Every product that has multiple user privilege levels?

* Mitigation: Security relevant configuration can only be edited by authorized user

* Test: For each security-relevant configuration item, attempt to edit, delete, or disable

* Result: Failure messages, configuration does not change

* Output: Failure messages, before and after comparison of configuration shows no change

* Requirements: way to attempt configuration changes as unauthorized user, way to read error messages, way to compare configuration before and after

* Documentation: list of all security-relevant configuration items, source, description, output of tests, documentation on how to set up tests, read configuration

> Copy-n-paste mitigation format

### 5.2.X **TR-XXXX**:

#### 5.2.X.1 Threat description

Threat:

#### 5.2.X.x **MI-XXXX**:

Use case:

* Mitigation:

* Test:

* Result:

* Documentation:

### 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?