WEBVTT

00:00.000 --> 00:02.760
>> Indicators of compromise.

00:02.760 --> 00:05.340
The learning objectives
for this lesson,

00:05.340 --> 00:07.710
are to define an
indicator of compromise,

00:07.710 --> 00:11.550
detail where indicators of
compromise can be found,

00:11.550 --> 00:14.490
and respond to indicators
of compromise.

00:14.490 --> 00:19.350
Let's get started. Indicators
of compromise or IOC

00:19.350 --> 00:21.885
can be thought of
as a clue or a sign

00:21.885 --> 00:24.840
that an intrusion has
taken place in some way.

00:24.840 --> 00:26.790
For example, if an attacker were

00:26.790 --> 00:29.130
using the technique
of password spraying,

00:29.130 --> 00:30.930
you might see that many accounts

00:30.930 --> 00:32.980
were being locked out
at the same time.

00:32.980 --> 00:35.480
In addition, your log
files are going to be

00:35.480 --> 00:38.255
filled with invalid
credential events.

00:38.255 --> 00:40.310
If an attacker has breached

00:40.310 --> 00:42.995
your network and is in the
process of stealing data,

00:42.995 --> 00:44.660
you might see an
abnormal amount of

00:44.660 --> 00:47.020
traffic exiting your network.

00:47.020 --> 00:50.390
Finally, you may see
privileged accounts being

00:50.390 --> 00:53.405
created or used
in abnormal ways.

00:53.405 --> 00:55.715
The root or administrator
level account

00:55.715 --> 00:57.905
is the crown jewels
for most attackers.

00:57.905 --> 01:00.215
What they're looking
for is to get in,

01:00.215 --> 01:02.630
gain access to that level
of account and then start

01:02.630 --> 01:05.390
using it in ways that you
wouldn't be using it.

01:05.390 --> 01:08.180
They also want to create
additional accounts that are at

01:08.180 --> 01:12.570
the same level in case their
main access gets cut off.

01:13.030 --> 01:16.160
Logging. Most devices on

01:16.160 --> 01:18.890
your network will generate
logs in some form.

01:18.890 --> 01:21.514
These logs will always contain

01:21.514 --> 01:24.905
valuable information on
locating potential IOCs.

01:24.905 --> 01:26.930
Some examples of
log files would be

01:26.930 --> 01:28.820
your operating system
events such as

01:28.820 --> 01:30.650
your window event logs and

01:30.650 --> 01:33.095
your Syslog on Linux
and Unix systems.

01:33.095 --> 01:36.380
Routers and switches will
also generate their own logs,

01:36.380 --> 01:38.345
as do access points
and printers.

01:38.345 --> 01:40.130
The problem with
logs is that they're

01:40.130 --> 01:42.230
all scattered across
your network and

01:42.230 --> 01:43.550
you have to go to each one to

01:43.550 --> 01:45.230
look for them and
then look through

01:45.230 --> 01:50.700
many events to find those
very few fleeting IOCs.

01:51.190 --> 01:55.265
We can also use packet
capture for looking for IOCs.

01:55.265 --> 01:57.440
This is when we're looking
at the network traffic

01:57.440 --> 01:59.000
down to the packet level.

01:59.000 --> 02:01.670
This requires the use of
a special tool known as

02:01.670 --> 02:04.684
a snipping tool or also
a protocol analyzer.

02:04.684 --> 02:08.850
Examples of these would be
Wireshark and TCP dump.

02:09.620 --> 02:13.340
IOC notification
sources are devices

02:13.340 --> 02:16.460
that send us the information
when they detect IOCs,

02:16.460 --> 02:18.260
rather than us having
to go and look through

02:18.260 --> 02:20.510
all those logs scattered
through our network.

02:20.510 --> 02:23.060
Examples of these
would be SIEM devices,

02:23.060 --> 02:25.910
intrusion detection or
prevention systems,

02:25.910 --> 02:28.355
file integrity
monitoring systems,

02:28.355 --> 02:30.830
data leak or loss
prevention systems,

02:30.830 --> 02:34.020
and antivirus or
antimalware software.

02:34.880 --> 02:37.765
How do we respond to an IOC?

02:37.765 --> 02:40.310
The first thing we have
to do, is prioritize.

02:40.310 --> 02:43.465
It should not be a first-come,
first-serve basis.

02:43.465 --> 02:45.995
It should be based on
the following factors.

02:45.995 --> 02:48.050
The severity and the priority.

02:48.050 --> 02:50.705
The functional impact
to your organization.

02:50.705 --> 02:53.450
The information impact.
What is being stolen,

02:53.450 --> 02:55.310
what data is being affected?

02:55.310 --> 02:59.710
Then the recoverability. We can

02:59.710 --> 03:02.035
also use our existing
security infrastructure

03:02.035 --> 03:03.385
in our responses.

03:03.385 --> 03:05.020
For example, firewall rules can

03:05.020 --> 03:06.880
be quickly created to block off

03:06.880 --> 03:11.020
traffic from leaving a network
or traffic from coming in.

03:11.020 --> 03:13.270
We can also use our intrusion

03:13.270 --> 03:16.150
prevention or intrusion
detection system rules,

03:16.150 --> 03:17.975
or access control lists rules.

03:17.975 --> 03:20.710
Endpoint protection can
be updated to look for

03:20.710 --> 03:23.680
certain files that
have been added to

03:23.680 --> 03:25.930
a system that contain
malicious content

03:25.930 --> 03:29.665
or to block specific attacks
as they're occurring.

03:29.665 --> 03:32.260
We can also update
our DLP rules.

03:32.260 --> 03:34.000
We can use scripts that contain

03:34.000 --> 03:35.500
regular expressions to help

03:35.500 --> 03:38.180
us automate some of
these activities.

03:39.080 --> 03:41.810
Triage and incident response.

03:41.810 --> 03:43.960
During triage, your first goal

03:43.960 --> 03:46.060
is to determine the
scope of the breach,

03:46.060 --> 03:48.700
how many systems have
been impacted and

03:48.700 --> 03:52.290
what has been affected?

03:52.290 --> 03:55.465
Then you need clearly
defined processes

03:55.465 --> 03:57.435
for identifying incidents,

03:57.435 --> 03:59.555
classifying those in incidents,

03:59.555 --> 04:00.790
and then responding to

04:00.790 --> 04:02.665
the incidents in the
appropriate way.

04:02.665 --> 04:04.210
The key is this needs to be

04:04.210 --> 04:06.250
created before these
type of things are

04:06.250 --> 04:07.765
occurring so that you have

04:07.765 --> 04:09.885
everything in a
documented manner.

04:09.885 --> 04:11.155
When these incidents happen,

04:11.155 --> 04:12.820
you're not going to be
thinking with a clear head.

04:12.820 --> 04:14.080
It's crucial to have

04:14.080 --> 04:18.050
these processes already
identified ahead of time.

04:18.660 --> 04:21.085
Event classification.

04:21.085 --> 04:23.680
We have four
categories of events.

04:23.680 --> 04:25.690
The first is false positive.

04:25.690 --> 04:29.205
This is something identified
as an issue, but it's not.

04:29.205 --> 04:31.180
Then we have false negative.

04:31.180 --> 04:34.285
This is a potential issues
that weren't identified.

04:34.285 --> 04:38.575
True positives are an issue
that is correctly identified.

04:38.575 --> 04:40.315
Finally, we have true negative.

04:40.315 --> 04:41.830
This is informational item that

04:41.830 --> 04:44.330
is flagged as a non-issue.

04:46.110 --> 04:50.005
We need a communications plan
in our incident response.

04:50.005 --> 04:52.495
We need to define who
are the stakeholders.

04:52.495 --> 04:53.920
This usually involves the human

04:53.920 --> 04:55.570
relations part of the company,

04:55.570 --> 04:57.985
public relations,
senior leadership,

04:57.985 --> 05:00.730
legal, law enforcement
and regulators.

05:00.730 --> 05:03.910
We also need to decide
who needs to be notified.

05:03.910 --> 05:07.045
We also need to know how
we're going to notify them

05:07.045 --> 05:08.800
and how are we going to control

05:08.800 --> 05:11.005
the release of information
about the incident?

05:11.005 --> 05:13.030
It's critical that we don't

05:13.030 --> 05:15.535
release sensitive information
about the breach.

05:15.535 --> 05:17.350
These are the types
of things that

05:17.350 --> 05:19.585
also need to be
planned ahead of time.

05:19.585 --> 05:21.875
You don't want to be
deciding these on the fly,

05:21.875 --> 05:24.440
after an incident has
already happened.

05:25.340 --> 05:28.255
Then the incident
response process

05:28.255 --> 05:30.580
we first start with preparation.

05:30.580 --> 05:31.860
We harden our systems,

05:31.860 --> 05:34.075
we create policies
and procedures,

05:34.075 --> 05:37.300
and then we create an incident
response procedure plan.

05:37.300 --> 05:40.390
Again, all of this needs
to be done ahead of time.

05:40.390 --> 05:42.505
Detection analysis.

05:42.505 --> 05:44.290
We need to decide
if an incident has

05:44.290 --> 05:46.180
occurred and then
how serious it is,

05:46.180 --> 05:48.665
from there we notify
our stakeholders.

05:48.665 --> 05:51.390
After that, we begin to
contain the incident.

05:51.390 --> 05:53.680
We limit the scope
of the breach.

05:53.680 --> 05:55.775
Once we've contained everything,

05:55.775 --> 05:58.670
we move to the eradication
and recovery phase.

05:58.670 --> 06:00.530
This is where we
remove the cause of

06:00.530 --> 06:03.220
the breach and bring things
back to where they were.

06:03.220 --> 06:05.670
Then we have a post
incident activity.

06:05.670 --> 06:08.340
This is an after action review.

06:08.340 --> 06:11.045
What can we improve?
What did we do?

06:11.045 --> 06:13.240
Well, what did we
not do so well in,

06:13.240 --> 06:15.140
and then what lessons
can we learn and

06:15.140 --> 06:18.130
then document those
for the future?

06:18.130 --> 06:22.610
Let's summarize. We went over
indicators of compromise.

06:22.610 --> 06:23.840
We discussed logging,

06:23.840 --> 06:26.135
and where log files come from.

06:26.135 --> 06:28.780
Then we discussed
the sources of IOCs,

06:28.780 --> 06:31.775
and we moved to triaging
and incident response.

06:31.775 --> 06:33.950
How to classify incidents and

06:33.950 --> 06:36.380
then coming up with a
communications plan.

06:36.380 --> 06:38.585
Let's do some example questions.

06:38.585 --> 06:40.280
Question 1.

06:40.280 --> 06:43.160
This stage of the incident
response process is

06:43.160 --> 06:47.070
focused on controlling how
far the incident has spread,

06:47.200 --> 06:52.230
this is Phase 3 or containment.

06:52.610 --> 06:55.730
Question 2. Which
of the following

06:55.730 --> 06:58.565
would you not include in
your communications plan?

06:58.565 --> 07:01.145
One, legal counsel, two,

07:01.145 --> 07:02.930
human resources, three,

07:02.930 --> 07:06.510
financial department,
four, law enforcement.

07:07.360 --> 07:11.500
This is three, the
finance department.

07:11.500 --> 07:14.150
Question 3. Which of the

07:14.150 --> 07:17.090
following would not
likely be an IOC?

07:17.090 --> 07:19.730
Ransomware demand found on PCs,

07:19.730 --> 07:22.120
a user account being locked out,

07:22.120 --> 07:24.975
abnormal bandwidth
leaving the network,

07:24.975 --> 07:29.009
excessive log entries
for invalid credentials.

07:29.180 --> 07:31.850
A user account being locked out.

07:31.850 --> 07:33.320
A single user account is

07:33.320 --> 07:34.640
a normal occurrence in

07:34.640 --> 07:36.500
the day-to-day
operations of a network.

07:36.500 --> 07:39.695
One user account would not
necessarily be an IOC.

07:39.695 --> 07:41.420
Several user accounts being

07:41.420 --> 07:42.800
locked out around the same time

07:42.800 --> 07:46.230
would be. Question 4.

07:46.230 --> 07:48.740
This technology allows
for the capture of

07:48.740 --> 07:50.720
network traffic
data so that it can

07:50.720 --> 07:53.970
be analyzed at the
packet and frame level.

07:54.350 --> 07:57.370
Sniffer or protocol analyzer.

07:57.370 --> 07:58.850
I hope this lesson was helpful

07:58.850 --> 08:01.380
for you, and I'll see
you in the next one.