RE: Incident investigation methodologies
From: Fiscus, Kevin (kfiscus_at_allianttech.com)
Date: Fri, 4 Jun 2004 11:29:39 -0400 To: "FRCMSEC" <FRCMSEC@terra.es>, "Harlan Carvey" <firstname.lastname@example.org>
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.
From: FRCMSEC [mailto:FRCMSEC@terra.es]
Sent: Friday, June 04, 2004 1:01 AM
To: Harlan Carvey
Cc: email@example.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
----- Mensaje Original -----
De: Harlan Carvey <firstname.lastname@example.org>
Fecha: Jueves, Junio 3, 2004 2:00 am
Asunto: Re: Incident investigation methodologies
> > > 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...