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.