Zero trust network access means different things to different folks.
Every security vendor in the world today seems to have a
zero trust network access solution,
and the definition of such can vary from product to product.
I like to use the Gartner definition of zero trust network access,
and that is that it's a product or a service that creates an
identity and context‑based logical access boundary around an
application or set of applications.
Fundamentally, it's the implementation of the principle of least privilege.
At the end of the day,
it's granting access only for what an application or service might require.
Zero trust is implemented with Always On VPN using a variety of
features or capabilities of Always On VPN.
The first is traffic filters, and traffic filters are
traditional kind of Layer 3/Layer 4 access controls.
You can control access by, you know,
source and destination IP address, the protocol,
source and destination ports as well.
You can also leverage application filters, meaning that you can restrict access
by the executable, by the package family name, or even restricted to system
access. With Always On VPN and zero trust, you can use a combination of traffic
and application filters to enforce policy.
An important caveat is that unfortunately, today, traffic filters do
not work with IPv6. That just seems to be broken.
If you're assigning an IPv6 address to an endpoint over the VPN and expecting
VPN access over IPv6, traffic filters simply don't work.
It actually breaks the VPN connection.
So unfortunately, if you're using IPV6 today for Always On VPN,
you will not be able to take advantage of traffic filters. Before we get
on to implementing our zero trust policies with traffic and application
filters, I want to talk about some of the things to really think about
before you go down this path.
There are many advantages to implementing zero trust, of course,
and the first is limited network access reduces your attack
surface. So if an endpoint is compromised,
you know, with malware or ransomware,
specifically, the access to the internal network is dramatically reduced.
It may only have access to a couple of resources and just a subset of services
on your internal network, so that's obviously quite positive.
Traffic enforcement is done on the endpoint, meaning if
there's traffic that is being blocked,
it's being blocked on the client device, so it doesn't ever come
over the VPN tunnel, and that can reduce, you know,
noise on your internal network and internal logs,
it reduces the traffic on your VPN tunnels, of course, and
that has some positive benefits as well.
And as you'll see in the next demonstration,
it's fairly easy to configure policies, at least basic policies, using
Intune. Now, with regards to disadvantages, of course,
all of this comes at a cost, and any time you have increased complexity,
it's going to make the solution more difficult to manage and support and
troubleshoot and all of that, so keep that in mind. Also,
these policies are fixed policies,
meaning there's no just‑in‑time access. Once you apply a policy to an endpoint,
that's the policy. And if you need to make changes to it,
you will need to remove the VPN profile and reapply it.
If you're using Intune, not a problem.
We've extolled the virtues of Intune quite a bit to this point in
that it simplifies the management a great deal,
meaning you can change your zero trust policies in Intune, and the
clients just take care of themselves, right?
So they'll just sync with Intune, get the new policy, and you're good to go.
But if you're managing Always On VPN using SCCM and
PowerShell or something else, then that burden is on you,
the administrator, to have to go out, remove the VPN profile,
and then recreate it using the new policy.
And this can be challenging at scale if you're constantly adding and
removing applications or you're moving internal infrastructure, and so
applications are now located in a different subnet, and so all of that
increases the administrative overhead a great deal.
And finally, and again, you'll see this here in the next demonstration,
is that true granular access control using application and
traffic filters is just not supported in Intune. It's just
prohibitively difficult.
So it really requires that you use XML to manage and control your zero trust policies.