This third instalment on Connectivity in the Mobile Age will cover the alternatives to using an APN for isolation and segmentation (you can read part 1 here and part 2 here). Our focus will be on the enterprise use of access paths — specifically, how the current use of APNs to isolate and control enterprise traffic can evolve for better access and control.
To address this topic in the best way possible, it is best to look at an APN for what it is: a network.
An Underlay is an Underlay
Mobile networks, much like all other networks — from your home to the coffee shop WiFi network — are now simply commodities. You or your users, as the consumer, only want to consume connectivity. As is the case with all other commodities, they are underlays for the real service.
First, what is an underlay?
Consider your home, be it an apartment or a house; you have pipes that bring water into this home. You have a water provider, which is the entity that brings the water to your house. This provider has no idea of what you do with the water — just that you consume it, and they provide it to you.
This is an underlay; they provide the commodity that you consume. This is no different with your network provider, e.g. WiFi or mobile provider. Your access should not be controlled any more than is necessary to provide you with access. Why? So that you can consume that network.
The value of this underlay is simply to provide you with connectivity. It is the value of the overlay — that being the service you use on top of your connectivity — that allows you to make decisions about your use. Your water provider doesn’t tell you what bathtub to use; you wouldn’t trust your water provider to tell you how to use the water.
In addition to not having the right to shape or direct your traffic, the underlay provider — in the case of your mobile phone, the carrier — should not be profiting from your data. The carrier should not have any rights to view any part of your traffic.
Interesting Fact: Should you encrypt your application traffic, e.g using TLS for web traffic, the content of the session is not visible. However, carriers can still see the domains that their subscribers visit from the connection setup metadata, i.e. DNS. Some carriers even break TLS sessions to snoop on your traffic, inspecting things like content, SNI, certificate exchanges, etc.
Essentially, what enterprises must do for privacy and data security is to remove the carrier from the decision path of the traffic and turn them into nothing more than a conduit to get the water to where you want it to go. Removing the reliance on the carrier to direct your traffic will give your enterprise more control and independence.
An APN is nothing more than a select switch to decide via which network gateway your traffic is sent. The APN is generally not validated by any check or test. Rather, the connecting device simply presents a text string that then assigns it to the requested path. The Network Identifier used by an APN is free form text, and thus anyone can copy it, change it, and use it to access any network — which is why some APNs have passwords, but even these are trivially extracted.
Not only can anyone with the correct string connect to these APNs — once they are on those APNs, as previously outlined, there is rarely segmentation within the network. As such, anyone who is connected can see and access not only the other mobile devices, but also the internal functions of this network.
This entire access path is enabled by a text string. Which really doesn’t give the level of security and control needed.
Interesting Fact: Some APN providers have attempted to add additional layers of access control by checking the individual IMSI/MSISDN of the SIM card.
An enterprise should consider allowing any mobile device to use any public APN and leveraging that Internet connection to implement their own secure path to their internal network. An overlay network, riding on top of the APN, allows the enterprise to control and segment their access path.
Trust has to be proven, hence the overlay
Using mobile technology, IoT and hotspots, etc. will always require the utilization of a mobile carrier. These carriers will have the right to direct your traffic onto one of their controlled APNs, and quite possibly they will still attempt to manage and inspect your traffic.
The way to avoid this challenge is to simply use Public APNs on your devices and encrypt all traffic from your device across the carrier network to its destination. Doing this will ensure not only that you control the flow of traffic, but more importantly, that there is no need for costly private APNs and interconnectivity.
If this sounds like a familiar story, then you only need to look at security recommendations over the last 5 years when using WiFi — use a VPN to encrypt traffic — and the same principle will work over a mobile network.
The „just trust this network“ “ model, providing in-path security between the user and the network, has been proven to be exploited by the network owner. The network underlay should be considered nothing more than a transit path.
Applying a “don’t trust this network“ model to the underlay network is as simple as enabling an encrypted tunnel for traffic from your device to networks they need to access.
This also means that devices that go off-network and connect to a WiFi or hotspot will still have the traffic pass through the VPN to the enterprise network. Which then gives the enterprise the ability to ensure the same security and control by continuing to route all of the traffic over that dedicated tunnel.
However, even the VPN overlay model has some shortcomings. These are based on the nature of TCP/IP, which ultimately dictates that to have traffic route from a user to an app, the user and app must share a network context. To implement this in the overlay model, devices must connect over a virtual link (normally a VPN tunnel) to the application space where you host your apps. This works well when your apps are in one location.
The challenge arrives when your user traffic is bound for services outside of your data center, e.g. internal apps in cloud environments, IaaS or PaaS services, or even another corporate site. Now the traffic generated by the mobile user must still enter at a single ingress point, then be passed to the appropriate service over the internal network.
This does give advantages of passing the traffic through your internal security controls, allowing the enterprise visibility into who is going to what app. This is the famous “castle and moat” model, where your castle is the central point of control for all access to all applications and access is only granted via a single entry point — the drawbridge across the moat leading to the entry gate in the castle walls.
There are two substantial challenges to this model, both of which are based on the idea of enabling access via network overlay
First, Scale. It is not possible to enable simultaneous direct access to multiple sites or application locations in parallel; all traffic must be brought in via the central ingress stack — as this is where the network path is defined.
It is possible to enable split tunneling, where externally-destined traffic can be excluded from this network path, but that becomes complex to maintain and expensive to enforce. Hence the problem with scale.
Second, you are breaking the mobile user experience. Every time the device switches underlay networks, the overlay network connection will be broken, thus requiring the device and the user to re-connect to the overlay network via the new underlay.
The value of the overlay must be clear at this point. Not relying on a carrier to route or steer your corporate traffic from mobile devices is certainly cost effective and maximizes your risk avoidance. However, the end experience of a user on a VPN is not the mobile experience they have come to appreciate, nor will it scale to meet the enterprise’s wider requirements for app hosting across multiple locations.
So what is the true solution to removing dependency on the APN for isolation?
The Zero Trust overlay
First, we should clarify what Zero Trust access really means: providing a secure access path from users to applications, independent of networks. You can find a good history of how the Zero Trust model evolved here.
This is done by breaking the assumption that context for application access stems from network-level access, e.g. users must be connected to a network to see and connect to applications. This shift in perspective enables us to consider that access may only be enabled to an application if the user is validated, and only to that application — not the entire network.
A Zero Trust architecture removes the dependency on network connectivity and, by doing so, enables the application to exist anywhere and the user to connect from anywhere.
Demonstrated in the diagram in figure 5, the actual path for access is only enabled, per application, once there are a number of validations about the requested connection. Only after these conditions are met is access to the application then enabled.
The beauty of the Zero Trust model is that access is granted on a per-application basis — and, more importantly, there is no limit on the number of application access paths. By using Zero Trust access, users can create multiple, even hundreds or thousands, of connections — each to a unique application and without ever having to establish a network connection to the private application network.
Due to the nature of Zero Trust, applications can live anywhere, users can be anywhere, and the Zero Trust access model enables access to be brokered between the user and their application.
In their Zero Trust Network Access white-paper, Gartner describes two types of zero trust implementations: client-initiated and server-initiated.
The client-initiated model is topologically very similar to a VPN, except for the point that there is no network connection. Users still need their traffic routed to a central controller that then sends authorized requests through the internal path to wherever the applications are based. This is a functional solution, but the end user experience and scalability challenges are no different from a remote access VPN over an APN. The server-initiated model, by contrast, eliminates these challenges by enabling multiple simultaneous direct connections to separate application environments.
Interesting Consideration: This is all well and good, but these models both define sending all traffic to the Zero Trust path, including Internet Traffic. Whilst this is somewhat true, it is entirely possible to have Internet access split out of a Zero Trust path. The challenge for an enterprise is how to provide the security controls needed for that Internet path.
It is the recommendation of this Author that Zero Trust only be used for private or internal application access. Internet access should be direct. However to ensure the security of Internet bound traffic, an enterprise must consider the security challenges and controls. There are 3 options:
- Send all Internet traffic direct, without inspection or analysis — not recommended
- Send Internet traffic through the Zero Trust connection to outbound security controls within the enterprise — not recommended
- Leverage a global, cloud-based Internet security service that offers the same outbound security controls, but globally to any user, anywhere — recommended
The cloud-based approach for Internet traffic thus also matches the goal of the Zero Tust model: “any authorized user to any application“.
Leveraging a service-initiated Zero Trust architecture, where both the user and the application controls connect out to a global broker, means that users are never routed to a central gateway. In turn, that then enables direct access to applications that exist in any application location, including private and non-Internet connected segments. This drives a very granular, yet broadly available set of access paths for users to applications.
Zero Trust Makes an APN Simply a Connection Path
When considering the path from your mobile or IoT devices to consume required services, no externally-managed controls should block, inspects, or steer your enterprise traffic. Such actions should be managed by the enterprise, not a carrier. Therefore the APN, the carrier network, etc. that are used to provide initial connectivity to your users should be seen as nothing more than a connection path.
The lack of general understanding of mobile networks has allowed carriers to establish a set of controls that allows them to sell special-purposes services, gather end user data, and interfere with end user traffic. This has also meant that there were no other viable options. which has locked customers into legacy ways of working with little flexibility, unable to be fully empowered by the ubiquity of the Internet.
Mobile connectivity has started to, and will continue to, threaten traditional user networks — LANs, WiFi, etc. Especially with the advent of 5G, the ability for an end user to have always-on, reliable, high-speed connectivity from anywhere will only drive more users and organizations to question the need for private network services. Thus, private applications and services should be consumed in the same way users consume YouTube — fast and friction-free.
Until recently, this sort of consumption model wasn’t available; hence the reliance of enterprises on carrier provided access services. This has changed with the delivery of feasible globally-scalable Zero Trust services.
For enterprises looking to drive seamless, secure, simple, and segmented access to their Internet-based and private applications, looking at the benefits offered by Zero Trust access is worthwhile.
It is time to say goodbye to private APNs.
For more details on Zero Trust, Zero Trust Network Architecture, please refer to these resources:
Zero Trust Networks by Doug Barth, Evan Gilman: https://www.oreilly.com/library/view/zero-trust-networks/9781491962183/ch01.html
The Rise of Zero Trust Archicture: https://hackernoon.com/the-rise-of-zero-trust-architecture-17464e6cbf30
