Global Secure Access: Is it for the SMB?

A couple of months ago, I presented a session on Microsoft Entra’s Global Secure Access (GSA), which is really two products under a single unifying banner.

Almost nobody in the audience had heard of Global Secure Access before. Granted, it was (and still is) fairly new, but I was expecting this announcement to make a bigger “splash” than it ultimately did. Especially in the SMB space, there doesn’t seem to be much awareness of it yet. Also to be fair, since this is still in preview, I would not necessarily recommend it for production at this time, but I do think it is something we should be keeping an eye on in the long term.

Is it just a VPN?

Some of the tech blogs out there are making a comparison between this product and legacy Virtual Private Networks, as if this were just a “Next-Gen VPN,” but this isn’t quite on the mark. Technically, GSA is a Security Service Edge (SSE) product. Microsoft themselves describe this as a “cloud-delivered network perimeter” that is “identity-aware” and integrated with their security ecosystem including Conditional Access and Microsoft Defender for Cloud Apps (Source: What is Global Secure Access (preview)? – Global Secure Access | Microsoft Learn).

I will briefly add here that, as usual, Microsoft’s marketing is a few steps ahead of their engineering department. Based on my testing so far, some of the promises of this product aren’t fully realized yet (but again, it is still in preview). In a nutshell, the solution leverages the Global Secure Access client, which you install on endpoint devices so that it can intercept and forward the traffic to Microsoft’s Security Service Edge (you can also configure your own network edge devices to forward their traffic as well). The GSA service can handle traffic for both private (e.g., on-prem) resources, and public resources, such as Microsoft 365 and other apps and websites on the Internet.

Microsoft’s stated goal with GSA is bringing the network edge–policies which you might normally enforce on a firewall–down to the endpoint itself. The policies are managed in the cloud, rather than on your conventional network perimeter. This has some obvious benefits, like being able to apply traffic policies no matter where in the world the device is connected (it doesn’t have to be behind a corporate firewall or connected to a VPN). The “perimeter” is therefore everywhere and anywhere that you happen to be. Which is pretty awesome.

Microsoft Entra Internet Access is Where it’s At

Global Secure Access includes both Microsoft Entra Private Access, and Microsoft Entra Internet Access. In the SMB, we are generally trying to get out of the on-premises hosting game, so the “Private” side of this product will find a much smaller audience here (not that the need doesn’t exist at all, it just won’t be as prevalent). However, with regard to the Internet Access product, the appeal should be universal; there are some tremendous benefits that the small and mid-sized business crowd would be remiss not to explore.

When you configure Global Secure Access from the Microsoft Entra portal, there are three traffic forwarding “profiles” that we have to work with out of the box:

I have enabled both the Microsoft 365 access profile, and the Internet access profile. When you switch these profiles on, Microsoft Entra instructs the Global Secure Access client to forward these types of traffic through Microsoft’s Security Edge, instead of going directly to the resource out on the world wide web. In turn, that gives you the opportunity to apply Conditional Access policies against that traffic in the cloud. Now access to these destinations will be contingent on the rules you set up.

For example, if we are targeting the Internet traffic profile, we can assign Global Secure Access “security profiles” to enforce web filtering.  This is similar to the web filtering we get with Microsoft Defender for Endpoint/Business, but with this solution we gain much more granular control using Conditional Access, which enables us to target users and other context rather than just ‘device groups’ as in MDE. Also, we can apply “priority” to policies, much like you would on a firewall.

Now of course, none of these policies mean anything unless the GSA client is installed on your endpoint devices. The client is available for download via the Microsoft Entra portal, and then we can accomplish the deployment org-wide right from Intune.

The other benefit of course, is that all this client traffic is centrally logged and visible now as well.

Stop Adversary-in-the-Middle attacks

Yet another major benefit of adding GSA to your Conditional Access toolkit is that you have an additional verification datapoint. That is, you can create a policy that will block traffic if the GSA client is not enabled or present, in other words, if the access request didn’t “arrive” via the GSA edge, then you don’t get access.

How does this work? When you configure GSA in your tenant, it will automatically create a new Named location called “All Compliant Network locations.” This object is now available for you to use in your policies (you can optionally set this as a “Trusted” location if you have existing policies that leverage this feature already).

In your policy, you would set the location condition to exclude All compliant network locations (i.e., GSA-connected), and then set the access controls to Block access. Meaning, if you aren’t connected to the GSA edge, then your access will be denied. And that means adversary-in-the-middle attacks (such as those made possible by Evilginx) are instantly thwarted, because the adversary’s device is not going to be connected to the security edge.

(Note: at this time, this policy is only supported for Office 365 Exchange Online and SharePoint Online).

Then there is the ability to enforce Universal Tenant Restrictions, which I mentioned briefly in a previous blog post.  In short, this means that you can prevent users from signing into other Microsoft 365 tenants, and protect corporate information from leaking into external organizations. This is optional to turn on, and it won’t be for everyone, but where it is required, it will be a godsend.

Proceed with caution

I have found a few buggy things with GSA that I am (mostly) confident Microsoft will be able to work out, and hopefully before it goes to General Availability (it’s still in preview now). For example, when I use Outlook on the web, I have noticed that I cannot access the files in my Groups. The reason, I suspect, is that Outlook is not forwarding its requests via the GSA edge service. So for now at least, the “Compliant networks” policy comes with some annoying side effects.

When I was setting it up for myself I also ran into a couple of hiccups, for example, if IPv6 is enabled it may become an issue since only IPv4 traffic is supported at this time for the Internet access profile (and also, only ports 80 and 443 are forwarded, so any sites with a different port number like 8080 or whatever would not be picked up by the client). And there are some other limitations as well.

Luckily, the GSA client has a handy little diagnostic tool built into it, which helped me identify and iron out (most) of the issues.

Conclusion

So again, turning the Global Secure Access profiles on in the Entra portal does not by itself impact anything, until you install the Global Secure Access client. Then you would begin to actually enforce the corresponding policies using Conditional Access. If you decide to try this out in your own organization, I would strongly recommend constraining it to a pilot group, and know that you could run into issues, especially when first setting it up, and especially while it is still in preview.

I will have a course out soon that covers the setup steps and various policies that are possible today (if you are a member of SquareOne, then you have already seen it). Long term I hope Microsoft takes this much further–I would like to see full egress filtering added eventually for instance. I have no idea if this is on the roadmap or not, but, even with the Conditional Access capabilities we have today, this product is showing a lot of promise, and if they can iron out some of the bugs that remain with the noncompliant networks policy by the time this goes to GA, I would certainly consider adopting it as part of my standard deployment in the SMB.

The only other roadblock I can imagine, is if the licensing requirements for this end up being different than they are now; during the preview at least, all I need is Microsoft Entra ID P1 (which is already part of Business Premium). If there are additional licenses required to use this product in the future (does anyone know this?), then the SMB certainly is less likely to adopt it. But I do not know the answer to this question–so it remains to be seen.