Welcome back to the Windows Forensic Path.
In Course 11, we're talking about
creating a forensic disk image.
In this module, Module 2,
we're going to talk about validating our forensic tools.
Validation is important because
we want to ensure the accuracy
of our findings and conclusions.
If we haven't validated the tools we're using,
how can we say with
certainty that they're working properly?
We want to be aware of any software issues,
so we need to test and validate to make sure that
your tools are working and you do
not have any software issues.
We want to avoid our findings being called into question.
If we haven't tested and validated,
it leaves a big hole for somebody
to attack us on the validity of our findings.
What should be validated?
Well, definitely you want to
validate your hardware write blockers,
and you want to make sure they're working.
You want to validate your software write blockers,
I would do this at each use.
You want to make sure you validate your imaging software,
the software we're going to use to make the image
just to ensure that it is working correctly,
and you want to also validate your examination software,
the software you're going to use
to conduct your examination.
When we're validating our hardware write blockers,
you want to use a designated drive.
You want to have a designated test drive in
your lab that you
use to validate your hardware write blockers.
You never validate on the original evidence.
You want to know the hash value of
the drive that you are using,
the designated drive you're using.
It is good to use a small drive
because it makes it faster to do the validation.
Validate at least monthly or
whatever your operation requires.
Keep the firmware updated.
Hardware write blockers have internal firmware,
and you want to make sure that
your firmware is up-to-date.
You never want to be embarrassed
finding out that you're write blocker failed
because you as the investigator
failed to update your firmware.
The validation process for a hardware write blocker
is you'll connect your
designated test drive to the write blocker,
you will conduct a hash value of the test drive.
Once you've conducted the hash value,
you'll attempt to write to the drive.
Then you will rehash
the test drive and the hash value should match.
Now, while you're going through this process,
you want to be documenting.
You want to be writing your steps down,
you want to take screenshots of your write attempts to
show that you have attempted to write to
the drive and that you were not able to,
and you want to record your beginning hash value,
the one you do before you attempt to write to the drive,
and the hash value you do
after you've attempted to write to the drive.
You want to record all this,
you want to keep it in a file somewhere in
your lab, and like I said,
you want to do it at least monthly
or whatever your agency requires.
Validating your software write blockers.
Now, software write blockers are used
mainly on removable media at this point in time.
Or you're going to use them on
a hard drive that cannot be removed,
like when we talked about booting into
a Linux distro or a Windows FE distro.
You're going to use these when
the hardware option is not available.
If you have a hardware options available,
always use it over the software option,
and make sure that you keep
your software write blockers updated.
Software write blockers also use a designated drive.
Again, have a designated USB device because you're
mainly going to use these things on
removable media at this point in time,
know the hash value of that drive,
use a small drive,
and validate it before each use.
The process would be the same as it
was with your hardware write blocker.
You would initiate the software write blocker
and make sure it's turned on,
plug in the USB device,
hash the USB device,
attempt to write to it,
and then rehash the device and
make sure those hash values match.
It doesn't take very long to do,
and I highly recommend doing it before each use.
When you do it, you're going to do it on your test drive,
never ever validate on original evidence.
We're going to activate the software write blocker,
we're going to connect the test drive
to our examination computer.
We're going to hash the test drive,
we're going to attempt to write to the test drive,
and rehash the test drive.
That is the validation process.
Our hash values should be the same, and again,
make sure you document the results and
the actions that you took when you
attempted to write throughout this process.
You should also keep these validations somewhere in
your lab so that you can
show documentation if it's ever called into question.
Now, your imaging software.
One thing you want to make sure about
your imaging software is you want to make sure it
is imaging the entire physical disk
if you're imaging a physical drive.
Make sure you're getting the entire drive.
When you validate again,
use a test drive with a known size and known hash values.
The hashes should match;
the hash of the test drive,
should match the hash of the image,
and when you rehash the test drive,
that hash value should also match.
Use a small drive because
it makes the process much quicker.
Keep your software updated, your imaging software.
You should not be using outdated versions.
Validate as required by your agency policy.
If you do not have a policy, again,
I would recommend doing it in disk once a month.
Again, you need to document the results of a validation.
Our examination software.
Read through these notes on
your evaluation software so
you know if there are any known bugs.
Be aware of these known issues.
Always update your examination software
to the latest stable version.
The process is similar.
We're going to use a designated validation drive.
Your lab should have a drive that they use to
validate the software you're
examining your evidence with.
The drive should have known results.
It should have known hash values,
and it also should have known files on it.
You want to cover
all the major functions of your software.
Whatever examination software you're using,
when you do your validation,
that should include all the major functions
of that particular piece of software.
If you're looking for a lot of image files,
for example, part of
your validation should be recovering image files.
Cover the common areas of your examinations.
Follow your agency policy,
and document the results of your validation.
If you're somewhere that does not have a policy,
I would do a validation with
each full-number upgrade of the software.
If you go from version 4.1 to version 5.1,
when that 4 becomes a 5 is when you need to validate.
What validation does for us is it allows us to be
confident in the accuracy of
our findings and conclusions.
Because if we didn't test our examination software,
how can we be confident with the findings that we're
seeing when our dates and times with the files recovery,
the locations that software
is telling us these files came from?
You definitely need to
validate your examination software.
We also want to adhere to scientific principle We talked
about scientific principles at
the beginning of this path.
This also helps us head off
our findings being called into question.
In our next module,
we're going to take a close look at
our write blockers and talk about how they function.