WEBVTT

00:00:00.340 --> 00:00:05.050
Our last topic of concern inside of managing security operations

00:00:05.050 --> 00:00:08.020
would be the supporting of digital forensics.

00:00:08.320 --> 00:00:13.510
When we think of digital forensics, ISO/IEC 27037,

00:00:13.520 --> 00:00:18.150
the digital forensics guidance has three elements to it that include,

00:00:18.250 --> 00:00:23.060
step 1, a prioritization plan to acquire the data.

00:00:23.070 --> 00:00:26.100
We should be thinking about what the likely value is of the

00:00:26.100 --> 00:00:28.830
data based on our understanding of the situation and our

00:00:28.830 --> 00:00:31.410
previous experience in similar situations.

00:00:31.420 --> 00:00:33.950
Here again, just as in incident management,

00:00:33.960 --> 00:00:40.720
we need to have a preknowledge of what the information value is

00:00:40.730 --> 00:00:43.900
and the corresponding impact and prioritization.

00:00:43.910 --> 00:00:45.480
When we talk about volatility,

00:00:45.490 --> 00:00:49.280
we're thinking about data that lives on a live system that

00:00:49.280 --> 00:00:52.900
could be lost after that system is shut down,

00:00:52.990 --> 00:00:54.730
terminated, or powered off.

00:00:54.730 --> 00:00:58.810
A little bit different behavior in the cloud, but some of the same results.

00:00:58.820 --> 00:01:01.560
Also we have to think of what's the amount of effort

00:01:01.740 --> 00:01:04.640
required to acquire the different data sources?

00:01:04.650 --> 00:01:06.240
Could vary widely.

00:01:06.250 --> 00:01:10.080
So, effort involves not only the time spent by security professionals,

00:01:10.090 --> 00:01:11.890
but also others in the organization.

00:01:11.890 --> 00:01:14.550
That could be legal advisers and the like.

00:01:14.560 --> 00:01:17.180
Step 2 is to acquire the data.

00:01:17.200 --> 00:01:20.250
If the data has not already been acquired by security tools,

00:01:20.250 --> 00:01:21.680
analysis tools, or other means,

00:01:21.680 --> 00:01:25.060
the general process for acquiring the data involves using

00:01:25.060 --> 00:01:28.470
forensics tools to collect volatile data.

00:01:28.480 --> 00:01:30.980
Here again in the cloud creating a snapshot,

00:01:30.980 --> 00:01:32.420
as we demonstrated earlier,

00:01:32.420 --> 00:01:36.140
could be all that's necessary to capture everything needed,

00:01:36.220 --> 00:01:42.570
but we need to make sure that we have this already specified based upon what

00:01:42.570 --> 00:01:46.740
kind of data should travel or can travel across a network.

00:01:46.780 --> 00:01:49.580
In step 3, we're verifying the integrity of the data.

00:01:49.740 --> 00:01:53.280
After the data has been acquired, it should be verified.

00:01:53.490 --> 00:01:56.450
It's particularly important to prove that the data has not been

00:01:56.450 --> 00:02:00.720
tampered with because you may need this for legal reasons.

00:02:00.730 --> 00:02:04.990
Data integrity verification typically consists of using tools to compute

00:02:05.000 --> 00:02:08.050
the message digest based off of a hashing algorithm.

00:02:08.060 --> 00:02:08.789
With forensics,

00:02:08.789 --> 00:02:13.060
it can be complicated in the cloud based off of privacy

00:02:13.060 --> 00:02:16.490
concerns that you may be mandated to follow,

00:02:16.500 --> 00:02:21.900
provider dependencies when it comes to the localization of particular data,

00:02:21.910 --> 00:02:25.990
who it is that is going to be responsible for the collection of the data,

00:02:26.000 --> 00:02:28.600
the physical location of that data,

00:02:28.610 --> 00:02:31.550
and also the trustworthiness of evidence based,

00:02:31.550 --> 00:02:34.250
on part, on the cloud service provider.

00:02:34.360 --> 00:02:37.090
Once the data is collected, evidence management,

00:02:37.100 --> 00:02:41.230
we're thinking of keeping a detailed log of all the steps that have been taken.

00:02:41.240 --> 00:02:42.370
In some cases,

00:02:42.380 --> 00:02:45.650
those who are responsible as a custodian may end up taking

00:02:45.650 --> 00:02:47.780
a photograph of the entire environment,

00:02:47.790 --> 00:02:50.750
and it's really important to remember to maintain the chain

00:02:50.750 --> 00:02:53.860
of custody by documenting everything.

00:02:53.870 --> 00:02:59.820
The documentation should show a chronological order of who had access to it,

00:02:59.820 --> 00:03:04.300
when was the data actually checked out, what the analysis process was,

00:03:04.310 --> 00:03:07.580
and what the disposition of it is in case it needs to

00:03:07.580 --> 00:03:09.250
be presented in the court of law.