Re: Incident investigation methodologies

[Harlan Carvey <keydet89 () yahoo com>]

> 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. 

Well, another way to look at it is that we can develop
methodologies that will allow us to determine whether
or not a 'rootkit' has been installed.  After all,
that's the goal of incident response, right? 
Determine whether or not an incident has occurred
(verification) and if so, what it is (identification).
 This then guides our responses. 

With regards to your question regarding whether or not
it's sufficient to analyze the state of the system,
I'd say that's a really good place to start.  After
all, there are freeware tools available that allow you
to do this...and with automation, data collection and
analysis can be done relatively quickly and
efficiently.  So, at no monetary cost, and very little
time, you can get an idea of whether or not something
happened on a system.  Whereas, dumping system memory
to a file on the drive an analyzing it offline is very
time consuming, and can be expensive (with regards to
tools and knowledge required).

> What is the best practice? 

Well, aside from what's already been posted here, I
think that was the focus of my original post.  Sure,
there are sites out there that list, in general terms,
what you can/should do, but very few (even CERT)
provide actual tools and steps.  What I'm looking at
doing is essentially developing best practices...well,
for Windows systems, anyway.

> Is the risk of a rootkit manipulating system calls
> low enough to work around it with an assorted
> collection of tools? 

> From my perspective of working with Windows systems, I
would say "yes".  From what I've seen so far, and
where I hope to go with regards to verifiable and
repeatable research, using multiple tools to examine a
system is very beneficial.  Using scripting languages
to automate the collection and correlation/analysis of
data increases the speed, efficiency, and reliability
of these activities.
 
> 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?

I have to admit, I really get cautious when I see
someone say "...of course documentation is crucial,
but...", as if to give a reason why documentation
should not be done.

To be very clear, what I'm proposing is a methodology
that can be implemented for different platforms.  The
point is that the methodology (and it's
implementation) be solid enough to take rootkits into
account now, but also be flexible enough that new
information can be added in the future, as it becomes
available.

When you do not even know whether or not an incident
has occurred...you simply have a user report or
something odd appearing in your IDS or logs, live
analysis should be the first step in determining what
occurred.
  
> Because in security business it's always good to be
> paranoid to some extent ;)

You know, I hear that a lot.  How about this, instead?
 Rather than saying that it's good to be paranoid, or
actually being paranoid, why not be knowledgeable? 
According to dictionary.com, the definition of
"paranoid" is "Exhibiting or characterized by extreme
and irrational fear".  

Which do you think is better?  Fear, or knowledge? 
> From your perspective, would you rather have a
security professional address your issues with fear,
speculation and rumor, or with knowledge and
professionalism?

One more thing to think about...what happens when you
go to the doctor?  When you go to a doctor's office
with a complaint, does he simply give you a lethal
injection then perform an autopsy to determine what
was wrong with you?  Or does he collect volatile
information...interview you, ask you questions, take
your temperature and blood pressure, etc?