- In this lesson,
we're gonna focus in on zero trust,
which is an emerging but extraordinarily important topic.
Zero trust, you'll sometimes see abbreviated as ZT,
is a security framework
that requires all subjects, all assets,
and all workflows to be authenticated, authorized,
and here's the key,
continuously validated before being granted
or keeping access to applications and data.
Think about what we do now, right?
We assign permissions, and those are the permissions,
the rights and permissions you have.
And if you have privilege,
like you're an admin, domain admin, enterprise admin,
root user, superuser in the Unix or Linux world, right,
you have those privileges,
those rights and permissions all the time.
Here we're saying,
"Uh-uh, that's not what we're gonna do," right?
That everything has to be authenticated, authorized,
and continuously validated
before granting or keeping access to applications and data.
So it is an entirely, entirely different way, right,
of looking at trust in an environment.
Now the goal is to prevent unauthorized access
to data and services
coupled with making access control enforcement
absolutely as granular as possible.
So when we think about a zero trust network
or the view of a zero trust network,
these are the assumptions that we're basing it off on.
No implicit zone trust, no ownership assumptions,
the fact that our connections will be insecure,
and that we wanna have a consistent security policy.
So no implicit zone trust means
that the entire enterprise private network is
not to be considered an implicit trust zone.
Now, that's again another way of thinking things, right?
We've always thought about our internal network
as the trusted network.
Here we're saying,
"Nope, even though it's our enterprise,
even though it's our private network,
we're not gonna consider it an implicit trust zone."
That assets should always act
as if an attacker is present on the enterprise network.
So we should always make an assumption
that even on our private network,
there is an attacker.
The second is no ownership assumptions.
And that's the assumption
that devices that are on our network may or may not be owned
or configurable by the enterprise.
So you could well have devices in your environment
maybe that are personally owned by a user,
maybe their cell phone,
or perhaps by a vendor,
and that not all of your resources,
the enterprise-owned resources are
in an enterprise-owned infrastructure.
Maybe they're your devices that are in, you know,
other networks, or other environments,
or mobile, or at someone's home.
So no ownership assumptions that, you know, that you own it,
that you're configuring it, right,
that you've got complete control.
The third is insecure connections.
And that's a remote subject should assume that local,
meaning a non-enterprise-owned network,
is a hostile network.
So we're gonna assume that, you know,
all our other networks are hostile,
that our connections are hostile.
And we're gonna assume that all traffic is being monitored
and potentially modified.
It's kind of a depressing view, right,
because we're saying,
assume you're always being attacked, right?
Don't make any assumptions
about ownership and configuration.
And assume that your connections are all insecure.
And then the last part is
that we should have a consistent security policy.
So assets and workloads should retain their security posture
when moving to or from an enterprise-owned infrastructure.
So our security posture shouldn't change
depending upon location.
So no implicit zone trust, no ownership assumptions,
fact that our connections should all be assumed
to be insecure,
and that we wanna really have a consistent security policy.
Now the core principles of zero trust are
actually really-well detailed and discussed
in another NIST special publication.
NIST being National Institute of Standards and Technology,
this is Special Publication 800-207,
really one of the best documents I've seen on zero trust.
And they talk about four core principles:
continuous verification, access limitation,
we're gonna limit the blast radius,
think of it as a bomb going off,
and we want to automate.
Continuous verification says
we're always, always, always,
always, always, always going to verify access
all the time for all resources.
That's our continuous verification.
Our access limitation principle will say access
to individual enterprise resources is going to be granted
on a per-session basis.
So just because you had access yesterday doesn't mean
you're gonna have access tomorrow.
Limit the blast radius
so that we wanna be able to minimize the impact
if the internal or external resources are breached.
Now, we might do that with segmentation.
We might do that with having least privilege,
meaning that we're signing the least rights and permissions
necessary to do a job,
but we wanna make sure
that if internal or external resources are breached, right,
the impact is small.
We wanna limit the blast radius.
And lastly that we can't do this manually.
If we're going to implement zero trust,
we really, really have to have automated processes.
So we have to automate content collection and response,
whether that's in credential management or in workloads,
or how we configure and manage and provision our endpoints
or our SIEMs,
as well as the intake and processing
of our threat intelligence.
We'll be talking a lot more about automation
at different points later in this course.
So let's talk from a conceptual or high-level view,
how do we actually implement a zero-trust environment?
And to do that,
we need to talk about control and data planes.
And you might be thinking,
"A plane? What's a plane?"
Well, in networking,
a plane is this abstract concept
of where certain processes take place.
And in a zero-trust environment,
there needs to be a separation,
also known as the control plane, and the data plane.
Now the control plane is used by infrastructure components
to maintain and configure assets,
access control, and communication security.
In a zero-trust environment,
requests for access are gonna be made
through the control plane.
And then a data plane is used for communication
or moving data between software components.
So going back to SP 207,
the NIST publication on zero trust architecture,
let me share with you this visual
of what the architecture looks like.
Above the dotted line, we have the control plane.
Below the dotted line, we have the data plane.
Up in the control plane,
this is where we have a policy decision point.
There's two components there:
a policy engine and a policy administrator.
And below the line,
this is where we actually have our assets in the data plane
and where these systems are going to communicate
with each other.
So we start with our subject,
trying to access a system,
but they're untrusted to begin with, right?
So they're on a system.
They've asked for some access.
They're untrusted.
They stop and hit this policy enforcement point.
We now come up to the control plane,
up to our policy decision point
where our policy engine
and then our policy administrator will make
the stop, go, yes, no, yay, nay decision, right?
If it is trusted, that information comes back down,
and now they have been trusted,
and they can access that enterprise resource.
And that's gonna happen every single time they try to access
that enterprise resource.
So we have a control plane making all those decisions.
We have the data plane,
who becomes the recipient or the beneficiary, if you will,
of those decisions.
So let's talk a little bit more about what do we mean,
what's a policy engine?
What's a policy administrator?
What's a policy decision point,
or a policy enforcement point?
And as we're going through this,
keep drawing in mind as I'm defining them to you.
The policy decision point focuses really as the gatekeeper,
and it has two logical components.
It has the policy engine and the policy administrator.
Now the policy engine, or the PE,
is responsible for the ultimate decision
to grant access to a resource for a given subject.
The policy administrator,
remember that's the second part
of the policy decision point.
We had two components.
The policy administrator, or the PA,
generates any necessary session-specific authentication
and authentication token,
or credential used to access the enterprise resource.
And then when we come down below the line,
that's where we have our policy enforcement point.
And the PEP is responsible for enabling, monitoring,
and eventually terminating the connections
between a subject and an enterprise resource.
Now this is a really big topic.
And there's a lot of pieces here.
I like that the NIST document.
I think it's really helpful for studying a little bit more.
You will not have to have really an in-depth understanding
for the exam,
but you do need to understand this
from a fundamental concept or principle perspective.
And later on when we're talking
about access control and authentication,
we're gonna revisit a lot of these zero-trust concepts.
So that, my friends, brings us to a three-second challenge,
five challenge questions, three seconds each.
I know you know how to do this now.
Ready? Let's do it.
The premise that trust is never granted implicitly
but must be continually evaluated.
One, two, three.
Oh, everybody's gonna get this one right?
Let's do it.
ZT, or zero trust.
Used in ZTA, that's zero trust architecture,
by infrastructure components
to maintain and configure assets, access control,
and communication security.
Going back to which component it was.
One, two, three.
And that's gonna be the control plane.
Used in ZTA for communications between software components.
Well, if it's not the control plane, it must be?
One, two, three.
That's the data plane.
The ZTA logical component responsible
for the ultimate decision to grant access to a resource
for a given subject.
One, two, three.
It's gonna be the policy engine, or the PE.
I know for many of you, this is all new.
So you may have to go back through it more than once.
And lastly, the ZTA logical component responsible
for enabling, monitoring,
and eventually terminating connections
between a subject and an enterprise resource.
One, two, three.
That's gonna be our PEP, our policy enforcement point.
All right, so let's do a security and action case study
about zero trust.
I'm gonna give you a zero trust scenario.
I'm gonna ask you a question.
After we get that far, good place to put me on pause,
write down your answer,
and then we'll do the response together.
Your organization contracts with a number of third parties
for building environmental control monitoring
and maintenance, for example, smart lighting and HVAC,
across your enterprise.
Now, to provide service,
contractors need network connectivity to their devices
and to the Internet.
And your boss wants to know,
maybe your boss has been reading up on this,
wants to know if it makes sense to implement ZT,
or zero trust, in this scenario.
What would you say?
So think about that for a moment.
Put me on pause, jot down some notes,
and then we'll do a response together.
Absolutely, right?
Zero trust could allow service providers
time-sensitive access to their systems
and access to the Internet
while obscuring enterprise resources.
So only get access to what they need when they need it
for a limited amount of time,
when they have been continuously re-evaluated.
In a zero-trust environment,
each user, each device,
and the application can have its own perimeter security.
Access permissions are controlled
with individuals having just-enough
or sometimes referred to as just-in-time access.
Later on, one of our lessons,
we're gonna be talking about JIT,
or just-in-time privilege access management.
But being able to understand
how zero trust would work in your environment
and what its application is,
that, my friends, is definitely security in action.
There's your word cloud.
There's not a lot here,
but probably a lot of really unfamiliar components,
whether we're talking about the control plane,
or the data plane, or the policy enforcement point.
Probably a lot of new stuff here.
So please make sure, right,
that you can speak to everything on this word cloud
before you move on.
And when you're ready, I'll see you in the next lesson.