The core tenet of zero trust architecture can be summed up as: never trust, always verify. Traditional security approaches treat a site as a fortress against the outside versus one which accepts it may be breached from inside. Your security plan should treat breaches as an inevitability rather than a possibility, and focus on the response rather than only prevention. Zero trust architecture grants better security, bottlenecks (or even stops) successful attacks, and can improve overall business functionality.
It works so well because it’s not a specific technology, it’s a strategy. Zero trust is technology agnostic (past a certain requisite level of minimum functionality). The hard part is building the policy and then maintaining it. To do so, you need to understand what you’re doing and why at every level.
Never Trust, Always Verify
Security has changed (see here on how to future-proof your MSP). We live in a post-security landscape where you have to accept security incidences as a cost of doing business rather than something you can always prevent. Total security is impossible, but you can mitigate its damage. Never trust a source even if it should be legitimate.
Many modern security problems come from an overabundance of trust inside one’s own network. What makes your job easy can make a threat actor’s job easier too.
Flat networks allow anything to talk to anything else on a given network. The flatter your network, the less work it takes to maintain but the more easily a security incident could spread. A ransomware event on the secretary’s computer probably doesn’t matter, but what about when it spreads across the network? A flat network is a plain of dry grass for the coming wildfire.
The topography of your network can matter as much as which EDR (or XDR) you use, what firewall you have, or even what email provider you use depending on the industry and required compliance. Things have just gotten more complex with the uptick in cloud services and work from home.
The situation is just going to continue getting more complicated. Each new exploit raises the bar in the arms race for security. The era of BYOD (Bring Your Own Device) and now WFH (Work From Home) have just made the need all the more obvious for zero trust architecture. Any device could be legitimate, but it can also become a threat with the right threat actors. Never trust, always verify.
BYOD and WFH
From a security standpoint, the worst thing your company can do is allow people to bring their own devices. From a social or morale perspective, the worst thing your company can do is forbid those devices (without a good reason). The cat’s out of the bag for employee devices in the workplace. You can try to implement restrictions, but it’s easier to just embrace the security implications of BYOD (and WFH).
The problem with BYOD isn’t the fact people bring their devices – it’s the lack of control over them. BYOD isn’t (typically) dangerous because of internal hackers (they may exist, but they’re rare for most businesses), it’s dangerous because the devices themselves may be compromised by the time they connect to the company WiFi or network.
WFH has the same problems, but exacerbated by the fact that you can’t control the network their device (which may not be in your purview) is on, you need a way in for their connection, and multiple services are stitched together to make this all transparent for the employee. You have the worst from BYOD, but all the way up to their connection.
How much can you trust a remote user (outside of what they need)? How much can you trust that same user knowing they might be on an unencrypted, public network? They aren’t malicious, but their network or environment is questionable at best (for most positions).
How do you strike a balance without making the security requirements onerous? You have to assume that something attached to your network is as much a way in as it is a way out for data and/or threats. Zero trust architecture changes this from a matter of who to trust to acknowledging that trust (from a security standpoint) is purely condition.
What It Means for Security
Zero trust architecture is a philosophy for security rather than a specific set of techniques. The implementation is generic at best, but follows an abstract, iterative process. You aren’t following a guide for how to do something – you’re looking at what general goals each security change should have.
Zero trust architecture distills the concept of not trusting everything (or anything) on your network to something memorable and applicable. You need to understand what attack surfaces exist which you can turn into protect surfaces. Each asset on your network performs a specific function – if it doesn’t, why is it there? The next step is to divide a network into spaces where there needs to be some form of trust, and a way to connect each microperimeter. From there, you establish an actual implementation enforcing what needs to happen as a zero trust policy (that is, put the previous findings into a sane policy) and maintain it.
There’s a lot of auditing and understanding the network setup involved for implementing zero trust architecture. You need to understand more than just what comes in and goes out of the network – you need to understand what goes on inside your network to make the business work. What ports need to be available to what networks? How do you isolate devices without choking the business?
Implementing zero trust architecture is an iterative process. Identify, survey, delineate, and then codify and maintain. These steps are effective in almost any process, but they have specific meaning for zero trust architecture. You need to establish your boundaries, then you need to figure out what happens in your purview, then you need to split up regions for sane security. Done right, this is the basis of a policy you can implement and maintain.
Identify the Protect Surface
Your protect surface is the opposite of your attack surface. Any way into your network is also a way in for potential threat actors.
Every unprotected device is a ticking time bomb if not managed properly. Every unknown device is an unknown threat. What do you need to protect overall and what do you need to protect for the business to function? It’s one thing to lose a couple rarely used PCs, it’s another when your core application server or production database gets hit. There are levels in between as well where sometimes the trade-off in security impact is worth the loss in flexibility or convenience to keep a business running.
You need to see what is an attack surface from the outside, but also, what can be used as such internally? A file share which your business depends on is essential, but it also needs some level of trust between multiple types of access. Done right, a compromised machine can only ruin data for a single department or in limited areas. Done (more) right, you have a backup to restore from because this is essential to your business.
Map the Traffic Flow
Every asset you have can create a hole in your security setup. A device needs to have a purpose where it is or else it can become a liability. A dumb, networked printer may make sense in one area, but should it have access to internal networks? It probably won’t matter (hacking is a numbers game for most basic intrusions), but it doesn’t add value at the expense of a potential risk. Each way in can be a liability, so make sure you know what has access to where and why.
This is basically creating a network map with dependencies. If a user needs access to a specific application, and a specific file share, how do they get there on the network? If it’s necessary, you probably can’t wall them off from both, but you can wall them off from other assets, ports, applications, etc. that may exist in the same microperimeter (see below) they need access to.
Define the Zero Trust Microperimeters
Divide the networks into regions which can have a sane policy. A microperimeter is effectively a subsection of your network which is secured as if each other portion is potentially hostile. This means that you are creating the equivalent of smaller LANs (like old school subnetting) but for smaller units using smarter technology for network flow (i.e. not going crazy from maintaining a traditional, paranoid subnet).
If an RDS requires a file share, they’ll probably end up in the same microperimeter, or at least have some path between them. You want assets which depend on each other to have some level of trust between them to prevent security from overwhelming functionality. Unless you’re in a high security environment, it isn’t typically acceptable to make a user jump between jump boxes to do basic computing tasks. You need to define the perimeters in the network based on both security and functionality.
Create a Zero Trust Policy
Once you know what goes together, why it goes together, and how it all goes together, you can begin creating an actual zero trust policy. Does your secretary’s machine need access to the DC? Almost definitely, but does it need access to a privileged engineering share? Probably not. Define your policy on real usage from what you measured before. We define our microperimeters based on our network mapping and what our protect surface is. A good zero trust policy is just enforcing what a network needs to function without allowing arbitrary access.
Zero trust architecture is a process and not a specific technique. How you implement depends on what you have available. A layer 7 firewall might be more efficient for making the separations less painful, but a standard layer 3 setup is good enough for most policies. The point is to separate out assets and prevent implied trust between each computing unit or microperimeter. We can always go back and change out the technology as things improve, but the general process behind creating a zero trust policy is always virtually the same, never trust, always verify.
It’s one thing to let an application server inherently trust its own database server, and another to let a random cloud service have wholesale access to your network. Base your policy on use and the minimum of what is needed to function combined with what the risk is for a given compromise. A minor compromise at a Department of Defense contractor is more impactful than the same level compromise at a franchised fast food restaurant.
Iteratively Maintain the Zero Trust Policy
Once a policy is set, it needs to be maintained. Zero trust is an iterative process. You assess the network and the resources available and you define policy based on what needs access to what and why. Business needs or technical changes can impact the previous policy and make it inefficient. You establish zero trust architecture once, but you never stop iterating over it.
Make auditing and refining your policy something which is ongoing. Small changes are easier than massive overhauls. Quarterly (or ideally more frequently) audit your resources and your network. What talks to what and why? This question is something you need to be able to answer about every line of communication internally, if not, things are falling through the cracks.
You need to keep looking for new holes and new weaknesses. What constitutes a “response” will vary depending on what you need to respond to. All that matters is that you make your policy congruent with the reality of security.
Going Forward
Zero trust architecture isn’t anything new, but the term does nicely package up concepts which have existed in security for ages. Research facilities and more secure government entities have used similar techniques, going so far as air-gapping and similar to achieve much higher stake “microperimeters”. Modern technology has made the principle easier to perform without having to make as large scale infrastructure changes and without the same headache of managing it. A modern firewall can split a network on par with air-gapping or separate networks (for most civilian purposes).
Flat networks are easy to maintain, but risky, while heavily subnetted and otherwise schismed networks are much more secure at the cost of functionality. You need to create the right balance so that your users get the best of both (where possible). Even if you can’t implement a full zero trust policy, preparing one can have its own benefits to shoring up security or even performance issues.
The very process of building a zero trust policy involves auditing the network, understanding what goes where and why, and trying to do something about the flow to prevent potentials roads of ingress and egress. Breaching a computer can breach your whole network and bring down your business, or it can inconvenience a user for an afternoon. It all boils down to how much trust each asset requires at a bare minimum to function at a business and reducing your attack surface around these requirements. Never trust, always verify.