Delete EN 304 620 Part 2

## EN 304 620: Virtual Private Networks (Part 2)

Welcome. Here you will find the draft Standards for this vertical, as well as an issue tracker where you can submit comments, and discuss the standard.

## Disclaimer

> [!caution]

> Exercising one of the Principles of international standardization – Openness – and taking it to a different level, ETSI is piloting informal public consultations of the vertical standards in support of the Cyber Resilience Act at a much earlier stage than it is usual in the standardization world. In this context, please keep in mind that the standard draft herein is an INTERIM DRAFT, which expectably will be subject to substantial changes before its target publication date in the second semester of 2026. This INTERIM DRAFT document is provided for information and is for future development work  within the ETSI Technical Committee CYBER EUSR Working Group (CYBER-EUSR) only. ETSI and its Members accept no liability for any further use/implementation of this Specification. Approved and published specifications and reports shall be obtained exclusively via the ETSI Documentation Service at http://www.etsi.org/standards-search

## Commenting guidelines

Your comments to improve this early draft are very welcomed. To ensure the effectiveness of your contribution, please make sure to include the following elements in your comment:

1. Clear identification of the section of the draft your comment is referring to.

2. Objective proposal to delete content, add content or substitute content.

3. Concrete contribution (exact content you suggest including in the draft as an addition to, or in substitution of, existing content).

4. Brief rationale to justify the proposal (e.g. why the suggested content should be added an/or the existing content should be deleted or substituted).

Please note that comments without concrete contributions will be noted but not acted upon by ETSI CYBER-EUSR. We trust and value your expertise and therefore expect you to take this opportunity to proactively contribute to solving the issues you find while analysing this early draft.

## How to submit comments

You can submit comments from the issue tracker:

1. In the sidebar, click the "Issues" button.

2. Check that the issue you are raising is not already in the list.

3. Click the blue "New Issue" button.

4. Enter a descriptive title for your comment, then select "Vertical Standard Comment" from the templates menu, and fill in the template.

  - You can find the line number by Opening the standard from the repository and switching to the "Code" view, using the toggle on the right hand side.

  - For the version number, please use the string of letters and numbers in the box to the left of the "History" button at the top of this page. You can click the clipboard icon to automatically copy it.

5. Please remember to **add a label** indicating the type of issue you are opening, and use the template. There are three types of issue

- **Discussions**: for discussion of overarching issues not related to specific elements in the draft standard, or a place for rapporteurs to ask questions to the community.

- **Editorial Comment**: for issues that concern Grammar and Wording of the Standard, and not the technical substance.

- **Technical Comment**: for issues with the technical substance of the standard.

6. Once you are done click "Create Issue". Other users will be able to comment and upvote or downvote the issue you have raised.

> [!warning]

> This repository does not accept merge requests. Please only use the issue tracker.

This document has been made obsolete by its subject matter being covered in [EN 304 620: Virtual Private Networks (Part 1)](https://labs.etsi.org/rep/stan4cra/en-304-620-1/)

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

*******

Example requirement format via NI

Threat: [specific technical failure event]

Mitigation(s): [there may be one or several, some or all may be required]

[action to take to mitigate]:

Test: [a step or list of steps to take]

Result: [expected output of above test]

Documentation: [description of how test was executed]

False negative prevention: [a step or list of steps to take in order to trigger the opposite result]

[a different action to take to mitigate]:

Test: [a step or list of steps to take]

Result: [expected output of above test]

Documentation: [description of how test was executed]

False negative prevention: [a step or list of steps to take in order to trigger the opposite result]

*******

Example requirement via NI

Threat: Out-of-bounds memory access caused by unvalidated input in incoming packets

Mitigations: Select from the following depending on use case/risk factor (TBD)

Fuzz packet input with memory use checker

Test: run a packet fuzzer on instrumented firmware in simulator with memory access checking until it reaches NN% code coverage (NN based on overall risk)

Result: simulator shows no out-of-bounds memory access

Documentation: what simulator and fuzzer was used, with what configuration

False negative prevention: create a firmware version that DOES allow an out-of-bounds write and show that it is logged by the simulator

Source code analysis

Test: run a source code analyzer that statically checks for out-of-bounds memory access

Result: analyzer results shows no out-of-bounds memory access

Documentation: source code, what source code analyzer was used, what parameters, any explanations of false positives or annotations in the source code that are instructions to the analyzer

False negative prevention: create a firmware version that DOES allow an out-of-bounds write and show that the analyzer catches it

Implement in a memory-safe language

Test: examine source code and firmware to see if they are in a memory-safe language

Result: source code is in a memory-safe language, binary appears to be built from the source, any part of the source code that allows unsafe memory access has documentation explaining why it does not affect memory safety

Documentation: source code, how to copy firmware from device

*****

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

- Credential harvesting

  - phishing

    - not our problem

  - transmitting credentials in plain text

    - TR: don't transmit sensitive stuff in plain text

	Requirement: for each method of authenticating and each transport method, authenticate, capture the traffic, search for a string matching the plain-text credentials. and document it all

  - Logging

    - TR: send logs to a remote server

  - compromised devices

    - TR: threat detection (traffic analysis)

      - require AV, XDR, SIEM, SOAR, etc. or provide it yourself

	  - there is an API or something

	  - it must provide security at X level

	  - ??? how to make this connect to use case/security profiled/overall risk? Overall risk score?

	  - If you see a bunch of data being exfiltrated through a laptop, it's suspicious - this can be provided by a SIEM, firewall, etc.

  - connecting to masquerading server

    - TR: secrets or certificates or fingerprints pre-shared or transmitted by alternate secure channel

	  Test: Set up an unauthorized server, send it the traffic from the clients, capture the traffic from the clients and see if they sent anything they shouldn't have, check if the clients refused to connect

	- TR: client authentication cannot send any confidential information to the server before the client has authenticated the server

      Test: Same as above, with all authentication methods

  - weak encryption

    - TR: use strong encryption (ref existing standards)

  - saving traffic and decrypting later

    - TR: use strong encryptiong (same)

  - using compromised keys

    - TR: key rotation

    - TR: allow for forced key expiry

    - TR: provided feature to revoke keys in service

  - physical possession of authorized device

    - TR: auth timeout (periodic re-auth)

    - TR: require re-auth after sleep of device

    - TR: encrypt stored credentials and use some derived thing with a timeout (password vault kind of stuff)

    - TR: provided feature to revoke device

  - duplication of entire hard disk

    - TR: detect identical clients

    - TR: don't store credentials in secure TPM

  - TR: don't use reusable credentials, use passkey etc.

  - 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 thing

- TR: data validation before encryption (todo)

- TR: look at all the traffic generated and see if there is anything in the clear, going to the wrong place etc.

- Traffic hijacking (DoS)

  - bad normal internet routing (DoS)

    - TR: include traceroute style debug info

  - providing wrong configuration info from masquerading servers

    - TR: require server certificate (TLS, etc.) (pre-shared, in configuration)

- Circumventing encryption

   - note: two TSs in ETSI on encrypted traffic are almost done - Galina knows this, ZT-Kipling method? (sp), probably can reference this

   - see previous TRs

- Unauthorized reads of config data

  - TR: stored in form that can only be read with authorization

  - TR: do not transmit in the clear

- Remote code execution (on client, server, element)

  - TR: mitigation: limit privileges of VPN software

  - TR: split into smaller pieces with lower privileges on some

  - TR: fuzz testing of input data?

  - note: secure design/devel outside scope of this part unless testable on product

- DNS Leaks to local network

  - misconfiguration

  - bugs in software

  - bad DNS config served

  - TR: look at traffic

  - TR: configuration checks

  - TR: warn user???

  - TR: client check DNS configuration and warn or disable?

  - TR: device posture thing or integrates with other tools that check configuration

  - TR: integrate with things that monitor traffic

- Allowing untrusted traffic

  - allowing external traffic to route into VPN client or server

  - failure to exclude by application or port or endpoint

  - TR: policy engine allowing configure of packet filter or firewall (may be external product)

  - TR: validating data you are sending

  - TR: authentication of clients (already covered)

- Traffic validity failure

  - FIXME: see above we think? correct if not duplicate

- authentication failure

  - FIXME: covered above?

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

  - traffic analysis

  - leaks in general (DNS, logs on end-user device or servers, initial connection, error-related packets, partial information disclosure in packets)

  - see above

- config error causing misrouting of traffic

  - see above, but add specific for misrouting?

- utter betrayal by the provider

  - note: only can work if there is a third party thing to test against

  - TR: third party checker/validator

  - TR: third party AV, etc.

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

  - see above

- unauthorised collection of PII by client

  - TR: examine data sent by VPN software that is "metadata" (not created by user)

- unauthorised filtering or tampering of traffic (pitm)

  - see previous TRs

- installer vulnerabilities e.g. put wrong library in path

  - TR: validate things needed by the installer with a hash or similar

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

- Requirement: administrators must be able to revoke and regenerate credentials, individually or in bulk, in case of exploit

- Disable remote access for administrators?

- MFA, obviously

## 5.6 [TKTK] Integrity protection

## 5.7 [TKTK] Confidentiality protection

## 5.8 [TKTK] Data minimization

Personal VPNs: don't log traffic activity

Any logged traffic activity is subject to replay exposure, protect it jealously and rotate logs frequently

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

- rotate logs that may expose proprietary data frequently

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