The VPN provider shall offer anonymous payment methods.
Test: Go to the provider's website, create an account
Result: There are options available that do not require any PII
Output: Screenshot of a record of payment by anonymous method
### 5.2.X **TR-TRAF**: No traffic through the node you haven't explicitly approved
The VPN provider shall not route traffic through the endpoint from sources/destinations other than the endpoint without the user's explicit informed consent, and it shall not be necessary for the use of any unrelated function.
#### 5.2.X.x **MI-TRAF-1**:
The VPN provider shall not implement the capability for routing traffic through endpoints.
* Test: Connect an endpoint and capture the traffic on all interfaces
* Result: No forwarded traffic
* Output: Packet capture with labeling of packets as to origin, etc.
* Test: Look at configuration options???
* Result: No option to allow forwarded traffic
* Output: Configuration stuff???
#### 5.2.X.x **MI-TRAF-2**:
The VPN provider shall disable by default the capability to forward traffic through an endpoint.
* Applicability: If there is a feature allowing traffic forwarding
* Test: Connect an endpoint and capture the traffic on all interfaces, then enable it, then capture again
* Result: No forwarded traffic, then forwarded traffic
* Output: Packet capture with labeling of packets as to origin, etc.
#### 5.2.X.x **MI-TRAF-3**:
The VPN provider shall alert the user if traffic can be forwarded through the endpoint.
* Applicability: If there is a feature allowing traffic forwarding
* Test: Connect an endpoint, enable the forwarding through it
* Result: Some indication to the user such as a UI change or sound or log message or notification
* Output: Record of UI change
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
| Risk factors | Requires mitigations |
|--------------|------------------------------|
| any | TRAF-2, TRAF-3 if applicable |
| DAT >= 2 | TRAF-1 |
### 5.2.X **TR-XXXX**:
#### 5.2.X.x **MI-XXXX**:
_Description of mitigation in "shall" format_
* Test:
* Result:
* Output:
Optional:
* False positive test:
* Requirements:
* Documentation:
> Copy-n-paste mitigation format
### 5.2.X **TR-NPII**:
The VPN provider shall not collect PII without explicit authorization.
#### 5.2.X.x **MI-NPII-1**:
Document all data sent to the VPN provider, label it all as to PII or not, and justify all PII sent, and document if it is kept or not, for how long, who it is shared with, how it is stored, how the user consents to it, record of user consent.
* Test: Packet capture during typical hour of use
* Result: Only PII described is sent under conditions documented
* Output: Packet capture
#### 5.2.X.x **MI-NPII-2**:
VPN provider shall not send PII outside of the endpoint at all.
* Test: Packet capture during typical hour of use
* Result: No PII is sent
* Output: Packet capture
## Notes - will go away in final version
### Don't write generic technical requirements
@@ -189,14 +272,7 @@ The generic cross-vertical versions of the following requirements are a work in
### Areas of technical requirements still to be written
### Logging
Threat: someone (maybe VPN provider) gets access to remote logs
- TR: don't remotely log sensitive info
- TR: don't remotely log identifying info
- TR: don't remotely log anything
- TR: delete remote logs frequently
### TRs whose solution is logging
Threat: someone is trying to login to your VPN
@@ -210,8 +286,34 @@ Threat: attacker deletes local logs to hide activity
- TR: send selected logs to a remote server
### Segmentation
done: clients not connecting to each other by default
### Betrayal by VPN provider
- 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.
- 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
What is even legal for the user to give up in exchange if informed properly?
Threat: someone (maybe VPN provider) gets access to remote logs
- TR: don't remotely log sensitive info
- TR: don't remotely log identifying info
- TR: don't remotely log anything
- TR: delete remote logs frequently
Threat: using your connection unauthorized to transmit data
- TR: don't send data through without user's knowledge <- what is sufficient?
### Transmitting data in the clear
- compromised devices
@@ -264,16 +366,6 @@ Threat: attacker deletes local logs to hide activity
- 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
@@ -284,26 +376,12 @@ Jan from BSI is doing:
#### Threat: Unencrypted traffic exposes private information
Mitigation:
: Encryption by default
VPNs **shall** be released to the market with encryption enabled.
Test:
Result:
Documentation:
False negative prevention:
: Warning when disabling encryption
If a VPN product is capable of disabling encryption, it **shall** provide a warning against disabling encryption
Test:
Result:
Documentation:
False negative prevention:
User interfaces, especially in regard to settings, shall be designed in a manner that prevents unintentional disabling of default security features.
Jeroen Janssen <jeroen@laylo.nl>