VPN, vs a different implementation of VPN, vs secure web services... a question of trust?

Often, a VPN is seen a security panacea; a cure for all remote-access security ills.

Let's assume we have to deliver a service with providing super secret information outside of the safety of our LAN. That's a need for a VPN... or is it?

Here are my rambling thoughts on the subject, read them, enjoy them... I'm taking a devil's advocate view here somewhat, and this is not intended as a fully encompassing paper on the subject either. I expect I may have left gaps and you may have your own thoughts, feel free to add them.

Lets get going and explore this idea a little, starting with the traditional...

...VPN delivered to the fully managed corporate laptop. This is the method often seen as the most secure; you manage the assets, their patching, their hardening. You have a record of the assets in your CMDB, you know what operating system they're running. The users are managed via your global directory. They connect using strong IPsec or TLS, authenticate using 2FA and once connected they're isolated from their local LAN... everything is cool, right? Maybe. Let's consider a few things:

- Have you designed your hardening, security baselines and endpoint protection based on the assumption that you are always dealing with an asset located at a desk in your office?
- Do those controls above work in the same way when the asset is removed from the office and connected via VPN? Do you AV updates fail because the remote user only has access to a slow link?
- Can you securely support the remote device when its out in the field, or do you need to revert to using non-random passwords for local accounts for VPN users as your find yourself dealing with incidents that need to be resolved remotely before the VPN tunnel can be established?
- You have made assumptions about your users, based on their presence in the office. In the office they must pass through secure locked doors, display ID badges, and face colleagues who would quickly be able to identify if they were no who they claimed to be. The only method you may have to verify a remote user is the fact that they have authenticated into the VPN itself, by which time they may already have full LAN access. You trust them as you would if they were in the office based solely on their ID and this authentication process?
- Do you hang more IDS/IPS systems on the back of your incoming VPN connections, or do you view traffic from the VPN connections no differently to that from LAN connected devices?
- How often is the managed asset connected to untrusted networks and not connected to the VPN? Your users don't know how to get around proxy settings, do they? If they do, what do they do once those settings are bypassed (sit on open hotel WiFi torrenting movies, perhaps?)

Next up, VPN services provided by more advanced clients which will probably support features such as client posture checking, to non managed non company owned devices, again either delivered via strong IPsec or TLS:

-We're dealing with a very different animal now. We no longer have our nicely managed assets to remotely connect into our LAN.
-Whereas in the example above we had a high level of trust of the devices we were allowing to remotely connect to our LAN, that trust is now much, much lower.
- On advanced VPN clients, we may have the ability to check the connecting device's patch level, AV status, OS version and service pack levels, IOC for various types of malware all *prior* to the device being allowed to connect; I'm willing to bet that's more security assessment than you perform on your managed assets after they've been connected to your LAN for a year...
- Despite all the posture checking, advanced threats could still be present on a non-managed device which could evade even the smartest VPN client.
- Using a TLS VPN? You've probably chosen a more random port than 443, and because you're not offering services to browsers, you can enforce this pretty well. You 1, script kiddies 0.
- Unless you require registration of new endpoint devices, you lose the ability to link a user to a device; e.g. you can not assert that Gary only uses his MacBook, ID=blah to connect, then a connection initiated by Mallory using stolen credentials/tokens from a different device (which may be perfectly capable of passing posture checking) is potentially indistinguishable from a legitimate connection.

And finally, delivering those services via a HTTPS web session, again summing you're doing all the cryptography and implementation right:

- This is the least trusted option; you're offering up web services on 443, you'll be seeing every probe, skiddie attack, bot, spider, etc out there.
- And leading on from that point, you'll be expecting them, and your service will be hardened accordingly.
- You will possibly have made a distinction between a valid user of your network/LAN, and a valid user of the web application, i.e. using different credentials and authentication systems for both.
- A web server, unlike a VPN, will be offering the required service with a much greater segregation from your LAN. If we consider the traditional layered DMZ, your web server will be sitting at least 2 domains away from the interesting stuff on your LAN, hopefully with firewalls and IDS at each boundary crossing.
- You're gaining granularity. No need to expose a LAN full of 50 services to those remote users who only need 5.
- Let's assume I'm Mallory. Armed with my rubber hose, I walk up behind the user sat in the cafe accessing your services and kosh them over the head. I now I have full access to their endpoint (Ok, ok... this exact situation is unlikely, so lets just call it a "total physical endpoint compromise" we're dealing with here). Assuming we're using a VPN, I may have full LAN access. If our poor legitimate user was logged into a secure web service, I only have access to the data permitted to be accessed from the service in question; to get any further into the network, I'll need to exploit the app, get root on the host, move laterally around the web stack, break through risk domains etc etc... and that should be a) hard and b) detectable.
- Your services are subject to the same attacks as any other web service, but these attack vectors are well publicised and the skills and tools to defend against them are commonplace, chances are you'll be routing your connections for your confidential services via the same reverse proxies and WAFs as the rest of your inbound web traffic; well monitored, well understood. VPN security experts? They're less common.

Trust seems to be the key factor here: Are we implying trust where there needs to be less trust? Are we trusting endpoints, or users? Do we apply the same level of trust to a user on the road as to one in the office? Does successful authentication imply that we now trust whomever has done that authentication? As trust goes down, our security controls must come up to deal with that greater risk. Trust can be misplaced, and like anything you misplace, the less you start with, the less you have to lose.