Friday, January 27, 2012

Revisiting "Forensic Value"

I posted some thoughts a while back on defining "forensic value"...in that post, I pondered the question of who defines the "forensic value" of an artifact or finding.  The post had received 15 comments relatively quickly, and it seems that there's something of a consensus that the forensic value of data is in the eyes of analyst.  One would suppose that this means, then, that the forensic value of a particular artifact can be determined by viewing that artifact through the lens of the analyst's knowledge and experience.  In my previous post, I used terms like relative and subjective value, and I think that these descriptive terms come not only from the goals of the examination, but also depend heavily on the knowledge and experience of the analyst.

I recently had the opportunity to review a paper written by someone who had done some pretty comprehensive testing and documented some interesting artifacts.  In that paper, the author mentioned certain artifacts that were available, but that these artifacts were not pertinent to the analysis being performed...the artifacts were provided for informational purposes, and might be of value to other analyses.  For the paper and the analysis being performed, I thought that this was a valid distinction to make, as it addressed the issue of why those artifacts were not discussed (how the got there, their format, etc.) further in the paper. In short, the author had made a clear distinction as to the relative value of certain artifacts.

The relative value of an artifact often has a lot to do with the context of that artifact.  Consider an email address found within an image, perhaps using something like bulk_extractor or a keyword search.  The email address may already have an intrinsic value to you, possibly as a piece of intelligence.  From that point, any additional value of that artifact can rely heavily on the context in which that artifact resides.  Was that artifact found in a file?  In a PST file?  If the email address was found in a PST file, in an email, what is the context?  The value of the email address vary greatly depending upon not only the goals of your examination, but also whether the address was found in the To:, From:, or CC: block of the email, or if it is located in the body of the email.  Depending upon the goals of your examination, the fact that the email address was found in the body of an email may be more important and have more relative value than if it were found in the To: block.

The absence of an artifact can also be of significant value, but again, that will depend heavily upon (a) the goals of the examination, and (b) the skills of the examiner.  For example, I was performing some Registry analysis a while back to determine which files a user account had been used to access on that system (goals).  I noticed immediately that RegRipper reported that the "RecentDocs key was not found."  This was a very significant finding, and not something I had expected...and my experience told me that it was something worth exploring, particularly given the goals of my exam.  I quickly determined that a "scrubbing" tool had been applied to the system, and determined when that tool had been installed and run, and by which user.  I was also able to recover a significant bit of deleted data from within the hive file itself.

Now for the big question...so what?  How does this apply to...well...anything?  Well, consider my recent post on Timeline Analysis...for those analysts who want to "see everything", how much of that "everything" is actually relevant and of forensic value?

In order to address that, I think that we need to look at a couple of things...and I'd start with, what are the goals of your exam?

I've heard some folks say that during analysis, it's important to understand an attacker's methods, as well as their intentions.  I'm not so sure that's something I'd hang my hat on...mostly because the attacker isn't sitting next to me so that I can ask them questions and understand their intentions.  When performing analysis, all we see is the results of their actions...maybe only some of those results...and we often look at those results and artifacts through the lens of our own experiences in order to attempt to determine the intentions of others.  Further, when it comes to understanding the methods an attacker uses, that's an understanding that's most often developed by observing various artifacts from within the system...but if we're not familiar with the system that we're analyzing, and we're using some automated tool to pull out all of the "relevant" artifacts for us, are we observing all of the artifacts, or at least the right ones to give us a view into what the attacker is trying to do?

Consider this...given an image acquired from a system...let's say, for the sake of discussion, a Windows 7 system...how do we know that when we run a particular tool (or set of tools) against that image that we're extracting all of the relevant data that we require in order to make informed opinions regarding our findings?  When an analyst says, "I want a timeline, and I want it with everything!", how does that analyst then know that they've got everything in that timeline?

The forensic value of any particular artifact is determined by the goals of the exam, and the relevance of that artifact, taken in context with other artifacts.  The terms "relevance" and "context" will often be subjective, based on the knowledge and skill level of the examiner.

Does this mean that every analyst needs to be an expert in Windows?  No, that's not entirely practical.  What it does mean is there needs to be should be multiple levels of access to knowledge, including training, mentors and trusted advisers available to your analysts, and that these should all be part of or accessible to your analysis team.

No comments: