In this lesson,
we're going to discuss data collection procedures.
During an incident response,
we often need to collect evidence of the cyber attack
for further analysis.
For example, if your main server
has been infected with some kind of malware
as part of an attack,
you want to get that cleared up
and get the server back online as quickly as possible
to minimize the disruption to your operations.
But if you do that,
you may erase the evidence of the attack.
That will make it impossible to figure out who did it.
Now, to overcome this challenge,
we often use digital forensic collection techniques
to make forensic images of the data on the servers,
and we use that as evidence for later analysis.
Doing that allows your incident response team
to help you get your server back online
as quickly as possible and resume operations,
but also maintain the evidence.
Your incident response team may need the evidence
because they may be working with law enforcement,
and if you're doing that,
you're probably going to seek criminal prosecution
for the attacker who broke into your system.
As part of your data collection
and evidence collection efforts,
you're going to do a lot of different things.
For example, you're going to capture
and hash the system images.
This means you're going to use tool like FTK Imager
to make an exact copy of the server's hard drive,
and then hash it
to make sure it doesn't change while you're analyzing it.
Then you're going to analyze the data you collected
using software tools.
You're going to use forensic tools like FTK,
Forensic Toolkit, or EnCase.
Then you're going to have to capture
screenshots of the machine.
What was the machine looking like
when you arrived on the scene?
You want to capture pictures of that
so you know exactly what it looked like.
You might also go back
and look at your network traffic logs and captures
and go and review all of that
and see how they moved throughout the network
as you're trying to trace back the attack,
and if you think someone was physically on your property,
you may want to capture video from the closed circuit TV.
Now, as you're collecting this data and evidence,
you want to consider the order of volatility,
which means which order things get modified quickest.
The quickest thing that gets modified
is the cache inside of the processor,
then the memory, then the swap files,
then the hard drives, right?
And you think about which one is going to get changed first.
When you do that, you have to collect things
based on that order as well,
and anything on the victim machine can be modified
if there's a threat actor on the machine, right?
We also want to collect the evidence as quickly as possible.
Then we want to take statements
from witnesses and administrators.
What did they see?
What made them think that there was an incident?
Maybe there was just someone who said,
"Hey, the mouse from my computer
all of a sudden started jumping all over the screen."
That's something you need to collect the information from
and figure out why did that happen.
Then we want to review our licensing and documentation,
and figure out
do we have the proper license for all of our systems,
and do we understand how they work,
and are they working the way that they were designed
based on the documentation?
And then of course,
we're going to track our man hours and our expenses,
because at the end of the day,
this is an incident response.
Someone is going to say, "How much did it cost us?",
and if you look at the most recent data breaches in the USA,
large companies are suffering
millions and millions of dollars of losses
in the cost of these data breaches,
both in their response efforts
as well as the value of the data that was lost.
Now that we have some basic understanding,
let's talk about data acquisition.
Data acquisition is a method and tools
used to create forensically sound copy
of the data from a source device,
such as system memory or hard disk.
Now, when you deal with acquisition,
the first question you have to ask,
"Do I have the right
to search or seize this thing legally?"
This is an important question, because in your organization,
not all devices are owned by the company.
If it's owned by the company,
yeah, you have the right to go ahead and collect it
because you work for that company
and they want you to do it.
But what if you're allowed to bring your own device?
If you're allowed to bring your own device
into the organization,
these policies can get very complicated very quickly,
because you might not be legally able
to search or seize that device
because you don't own it.
The employee does.
And so you have to make sure
that the evidence you're gathering,
you have permission to gather it.
Otherwise, that search could be inadmissible.
Another thing that makes data acquisition very complicated
is that when you get to a crime scene,
you're not just dealing with the physical world.
You're dealing with the digital world.
And so when I come into a room
and I see the lights are on, the computer's on,
how am I going to collect the data off of that computer?
Am I going to shut it down? Am I going to power it off?
Am I going to collect it when it's powered on?
All of these are valid options,
and each one has its drawbacks and benefits
depending on what you're trying to collect,
but for now, I just want you to keep in mind
the fact that you're dealing with a digital crime scene,
as opposed to just a physical one.
There is some evidence that could be lost
when you turn off a computer or shut it down,
and so you need to make sure
that you understand what you're going to do
and the procedures that you're going to deal with.
Now, this brings us to the idea
that some of this data can only be collected
when a system is on.
Some of the data can only be collected
once the system is shut down
or you suddenly remove the power.
Now, an analyst always has to think
about the order of volatility
when they collect their evidence.
First, we always want to collect anything
that is short term,
anything that is highly volatile.
So, if you start thinking about things
like the CPU registers and the cache memory,
that is very small amount of memory inside that processor,
so it's getting changed very frequently,
so you want to collect that as soon as possible.
Then we move onto other volatile memory,
which are things like system memory, routing tables,
ARP caches, process tables,
temporary swap files, and things like that.
All of those things are volatile
and are changing quite rapidly,
but not nearly as quickly
as the CPU register or cache memory.
Then we move onto data that's on persistent mass storage.
Now, in the old days, we would just say hard drive,
but nowadays, we just say mass storage,
because this includes our hard drive,
our solid state drives, and our flash drives.
All of these are persistent mass storage devices
because they will retain information
when you take the power away,
unlike memory,
but it does still change quite often,
as long as the computer is on
and people are writing or reading to that disk.
Then we're going to go ahead
and collect the things that are remotely logged,
things like our SIEM and monitoring data.
This is important
because while it is not on the system that you're analyzing,
it was already remotely logged somewhere else.
That other place somewhere else
is still being read and written to
over and over again by other systems,
and so it could modify some data,
so we want to collect that as well.
After that, we want to get anything that's physical.
This is the physical configuration and network topology,
and things of that nature.
So, if I go into the network
and I start looking at the way it's wired
and just say, "Okay, this computer was talking to a switch,
which talks to this router,"
and I can start mapping out and collecting the information.
After that, we're going to collect archival media.
Now, what is that?
It's things like backup tapes and offsite storage.
Things that are written once and then aren't touched again.
For instance, you might write something to a CDR or a DVR.
Once it's written to that disk,
it's going to maintain that data on it
until you destroy the disk,
so it is our lowest priority of collection,
but still something we want to collect
at the end of the day.
Now, one piece of warning that I want to give you
is something that a lot of junior analysts
would neglect to think about.
When you're dealing with the Windows registry,
a lot of people think about the Window registry
as being on the hard disk,
and while most of the Windows registry
is stored on the hard disk,
there are many key areas like the HKLM\Hardware component
that only stores themselves in memory.
So, you want to analyze that registry part
using a memory dump instead.
When I analyze the registry,
I usually do it via memory dump first,
and then I can go back
and do it off the hard drive afterward.
That way, anything that was missed in memory
might get caught by the hard drive,
and I could see both things.
When you're dealing with things like the \Hardware hive,
it's really important to capture that,
because it's going to record every single disk
that has been connected to or taken out of that computer.
If I use a thumb drive on the computer,
it's going to be logged in that HARDWARE hive,
so that would tell me as an analyst
that I need to start looking
for that thumb drive or that flash drive,
so I can find data that was written off of this computer,
and so that's one of the reasons
why it's really important to think about it.
So remember, when it comes to data acquisition,
we're talking about the method and tools
used to create a forensically sound copy of the data
from a source device such as a system memory or hard disk.
When performing data acquisition,
always follow your documented processes and procedures
to ensure that you don't contaminate
or lose any potential evidence of a cyber attack
for the investigation that you're responding to.