Re: Incident investigation methodologies

[Maarten Van Horenbeeck <maarten () daemon be>]

Hello Harvey,

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

I am sorry, but I must disagree here.  I think your proposal makes sense,
and having actual data on intrusions is most definitely a good idea.  The
issue I see here however, is that in the end, "security engineering" is
mainly "exception engineering".  When we engineer towards information
security, we want to safeguard our information systems from a wide range
of threats, both things which can be assessed initially and those which
cannot.

When we do threat assessments on information architecture, it is the
essence of this work that I develop multiple layers to safeguard systems
against multiple exploits.  We try to implement HTTP reverse proxies in
order to filter requests and make sure that unknown attacks do not pass
through, we use anomaly based IDS to catch attacks which signature based
tracking wouldn't notice.

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

During the last couple of years, we have seen an increase in the amount of
truly malicious attacks.  Attacks which are focused on a certain goal, and
where significant effort is put into actually achieving that goal (pure
economics, really).  In such case, exploits are often specifically written
with as goal not to trigger existing IDS systems, or to bypass security
measures in place (antivirus systems without heuristic detection enabled).
An additional fact the forensics analyst will need to live with is the
fact that there are rootkits which are designed to look like other, more
common rootkits, while actually having a much more complicated design.

All our assessments should be based on facts, otherwise we would be doing
our profession a grave injustice.  However, the difference between most
forms of engineering and security/exception engineering is that we need to
think outside of the box, and imagine other uses of the application at
hand.  This is valid for all base tenets of information technology, both
in the field of secure coding and network design/forensics.  Getting
information from a user can be used for good purposes (engineering) and
for malicious purposes (exception/security engineering).  A rootkit can be
used both through predictable paths (a regular hack) and in ways which
cannot be predicted (corporate espionage?).

In principle I agree with your approach.  We should however not limit
ourselves to solely working from the basic "facts".  Someone may
understand our modern gadgets better than we do.  Someone will.  We should
take this into account when working on our defenses, and when doing
post-mortem analysis.

Best regards,
Maarten

--
Maarten Van Horenbeeck, GCIA <maarten () daemon be>
http://www.daemon.be/maarten