.jpg)
When I first read the federal government’s memo on it’s transition to zero trust, I was jumping out of my skin with excitement. There’s lots of great stuff in that federal zero trust memo (see my earlier blog post) but what excited me most was the memo’s stance on VPNs. Namely, the memo is a resounding victory for those of us who support VPN replacement technologies.
The Federal Zero Trust Memo Says Perimeter VPNs are Deprecated.
You would expect the memo to say “VPNs are not enough,” because they really aren’t. The memo says:
… the Federal Government can no longer depend on conventional perimeter-based defenses
The old-fashioned perimeter VPNs are highly problematic, if they are used in the absence of other defenses. Having just one perimeter VPN to protect your assets, but no other defense, is akin to basing your corporate security posture around giving keys to office buildings but not to individual offices. Once the attacker enters the building, they can get into any office and no one can stop them from doing whatever they want.
We already know that this memo is, in part, a reaction to the Colonial Pipeline ransomware incident of 2021, where a single inactive VPN account allowed the attackers to breach Colonial Pipeline’s entire infrastructure. So we’d expect perimeter VPNs to be deprecated.
Segmented VPNs Are Also Deprecated.
So what I would have expected next would be for the memo to say “segment your network using VPNs.” This would be like giving individuals keys to individual offices, rather than the entire building. And this is what many of today’s modern VPNs do — they use policy or role-based access control (RBAC) to control which part of a corporate network a given user has access to. But, actually, the memo didn’t say that. It said:
Users should log into applications, rather than networks
So, that sounds kind of reasonable. You could imagine having users log into applications behind a VPN. So first you would VPN into the network, and then you would use another set of credentials to log into your application.
.png)
Just Log Into Applications.
But, actually, the memo doesn’t say that. It says:
Enterprise applications should be able to be used over the public internet.
In other words, it actually advises against using VPNs at all! Enterprise applications must be secure enough to be used without a VPN. This is the beyondcorp approach that Google promulgated back in 2013. The memo later spells out its stance even more starkly by saying
Making applications internet-accessible in a safe manner, without relying on a virtual private network (VPN) or other network tunnel, is a major shift for most agencies that will take significant effort to achieve.
But why is the government taking this aggressive stance?
No More Crutches. It's time for VPN Replacement Technologies.
One way to think about this is that VPNs are a crutch. If teams believe that their applications are “behind a VPN” and therefore “inaccessible to adversaries”, then they’ll be lazy about locking down the applications and therefore increase the risk that the applications will be breached.
In other words, it’s more difficult to lock down individual applications by inserting authentication systems, MFA, and RBAC (as suggested by the memo), and it’s much easier to stick things “behind a VPN." The memo encourages a change in mindset by stating “every application should be treated as internet accessible from a security perspective.”
This is a shift. It will take time for the government and even private companies to get used to this.
Restrict Lateral Movement.
Here’s another reason you want to control access to a specific application — doing this reduces the risk that an attacker will move laterally from one target hosted in a network segment to another target in the same network segment.
We know that lateral movement via remote access protocols is a common strategy for attackers. This happened, for instance, in the 2009 Operation Aurora (when attackers used compromised admin credentials to jump from one target to another while behind a VPN).
I spent some time talking about this very issue with Andy Ellis at DevSecCon24.
Forcing users to log into applications limits the risk of this sort of attack.
(To be fair, there are other things one needs to do to restrict lateral movement, like close open ports and properly architect the network layer, but it is undeniable that lateral movement via remote access tools is a technique attackers love to use.)
I think this is the key reason the government adopted this stance.
Direct, Rather Than Indirect Access Control.
Segmented VPNs also provide mediocre access control — they can control which private networks Alice is allowed to access, but not which targets or applications or roles she’s able to access while she’s inside that network. Network segmentation almost always occurs at a level of granularity greater than the application creating clusters of access. You always want your compartment to contain one application. The best way to do that is to control access to applications.
Let’s go back to my office building analogy. Even if Alice is allowed to access only a specific set of offices, once she’s inside an office, she can access any of the devices, paperwork, or materials that are lying around in the office. So if Alice is in HR, you better make sure that all the HR paperwork is available in Alice’s office. (OK I am struggling with this physical analogy, I haven’t been in a real office for a while, but you get what I am saying!)
We can do better than indirectly gating access using keys to offices (i.e. segmented VPNs). A far better approach would be to enforce specific organizational roles and responsibilities on Alice. If she’s an HR person, she gets access to HR information. If she’s an accountant, she gets access to accounting information.
Controlling access to specific roles on an application is not something that VPNs are designed to do very well.
Better Logging.
The federal zero trust memo alludes to the need to log the behavior of users while they are accessing applications, talking about “improve[d] agencies’ knowledge of user activities, thereby better detecting anomalous behavior.”
VPNs can’t do this very well. They just track what network segment a user accessed. In other words, they stop at the front door of the office, but they lack visibility of what’s going on inside the office. (There are a multitude of tools you could deploy and correlate to get an understanding of a user’s behavior through a VPN. Just imagine having to correlate between my VPN, NAC, CASB, NGFW, and directory logs. But who wants to do that!?)
This is where VPN replacement technologies can come into play. If users authenticate into applications, agencies can track exactly who logged into the applications, what role they assumed, and what commands they ran, or resources they accessed. And all of this activity is tied back into their user identities, rather than into an ambiguous role or IP address.
Betting on the Right Horse.
All of this kind of reminded me of that moment in 2013 when I saw President Obama say the words “cyber-attack” in his State of the Union address. It’s funny to say this now, but back then I was stunned and felt like I had bet on the right horse for my PhD.
I feel like that right now, with BastionZero.
Because BastionZero is not a VPN. BastionZero lets you log into targets, not networks. It controls what roles users access on those targets. And it logs everything that users do on those targets.
Learn more here or read our docs.
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.
