Saturday, December 28, 2019

Improving DFIR Skills

There are more than a few skills that make up the #DFIR "field", and just one of them is conducting DFIR analysis.  Brett Shavers recently shared his thoughts on how to improve in this area, specifically by studying someone else's case work.  In his article, Brett lists a number of different avenues for reviewing work conducted by others a means of improving your own skills.

Brett and I are both Marine veterans, and Marines have a long history of looking to the experience of others to expand, extend, and improve our own capabilities.  In the case of war fighting, a great deal has been written, providing a wealth of information to dig into and study.  Jim Mattis stated in his book, "Call Sign Chaos", that "...your personal experiences alone are not broad enough to sustain you."  This is true not only for a Marine general, but also for a DFIR analyst.  In fact, I would say even more so for an analyst.

Okay, so how do we apply this?  One way is to follow Brett's advice, and seek out resources.  There are numerous web sites available, and another resource is David Cowen's book, Computer Forensics InfoSec Pro Guide.

Another available resource is Investigating Windows Systems.  What makes this book different from others that you might find is that when writing it, my goal was to demonstrate stitching together the analysis process, by explaining why certain decisions were made, and the data and thought processes led to various findings.  Rather than simply presenting a finding, I wanted to illustrate the data that was laid out before me when I made each of the analysis decisions.  As with all of my other books, I wrote IWS in large part due to the fact that I couldn't find any book (or other resource) that took this approach.

Another approach is participating in CTFs.  However, if you don't feel confident in participating in the actual CTF itself, but still want to take a shot at the analysis and see how others went about answering the challenge questions, there are often options available.  In 2018, DefCon had a forensic analysis CTF, and a bit after the conference, several (I found 3) folks posted their take on the challenges.

My "thing" with CTFs is that they very often aren't 'real world'.  For example, in all of my time as an incident responder, I've never had someone ask me to identify a disk signature or volume serial number from an acquired image.  Can I?  Sure.  But it's never been part of the analysis process, in providing services to a customer.  As such, I posted something of my own take on a few of the questions (here, and here), so they're available for anyone to read, and because the images are available, anyone can walk through what I or the other folks did, following along using their own tools and their own analysis processes.

If you do decide to engage in developing your skills, one of the best ways to do so is when you have someone to help you get over the humps.  I'll admit it...sometimes, I take time to research something and may come up with a solution that isn't at all elegant, and could perhaps be done better.  Or maybe, due to the fact that I'm relying on my own experiences, I don't see or consider something that to someone else, is obvious.  Having a mentor, someone you can go to with questions and bounce ideas off of can be very beneficial in both the long and short term.


Brett Shavers said...

It is always easier to learn from the mistakes of others (less painful too) as I make enough on my own..

But I also believe in learning from the successes of others, like those who seem to work great cases and make seemingly perfect decisions. I take the training principles in both the military and LE (particularly with SWAT), that practicing as close to perfect, as often and regular as possible, increases skills and knowledge. Applying that to DFIR, doing a few case studies over a period of a couple of nights is way easier then re-running dynamic entries for 8 hours, but the result is the same - you get better.

H. Carvey said...


Agreed, I make enough mistakes of my own, no one should have to make the same ones.

When I was in grad school, I was learning to use the Borland C++ compiler. I think I saw not only every documented error message, but a few undocumented ones, that started with, "...dude...WTF?" ;-)