Evaluating Forensic Tools: Beyond the GUI vs Text Flame War

One of the good old flamewars that comes up every now and again is which category of tools is “better”: graphical, console (e.g. interactive text-based), or command-line?

Each interface mechanism has its pros and cons, and when evaluating a tool, the interface mechanism used can make an impact on the usability of the tool. For instance displaying certain types of information (e.g. all of the picture files in a specific directory) naturally lend themselves to a graphical environment. On the other hand, it’s important to me to be able to use the keyboard to control the tool (using a mouse can often slow you down). The idea that graphical tools “waste CPU cycles” is pretty moot, considering the speed of current processors, and that much forensic work focuses on data sifting and analysis, which is heavily tied to I/O throughput.

Text based tools however do have the issue that paging through large chunks of data can be somewhat tedious (this is where I like using the scrollwheel, the ever-cool two-finger scroll on a Macbook, or even the “less” command.)

To me, there are more important issues than the type (e.g. graphical or text-based) of interface. Specifically some of the things I focus on are:

  • What can the tool do?
  • What are the limitations of the tool?
  • How easy is it to automate the tool (getting data into the tool, controlling execution of the tool, and getting data out of the tool)?

The first two items really focus on the analysis capabilities of the tool (which can be “make-or-break” decisions by themselves), and the last item (really three items rolled into one) focuses on the automation capabilities of the tool.

The automation capabilities are often important because no single tool does everything, and an analyst’s toolkit is composed of a series of tools that have differing capabilities. Being able to automate the different tools in your toolkit (and being able to transfer data between multiple tools) is often a huge time saver.

Many tools have built-in scripting capabilities. For instance ProDiscover has ProScript, EnCase has EnScript, etc. Command line tools can typically be “wrapped” by another language. Autopsy for example, is a PERL script that wraps around the various Sleuthkit tools. While it is useful to be able to automate the execution of a tool, it’s also useful to be able to automate the import and export of data. Being able to programmatically extract the results of a tool and feed them as input (or further process them) allows you to combine multiple tools in your toolkit.

So to me, when evaluating a forensic tool the capabilities (and limitations) and the ease of automation are (often) more important than the interface.

Trackbacks

  1. […] Evaluating Forensic Tools: Beyond the GUI vs Text Flame War – Very good points. Each interface mechanism has its pros and cons, and when evaluating a tool, the interface mechanism used can make an impact on the usability of the tool. For instance displaying certain types of information (e.g. all of the picture files in a specific directory) naturally lend themselves to a graphical environment. On the other hand, it’s important to me to be able to use the keyboard to control the tool (using a mouse can often slow you down). The idea that graphical tools “waste CPU cycles” is pretty moot, considering the speed of current processors, and that much forensic work focuses on data sifting and analysis, which is heavily tied to I/O throughput. See Andrew Hay and Daniel Cid’s tutorial on Enterprise Log Analysis with Q1 Labs QRadar and OSSEC at the iTrust and PST Conferences on Privacy, Trust Management and Security in Moncton, New Brunswick, Canada. Email andrewsmhay [at] gmail.com for more information. […]

  2. […] Evaluating Forensic Tools: Beyond the GUI vs Text Flame War […]

Leave a Comment