WEBVTT

00:00.000 --> 00:02.070
>> We can't talk about
network operations

00:02.070 --> 00:03.074
>> in the day-to-day

00:03.074 --> 00:04.620
>> without talking
about the importance of

00:04.620 --> 00:06.855
scanning and monitoring
your network,

00:06.855 --> 00:08.605
as well as patching.

00:08.605 --> 00:11.150
We'll talk a bit
about log reviews and

00:11.150 --> 00:13.520
scanning for ports and
other vulnerabilities.

00:13.520 --> 00:15.360
We'll talk about
managing patches,

00:15.360 --> 00:16.980
distributing them, and being

00:16.980 --> 00:19.425
able to roll back
patches as necessary.

00:19.425 --> 00:21.840
We'll look at the
significance of baselines

00:21.840 --> 00:25.630
then talk about packet
and traffic analysis.

00:25.640 --> 00:29.100
One of the processes that
we're always considering is

00:29.100 --> 00:30.480
the possibility of events and

00:30.480 --> 00:33.165
incidents and materializing
on the network.

00:33.165 --> 00:34.635
We talk about an event,

00:34.635 --> 00:37.050
it's really just a
measurable change in state.

00:37.050 --> 00:40.140
DNS service started,
DNS service stopped.

00:40.140 --> 00:41.815
It's neither here nor there.

00:41.815 --> 00:43.730
When we have events
that are negative

00:43.730 --> 00:45.860
or have a negative
event on our network,

00:45.860 --> 00:47.855
we consider that
to be an incident.

00:47.855 --> 00:50.000
A lot of times we
can associate that

00:50.000 --> 00:52.220
and say that a third
has materialized.

00:52.220 --> 00:53.660
We want to make sure that we use

00:53.660 --> 00:55.700
our due diligence and
stay knowledgeable on

00:55.700 --> 00:57.110
the various types
of attacks that are

00:57.110 --> 00:59.285
current and on the horizon.

00:59.285 --> 01:01.520
We also want to make sure
that we have tools and

01:01.520 --> 01:04.340
police so that way we
can detect those events.

01:04.340 --> 01:06.380
When we talk about
being knowledgeable

01:06.380 --> 01:07.490
and doing our research,

01:07.490 --> 01:10.100
we usually consider that
to be threat intelligence,

01:10.100 --> 01:11.510
making sure we
have the tools and

01:11.510 --> 01:12.770
expertise in place so that

01:12.770 --> 01:14.090
way we can make good decisions

01:14.090 --> 01:15.980
based on threats is important.

01:15.980 --> 01:17.735
They're obviously going to be

01:17.735 --> 01:19.370
other sources of information,

01:19.370 --> 01:21.110
like lots of databases that

01:21.110 --> 01:23.585
indicate common threats
and vulnerabilities.

01:23.585 --> 01:25.700
We can sign up for
notifications from

01:25.700 --> 01:28.160
these third-party
resources and can also

01:28.160 --> 01:30.260
configure notifications
and alerts for

01:30.260 --> 01:32.750
our network to indicate that
something has happened,

01:32.750 --> 01:34.760
like percentage of
network utilization

01:34.760 --> 01:36.650
increasing or certain types

01:36.650 --> 01:38.630
of traffic detected
on the network.

01:38.630 --> 01:40.700
It's all about detecting
at any sort of

01:40.700 --> 01:42.785
event that might have
a negative impact.

01:42.785 --> 01:46.280
We often think of SIEMs
systems in this case.

01:46.280 --> 01:48.830
That security incident
and event manager

01:48.830 --> 01:52.165
or a security information
and event manager.

01:52.165 --> 01:54.875
These are the systems
I put it all together.

01:54.875 --> 01:57.425
We have agents running
on various firewalls,

01:57.425 --> 02:00.800
routers and honeypots, all
these different systems.

02:00.800 --> 02:03.020
Ultimately, those agents report

02:03.020 --> 02:05.060
to a central management
console where we can

02:05.060 --> 02:06.740
look at the big picture
of what's happening on

02:06.740 --> 02:09.655
the network and try to
correlate the details.

02:09.655 --> 02:12.650
Activity on one server
may seem very benign.

02:12.650 --> 02:14.360
But when you see that
same activity on

02:14.360 --> 02:16.760
>> multiple servers, that
might be an indication

02:16.760 --> 02:18.750
>> that there's a
greater threat.

02:19.100 --> 02:22.110
Simple Network
Management Protocol.

02:22.110 --> 02:24.830
SNMP [NOISE] is a protocol
and a service that

02:24.830 --> 02:26.600
devices or information is

02:26.600 --> 02:28.325
tracked within our organization.

02:28.325 --> 02:32.165
Specifically, configuration
and security-related issues.

02:32.165 --> 02:35.120
Now, there's an SNMP
manager tool that I

02:35.120 --> 02:38.900
something called a MIB,
management information base.

02:38.900 --> 02:40.910
That's just a
formatted text file

02:40.910 --> 02:42.050
that is designed to collect

02:42.050 --> 02:43.700
information on certain types of

02:43.700 --> 02:46.130
thoughts or activities
that I can scan for.

02:46.130 --> 02:49.670
The SNMP manager takes on
information and is able to

02:49.670 --> 02:51.695
translate it to more
helpful information

02:51.695 --> 02:53.930
that will be useful
to a network manager.

02:53.930 --> 02:56.330
You can see over on the
right that might not be

02:56.330 --> 02:58.835
particularly meaningful
but ultimately,

02:58.835 --> 03:00.335
with good reporting software,

03:00.335 --> 03:01.715
it could pull out issues,

03:01.715 --> 03:04.010
drop packets, different
types of traffic on

03:04.010 --> 03:06.865
the network and different
devices on the network.

03:06.865 --> 03:08.660
SNMP provides a lot of

03:08.660 --> 03:10.810
information for
managing the network.

03:10.810 --> 03:14.570
SNMP version 3 is the latest
and is also the only type

03:14.570 --> 03:16.115
that transmits this information

03:16.115 --> 03:18.590
across the network in
encrypted fashion.

03:18.590 --> 03:20.720
Everything else
census information

03:20.720 --> 03:22.250
that's been captured
across the network,

03:22.250 --> 03:25.700
unencrypted and SNMP could
be compromised and help

03:25.700 --> 03:27.020
an attacker figure out what's on

03:27.020 --> 03:30.720
your network and what
vulnerabilities exist.

03:31.780 --> 03:34.160
In addition to monitoring,

03:34.160 --> 03:35.930
we have to know what
we're looking for.

03:35.930 --> 03:38.860
You can't just look, you
have to look with a purpose.

03:38.860 --> 03:40.400
What we've got to look at is

03:40.400 --> 03:43.130
the various controls and
systems that we have in place

03:43.130 --> 03:45.844
>> and determine what
our expectations are.

03:45.844 --> 03:48.230
>> What amount of error
rate is acceptable?

03:48.230 --> 03:50.825
How much utilization
is too much?

03:50.825 --> 03:52.685
What about packets
being dropped?

03:52.685 --> 03:55.195
At what point in time does
that become an issue?

03:55.195 --> 03:58.100
None of those questions are
ones that I can answer.

03:58.100 --> 03:59.525
It really varies on your network

03:59.525 --> 04:01.595
and the type of traffic
that you transmit.

04:01.595 --> 04:03.470
The bottom line is, these are

04:03.470 --> 04:05.450
some things that we
need to consider and

04:05.450 --> 04:07.400
these metrics are
frequently things that we

04:07.400 --> 04:10.265
monitor along with a
slew of other metrics.

04:10.265 --> 04:11.960
The purpose here is
knowing what we're

04:11.960 --> 04:13.490
looking for and what

04:13.490 --> 04:18.995
our network performance
expectations are. Log review.

04:18.995 --> 04:22.165
Many times we think we go
to our logs after the fact.

04:22.165 --> 04:24.570
We've had some
negative event happen,

04:24.570 --> 04:26.425
so let's go check the logs.

04:26.425 --> 04:29.240
If we're proactive in
monitoring our logs,

04:29.240 --> 04:31.490
many times we can see an
event as it begins to

04:31.490 --> 04:33.080
materialize and we don't

04:33.080 --> 04:35.035
have to wait until
after the fact.

04:35.035 --> 04:38.135
Most devices have
some logging feature.

04:38.135 --> 04:41.390
Again, these help us look
at the big picture and

04:41.390 --> 04:43.490
>> spot any anomaly
or thing that is

04:43.490 --> 04:45.200
>> indicative for it's something

04:45.200 --> 04:46.820
on to the normal is happening.

04:46.820 --> 04:48.200
We want to make sure that our

04:48.200 --> 04:49.580
logs are stored in such a way

04:49.580 --> 04:52.385
that they can't be
tampered with or modified.

04:52.385 --> 04:54.770
That would involve
using hashes that to

04:54.770 --> 04:57.350
make sure that there's
no modification.

04:57.350 --> 04:59.030
We really want to
be able to review

04:59.030 --> 05:01.580
those logs and see if we can
preemptively determinant

05:01.580 --> 05:03.200
that hack is happening or

05:03.200 --> 05:06.215
at least the diaphysis
and suspicious activity.

05:06.215 --> 05:08.720
We want to be able to
correlate this fox across

05:08.720 --> 05:13.100
multiple systems and
we do that with SIEMs.

05:13.970 --> 05:16.230
Port scanning goes hand in

05:16.230 --> 05:18.415
hand with vulnerability
scanning.

05:18.415 --> 05:21.425
What we're looking for
is known weaknesses.

05:21.425 --> 05:23.255
When we're scanning
for open ports,

05:23.255 --> 05:25.780
those are points that
have services installed.

05:25.780 --> 05:27.650
We have to remember
that a port is

05:27.650 --> 05:30.005
really just access
into our system.

05:30.005 --> 05:32.450
If my system is
listening on port 80,

05:32.450 --> 05:34.955
it's allowing web-based
traffic to come in.

05:34.955 --> 05:38.120
If we have too many ports
or unexpected ports,

05:38.120 --> 05:41.245
then we have unexpected
pathways into our system.

05:41.245 --> 05:43.460
The way you close
the ports is to

05:43.460 --> 05:45.605
remove the software
that opens the port.

05:45.605 --> 05:47.000
Port scans are usually

05:47.000 --> 05:50.520
the first step in an
attempted compromise.