WEBVTT

00:00.079 --> 00:03.945
>> Endpoint Security-
Hardening Part 1.

00:03.945 --> 00:06.480
This is a big topic and
I've divided it into

00:06.480 --> 00:07.680
two lessons so that we can

00:07.680 --> 00:09.865
make sure and cover everything.

00:09.865 --> 00:12.030
The learning objectives for

00:12.030 --> 00:15.885
this video are: discover
hardening techniques,

00:15.885 --> 00:19.395
define software patching
and device protection,

00:19.395 --> 00:23.170
and also explore
mandatory access control.

00:23.170 --> 00:27.590
Let's get started. Hardening is

00:27.590 --> 00:30.140
the process of making changes to

00:30.140 --> 00:32.225
the configuration of
an operating system

00:32.225 --> 00:34.760
or application to
help secure it.

00:34.760 --> 00:36.830
You create a standard or

00:36.830 --> 00:39.860
a secure configuration
for devices that allow

00:39.860 --> 00:41.990
for all necessary apps to still

00:41.990 --> 00:44.785
function but to
secure the device.

00:44.785 --> 00:46.490
The configuration should be

00:46.490 --> 00:50.070
saved so it can be deployed
again in the future.

00:51.200 --> 00:53.715
Hardening Techniques.

00:53.715 --> 00:55.900
The first step is to

00:55.900 --> 00:59.990
remove unnecessary
services and protocols.

00:59.990 --> 01:02.120
For example, if you don't need

01:02.120 --> 01:05.090
a web server software
running on your computer,

01:05.090 --> 01:08.750
then disable it, or if you
can, actually remove it.

01:08.750 --> 01:11.900
If the system doesn't
need to send email,

01:11.900 --> 01:14.290
remove all email
server software.

01:14.290 --> 01:18.695
Disable any network interfaces
that aren't needed.

01:18.695 --> 01:20.270
A lot of computers now will

01:20.270 --> 01:21.670
come with multiple interfaces,

01:21.670 --> 01:25.280
for example, an Ethernet
port and a Wi-Fi port.

01:25.280 --> 01:28.384
If you're using ethernet
and not the Wi-Fi,

01:28.384 --> 01:30.590
it's best to disable it
so that attackers can't

01:30.590 --> 01:33.325
use that as a back way
in for your network.

01:33.325 --> 01:36.730
Look for listening
ports on the device,

01:36.730 --> 01:38.030
and then block any that can't be

01:38.030 --> 01:40.445
disabled with a host firewall.

01:40.445 --> 01:43.940
Verify all user accounts
on the device are

01:43.940 --> 01:47.490
needed and they have the
appropriate level of access.

01:47.490 --> 01:49.930
A common problem in modern IT

01:49.930 --> 01:52.870
today is what we call
capability creep.

01:52.870 --> 01:55.240
For example, at some
point you may give

01:55.240 --> 01:57.070
access rights to a user

01:57.070 --> 01:59.065
when they only needed
them temporarily,

01:59.065 --> 02:01.390
but when that need
was no longer there,

02:01.390 --> 02:02.755
no one went back and removed

02:02.755 --> 02:05.230
those capabilities or
those access rights.

02:05.230 --> 02:08.320
Over time, these accumulate
until you have users

02:08.320 --> 02:09.340
that have way more

02:09.340 --> 02:11.680
privilege and access
than they actually need.

02:11.680 --> 02:13.540
The last one is disable

02:13.540 --> 02:15.940
USB ports if they're
not expressly needed.

02:15.940 --> 02:17.530
This will help
prevent people from

02:17.530 --> 02:19.150
plugging in flash drives,

02:19.150 --> 02:21.820
or maybe their mobile
device to use as

02:21.820 --> 02:26.270
an external device to help
control data exfiltration.

02:26.950 --> 02:30.590
Best Practice
Configurations. Now,

02:30.590 --> 02:33.305
this is already a fairly
complicated process,

02:33.305 --> 02:35.435
but there are groups
that have published

02:35.435 --> 02:37.490
best practice guidelines that

02:37.490 --> 02:39.860
you can use for your
own enterprise.

02:39.860 --> 02:41.180
For example, the US

02:41.180 --> 02:43.130
Department of Defense
Security Technical

02:43.130 --> 02:45.530
Implementation Guides or STIGs,

02:45.530 --> 02:49.160
and the Center for Internet
Security CIS benchmarks.

02:49.160 --> 02:51.485
These have all the
best practices

02:51.485 --> 02:53.705
for a given operating system or

02:53.705 --> 02:56.300
hardware device
that you can use to

02:56.300 --> 02:57.650
create your own best

02:57.650 --> 03:00.630
practices guideline
for your enterprise.

03:01.700 --> 03:04.740
Patching. This is a big one.

03:04.740 --> 03:08.925
Software vulnerabilities
are discovered every day.

03:08.925 --> 03:12.590
As we continue to increase

03:12.590 --> 03:14.570
the number of
software applications

03:14.570 --> 03:16.340
that we're using on our PCs,

03:16.340 --> 03:19.205
our mobile devices, our servers,

03:19.205 --> 03:21.740
keeping up with all of those
and making sure they're all

03:21.740 --> 03:25.505
patched is a very
daunting process.

03:25.505 --> 03:29.360
What is required as a patch
management process to

03:29.360 --> 03:31.160
ensure that all the
vulnerabilities are

03:31.160 --> 03:33.710
patched in the
appropriate timeframe.

03:33.710 --> 03:36.020
Patch management can be manual,

03:36.020 --> 03:39.780
automated, or be a
combination of both.

03:40.120 --> 03:43.294
To create a patch
management program,

03:43.294 --> 03:45.335
you're going to want to
look at a few things.

03:45.335 --> 03:46.790
The first is,

03:46.790 --> 03:49.700
to have a specific
person or team assigned

03:49.700 --> 03:51.665
the responsibility for obtaining

03:51.665 --> 03:53.915
and reviewing the
security bulletins.

03:53.915 --> 03:55.610
If you don't know
there's a vulnerability

03:55.610 --> 03:57.605
out there, you can't patch it.

03:57.605 --> 03:59.660
Next is a way to patch

03:59.660 --> 04:02.720
all devices regardless of
their operating system,

04:02.720 --> 04:05.440
or the applications that
might be installed.

04:05.440 --> 04:07.250
You also want to consider

04:07.250 --> 04:09.620
patch management for
your Cloud resources

04:09.620 --> 04:11.630
that may not be the same as that

04:11.630 --> 04:14.270
you would use on
your local networks.

04:14.270 --> 04:18.395
When you have all the
patches available for you,

04:18.395 --> 04:22.310
you want to review and
classify the updates that

04:22.310 --> 04:24.290
you're installing into urgent,

04:24.290 --> 04:27.300
important, and non-critical.

04:27.910 --> 04:30.950
You also want to
have a way to test

04:30.950 --> 04:35.270
patches before you actually
deploy them to live systems.

04:35.270 --> 04:37.900
I'm sure if you've been in
IT for any length of time,

04:37.900 --> 04:39.485
you have seen where

04:39.485 --> 04:41.510
Microsoft updates have caused

04:41.510 --> 04:43.865
machines to blue screen
after they reboot.

04:43.865 --> 04:45.830
This will help prevent that.

04:45.830 --> 04:47.570
You can test the patches on

04:47.570 --> 04:50.360
a little lab system or
a lab network that you

04:50.360 --> 04:52.340
create to ensure that
it doesn't create

04:52.340 --> 04:53.735
any additional problems for

04:53.735 --> 04:55.795
you after the patch
is installed.

04:55.795 --> 04:57.740
Then you're going
to want to have

04:57.740 --> 05:00.185
logging capabilities to ensure

05:00.185 --> 05:01.550
that once those patches are

05:01.550 --> 05:05.280
installed it didn't create
any new issues for you.

05:05.650 --> 05:08.450
Then the ability to immediately

05:08.450 --> 05:11.615
push out approved updates.

05:11.615 --> 05:14.870
Finally, you want to do
periodic evaluation and

05:14.870 --> 05:18.480
then full rollouts for
non-critical patches.

05:19.940 --> 05:23.215
Preventative Security Measures.

05:23.215 --> 05:25.880
These are extra little
things you can do on

05:25.880 --> 05:28.685
your systems to help
prevent attacks.

05:28.685 --> 05:31.520
The first one is local
drive encryption.

05:31.520 --> 05:35.290
This protects the data when
the system isn't running.

05:35.290 --> 05:37.910
For example, if you had
a laptop that maybe

05:37.910 --> 05:40.280
had some protected health
information on it,

05:40.280 --> 05:42.020
and the laptop was stolen,

05:42.020 --> 05:45.380
then this would help protect
the data on that laptop.

05:45.380 --> 05:48.244
Some examples of this are
Microsoft's BitLocker,

05:48.244 --> 05:51.250
TrueCrypt, and
Linux's cryptsetup.

05:51.250 --> 05:55.075
Enable no execute
and execute never.

05:55.075 --> 05:58.400
These are set in the CPUs
to keep areas of memory

05:58.400 --> 06:02.455
separated that are designated
for instructions or data.

06:02.455 --> 06:06.410
Then lastly, disable CPU
virtualization support.

06:06.410 --> 06:08.930
This can cause issues
for guest isolation,

06:08.930 --> 06:10.460
and also allow data to leak

06:10.460 --> 06:12.470
from one virtual
machine to another.

06:12.470 --> 06:14.660
Virtualization can
also be used by

06:14.660 --> 06:17.790
malware to help hide
itself from detection.

06:19.280 --> 06:23.510
Secure encrypted enclaves,
memory encapsulation.

06:23.510 --> 06:25.070
These are protected areas of

06:25.070 --> 06:27.050
memory in a database engine that

06:27.050 --> 06:30.665
only allows the data to be
decrypted on the fly in a CPU,

06:30.665 --> 06:32.890
a sock, or a protected region.

06:32.890 --> 06:35.690
Shell restrictions control what

06:35.690 --> 06:39.380
a shell is allowed
to do. Pretty basic.

06:39.380 --> 06:43.100
Then lastly, Access Space
Layout Randomization,

06:43.100 --> 06:47.730
ASLR, buffer overflow
prevention controls.

06:48.910 --> 06:51.470
These make it difficult to guess

06:51.470 --> 06:55.200
the memory locations of
executables in stored memory.

06:56.000 --> 06:59.715
Moving onto mandatory
access control.

06:59.715 --> 07:01.145
Before we go into this,

07:01.145 --> 07:02.930
I wanted to point
out that the acronym

07:02.930 --> 07:06.905
MAC is used for several things
in IT and cybersecurity.

07:06.905 --> 07:09.125
But in this particular
occurrence,

07:09.125 --> 07:11.720
we're using it for
mandatory access control.

07:11.720 --> 07:15.095
This is a fairly big
item for the test.

07:15.095 --> 07:17.540
Mandatory access control is

07:17.540 --> 07:20.065
based on security
clearance levels.

07:20.065 --> 07:21.605
Then rather than setting

07:21.605 --> 07:25.325
access controls on
resources, instead,

07:25.325 --> 07:27.830
every object and subject is

07:27.830 --> 07:30.845
given an access level
with its own label.

07:30.845 --> 07:33.425
If you're using a
hierarchical approach,

07:33.425 --> 07:37.130
subjects may access anything
in their level or below.

07:37.130 --> 07:39.920
They wouldn't be able
to go up a level.

07:39.920 --> 07:43.264
Subjects may also not change

07:43.264 --> 07:47.755
an object's label or rules
on their own account.

07:47.755 --> 07:50.310
One key thing to remember about

07:50.310 --> 07:52.800
MAC is that it's
non-discretionary.

07:52.800 --> 07:58.590
That is a testable item.

07:59.900 --> 08:04.820
SELinux. Execution
control decides

08:04.820 --> 08:06.890
what software or scripts
may be installed on

08:06.890 --> 08:09.815
a system beyond its current
baseline configuration.

08:09.815 --> 08:11.975
In Linux, this is achieved using

08:11.975 --> 08:13.730
a MAC kernel module

08:13.730 --> 08:17.090
known as the Linux
Security Module or LSM.

08:17.090 --> 08:20.510
SELinux is an example of an LSM.

08:20.510 --> 08:23.820
AppArmor is another
common example.

08:24.650 --> 08:28.370
SEAndroid. Android uses MAC

08:28.370 --> 08:31.355
through a process
known as SEAndroid.

08:31.355 --> 08:33.605
Apps are run in sandboxes.

08:33.605 --> 08:35.060
This keeps them isolated from

08:35.060 --> 08:37.315
each other and other
parts of the system.

08:37.315 --> 08:39.575
In addition, when
apps are installed,

08:39.575 --> 08:41.959
specific permissions
are granted,

08:41.959 --> 08:44.525
such as the access
to SMS texting,

08:44.525 --> 08:47.390
the ability to make
calls, or view contacts.

08:47.390 --> 08:49.745
If you're an Android user
and you install an app,

08:49.745 --> 08:52.310
you've probably seen
this before when

08:52.310 --> 08:54.650
the install process
will tell you

08:54.650 --> 08:57.080
this app is requesting the
following permissions.

08:57.080 --> 09:00.780
You can choose whether to
allow or deny that from there.

09:01.100 --> 09:04.445
Let's summarize what we
discussed in this lesson.

09:04.445 --> 09:06.545
We discussed system hardening,

09:06.545 --> 09:09.260
and also the best
practices for that;

09:09.260 --> 09:11.960
how you can get resources
online to help you create

09:11.960 --> 09:16.295
your own hardening process
in your own network.

09:16.295 --> 09:18.470
Patch management,
why it's important,

09:18.470 --> 09:21.415
and how to go about doing it
in your own organization.

09:21.415 --> 09:23.670
Mandatory access controls,

09:23.670 --> 09:24.950
and then we gave some examples

09:24.950 --> 09:27.515
with SELinux and SEAndroid.

09:27.515 --> 09:30.270
Let's hit some questions.

09:30.590 --> 09:33.960
Question number
1, true or false?

09:33.960 --> 09:38.690
MAC requires that all subjects
be classified with labels?

09:41.710 --> 09:45.290
This is true. That is a key item

09:45.290 --> 09:47.840
for MAC is that

09:47.840 --> 09:51.690
every object or subject
have its own label.

09:52.490 --> 09:55.495
Number 2, true or false?

09:55.495 --> 09:57.725
Local drive encryption
can prevent

09:57.725 --> 09:59.450
a ransomware attack since

09:59.450 --> 10:00.650
the encryption will prevent

10:00.650 --> 10:03.240
the malware from
reading your data.

10:04.720 --> 10:08.195
This is false. Local
drive encryption

10:08.195 --> 10:11.150
only protects the data when
the operating system is off.

10:11.150 --> 10:13.160
If the operating
system is running,

10:13.160 --> 10:15.635
the malware can read
the encrypted data

10:15.635 --> 10:17.330
at the same access
level that the

10:17.330 --> 10:19.100
current logged in user can do.

10:19.100 --> 10:23.650
It's not going to protect you
from a ransomware attack.

10:23.650 --> 10:26.240
Number 3, which of

10:26.240 --> 10:28.760
the following is not
a part of hardening?

10:28.760 --> 10:31.390
Remove unnecessary services,

10:31.390 --> 10:34.390
install the latest version
of Microsoft Office,

10:34.390 --> 10:37.995
verify all accounts on
the system are necessary,

10:37.995 --> 10:41.220
or close unnecessary ports.

10:42.360 --> 10:45.820
This is a little bit of a
trick question because if

10:45.820 --> 10:48.655
Microsoft Office is necessary
in your enterprise,

10:48.655 --> 10:50.140
then you're going
to want to deploy

10:50.140 --> 10:53.230
the most current version
when you deploy systems.

10:53.230 --> 10:55.360
However, the test is usually

10:55.360 --> 10:57.400
looking for what is
the best answer,

10:57.400 --> 11:00.655
and since not every organization
uses Microsoft Office,

11:00.655 --> 11:02.500
it would not be a part of

11:02.500 --> 11:03.745
a hardening process that is

11:03.745 --> 11:05.680
a generalized approach
for everyone.

11:05.680 --> 11:07.390
However, the other three,

11:07.390 --> 11:10.275
removing unnecessary services,
verifying all accounts,

11:10.275 --> 11:12.640
and closing ports would be.

11:13.880 --> 11:16.925
Number 4, true or false?

11:16.925 --> 11:19.345
A patch management
process should push out

11:19.345 --> 11:21.290
all patches as soon as they're

11:21.290 --> 11:24.360
available to decrease the
chances of compromise.

11:25.120 --> 11:28.490
This is false. Patches
should first be

11:28.490 --> 11:32.160
classified and then
tested before deployment.