Sunday, December 20, 2009

Audience Participation Time

While catching up on some reading over at Harlan's blog I started thinking about all of the programming I've done in the past year or so. I really appreciate all of the hard work that goes into developing programs like RegRipper and countless others. It's cool when people are able to share tools they have developed to solve problems they have encountered in the field. It's also cool when people who are in the field are able to solve the problems themselves. I have been thinking about whether or not someone who is working in the field of digital forensics really needs to know a programming language or not. My thoughts are yes (which is influenced by what I see around me and may be biased, considering that I do a lot of programming), but I can see how some people may think differently. The reason why I bring this up is because this question has been in the back of my mind since my last discussion with someone from my alma mater, John Jay College.

John Jay's MS in Forensic Computing has been established since 2004 and it has been evolving ever since its conception. The courses of the program have roughly contained a lot of hands on labs as well as theory (algorithms, cryptography, network protocols etc) and programming (various scripting, C Linux OS) in addition to Criminal Justice courses on laws regarding digital evidence. The question has come up several times as to whether or not the theoretical and programming courses are needed in the background of someone who wants to be a forensic examiner.

When I was in attendance there, the general feeling from *some* (not all) of my colleagues was that they didn't need to learn programming and theory in order to work as a forensic examiner. They said they only needed to learn how to use tool XXX or YYY and get a certification in A, B, and/or C they would be set... Perhaps they were right in some way, as they went on to find jobs where that was enough for them. The debate continues about the direction of the program and whether or not theory and programming are needed and whether or not some kind of certification should be obtained instead.

Having been out in the "real world" for a little while, I see a lot of people who do not need any programming knowledge whatsoever to fulfill their jobs. There are plenty of tools that they are more than proficient in using and I'm not knocking their skills, because they are really quite knowledgeable at what they do. However, there are many times that tool XXX or tool YYY doesn't do whatever it should normally, or it cannot fulfill the job the way the client would like. Having a little programming knowledge helps out immensely in these cases. In addition to the EnScripts I have written at work, I have written a lot of Perl scripts, *nix scripts, Visual Basic programs, SQL queries etc. to get the job done. I have also taken someone else's code in language X, Y or Z and tweaked it to run the way I needed it to for a particular job. Now I concede that it's not every day that I need to write these customizations, but it happens enough that I'm glad I can do it.

I often hear from colleagues at work or elsewhere that they wish they knew how to program in X or Y so they could write their own tools to do something. I have suggested books or websites from which they could glean this wanted knowledge. This often comes with some "stern" advice that they must also practice programming if they want it to stick. Some have taken my advice, some probably just don't have the time for it...

So after much rambling on the subject, what do you think? How often do you wish/are you glad that you knew how to program? How often would it have helped you/does it help you on your job as a forensic examiner/incident responder?

Don't be afraid to comment. I only moderate to keep down on the spam (which I seem to get a lot of for some reason).

4 comments:

Alex W. said...

I do have some background in Java, C and Delphi (ugh) programming, but I find that the most I ever need as a forensic examiner is some Perl/VB scripting - it is very rare that I am unable to find a readily availble tool, and simply manipulate the output it produces with some simple scripts, to either find something I am looking for or feed into the next tool... Having said that, I think that in this field, someone with absolutely no knowledge and understanding of programming/scripting languages, is very unlikely to succeed on the tools alone. 'Script kiddie' approach rarely works here.

Security Shoggoth said...

I absolutely 100% agree that the ability to program increases your forensic skillset 100-fold. Even if you don't use it to build new tools, you can use it to automate your toolset in many areas - reducing the likelihood of user error.

While I find that perl is the most useful to me, I've tasked myself with learning Python as well. There are too many projects out there which have Python hooks that are too valuable to not use.

On the comments from your peers that "you have to practice programming if you want to stick with it", I disagree. I really believe that once you get the core concepts of programming down, you can learn any language quickly (without constant practice). Thats why we have reference books and the Internet. If you are creating production level code you're going to sell, then I would agree with that statement. If you use programming to augment your tools/skillset, then not really.

JL said...

Thank you both for the comments! I appreciate the input and it helps me get a better picture of things.

@Security Shoggoth: I guess you are right about practicing, if someone has an idea of programming already. However the people I've said this to had no previous experience and had a hard time retaining what things they had learned from books. Plus often they were not really doing any hands on reinforcement, which I think you have to do at some point really...

Kayna said...

hi..
I do agree that if you can at least able to understand the code that would make life easier..I was a functional consultant for an ERP software(not a security tool though), and knowing where the 'logic' went wrong in the source code indeed, was much appreciated by our technical ppl. To actually do the programming itself, to me it's an issue of time.