Kristinn Gudjonsson’s GIAC Gold Paper Released

Kristinn has announced that his GFCA gold paper entitled “Mastering the Super Timeline With log2timeline” has been released. You can get it here.

Kristinn and I are also back at work on the Adobe Flash Cookie research and tool development project and we hope to have it wrapped up relatively soon.  The release of Flash Player 10.1 set my portion of the research back a little bit since there was some changes to how things work, but the fundamentals remain the same.

I have completed the file system tunneling research portion of the project and that will be part of the final paper since it’s critical to understanding time and date issues with these artifacts. The universal response when I have approached various forensic gurus on the issue has been unfamiliarity.  It’s appears that file system tunneling is something that was esoteric enough where it hasn’t appeared on anyone’s file system research radar until Kristinn and I ran into it during the course of our research.

Sometimes you just get lucky.

Links

There have been a lot of interesting items that I have run across recently that I’d like to share with the group.

The first is an EFF article on Apple’s efforts to patent spyware and what EFF terms “traitorware”. Your spider senses should start tingling when you read the article.

The second is a fantastic Brad Garnett SANS Blog post on report writing.  Report writing is an area that is critically important for digital forensic examiners to learn and master, but it’s a very neglected topic when it comes to digital forensic training.

Lastly, Brandon Gregg has an excellent article over at CSO Online on free and cheap tools to help manage investigations.  I found the last segment on “hypothesizing your investigation” to be particularly intriguing. 

Horse Then Cart

I usually have a couple blog posts in some sort of draft form at any given time.  This thread over at Forensic Focus allowed me to flesh out one of those drafts enough where I essentially wrote the core of what I’d like to write about today. 

I’m frequently approached by people who are either putting together a forensic team or just preparing to get into forensic work on their own.  One of the first question that I am almost invariably asked is what tools I recommend that they obtain.  That’s not a question that I can intelligently answer unless I have some idea of what purpose the team is going to serve.  In the business world, customer requirements should drive tool selection, team recruitment and process development.  One of the classic mistakes that one can fall into is allowing your processes to be driven by your tools.  Vendors are very keen to sell you their tools regardless of whether they are a good fit for your organization or customer requirements.  If you allow the vendors to drive your team development by making you dependant on their tools and processes, you can end up with a team that isn’t much more than a group of glorified tool drivers.

It’s important that to understand the customer requirements first and then craft a team to meet those requirements.  A team that is intended to do a lot of eDiscovery work will not have the same tools, people and processes as a team that is primarily tasked with incident response forensics.  The eDiscovery focused team, for example, won’t have as keen of a need for memory forensics and malware reverse engineering compared to the incident response forensic team.

Team selection and training will also be driven by customer requirements for the same reason.  There are quite a few subdisciplines in digital forensics and team selection will be driven in part by how mastery of selected subdisciplines will accomplish the customer requirements.  For example, if a team is going to be engaging in eDiscovery, that team will require people with backgrounds in areas such as software development and database management.  There are many fine eDiscovery tools out there, but they aren’t necessarily going to be tailor made to meet your requirements right when you take off the shrink wrap.  I’m still amazed when I run across firms that are doing eDiscovery work who don’t have anyone on staff that can do development work.  That tells me that their processes are probably being dictated by the tools and they almost certainly lack the flexibility of other firms that have a robust developmental capability.

By the same token, it’s hard for me to consider a team to be a world class incident response team if it doesn’t have a robust malware reverse engineering capability.  Sure, you can do incident response without having malware gurus on staff, but it’s a hard sell to claim that you’re somehow on the cutting edge of incident response work if you can’t study the tools of an attacker in detail.

Lastly, it strikes me as a mistake to disqualify otherwise excellent forensicators because they aren’t familiar with a particular tool that your team uses.  While it’s certainly something to take into account, a candidate’s fundamental knowledge is more important than their ability to drive a tool. It’s much harder to pick up the fundamentals than it is to learn to drive a tool.