@@ -91,37 +91,61 @@ Areas for Technical requirements to be written:
### Authentication
Joseph Rotolo is doing:
**Threat: Untrusted Traffic Ingress** - An unauthorized or unauthenticated external packet, or traffic flagged as malicious by the policy engine, is permitted to route into the VPN client or server, or is permitted to transit the secure tunnel.
Threat: 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)
Mitigation(s):
Policy-Driven Traffic Exclusion (Firewall Integration): The VPN client and server shall implement or integrate with a policy engine (e.g., a packet filter or firewall) to enforce granular packet filtering by application, port, and endpoint identity.
- Test: Attempt to send traffic to the VPN client's internal IP address over a port (e.g., SMB/445) explicitly blocked by the central policy engine for the connecting user.
- Result: The VPN client or server shall immediately drop the packet and record a "Policy Deny" event in the monitoring log, preventing the traffic from transiting the tunnel.
- Documentation: Configuration file confirming the deny rule, and the centralized log showing the packet drop event.
- False negative prevention: Attempt to send traffic over a port (e.g., HTTPS/443) that is explicitly permitted by the central policy engine for the connecting user, to verify that legitimate traffic is allowed.
Data Validity and Tunnel Integrity: The VPN server/gateway shall implement data validity checks on all incoming packets to ensure they conform to the expected format and protocol of the restricted network, preventing tunnel misuse.
- Test: Inject a packet into the VPN server's receiving interface that contains an invalid IP header or a malformed routing address intended to escape the restricted network space.
- Result: The VPN server shall discard the malformed packet and shall not attempt to forward it onto the internal restricted network, recording a "Traffic Validity Failure" event.
- Documentation: Network capture or log showing the malformed packet being received but not forwarded, and the server log showing the integrity failure.
- False negative prevention: Send a valid, correctly formatted packet over an approved application port to confirm successful routing and delivery within the restricted network.
**Machine-in-the-Middle (MITM) & Server Masquerading** - An unauthorized server intercepts connection attempts and presents itself as the legitimate VPN server, potentially capturing client-side secrets or routing information.
Mitigation(s):
- authentication failure
Pre-Authenticated Server Integrity: The VPN client shall require the use of pre-shared secrets, certificates, or fingerprints to authenticate the server's identity, preventing connection to a masquerading server.
- Test: Set up an unauthorized test server using a self-signed certificate not pre-shared with the client. Configure the client to attempt to connect to this unauthorized server.
- Result: The VPN client shall refuse to connect and report a server authentication failure event, and shall not transmit any confidential information beyond the initial cryptographic handshake necessary for server authentication.
- Documentation: Network capture or log confirming the absence of confidential client data transmission, and the client's connection log showing the cryptographic refusal.
- False negative prevention: Attempt the connection again after correctly pre-sharing the unauthorized server's secret/certificate/fingerprint with the client, verifying that a successful connection is then established.
**Credential Harvesting & Plaintext Transmission** - The client transmits user credentials (passwords, tokens, or other secrets) in plaintext before a secure, server-authenticated tunnel has been fully established.
Mitigation(s):
Confidentiality of Credential Transmission: The VPN client shall not transmit any user credentials or sensitive authentication material in plaintext for any supported authentication method or transport protocol.
- Test: For each supported authentication and transport method (e.g., username/password over UDP, token over TCP), authenticate a test user. Capture the network traffic for the entire authentication process. Search the captured traffic for a plaintext string matching the user's password or token.
- Result: No plaintext string matching the user's credential shall be found in the network capture. The transmission of credentials shall only occur within a cryptographically protected and server-authenticated channel.
- Documentation: A report detailing the authentication method and transport used, and a log analysis report confirming the absence of plaintext credentials in the network capture.
- False negative prevention: Deliberately revert the client or server to an unencrypted transport method (e.g., HTTP for an API call, if applicable) and re-run the test, confirming that the credentials are then visible in plaintext.
**Physical Control Compromise** - An attacker gains unauthorized physical control of the client device (e.g., laptop or mobile phone) and attempts to access the private network using an already authenticated or stored session.
Mitigation(s):
Threat: Machine-in-the-middle, 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
Session and Authentication Timeouts: The VPN client shall implement an authentication timeout that requires periodic re-authentication of the user for active sessions.
- Credential harvesting
- phishing
- not our problem
- transmitting credentials in plain text
- TR: don't transmit sensitive stuff in plain text
- Test: Establish a successful VPN tunnel. After the configured authentication timeout interval (e.g., 8 hours), attempt to send traffic across the tunnel.
- Result: The tunnel shall be automatically disconnected, and the user shall be prompted to re-authenticate with credentials before the tunnel is re-established.
- Documentation: Centralized security log showing the "Session Timeout" event and the timestamp of the mandatory re-authentication prompt.
- False negative prevention: Attempt to send traffic across the tunnel just prior to the authentication timeout interval (e.g., 7 hours 55 minutes) to verify that the session remains active until the threshold is crossed.
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
Threat: attacker gains physical control of 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: provide feature to revoke device
/JR - Wasn't really sure what to do with this one.
Threat: attacker gains physical control of device and duplicates the storage containing credentials
