Quick and dirty swap of parts 1 and 2

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

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

## 5.1 General

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

- Traffic hijacking

  - 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

- Remote code execution

  - 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

- utter betrayal

  - 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

- unauthorised filtering or tampering of traffic (mitm)

common CVE: auth bypass

- De-anonymize using stuff in the unencrypted header that is unique to user

  - Document the purpose of each field and whether or not it could be used to identify the user, by itself or in combination with other fields

  - Reduce the number of fields to the point where they cannot uniquely identify more than 1% of the total users? (or zero fields)

  - 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.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: do not log traffic activity

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.11 [TKTK] Limit attack surface

- rotate logs that may expose proprietary data frequently

## 5.12 [TKTK] Logging and monitoring mechanisms

Basic level: DON'T