Remove subjective and insufficienly clear words

Figure { seq fig }: A diagram illustrating a hub-and-spoke network

In a mesh network, clients and gateways establish direct tunnels between each other. A management server is used to authenticate VPN clients and gateways, and to configure them.

In a mesh network, clients and gateways establish direct tunnels between each other. A management server is used to authenticate VPN clients and gateways, and to configure nodes.

![A diagram illustrating a mesh network.](./media/mesh.drawio.png)

#### 4.2.4.2 Server & gateway remote data processing

When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. They typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on their customers’ infrastructure. Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, such reliance introduces a product-facing RDPS boundary between the local product side and the RDPS side. RDPS-side VPN servers and gateways are held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.

When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. These typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on customer infrastructure. Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, such reliance introduces a product-facing RDPS boundary between the local product side and the RDPS side. RDPS-side VPN servers and gateways are held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.

### 4.2.5 Management server

* Access control: policies that permit or deny certain traffic within the network.

* Monitoring and logging: configuration logs, network logs, telemetry used for troubleshooting.

The management server typically maintains configuration of the whole network and provides configuration to individual clients as they connect (authentication, address assignment, routes, etc). In VPNs using a hub-and-spoke topology, management server is often implemented as part of the VPN server. For consumer and small-business use cases as described in 4.6, this server is considered remote data processing and fully controlled by the manufacturer. Mesh networks may use a management server operated by the manufacturer as part of their remote data processing solution, or may handle all management in a peer-to-peer fashion.

The management server typically maintains configuration of the whole network and provides configuration to individual clients at the time of connection (authentication, address assignment, routes, etc). In VPNs using a hub-and-spoke topology, management server is often implemented as part of the VPN server. For consumer and small-business use cases as described in 4.6, this server is considered remote data processing and fully controlled by the manufacturer. Mesh networks may use a management server operated by the manufacturer as part of their remote data processing solution, or may handle all management in a peer-to-peer fashion.

## 4.3 Operational Environment

(previously ## 4.4)

<mark>Editor’s Note: This clause should describe the conditions under which products of a particular type in the category are used as well as detailing possible systems in which they are integrated, including network context, integration environment, and physical surroundings, including the external conditions affecting RDPS.</mark>

### 4.3.1 General description

The physical environment a VPN product may be deployed in affects the applicable risks and enables potential risk transfers. VPN products may be deployed in various different environments such as different physical devices as well as different physical networks.

There are various types of devices, but they all share that the firewall is managed by the underlying system and outside of the control of the VPN product.

There are various types of devices, but all share that the firewall is managed by the underlying system and outside the control of the VPN product.

* **Network devices**: VPN products are often deployed on network devices to tunnel traffic to remote endpoints. Such network devices (for example a router) are usually located on the edge between a private and public network and thus exposed to internal as well as external attack surfaces. A firewall is usually included by the underlying OS or hardware system for such network devices.

* **Internet of Things, Consumer Gadgets and Appliances**: VPN products could be deployed on IoT devices, consumer gadgets, TVs or other appliances where the product is bound to the security model of the device hardware and operating system. The device might lack proper hardware security modules, firewall support, or enforce a relaxed security model (for example requiring the product to run as root without proper isolation between applications and users). Such devices are usually placed in private networks.

The technical requirements of the present document apply under the product context described in [clause 4](#_clause.4), which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.

Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product. Each requirement clearly indicates its applicability, and all requirements are mapped to use cases in Annex B. The applicability of requirements is based on the security analysis in Annex B, using the product assets and risk factors derived from the characteristics of each use case.

Not all requirements are universally applicable: The applicability of requirements may be based on use cases described in clause 4.6 or specific capabilities of the product. Each requirement clearly indicates its applicability, and all requirements are mapped to use cases in Annex B. The applicability of requirements is based on the security analysis in Annex B, using the product assets and risk factors derived from the characteristics of each use case.

Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, mitigations that transfer the risk will be included as an option to fulfill a cybersecurity requirement, depending on the use case and risk factors.

#### 5.2.2.1 Requirement

1. **REQ-SSD-02 (MI-SSCA)-1** All cybersecurity-relevant parts of the product shall be checked for known code patterns that produce _common memory errors_, and

2. **REQ-SSD-02 (MI-SSCA)-2** any identified memory errors or suppression of warnings shall be documented with a rationale for why it does not constitute an unacceptable risk.

2. **REQ-SSD-02 (MI-SSCA)-2** any identified memory errors or suppression of warnings shall be documented with a rationale for how it does not constitute an unacceptable risk.

> NOTE: Examples of _common memory errors_ include, but may not be limited to:

>

#### 5.2.5.1 Requirement

1. **REQ-SSD-05 (MI-IMSL)-1** The product shall employ implementation practices, tooling, or language features that mitigate memory corruption vulnerabilities, and

2. **REQ-SSD-05 (MI-IMSL)-2** any use of unsafe memory features in the product's own code or in dependencies shall be documented, justified as necessary, and accompanied by the specific mitigations applied to reduce residual risk.

2. **REQ-SSD-05 (MI-IMSL)-2** any use of unsafe memory features in the product’s own code has corresponding evidence of both necessity and the specific mitigations applied to reduce residual risk.

#### 5.2.5.2 Applicability

#### 5.7.1.2 VPN traffic routing (MI-ROUT-1, MI-ROUT-2, MI-ROUT-3, MI-ROUT-4)

From the moment the user activates the VPN connection until the user knowingly deactivates the VPN connection, no network traffic intended for the VPN connection should exit the endpoint via anything other than the VPN connection, whether or not the VPN connection is functioning.

From the moment the user activates the VPN connection until the user knowingly deactivates the VPN connection, no network traffic intended for the VPN connection should exit the endpoint via anything other than the VPN connection, regardless of whether the VPN connection is functioning.

Out of scope for routing-related requirements are other software on the user’s endpoint with elevated privileges, users with administrator privileges, as well as the operating system itself that could change relevant network configuration (network interfaces, routes, DNS) or circumvent the VPN tunnel due to elevated privileges.

> NOTE: For the purpose of the present clause, "cybersecurity-relevant logs" refers to security related information logged locally on the VPN client.

> NOTE: Certain cybersecurity-relevant events might still be transferred to the VPN manufactorer without explicit authorization from the user, if the event transmissions are required to fullfill the intended purpose of the product. 

> NOTE: Certain cybersecurity-relevant events might still be transferred to the VPN manufacturer without explicit authorization from the user, if the event transmissions are required to fulfill the intended purpose of the product. 

> NOTE: If not absolutely necessary, free text inputs should be omitted from log entries. Not only does this protect against log injection attacks, but also against accidentially logging sensitive data the user mistakenly entered. 

> NOTE: If not absolutely necessary, free text inputs should be omitted from log entries. Not only does this protect against log injection attacks, but also against accidentally logging sensitive data the user mistakenly entered. 

### 5.14.TK REQ-LOG-TK (MI-LOGG-1) Local event logging

PASS if **any** of the following are fulfilled:

* The output of the source code analysis tool confirms the absence of the listed memory errors, or

* documentation is present, the method of running the tool is consistent with rationale, and all warnings or suppression of warnings have documented justification for why they are an acceptable risk.

* the method of running the tool is consistent with rationale and all warnings or suppression of warnings have documentation demonstrating that each one does not present an unacceptable cybersecurity risk.

Otherwise FAIL

Carry out one of the following methods. Only one method is necessary to complete the assessment.

Method 1: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product's interfaces that are normally accessible in the product's intended use. Use the code coverage tool to determine which lines of code have been exercised. Continue this process until each line of code that can reasonably be exercised deterministically by providing specific input values has been executed. For each memory error detected, document why it does not constitute an unacceptable risk.

Method 1: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product’s interfaces that are normally accessible in the product’s intended use. Use the code coverage tool to determine which lines of code have been exercised. Continue this process until each line of code that can reasonably be exercised deterministically by providing specific input values has been executed. For each memory error detected, provide documentation demonstrating that it does not constitute an unacceptable risk.

Method 2: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product's interfaces that are normally accessible in the product's intended use. Use the code coverage tool to determine which lines of code have been exercised. Use a risk-based approach and the output of the code coverage measurements to decide when testing is complete. For each memory error detected, document why it does not constitute an unacceptable risk.

Method 2: For all cybersecurity-relevant executables that may have memory errors, run the executable in an environment that allows measurement of code coverage and detection of common memory errors. While running the executable, vary the inputs to the product’s interfaces that are normally accessible in the product’s intended use. Use the code coverage tool to determine which lines of code have been exercised. Use a risk-based approach and the output of the code coverage measurements to decide when testing is complete. For each memory error detected, provide documentation demonstrating that it does not constitute an unacceptable risk.

Method 3: Run a tool that tests the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors. For each memory error detected, document why it does not constitute an unacceptable risk.

Method 3: Run a tool that tests the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors. For each memory error detected, provide documentation demonstrating that it does not constitute an unacceptable risk.

Method 4: Review source code to determine its language and what exceptions to memory safety exist. For each use of memory-unsafe features or code, document why it does not constitute an unacceptable risk.

Method 4: Review source code to determine its language and what exceptions to memory safety exist. For each use of memory-unsafe features or code, provide documentation demonstrating that it does not constitute an unacceptable risk.

#### 6.2.3.4 Verdict

Method 1: PASS if **all** of the following are fulfilled:

* All code that could be deterministically exercised by varying the inputs has been executed, and

* all reported memory errors are documented and justified.

* all reported memory errors have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.

Otherwise FAIL

Method 2: PASS if **all** of the following are fulfilled:

* The interfaces have been properly covered from a risk perspective, and

* all reported memory errors are documented and justified.

* all reported memory errors have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.

Otherwise FAIL

PASS if **all** of the following are fulfilled:

* All boundary values tested, and

* all memory errors detected are documented and justified.

* all detected memory errors have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.

Otherwise FAIL

PASS if **all** of the following are fulfilled:

* Source code is in a memory-safe language, and

* the documentation of all uses of unsafe memory features convincingly demonstrates that each one does not present a cybersecurity risk.

* all uses of unsafe memory features have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.

Otherwise FAIL

PASS if **all** of the following are fulfilled:

* All boundary values tested, and

* all memory errors detected are documented and justified.

* all detected memory errors have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.

Otherwise FAIL

PASS if **all** of the following are fulfilled:

* The product employs implementation practices, tooling, or language features that mitigate memory corruption vulnerabilities, and

* documentation of all uses of unsafe memory features in the product’s own code or in dependencies identifies each instance, justifies its necessity, and demonstrates that the applied mitigations reduce the residual cybersecurity risk to an acceptable level.

* each instance of unsafe memory features in the product’s own code or in dependencies has corresponding documentation demonstrating evidence of necessity, and that the applied mitigations reduce the residual cybersecurity risk to an acceptable level.

Otherwise FAIL

PASS if **all** of the following are fulfilled:

* Binaries actively implement the appropriate exploit mitigations, and

* all exceptions are documented and justified.

* all exceptions have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.

Otherwise FAIL

#### 6.8.2.5 Evidence

* Collected system configuration

* Annotations of any configuration changes explaining why those changes are not functional

* Annotations of any configuration changes detailing how those changes are not functional

* Log messages from tests

### 6.8.3 REQ-INT-03 (MI-CONF-2) VPN client provides a method to restore any system configuration it changes to its previous state

#### 6.8.3.5 Evidence

* Collected system configuration

* Annotations of any configuration changes explaining why those changes are not functional

* Annotations of any configuration changes detailing how those changes are not functional

* Log messages from tests

* Method used to force connection to end without allowing shutdown tasks to run

* Method used to restore system configuration

#### 6.8.4.5 Evidence

* Collected system configuration

* Annotations of any configuration changes explaining why those changes are more restricted/secure

* Annotations of any configuration changes detailing how those changes are more restricted/secure

* Log messages from tests

* Method used to force connection to end without allowing shutdown tasks to run

* Packet capture

* Documentation of Personal Data

* Authorization

* Justification

* Documentation of necessity for product’s intended purpose

### 6.9.3 REQ-DM-03 (MI-NPER-2) No Personal Data sent outside endpoint

* All labelled Personal Data collected is either:

   * strictly necessary for the confidentiality or availability of the product as outlined in the internal policy and intended use of the VPN manufacturer or

   * Personal Data collected is explicitly justified for authentication, access control, or subscription management.

   * Personal Data collected is explicitly necessary for authentication, access control, or subscription management.

* No personal data is collected from the user’s VPN tunnelling and routing functionality which is not indented for the VPN manufacturer.

Otherwise FAIL

#### 6.9.3.5 Evidence

* Packet capture

* Technical documentation justifying the necessity of any transmitted data

* Technical documentation demonstrating the necessity of any transmitted data

### 6.9.4 REQ-DM-04 (MI-NPER-3) Minimize Personal Data required service provisioning and payment

2. Select the options that require the least Personal Data

3. Recording all data entered

4. Examine the data entered looking for Personal Data

5. Review the provided documentation of justification for the necessity of this data in relation to providing the service, processing payment or managing the subscription.

5. Review the provided documentation demonstrating the necessity of this data in relation to providing the service, processing payment or managing the subscription.

#### 6.9.4.4 Verdict

PASS if **any** of the following are fulfilled:

* There is no Personal Data recorded, or

* Personal Data recorded has a justified, legal, or documented operational reason essential for the delivery of the service or payment processing.

* Personal Data recorded has a documentation providing the legal or operational reason it is essential for the delivery of the service or payment processing.

Otherwise FAIL

#### 6.9.4.5 Evidence

* The record of data entered with a short description indicating whether the particular data element alone or in combination with other data elements allows for singling out the individual in accordance with the definition of personal data under the applicable law. Where this is the case, the reason why the data element is required should also be documented.

* The record of data entered with a short description indicating whether the particular data element alone or in combination with other data elements allows for singling out the individual in accordance with the definition of Personal Data under the applicable law. Where this is the case, the reason the data element is required should also be documented.

### 6.9.5 REQ-DM-05 (MI-NPER-4) Minimize Personal Data stored

PASS if **any** of the following are fulfilled:

* There is no Personal Data recorded, or

* Personal Data recorded has a justified, documented operational reason aligned with the intended purpose of the product.

* the product has a documented operational necessity for any Personal Data recorded which aligns with the intended purpose of the product.

Otherwise FAIL

* Policy

* Samples of stored data

* Documentation of why the samples don't contain Personal Data

* Documentation of the operational reason for samples to contain Personal Data in order to fulfil the intended purpose of the product.

### 6.9.6 REQ-DM-06 (MI-LOGG-X) No data persistence or storage enabled on exit nodes (MI-LOGG-X)

* Invalid packets and descriptions

* Logs of processing

* Annotations explaining why the order of operations is the most efficient reasonable way to process the packet

* Annotations detailing how the order of operations is the most efficient reasonable way to process the packet

### 6.10.3 REQ-AP-03 (MI-LMEM) Limit memory usage

#### 6.12.2.5 Evidence

* Collected permission states

* Annotations of any permission requests explaining why those permissions are more restricted/secure

* Annotations of any permission requests detailing how those permissions are more restricted/secure

* Log messages from tests

## 6.13 Exploit mitigation

#### 6.13.5.3 Activities

1. Create a list of services that can only be used if routing of external traffic is enabled, and

2. document why each service requires routing of external traffic to function.

2. document the reason each service requires routing of external traffic to function.

#### 6.13.5.4 Verdict

PASS if **all** of the following are fulfilled:

* All such services are documented, and

* explanation is convincing.

* documentation aligns with the product’s functionality.

Otherwise FAIL

* for each triggered event:

    * the collected log message reflects the cybersecurity-relevant event,

    * the log message indicating the event does not include any secrets, credentials, network traffic content or connection metadata as defined in 5.14.1.3, and

    * the log message indicating the event is not transmitted to the manufacturer without explicit user authorization, or the technical documentation provides a clear justification as to how such a transmission is required to fulfill the intended purpose of the product.

    * the log message indicating the event is not transmitted to the manufacturer without explicit user authorization, or the technical documentation demonstrates the necessity of this transmission in order to fulfill the intended purpose of the product.

Otherwise FAIL