WEBVTT

00:00.000 --> 00:01.570
>> I hope it goes without saying

00:01.570 --> 00:03.160
it is incredibly
important to keep

00:03.160 --> 00:05.080
our systems patched
and up-to-date from

00:05.080 --> 00:06.625
both a performance perspective

00:06.625 --> 00:08.860
and a security perspective.

00:08.860 --> 00:10.810
A lot of these attacks we hear

00:10.810 --> 00:13.030
about often there have
been patches to show up

00:13.030 --> 00:14.680
the vulnerabilities
those attacks

00:14.680 --> 00:17.210
exploit for weeks and
sometimes even months.

00:17.210 --> 00:19.630
It's a difficult
process to keep systems

00:19.630 --> 00:22.450
patched because vendors
push out a lot of patches.

00:22.450 --> 00:25.375
If you're not familiar with
Microsoft Patch Tuesday,

00:25.375 --> 00:26.680
where they roll
out their patches

00:26.680 --> 00:28.090
and all their software products,

00:28.090 --> 00:30.925
you will become familiar
with Patch Tuesday.

00:30.925 --> 00:33.415
It's important, just
like everything else,

00:33.415 --> 00:35.425
that we have a
documented process.

00:35.425 --> 00:37.300
With patches, we
need to document

00:37.300 --> 00:40.195
patch management and
lifecycle of patches.

00:40.195 --> 00:42.705
At first we go through
discovery phase.

00:42.705 --> 00:44.705
There's a new patch
that's been released,

00:44.705 --> 00:45.800
or more likely lots of

00:45.800 --> 00:47.795
new patches that
have been released.

00:47.795 --> 00:51.095
We have to categorize
and prioritize.

00:51.095 --> 00:53.690
We certainly want to be
able to give priority to

00:53.690 --> 00:56.645
security patches and those
patches that are urgent,

00:56.645 --> 00:58.370
and we need to develop a policy

00:58.370 --> 01:00.500
that talks about how
we're going to do it.

01:00.500 --> 01:02.210
We continue to monitor for

01:02.210 --> 01:04.360
new patches as they're released.

01:04.360 --> 01:06.020
We may have a centralized

01:06.020 --> 01:07.440
patch server that
keeps the track

01:07.440 --> 01:10.565
or gets alerts based
on these new patches.

01:10.565 --> 01:12.380
When patches are available we

01:12.380 --> 01:14.585
generally bring them
down and test them.

01:14.585 --> 01:15.950
We test those patches,

01:15.950 --> 01:18.445
of course, in non-production
environments.

01:18.445 --> 01:21.365
Maybe on a virtual
system or in a lab,

01:21.365 --> 01:22.700
because we want to
make sure that we

01:22.700 --> 01:24.440
understand any change to

01:24.440 --> 01:25.850
a baseline configuration of

01:25.850 --> 01:29.285
the systems may cause the
environment to become unstable.

01:29.285 --> 01:31.745
We want to test those patches.

01:31.745 --> 01:33.770
Not everything that's
released out there

01:33.770 --> 01:35.825
is going to have a
beneficial impact.

01:35.825 --> 01:37.370
Configuration management.

01:37.370 --> 01:40.675
We're going to document the
changes that have to be made.

01:40.675 --> 01:42.660
We've rolled out the patches.

01:42.660 --> 01:44.525
It's best if we
can automate that,

01:44.525 --> 01:47.720
which is exactly what a
central patch server will do.

01:47.720 --> 01:49.640
Windows has a product called

01:49.640 --> 01:51.755
Windows Software
Update Services,

01:51.755 --> 01:53.765
and that's a central
patch server.

01:53.765 --> 01:55.880
There are lots of other
third-party tools

01:55.880 --> 01:57.830
that will help you
manage your patches.

01:57.830 --> 01:59.360
We want to be able to provide

01:59.360 --> 02:00.680
reporting so that way we can

02:00.680 --> 02:02.000
go back and can know that we're

02:02.000 --> 02:03.860
keeping our systems up to date.

02:03.860 --> 02:06.500
Then review, optimized, repeat,

02:06.500 --> 02:07.985
so looks at our reports,

02:07.985 --> 02:09.440
figure out where
we can strengthen

02:09.440 --> 02:12.575
our processes and
start all back over.

02:12.575 --> 02:14.510
Some of the patches
may need to be

02:14.510 --> 02:16.445
rolled back at any
point in time.

02:16.445 --> 02:18.905
Usually vendors provide
the information

02:18.905 --> 02:20.975
on how to roll back
those patches.

02:20.975 --> 02:23.030
If at any point in
time we're coming into

02:23.030 --> 02:26.135
difficulty during the testing
period or after rollout,

02:26.135 --> 02:27.440
we should be able to go back

02:27.440 --> 02:29.885
a step before the
patches were installed.

02:29.885 --> 02:31.820
At the very least,
we can go back to

02:31.820 --> 02:34.460
an earlier snapshot
or a resort point.

02:34.460 --> 02:36.350
But we have to be
able to determine

02:36.350 --> 02:38.180
between that patch rollout and

02:38.180 --> 02:40.100
the recording
capabilities to determine

02:40.100 --> 02:43.050
if there's an issue that
the patch has caused.

02:43.250 --> 02:46.880
Baseline configuration.
Like I said,

02:46.880 --> 02:49.070
baseline configuration
is essential

02:49.070 --> 02:50.120
because how am I going to

02:50.120 --> 02:51.170
know when things are out of

02:51.170 --> 02:53.930
the norm if I don't
know what the norm is?

02:53.930 --> 02:56.870
When we're talking about
baseline performance we're

02:56.870 --> 02:58.010
talking about compliance with

02:58.010 --> 02:59.630
security goals and policies.

02:59.630 --> 03:01.055
Whatever we're talking about,

03:01.055 --> 03:04.210
baseline is the standard
that we want to adhere to.

03:04.210 --> 03:07.330
We'll have a baseline
security configuration,

03:07.330 --> 03:09.625
and we want to adhere
to that baseline.

03:09.625 --> 03:11.480
It's the point that's fixed in

03:11.480 --> 03:13.685
time that's tied to
what our goals are.

03:13.685 --> 03:15.725
We document baseline performance

03:15.725 --> 03:16.850
and then we monitor when we

03:16.850 --> 03:18.290
see that in order to detect

03:18.290 --> 03:20.790
things outside of the baseline.

03:21.950 --> 03:25.005
Packet and traffic analysis.

03:25.005 --> 03:27.725
Sniffer perform the
service for us.

03:27.725 --> 03:29.180
We capture packets on

03:29.180 --> 03:31.330
the network so that way
we can analyze them.

03:31.330 --> 03:32.840
We might be interested in

03:32.840 --> 03:35.210
determining what type of
traffic is on the network,

03:35.210 --> 03:37.310
what protocols that are in use,

03:37.310 --> 03:38.450
when information is going

03:38.450 --> 03:40.715
across the network
in plain text.

03:40.715 --> 03:43.475
Just like an attacker
uses a sniffer,

03:43.475 --> 03:46.730
so can administrator to learn
more about the network.

03:46.730 --> 03:49.325
Whether we're looking
at passive or active,

03:49.325 --> 03:51.274
passive is just monitoring.

03:51.274 --> 03:53.480
Active would mean we're
injecting data into

03:53.480 --> 03:56.120
the data stream just
to determine results.

03:56.120 --> 03:58.520
Also, I'll mention that
sometimes you don't even

03:58.520 --> 04:00.935
have to capture the data
to get what you need.

04:00.935 --> 04:04.180
Sometimes you can simply
analyze the flow of traffic.

04:04.180 --> 04:07.460
For instance, if I know
and I see a ton of

04:07.460 --> 04:10.835
traffic is going to a
particular server at 8:00 AM,

04:10.835 --> 04:13.370
that may tell me that's
a domain controller.

04:13.370 --> 04:15.890
Sometimes just watching
where traffic is going,

04:15.890 --> 04:17.945
is going to give me
some information.

04:17.945 --> 04:19.760
Also, the fact that traffic is

04:19.760 --> 04:22.295
encrypted tells me that
something is insensitive.

04:22.295 --> 04:25.505
That sometimes is referred
to as a side channel attack,

04:25.505 --> 04:27.380
where you're learning
about the network without

04:27.380 --> 04:29.630
really capturing the
actual information.

04:29.630 --> 04:32.495
But you're looking
through other pathways.

04:32.495 --> 04:34.925
To wrap up this last section,

04:34.925 --> 04:36.050
we talked about the patching

04:36.050 --> 04:37.520
lifecycle and how we go through

04:37.520 --> 04:38.990
a process where we have to have

04:38.990 --> 04:41.270
our policies and
procedures in place.

04:41.270 --> 04:44.120
We have to discover that
patches have been released.

04:44.120 --> 04:46.805
We have to have some means
of prioritizing them,

04:46.805 --> 04:48.290
testing them, and then

04:48.290 --> 04:50.735
rolling them out in
an orderly fashion.

04:50.735 --> 04:52.925
We continue to
monitor those patches

04:52.925 --> 04:54.880
and we're looking for
any evidence that we

04:54.880 --> 04:56.870
might need to roll
patches back in order

04:56.870 --> 04:59.270
to maintain smooth operations.

04:59.270 --> 05:01.070
We also talked about
the importance

05:01.070 --> 05:02.555
of baseline configuration,

05:02.555 --> 05:05.000
and we talked about how our
baselines must be set and

05:05.000 --> 05:08.645
documented so that way we
can detail any changes.

05:08.645 --> 05:11.000
Really, this whole
section focus on

05:11.000 --> 05:12.140
the importance of knowing

05:12.140 --> 05:14.210
your network and
monitoring your network,

05:14.210 --> 05:17.630
looking for vulnerabilities,
reviewing log files,

05:17.630 --> 05:19.460
but staying on top
of things because

05:19.460 --> 05:21.740
things can change very
quickly in the network.

05:21.740 --> 05:23.240
I want to make sure that I have

05:23.240 --> 05:24.830
the tools at my disposal and

05:24.830 --> 05:25.850
the knowledge of how to use

05:25.850 --> 05:28.890
those tools and
interpret the results.