Zero Trust architecture and security explained
It’s the start of the year. In Australia that means summer. In a pre-covid world that also meant summer festivals for music and food lovers (they are still happening, but the situation is… complicated). Perfect timing to address a really fun topic: Zero Trust Architecture.
Zero Trust Architecture (or just Zero Trust) is an overused term across the board in IT. Its meaning is often hard for many people to understand. If you want you can read technical articles like NIST Special Publication 800-207: Zero Trust Architecture, but I’d like to simplify and explain what it means in a TL;DR fashion.
What does Zero Trust really mean?
At the heart of most security are the authentication and authorization processes. Both are about establishing the identity of who or what wants some data and if they are allowed to have it.
- Authentication asks: who is the requester?
- Authorization asks: is the requester allowed to have access?
Fundamentally, Zero Trust is about ensuring that all requests for access to a resource have the same level of scrutiny. And that the context of the request is a part of the decision to grant access.
How Zero Trust works: authorization and authentication
You’re at a summer festival. Any kind, you pick.
You’ve booked your ticket online for venue pick-up (I know, hardly anyone does this anymore). You’re at the ticket booth saying to the staff, “I’m Betty. I booked an entry pass.” They would ask for some ID, confirm your name matches the ticket purchase, and then hand you your pass.
Then you head to the gate. The security guard looks at your pass, confirms it’s legitimate, then allows you entry.
And that, at a high level, is how most authentication and authorization systems operate.
The ticket booth is what would be called the Identity Provider.
The Festival itself would be the Service Provider.
And the gate would be a Policy Enforcement Point.
Tenants of Zero Trust
Everything is a resource
Now that you’re at the festival, there are a bunch of fun things to do. There are multiple stages of live music, chill-out areas, food stalls, licensed areas, and even VIP/backstage areas. Access to the festival doesn’t mean carte blanche access to all of these areas. Zero Trust means that these resources should be separate in their own right.
All interactions with resources are secured
Once you’ve entered, you have access to everything, and you’re having a good time.
This is the problem with older style architectures. Once an attacker is on the internal network/in the festival, they receive fewer levels of scrutiny. Their activities are assumed as acceptable. Whether or not they should be there isn’t in question. A problem with this model is that a malicious actor could just jump the fence. Or some scoundrels could wear high-viz jackets, pretend they’re workers, and simply walk in the front gate.
That’s not the case at most festivals. There will be security guards performing pass checks at a licensed area, the VIP area, backstage, and so on. In a Zero Trust sense, these are all Policy Enforcement Points. This is where the request for access is evaluated against each resource separately.
Access to a resource is granted on a per-session basis
ID checks for a licensed area are performed once at most festivals. Then you have continued access to the bar. However, if you leave and come back, or move to another licensed area, then you’re likely to have your ID checked again.
Another example is the photographer backstage. While they’re in the same location as the performers, that doesn’t mean they get to socialize with them just based on location. This is an example of Zero Trust’s least privilege principle.
Access to a resource is based on dynamic policy
Zero Trust architectures need to be dynamic in how resource access is granted. Gaining entry is dependent on the behavior and state of the entity that’s requesting access.
Think of this as not being allowed access back into the VIP area because you’ve lost your shirt. Or being cut-off at the bar because the staff thinks you’ve had one too many strawberry daiquiris.
Monitor the integrity and security of all assets
Having the ability to monitor and evaluate the integrity of assets performing requests is a prerequisite of Zero Trust. This requires telemetry on all assets that can assist in building a correct picture of the security of the asset. Like bar staff understanding how to tell if someone is drunk, or requiring people backstage to be visibly wearing their pass at all times.
Data from constant monitoring is used to improve security posture
You should be using data collected from assets to improve security posture over time. This can include baselining expected behaviors to detect outliers or the ability to identify weaknesses is the security.
Security at festivals will move people to areas of need, i.e. areas with a group of particularly disruptive individuals, or to cover areas where people have been jumping the fence. Or security might re-check a pass backstage if someone was behaving less like staff and more like a festival patron.
Security you can… trust?
What Zero Trust is not, is a turnkey solution that you can buy. It’s also not just putting all your services on the internet.
What is all this trying to say? Zero Trust is about having a design framework that allows you to govern access to resources based not only on permissions assigned to a subject (user or system) but also taking into account the task being conducted and the current status of the requester.
This in turn creates the requirement to have strong telemetry and asset tracking for IT resources. And the ability to correlate that data into actionable security insights that can be applied dynamically.
It also implicitly understands, that in practice, a modern internal network is less like an ordered, solemn workplace, and a little bit more like a mosh pit.
Are you unsure about your print environment’s security? Let’s talk…