Structure and Approach

Sorry, slightly OT but does this page format weirdly in other people's browsers or is it just me (might be to do with the quoted text)?

J

Sorry my bad … (

Should be better now … )

Lost a " in my manual quoting … ?

It seems to me that there are two basic structures that we can take

a) One single, comprehensive document.

b) Multiple documents, each covering a specific area, with an overseeing guide to their combination and usage.

I must admit that I started off thinking about doing (a) but as time goes on I am really heading down the route of (b). I think that this will allow the workload to be better distributed amongst willing participants, will allow individual sections to be kept up-to-date rather than having to review a full document, and will make for easier referencing and day-to-day use.

I think this is the prefered path. By having each methodology in a separate document we can expand and customize as needed. The level of detail will, by their nature, vary greatly depending on the topic and the user and their needs.

An idea, due to the huge number of topics involved in CF, what about using the "programming by interfaces" paradigm and trying first to describe the generic approach to an artifact (i.e. a rdbms, a vm, etc.) then "implement" the concept on the specific (i.e. mysql, vmvare, etc.).
How does it sound to you ?

If I understand what your saying, I agree. Can you give us a strawman?

what about using the "programming by interfaces" paradigm…

I must be honest and say I'm struggling with this, can someone outline the idea in layman's terms? Thanks.

Jamie

@Jamie
I apologize for the expression, it's my damned background as a Java developer that sometimes comes out.
"programming by interfaces" is one of the main guidelines in Java programming (object oriented), it consists in defining behaviours of the object that you want to use in a special kind of class called "interface"; then you can implement in different ways (different classes) this interface in order to have a common general behaviour.
Binding the concept (ad adjusting it) on CF methodology, we can say that approaching a system we can have some common behaviours for all the systems (from the mobile phone with Symbian to the unix server), implementing the interface "system" we'll have classes about Windows, Mac OS, etc.; every class is adocument or chapter of).
I said that because it seems that we're facing a huge task and I felt a safe approach beginnig with interfaces and implement later.
Always imho and always open to other better approaches.
cheers

Rob

Thanks Rob, my limited experience of Java programming was so long ago that it's all but forgotten. Could you expand on an example in even more detail so we can take a closer look at what you have in mind? I definitely think it's time well spent looking at as many methods as possible of addressing the breadth and complexity of investigations wrt a new methodology.

Jamie

I'm going to have a stab at this one based on my (limited) knowledge of object concepts …

What I think that you are saying is that essentially we define a top level document (class) and then we create instances of that document (class) for each type of system within it ?

So we would start off with

system
|
|
--- pda
|
|
--- phone
|
|
--- computer
|
--- unix
|
--- apple
|
--- pc

where each contains a set of attributes that are passed down from the parent class and adds more, depending on specific implementations …

So for example all classes would have the attribute "data" but only the computer classes would have the attribute "disk" ?

How far off am I ? 😉

( OO fans please forgive me - I only write procedural perl ! )

Jamie,
in order to avoid any misunderstanding on "programming by interfaces" - my written English doesn't allow me to be as clear as I would want - I suggested that approach for the document used to describe the methodology not for the methodology itself, but if you and other of the smart guys in CF feel that it could be applied for investigations as well… better!
Anyway I'll manage an example in a couple of days (I hope).
cheers
Rob

my written English doesn't allow me to be as clear as I would want

Rob, don’t worry my friend. My native language is ‘merican, so I struggle with English as well. )

Azrael, my understanding of the concepts seems to arrive at a similar point, but coming from a different direction. If the list will indulge me, I’ll explain how I’m looking at methodology. My living is education and training, forensics being the most joyful part of that. I tend to look at “things to be taught,” the order they need to be taught in, and what detail and proficiency any given topic should be taught to.

Forensics consists of a series of domains of knowledge, a subset of that being a common body of knowledge. Much of the contents of each domains are methods, some good, some bad, some universal, some very specific. Some of the contents is theory, business practice, policy and such that are not methods.

One of the Azrael identified above is the system domain and most would agree that PC (Windows) would be part of the common body of knowledge as they comprise the largest single category of forensic work.

I’ll put a separate posting under topics about how I see the topics concerned within the framework of domains of knowledge. As to this thread, “Structure and Approach” I’ll suggest this as an example.

Domains include (but obviously are not limited to
Acquisition of evidence
Systems

But under Acquisition of evidence we have specific jobs within the domain
Acquisition of “dead” system
Live system acquisition
Acquisition of Network Area Storage Device
And so on.

Under Acquisition of “dead” system we have a specific methodology (or what I would call a task)
Acquisition of an IDE drive using Tableau FireFly write-blocker
Acquisition of an IDE drive using HardCopy 2 write-blocker
And so on.

Thoughts? Comments?