Reformat some requirements, add mapping to risk factors

* Test:

* Result:

* Output:

Optional:

* False positive test:

* Requirements:

* Documentation:

* Test: start the VPN connection, after it reports that it is connected, kill the VPN software in a way that does not allow it to execute any clean up routines, then attempt to transfer data that should only go through the VPN connection

* Result: no data should exit the system

* Output: log of starting VPN, connection succeeding, client being killed, transfer failing, packet capture showing no data left after the VPN client was killed

* Documentation: how to kill the VPN connection without allowing any clean up routines

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

### 5.2.X **[TR-CONF]** System configuration restored after VPN connection ends

All mitigations are required for all products.

After the user knowingly deactivates the VPN connection, the product shall restore any system configuration it has changes to a state that is functionally equivalent to the state it was in before the VPN connection began.

### 5.2.X **[TR-CONF]** VPN client preserves system configuration

The establishment and ending of a VPN connection shall not result in functional changes to the system configuration unless explicitly authorized by the user.

#### 5.2.X.x **[MI-CONF]** VPN client restores any configuration it changes to its previous state after the VPN connection ends

After the user knowingly deactivates the VPN connection, the VPN client shall restore any system configuration it has changed to a state that is functionally equivalent to the state it was in before the VPN connection began.

* Test: collect the state of all system configuration the product may alter, start the VPN connection, after it reports that it is connected, stop the VPN connection, collect the system configuration again, and compare with previous version, repeat with different system and product configurations until all the possible system configuration changes have been tested

* Result: no functional differences in system configuration

* Output: before and after system configuration, any differences, explanation of why any differences do not affect the function of the system

* Documentation: a list of all the system configuration the product may change, a list of all the different system and VPN configurations that would result in different parts of the system configuration changing

### Authentication

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

All mitigations are required for all products.

**Threat: Untrusted Traffic Ingress** - An unauthorized or unauthenticated external packet, or traffic flagged as malicious by the policy engine, is permitted to route into the VPN client or server, or is permitted to transit the secure tunnel.

### 5.2.X **[TR-NUTI]** No untrusted traffic in the VPN connection

Mitigation(s): 

Traffic from an unauthorized or unauthenticated source shall not be permitted to transit the VPN connection.

Policy-Driven Traffic Exclusion (Firewall Integration): The VPN client and server shall implement or integrate with a policy engine (e.g., a packet filter or firewall) to enforce granular packet filtering by application, port, and endpoint identity.

#### 5.2.X.x **[MI-NUTI-1]** Policy-driven traffic exclusion

- Test: Attempt to send traffic to the VPN client's internal IP address over a port (e.g., SMB/445) explicitly blocked by the central policy engine for the connecting user.

- Result: The VPN client or server shall immediately drop the packet and record a "Policy Deny" event in the monitoring log, preventing the traffic from transiting the tunnel.

- Documentation: Configuration file confirming the deny rule, and the centralized log showing the packet drop event.

- False negative prevention: Attempt to send traffic over a port (e.g., HTTPS/443) that is explicitly permitted by the central policy engine for the connecting user, to verify that legitimate traffic is allowed.

The VPN client and server shall implement or integrate with a policy engine (e.g., a packet filter or firewall) to enforce granular packet filtering by application, port, and endpoint identity, and shall only permit traffic explicitly authorized to transit the VPN connection.

* Test: attempt to send traffic that is explicitly blocked by the central policy engine directly to the network port used to route traffic into the VPN connection on the VPN client, repeat on VPN server

* Result: the packet is dropped, does not enter the VPN connection, and does not exit it

* Documentation: configuration file including the deny rule, packet capture of both incoming and outgoing interface, log message recording the denied traffic

Data Validity and Tunnel Integrity: The VPN server/gateway shall implement data validity checks on all incoming packets to ensure they conform to the expected format and protocol of the restricted network, preventing tunnel misuse.

#### 5.2.X.x **[MI-NUTI-2]** Protocol validity checks

- Test: Inject a packet into the VPN server's receiving interface that contains an invalid IP header or a malformed routing address intended to escape the restricted network space.

- Result: The VPN server shall discard the malformed packet and shall not attempt to forward it onto the internal restricted network, recording a "Traffic Validity Failure" event.

- Documentation: Network capture or log showing the malformed packet being received but not forwarded, and the server log showing the integrity failure.

- False negative prevention: Send a valid, correctly formatted packet over an approved application port to confirm successful routing and delivery within the restricted network.

The VPN client and server shall implement data validity checks on all incoming packets to ensure they conform to the expected format and protocol of the restricted network, preventing tunnel misuse.

**Machine-in-the-Middle (MITM) & Server Masquerading** - An unauthorized server intercepts connection attempts and presents itself as the legitimate VPN server, potentially capturing client-side secrets or routing information.

* Test: inject a packet into the receiving interface of the VPN client or server that contains an invalid IP header or a malformed routing address intended to escape the restricted network space

* Result: the VPN client or server shall discard the malformed packet and shall not attempt to forward it onto the internal restricted network

* Documentation: packet capture on both incoming and outgoing interface, log message or dropped packet counter show the packet was dropped

Mitigation(s): 

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

Pre-Authenticated Server Integrity: The VPN client shall require the use of pre-shared secrets, certificates, or fingerprints to authenticate the server's identity, preventing connection to a masquerading server.

All mitigations are required for all products.

- Test: Set up an unauthorized test server using a self-signed certificate not pre-shared with the client. Configure the client to attempt to connect to this unauthorized server.

- Result: The VPN client shall refuse to connect and report a server authentication failure event, and shall not transmit any confidential information beyond the initial cryptographic handshake necessary for server authentication.

- Documentation: Network capture or log confirming the absence of confidential client data transmission, and the client's connection log showing the cryptographic refusal.

- False negative prevention: Attempt the connection again after correctly pre-sharing the unauthorized server's secret/certificate/fingerprint with the client, verifying that a successful connection is then established.

### 5.2.X **[TR-AUTH]** Authentication of servers

**Credential Harvesting & Plaintext Transmission** - The client transmits user credentials (passwords, tokens, or other secrets) in plaintext before a secure, server-authenticated tunnel has been fully established.

All elements of the product that connect to servers providing security-relevant services shall authenticate the server before using any services from the servers.

Mitigation(s): 

#### 5.2.X.x **[MI-AUTH-1]** Authentication via pre-shared secrets

Confidentiality of Credential Transmission: The VPN client shall not transmit any user credentials or sensitive authentication material in plaintext for any supported authentication method or transport protocol.

The VPN client shall require the use of pre-shared secrets, certificates, or fingerprints to authenticate any security-relevant server's identity, preventing connection to a masquerading server.

- Test: For each supported authentication and transport method (e.g., username/password over UDP, token over TCP), authenticate a test user. Capture the network traffic for the entire authentication process. Search the captured traffic for a plaintext string matching the user's password or token.

- Result: No plaintext string matching the user's credential shall be found in the network capture. The transmission of credentials shall only occur within a cryptographically protected and server-authenticated channel.

- Documentation: A report detailing the authentication method and transport used, and a log analysis report confirming the absence of plaintext credentials in the network capture.

- False negative prevention: Deliberately revert the client or server to an unencrypted transport method (e.g., HTTP for an API call, if applicable) and re-run the test, confirming that the credentials are then visible in plaintext.

* Test: set up an unauthorized test server using a self-signed certificate not pre-shared with the VPN client, configure the client to attempt to connect to this unauthorized server

* Result: the VPN client shall refuse to connect and report a server authentication failure event, and shall not transmit any confidential information beyond the initial cryptographic handshake necessary for server authentication

* Documentation: network capture or log confirming the absence of confidential client data transmission, and the client's connection log showing the cryptographic refusal

**Physical Control Compromise** - An attacker gains unauthorized physical control of the client device (e.g., laptop or mobile phone) and attempts to access the private network using an already authenticated or stored session.

FIXME requirements on RDPS

Mitigation(s): 

#### 5.2.X.x **[MI-AUTH-2]** Transmitted credentials must be encrypted

Session and Authentication Timeouts: The VPN client shall implement an authentication timeout that requires periodic re-authentication of the user for active sessions.

The VPN client shall by default encrypt all transmitted user credentials or sensitive authentication material using for any supported authentication method or transport protocol.

- Test: Establish a successful VPN tunnel. After the configured authentication timeout interval (e.g., 8 hours), attempt to send traffic across the tunnel.

- Result: The tunnel shall be automatically disconnected, and the user shall be prompted to re-authenticate with credentials before the tunnel is re-established.

- Documentation: Centralized security log showing the "Session Timeout" event and the timestamp of the mandatory re-authentication prompt.

- False negative prevention: Attempt to send traffic across the tunnel just prior to the authentication timeout interval (e.g., 7 hours 55 minutes) to verify that the session remains active until the threshold is crossed.

* Test: for each supported authentication and transport method, authenticate a user while capturing the network traffic for the entire authentication process, search the captured traffic for a plaintext string matching the user's password or token

* Result: no plaintext string matching the user's credential is found

* Documentation: the authentication method and transport used, a packet capture, the plain text of the user's credential(s), and the output of a search for the credential(s)

* False negative prevention: deliberately revert the client or server to an unencrypted transport method and re-run the test, confirming that the credentials are then visible in plaintext

#### 5.2.X.x **[MI-AUTH-3]** Authentication timeout

The VPN client or server shall implement an authentication timeout that requires periodic re-authentication of the user for active sessions.

/JR - Wasn't really sure what to do with this one.

* Test: configure the authentication timeout, establish a VPN connection, after the configured authentication timeout interval, attempt to send traffic via the VPN connection

* Result: no traffic is transmitted until the user has re-authenticated

* Documentation: log messages showing VPN connection establishment, disconnection, re-authentication, packet capture with timestamps synchronized with log messages

Threat: attacker gains physical control of device and duplicates the storage containing credentials

#### 5.2.X.x **[MI-AUTH-4]** Cloned credentials detection

Note: this is also just an annoying usability problem that happens by accident with images and cloning

The VPN client or server shall detect when multiple clients are using credentials that should be unique to a VPN client and notify the users of both VPN clients.

  - TR: detect identical clients

  - TR: store credentials in secure TPM

  - TR: document what the user has to do to avoid this

  - TR: document that this product isn't appropriate for use case or doesn't provide this thin

### Logging

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

| Risk factors | Requires mitigations |

|--------------|----------------------|

| any          | AUTH-1, AUTH-2       |

| DAT >= 1     | AUTH-3, AUTH-4       |

Aki is doing this one probably:

### Logging

Threat: someone (maybe VPN provider) gets access to remote logs

David from Crab Nebula is doing:

Good source of VPN leak testing: https://github.com/expressvpn/expressvpn_leak_testing

- DNS Leaks to local network

  - misconfiguration

  - bugs in software

- Firewalls, routing, DNS configuration not correctly

  - TR: restore

## 5.3 [KEV] Known exploitable vulnerabilities

#### Threat: Unencrypted traffic exposes private information

Mitigation: