In my experience, people use VPNs as an excuse to push weak host security through review. Eventually, everyone dismisses all security concerns with "it's behind VPN". And then they connect to the VPN with their malware-ridden computers. People are also surprised that whatever they run inside supposedly sandboxed VM actually gets full access to the VPN. And then there are configuration errors that can lead to surprising effects like forwarding all traffic from one's home computer through company's network filter/sniffer.
For these reasons, I always recommend running everything with public IP address. No more excuses. It's public, so security is a must. No more surprising network flows. Cloud-based monitoring tools can access the servers. Limited access can be granted to non-core team members and computer-illiterate staff.
For organizations with extremely sophisticated security teams, pretty far beyond the industry norm for "unicorn" startups (which themselves tend to have security teams with 10+ people on them, meaning millions of dollars of annual spend on security), this makes sense.
But for other companies, when they haven't been architected from the beginning to carefully support this access model, this is terrible advice. Just awful. Converting a company with a VPN/private deployment environment model directly to a "YOLO BeyondCorp" model will get that company owned up.
Further: if the primary things people need to get into private IP space for are (1) developer access and (2) access for non-technical staff to admin interfaces, the win just isn't there, even if done correctly, for most companies with the BeyondCorp model. It costs more to keep that model secure than it does to set up a system of VPNs for private access.
You and others here are assuming that VPN provides you with at least some security. In reality, VPNs grow large and open and someone will inevitably bring malware in. Furthermore, people run untrusted software in browsers and VMs that is capable of scanning the VPN and exploiting vulnerabilities. There is no security in a VPN. It's as naked as public IPs.
As for the cost of host security, you have to consider the cost of VPNs too:
- VPNs complicate everything, because all computers inside them are effectively on a crippled, partitioned Internet. Staff that could normally just login via web interface has to fiddle with network settings. High-bandwidth apps need custom configuration to bypass the VPN in select cases.
- VPNs block cheap cloud services. They encourage deployment of poorly secured self-hosted services with on-going administration costs.
- And then there's the latency. People will setup star topology for VPNs, because it's simple and easy to control, but then everyone spends time compensating for the increased latency.
Sure, migration between security models is tricky, but migration to anything is always tricky.
I'm certainly comfortable with WireGuard for machine to machine connections, but I don't see how it would replace traditional VPN w/ 2FA (e.g OVPN w/ Duo) for non-technical staff to access internal apps (at least without something similar to PAM)
When non-technical people get VPN access, it's almost always to access a small selection of specific applications. Lock their VPN connections down and implement 2FA (or, more realistically, 2FA-enabled SSO) for the applications rather than the VPN connection.
The 2FA VPN thing is, I think, a consequence of how hard it is to set up VPNs. Companies share VPN infrastructure between developers (who need relatively unfettered access) and non-technical staff, because maintaining multiple VPN configurations is so painful. WireGuard fixes that problem.
This is what I'm talking about when I say that WireGuard is a big deal. The current situation, with 2FA logins to very powerful VPN connections, is deeply suboptimal, and is what BeyondCorp was a response to in the first place.
If I was asked by a client today to design a remote access solution for customer support people to access an internal admin app, I might try to devise a site-to-site system (in which case I'd happily use WireGuard) --- deploying host-based VPN for support staff seems like a nightmare. But even if I couldn't, what I could do now that WireGuard is available is retain OpenVPN but drastically ratchet down what it has access to, SAML-ize the admin applications, and migrate developers to WireGuard environments.
Indeed.. There's no way at "OlderCorp" where I work would be able to move to this "YOLO BeyondCorp" public ip everything, we would be owned in seconds.
Secure hosts would be nice. I always say that VPNs and even firewalls are a band-aid. The problem is that the world is overrun with insecure legacy software and insecure-by-design new software that assumes it to always be running on a "secure network." This includes tons of database and orchestration software that has little or no authentication or where authentication is an obvious afterthought.
Saying that VPN is an incomplete control is not the same thing as saying VPNs are pointless. And the real argument (VPNs used as an excuse to not secure hosts) is even weaker. It’s often true! But that doesn’t mean a VPN isn’t an entirely reasonable control.
The one thing I like about a well-designed VPN is it's work done once on a relatively-simple component that can pay dividends protecting many, many, network-facing apps. Those will usually be highly-complex, not made by security experts, coded partly/wholy in unsafe languages, and could even change a lot increasing misconfigurations. A good VPN often reduces a hard problem of defending all that software from network attack to a simpler problem of installing the good VPN with a configuration forcing everything through it. This is, of course, not excuse to ignore other vectors. It just does a lot for user with minimal effort. Excellent ROI.
That's why tunneling proxies were used in high-security environments to protect messaging, voice, and video before apps were developed that had built-in protection. Just reuse the trusted, link encryptors or VPN's watching out for covert channels like traffic patterns. Fixed-rate, fixed-size with non-leaky, error messages covered that. Basically no effort to leverage them vs developing per-app solutions needing arbitrary protocols.
There's also a reason ipsec is in the ipv6 spec; and a reason Google (reportedly) turned on encryption/vpn of their dark fiber links after the Snowden relevations: there is no such thing as a "secure" cable, or "physically private" network.
You either encrypt your traffic, or you're vulnerable.
That doesn't mean a vpn is sufficient for security, just means it's a prerequisite.
People are pushing towards securing transport at the protocol layer - but it leaves issues like unencrypted dns, icmp etc.
What stops you from fronting the legacy or insecure-by-design software with authenticated HTTPS? You just run nginx/Apache on the same host and block direct access with a port filter on host's firewall. Setup automated updates to keep the HTTPS front secure. You could even front the app with 2FA, but that's usually an overkill. I don't see how this is any less secure than VPN.
> I always recommend running everything with public IP address. No more excuses. It's public, so security is a must.
Fully agree but depending on the culture of the company, you'll be treat as fool is you make such a claim. One of my clients is a Fortune 500, VPN access is done without 2FA, you will find all sort of company credentials available from a github search. Was surprised to see one of those credentials belong to a Thales contractor working in the security field ... Security is a good as the weakest link, you can't win against people madness.
For these reasons, I always recommend running everything with public IP address. No more excuses. It's public, so security is a must. No more surprising network flows. Cloud-based monitoring tools can access the servers. Limited access can be granted to non-core team members and computer-illiterate staff.