WEBVTT

00:00:00.980 --> 00:00:01.380
You know,

00:00:01.380 --> 00:00:05.160
in the old days when I was young and we had dinosaurs

00:00:05.160 --> 00:00:07.060
through the western part of the continent,

00:00:07.830 --> 00:00:11.620
then we believed in something called perimeter‑based security.

00:00:12.070 --> 00:00:16.790
We put a hard outer shell around our networks and that was

00:00:16.790 --> 00:00:19.810
where we controlled all the traffic that came in and

00:00:19.810 --> 00:00:22.750
protected ourselves from hackers, for example.

00:00:23.600 --> 00:00:25.150
That doesn't work anymore,

00:00:25.460 --> 00:00:29.240
especially in a world where we have all sorts of wireless,

00:00:29.240 --> 00:00:33.400
whether or not we're talking Bluetooth or wireless access points,

00:00:33.730 --> 00:00:37.230
and many ways to communicate that don't come through the

00:00:37.230 --> 00:00:40.760
traditional copper or fiber into the building.

00:00:41.150 --> 00:00:45.890
We've had to migrate towards what we call a zero trust architecture.

00:00:46.140 --> 00:00:49.090
Zero trust means we don't trust anything.

00:00:49.760 --> 00:00:53.460
Each part of the system must be secure in itself,

00:00:53.820 --> 00:00:57.720
not trust on security being provided by another part.

00:00:58.330 --> 00:01:04.180
So if everything is secure in itself, even if there is a breach at one point,

00:01:04.300 --> 00:01:07.730
that shouldn't lead to a breach of other systems within

00:01:07.980 --> 00:01:10.220
that sort of trusted environment.

00:01:11.820 --> 00:01:15.790
The idea, of course, is that if an external connection is going to come in,

00:01:16.000 --> 00:01:17.940
then it should be untrusted.

00:01:18.290 --> 00:01:20.340
Is it from a trusted device?

00:01:20.350 --> 00:01:24.540
And we see this very often where we can trust certain systems

00:01:24.540 --> 00:01:29.120
based on maybe an IP address or we've used things like MAC

00:01:29.120 --> 00:01:34.150
addresses for this or some type of software built into that

00:01:34.160 --> 00:01:36.450
external machine for remote access.

00:01:37.170 --> 00:01:44.190
And internally, we also put in layers of defense between all of our systems.

00:01:44.950 --> 00:01:49.970
Implementing zero trust means that every device which is

00:01:49.970 --> 00:01:54.380
connected to a network will call that an endpoint,

00:01:55.160 --> 00:01:58.860
it's one end of a network connection so therefore,

00:01:58.860 --> 00:02:04.260
it's an endpoint, and we validate that that device itself is secure.

00:02:04.450 --> 00:02:07.630
So even if it was attacked from that network,

00:02:07.640 --> 00:02:10.810
it should still have some defenses in place.

00:02:11.790 --> 00:02:15.790
We rely a lot on multi‑factor authentication.

00:02:16.020 --> 00:02:18.940
Instead of just using a password to log in,

00:02:19.270 --> 00:02:22.420
now we try to make it more difficult so if someone does

00:02:22.420 --> 00:02:25.210
break in and knew somebody else's password,

00:02:25.360 --> 00:02:28.320
they wouldn't just automatically have access to everything.

00:02:29.250 --> 00:02:32.120
We also do a lot of network segmentation,

00:02:32.220 --> 00:02:35.810
something we'll look at in the network security domain as well,

00:02:36.270 --> 00:02:40.250
and that is we put in barriers within our internal networks

00:02:40.610 --> 00:02:44.580
and between our internal and external networks using a

00:02:44.590 --> 00:02:51.730
demilitarized zone extra nets, as well as a lot of small network segments.

00:02:52.380 --> 00:02:55.620
So let's say that in finance, there was a problem,

00:02:56.250 --> 00:02:59.990
then the only machines that should be affected would be those in

00:02:59.990 --> 00:03:05.070
finance because they are segmented off of the areas of HR or

00:03:05.080 --> 00:03:08.110
research or other parts of the organization.

00:03:09.340 --> 00:03:13.520
It used to be that I remember when single sign‑on first was being

00:03:13.520 --> 00:03:18.730
talked about in the early 1990s that they said we have to do

00:03:18.730 --> 00:03:24.290
something because the average person has 12 to 15 different user IDs

00:03:24.290 --> 00:03:26.140
and passwords they have to remember.

00:03:26.210 --> 00:03:29.730
The statistics are today that the average person has over 80

00:03:29.730 --> 00:03:33.480
different user IDs and passwords they have to remember.

00:03:33.620 --> 00:03:39.040
So coming with some type of a single sign‑on solution was a

00:03:39.040 --> 00:03:42.500
great idea then and even better idea now.

00:03:43.040 --> 00:03:48.220
If I can remember one password, I'm probably going to choose a better password,

00:03:48.630 --> 00:03:52.760
and it's going to make it a lot more useful as far as things

00:03:52.760 --> 00:03:55.950
like productivity and being able to get on without having to

00:03:55.950 --> 00:03:57.980
log in 80 different times.

00:03:58.640 --> 00:04:01.230
A good example of this is when a person wants to

00:04:01.230 --> 00:04:04.210
connect to say a wireless access point.

00:04:04.860 --> 00:04:09.780
So the user connects wirelessly to wireless access point and that wireless

00:04:09.780 --> 00:04:14.070
access point has software on it that's called RADIUS,

00:04:14.070 --> 00:04:18.510
Remote Access Dial‑In User Service, though it's not dial‑in anymore.

00:04:18.959 --> 00:04:24.090
But RADIUS was one of the very early implementations of this as a

00:04:24.090 --> 00:04:29.040
protocol and the client operates on that wireless access point that

00:04:29.040 --> 00:04:31.340
then communicates with a RADIUS server.

00:04:31.830 --> 00:04:35.180
The RADIUS server is what we call a AAA server.

00:04:35.270 --> 00:04:39.620
It does authentication, authorization, and accounting,

00:04:40.210 --> 00:04:45.670
so the three main parts of then the identity and access management model.

00:04:46.730 --> 00:04:51.000
The RADIUS client insists that the user provide a

00:04:51.000 --> 00:04:56.910
legitimate username and password, it verifies that with the RADIUS server,

00:04:57.080 --> 00:04:59.590
and then the RADIUS server comes back and says yes,

00:04:59.590 --> 00:05:03.820
that is correct and these are the permissions that that user should have.

00:05:04.020 --> 00:05:09.400
They can go to, as in this example, Application A and Application B,

00:05:09.400 --> 00:05:11.310
so they have that ability.

00:05:11.600 --> 00:05:12.370
Now,

00:05:12.380 --> 00:05:15.490
they've logged in at one point and are able to access

00:05:15.490 --> 00:05:17.870
multiple different services in behind.

00:05:18.420 --> 00:05:20.860
Now there are many different ways to implement this,

00:05:20.860 --> 00:05:26.320
but we're just trying to show you here the theory behind it and how it's

00:05:26.320 --> 00:05:34.310
often done that it can be a way to ensure that only authorized people are

00:05:34.310 --> 00:05:38.990
able to connect and that we can manage all of those people's permissions

00:05:38.990 --> 00:05:44.210
at one place on the RADIUS server, rather than having to manage it on each

00:05:44.220 --> 00:05:45.790
individual application.

00:05:46.380 --> 00:05:48.950
When we look at web‑based services,

00:05:49.230 --> 00:05:52.130
this is where we have single sign‑on for the web,

00:05:52.140 --> 00:05:55.460
often known as Federated Identity Management,

00:05:55.660 --> 00:05:59.010
using a number of different protocols like OAuth,

00:05:59.010 --> 00:06:01.230
OpenID, and SAML, for example.

00:06:02.120 --> 00:06:05.390
Let's say we have a user who goes to a merchant and wants

00:06:05.390 --> 00:06:08.090
to make an online ecommerce purchase.

00:06:09.120 --> 00:06:11.120
The merchant says okay,

00:06:11.150 --> 00:06:16.120
would you like to continue as a guest or would you like to sign in

00:06:16.220 --> 00:06:18.950
so that maybe you're going to be coming back,

00:06:18.950 --> 00:06:22.000
I can keep track of your orders, and so on,

00:06:22.450 --> 00:06:25.870
and the user says yeah, I'll create an account,

00:06:25.870 --> 00:06:28.770
I'll sign in. And the merchant says, okay,

00:06:28.770 --> 00:06:29.890
I'll give you two options.

00:06:29.900 --> 00:06:30.600
Number one,

00:06:31.470 --> 00:06:34.230
I could look after that sign in for you where you

00:06:34.230 --> 00:06:38.520
provide a user ID and a password, but that means that I,

00:06:38.520 --> 00:06:43.510
as the merchant, now have to manage all of those password resets and everything.

00:06:43.630 --> 00:06:44.970
Or instead,

00:06:45.200 --> 00:06:50.090
you probably have a social media account so why don't you instead

00:06:50.260 --> 00:06:55.850
use that social media account to log in to me because I have a

00:06:55.850 --> 00:06:59.750
relationship with an identity provider.

00:07:00.280 --> 00:07:05.380
So I will redirect you to that identity provider where you

00:07:05.380 --> 00:07:09.140
then will be requested to log into that,

00:07:09.140 --> 00:07:14.660
say a social media account, and when you do,

00:07:14.710 --> 00:07:20.150
that identity provider will put a token on your machine.

00:07:20.940 --> 00:07:25.670
I can read that token, and I trust that identity provider.

00:07:25.670 --> 00:07:28.760
They say that you're Sam, I'll believe you're Sam.

00:07:29.440 --> 00:07:33.840
And so instead of me having to manage passwords and user IDs,

00:07:33.920 --> 00:07:37.890
we can use your social media account for that.

00:07:38.540 --> 00:07:41.030
So this makes it much easier for the merchant.

00:07:41.270 --> 00:07:43.810
And let's say a few moments later,

00:07:43.810 --> 00:07:47.570
the user goes to another merchant and wants to make a purchase.

00:07:48.340 --> 00:07:49.650
The merchant says, hey,

00:07:49.850 --> 00:07:53.470
I already know you're Sam because I can see that token you have.

00:07:53.670 --> 00:07:54.790
So therefore,

00:07:54.800 --> 00:07:57.330
you don't need to log in with me and you don't even need to

00:07:57.330 --> 00:08:01.130
log back into the identity provider because your token hasn't

00:08:01.130 --> 00:08:03.040
expired yet and is still valid.

00:08:03.700 --> 00:08:06.700
So this is an example of, as we call it,

00:08:06.700 --> 00:08:13.760
single sign‑on for the web and they're used a lot today in order to make the

00:08:13.760 --> 00:08:18.430
whole relationship of ecommerce so much easier as well.

00:08:19.550 --> 00:08:23.250
We've had many different ways to implement access control,

00:08:23.250 --> 00:08:27.000
a lot of it over the years has been through directories,

00:08:27.000 --> 00:08:32.309
directory services, and a very common implementation of that has been LDAP,

00:08:32.320 --> 00:08:34.840
Lightweight Directory Access Protocol,

00:08:35.309 --> 00:08:41.030
which is a very much vendor neutral implementation that we can use that

00:08:41.030 --> 00:08:44.510
lists what a person's permissions and rights should be.

00:08:45.450 --> 00:08:49.810
We've also had other implementations, Network Information Services,

00:08:49.810 --> 00:08:51.600
and even a NIS+.

00:08:52.340 --> 00:08:55.950
The Domain Name System is a type of directory that lists,

00:08:55.950 --> 00:08:57.870
of course, the places we can go.

00:08:58.630 --> 00:09:04.460
And we've had a lot of access granted based on standards such as the

00:09:04.460 --> 00:09:10.290
X.400 and X.500 standards which are based on things like email

00:09:10.290 --> 00:09:14.900
addresses and other user IDs that are accessible,

00:09:14.910 --> 00:09:19.260
and of course, usable in many different access control implementations.

00:09:20.230 --> 00:09:23.500
We don't normally talk about vendor products,

00:09:24.160 --> 00:09:27.650
but since this is probably the most commonly used

00:09:27.660 --> 00:09:31.570
directory service in the world, we should mention it at least,

00:09:31.570 --> 00:09:33.560
and that is, of course, Active Directory,

00:09:33.560 --> 00:09:34.340
or AD.

00:09:34.480 --> 00:09:38.190
Active Directory lists all of our permissions and rights,

00:09:38.190 --> 00:09:43.880
for example, on what we are enabled to do when we,

00:09:43.880 --> 00:09:46.710
for example, are on a Windows‑based system.

00:09:48.290 --> 00:09:49.650
The key points review.

00:09:50.500 --> 00:09:55.320
We've looked at theory here when we talked about discretionary access control,

00:09:55.490 --> 00:09:57.150
and remember,

00:09:57.150 --> 00:10:02.390
the main thing about that is it allows owners and users to set

00:10:02.390 --> 00:10:06.040
up access and grant access to other users.

00:10:06.930 --> 00:10:11.000
Mandatory access control does not permit those users

00:10:11.000 --> 00:10:13.490
to grant access to other users.

00:10:14.240 --> 00:10:18.780
A role‑based access control works really well in an environment

00:10:18.790 --> 00:10:22.180
with many users needing similar permissions.