Move part 2 clause 5 document to new repo

# 5 Requirements specifications

does split tunneling pose a security threat relevant to this document? maybe in the documentation section? 

## 5.1 General

## 5.2 Technical security requirements specifications

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

> Example technical security requirements can be found in related standards, such as:

>

> - Protection profiles for similar categories of product

> - [EN-18031-2 (Radio Equipment Directive)](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09/CEN-CLC-JTC%2013-WG%209_N433_EN%2018031%20series.zip)

> - Other vertical standards drafts in [ETSI GitLab](https://forge.etsi.org/rep/cyber/stan4cr2)

> - Other vertical standards drafts as [contributions to verticals meetings on the ETSI Portal](https://portal.etsi.org/Meetings.aspx#/)

> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)

> - ENISA's [CRA Requirements Standards Mapping](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf)

**TODO: specific known attack vectors to apply to appropriate requirements**

- Credential harvesting

- Traffic hijacking

- Circumventing encryption

- Unauthorized reads of config data

- Remote code execution

- DNS Leaks to local network

- Allowing untrusted traffic

- Traffic validity failure

- authentication failure

- observation or disclosure of the user's online activity by an unauthorized and/or malicious party, including delayed disclosure

- config error causing misrouting of traffic

- utter betrayal

- unauthorized use of exit node (\*\* by service provider)

- unauthorised collection of PII by client

- unauthorised filtering or tampering of traffic (mitm)

## 5.3 [KEV] Known exploitable vulnerabilities

## 5.4 [CONFIG] Configuration

### 5.4.1 [CONFIG-1] Encryption by default

#### 5.4.1.1 Requirement

If a VPN product is capable of encrypting traffic between points, it **shall** be released to the market with encryption enabled.

#### 5.4.1.2 Rationale

VPNs carry with them an expectation of secure communication over the wire.

#### 5.4.1.3 Guidance

#### 5.4.1.4 Assessment criteria

### 5.4.2 [CONFIG-2] User intent

#### 5.4.2.1 Requirement

User interfaces, especially in regard to settings, shall be designed in a manner that prevents unintentional disabling of default security features.

### 5.4.3 [CONFIG-3] Validation

#### 5.4.3.1 Requirement

User-manageable VPN settings shall be configurable in a manner that introducing unexpected punctuation or other formatting errors cannot result in a failure of encryption.

## 5.5 [ACM] Authentication and access control mechanisms

## 5.6 [TKTK] Integrity protection

## 5.7 [TKTK] Confidentiality protection

## 5.8 [TKTK] Data minimization

Personal VPNs: do not log traffic activity

## 5.9 [TKTK] Availability protection

## 5.10 [TKTK] Impact minimization

Go into enterprise security here, specifically describe potential mitigations that may be complimentary to VPN

## 5.11 [TKTK] Limit attack surface

## 5.12 [TKTK] Logging and monitoring mechanisms

Basic level: DON'T

Middle & Critical level: LOG CONFIG CHANGES

- log access attempts

- log config changes

## 5.13 [TKTK] Deletion mechanisms

## 5.12 [TKTK] Other product's technical requirements specifications