Documentation

If you didn't document it, it didn't happen.

When I first heard that, it had nothing to do with DFIR work, but it holds true nonetheless.

How often does this happen?  We're working on a school or self-imposed project, and you run across an issue, so you go online to ask a question of the communal brain trust (Twitter, Forensic Focus, CFID mailing list, etc.).  Within short order, you start getting queries...which version OS/version of Windows, which application, where did you get the file (path), etc.  By the time you return to the online world, you can't remember any of this, and now have to start over.  However, had you kept case notes or documentation of some kind, this wouldn't be an issue.

So the questions I usually see/hear at this point are how do I keep case notes and to what standard do I keep case notes?  The how is easy...what works?  When I was on the IBM team, we used the QCC Forensic CaseNotes tool.  This is a very good tool to use, and includes a lot of functionality.  However, it's sometimes simply easy to use MS Word, and create the necessary sections.  I usually create a section for Exhibits (what items I had received, often in a table if there were more than 2 or 3 items), as well as one for Hours (again, sometimes in a table).  When I got to the actual notes, these were most often a narrative of what I actually did, broken down by day.

You can create other sections, as well.  Bill over at Unchained Forensics recently posted about having a case outline or preparation plan.  I usually have an analysis plan in mind, and if it's for work that I don't already have a checklist, I write one.  I think that Chris has even talked about having an analysis plan documented.

So, to what standard do you keep case notes?  Most often, I'll say, "...so that you can come back a year later and know what you did."  Too often, however, this provides a lazy analyst with an easy out, because from their perspective, what are the chances that in a year, someone's going to come back and ask them a question?  Well, you don't know until it happens...and it does happen.  The best standard to use when writing your case notes is to assume that at any point, you could "get hit by a bus" and another analyst will have to take your notes and finish the exam.  As such, are your case notes written to a level where another analyst could run the same commands, using the same versions of the tools you used, and replicate your results?  So, in your case notes, do you say, "Checked for ADSs", or do you say "Mounted image with FTK Imager v3.0 as G:\ volume, scanned for ADSs using LADS v4.0"?  This is important...remember MHL's post on stealth ADSs?  There are more things on heaven and earth than are dreamt of in your philosophy, Horatio...so the tool you use will make a difference, and you might want to consider using the tool that MHL provided.

On that note, consider this...what do your case notes say?  If you do PCI work, do your notes say, "Ran CCN search"?  Is that adequate?  How was that search run, and over what data?  Did you load the image into EnCase?  If so, which version?  And yes, the version of EnCase you're using DOES matter.  Was your search run using a specific EnScript, and was that a publicly available EnScript or one crafted specifically by/for your team?  Or did you extract the unallocated space from the image using blkls from the TSK tools, and run a series of regexes over the data?

All of this is important because the number of CCNs that may have been exposed are extremely important to the merchant as well as the banks; as such, accuracy is critical, and one way to ensure accuracy is to be able to replicate your findings.

Start with a Process
An efficient way for maintaining case notes is to have documented processes already in place.  For example, if you're tasked with detecting malware within an acquired image (no memory dump available), do you have a documented process for doing this?  If so, you can say "followed documented malware detection process" and provide the version number or date, as well as the completed checklist itself.  That documented process can be a separate document in your case notes directory, and all you would need to include is any additional actions you took, or anything you decided to leave out, including your justification (ex: "Did not run search for ADSs, as the file system was FAT.").

The Value of Case Notes
So why are case notes so important?  Well, those of us that teach the need for this kind of documentation use the you may have to testify a year later and what if you get hit by a bus hooks, but in the big scheme of things, these events rarely happen.  When they do, they're real eye openers, but by then it's too late and everyone's left saying, "...yeah, I should have kept case notes...".

Something that a lot of folks don't think about when it comes to case notes is competitive advantage.  How do organizations that provide DFIR services define "competitive advantage"?  Most often, the outward expression of this perception is generated through marketing (presentations at conferences, blog posts, use of social media, webinars, etc.) efforts; however, behind the scenes, that organization is going to have to deliver at some point, and it becomes a matter of the quality of the service provided (usually in relation to margins).  As such, detailed and clear case notes serve as a fantastic learning tool for other members of the DFIR team.  Let's say there's a team of 11 analysts/responders, all of whom are geographically dispersed.  One analyst spends 16 hrs of analysis and finds something new, that no one else has ever seen.  Now, assuming a common skill set level across all analysts, we have to assume that for everyone else to replicate this finding, assuming they get a relatively similar case, would take a total of 160 hrs (10 analysts x 16 hrs/analyst).  This isn't terribly efficient, is it, particularly given the assumptions?  However, if the first analyst's case notes are clear, they can be used to provide information to the other analysts regarding what to look for, etc.  If the team uses a remote presentation capability (WebEx, brown bag "lunch and learn", etc.), the 160 hrs can be reduced to 30 minutes, and all analysts would then have the same knowledge and capabilities, without having to have had the same experience.  This can provide a great deal of competitive advantage to that organization.

Another use of the case notes is to use them to create the appropriate indicators of compromise (IoC), or a plugin for a forensic scanner, to be shared amongst all analysts.  This provides an immediate capability (the time it takes to share the plugin) with zero experience, in that the other analysts don't have to actually have had the experience in order to achieve the capability.  This means that corporate knowledge is always available and retained well after analysts leave the organization, and knowledge retention becomes competitive advantage.

Consider this...when performing a specific exam (i.e., malware detection), how do you go about it?  Do you have a series of artifacts that you look for or tasks that you perform?  Now...and be honest here...do you have a documented checklist?  If you do, how much of that can you put into an automated process such as a scanner?  If you do this, you have now reduced your initial analysis time from days or hours to minutes, and by using automation, you've also reduced your chances of forgetting something, particularly those repetitive tasks.  Now, imagine collaborating with other analysts and increasing the number of plugins run...you now have a communal knowledge bank focused on quickly checking for the low-hanging fruit, and providing you with the output report (and a log of all the plugins run).  Ultimately, you're left to do the actual analysis.

So in the case of the scanner, the documentation comes in two forms...first, the documentation of previous analysis that results in a plugin.  Second, the output report from the scanner, as well as the activity log, serve as case documentation, as well.