Something that is comming up with people on all sides of a fence with more than two sides, is if we should cover specific tools or not.
I recently came accross a definition of methodology that sumarises it as such
the analysis of the principles of methods, rules, and postulates employed by a discipline
"methodology" is often seen as a synonym for "method" where it is far more accurately translated as framework.
It is my opinion that we should be looking at the forensic artifacts, what they mean and where they can be found, not providing a "How to" guide for specific tools. My reasons for this are as follows
I, for one, could only support documenting 2 or 3 of possibly hundreds of available tools for doing any one task.
It would require updating every time a new version of software X is released, now if you use FTK this is fine, but anything else could be more frequent than is acceptable …
It would potentially exclude users who don't have those tools, students etc. and we are trying to improve knowledge distribution in the community - not exclude people.
–
Now, that's not to say that I don't think that some examples would have merit - just that I think that they should not be part of the main methodology - appendix at worst - separate worked examples at best. I would suggest that in doing this ( if it is indeed us that do it … ) using Open Source tools would be fairest, so that everyone and his dog can download the SleuthKit and reproduce the example.
Perhaps the big boys might like to have their documentation teams create a demonstration of "How to follow the Open Forensic Methodology using ExpensiveForensic 2.0" … Just an idea 😉
What is the general feeling on this ? As I said I've seen pretty much every opinion under the sun stated at least once … I've made a basic poll for it … but obviously not a very detailed one, please elaborate on your answers a bit -) This is my first poll, so if anyone has suggestions for refining it - I'm open to criticism.
Thanks.
I like your clarification of terms and I really appreciate the work you’ve put in this one. If I may offer one more for consideration That we use protocol or something similar term to refer to the detailed "How to follow the Open Forensic Methodology using ExpensiveForensic 2.0" that we hope also gets written. Someday. Just providing the general open methodology is quite an undertaking but I can also suppose that as people write “things†they’ll need a way for them to be included.
I think methodology should be as vendor independent as much as possible.
Supporting procedures for a specific methodology, on the other hand should present any and all product, solution, service.
Cleary, in some cases the methodology is unique to a specific vendor, which is not available with other vendor or solution. The description of the methodology still should be as detached from the product as much as possible, and then present the actual procedures from the vendor.
I do not understand Open Forensic Methodology per se. Unless one starts patenting the methodology in forensics, which is not impossible, all should be "Open".
As for writing them, I think writing the procedures first for a specific tool, then extracting it into a non-vendor-specific methodology would be easier, as it would provide a framework. Other vendor procedures to the same methodology would further expand the documented methodology.
But, then what do I know D.
But, then what do I know D.
Judging by the general readership of these forums, probably as much as any of the rest of us -)
I do not understand Open Forensic Methodology per se. Unless one starts patenting the methodology in forensics, which is not impossible, all should be "Open".
I'd hope that prior art would be on our side in that case !
"Open" is more to do with the philosophy that we wish to apply to its creation and distribution - e.g. open source, open standard - obviously many of the concepts in it will be drawn from the way that individuals carry out a certain task and in sharing that and writing it down they create, by default, a copyright on that work. The "Licensing" thread in this forum covers the way that we are going to crack that particular nut …
Incidentally - "Open Forensic Methodology" is a somewhat flexible working title at this point pending any better suggestions -)
Cleary, in some cases the methodology is unique to a specific vendor …
I'm not sure that I agree with that … Obviously some tools make it an easier proposition than others, but, taking the basic assumption in computing that every program is merely an implementation of an algorithm, it would suggest that there is nothing that you can extract in terms of evidence from EnCase ( or the program of your choice ) that you can't extract using WinHex ( enter your favourite hex level disk viewer here ), given enough knowledge, time and patience …
In fact, as one should really verify any results obtained using a given program, one would really hope that nothing is locked into a specific vendor …
As for writing them, I think writing the procedures first for a specific tool, then extracting it into a non-vendor-specific methodology would be easier, as it would provide a framework. Other vendor procedures to the same methodology would further expand the documented methodology.
Having said all of the above - this may well be the best approach for the development stages … But the actual resulting text will need to be vendor independent.
Thank you - interesting discussion -D
I voted Theory only. The OS-TUM (;)) did this well. It's assumed that there are tools to do any of the theory documented; the implementation to be addressed later or left up to the entity.
Definetely I realized, after some more self-brainstorming, that theory-only is my best choice.
Jamie, could you please move my early vote from theory and open source to theory only ? Thanks, and sorry for my early vote.
Rob
Incidentally - "Open Forensic Methodology" is a somewhat flexible working title at this point pending any better suggestions -)
I think it is a fine title. My concern was some people may conclude that there is a "non-open" forensic methodology.
I'm not sure that I agree with that … Obviously some tools make it an easier proposition than others, but, taking the basic assumption in computing that every program is merely an implementation of an algorithm, it would suggest that there is nothing that you can extract in terms of evidence from EnCase ( or the program of your choice ) that you can't extract using WinHex ( enter your favourite hex level disk viewer here ), given enough knowledge, time and patience …
In fact, as one should really verify any results obtained using a given program, one would really hope that nothing is locked into a specific vendor …
Let me further clarify what I suggested - there will be new ground-breaking methodologies to do something innovative.
For example visually representing information process flow, using data timestamps cross referenced with file header types, allowing a definite conclusion of … whatever.
In such new tool, the methodology is unique to that single vendor. Theoretically we could extract the methodology and not mention the vendor, but it would do no justice as most naming and process conventions for that methodology would be driven by the vendor. Just a thought.
Jamie, could you please move my early vote from theory and open source to theory only ? Thanks, and sorry for my early vote.
There isn't a particularly easy way to do that other than fiddling with the database directly (not something I'm going to do late Friday night) - let's just keep the change in mind.
Jamie
Vote cast (option 1). I think I'd already assumed this to be the case anyway.
Now, that's not to say that I don't think that some examples would have merit - just that I think that they should not be part of the main methodology - appendix at worst - separate worked examples at best. I would suggest that in doing this ( if it is indeed us that do it … ) using Open Source tools would be fairest
Agreed.
Jamie
First, I want to say that it is great to see you guys respond to a much needed area in forensics. I'm fairly new to this board, but not new to forensics. I'd be willing to help in this endeavour.
Here's my .02 on this particular topic. Maybe more of a question. First, let me give some background.
I had a case in recent history where I had to investigate one of our parole client's linux box. On a standard install, this is straightforward. But this one had LVM2 configured. This means, that my tool of choice, and none that I'm aware (on the Windows side) will read it natively. I had to get very creative, I'm sort of proud of how it turned out, with a combination of VM Ware, EnCase and Helix to get the necessary evidence.
That being said, if the "methodology" includes how to do specific things, albeit high level ideas, and to the best of my knowledge would require those very specific tools, how would should they be addressed?
For most areas however, I do think theory would be best.