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
- 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
- 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)
## 5.3 [KEV] Known exploitable vulnerabilities
#### Threat: Unencrypted traffic exposes private information
## 5.4 [CONFIG] Configuration
Mitigation:
### 5.4.1 [CONFIG-1] Encryption by default
: Encryption by default
VPNs **shall** be released to the market with encryption enabled.
#### 5.4.1.1 Requirement
Test:
Result:
Documentation:
False negative prevention:
If a VPN product is capable of encrypting traffic between points, it **shall** be released to the market with encryption enabled.
: Warning when disabling encryption
If a VPN product is capable of disabling encryption, it **shall** provide a warning against disabling encryption
#### 5.4.1.2 Rationale
Test:
Result:
Documentation:
False negative prevention:
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
- 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.8 [TKTK] Data minimization
Personal VPNs: do not log traffic activity
Personal VPNs: don't log traffic activity
## 5.9 [TKTK] Availability protection
## 5.10 [TKTK] Impact minimization
Any logged traffic activity is subject to replay exposure, protect it jealously and rotate logs frequently
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
- rotate logs that may expose proprietary data frequently
