[DannyBee]

Can you explain why this is better than allowing access using 2FA over HTTPS (with a non-crappy set of cipher choices)?

IE What does the VPN buy you, specifically, on the employee side?

(I understand entirely what it buys you on the other side of the equation, such as a smaller attack surface, i'm just trying to understand why you would think having a VPN would have made this particular case more secure)

[tptacek]

The value of a VPN over individually-secured HTTPS/TLS+2FA connections is that you can configure the VPN once, use very standard networking tools to continuously ensure that your internal services are only available over the VPN, and not have to worry about individually securing different internal services.

Another benefit is that as your internal userbase changes, you can revoke access from a single point and be reasonably assured that you've mitigated risk, which is something you only get with individually-secured services if you have a reliable directory system.

A problem with individually-secured ops/support systems is that most 3rd party code is not ready to be securely deployed Internet-facing.

Both approaches are totally workable, but the VPN approach is easier.

[DannyBee]

I guess, in a lot of ways, i'm not sure about " and not have to worry about individually securing different internal services."

This is essentially something you need to worry about anyway, for other attack reasons.

[tptacek]

That's true and a point worth making, but as a practical matter, breaching almost anyone's perimeter is game-over. To not have that be the case, you need to design from the ground up so that internal services don't trust their own deployment network; it's difficult, time consuming, and in many cases confining (ie, it makes some services prohibitively difficult to deploy).

It's for this reason that pentesters learn quickly that the "make an arbitrary HTTP query from the target's own server" bug is usually sev:critical; for instance, in virtually any Fortune 500 network, that pivot gets you (with a little effort and 50 lines of code) to a JMX console somewhere, and from there code execution.

There's no good reason not to do both (ensuring that your internal services are authenticated reasonably and don't expose functionality or information pre-auth, AND setting up a VPN). But the VPN is the most valuable step.

[jumby]

Yes: from the internal rather than the external threat (bad guy employee).

As tptacek mentions, breaching perimeter security from external is "game-over" in most cases.

[jumby]

Right, I think having a non-split tunneling VPN forces employees remote computers onto the "corporate" network where they are governed by the rules of that network and establishing rules for access to internal resources is done centrally.

I just wouldn't trust having something critical like "impersonate user" on the open internet - even if secured by https + 2fa.