Thursday, September 26, 2013

What makes up a good procedure?

I love documentation, so long as it is clear, and most importantly, it gives useful examples on how the procedure can be used immediately without too much effort. I don’t like hard, I like easy, thats why we document right! What I don’t like is documentation that causes me to get lost as I start reading it. Once that happens, I get frustrated and move on to seek out better documentation. What causes people to get lost? In my opinion, I believe it is lack of planning on behalf of the individual writing the documentation, coupled with a whole ton of assumptions and not knowing your audience. I hate assumptions when reading procedures.
People who write procedures, in my opinion, must write it as if the reader is a complete newbie. By doing this you level set all your readers. The more advanced reader can just skip to the juicy bits they are more interested in without reading all the background and prerequisites. Explanations, these I love also. If your going to show a command line command, then explain what it is doing. This way you are giving your reader the opportunity to really understand what is going on with all the switches and options used in the command. On that note, give some actual real world usage of the procedure, don’t leave the fella hanging.
So, what makes up a good procedure? What makes it so complete and fool proof? Lets take a stab.
1. Purpose – Describe the purpose of the procedure.
2. Why? Why are we doing this and what are the benefits.
3. Prerequisites  & Environment – Tell the reader what ALL the prerequisites are for this procedure and what your environment looks like so they can replicate it.
4. The Procedure –  Here is where we commence the actual procedure walking the reader through the steps.
5. Explanations – Provide explanations along the way with screen shots (really good screen shots). During the procedure give detailed explanations of what you are doing.
6. References – Provide links to other web pages topic related. Providing links to additional documentation or other posts discussing the topic gives the reader opportunity to see how other folks are dealing with it or what they know about the subject.
7. Use Cases – How else can I use this? Give additional example(s) of how this procedure can be used. This gets the reader thinking on how they might use the procedure in their environment.
8. Finally, after all of the above is accomplished, the reader leaves with a sense of empowerment and new knowledge to use and share with his peers.
This, I believe,  makes up a good template for creating procedures that are well documented and can be repeated by any analyst. If you fail at this, then apply the deming cycle to correct it.
In my next post I will post an empty template to illustrate the above. Beyond that, I will start posting procedures that I have created due to a need and use quite often
Mr. Orinoco

Hello World!

The Purpose of my Blog.
I have wanted to blog for a long time, however, I personally felt there were a number of things that prevented me from blogging, especially on a topic so technical. Digital Forensics is such a wide reaching field, it covers so many aspects of modern day computing; it is easy to become overwhelmed just by thinking of the scope of this profession. To then think that you are adequate enough to contribute to this profession where folks like Mandiant dominate on the IR level, and then throw in the DFIR Gods like Rob Lee, Harlan Carvey, and Corey Harrell who are front and center every day with their incredible insights and analysis.  These guys are my “American Idols”. Nonetheless, I have decided to stick my neck out. The reason? I want to share what I have learned, I want to be commented on (peer review), and ultimately, I want to get on. I want to advance my career in this fascinating field and crush a few bad guys along the way. There is RISK in this blogging thing, I have no idea how it will go, but I have a purpose.  As I have stated I want to share, I want to learn, and I want to move up in this world of DFIR. How do you do that if nobody knows you, and by that extension, they do not know your thoughts, procedures, and capabilities to achieve your results and wins.
My background in PC computing stems from a technology start back in 1996 just as the PC/Internet world was coming to fruition. Heck, I had a Packard Bell 486 DX2 66 with a 2400-baud modem to Prodigy for Win3.1. After a career change and fresh out of IT school I held a few positions quickly rising in IT responsibilities with each move. I started of on a helpdesk, then to product support, to Desktop OS and application support, then Network Admin on Novell, switching to NT, then some engineering, then into end point security products, and ultimately to where I have been for the past few years as a DF Examiner. Most DF examiners that have been doing this for the past 5 years or so fall into these positions because someone asked them to assist with something related to info sec, or some other security related issue. I am no different. Simply because the group I was in at the time I was asked if I would like to do disk forensics? “Wow” I said, “sounds exciting”. I have an IT background but had no idea on forensics. I recall my manager walking me through the use of EnCase 5.x over the phone doing a set include!
Anyway, I plan to publish useful articles on procedures anyone can use. These procedures will have a theme and an end result goal in mind in what I am trying to accomplish. Additionally, I can use it as my own personal library collection so I can reference them myself. It’s hard to remember all your procedures when you have so many, so why not have them readily available and share them. What I really hope for is for someone to say “hey, you know you can do it this way also which is easier”. Or, “hey, have you thought about this or that?” I as said, I want to learn and move up in this profession, and I cant do that unless I put myself out there so people can  see what I am doing right!
 So, check back soon, I ‘ll have something up asap.


Mr. Orinoco