How Global Secure Access changes our zero trust thinking

With the recent launch of Global Secure Access (GSA), Microsoft’s new Security Service Edge (SSE) technology, we need to revisit how we think about zero trust. I previously wrote about the zero trust concept, and how we can take the ideas behind zero trust and turn them into prioritised work. While the principles hold true, and changes in the threat landscape only strengthen the need for this work, we now have new, integral technology that can underpin these adaptations.

My colleague Pravesh Kara has recently written about what SSE technologies are and how they help mitigate a range of specific attacks. These concerns are tightly bound. Zero trust architectures describe protective measures to defend against these attacks. SSE technologies provide new tools to achieve many of those aims. In this post, I’ll expand beyond the high-level overview I provided when the technology arrived in Public Preview last July, to get more specific about GSA capabilities and how we can root zero trust adaptations in this technology.

Types of Global Secure Access projects

Although this article will focus on use of GSA for zero trust goals, it’s worth offering a final preamble about other types of GSA projects. For instance, the pricing is very attractive, so we expect many organisations will start their GSA journey from a less ambitious position, focusing on technology displacement and consolidation.

In this scenario, an organisation might choose to move all existing virtual private network (VPN) and/or forward proxy rules from existing platforms to GSA. There are lots of good reasons to do this. We can decouple migration complexity from hardening complexity. Then, once a migration is complete, an organisation can use the new technology to model new rules before transitioning in a more measured way. Policies can be placed in testing modes to understand their impact before a less permissive posture is adopted. It’s important to acknowledge that although GSA is the technology that helps with zero trust, we needn’t only see it through that lens.

A refresher on zero trust principles

If you read the NIST zero trust architecture guidance, you will notice some common themes:

• “Trust is never granted implicitly but must be continually evaluated”
• “Minimise uncertainty in enforcing accurate, least privilege per-request access decisions”
• “Access control enforcement as granular as possible”

Each access decision is subject to its own evaluation. The scope of this decision must be as small as possible. Once given, trust is time-bound, and re-evaluated. All of this stands in contrast to legacy network authentication technologies. While much effort was poured into securing initial authentication with multiple factors or other strong authentication methods like certificates, this would reduce to unrestricted onward access, with no guarantees of re-evaluation.

Once access was established, there were typically few ways to revoke that access with confidence. It typically lasted too long for comfort. Shortening it aggressively typically involved some high-friction trade-offs that would destroy the user experience and harm productivity. Once “inside” the network, there was often inadequate measures in place to restrict movement from the initial resource to something else. In fact, in many cases the initial target served only one purpose: to move somewhere else, like a jump box.

All of this is well-known and well-exploited by attackers. When we talk about detecting lateral movement, we mean that a network does not have sufficient restrictions in place to prevent that movement; communications once inside a network are generally permitted. Where network segmentation restricts this movement, it is often scoped very broadly. Perhaps standard endpoints are prevented from accessing servers, but not prevented from accessing the administrator endpoints, which can in turn access those servers. This is what attackers normally find, and what zero trust principles seek to up-end.

Mapping zero trust principles to Global Secure Access capabilities

NIST puts forward technology-agnostic tenets of a zero trust Architecture, which are articulated in an idealised form, accepting some pragmatic needs. For instance, if you require re-authentication every one minute, your workforce will grind to a halt. Although the NIST tenets are put forward as an ideal, we can now see that GSA aligns with them by design. This is a list of these principles, grouped/paraphrased and aligned with GSA capabilities:

All entities are a resource

Traditionally, organisations have focused on securing access to sensitive workloads or data. The control aligned only to the target. A zero trust Architecture does away with the fallacy that this machine is a client or a server. Instead, client and server should be thought of as ends of a session.

We know that servers act as clients to other servers or services, and client machines can be servers (for instance file shares or remote desktop sessions). In GSA, the security of the requesting entity (comprised of user, device, location, etc.) is represented in the conditions we know from Conditional Access today (with some new additions), and these conditions can be applied to access at any target application or network scope.

GSA ensures comprehensive security policies are applied uniformly across all entities, whether they are on-premises or on-cloud, and makes all trust evaluations explicit in policy.

Strong network security everywhere

Traditionally, an organisation might terminate their network protections at the perimeter, for performance or compatibility reasons. Thankfully, this approach has become less common with web workloads since TLS connection have become the norm, but with other protocols we still find dated network protections.

By brokering access with GSA, we uplift this communication to modern authentication and network protocol standards as much as possible, allowing us to strictly ring-fence any lingering legacy weaknesses. Modern, brokered connections become the norm for all but the most exceptional sessions, and we can expect strong protections against any attackers who might try to intercept traffic as a ‘man in the middle’.

A session’s security context is comprehensive, and always re-evaluated

Traditionally, access tokens would be issued based on the context when the session was initiated, but re-evaluating this context was not always viable. A token would have some lifetime that wasn’t bound to the same conditions as when it was created.

The canonical problem would be a laptop’s session initiated on the corporate network, which remains alive when the laptop roams to a coffee shop’s network. The network security context has changed dramatically, but the token grants access to the same thing without a need for added security measures.

Zero trust architectures account for this need by specifying the re-evaluation of the context in near real-time, coupled with any additional security measures aligned with that change. This evaluation encompasses location, device compliance (including required controls, security health signals, or system version), identity threat level, anomalous behaviour, resource permission changes or explicit revocation actions.

Mitigating the ‘hairpin’ problem created by ‘Always On’ connections

Evaluating in real time seems like an obvious thing to do, but in practice it is only possible if your VPN is ‘always on’, or your SSE technology is an intermediary to everything you want to access. This creates a new problem: the network ‘hairpin’.

All traffic must be routed for evaluation, before an approved request can be routed to the requested resource. Where an organisation orientates on Microsoft technologies, GSA becomes the only SSE vendor that can avert the majority of ‘hairpinning’ woe, since the SSE technology and the resource are on the same global backbone.

Policy evaluations are informed by logs and telemetry

GSA enhances normal Microsoft 365 logging data (while simultaneously overcoming some log latency problems we typically see), adding new richness to the visible activity within these services. This added richness, coupled with a stream of comprehensive signals from a requesting device, yields new insights into user activities, network traffic patterns, and asset states.

Zero trust architectures prescribe bringing this type of intelligence to access policy, as we get with Conditional Access risk-based conditions today. These risk-based decisions are now more informed, can be applied to any GSA-brokered application, and this access can be revoked in near-real-time through Continuous Access Evaluation.

Low trust does not mean no trust

Most zero trust Architectures must accommodate BYOD. It’s important to acknowledge that we already have good ways of accommodating low-trust contexts with capabilities like Intune App Protection policies (MAM), and the Microsoft Defender for Cloud Apps Session Proxy.

These approaches don’t go away simply because we have a new way of establishing high trust access with GSA. Many organisations will be tempted to embrace GSA for low trust access, but it’s important to remember that these untrustworthy devices should not earn high trust access.

It may be counterintuitive to look outside of our most zero trust-aligned technology for these provisions, but that is precisely what we should do if we’re embracing a zero trust Architecture. This should also be considered when granting access business to business.

How to manage exceptions

Although the most obvious idea in zero trust thinking is that you should not trust the network, we may be left with some scenarios where we have no better choice. We may choose to use GSA to support these scenarios as a managed exception within a zero trust Architecture.

Imagine you have printers in branch offices that must communicate with servers in Azure. The printers are unable to satisfy most zero trust criteria for secure access to that environment. However, we might choose to use the remote connectivity capabilities in GSA as our least-worst option to secure very specific, allowable traffic to only the servers that the printers must reach. We know that:

• The network access we allow will be as granular as possible
• The communication will be uplifted to a modern standard
• We will have visibility of unexpected activity
• We will have the tools to revoke that location’s access if it must be contained

None of that is true of a site-to-site VPN, so we use a zero trust technology to accommodate some acceptable access, even though we know the policy has not met the conditions for high trust access. We do this simply because it’s a significantly better choice than the alternatives. All of this can nicely co-exist with high trust access in that same location, since the more trustworthy devices will typically be able to meet their own access criteria from any location.

Don’t forget the inner layers

IT and security departments often look at risk and security through their own lens. They can typically ‘see’ the outside of the session, but not always inside it. They can control access at this outer scope.

Although it’s also possible to use Entra ID Groups and related capabilities to control access within an integrated application, for role-based access or more granular permissions, this work is often delegated to the business units that own their own areas (such as a Team or a SharePoint Site) inside that workload.

IT departments may be tempted to look at GSA, embark on an ambitious programme of adaptation to ‘become’ zero trust, and then forget about the world of security beyond their normal control. It’s important that even if this ‘isn’t IT’s problem’, the problem does receive the attention it deserves. This has never been more true than now, as people assess the depth of the risks they hold, when considering if they are ready to bring generative artificial intelligence services in contact with their own data.

Transforming zero trust with Global Secure Access

Hopefully the significant strengths of Global Secure Access are coming in to focus. This revolutionary set of capabilities build on the virtue of the existing Entra stack, extending it respectfully to where it couldn’t reach previously.

GSA is the most powerful and comprehensive tool in our kit to support zero trust adaptation – especially when we think about the scope, intelligence and timeliness of its controls. We still need to understand zero trust adaptation more broadly than the GSA frame, but the assurances we can take from this new network intermediary transform how we look at the total picture.