“Data is not static like a chemical can be, and each time data is accessed the same result is not guaranteed. This variety has come to make a standard very difficult to set, let alone maintained, in the field of digital evidence.” - Institute of Computer Forensic Professionals

All-in-one cell phones, Bluetooth devices, flash drives and PDAs capable of performing the same tasks as laptops. These are just a few of the new technologies that make up the digital organization that you’re responsible for securing. What’s worse is that these devices may connect to your network, scrape data and vanish without your knowledge. As we approach a pervasive computing society, are you prepared for the challenge of using digital forensics to reconstruct a compromise?


Understanding the challenges is just as important as securing the enterprise. To begin with, digital forensic techniques are in their infancy. There is no central regulatory or governing body that publishes accepted digital forensic standards and best practices. This means that you have little to go on when looking for the right road to travel in conducting digital forensic work. What one forensic investigator decides is sound, another will tell you it’s not. This doesn't’t bode well for already tapped-out IT shops looking to quickly ramp up skills in this discipline.

If this was the only issue you’re facing, life wouldn’t be that difficult but, as you are about to see, there is much more to consider.

We’ll start with everyone’s favorite problem – cost.

Securing an enterprise is extremely expensive but when looking at every single thing that needs to be done to forensically recreate thousands of possible compromise scenarios you quickly realize that you’re at a huge disadvantage. You may as well forget outsourcing forensic work too. The cost for third-party forensic work is currently the most expensive service in the security sector.

Now that you know that you’re priced out of throwing money at the problem, what other demons await? For openers, proprietary formats. Let’s take a look at an Oracle database for example. Because Oracle uses a proprietary format, you will have to deal directly with them in situations dealing with the underpinnings of their data structure. There are many other companies with similar proprietary formats. Be smart and figure out what needs to be done before you have a problem, not right afterwards.

While we’re on the topic of structure, you may have gaps in your data and or security structure. What if something happens and you’ve traced the activities to a point where logging is missing and the trail goes cold? What if you have the opposite problem? What if you have so much data that the trail of a compromise becomes buried in the sea of white noise and it becomes impossible to sort through the mountain of data?

Let’s pretend that we don’t have to deal with proprietary formats, steep costs, fragmented data structures or an unmanageable data set. There are still additional pitfalls lying in wait. In many cases, you will be faced with using dozens of tools to piece together evidence. The hook here is that you need to understand precisely how these tools operate. This will become more complex as you add more and more tools to the process.

For example, many people will tell you to use a Knoppix boot CD to examine a hard drive. Many more will tell you that this is a forensically sound practice, but is it really? Unless you are intimate with this tool and a solid understanding of sound forensic practices, you won’t know that Knoppix writes to the swap file on the hard disk by default. This could instantly taint the data and ruin your forensic investigation. In case you’re wondering, you can disable this action at boot time but you have to know to look for it. So in this case, the answer to the question is ‘maybe’ but certainly not ‘yes’.

Let’s move along and assume that you have collected enough digital evidence and believe it to be a solid case against an employee who has compromised the organization. You must be certain that you are thorough in your methods. Drawing from the previous example, just because you know what to look for does not mean that you know what happened.

Recently I heard a case where an employee was on the stand for tampering with evidence. The story goes that the employee intentionally defragged his hard disk when he knew that a forensics team was coming to remove it as evidence. The forensic investigator assigned to the case built his claim by looking in the Windows prefetch directory on the host he retrieved. Because of what he found there, the forensic investigator insisted that the employee ran defrag right before the host was taken.

For those not familiar with the function of prefetch, Windows places a list of frequently used applications in a folder named prefetch, which resides in the windows directory. The files in this prefetch directory end in .pf and typically have an alpha numeric sequence of numbers after the name of the executable. Prefetch is a performance enhancement feature of the Windows operating system.

The investigator looked in the prefetch directory and saw two files. DEFRAG.EXE-23434DEF.pf and DFRGNTFS-2223rrdesfc.pf. When looking at these two files and their dates modified, it appears that the employee had run the disk defrag utility right before the host was taken into custody, but was this really the case?

Unfortunately not.

What the investigator failed to do was to be thorough. The forensic investigator didn’t know that Windows XP runs disk defrag automatically and in the background when the system is idle for a specific amount of time, typically around 5 minutes. If the investigator was thorough, he would have spawned disk defrag manually to see what files appear in the prefetch directory and compare that against what he found. If he had done this, he would have seen that the items placed in there do not match. This should have led him to Google or any place else where he would have discovered that these files in the prefetch directory are there because of automatic optimization performed by the OS and not by any actions of an end user.

So the suspect employee was actually telling the truth. He did not intentionally run defrag in attempts to destroy evidence. What happened here is that the investigator did not do a thorough job and made a mistake. The horrible thing here is that the mistake isn’t the worst problem. The investigator caused damage to a reputation and that becomes extremely difficult to recover from. Can you place a cost on your reputation?

In the end, the employee walked. There were several other mistakes made which provided enough doubt for the accused to leave the courtroom a free man.

As an aside, when presenting digital evidence to a jury, you have to be very precise and deliberate. Credibility is paramount. Digital evidence is not tangible and thus is not easily understood by most people. This gives plenty of opportunity for the opposing council to shoot holes in your case. The company should have gotten a technically savvy attorney who was familiar with case law in the area of digital forensics/evidence and, of course, an IT security professional capable of conducting digital forensics thoroughly and correctly.

After considering all of the above, it is important to note that you are not alone. There are many bright minds out there looking to solve the issues discussed here and more that I haven't even touched on. One place to stop and have a look is at the site of the Institute of Computer Forensic Professionals, A group dedicated to working on standards for forensics and best practices for those seeking guidance. While I do not make any endorsement of this organization, I do believe in the overall mission of this organization and others like it.

This article was first published on EnterpriseITPlanet.com.