You know,
in the old days when I was young and we had dinosaurs
through the western part of the continent,
then we believed in something called perimeter‑based security.
We put a hard outer shell around our networks and that was
where we controlled all the traffic that came in and
protected ourselves from hackers, for example.
That doesn't work anymore,
especially in a world where we have all sorts of wireless,
whether or not we're talking Bluetooth or wireless access points,
and many ways to communicate that don't come through the
traditional copper or fiber into the building.
We've had to migrate towards what we call a zero trust architecture.
Zero trust means we don't trust anything.
Each part of the system must be secure in itself,
not trust on security being provided by another part.
So if everything is secure in itself, even if there is a breach at one point,
that shouldn't lead to a breach of other systems within
that sort of trusted environment.
The idea, of course, is that if an external connection is going to come in,
then it should be untrusted.
Is it from a trusted device?
And we see this very often where we can trust certain systems
based on maybe an IP address or we've used things like MAC
addresses for this or some type of software built into that
external machine for remote access.
And internally, we also put in layers of defense between all of our systems.
Implementing zero trust means that every device which is
connected to a network will call that an endpoint,
it's one end of a network connection so therefore,
it's an endpoint, and we validate that that device itself is secure.
So even if it was attacked from that network,
it should still have some defenses in place.
We rely a lot on multi‑factor authentication.
Instead of just using a password to log in,
now we try to make it more difficult so if someone does
break in and knew somebody else's password,
they wouldn't just automatically have access to everything.
We also do a lot of network segmentation,
something we'll look at in the network security domain as well,
and that is we put in barriers within our internal networks
and between our internal and external networks using a
demilitarized zone extra nets, as well as a lot of small network segments.
So let's say that in finance, there was a problem,
then the only machines that should be affected would be those in
finance because they are segmented off of the areas of HR or
research or other parts of the organization.
It used to be that I remember when single sign‑on first was being
talked about in the early 1990s that they said we have to do
something because the average person has 12 to 15 different user IDs
and passwords they have to remember.
The statistics are today that the average person has over 80
different user IDs and passwords they have to remember.
So coming with some type of a single sign‑on solution was a
great idea then and even better idea now.
If I can remember one password, I'm probably going to choose a better password,
and it's going to make it a lot more useful as far as things
like productivity and being able to get on without having to
log in 80 different times.
A good example of this is when a person wants to
connect to say a wireless access point.
So the user connects wirelessly to wireless access point and that wireless
access point has software on it that's called RADIUS,
Remote Access Dial‑In User Service, though it's not dial‑in anymore.
But RADIUS was one of the very early implementations of this as a
protocol and the client operates on that wireless access point that
then communicates with a RADIUS server.
The RADIUS server is what we call a AAA server.
It does authentication, authorization, and accounting,
so the three main parts of then the identity and access management model.
The RADIUS client insists that the user provide a
legitimate username and password, it verifies that with the RADIUS server,
and then the RADIUS server comes back and says yes,
that is correct and these are the permissions that that user should have.
They can go to, as in this example, Application A and Application B,
so they have that ability.
Now,
they've logged in at one point and are able to access
multiple different services in behind.
Now there are many different ways to implement this,
but we're just trying to show you here the theory behind it and how it's
often done that it can be a way to ensure that only authorized people are
able to connect and that we can manage all of those people's permissions
at one place on the RADIUS server, rather than having to manage it on each
individual application.
When we look at web‑based services,
this is where we have single sign‑on for the web,
often known as Federated Identity Management,
using a number of different protocols like OAuth,
OpenID, and SAML, for example.
Let's say we have a user who goes to a merchant and wants
to make an online ecommerce purchase.
The merchant says okay,
would you like to continue as a guest or would you like to sign in
so that maybe you're going to be coming back,
I can keep track of your orders, and so on,
and the user says yeah, I'll create an account,
I'll sign in. And the merchant says, okay,
I'll give you two options.
Number one,
I could look after that sign in for you where you
provide a user ID and a password, but that means that I,
as the merchant, now have to manage all of those password resets and everything.
Or instead,
you probably have a social media account so why don't you instead
use that social media account to log in to me because I have a
relationship with an identity provider.
So I will redirect you to that identity provider where you
then will be requested to log into that,
say a social media account, and when you do,
that identity provider will put a token on your machine.
I can read that token, and I trust that identity provider.
They say that you're Sam, I'll believe you're Sam.
And so instead of me having to manage passwords and user IDs,
we can use your social media account for that.
So this makes it much easier for the merchant.
And let's say a few moments later,
the user goes to another merchant and wants to make a purchase.
The merchant says, hey,
I already know you're Sam because I can see that token you have.
So therefore,
you don't need to log in with me and you don't even need to
log back into the identity provider because your token hasn't
expired yet and is still valid.
So this is an example of, as we call it,
single sign‑on for the web and they're used a lot today in order to make the
whole relationship of ecommerce so much easier as well.
We've had many different ways to implement access control,
a lot of it over the years has been through directories,
directory services, and a very common implementation of that has been LDAP,
Lightweight Directory Access Protocol,
which is a very much vendor neutral implementation that we can use that
lists what a person's permissions and rights should be.
We've also had other implementations, Network Information Services,
and even a NIS+.
The Domain Name System is a type of directory that lists,
of course, the places we can go.
And we've had a lot of access granted based on standards such as the
X.400 and X.500 standards which are based on things like email
addresses and other user IDs that are accessible,
and of course, usable in many different access control implementations.
We don't normally talk about vendor products,
but since this is probably the most commonly used
directory service in the world, we should mention it at least,
and that is, of course, Active Directory,
or AD.
Active Directory lists all of our permissions and rights,
for example, on what we are enabled to do when we,
for example, are on a Windows‑based system.
The key points review.
We've looked at theory here when we talked about discretionary access control,
and remember,
the main thing about that is it allows owners and users to set
up access and grant access to other users.
Mandatory access control does not permit those users
to grant access to other users.
A role‑based access control works really well in an environment
with many users needing similar permissions.