Zero-Trust sometimes seems to the word of the year and every vendor has its own definition about what it stands for… Fortinet kind of claims that zero-trust superseds VPN solutions, but I never get that. I mean if I have resources that I only can and need to access in my own network, how could I reach them safely only with a zero-trust-model?
The way to access them and to not give the whole world access to the data I have transfered is via an encrypted, secured connection - in other words a VPN. And zero-trust would say “you can only access it if your Windows runs the current patchlevel” and such stuff - but an attacker could have a fully patched Windows as well.
So I don’t get it and it seems to me that it’s more a marketing-term, but eventually you still need VPNs for the usecases mentioned above.
Beyond the compatibility checks that the ZTNA performs on each session, there is also a comparison of the user against your IDP. You don’t grant an access to subnets like you usually do with a VPN, but per app
You don’t need a VPN connection, you do a kind of virtual IP that verifies the user’s tags
And just as importantly it doesn’t have to be for remote connection, you can enforce ZTNA even within your network and save NAC solutions altogether
ZeroTrust is a strategy. That means it’s up to you to define how far to take it. How do you ensure trust within your unique environment. Fortinet provides a box of tools in their firewall and VPN. It’s up to you decide which ones to use.
ZTNA is Zero Trust Neteork Access. This is a term used to define applying Zero trust principles to network access. Internal VPN is one tool used to apply this strategy. There are others such as SD Access, 802.1x, NAC, PVLAN, etc.
I HIGHLY recommend the following book/novel to everyone who is trying to get a handle on Zero Trust:
And to your point about having an attacker coming from a patched device: with ZTNA, the attacker must come from a company patched device, not just any patched device because with ZTNA, you not only do a posture check but you also allow connections if it’s coming from a corporate issued device (via PKI/certificates), so even if the credentials were compromised the attacker would not have a chance to use them because with zero trust all those checks happen prior to initiating the connection in the first place
It’s one of those times when it’s marketing but also a real thing. It’s a model/way of thinking. ZTNA is essentially proxying traffic through your FortiGate, but at much more granular level than a traditional VPN. You can check for all sorts of things like various endpoint protections, patch levels, user authentication, etc… while only allowing access to specific applications/destinations.
It’s a different model than the traditional VPN where you generally just tunnel by IP ranges. You users don’t show up as a VPN IP (they don’t even have one). It also requires a lot more overhead/management.
Definitely cautious in my response as possibly being over my skies a bit; however I have one customer who is looking at replacing the VPN with FG ZTNA, and it has been a mixed bag to date.
Accessing Apps (ie web apps) within org, not a problem. SMB shares direct to a file server…ok.
Using DFS has been challenging to say the least (not working would be more accurate). FG themselves is scratching their head (as most forum related posts). All the long-established namespaces and folder referrals are defined as FQDN (per FG June 24 KB) - we are moving to next step which is properly flag all server configs as enabledFQDN just to see if that helps.
Of course there will be other challenges: like AD password changes to sync on local workstation, possible other AD related issues (Trust). And gone would be the days of asking an end user to provide bare bone IPconfig info to eliminate some basic TS steps.
I am not sold on easier management either, as everything needs to be defined, and that can be *fun* in environments that are not as well documented/controlled/structured as they should be (which seems more the rule than not in Small-Medium business). Stating it is a good time to implement those controls is great, but without complete buy-in from the top, it goes nowhere as there is always something ‘more pressing’. It’s like trying to re-organize a file server structure (something not technically difficult but too ‘hard’ for the end users).
I actually find the tech pretty intriguing but far from sold from a practical standpoint based on what our customer base is like. Maybe when AI does a complete takeover it will all be better.
A vpn uses authentication and encryption to create a secure network connection to access specified resources at the other end.
Zero trust will dynamically create tunnels to access specific resources based on authentication and other criteria. The “other criteria” is reevaluated on an interval.
So, in a fortinet world, zero trust is similar to vpn except it creates multiple vpns on the fly and transparent to the user and it evaluates more things… anti-virus running, for example. And it will shut down access if the situation changed )antivirus stopped), group membership changed.
Also, fortinet zero trust requires an EMS (web) service which is open to wherever your users are, typically the public Internet. Many would call this a security risk in and of itself.