Your DFIR Frankenstein System


Published Date
January 18, 2022

Too Long; Didn’t Read

The point of this post is to give you ammo to defend your forensic processes, procedures, theories, and reports when using more than one forensic tool.  Have the answers before the questions are asked to make testimony and presenting findings less painful.

Put more bluntly, if it looks like your processes and choice of tools are a hodge-podge of randomness that resembles the Frankenstein monster, you will look like a hodge-podge analyst. Your credibility is what is being judged on what you did, how you did it, and why you did it that way.

Your DFIR Frankenstein System is Different From Mine

If you work anywhere in DFIR using any DFIR software, you have a degree of a Frankenstein software system. I mean this in the manner that you constantly work to force your tools to work with each other, either through APIs, tools that automate functions between tools, or simply by incorporating the results of multiple different tools into one report.

Even within the same office, in two different cubicles, doing the same job, two different people will use different tools to accomplish the same task. These differences are based on personal preferences, past training and education, and the specificity of the data being analyzed. Putting different tools to solve problems is a Frankenstein system and there is absolutely nothing wrong with that. Actually, this is the way it works, the best way it works, and if you are seeking out better solutions for what you are using now, you will be behind in your capabilities.

One tool does not do it all.

Some forensic suites do A LOT.  Some of these suites can do everything that you need in a particular case or particular type of cases that you work.

Many forensic tools do VERY LITTLE. In fact, some of these tools do only ONE THING and nothing else. And you might not even need these small tools on all or many of your cases.

Between these two groups of full suites and small tools, we have a plethora of mid-range tools that do the majority of what we need for the average cases.

One case does not need it all.

The needs of your case (should) dictate your choice of tools. Again, this is dependent on your capabilities and resources. There are cases where only one type of data is important and other cases where practically everything bit of data needs to be analyzed. Most fit within these two ranges, just like the tools available fit in with fulfilling case needs.

Few tools do everything well

Tool developers do their best to make sure that their tools do everything well. By “well,” I mean that the function does the best compared to other tools, or at least does well enough to accomplish the mission. However, this is not always the case. Some multi-function tools do some things well and other things not-well. 

This is important because some of the questions that can be asked of you (on the stand or in the conference room) are “Did you choose the best tool for this task?” or “Are there other tools that are better for doing this task?” and “Why did you choose Tool A over Tool B?”.

You need to know the capabilities of your tool to effectively answer these questions. One of the easiest answers is that you choose Tool A because only Tool A can do what was needed.  An analogy of choosing tools is that you can drive a Ford or a Honda to work as both meet safety standards, are reasonable in cost, and effectively accomplish the needs of reliable transportation. Your tools work the same.

Using the same analogy, where riding a skateboard two blocks to work might be reasonable work transportation, a skateboard would not be reasonable if the distance was 20 miles to work.

Be aware of the capabilities and limitations of your tools!

Document your DFIR Frankenstein System

Let’s take a look at one example of a case that needs “many” things to be done. You have a few choices.

  1. Use a ton of small tools to do many things
  2. Use a medium tool that covers these many things
  3. Use a full suite that does these many things and more things
  4. Use a combination of 1-3 above for a combination of reasons

Personally, #4 fits well.  I am sure that this is something that you do too, even outside of validation of findings. I have seen DFIR “practitioners” use a single tool for everything in cases, and the results totally showed it.

Another issue of the DFIR Frankenstein System is that different cases require different tools and even with similar types of cases, we tend to use different tools each time. This is okay. Actually, this is probably best.  Beware the forensic examiner who knows only one tool, because evidence will be missed.

Documenting your processes and tools is nothing out of the ordinary. Using a small tool for a function, even when the forensic suite that you are using is also okay, as a simple explanation that the small tool, in that instance, outperforms the larger suite’s function. That does not discredit the larger suite’s capability, but that you choose the most effective and efficient way of performing the task.

Don’t pigeonhole yourself

The more you document your processes, the better. But be careful with documenting the exact tools in your processes as this will become inflexible. There are so many tool updates, added features, and new tools that occur to lock yourself into using a select set that you will be forced to violate your own documented processes.

Which tool is better?

The most common question on DFIR tools is “which is the best?”.  The best is not always the most expensive, or does the most, but sometimes that might be the case, and sometimes it is not. Like everything in DFIR, the answer is typically that it depends on multiple factors.

A simple task of registry analysis is not simple when choosing which tool to use for the analysis.  Do you just need to export specific keys to a text file using a small tool? Or maybe a broad overview of registry with a larger tool? Or maybe deep analysis with a different tool?  It depends on what you need, and in some (many?) instances, you may start with a quick export of keys, leading you into looking more broadly, and finally diving in deep with a registry explorer tool. FRANKENSTEIN REGISTRY ANALYSIS (but this works!).

You need to know how to use the tools

This should go without saying, but pushing buttons without taking some formalized training, or even reading the manual, is a red flag for problems to come.  Time and time again, I have seen, and been asked about having training on a DFIR tool that was used to extract evidence that was eventually presented as evidence. Tough question to answer without having training, and when the opposing team knows that you have no documented training, they see blood in the water.

The obvious counter to not having formal training is that you can show competence in another manner. Maybe through years of using the tool, documented self-learning and self-testing, and knowing the tool’s documentation well. Much easier to have a training certificate, but when you don’t be sure that you can prove that you know what you say you know, at least on paper.

My tool is better than yours

I have had some engagements where the client law firm required me to use a specific forensic suite in a case. Mostly this is due to the developer’s marketing having influence over some attorneys, and other times it is because the opposing expert is using the same software. I don’t agree with this method since there has been a time when I never used the other expert’s software and had to learn it. The other issue is that when forced to use a specific tool, evidence will be missed if that tool does not do everything well or does some things not-well.

In a recent deposition, I was asked why I used “Tool A” like his expert used instead of a competitor “Tool B” by the opposing attorney.  The opposing attorney was well aware of “Tool B” and made obvious attempts for me to slander Tool A somehow as being not as good as my tool, then tried the other way of making the Tool B that I choose to not be as good at Tool A.  My answers were that both Tool A and B work, were both adequate for the analysis, and that I trust both tools as being reliable.

One tool is better than that other. One tool is not better than the other. It all depends on the capabilities of the tools in question as being fit for the task in front of you.

With that, do not be afraid of having a DFIR Frankenstein System of tools, because if you might be doing it wrong otherwise.


User comments

There are no user comments for this listing.