RE: Incident investigation methodologies

["Fiscus, Kevin" <kfiscus () allianttech com>]

I have been watching this thread since its inception.  I must admit that I am a bit shocked.  The keys to good incident 
response and effective forensics investigations are your process and your approach.  Technology comes second.  If this 
were a matter of running the newest techno-gizmo, anyone could do it.  To effectively respond to an incident, we must 
have good processes.  In other words, we must have incident investigation methodologies.  I cannot think of anything 
that would be of greater value to an incident handler or a computer crime investigator (especially one new to the 
field) than a basic approach that has been tested and tried.  Having a group of skilled and experienced professionals 
who work together to build and maintain them would ensure that they are both useful and accurate.  This, I believe, is 
one half of what Harlan is trying to create.  I, for one, applaud this effort.

The second half of what I believe Harlan is trying to do is to take discussion from the realm of theory into the realm 
of practical experience.  We all know what rootkits should be able to do.  We all know that there are thousands of 
exploits in the wild.  It would seem to me that instead of saying that a rootkit could do something, it would be more 
beneficial to the community at large to:
 - State the capabilities of specific rootkits
 - Describe some of the indications that a rootkit may be present on a      system
 - Describe how the rootkit presence could be verified
 - Identify how the rootkit can be removed
 - Identify the steps that may be taken to discover how the rootkit ended up on the system in the first place

This information should be collected using real, controlled test scenarios or real-world experience rather that a bunch 
of theory that anyone who can read can get from the local book store.  Again, I think that this effort would be 
extremely valuable.

Kevin Fiscus, CISSP
GIAC Certified Forensics Analyst
SCSA, CCNA, RCSE
Alliant Technologies, LLC.

-----Original Message-----
From: FRCMSEC [mailto:FRCMSEC () terra es] 
Sent: Friday, June 04, 2004 1:01 AM
To: Harlan Carvey
Cc: incidents () securityfocus com; Gadi Evron
Subject: Re: Incident investigation methodologies

1º What you suggest is a modified version of Bugtraq.
2º People dont have time or dont want to make the effort of making a 
documented report every time they post a message.

I dont know what rootkit is capable of doing what things. I only want 
to know if it was a rootkit, if it is in my system and what it has done 
in my system.

If you want to document your activities, it will be something similar 
to forensic.

----- Mensaje Original -----
De: Harlan Carvey <keydet89 () yahoo com>
Fecha: Jueves, Junio 3, 2004 2:00 am
Asunto: Re: Incident investigation methodologies

> Gadi,
>
> > > While it's entirely possible that a rootkit
> > *could* do
> > > something, why not base what we do in fact, rather
> > > than in speculation, rumor, and paranoia?
> >
> > What you are suggesting, basically, is an
> > information sharing network 
> > for different attack descriptions and information?
> >
> > A forensic dictionary? :)
>
> Admittedly, I may not have been as absolutely clear as
> I could have, but I really don't see where you were
> able to infer such a thing - particularly given the
> title of the post.
>
> To try again...what I'm suggesting is a documented,
> verifiable, repeatable methodology for incident
> response.  I'm aware that the implemented methodology
> will have to specific to the platform (ie, Windows,
> Linux, *nix, *BSD, etc).  I'm also aware that the
> framework will have to be flexible enough to allow new
> information to be incorporated.
>
> Hopefully, that's clear enough for a start...