Security Incidents mailing list archives
Re: Incident investigation methodologies
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Thu, 3 Jun 2004 12:07:41 +0200
On 2004-06-02 Harlan Carvey wrote:
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.
Don't get me wrong. My question was: is it sufficient to analyze the system's state with tools/scripts running on the compromised system itself, or is it better to preserve the state in a memory dump and analyze it offline? The latter is of course more complicated, whereas the former bears the risk of a rootkit manipulating the data. What is the best practice? Is the risk of a rootkit manipulating system calls low enough to work around it with an assorted collection of tools? What are the experiences of the professionals in this field? Please keep in mind that, like I said before, I'm an absolute beginner in this field.
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.
Again, that was not my intention.
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.
Of course documentation is crucial, no matter whether you do the analysis on the live system or on a memory dump. But in case of a compromised system where you *don't* know, which rootkit is installed, or even if there is a rootkit installed at all? Would live analysis be best practice?
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?
Because in security business it's always good to be paranoid to some extent ;) Regards Ansgar Wiechers
Current thread:
- Re: NKADM rootkit - Something new?, (continued)
- Re: NKADM rootkit - Something new? Harlan Carvey (Jun 01)
- Re: NKADM rootkit - Something new? Gadi Evron (Jun 01)
- RE: NKADM rootkit - Something new? Lachniet, Mark (Jun 01)
- RE: NKADM rootkit - Something new? Levinson, Karl (Jun 01)
- Re: NKADM rootkit - Something new? 'Ansgar -59cobalt- Wiechers' (Jun 01)
- Re: NKADM rootkit - Something new? Harlan Carvey (Jun 02)
- Dead Thread: Re: NKADM rootkit - Something new? Daniel Hanson (Jun 02)
- Incident investigation methodologies Harlan Carvey (Jun 02)
- Re: Incident investigation methodologies Gadi Evron (Jun 02)
- Re: Incident investigation methodologies Harlan Carvey (Jun 03)
- Re: Incident investigation methodologies Ansgar -59cobalt- Wiechers (Jun 04)
- Re: Incident investigation methodologies Paul Schmehl (Jun 04)
- Re: Incident investigation methodologies Jon Coller (Jun 04)
- Re: Incident investigation methodologies Valdis . Kletnieks (Jun 04)
- Re: NKADM rootkit - Something new? 'Ansgar -59cobalt- Wiechers' (Jun 01)
- Re: Incident investigation methodologies Harlan Carvey (Jun 07)
- Re: NKADM rootkit - Something new? Harlan Carvey (Jun 01)
- Re: Incident investigation methodologies Pho Man (Jun 04)
- RE: Incident investigation methodologies James C Slora Jr (Jun 07)
- RE: Incident investigation methodologies Harlan Carvey (Jun 08)
- Re: Incident investigation methodologies James C. Slora Jr. (Jun 08)