From my experience corporate VPNs exist to allow employees to access internal resources remotely. They aren't typically used for security although they can provide some form of security for remote workers.

Of course they're used for security -- VPNs are a hassle for users and admins, it'd be easier for everyone (except security!) if all internal apps were just public on the internet.

VPNs are a band-aid / work-around for "we don't have strong authentication and authorization on all services". That's fine, not everyone can do the latter, and they can provide some safety v.s. the anonymous attacker case. But too often they lure IT environments into a false sense of security.

You're ignoring the reality that most enterprise software is a tire fire (from a security standpoint) and that it's not feasible to secure hundreds (or even dozens!) of enterprise apps.

VPN's are the enabler that ensures status quo remains.

I agree — band-aids aren't per-se a bad thing. However, a VPN isn't the ideal end state. Even if you can't modify the underlying application, the goal should be "wrap in a reverse-proxy that handles authn / some-amount-of-authz so you can minimise the risk".

VPNs handle network security, but don't protect you against an attacker able to compromise an endpoint in your corporate environment.

Can you propose an alternative solution?

Some protocols/services are designed with a local network in mind and would require modifications to work on the internet. A VPN is invisible to the apps and can easily save a lot of work in a large IT environment with numerous internal services.

You're probably alluding to things like PXE or mDNS, or some proprietary industrial control protocols? This is true but deploying a VPN to cover them is a pretty high price to pay in operational complexity and security cost. There's usually other ways to address the task at hand.

How is a local network different from the internet, presuming there is no firewall or nat between the client and the server ?

On a local network, you make the assumption that there are only authorized users.

Uh oh, that assumption is a big no no.

depends

Can you elaborate? Honestly asking.

I wouldn't recommend it with PCs, notebooks, phones, random crapware, but:

When you control¹ all the devices on the network, the network is small enough and the danger from the non-authenticated protocols isn't too high, then I would say it is reasonable to assume being present in the network is sufficient authentication. Not saying it could not be improved, but there are probably many more pressing concerns.

¹ you don't fully control anything anymore, but you're not going to fix that either.

The air gapped power plant networks I work on have unused Ethernet ports shut off and the ones in use only accept traffic from the MAC address of the device that is meant to be there. So you can’t just show up and plug in.

Thanks a lot. That gave some perspective. I'll keep that in mind.

> presuming there is no firewall or nat between the client and the server

That's one of the issues though. If you can't access a machine via its internal IP, many useful usage patterns break.

Someone complained that the issue is that services aren't secure, but there's more to it than that: good security depends on defense in depth, and firewalls are an important part of that.

Yep, using VPNs makes the organisation lazy in security. But insecure apps in a "company internal network" is still not ok IMO. In the exceptional cases that you can't fix, the way to go is separate dedicated environments for the risky apps, and disconnected from central services.

Honestly, isn’t 90% of compliance like that? Checking boxes...

The thing is, people are very good at checking boxes, and not very good at remembering important things.

So while it may seem inane, plain old checking boxes is almost certainly part of a good strategy for dealing with tedious, repetitive tasks where one error can cause serious issues - and this kind of security is probably one of those.

Obviously, it's not enough, nor an excuse to turn off your brain - but it's a pretty proven behavioral pattern.

Sure I mean it’s a lot of CYA regulation-wise. Because if you chose a solution which is arguably better but not part of the list and the one on the list which is a worse solution isn’t checked, well you’d better have your resume ready when something happens.

Flying is a great example of 'checking boxes' saving lives.

Having worked a lot with security compliance, I'll say there are two types of things you do:

1. The things for compliance.

2. The things for security.

Only rarely does something fit in both categories.