RE: Incident investigation methodologies

[Harlan Carvey <keydet89 () yahoo com>]

> > Based on the circumstances, one must
> > assess the risk vs. reward of performing certain
> > actions versus and make a decision.  In some
> > circumstances, it makes sence to take a production
> > system off-line and in other cases, it doesn't. 
> In
> > some cases, it may even make sence to simply
> monitor
> > the situation and otherwise do nothing.
>
> Agreed. So if we assign response scenarios based
> upon
> criticality of data, we can provide administrators
> with a template for each type of situation.

Agreed.  However, consider this...rather than
assigning response scenarios based on criticality of
data, the response activities should be passed on
policy...and the policy should identify critical
systems.  A matter of semantics, perhaps, but policies
and procedures are a critical part of incident
response, particularly in a corporate environment. 
They also play a critical role in the LEO environment.

I think the question then becomes, do we need to have
separate templates based on the activities, or can we
create a single template for, say, the most critical
systems, and that same template can be used for all
less-critical systems?
  
> Simply restoring from backup will not prevent the
> same
> compromise from occuring again, so we might want to
> do
> some analysis to determine how the intrusion
> occurred
> and prevent the system from being compromised as
> soon as it is put back online. 

Exactly.  The lack of analysis seems to occur rather
frequently (I'm basing this statement on personal
experience and review of public lists).  I can't
really make any statements regarding re-infection or
re-compromise of systems based on empirical data.

> Agreed. This is the reason for assigning security
> labels. We can use the same idea for response
> levels.
> A compromise of a system with critical data should
> get
> the full forensic examination, and merely internal
> data should be reimaged and patched.

What I've been trying to develop is a usable,
verifiable, document procedure for collecting volatile
data from live systems, to perform incident
verification and identification.