WEBVTT

00:00.079 --> 00:03.795
>> Endpoint Security
Hardening, Part 2.

00:03.795 --> 00:06.795
The learning objectives
for this lesson

00:06.795 --> 00:09.705
are to differentiate secure
boot configurations,

00:09.705 --> 00:12.615
to explore hardware-based
encryption technologies,

00:12.615 --> 00:15.315
and to explore host-based
protection technologies.

00:15.315 --> 00:19.615
Let's get started. Secure
boot configurations.

00:19.615 --> 00:21.540
Currently, we have
two main types

00:21.540 --> 00:23.250
of secure boot configurations.

00:23.250 --> 00:26.400
The first is the basic
input/output system, or BIOS,

00:26.400 --> 00:28.260
and also the unified extensible

00:28.260 --> 00:30.375
firmware interface or UEFI.

00:30.375 --> 00:31.830
Both of these are designed for

00:31.830 --> 00:34.380
the booting and the loading
of an operating system.

00:34.380 --> 00:37.579
They could be for both
computers or other devices.

00:37.579 --> 00:39.680
BIOS uses the
Master Boot Record,

00:39.680 --> 00:41.615
or MBR, for boot information,

00:41.615 --> 00:43.205
whereas the UEFI uses

00:43.205 --> 00:46.705
a GUID partition table
known as the GPT.

00:46.705 --> 00:48.810
UEFI is more advanced and

00:48.810 --> 00:51.700
allows for boot
integrity checks.

00:52.850 --> 00:56.280
Trusted Platform Module or TPM.

00:56.280 --> 00:58.200
These are specifications for

00:58.200 --> 01:00.860
hardware-based storage
of encryption keys,

01:00.860 --> 01:03.965
hashed passwords, and
other identification data.

01:03.965 --> 01:06.110
It's part of a
chipset or also it

01:06.110 --> 01:08.500
could be an embedded
function in the CPU.

01:08.500 --> 01:11.255
Each TPM has a
hard-coded, unique,

01:11.255 --> 01:13.640
and unchangeable
asymmetric private

01:13.640 --> 01:15.410
key known as the
endorsement key.

01:15.410 --> 01:17.600
This is used to create subkeys.

01:17.600 --> 01:20.240
However, when a TPM
owner takes ownership of

01:20.240 --> 01:23.380
the TPM and this will
destroy the subkeys.

01:23.380 --> 01:26.690
TPMs are becoming more and
more common because it is

01:26.690 --> 01:28.850
an embedded technology
that's already built onto

01:28.850 --> 01:31.080
our device to allow
us to store keys,

01:31.080 --> 01:32.510
and it did cause some problems

01:32.510 --> 01:34.010
when Windows 11 came out because

01:34.010 --> 01:35.840
Windows 11 was stating that you

01:35.840 --> 01:38.030
had to have a TPM to
be able to use it,

01:38.030 --> 01:39.620
and this caused
problems for a lot of

01:39.620 --> 01:41.540
people who had older
computers that

01:41.540 --> 01:42.920
might not be able to

01:42.920 --> 01:46.350
migrate over to Windows
11 because of that.

01:47.020 --> 01:49.595
We could also use secure boot.

01:49.595 --> 01:51.410
This prevents
computers from being

01:51.410 --> 01:53.770
hijacked by a malicious
operating system.

01:53.770 --> 01:56.450
It's configured with a
digital certificate from

01:56.450 --> 01:59.000
a valid operating system
vendor and then the

01:59.000 --> 02:00.620
firmware checks
the bootloader to

02:00.620 --> 02:02.555
ensure that the
certificate is valid.

02:02.555 --> 02:05.945
This requires UEFI,
but not a TPM.

02:05.945 --> 02:07.960
We can also use measured boot.

02:07.960 --> 02:10.530
This uses platform
configuration registers,

02:10.530 --> 02:12.110
or PCRs, that are in

02:12.110 --> 02:15.160
the TPM at every stage
of the boot process.

02:15.160 --> 02:17.480
It validates the hashes of key

02:17.480 --> 02:19.414
>> boot firmware, bootloader,

02:19.414 --> 02:21.200
>> kernel, and drivers to

02:21.200 --> 02:22.550
ensure that they have not been

02:22.550 --> 02:25.140
altered during the boot process.

02:25.390 --> 02:28.825
Hardware-based
encryption technologies,

02:28.825 --> 02:30.705
attestation services.

02:30.705 --> 02:33.770
These are hardware-backed
attestation that ensure

02:33.770 --> 02:34.850
the integrity of

02:34.850 --> 02:37.910
the startup and runtime
operations of a device.

02:37.910 --> 02:41.505
We can use remote attestation
services that provide

02:41.505 --> 02:43.460
a central way of interfacing

02:43.460 --> 02:45.850
with these locally
installed devices.

02:45.850 --> 02:49.770
OEMs will add a secure
boot data portion to

02:49.770 --> 02:51.185
the nonvolatile RAM or

02:51.185 --> 02:53.945
NVRAM during the
manufacturing of the device.

02:53.945 --> 02:56.464
This will contain the
signature database,

02:56.464 --> 02:58.655
the revoked signature database,

02:58.655 --> 03:01.300
and the key enrollment database.

03:02.720 --> 03:06.300
Hardware security
module, or HSM.

03:06.300 --> 03:09.290
These are network
appliances that offer

03:09.290 --> 03:12.955
centralized PKI management
for the network.

03:12.955 --> 03:15.810
They can offer key
escrow for devices.

03:15.810 --> 03:17.910
Comparing them to a
certificate server,

03:17.910 --> 03:20.405
a hardware security
module offers

03:20.405 --> 03:23.885
a smaller attack surface and
they're also tamper-evident.

03:23.885 --> 03:26.770
This helps to protect
against insider threats.

03:26.770 --> 03:28.550
The form factor
these devices come

03:28.550 --> 03:30.350
in could include rack-mount,

03:30.350 --> 03:32.885
plug-in PCIe adapters,

03:32.885 --> 03:36.059
and also USB peripherals.

03:36.440 --> 03:39.605
The trusted computing
group, or TCG,

03:39.605 --> 03:44.135
maintains a list of self
encrypting drives known as SEDs.

03:44.135 --> 03:46.070
They have their own specs
for this and they're known

03:46.070 --> 03:48.295
as the TCG Opal 2.0.

03:48.295 --> 03:50.720
Opal 2.0 is designed
to be completely

03:50.720 --> 03:53.650
transparent to the system
or the operating system.

03:53.650 --> 03:57.060
It incorporates FIPS 140-2

03:57.060 --> 04:00.315
and IEEE 1667
encryption standards

04:00.315 --> 04:02.870
and it uses an onboard
encryption processor

04:02.870 --> 04:06.390
to keep the contents of
the hard drive encrypted.

04:07.460 --> 04:11.500
Host-based protection
technologies. Now,

04:11.500 --> 04:13.420
we're all familiar with
antivirus software and

04:13.420 --> 04:15.580
originally this was
just signature-based

04:15.580 --> 04:18.370
that would scan files
looking to see if anything

04:18.370 --> 04:19.600
matched the signatures that were

04:19.600 --> 04:21.290
in the antivirus database,

04:21.290 --> 04:24.590
but now antivirus
software has evolved

04:24.590 --> 04:27.640
and to become anti-malware
software, but not only that,

04:27.640 --> 04:31.540
the techniques that it uses
to find different points of

04:31.540 --> 04:33.700
attack or malicious
activity have

04:33.700 --> 04:36.250
also improved over time as well.

04:36.250 --> 04:37.630
Now, we're looking to see

04:37.630 --> 04:39.070
if processes are being launched

04:39.070 --> 04:40.270
and we can intercept them

04:40.270 --> 04:42.135
and then it will look
for a signature match.

04:42.135 --> 04:43.960
We're also not looking
just for viruses

04:43.960 --> 04:46.210
anymore because now we
need to look for trojans,

04:46.210 --> 04:48.470
spyware, rootkits,
and ransomware.

04:48.470 --> 04:51.690
The Common Malware
Enumeration, or CME,

04:51.690 --> 04:53.140
this is where malware will be

04:53.140 --> 04:55.150
tagged with an identifier
so that it can be

04:55.150 --> 04:56.530
researched for its symptoms and

04:56.530 --> 04:59.020
its methods and that the
malware will be used,

04:59.020 --> 05:00.835
and we can use this to help

05:00.835 --> 05:03.400
update our technology
to ensure that when

05:03.400 --> 05:05.230
a new technique is noticed that

05:05.230 --> 05:08.380
we're able to create a way of

05:08.380 --> 05:09.820
preventing that or catching

05:09.820 --> 05:10.870
it and then pushing that out to

05:10.870 --> 05:14.945
our customers through their
anti-malware software.

05:14.945 --> 05:18.315
We can also use
application controls.

05:18.315 --> 05:19.960
This determines which software

05:19.960 --> 05:21.975
can be run and also by whom.

05:21.975 --> 05:23.770
The software can be limited to

05:23.770 --> 05:25.930
run only during work
hours and then from

05:25.930 --> 05:27.850
certain directories
and then only if it

05:27.850 --> 05:30.730
matches a specific
digital signature.

05:30.730 --> 05:32.990
We can use this to block
software installs as

05:32.990 --> 05:35.615
well through the use of
allow list and block lists.

05:35.615 --> 05:37.640
This is a very handy type thing

05:37.640 --> 05:39.170
to use where, for example,

05:39.170 --> 05:41.735
in some of our sites that use
electronic medical records,

05:41.735 --> 05:44.300
we have those EMR set
to not be allowed to be

05:44.300 --> 05:47.300
used on workstations
after business hours.

05:47.300 --> 05:50.330
The computer stay on because
they need to be updated or

05:50.330 --> 05:51.920
have different things ran on

05:51.920 --> 05:53.735
them as part of
managed services,

05:53.735 --> 05:56.050
but no one needs to
be accessing the EMR.

05:56.050 --> 05:58.565
A lot of times when an
attacker would get in,

05:58.565 --> 06:01.490
they can login to the EMR and
then steal the data through

06:01.490 --> 06:02.960
that workstation and then just

06:02.960 --> 06:04.750
send it straight
out of the network.

06:04.750 --> 06:06.170
There's no reason
for that type of

06:06.170 --> 06:07.710
thing to be running
after business hours,

06:07.710 --> 06:10.680
so we set those not
to be able to be run.

06:11.560 --> 06:14.865
We can also use
host-based firewalls.

06:14.865 --> 06:16.790
This is a firewall that's run on

06:16.790 --> 06:19.250
a single host and it will
protect that host only.

06:19.250 --> 06:20.690
It's not a network firewall.

06:20.690 --> 06:22.265
It will use packet filtering,

06:22.265 --> 06:26.050
ACLs to allow or block
traffic on that given host.

06:26.050 --> 06:29.405
We can also use redundant
and self-healing hardware.

06:29.405 --> 06:32.840
This is because we need
availability for our devices.

06:32.840 --> 06:34.190
Availability is critical,

06:34.190 --> 06:36.400
it's part of the CIA triad.

06:36.400 --> 06:38.780
We can use redundant components,

06:38.780 --> 06:40.640
such as power
supplies, or drives,

06:40.640 --> 06:42.830
and even computers
in clusters to help

06:42.830 --> 06:45.785
ensure that we have a
level of redundancy there.

06:45.785 --> 06:48.005
Self-healing hardware can detect

06:48.005 --> 06:49.640
and react if components are

06:49.640 --> 06:51.350
going to fail in a way

06:51.350 --> 06:53.395
that allows for
continued operation.

06:53.395 --> 06:55.130
It can also be pre-emptive by

06:55.130 --> 06:58.085
detecting and then alerting
to an impending failure.

06:58.085 --> 06:59.510
A good example of this at

06:59.510 --> 07:02.065
a very basic level are
redundant power supplies.

07:02.065 --> 07:03.500
A lot of servers can come with

07:03.500 --> 07:05.540
two power supplies in
them and if one fails,

07:05.540 --> 07:06.950
the other automatically
picks up and

07:06.950 --> 07:08.420
keeps on going and then you

07:08.420 --> 07:09.950
get an alert to let you
know that you need to

07:09.950 --> 07:11.690
come and replace
the one that died.

07:11.690 --> 07:13.280
This is a really good way to

07:13.280 --> 07:15.090
ensure the server
stays up and running.

07:15.090 --> 07:17.670
If you're looking at keeping

07:17.670 --> 07:20.660
critical devices up and

07:20.660 --> 07:22.620
running because sometimes
it's not just a server,

07:22.620 --> 07:24.410
you might need
redundant firewalls.

07:24.410 --> 07:26.330
When you're looking at
this, you need to decide

07:26.330 --> 07:28.490
what is critical and
then what can you

07:28.490 --> 07:30.650
put into it that would
allow it to stay up and

07:30.650 --> 07:33.155
running given specific
failures that

07:33.155 --> 07:35.540
you've determined in your
risk assessment would

07:35.540 --> 07:39.270
be likely or possible
in your scenario.

07:40.600 --> 07:42.680
Just like we have intrusion

07:42.680 --> 07:44.225
detection systems
for the network,

07:44.225 --> 07:46.085
we also had them for our hosts.

07:46.085 --> 07:48.440
Host-based intrusion
detection systems or

07:48.440 --> 07:50.900
HIDS are similar to the
ones we use on our network,

07:50.900 --> 07:52.610
but they're only on
a single system.

07:52.610 --> 07:55.400
They're going to monitor
the OS logs, files,

07:55.400 --> 07:57.410
and processes and
they may also use

07:57.410 --> 07:59.030
file integrity
monitoring because

07:59.030 --> 08:00.830
certain files in the system
should never change,

08:00.830 --> 08:02.360
and if they do, that could be

08:02.360 --> 08:04.585
an indication of
malicious activity.

08:04.585 --> 08:06.930
Host-based intrusion
prevention systems,

08:06.930 --> 08:08.450
or HIPS, do the same thing,

08:08.450 --> 08:11.030
but they also add the ability
to respond to the anomalies

08:11.030 --> 08:12.724
by either stopping the processes

08:12.724 --> 08:14.850
are blocking the traffic.

08:15.410 --> 08:19.680
We also can use endpoint
detection and response, or EDR.

08:19.680 --> 08:22.250
This is a centralized
managed solution

08:22.250 --> 08:24.800
and it's usually available
from a Cloud portal that

08:24.800 --> 08:27.200
monitors many systems at
once and it's looking

08:27.200 --> 08:29.995
for malicious activity
across all the systems.

08:29.995 --> 08:32.000
It will use artificial
intelligence

08:32.000 --> 08:33.710
and machine learning to monitor

08:33.710 --> 08:38.140
user and system behavior
and use that for analysis.

08:38.140 --> 08:40.730
By watching all the
devices in context,

08:40.730 --> 08:43.280
a more realistic
assessment can be formed.

08:43.280 --> 08:44.930
Then once the assessment has

08:44.930 --> 08:46.955
been determined to be malicious,

08:46.955 --> 08:50.155
then it can respond and these
responses are automated.

08:50.155 --> 08:53.030
What's really interesting
about this is you can have

08:53.030 --> 08:55.640
these EDRs installed
on your endpoints,

08:55.640 --> 08:57.050
but they're also going
to be installed on

08:57.050 --> 08:59.540
tens of thousands of other
end points around the world.

08:59.540 --> 09:01.415
What this managed solution is

09:01.415 --> 09:03.260
offering is they're
scanning all of these at

09:03.260 --> 09:06.680
the same time where someone
in another country may be

09:06.680 --> 09:08.720
exposed to a specific
type of attack and

09:08.720 --> 09:10.910
when the EDR responds to it,

09:10.910 --> 09:12.080
they're going to be able to use

09:12.080 --> 09:13.100
the machine learning and

09:13.100 --> 09:14.660
the artificial
intelligence to update

09:14.660 --> 09:16.850
their own central
detection system

09:16.850 --> 09:18.875
and then push that out
to all the customers.

09:18.875 --> 09:21.140
You're getting the benefit in

09:21.140 --> 09:22.970
almost real time of

09:22.970 --> 09:25.130
an attack that happens
nowhere near you,

09:25.130 --> 09:26.780
but you're going to get
the protection from it.

09:26.780 --> 09:28.070
This is the new way, it

09:28.070 --> 09:29.600
seems to be the
industry is shifting

09:29.600 --> 09:34.020
because we can react much
faster to intrusions this way.

09:34.750 --> 09:38.510
Finally, we have user and
entity behavior analytics,

09:38.510 --> 09:40.940
or UEBA.

09:40.940 --> 09:43.100
They scan the indicators from

09:43.100 --> 09:44.510
our intrusion
detection systems and

09:44.510 --> 09:46.640
logging systems
looking for anomalies.

09:46.640 --> 09:49.010
It's often integrated
with our SIEMs.

09:49.010 --> 09:51.230
It will use a baseline
and then compare

09:51.230 --> 09:54.470
the entity activity
to that baseline.

09:54.470 --> 09:58.450
Entities are machine
accounts across devices.

09:58.450 --> 10:00.320
It's dependent on AI to

10:00.320 --> 10:01.700
reduce false positives because

10:01.700 --> 10:02.735
you're going to
get a lot of them,

10:02.735 --> 10:04.805
especially in a large
enterprise environment.

10:04.805 --> 10:06.020
Examples of this would be

10:06.020 --> 10:07.970
Microsoft Advanced
Threat Analysis and

10:07.970 --> 10:12.840
Splunk's UEBA. Let's summarize.

10:12.840 --> 10:15.855
We discussed BIOS versus UEFI.

10:15.855 --> 10:19.040
We also went over the Trusted
Platform Modules or TPM.

10:19.040 --> 10:20.750
We discussed various types of

10:20.750 --> 10:22.669
host-based protection
technologies

10:22.669 --> 10:25.210
and hardware-based
encryption technologies.

10:25.210 --> 10:28.080
Let's do some sample questions.

10:28.080 --> 10:30.920
Question 1, a blank can

10:30.920 --> 10:33.575
filter network traffic from
a single host and block

10:33.575 --> 10:39.285
applications from connecting.
Host-based firewall.

10:39.285 --> 10:42.180
Question 2, sometimes it's

10:42.180 --> 10:44.580
known as an allow/block
list for applications,

10:44.580 --> 10:48.450
this determines what apps are
allowed to run and by whom.

10:48.620 --> 10:51.760
Application controls.

10:52.000 --> 10:54.800
Blank is a specification for

10:54.800 --> 10:57.605
hardware-based storage of keys

10:57.605 --> 10:58.370
that can be used for

10:58.370 --> 11:01.350
encryption and
identification purposes.

11:01.640 --> 11:04.980
Trusted Platform Module, or TPM.

11:04.980 --> 11:06.970
Finally Question 4,

11:06.970 --> 11:09.440
TCG maintains the TCG Opal

11:09.440 --> 11:14.070
2.0 specifications for
this type of device.

11:14.120 --> 11:17.130
Self-encrypting drives, or SEDs.

11:17.130 --> 11:18.500
I hope this lesson was

11:18.500 --> 11:21.280
helpful for you and I'll
see you in the next one.