The mechanics of digital forensics (and its related cousin, incident response) are fairly easy. A computer is a computer is a computer. Collecting data is collecting data. And an artifact is an artifact. As long as you follow the basic mechanical principles and concepts, you should be able to do the work without impossible obstacles.

A most basic example is imaging a hard drive on computer that is not running.

1. Protect the source
2. Image it

That’s about it. This example carries into all things DF/IR, as it is mechanical work coupled with decisions on overcoming obstacles in order to get the job done.

Here is where digital forensics is most easy!

DF/IR is easy to screw up. It is really really easy to screw up. Besides the mechanical ways to make an error, such as overwriting the original data, there ways to make things worse by thinking you know what you are doing, but actually don’t. Using the above example, there are a lot of little things that are needed for a complete job (like documenation, chain of custody, etc...).

Here are two personal examples.

Example 1:

I was hired for a civil case to examine a hard drive image. I received the image that was created by an employee from a nationally known computer repair company. The part of the case that matters is that after the computer was dropped off at this repair company, the computer was identified as being pivotal in a substantial and public civil case. An employee at the computer repair company talked his supervisor and attorney into believing that he could create a ‘forensic’ image of the hard drive.

The employee was first level IT in that I didn’t see much more experience than having an A+ certification and zero experience or education in digital forensics. The employee's only forensic work experience was creating this “forensic” image for the case using FTK Imager.

The process was not correct, as the employee believed that because FTK Imager (ie: “Forensic” Tool Kit Imager) was used, all was well in the world with the forensic image. Some of the issues: there was no chain of custody with the image or original source, the original source was subsequently lost, data was overwritten prior to and during imaging*, and barely any documentation existed. The only documents created were the receipt to drop off the computer and a text file created by FTK Imager.

I was hired to fix the ‘forensics’ in this case. The point of the story is that the employee thought he was doing forensics, but actually, he was screwing it all up by not having any basis of knowledge in the legal aspects of forensics or the technical aspects of creating an image (or much else).

End result: I couldn’t fix it because I didn’t have a time machine to go back in time to prevent the employee from touching the computer. Oh yeah. A new policy on not doing forensics was incorporated in the computer repair company.

Example 2:

On a civil case where I found child porn on a device, I immediately transferred the evidence to the local police department and wished the attorney-client luck (I don’t do those types of cases outside of law enforcement anymore). I also gave the PD the only image that I made of the original, along with an extensive report of what I saw that included verification of known CP hash comparisons. I’m stressing to you in this post that I made it extremely clear to the police department that without a doubt there was child porn on the hard drive, some of the worst that I have ever seen in my career. I even wrote my report as if it were an affidavit for a search warrant because what I saw certainly deserved police attention. 

Months later, the forensic detective told me in a phone call that he couldn’t image the drive and tried for months. He apparently gave up because he said that he was busy with more important cases (than child abuse), like rape and homicide...  He didn’t want any help, so that was it for me in the case. I offered that he could at least use my image that I gave...but nope.

Months later, I was re-hired to examine the drive, specifically for child porn, as the device owner was accused of also molesting his daughters. Then a weird thing happened. The wife (of the device owner) asked the PD to pick up the hard drive. She simply called and said it was her hard drive in evidence. They told her to come pick it up. Then they gave it (the original drive!) to her. Child porn and all. Nothing wiped, no court order for anyone to possess or examine.  Not only that, but the case was still open, and now included child molestation allegations.

The wife (client of my attorney-client) carried the original drive around, passed it on to her attorney, who days later wanted to give it to me. No one (including the police department) cared that child pornography on a hard drive in an active case of child abuse was being passed around without any a sliver of chain of custody or concern of what it legally means to possess that stuff. Or any care of how the data on the drive may refute or collaborate the real-time child abuse allegations.

PS: I refused custody of the drive until I was given a court order that said I could touch it.

The point of this story is that I wouldn’t expect the wife to know anything about chain of custody or possession of child pornography, but I would certainly expect (actually, demand) that the police detective and attorney exactly know. I further would expect that a police officer working in digital forensics could figure out how to image a hard drive in a day rather than never figure it out in months before giving up.

End result: I ended up in court. So did the detective. Some people got yelled at by the judge. I wasn’t one of the people getting yelled at. One positive out of this case is that there were so many problems, that I can use a hundred examples from it for a decade of how not to do digital forensics or police work.

These two examples, out of more than a few that I have personally seen, reinforce a largely ignored aspect of digital forensics work: a basic foundation.

A basic foundation is just that.  Basic. Foundation.

I am not talking about the basics of a specific job in DF/IR, but rather the basics that cut across all the jobs in DF/IR. This includes law enforcement! No one is perfect or exempt from being expected to have a basic foundation.

The DF/IR field typically focuses away from the legal aspects because many in the field wrongly assume that they are not working within the legal arena. For the most part, many are correct, until they aren’t. It is because that not only do we work with data, we also have a high risk of interacting with data that constitutes evidence in a legal case (civil or criminal). We should know what evidence is, how to know it when we see it, and what to do with it if and when we come across it.

Never complain about a problem without following up with a proposed solution

We need to know the foundational basics of both DF and IR.  When you focus on one small aspect of the entire field, you are working with a hammer. All your decisions will be based upon that small part of the field that you work with.  By “small part”, I do not mean insignificant. I mean that if we, in DF, come across an obstacle or issue that clearly fits the other side of the house, that we can identify it as such, and be able to refer or delegate it to more appropriate specialists. Same thing if we, in IR, come across a legal issue, that we handle it appropriately by knowing who best should handle it.

We cannot expect those who do not work in either DF or IR to know how to forensically image a hard drive, or have any of idea of the legalities of passing around a hard drive with child pornography (albeit, at the request of an attorney…after receiving it from law enforcement….). But we can require that us in the field have some basic foundation of both the common legal and technical aspects that cut across the disciplines.

A simple solution is requiring that those who work in either DF or IR, have this foundational knowledge. You don’t need to be an attorney to know chain of custody for evidence. You don’t need to be a police officer to know what evidence looks like. You don’t need to know how to reverse engineer malware if its not your job, but you should be able to know when it needs to be done. You don’t need to know how to do a chip off of a mobile device if you don't work with mobile devices, but you should know that it can be done if needed when you come across it.

What does a basic foundation look like?

1. What you need to know legally (only those things that everyone in DF and IR should both know)
2. What you need to know technically (only those things that everyone in DF and IR should both know)

Anything else is job specific and from which core competencies are built upon,  therefore not part of what I am talking about. Just the basics, like the very basics.  Because without it, digital forensics is really easy..to screw up.