Pages

Sunday, January 01, 2012

Contributing to the Community

So, here we go with my first post of 2012...

Not long ago, I posted some thoughts on how analysts can contribute to the DFIR community.  What I wanted to do was offer suggestions to those within the community who had read Rob's post and had maybe thought that writing a batch script or a full-on program was a pretty daunting endeavor, let alone standing up an entire project such as log2timeline.  Recently, there have been some interesting exchanges on Twitter, and I think that this is a good time for folks to consider how they might make a contribution to the DFIR community in 2012.

I think that one of the biggest misconceptions within the DFIR community is how one person can make a contribution.  I think that a lot of analysts get themselves into a nice, comfortable little place called "complacency" through paralysis.  What I mean by that is that too many analysts will convince themselves that they can't contribute to the community because they don't know how to program.  Some analysts seem to look around, see how some others contribute, and say to themselves, "I can't contribute to the community because I don't know how to program."  I think that this applies to other ways of contributing besides just programming, and I think this is just an excuse, and a pretty bad one at that.

At the first Open Source Digital Forensics Conference (put on by Basis Tech and Brian Carrier...thanks, Brian!) in 2010, toward the end of the conference a member of the audience asked, "Why can't I dump and parse memory from Windows 7 systems??"  To that, a prominent member of the community asked, "What have you contributed?"...the idea being that one can't...and shouldn't...simply sit back and expect everything to come to them for free without putting forth something.  But the response didn't center around someone's ability to code in Python...rather, it was about other aspects of how someone could go about making contributions.  Had the person asking the question offered up extra hardware to support development efforts, offered to write up documentation, or just said, "Thank you"?

Not everyone (me, in particular) expects all DFIR analysts to be able to write code.  There are a lot of really good analysts out there who don't go beyond simple scripts and regexes, and others who don't code at all.  Corey Harrell has made some pretty fantastic contributions, simply by having written a number of batch scripts, in essence tying together other tools.

There are a number of ways that anyone can make a contribution to the community, and most do not require the ability to write code.  Some of the ways you can do that in 2012 include, but are not limited to, the following:

Case Studies - One of the things that is definitely true about the DFIR community is that folks really love hearing how others have done things.  Many of us encounter the same or similar cases, or have those "one-offs" that don't get seen very often, and we all enjoy hearing about novel approaches to solving problems.  Admit it...just to be in this community, you have to have a little nerd in you, and there's a part of you that likes to hear how someone else may have overcome an obstacle that they encountered.  Keeping that in mind...that you like to hear those "war stories"...consider sharing yours with others.

If you can't program, but you are able to download and use a tool (commercial, open source), then a great way to make a contribution is to comment on how you used the tool.  Was it useful/sufficient/accurate?  Was it easy to use? 

Ask a question - Very often, this is a huge contribution!  Asking a question very often has the effect of sharing your perspective on things with others, and seeing different perspectives can very often be extremely beneficial.  For example, I like to dig into the Registry, but many times I don't really know what it is that other analysts find useful, or what would be most valuable to their case work.  If someone asks a question about the Registry (specific keys/values, how to locate something, etc.), that gives others a perspective of how they look at things, how they approach problems, and how they go about solving them...and many times, just this perspective can help someone else with an issue that they're working on.

If you download a free, open source tool and you're having trouble using it, start by asking the author for pointers or assistance.  Maybe there's something  wrong with how you're using it...maybe you're missing a switch.  Or maybe you're running an MBR parsing tool against a .vmem file (hey, I can't make this stuff up).  Asking the author your question gives them insight into who's using the tool, how it's being used, and maybe how to improve it...and it's far better (and much more appreciated) than going to a public forum and stating, "...this tool don't work."  

Here's a great example of how you can ask a question...the example is specific to the DFIROnline meetups, but it demonstrates how a number of folks can come together to provide different perspectives when addressing issues and answering questions.

Review a blog post, book or paper - Don't code, and can't share case studies?  Don't feel as if you can maintain a blog?  No problem.  How about this...have you read Corey's blog?  Did you find something interesting in one of his posts?  Did you think what he posted was cool?  Did you tell him about it?  Did you comment on it, and share your thoughts?  If you can't do so directly to the comment section of his blog, have you considered sending him an email?

If you decide to review a book, consider doing something just a little bit more than repeating the table of contents.  While authors appreciate knowing that someone picked up their book, they appreciate it even more knowing (a) if the material was useful, and (b) how it was useful.  Again, sharing your perspective can be very valuable.

What Not To Do
In 2012, consider what you can do, and consider not spending time worrying about (or stating) what you can't do.  "I can't program" isn't a contribution to the community.

If you feel strongly enough to download a tool that someone wrote, take the time to thank them.  Okay, you may not have time to do any in-depth testing of the tool, and you may have downloaded it just to have it for future use, but you had the interest and took the time to download the tool.  Now, this doesn't mean that you have to reach out and thank someone every time you actually run the tool, but just having the courtesy to thank someone for their efforts can go a long way toward the development of that tool, or others.

I think that most times, folks look at what others do to contribute within the community and think to themselves, "I can't program, I don't have the time to write books, and I don't like public speaking, so I can't contribute."...and to be honest, nothing could be further from the truth.  No one is expected to make contributions all the time...hey, we're people and have lives.  But there's really no reason why, if you're capable of doing the work that we do in this field, that at some point in the space of a year, you can't make some contribution of some kind, no matter how small.

Clicking "Like", "+1", or re-tweeting a post isn't a contribution, as it doesn't add anything to whatever it is you're commenting on.  If you like something enough to click a button, take a moment to say what you like about it, or how it was useful or valuable to you.  The same holds true for book reviews...if you're going to review a book, reiterating the table of contents isn't a review; however, describing what you found valuable (or not) and how it was valuable to you is what most of us look for in a review, right?  "The car has cup holders" isn't so much a review of a vehicle as "the car has three cup holders, none of which the driver can easily reach."

What if you're one of those folks who is bound by a corporate policy or something else that prevents you from contributing?   What does this policy prevent you from doing?  You can't talk about casework?  That's fine...in a lot of cases, many of us are thankful that you're the one dealing with the details of the specific case and not us. 

Final Thoughts
No one of us is as smart as all of us, and the best way to get smarter within this community is to engage with each other, share perspectives and thoughts, and then build from there.

Sometimes, the biggest contribution you can make is to simply thank someone for their contribution and efforts.  Seriously.  This means a lot.  Think about it...if you did something, no matter how small, wouldn't you appreciate it if someone said, "thanks"?

As an example of mandating that members contribute, check out the NoVA Hackers blog...they follow the AHA model of participation...which, in short, says that if you want to remain a member, you have to participate.  The AHA page lists what you must do in order to remain a member of their group, and remember, membership is voluntary, so one must accept these conditions upon becoming part of the group.

Here's looking forward to a great 2012, everyone...

Addendum:
Erika posted on this topic, as did Ken...both are excellent posts that take the conversation regarding contributing to the community several steps further.  More than anything, I think that it's valuable to hear from others in this regard, in particular those within the community who might say, "...I want to contribute, but I don't think I have anything of value to share."  I've said it before and I'll say it again...sometimes, the best question to ask is "why?".  When I was on the IBM ERS team, we brought Don Weber on board, and besides just being a great guy, he'd ask me "why?" during engagements, and that got me to re-think (and in many cases, justify) my base assumptions with respect to next steps on the engagement.  That isn't to say that it changed what I was going to do as the engagement lead, but it did open up discussion so that Don could understand what I was thinking.  It also afforded me the opportunity to get Don's input, which was invaluable.  Sometimes, the most information can come from questions such as, "why did you do it this way?" or "how did you go about accomplishing this?"

An additional thought or two that might help...choose your circles and choose your medium.  If you don't feel comfortable posting to an open list, find some other medium.  One way to ask the questions you may have would be to send them directly to someone you trust, and either ask them to post them as a proxy, or just see if they know the answer.

What happens sometimes is that someone will ask a question, and the response will be terse or concise, or include a link to LMGTFY, or just be, "...which OS?" These happen very often when little initial thought, effort or research is put into the question, and are often viewed by the recipient as a "slam".  I think that what folks really don't realize is that you can't convey tone in 140 characters or less, so many times it's assumed because it can't be implied.  If a medium like Twitter (limit of 140 char) leaves you thinking to yourself, "...hey, I asked a question, but that guy's response being mean to me...", then maybe that isn't the right medium for what you're trying to accomplish. 

Not every medium is suitable for everyone in this industry.  For example, the Win4n6 Yahoo group currently has 830 members listed in the forum, and only about a dozen or so "regular" contributors.  As I approve every membership application (solely as an effort to keep bots out), I see all of those who post during the application process that their reason for joining is to "contribute" and "take part" in discussions...and we never hear from them again.  So maybe this medium isn't something that works for them.

Final thought...this time around, anyway...if you don't have the time to put into a question, maybe it's not a good time to ask it.  I'm not saying that you shouldn't ask your question, I'm just suggesting that if you don't have the time to do some research on your own, or don't have the time to let folks know that you're looking at a Windows 7 system and not Windows XP (if you don't know why that matters, please feel free to ask...), maybe now is not a good time to ask the question.  Maybe it's better to hold off until you have more time to do a thorough job, rather than just throwing it out to "the collective".  Just something to think about...Ken referred to this when he mentioned "...ask stronger questions about forensic topics."  Excellent point, Ken.

5 comments:

  1. Great way to start the year Harlan!

    There are tons of ways to get involved and to contribute in our community. Share your forms, policies, procedures, and go bys. Post to listservs or answer posts that you know something about. Answer those calls for papers and speak at conferences or sit on a panel. Get active in one or more DF/IR professional organizations - sit on a committee or offer feedback.

    The more involved we all are, the fresher the ideas are, the more we collaborate, the better we move forward.

    What a great New Years resolution.

    Cindy

    ReplyDelete
  2. @Digital4rensics11:35 AM

    Thanks for the great post to start off 2012 Harlan. As a newer/younger analyst, reading about interacting in the community always has benefit. I've recently been getting a little more involved and the examples you provided will definitely be useful for the year to come.

    Here's to a great new year of increased collaboration and participation!

    -Keith

    ReplyDelete
  3. Donovan5:55 PM

    Great stuff!! People have been asking all week, "What is your New Years Resolution?" I would respond, "I didn't have anything..yet" So, this is a great challenge that I would be happy to be apart of. Another driver of this was me sending a HELP request to RLee about Active Registry Monitor (Thanks Rob). I wanted to do some testing...This WILL get the ball rolling for me. Once again appreciate reading your motivated Blog. Ohhh and Thanks for your help in the community!

    -Donovan

    ReplyDelete
  4. A. Thulin3:10 AM

    On the research side of the subject, a similar situation was recognized many years ago in observational photometry, where there were many amateurs with the capability of doingscientifically useful photometrical research, but without the knowledge of what actually was needed, and professional (or semi-professional) astronomers who knew what was needed, but lacked the time, or resources to do things entirely themselves. (Indeed, some tasks required observers spread around the world, and could not be performed by one person.)

    The result was IAPPP, an organization dedicated to bring these two groups together. The result was encouraging: there are number of scientific papers with amateurs as co-authors, and for at least some, it was a way to 'get known' in this particular community.

    The forensic community lacks the firm foundation in science and research and publishing (I firmly believe), so the approach can probably not be reapplied. Yet it would be possible to create a 'wanted' list of ... 'research topics' sounds a little fancy, and but that's probably what it comes to in the end.

    Similarly, creating test protocols for particular areas, would help ensure that end users can verify that tools and procedures work also for new releases of software. (My own exposure to the problems of badly undertested tools is based on some rather high-profile commercial products.)

    Personally, I'm thinking of looking into test data creation. Some such data is already available (DFTT project, for example), but it seems easy to come up with ideas of areas that are not well covered by tests.

    ReplyDelete
  5. Hi Harlan,

    Thank you for the fantastic blog. I don't comment much because I'm still very new to DFIR, but your fantastic blog posts have done a lot to help me through this. In particular, your IR best practices and IR prep posts have done a lot to shape how I've been approaching establishing our IR policy. Our talk on Twitter about getting a trusted advisor to help was very much on my mind when I was helping interview our new manager of platform security. Thank you for sharing your wisdom.

    ReplyDelete