[OC5 5] Fix note style to align with 3GPP md parser

* Objective: Prevent exploitation of known exploitable vulnerabilities at first use

* Preparation: Using the product's SBOM, relevant publically accessible vulnerability databases, private disclosures, and internal testing, compile a list of known exploitable vulnerabilities in the product and its components that will be tested. Collect tests for each one.

> [!NOTE]

> Some examples of publically accessible vulnerability databases are [GCVE](https://gcve.eu), [EUVD](http://euvd.enisa.europa.eu), and the Common Vulnerability and Exposures (CVE) List maintained by the MITRE Corporation. 

> NOTE: Some examples of publically accessible vulnerability databases are [GCVE](https://gcve.eu), [EUVD](http://euvd.enisa.europa.eu), and the Common Vulnerability and Exposures (CVE) List maintained by the MITRE Corporation. 

* Activities: On a new product, carry out a secure update, run the tests, and compare the results with the generated list of known exploitable vulnerabilities

* Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or mitigation requirement => PASS, otherwise FAIL

**Guidance:** In alignment with the Cyber Resilience Act Annex I Part I (1), this section addresses overarching risks and mitigations regarding the secure design and development of the product that are not specifically treated by other categorical essential requirements (such as confidentiality, access control, or secure updates). The requirements herein ensure the final product itself embodies security by design.

> [!NOTE]

> Security profiles (as described in Annex B) determine which of these controls can be utilised to mitigate the threat. In particular, across all security profiles only one—at most—of the following three is called for when applied to a single product: FZ95, BTIN, IMSL. See B.TK for more information.

> NOTE: Security profiles (as described in Annex B) determine which of these controls can be utilised to mitigate the threat. In particular, across all security profiles only one—at most—of the following three is called for when applied to a single product: FZ95, BTIN, IMSL. See B.TK for more information.

#### 5.2.3.2 MI-SSCA: Static source code analysis for memory errors

* Verdict: Update is not installed => PASS, otherwise => FAIL

* Evidence: Revoked update image, error message, before and after comparison of any data that would have been altered if it had been installed

> [!note]

> Multiple different versions of software that are _simultaneously_ endorsed/trusted for installation do not constitute a "rollback attack". This mitigation specifically applies to the scenario where the software updater on the product/device can be tricked into trusting a software package that is _no longer_ valid, or tricked into thinking that an older software version is actually a new update.

> NOTE: Multiple different versions of software that are _simultaneously_ endorsed/trusted for installation do not constitute a "rollback attack". This mitigation specifically applies to the scenario where the software updater on the product/device can be tricked into trusting a software package that is _no longer_ valid, or tricked into thinking that an older software version is actually a new update.

#### 5.2.4.11 MI-SURC: Signing keys have strictly scoped usage

The product shall reject Repository Metadata if its version number is equal to or less than the highest version number the update client has seen.

> [!note]

> This requirement is about repository metadata. Repository metadata should never be permitted to roll back; it merely communicates the attested validity of a set of software. Software itself can often be permitted to roll back; see also the guidance on MI-SURP (The product shall reject an update file that has been indicated to no longer be valid).

> NOTE: This requirement is about repository metadata. Repository metadata should never be permitted to roll back; it merely communicates the attested validity of a set of software. Software itself can often be permitted to roll back; see also the guidance on MI-SURP (The product shall reject an update file that has been indicated to no longer be valid).

* Reference: TR-SCUD

* Objective: Prevent rollback attacks by rejecting older versions of Repository Metadata

The VPN client shall not reduce system security after the end of the VPN connection, even if normal connection shutdown tasks have not completed.

> [!note]

> This is a "fail-closed" requirement—if something goes with the VPN connection, it is better to end with a more restricted/secure network configuration than the configuration before the VPN connection started, than a less restricted network configuration.

> NOTE: This is a "fail-closed" requirement—if something goes with the VPN connection, it is better to end with a more restricted/secure network configuration than the configuration before the VPN connection started, than a less restricted network configuration.

* Reference: TR-CONF

* Objective: Preserve cybersecurity of system

Custom VPN clients shall not require permissions that they do not need.

> [!note]

> The VPN product should be able to operate without a wide set of permissions—eg, a VPN does not require access to files/folders (like ~/Downloads) nor would it need access to the local network.

> NOTE: The VPN product should be able to operate without a wide set of permissions—eg, a VPN does not require access to files/folders (like ~/Downloads) nor would it need access to the local network.

* Reference: TR-CONF

* Objective: Operate on a least privilege principle

The following requirements apply to DNS traffic intended for the VPN connection. DNS queries for connection establishment, maintenance or restoration of the VPN tunnel are excluded.

> [!note]

> The network configuration of a system is frequently changed by multiple different pieces of software, many of which the VPN client has no control over or insight into.

> NOTE: The network configuration of a system is frequently changed by multiple different pieces of software, many of which the VPN client has no control over or insight into.

#### 5.2.9.2 MI-DNSL-1 Inform user of visibility of DNS queries

* Verdict: All DNS traffic shall be routed exclusively through the VPN connection => PASS, otherwise FAIL

* Evidence: VPN client configuration, a packet capture showing the destination of all DNS queries

> [!note]

> Excluded from this verdict are DNS queries which are transmitted using DoH, DoT or other DNS query hiding techniques. 

> NOTE: Excluded from this verdict are DNS queries which are transmitted using DoH, DoT or other DNS query hiding techniques. 

#### 5.2.9.4 MI-DNSL-3 Exclusive DNS routing by default

The VPN shall not store any Personal Data of the user on remote data processing systems.

> [!note]

> VPN manufacturers may use remote systems to handle support tickets, e-mail and a knowledge base. The VPN manufacturer shall not store any Personal Data in remote data processing systems without abundantly clear and explicit permission from the user.

> NOTE: VPN manufacturers may use remote systems to handle support tickets, e-mail and a knowledge base. The VPN manufacturer shall not store any Personal Data in remote data processing systems without abundantly clear and explicit permission from the user.

* Applicability: (optional, for requirements that depend on a feature)

* Reference: TR-DMIN

* Verdict: For each triggered event, the log contains a message indicating the event, log message does not include any information likely to be confidential => PASS, otherwise FAIL

* Evidence: Method of triggering events, log messages with annotations

> [!note]

> One type of event for which log messages must take care to not accidentally include a secret is failed password authentication attempts. Since users often type their password into the username field, including the username field in the log message may result in including a secret in the log message.

> NOTE: One type of event for which log messages must take care to not accidentally include a secret is failed password authentication attempts. Since users often type their password into the username field, including the username field in the log message may result in including a secret in the log message.

#### 5.2.15.3 MI-LOGG-2: Remote Logging

* Verdict: For each triggered event, the log contains a message indicating the event, log message does not include any information likely to be confidential => PASS, otherwise FAIL

* Evidence: Method of triggering events, log messages with annotations

> [!note]

> One type of event for which log messages must take care to not accidentally include a secret is failed password authentication attempts. Since users often type their password into the username field, including the username field in the log message may result in including a secret in the log message.

> NOTE: One type of event for which log messages must take care to not accidentally include a secret is failed password authentication attempts. Since users often type their password into the username field, including the username field in the log message may result in including a secret in the log message.

#### 5.2.15.4 MI LOGG 3: No-Logs Policy and Traffic Anonymization

* Verdict: If the server utilizes non-volatile disk-based storage for system logs, swap, or temporary processing, or if any data persists across a power cycle => FAIL, otherwise => PASS.

* Evidence: Copies of the relevant server configuration files demonstrating the use of RAM disks, and the output of the storage inspection after the power cycle.

> [!note]

> "Minimization of data compromise due to equipment compromise" is a completely NEW OBJECTIVE

> NOTE: "Minimization of data compromise due to equipment compromise" is a completely NEW OBJECTIVE

### 5.2.16 TR-SCDL: Secure deletion

The product shall provide a method of deleting all user data and settings and resetting the product to its secure-by-default configuration.

> [!note]

> Overwriting all user-writable storage or encrypting all user data and deleting the key are two secure deletion mechanisms.

> NOTE: Overwriting all user-writable storage or encrypting all user data and deleting the key are two secure deletion mechanisms.

#### 5.2.16.2 MI-RSET: Secure deletion via reset

The product shall check network traffic from untrusted sources for validity and discard it efficiently, using reasonable efforts to minimise use of system resources on invalid packets.

> [!note]

> One method of minimising resource use on invalid packets is to do the least resource-intensive validity checks first, and to do validity checks before using system resources based on possibly invalid data. For example, verifying that the length of a packet is valid should be done before verifying that the source address is valid, and both should be done before allocating memory necessary to process a packet of that length.

> NOTE: One method of minimising resource use on invalid packets is to do the least resource-intensive validity checks first, and to do validity checks before using system resources based on possibly invalid data. For example, verifying that the length of a packet is valid should be done before verifying that the source address is valid, and both should be done before allocating memory necessary to process a packet of that length.

* Reference: TR-AVAI

* Objective: Maintain service availability during denial-of-service attacks

The product shall limit and fairly allocate memory usage triggered by untrusted input to maintain availability of product functions and the functions of the underlying platform and other products sharing system resources.

> [!note]

> The product should range-check untrusted input fields that trigger memory allocations and rate-limit or drop input that would allocate enough memory to impair the functions of any part of the system.

> NOTE: The product should range-check untrusted input fields that trigger memory allocations and rate-limit or drop input that would allocate enough memory to impair the functions of any part of the system.

* Reference: TR-AVAI

* Objective: Maintain service availability during denial of service attacks

#### 5.2.20.2 MI-CDST: Protect confidentiality of data stored on the product

> [!note]

> This threat is currently only a covered by a single high-level mitigation, more detailed and specific mitigations will be added in future drafts.

> NOTE: This threat is currently only a covered by a single high-level mitigation, more detailed and specific mitigations will be added in future drafts.

The product shall protect data stored on the product from unauthorized access.

* Verdict: If all methods of ensuring confidentiality match the type of the data stored, and all the attempts to read confidential data without authorization fail => PASS, otherwise => FAIL

* Evidence: Logs of determination of type of data and method of confidentiality and attempts to read confidential data without authorization

> [!note]

> Data may be protected by the environment, permissions, encryption, salting and hashing, offline storage, or hardware-backed secrets.

> NOTE: Data may be protected by the environment, permissions, encryption, salting and hashing, offline storage, or hardware-backed secrets.

## 5.3 Risk mitigation sets