Zero Trust: Beyond Perimeter Security
Key Points
- Jeff Crume explains Zero Trust by comparing traditional home security (fence, locks, cameras) to a model that only protects against external threats, highlighting its weakness when an attacker is already inside.
- He illustrates that relying solely on perimeter defenses leaves internal assets vulnerable, necessitating granular, layered controls on every entry point inside the “house.”
- The speaker maps this analogy to a typical web architecture (browser → web server → app server → database) and shows how conventional security uses firewalls and a DMZ to separate trusted and untrusted zones.
- He argues that a Zero Trust approach discards the simple “red‑yellow‑green” traffic‑light model, instead requiring continuous verification and strict access controls for every component, regardless of its network location.
Sections
- Zero Trust Illustrated with Home Analogy - Jeff Crume uses a house security scenario to explain zero‑trust principles, highlighting the shortcomings of perimeter‑only defenses when attackers are already inside.
- Assume Breach, Verify Continuously - The speaker argues that traditional perimeter models fail under Zero Trust, so we must treat all network zones as untrusted, assume an internal breach, and continuously verify each entity before granting trust.
- Choosing Trust Levels for Security - The speaker explains that determining the appropriate network trust level hinges on one's risk tolerance and promises a deeper dive into risk analysis in the next video.
Full Transcript
# Zero Trust: Beyond Perimeter Security **Source:** [https://www.youtube.com/watch?v=lT11tGaEC3s](https://www.youtube.com/watch?v=lT11tGaEC3s) **Duration:** 00:06:52 ## Summary - Jeff Crume explains Zero Trust by comparing traditional home security (fence, locks, cameras) to a model that only protects against external threats, highlighting its weakness when an attacker is already inside. - He illustrates that relying solely on perimeter defenses leaves internal assets vulnerable, necessitating granular, layered controls on every entry point inside the “house.” - The speaker maps this analogy to a typical web architecture (browser → web server → app server → database) and shows how conventional security uses firewalls and a DMZ to separate trusted and untrusted zones. - He argues that a Zero Trust approach discards the simple “red‑yellow‑green” traffic‑light model, instead requiring continuous verification and strict access controls for every component, regardless of its network location. ## Sections - [00:00:00](https://www.youtube.com/watch?v=lT11tGaEC3s&t=0s) **Zero Trust Illustrated with Home Analogy** - Jeff Crume uses a house security scenario to explain zero‑trust principles, highlighting the shortcomings of perimeter‑only defenses when attackers are already inside. - [00:03:06](https://www.youtube.com/watch?v=lT11tGaEC3s&t=186s) **Assume Breach, Verify Continuously** - The speaker argues that traditional perimeter models fail under Zero Trust, so we must treat all network zones as untrusted, assume an internal breach, and continuously verify each entity before granting trust. - [00:06:09](https://www.youtube.com/watch?v=lT11tGaEC3s&t=369s) **Choosing Trust Levels for Security** - The speaker explains that determining the appropriate network trust level hinges on one's risk tolerance and promises a deeper dive into risk analysis in the next video. ## Full Transcript
Hi, I am Jeff Crume.
I'm a Distinguished Engineer with IBM.
And I'd like to spend a few minutes talking with you about the concept of Zero Trust, and in particular, what does it look like?
How do we take those principles and actually apply them?
Well, we can think about an analogy in terms of home security.
So, here's our house.
And if we're trying to secure this, then the things that we might do in order to do that would be, maybe, start with a fence around the yard.
We might also put some locks on the door.
Maybe a single lock, a deadbolt lock, this sort of thing.
I might put some security cameras on the corners with some lights so that I can monitor as people come up.
And then maybe I'll put an angry dog behind the fence to give me a little bit of extra assurance and harass all the bad guys.
So what's good and what's bad about the security?
Well, the good security is that it follows the principles that we would normally accept and assume.
But what's the problem with it?
Well, it assumes, built-in, that the bad guy is on the outside.
What if that's not the case?
What if the bad guy is not here?
What if the bad guy is inside?
Going with that old movie line "the call's coming from inside the house!", if you get that reference.
Okay, what if the bad guy is inside your house, lying on your sofa, drinking your soda and ordering up pay-per-view movies?
This is going to be a problem.
All of the perimeter security controls I was relying on are doing nothing.
And, in fact, what I would have to do is add additional security mechanisms inside the house.
Locks on each of the doors to every one of the rooms, locks on the refrigerator, locks on the TV and so forth.
So Zero Trust would basically say these mechanisms I have in place are really not sufficient.
And what I'm going to need to do is do something that's more extensive.
Now, take that analogy and let's apply it to an I/T example.
If we were to do that, then let's think of a typical web architecture where we have a user with a browser or mobile device and an app.
And they're using this to traverse a network to hit a web server, which then hits an application server, which then hits a database.
Very typical web architecture that we would see in these cases.
Now, what we might do in terms of just general security best practices, very traditional,
would be put a firewall in front of all of this and a firewall behind, which limits access.
So that this person here on the outside can't get directly to the sensitive stuff here.
And the way we typically code this, or think of this, is in terms of like a traffic light where we have a red zone -- untrusted.
We have a green zone, which we consider trusted.
This is the stuff that we can control.
This is our stuff in the back-end.
And then we have this section in the middle of semi-trusted that we call the DMZ.
So red, yellow, green traffic light architecture makes perfect sense.
Except if we were applying Zero Trust.
Because what does this share in common with the house analogy I just talked about?
It's assuming the bad guy is on the outside -- and what if the bad guy is already on the inside?
Then all of a sudden this is not a DMZ, this is another untrusted zone.
And this trusted zone is, in fact, an untrusted zone as well.
So, in fact, I have to assume that everything is untrusted.
And that's really one of the principles of Zero Trust.
If I was looking at Zero Trust, one of the first things that is unique about this is we assume breach.
What does that mean?
That means we assume the bad guy is already inside in either of these cases. It means that we assume the network is hostile, for instance.
This is not the thing I trust.
Only the things that I can verify can I trust.
And that goes to the next principle, which is "verify, then trust".
So I trust only to the extent that I've verified. In the real world with humans that we know, we tend to trust them.
And if we trust them, then we don't verify them all the time.
We don't look over their shoulders.
In Zero Trust, it's a different concept.
The things that I trust the most are the things that I have verified the most.
And the things that I will continuously verify, which is another one of the Zero Trust principles.
I'm not going to list them all here, because there are too many, but these are some of the key ones.
And another one to think about here is the notion of least privilege.
The principle of least privilege has been in security for a very long time.
And it basically says, I only give you the access rights that you need in order to do your job, to do this for a specific period of time.
There is no what I often refer to as the "just in case" principle.
And just-in-case basically says, I'm going to give you access just in case you need it.
And then if you don't, well, then you don't come back and bug me and ask for more access rights.
That sounds like a good idea, but it's not Zero Trust because those privileges could then ultimately be abused.
So, in fact, what we want to do is only give the access rights you need
for the time that you need them and remove them when you don't need them anymore.
So, another way to think about all of this, then, is that we have a continuum.
And on one end is implicit trust.
Implicit trust means I trust everything and verify nothing.
On the other end of this spectrum is Zero Trust.
With Zero Trust, it's just the opposite.
I verify everything and trust nothing implicitly.
Think of that then as a spectrum.
On either end, we have these two extremes.
Now, where should I fall?
What kinds of things?
Is this the kind of home I want to live in?
Where I've got locks on the refrigerator and so forth?
It might not be the home I want to live in.
But if I'm designing a network architecture for things that's really sensitive, then I might want that level.
So, how do I know which level of trust do I need?
Well, that's going to depend.
Do I want to be on this end?
On this in this end?
It's all based upon our understanding of risk.
How much you're willing to risk and what your tolerance for that is.
And risk analysis is what I'm going to cover in the next video.
Thanks for watching.
Please remember to Like this video and Subscribe to this channel so we can continue to bring you content that matters to you.