Forensic Analysis Applications

As a forensic nerd, I'm familiar with...either directly or indirectly...a number of tools. Like most folks, I try not to be specific to a single tool, but rather understand what I need to do, and then select the appropriate tool for the job. I've used EnCase (going back as far as v.3), FTK, ProDiscover, and recently I've had an opportunity to work with X-Ways Forensics. I have access to SMART and MacForensicsLab, although I can't admit to having used either to a great extent. I've also seen PyFlag in action, and at one point (several years ago) I even installed TSK/Autopsy on a Dell Inspiron 5150 laptop running Windows.

Before I go any further, let me say that I'm separating data collection from data analysis. If anyone's read my books, you'll know what I'm talking about. When discussing functionality in a forensic analysis application, I'm not going to be discussing the applications ability to acquire data (ie, an image)...only to present it. A great example of this is Matt Shannon's F-Response...Matt has focused solely on allowing incident responders to collect data in a vendor-agnostic manner, allowing them to use any tool they want to acquire an image from a live system.

That being said, all of these tools are just that...tools...and each has it's own strengths and weaknesses. I won't go into detail on that here, because to be honest, at some point, these things really start to become a matter of perspective. By that, I mean that I do certain kinds of analysis...intrusions, breaches, suspicious activity, etc...and I don't do other kings of work (ie, CP). Some tools are great for certain types of analysis and the folks who use them know how to navigate the application to perform those functions really well. Each forensic analysis application provides the user with a layer of abstraction of the data, as well. While the examiner may see the hex data that corresponds to the contents of the image being analyzed, she may also see things like the volume identifier, drive letter, file structure, and icons representing files and directories...all of which are abstraction layers that present and represent the data to her.

However, I don't feel that I'm completely limited by these forensic analysis applications. In many cases, I may have a need that I can fulfill by either using another tool, or by creating my own tools. For example, I do a considerable amount of Registry analysis when analyzing a Windows system. As such, Registry Viewers similar in function to RegEdit don't offer me a great deal of functionality. This is why I wrote RegRipper...and it's also the reason I've written other tools (like the ones on the DVD that ship with my book).

Working with these applications, I've found that in many ways, they're all vastly different...different in the capabilities they provide, and especially different in how you would go about getting them to perform a certain function and then display the results. Most applications abstract packages of data as 'cases' and that's great...each has their own way of requesting and storing the case-specific (examiner, date, etc.) information. Then try just adding an image file to the case...I think you can see where I'm going with this.

The issue I see facing us, as a community of forensic examiners, is that we're making our own jobs harder through complexity. I say "our" because as (heavy) users of forensic analysis applications, we should take it upon ourselves to provide input and feedback to the developers of the forensic analysis applications. We're facing the same issues we always see...storage media is increasing in capacity, data (aka, "evidence") can now be found in more sources and formats (cell phones/PDAs, physical memory/RAM, email .PST/.NSF files, etc.), and the forensic analysis applications themselves are adding to the complexity itself. There's more and more available data to analyze and it appears to me (via my own experience as well as viewing public and vendor lists/forums) that the design of forensic analysis applications is adding to the overall complexity, making it harder to get to the data presentation and reduction that is so important.

My thought is this...a forensic analysis application needs a core set of functionality and capabilities. Beyond that, additional functionality can be added through plugins or modules, as well as scripting capability via an extensive and usable API. A forensic analysis application should be a data presentation application...actual "analysis" needs to be done by the examiner or analyst themselves.

Core Functionality
- Stability - 'nuff said!
- Simplicity - again, this is all relative
- Be able to open/add/import standard and the most popular image file formats
- Be able to recognize and present a wide range of file systems
- Searches (grep/regex, keyword, filename) across all files, including inside files such as archives (zip, bz2, rar, etc.)
- File type/signature analysis
- File Carving
- Timeline creation
- Ownership/permission searches
- Hash creation/comparison
- Image viewing (aka, "Gallery View")
- Segregation of data between 'cases'
- Extensibility (via scripting API, and separate plugins)

This is just my list of core capabilities for forensic analysis apps, and shouldn't be construed as being comprehensive. Like I said before, there are going to be examiners who heavily rely on the Gallery View available in most forensic analysis apps for what they do...and there are going to be examiners (like me) who will start an examination by opening the 'case' and extracting certain files for detailed analysis. It's all a matter of what you do, and your personal preference.

Being a forensics nerd, I do understand economics. I do understand why some forensic analysis apps are designed the way they are...there is money to be made through providing training and support by making your application proprietary. There are forensic applications available and in extensive use for which the training is more about how to navigate the GUI rather than actually do productive work.

Don't get me wrong here...all I'm saying is that IMHO, I'm seeing certain aspects of what we do, and how we do it, as a "community", and I'm thinking...wow, can't this be easier and more straightforward? Shouldn't it be possible to get an analysis application that is stable, presents the data in a straightforward manner, and allows me to perform certain data reduction functions easily and accurately? Instead, why are we faced with applications whose interfaces become more complex and less easy to navigate between major releases, and at the same time loose or break major core, underlying functionality at the same time? And why are we charged thousands of dollars more for this new version? What's the focus here?

My goal here is neither to make forensic analysis so easy that a caveman could do it, nor to make so difficult that only a very select (genetic mutations) few could do it. I simply think that we've gone so far afield with the development of these applications that we've lost sight of what's actually necessary. I'd love to see a forensic analysis application that for one price comes with a core set of functionality (see above) for one price, and is simple and stable, and can be extended via a simple scripting API. Beyond that, include an a la carte menu of plugins or modules that will NOT increase the complexity of the application but instead simply add to its capabilities. For example, say an application that presents the file system within the image in an Explorer-style interface, and then a plugin that will allow the examiner to add .PST files to the case, open them in a similar style interface, and also allow the contents (including attachments) to be viewed, searched, etc...all without crashing the main app.

...or am I just completely out of my mind here?