Incident investigation methodologies

[Harlan Carvey <keydet89 () yahoo com>]

Stepping off from a now-dead thread, I'd like to open
up the discussion for investigation methodologies.

As mentioned earlier, it's very easy to sit back and
say "a 'hacker' could...".  Yes, that's true...but
what that ultimately leads to is complete paralysis. 
At a certain point, there are so many things that an
attacker *could* do that there's no sense in doing any
sort of forensics on the system, live or otherwise.

Folks within the security profession, and even those
on  the fringes, are doing themselves a huge
disservice.  Posting to a public list/discussion that
something *could* happen serves no purpose, and
greatly reduces the signal to noise level.  

Instead, what I'm suggesting is that we, as a
professional community, look to repeatable experiments
in those cases where we do not have actual data.  By
that, I mean we set up and document our experiments to
a level that someone else can verify them...run them
on the same (or similar) set up and get the same (or
similar) results.  

How do we do this?  Here's an example...instead of
saying "...a rootkit could...", get a system and a
rootkit, and install it.  Find out what that
particular rootkit does.  Document your testing setup
(ie, WinXPSP1, etc), what you did to test (ie, ran
FileMon and RegMon) and what you found.  

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?