_Table C.2 — Security profiles mapped to mitigations_
> TODO-HAS: Turn below threats into formal threats and mitigations
Threat: someone is trying to login to your VPN
- TR: log access attempts
Threat: attacker has access to your VPN client/network, changes config
- TR: log configuration changes
Threat: attacker deletes local logs to hide activity
- TR: send selected logs to a remote server
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?
Threat: Transmitting data in the clear
- using compromised keys
- TR: key rotation
- TR: allow for forced key expiry
- 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
- TR: integrate with things that monitor traffic
Threat: Unencrypted traffic exposes private information
: Warning when disabling encryption
If a VPN product is capable of disabling encryption, it **shall** provide a warning against disabling encryption
User interfaces, especially in regard to settings, shall be designed in a manner that prevents unintentional disabling of default security features.
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.
- 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
# Annex D (informative): Change history
The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.
@@ -981,65 +981,3 @@ _Description of mitigation in "shall" format_
| Security Profile | Requires mitigations |
|----------------------|------------------------|
| | |
## Notes - will go away in final version
### Areas of technical requirements still to be written
### TRs whose solution is logging
> TODO-HAS: Writing logging requirements and related threats
Threat: someone is trying to login to your VPN
- TR: log access attempts
Threat: attacker has access to your VPN client/network, changes config
- TR: log configuration changes
Threat: attacker deletes local logs to hide activity
- TR: send selected logs to a remote server
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
- using compromised keys
- TR: key rotation
- TR: allow for forced key expiry
- 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
- TR: integrate with things that monitor traffic
#### Threat: Unencrypted traffic exposes private information
: Warning when disabling encryption
If a VPN product is capable of disabling encryption, it **shall** provide a warning against disabling encryption
User interfaces, especially in regard to settings, shall be designed in a manner that prevents unintentional disabling of default security features.
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.
- Requirement: administrators must be able to revoke and regenerate credentials, individually or in bulk, in case of exploit