sleuthkit-users

[sleuthkit-users] Autopsy Case Management Gripes

[Brian C. <ca...@sl...>]

I'm looking for input and suggestions.   TSK v2 now supports disk 
images, split images, and will soon support other formats.  It also 
autodetects the file system and partition types (I really should have 
done that a long time ago).  Now I need to redo the case management 
part of autopsy to work these features in.  While I am at it, I want to 
know what people hate about the case management or any suggestions that 
people have to make it better.

The new basic design will be that you give the path to the 
disk/partition image and Autopsy will identify the image type and what 
file systems are in a disk image.  You can change the settings and add 
a known MD5 and then the image will be imported.   You will also be 
able to manually define the locations of partitions.

I am planning on having a "recent" list on the front page that allows 
you to bypass the Case and Host opening.

Any ideas, suggestions, or opinions?

brian

Re: [sleuthkit-users] Autopsy Case Management Gripes

[Paul S. <pa...@vn...>]

Hi Brian,

Thanks for asking!  Although my suggestion may not seem directly related to=
=20
workflow, when you think about a team of investigators, their collaboration=
=20
and the ability to audit the actions of each investigator, it could be=20
useful.  Therefore, I toss it into the ring for discussion.  It is one of t=
he=20
things that has always made me wonder, "why wasn't it done this way?"  and=
=20
their could be some good reasons for it :-)

	Autopsy uses a browser based UI.  However, it is designed to be primarily =
a=20
single user application.  Why not add multi-user support in order to=20
facilitate the sharing of high-performance hardware?  It could have a huge=
=20
impact on the productivity of a group of investigators if Autopsy ran more =
as=20
a server application.  This may require some drastic re-design of the=20
application itself perhaps rewriting it for Apache & PHP which would also=20
facilitate (necessitate?) the addition of MySQL (maybe something lighter?)=
=20
for database functionality.  I could see this being a benefit particularly=
=20
for searching timelines & strings, and storing a user's favorite queries et=
c.=20

	Would it be faster?  I don't know.  But it allows a more distributed=20
architecture.  Sometimes the use of databases and extra layers of stuff can=
=20
add more delay, complexity and administrivia than the perceived benefits th=
at=20
make them worthwhile.

	This suggestion may not be as easy to implement as it is to type in an=20
email ;-)  It would most certainly make things more challenging to get the=
=20
application up and running.  One of the things I like the most about=20
TSK/Autopsy is the ease with which installation is performed.

Paul

On Wednesday 12 January 2005 14:36, Brian Carrier wrote:
> I'm looking for input and suggestions.   TSK v2 now supports disk
> images, split images, and will soon support other formats.  It also
> autodetects the file system and partition types (I really should have
> done that a long time ago).  Now I need to redo the case management
> part of autopsy to work these features in.  While I am at it, I want to
> know what people hate about the case management or any suggestions that
> people have to make it better.
>
> The new basic design will be that you give the path to the
> disk/partition image and Autopsy will identify the image type and what
> file systems are in a disk image.  You can change the settings and add
> a known MD5 and then the image will be imported.   You will also be
> able to manually define the locations of partitions.
>
> I am planning on having a "recent" list on the front page that allows
> you to bypass the Case and Host opening.
>
> Any ideas, suggestions, or opinions?
>
> brian
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy Case Management Gripes

[Brian C. <ca...@sl...>]

Autopsy is browser-based because I only recently started to learn how 
to develop "real" GUIs.  HTML was quick and dirty.  The original one 
was Apache-based, but that was a pain for installation.  I agree that a 
backend database would be useful and potentially faster, but there are 
again many installation issues and complications. From what I 
understand, this is what pyFlag is doing.

As it stands now, you can have multiple investigators working on the 
same system.  There is no data sharing though.  I.e. the notes from one 
investigator are not shared with another.  This could be changed so 
that all notes go to a common location and the note identifies which 
person created it.  This is an easy change.

brian




On Jan 12, 2005, at 6:22 PM, Paul Stillwell wrote:

> Hi Brian,
>
> Thanks for asking!  Although my suggestion may not seem directly 
> related to
> workflow, when you think about a team of investigators, their 
> collaboration
> and the ability to audit the actions of each investigator, it could be
> useful.  Therefore, I toss it into the ring for discussion.  It is one 
> of the
> things that has always made me wonder, "why wasn't it done this way?"  
> and
> their could be some good reasons for it :-)
>
> 	Autopsy uses a browser based UI.  However, it is designed to be 
> primarily a
> single user application.  Why not add multi-user support in order to
> facilitate the sharing of high-performance hardware?  It could have a 
> huge
> impact on the productivity of a group of investigators if Autopsy ran 
> more as
> a server application.  This may require some drastic re-design of the
> application itself perhaps rewriting it for Apache & PHP which would 
> also
> facilitate (necessitate?) the addition of MySQL (maybe something 
> lighter?)
> for database functionality.  I could see this being a benefit 
> particularly
> for searching timelines & strings, and storing a user's favorite 
> queries etc.
>
> 	Would it be faster?  I don't know.  But it allows a more distributed
> architecture.  Sometimes the use of databases and extra layers of 
> stuff can
> add more delay, complexity and administrivia than the perceived 
> benefits that
> make them worthwhile.
>
> 	This suggestion may not be as easy to implement as it is to type in an
> email ;-)  It would most certainly make things more challenging to get 
> the
> application up and running.  One of the things I like the most about
> TSK/Autopsy is the ease with which installation is performed.
>
> Paul
>
> On Wednesday 12 January 2005 14:36, Brian Carrier wrote:
>> I'm looking for input and suggestions.   TSK v2 now supports disk
>> images, split images, and will soon support other formats.  It also
>> autodetects the file system and partition types (I really should have
>> done that a long time ago).  Now I need to redo the case management
>> part of autopsy to work these features in.  While I am at it, I want 
>> to
>> know what people hate about the case management or any suggestions 
>> that
>> people have to make it better.
>>
>> The new basic design will be that you give the path to the
>> disk/partition image and Autopsy will identify the image type and what
>> file systems are in a disk image.  You can change the settings and add
>> a known MD5 and then the image will be imported.   You will also be
>> able to manually define the locations of partitions.
>>
>> I am planning on having a "recent" list on the front page that allows
>> you to bypass the Case and Host opening.
>>
>> Any ideas, suggestions, or opinions?
>>
>> brian
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy Case Management Gripes

[John E. <es...@ya...>]

Even as a completely new user to Autopsy I found the
case management side simple enough to understand and
use.

What I found a little tricky was the actual imaging
process itself.  What would have been useful would
have been a utility that provided a 'suggested' dd
command line for imaging a disk.  In other words, take
the simple but very common situation of an
investigator just hanging a copy of the drive to be
investigated onto his system - in Autopsy you could
browse or pick the physical drive or partition and
Autopsy would  suggest a suitable command line for
making an image of it and provide a suitable mount
command line for it.

I know there are quite a few imaging tools out there
but for someone completely new to this area this 
facility would help to get things moving. This stage
of course is really one step before case management as
 defined in Autopsy at the moment, but data gleaned at
 this stage eg paths to image files, image filenames,
mount commands etc could obviously be automatically 
incorporated into the case management side of Autopsy.

On the issue of whether to have a database at the
backend of the case management I think it would depend
on what database you had in mind.  Ideally you would 
want a db that was transparent to the user,  ie no
maintenance or setup.  Something like mysql might add
quite a hit to the installation / maintenance overhead
 for the user and of course it is something else that
could potentially go wrong.

One other suggestion (not to do with case management) 
that would have saved me loads of time recently is 
having an extra button on the key word search results 
screen in Autopsy.  The extra button would begin a 
batch process that would look up the filename (and
extension) of every hit and put the filename next to
each hit.  This would save loads of time because if
you are most interested in say Word Docs you could in
the first instance only look at those hits that are
word documents.  Taking it a stage further the results
could be displayed in a navigable tree form with each
branch representing a different file type.  At the
moment you have to visit every hit and manually
'click' the MFT link to get the filename and type.  I
know there would be a time overhead in a batch process
like this but at least it would all be done non
interactively (ie you  can go for some lunch while
it's all happening). 

One other thing, a facility whereby you could do a
second (and perhaps a third, fourth ..) keyword search
but only just the results of an initial keyword search
would be useful.  It would get round those situations
where you want to find files that have word1 AND word2
And possibly word3 in them (which I don't know whether
it is possible to set up as a regular expression).

PS, I am not griping :), I think it is a great
programme.

Cheers,
Paul.










 --- Brian Carrier <ca...@sl...> wrote: 
> I'm looking for input and suggestions.   TSK v2 now
> supports disk 
> images, split images, and will soon support other
> formats.  It also 
> autodetects the file system and partition types (I
> really should have 
> done that a long time ago).  Now I need to redo the
> case management 
> part of autopsy to work these features in.  While I
> am at it, I want to 
> know what people hate about the case management or
> any suggestions that 
> people have to make it better.
> 
> The new basic design will be that you give the path
> to the 
> disk/partition image and Autopsy will identify the
> image type and what 
> file systems are in a disk image.  You can change
> the settings and add 
> a known MD5 and then the image will be imported.  
> You will also be 
> able to manually define the locations of partitions.
> 
> I am planning on having a "recent" list on the front
> page that allows 
> you to bypass the Case and Host opening.
> 
> Any ideas, suggestions, or opinions?
> 
> brian
> 
> 
> 
>
-------------------------------------------------------
> The SF.Net email is sponsored by: Beat the
> post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>  


	
	
		
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Re: [sleuthkit-users] Autopsy Case Management Gripes

[Brian C. <ca...@sl...>]

On Jan 18, 2005, at 6:53 AM, John Edwards wrote:

> Even as a completely new user to Autopsy I found the
> case management side simple enough to understand and
> use.
>
> What I found a little tricky was the actual imaging
> process itself.  What would have been useful would
> have been a utility that provided a 'suggested' dd
> command line for imaging a disk.  In other words, take
> the simple but very common situation of an
> investigator just hanging a copy of the drive to be
> investigated onto his system - in Autopsy you could
> browse or pick the physical drive or partition and
> Autopsy would  suggest a suitable command line for
> making an image of it and provide a suitable mount
> command line for it.

Fortunately, there are starting to be more interfaces to 'dd' to make 
the process easier.  There are AIR and GRAB:

AIR:
http://air-imager.sourceforge.net/

GRAB:
http://www.e-fense.com/helix/index.html

I haven't actually used either, but I know of people that have.

> One other suggestion (not to do with case management)
> that would have saved me loads of time recently is
> having an extra button on the key word search results
> screen in Autopsy.  The extra button would begin a
> batch process that would look up the filename (and
> extension) of every hit and put the filename next to
> each hit.  This would save loads of time because if
> you are most interested in say Word Docs you could in
> the first instance only look at those hits that are
> word documents.

That is actually a fairly easy update.  I can add that to the todo list.

> One other thing, a facility whereby you could do a
> second (and perhaps a third, fourth ..) keyword search
> but only just the results of an initial keyword search
> would be useful.  It would get round those situations
> where you want to find files that have word1 AND word2
> And possibly word3 in them (which I don't know whether
> it is possible to set up as a regular expression).

That can't be easily done until logical file searching is added.

> PS, I am not griping :), I think it is a great
> programme.

no problem.  I like knowing what people want.  I'm not really an 
interface programmer, so I need all of the help that I can get.

brian