Overview

Let us go over what zero trust is. This is the latest buzzword in the infosec/cybersecurity industry these days. This isn’t some tool you can buy to install so that you have zero trust despite what some vendors may want you to think. Yes, there is a system required to be able to reach full zero trust but like with so many other things in cybersecurity this isn’t simply about installing a gadget and now you’ve got zero trust. Vendor may sell you some system or set of systems and then go, BTW you need micro segmentation, a catalog of who needs access to what, good asset management and other aspects of Vulnerability Management before we can even get started. I recommend thinking about this from the other angle, setup network segmentation, figure out your defense strategy, get a detailed catalog of all your system and who needs access to what, then you can think about the additional systems needed.

Zero trust is a philosophy or mindset, not just one thing. This isn’t something revolutionary new thing, rather an evolution of cybersecurity thinking.

It used to be that networks and security posture was designed with implicit trust, for example if you were coming from a specific network, then you were trusted and allowed to go places. If you came from this other place, you were partially trusted, etc. Once you made it past the receptionist you had full access anywhere, etc. Then people realized that this was sub-optimal and started segmenting things down, but there was still a lot of trust involved.

Zero trust is yet another evolution of this thinking. When you adopt zero trust, all your policies, all your design decisions and your entire secure posture has zero trust assumptions. That nothing in your policies, designs or posture has implicit trust built into it. You trust nothing and validate everything.

Many of the aspects of zero trusts have been around for long time, this zero trust concept groups them together and tightens them up under a single concept. This includes old concepts such as network segmentation, the concept of least access and defense in depth, aka layered defense design. Let us look at those concepts before we delve deeper into Zero Trust.

Layered Defense Design

Before layered defense, aka defense in depth came into the picture there was perimeter defense. You would put all your efforts into protecting your perimeter, or edge, of your environment. If someone broke through that they had free rein throughout your entire infrastructure. This was obviously sub-optimal so layered defense came to be. Many have compared this to the layered defense of the accent castles, and I find that very apt.

Take the above picture I found online searching for a good illustration. I can see several layers of defense here. In accent times it was not uncommon to have a large moat around the property, possibly filled with something hazardous like crocodiles, pariahs, etc. Then you have large, tall walls with sharpshooters on top and guard towers ready to stop any that try to scale the walls. Then if you made it across the moat and over the walls you had more security guards to contend with. Once you get past them you have several levels of locked doors to get through before you get to the room with the crown jewels in them. See what I mean by layered defense, once you breach one layer you have many more to content with. If we translate this online security, you start with your border firewall, then you have a DMZ firewall, followed by a segmentation firewall and finally a host-based firewall on the server. Additionally there should be access control lists throughout to restrict traffic. Ideally these firewalls are from different vendors to make things harder for the threat actor, aka criminal, aka hacker. If someone manages to breach your checkpoint firewall, they can’t breach the Fortinet firewall the same way. The name of the game here is the more layers you have the more likely it is that a threat actor can’t get in and if they do manage to get in, it will be slow enough for you to notice and kick them out.

Network Segmentation

This is really just an extension of defense in depth, and it involves splitting your environment into many smaller environments. The saying “don’t put all your eggs in the same basket” is very applicable here. If we go back to the castle analogy, do you think it would be better to have all your valuables in one large room, or split them up into multiple smaller rooms? Obviously, you want to split them into multiple different rooms, each with their own lock. The same applies to your network environment, how you segment is design decision and there is no one right answer. One popular route, high level, is to segment (or group) like things together. For example, one segment is payroll and HR system, billing system in another, common service (email, file shares, DNS, authentication servers, etc) in another, etc. It is always recommended that user systems are in their own segment, possible even one segment per floor per building. You would then control cross segment traffic through some sort of access control device like firewall, router ACL or ZTNA device (defined later). Typically only traffic from a user segment to a non-user segment is allowed, traffic between user segments, or between non-user segment is typically not allowed. There is typically no reason for HR systems to talk to customer billing system, or for one user system to talk to other user segments.

Least Access Principle

This is also sometimes known as role base access. This is based on the concept that no one has access to anything they do not absolutely need in order to do their job. Under this model, for example, the CEO of a company has access to very few systems as that is not required for him do his job. They may have access to some sort of a SharePoint type system or file share, where they can access their reports, plus the company email system. If principle of least access is correctly implemented the C-Suite (CEO, CFO, CTO, etc.) will likely not have access to anything else. Engineers will have access to engineering system but only enough to successfully perform their job, they won’t have access to finance system for example. For large engineering system where there are specific teams have specific responsibilities then their permissions should match that. Say there is a dedicated Linux team and another team responsible for Windows servers and third team responsible for desktops, then the Linux team should only have access to the Linux system and no Windows system, etc. Care must be observed here though not to have such strict rules it impedes work or forces employees into what is known as Shadow IT, where employees find their own workaround the strict policies to get their job done.

Zero Trust

Now let us get back to the concept of zero trust. The first step on your zero-trust journey is to re-examine all your policies and procedures and root out as much of built-in trust as you can. Pay particular attention to your access policies to ensure that least access is being used. You can’t get very far along your zero-trust journey without having a solid inventory of all your system and exactly who needs to have what sort of access to what system. If you don’t want to buy anything new you can get pretty far by segmenting your network, implementing defense in depth and least access. However if you are going to go full on Zero trust you need to implement Zero Trust Network Access (ZTNA) technology throughout your environment. This is a system that grants access to each segment based on the user profile. The user profile dictates exactly which resource that user is allowed to access. This is why that catalog I spoke of earlier is so important. All user traffic if funneled through this ZTNA devices and thus you can’t even establish a network connection to a particular server unless you have explicitly been given permission to access that server. All users would go through the same scrutiny regardless of where they are coming from.

In traditional system, internal users would have network access to all systems and only login credentials would determine if they got into their system or not. If the user was remote, they would first have to pass through a VPN system and get authenticate there before they could connect to anything, but once the VPN OK’d them, they were trusted as internal user. With cloud-based systems, mobile computing (smartphones particularly) the whole internal vs external started to blur and so did the concept of perimeter or border.

With ZTNA every user is treated the same, doesn’t matter if the user is in the office, at home or at a coffee shop. Also doesn’t matter if the application is in a traditional company datacenter or if it is cloud-based. The ZTNA system handles everything the same, you simply authenticate to the ZTNA system, and it connects you to where you need to go, assuming you have permission to go there, regardless of where you are at.