Internal networks only accessible via VPN is considered an anti-pattern now in terms of security. It puts authorization firmly on the VPN. If the account with VPN access is compromised, then the attacker has full access to these sensitive systems.
This hack probably underscores the importance of zero trust. Although if the system is compromised from within (like this hack is) then there is not much you can do.
I would be curious as to who is citing that using a vpn is some "anti-pattern", to what? Not protecting your network accessible assets?
If you have the means, certainly use a corporate/smb/personal vpn. It is one layer in a multitude of layers you should be using to protect your network.
Its not as if once you achieve vpn access you have no other authz gates to internal applications. Its a "great filter" to help narrow the possible avenues of attack and it works. If your inner layer of authz fails its not the vpn's fault.
Whats your alternative? Just make every application and network endpoint publicly accessibly on the internet?
Yes, basically you should consider all networks untrusted including your internal network. You can still have a VPN but it shouldn't be the thing that protects the services inside your corp net because if it is then any breach means the intruder gets access to all your stuff.
This thread is a bit confusing to me. Have we moved past layered security for some reason?
The purpose of a VPN was never supposed to be the authentication layer to internal services. It's just a layer of security that makes it more difficult to carry out some types of attacks; thus increasing security defenses of an organization. Assuming that it has been breached is good practice, but doesn't mean that there's no point to it.... Unless layered security has been overturned?
The issue is that, for any company without thousands of employees (heck, probably even some of these are guilty), the VPN is often the only barrier to the entire network. The BeyondCorp model makes you explicitly specify "John can access support.corp.com but not admin.corp.com", while setting up these explicit checks is the exception for VPN-based access, not the norm (and sometimes it isn't even done right - eg. relying on DNS filtering).
> The issue is that, for any company without thousands of employees (heck, probably even some of these are guilty), the VPN is often the only barrier to the entire network.
Sorry, but what? I've worked in multiple small companies where the we where less than 5 system administrators and inside the vpn we had encrypted traffic and ldap auth on everything. It's a few days job for a single person to set everything up this way with open source tools that are extremely well known and documented.
For real, no wonder security is such a crap fest, when we have people repeating this BS that "VPN is an antipattern"
I'm all for debate but some things are close and shut. Yes, don't trust your user just because they are in the internal network, but no, that doesn't mean everything has to be visible from the outside.
If the "layers" of your security use the same factors are they really layers or are they simply a time sink for you permitted users, and another thing to break?
My visceral reaction was "you got to have a VPN" as well but the more I thought about it the more I was convinced you don't _need_ a VPN.
Effectively are you saying: if I hacked your account I hacked your VPN username/password too? It's still an extra step that might trigger some sketchy senses of some people.
Not sure if it still doesn't work effectively for that.
Or if your threat model accounts for the prevalence of stolen credentials and end-point compromise vs. the vulnerability of your exposed application attack surface.
> Have we moved past layered security for some reason?
Yes, yes we (more accurately "they") did. I don't know which schmuck with a blog came up with this idea that VPN is a thing of the past and a lot of people followed suit.
I bet there are IT shops out there that rely solely on VPN and the schmuck worked there, but that's like seeing somebody not lock their door and concluding doors are bad model for security and we should get rid of them.
oh come on. Competent companies regard their internal networks untrusted with or without a vpn access solution. If your an incompetent company then there is no argument for a vpn vs no vpn because your incompetent, and will eventually succumb to the horrors of your insecurities regardless if your applications and network endpoints are directly exposed to the internet or behind a vpn solution.
your beyondcorp link has nothing to do with a well implemented vpn solution + standard access controls to network endpoints like the link suggests. Your clearly supporting a false dichotomy in which having a well constructed vpn solution is "wrong" and does not add to your overall security posture. Shenanigans.
vpn or not you still need to authorize/authenticate your network endpoints. But hey, you don't want a vpn so give me a list of your internet accessible ssh hosts and well see how well your "zero trust" gets you if you can't keep up with best practices. Good luck!
That’s a shockingly dumb approach in the context of security today where zero days have to be included in your threat model. A VPN should be requisite to even get network connectivity to such critical services. Then on top of that, you should still have to auth to access them.
Does it though? Using a VPN for access to internal infrastructure doesn't mean said internal infrastructure is insecure or authless itself. As in, defense in layers.
Exactly, assume zero trust but VPN with MFA provides another layer of security. Given the weekly volume of package vulns Github notifies me about I don't want to miss a 0day and get scanned. Perimeterless is fine if you're only using SaaS or you have an army of SecOps, but I don't want an internal app rumbled.
Nobody is saying VPN is a replacement. Users should still have to authenticate against an IDP once they're inside the perimeter. VPN + MFA protects apps from drive-by attacks while they're waiting to be patched.
Yes, in a perfect world everyone would have an army of SecOps ninjas pentesting and patching all systems 24/7, but this is the Real World™
The rhetoric of this statement is far more of an "anti-pattern" than VPN will ever be. If VPN is your only line of defense, then it's not secure at all - not because of VPN, but because of poor security practices in general.
VPN and IP restrictions in general is a very good tool to limit the attack surface. That does not mean that Karen from accounting should be able to log into the production environment servers.
Exactly. We have application level authentication on top of various network level security policies. Karen from accounting can't even see servers that she doesn't need, and anything she does need has additional authentication requirements. Even if someone mistakenly gave her access to something at one of these layers, she would need that same mistake at multiple layers to actually get in.
> Internal networks only accessible via VPN is considered an anti-pattern now in terms of security. It puts authorization firmly on the VPN.
How do you jump from "VPN is not authorization" to "VPN is an anti-patern"? It's at a completely different layer than authorization ffs! You don't give up on seat-belts because they don't stop bullets coming through the windshield.
Who says its an antipattern? VPN Authentication is additional to authentication on internal systems. VPN is a requirement in most security frameworks like NIST.
> Internal networks only accessible via VPN is considered an anti-pattern now in terms of security.
I could be wrong, but I think they mean that access to the internal site should have been behind VPN (whether at the IP network level or via an HTTP proxy) even when accessed over the internal network. That is, the internal network should not be trusted any more than the network at the cafe down the street.
This hack probably underscores the importance of zero trust. Although if the system is compromised from within (like this hack is) then there is not much you can do.