Digital forensics describes the process
of collecting and protecting information
that is usually related to some type of security event.
As you can imagine, this can cover many different techniques
for gathering data across many types of digital devices.
And it also describes different methods
to use for protecting that information once you've
retrieved it.
If you'd like to get an overview of this process,
there is an RFC for this--
RFC 3227, which is guidelines for evidence collection
and archiving.
And it's a great best practice to get
an idea of what's involved with the digital forensics process.
This RFC describes three phases for the digital forensics
process--
the acquisition of data, the analysis of that data,
and the reporting of that data.
And you'll notice that the digital forensics
steps and the entire process of collecting and protecting
this data requires you to be very detail
oriented, especially since some of this information
could be used later on in a court of law.
One of the first notices you might
get relating to digital forensics
is something called a legal hold.
This is often requested by legal counsel.
And it's often a precursor to other types
of legal proceedings.
This legal hold often describes what type of data
needs to be preserved for later use.
The data copied for this legal hold
is often stored in a separate repository.
And it's referred to as electronically
stored information or ESI.
These legal holds may ask for many different kinds
of information and many types of applications.
And the information that you're storing
might be stored for a certain amount of time
or it may be an indefinite hold.
As a security professional, if you receive a legal hold,
you have a responsibility to gather and maintain that data
so that everything is preserved.
Another good source of information to gather
would be in a video form.
Video can provide important information
that you could reference after the fact that normally
would not be available.
For example, you can capture the screen information
and other details around the system that normally would not
be captured through any other means.
And if you've got a mobile phone,
it's very easy to grab video from wherever you might be.
You might also want to look around and see
if there's any security cameras which may also have stored
video that could then be included with this information
gathering.
This video content needs to be archived so that you're
able to view it later in reference
to this particular security incident.
One concern regarding the data that you collect
is how admissible that data might be in a court of law.
Not all data you collect is something
that can be used in a legal environment.
And the laws are different depending
on where you might be.
The important part is that you collect the data
with a set of standards, which would
allow that data to be used in a court of law if necessary.
Another concern is if you are authorized
to gather that information.
In some environments, the data itself is protected, in others,
the network administrator may have complete access
to that data.
And of course, there are correct ways
to gather data and incorrect ways to gather data.
You need to be familiar with the best
practices for your tools and the procedures that you follow.
If this data will be used by a laboratory,
you want to be sure the proper scientific principles are used
during the analysis process.
And you may be asked for your academic or technical
qualifications surrounding this data acquisition so that anyone
analyzing this data knows that it was gathered properly
by a professional.
Once you gather data, you want to be sure
that nothing happens to that information
and that no changes occurred to anything that you've collected.
To be able to verify this, we need
to have some type of documentation that
shows that nothing could have been changed since the time you
collected it.
This documentation is known as a chain of custody.
Anyone who comes in contact with this data
or uses it for analysis, needs to document what they
did with this chain of custody.
It's common to have a catalog that labels and documents
everything that's been collected into a central database.
We would also use hashes during the collection process
so that later on we can verify that the data that we're
looking at is exactly the same data that was collected.
An important piece of information,
especially as time goes on, is to document the time zone
information associated with the device that you're examining.
These time offsets can be different
depending on the operating system that you're using,
the file system that's in place, or where the device happens
to be located.
For example, if you're using the file allocation table file
system, all of the timestamps are
stored in local time on that file system.
If this device was storing information
in a file system using NTFS, you'll
find that all the time stamps in the file system
are stored in Greenwich Mean Time.
This is where the recording of this timestamp
becomes very important.
If a year later we go back to this information
and it shows that this file was changed at 5:00 PM,
is that 5:00 PM local time or 5:00 PM GMT?
There might also be time offsets in the operating system itself.
You may want to refer to the Windows
Registry or the configuration settings for the operating
system that you're examining, to see exactly what the time zone
settings are.
This may be very different depending on where
this device is located.
It may be in a different time zone.
And the rules regarding daylight saving time and other time
information may be specific to its local geography.
Event logs provide a wealth of information
because they are storing details about the operating
system, the security events, and the applications that
are running in that operating system.
So if you're collecting data from a device,
you want to be sure to get the event logs.
There's usually a method to export
the event logs, like in the Windows Event Viewer.
Or there may be a way to simply copy them off of the device,
if you're running something like Linux or Mac OS.
You may not need all of the data in the event log.
Maybe you only need to store a certain subset
of that information.
So you may be able to filter or pass
the data based on a particular application
or based on a time of day.
In Linux, you'll find the log information in the slash var
slash log directory.
And in Windows, you can gather all of the details in the Event
Viewer application.
We're often very focused on gathering information
from a digital machine.
But often you can gather important details
from the users of those devices so you
may want to perform interviews.
Interviews will allow you to ask questions and get information
about what a person saw when a particular security
event occurred.
You want to be sure to perform these interviews as quickly
as possible after the event, especially since people may
leave the organization or they may
forget what happened during that particular time frame.
This is the challenge we have when getting witness statements
is that they may not be 100% accurate because people may see
or hear things during this event,
but may not accurately describe that someone
during an interview.
And of course, once all of this data is collected,
there needs to be an analysis and report
of exactly what occurred during that security event.
This might start with a summary, which
would provide a high level overview of what occurred
during the security event.
There should also be detailed documentation that
describes how the data was collected,
the analysis that was performed on that data,
and the inferences or conclusions
that can be gathered based on that analysis.
There should also be detailed documentation about the data
acquisition process.
We need to know step by step exactly what data was gathered
and how that information was gathered.
We can then provide detailed information
about the analysis of that data.
And once we've collected the data and analyzed the data,
we need to document what conclusions we can
make based on that analysis.